Porgy: technical documentation Oana Andrei, Maribel Fernandez, Hélène Kirchner, Guy Melançon, Olivier Namet and Bruno Pinaud This document may not be up to date. July 18, 2011 Porgy is a set of plugins for the Tulip Framework. See http://www.tulip-software.com for more details about Tulip. To read and understand this document, it is mandatory to be familiar with Tulip because each component of Porgy is a graph.

1

Overview

The graph hierarchy used in Tulip is represented in Fig. 1. The root graph (used only as a container) has three subgraphs: traces for storing the derivation trees which keeps a trace of each rewrite operation, Models and Rules which are used as containers. Each transformation rule (rule_1, rule_2, rule_3) are stored as a subgraph of Rules. Each state of the model (m0, m1) are subgraphs of Models. When one tries to apply a rule rk on a model mi with a set of position Pj , the instances of the left-hand side of rk in mi are computed as subgraphs of mi . At least, one element of Pj must be in each subgraph. The names of the subgraphs are computed as follows: sg_rk _u_Pj where rk is the name of the rule and u the identifier of the subgraph. Pj is the name of the property used for computing the positions.

2 2.1

Details about each type of graph Portnodes

Rules and models are graphs called “Portgraphs”. They are made of portnodes and edges which link the portnodes via the ports. Under Tulip, a portnode is made of nodes and edges (see Fig. 2-a and 2-b). A first node is the center of the portnode (EGF.EGF in Fig. 2). The nodes connected to the center node are the ports. The connections between portnodes can only be done through ports. The properties detailed below must be used in order to identify each part of a portnode:

1

Root Rules

Traces

MainTrace

rule_1 Rules

rule_2

other trace Models

rule_3

Models sg_rule_1_0_P Instances of the left−hand side of the rules

m1

m0 m_i

sg_rule_1_0_P

sg_rule_1_1_P

sg_rule_1_1_P

sg_rule_2_0_P

sg_rule_1_3_P

sg_rule_4_0_P

sg_rule_3_0_P

Figure 1: Tulip graph hierarchy.

(a) A portnode with(b) The 4 ports. structure.

internal

Figure 2: A portnode and its structure. PortNode_type: type of the node. Two possible values: center or port. State: define a particular state of the port. The possible values depend on the data used and can also be different between rules and models: • hidden: the port cannot be connected to another one (for biochemical networks). • used : the port is connected to another one. This property can be used along with the property called “arity” (see below). • free: the port can be connected to another one (for biochemical networks). • not used (only for rules): the state and arity of the port are not taken into account by the matching algorithm for the application of a rule. • Principal : the port is the principal port of the agent (for interaction nets).

2

Left−hand side

Bridge

Right−hand side

Figure 3: Structure of a rule.

2.2

Rules

The string “rule_” must be used at the beginning of the name of each subgraph representing a rule. 2.2.1

Structure of a rule

Figure 3 is an example of a simple rule. A rule is composed of a left-hand side, a right hand-side and a bridge which connects both sides. The red edges represent connections of equivalent ports between the left-hand side and the right-hand side. For instance, the two ports labeled “4” in both EGFR portnodes on the left-hand side are connected to the ports also labeled “4” in the right-hand side. These specific edges allow to restore the state of the node and its connections after rewriting (used mostly for ports in the “not used ” state or with an arity greater than zero). All connections between the left-hand side and the righthand side must go through a port of the bridge. 2.2.2

Additional properties

Some additional properties are required to define a rule: Arity: Arity of a port in the left-hand side of the rule. Sometimes a port needs to be connected to some other ports in the model which are not part of the

3

Figure 4: Example of a particular state of a model left-hand side of the rule. This property is used to indicate the number of connections. Rule_side: For each component (nodes and edges), identify the part of the rule. There are four possible values: left, right, bridge and bridge_port. The value “bridge” is used to indicate which node is the center of the bridge. It is also used for the edges on either side of the bridge. The value “bridge_port” is used to identify the ports of the bridge. saveId: Only useful on the right-hand side. Used to save the initial Tulip id of nodes and edges before rewriting. This property needs to be set before applying the rewrite algorithm. M: if an element of the right-hand side of the rule has its M property set to true, then it is added to the current P position of the newly generated model during rewriting.

2.3

Models

The models (see Fig. 4 for an example) have some additional properties to keep a trace of each transformation: new: Boolean property set to true if the edge or the portnode is new, i.e. it has been created or modified by the last transformation. The subgraphs of each models which represent the instantiation of the left-hand side of a rule, use some specific properties: tag: Tulip id of the corresponding node or edge in the left-hand side of the rule P: This property is used to define a subgraph of a model m. This subgraph can be used to restrict the search of the instances of the left-hand side rl of a rule r in m. When one tries to find the instances I of rl in m, at least one node of each I must be in P. It is possible to define more than one P.

4

Figure 5: Example of a derivation tree. The model of figure 4 is the metanode labelled m6. During the rewriting operations, P is transferred from the source model to the destination model. The property M of the right-hand side of the rule is used to update the P property of the destination model only for the newly created portnodes and edges.

2.4

Derivation tree

The nodes of the derivation tree are metanodes associated to each generated models (See Fig. 5). There is a black edge between two metanodes a and b if the application of a rule transforms a source model a into a destination model b. The label of the metanodes (on the left side of each node) is the name of the model. The label of the edges is the name of the subgraph of the source model which is the instance of the left-hand side of the rule used to create the destination model. A red edge represents the application of a parallel rule. The result of a strategy is represented by a green edge between the source model and the results of the strategy. This result can be a metanode if the strategy succeeds or a red node if the strategy ends on a failure.

3

Rules application

The application of a rule to a given model consists in two phases: find at least one instance of the left-hand side of the rule inside the model, then replace this instance by the right-hand side of the rule. Each instance of the left hand-side is computed as a subgraph of the corresponding model.

5

Algorithm 1 Algorithm for matching the left-hand side RL of a rule R in a model G RL ← Left-hand side of the rule to apply n ← number of instances to return for all connected component c of RL do if c is a single portnode then Find all equivalent instances of this portnode in G if no instance found then return fail end if else if c is composed of an edge linking two portnodes then Find all equivalent instances of this pattern in G if no instance found then return fail end if else if c is composed of at least two edges then Find all equivalent instances of each edge of c in G Only keep the solutions with only one connected component and edges in the same order if no instance found then return fail end if end if Construct all instances of RL in G by using the instances of each connected component of RL in G return n (or all) constructed instances end for

3.1

Left-hand side-model matching algorithm

Given a rule R and a model G, the aim of this algorithm is to find all the instances of the left-hand side RL of R in G. See Algorithm 1 for a high-level version of this algorithm.

3.2

Parallel application of rules

The parallel application of a set of rules simply consists in the creation and the application of a new rule which is the concatenation of the different rules one wants to apply. For example, if one wants to apply rules a, b and c in parallel, we start by creating a new rule called parallel_a_b_c. The left-hand side (resp. the right-hand side) of this new rule is the union of the left-hand sides (resp. the right-hand sides) of a, b and c. Before creating the parallel rule, a precondition is that the intersection between the left-hand sides of a, b and c is empty.

6

4

Strategy

4.1

Grammar

Let L, R be port graphs, M, N positions, ρ a property, m, n integers, pi ∈ [0, 1]. (Focusing) F := CrtGraph | CrtPos | CrtBan | AllSuc(F ) | OneSuc(F ) | NextSuc(F ) | Property(ρ, F ) | F ∪ F | F ∩ F | F \ F | ∅ | P rop(P ) (Applications) A := Id | Fail | (L ⇒ R)N M | (A k A) (Strategies) S := A | S; S | ppick(S1 , p1 , . . . , Si , pi ) | while(S)do(S) | (S)orelse(S) | if(S)then(S)else(S) | isEmpty(F ) | setPos(F ) | setBan(F ) In Tulip, the Property(ρ, F ) is written: Property(”propertyname”, ”v1”, F ) where propertyname is the name of the Tulip property to consider and v1 is the desired value property. Note that for the Property operator, F cannot contains a Property Operator. A focusing operation (F ) can also use an existing tulip property with the P rop operator (e.g. setPos(P rop(P )) where P is the name of an existing (Boolean) Tulip property.

4.2

Strategy operators

See [2] for more details and examples. These operators are implemented in the same manner they are described (except repeat(S) and while(S1 )do(S2 )max(n)). • not(S) , if(S)then(Fail)else(Id) fails if S succeeds and succeeds if S fails; the graph is unchanged. • try(S) , (S)orelse(Id) is a strategy that behaves like S if S succeeds, but if S fails then it behaves like Id. • repeat(S) , while(S)do(S) applies S as long as possible and returns Id with the graph on which S has failed. This operator is not implemented as it is described because if ppick(S1 , p1 , . . . , Si , pi ) is used in S, then we cannot guarantee that the user will have the same results for both execution of S. Instead of using a while operator, S is applied as long as it does not return Fail. If Fail is returned, the strategy ends on the previous execution of S (which returned Id). If S fails during its first execution, then repeat(S) returns Fail. • while(S1 )do(S2 )max(n) , if(S1 )then(S2 ; if(S1 )then(S2 ; . . . )else(Id))else(Id) where . . . is n times. The implementation is much simpler: a while loop executed at most n times is used. • for(n)do(S) , S; . . . ; S where S is repeated n times. • A9A0 is similar to A||A0 except that it returns Id if at least one application of A or A0 is possible. A1 |||A2 , if(A1 )then(if(A1 ||A2 )then(A1 ||A2 )else(A1 ))else(A2 ) 7

Figure 6: A small multiples representation of a path of a Trace Tree. This is the path between m0 and m19 in the model of Fig. 5 by following the black edges. This SM representation shows all the intermediate states between two graphs: instantiation of the left-hand side, the right-hand side and the position where the rewriting takes place (P)

4.3

Todo list

The following operators are not yet implemented: • A1 |||A2 but it is recognized by the grammar (it does nothing) • CrtBan, AllSuc(F ), OneSuc(F ), NextSuc(F ), F ∪ F, F ∩ F, F \ F, ∅ • setBan(F)

5

Tulip plugins

Porgy is a Tulip perspective. A Tulip perspective replaces Tulip’s default GUI and specifies the different views and associated interactors that need to be activated when launching the application. Our framework can also be downloaded as a standalone application already containing Tulip from the PORGY project website The files and the necessary instructions are available from https://gforge. inria.fr/projects/porgy/.

8

References [1] L. P. Cordella, P. Foggia, C. Sansone, and M. Vento. A (sub)graph isomorphism algorithm for matching large graphs. IEEE Trans. on Pattern Analysis and Machine Intelligence, 26(10):1367–1372, 2004. [2] O. Namet, M. Fernandez, and H. Kirchner. A strategy language for graph rewriting. In Logic-Based Program Synthesis and Transformation, (LOPSTR 2011), 2011. To appear. [3] J. R. Ullmann. An algorithm for subgraph isomorphism. J. of the Association for Computing Machinery, 23(1):31–42, 1976. [4] A. Zündorf. Graph pattern matching in progres. In Selected papers from the 5th International Workshop on Graph Gramars and Their Application to Computer Science, volume 1073 of Lecture Notes in Computer Science, pages 454–468. Springer-Verlag, London, UK, 1996.

9