- Email: [email protected]
Heterogeneous graph grammars synchronization in CAD systems supported by hypergraph representations of buildings
Expert Systems with Applications 41 (2014) 990–998
Contents lists available at SciVerse ScienceDirect
Expert Systems with Applications journal homepage: www.elsevier.com/locate/eswa
Heterogeneous graph grammars synchronization in CAD systems supported by hypergraph representations of buildings Leszek Kotulski a, Adam Se˛dziwy a,⇑, Barbara Strug b a b
Department of Applied Computer Science, AGH University of Science and Technology, Al. Mickiewicza 30, 30-059 Krakow, Poland Department of Physics, Astronomy and Applied Computer Science, Jagiellonian University, Reymonta 4, 30-059 Krakow, Poland
a r t i c l e
i n f o
Keywords: Hypergraph representation of buildings Hypergraph transformation Building information modeling Graph grammar synchronization
a b s t r a c t The automation of the design process is an important property of computer aided design systems. One of the methods which support it is using graph grammars as a tool for representing the design process. In this paper we consider the coordination of two independent sub-processes: interior and exterior design. The problem of their coordination results from the fact that both actions may interfere. Assuming that sub-processes are modelled by means of two independent graph grammars, our goal is to create a mechanism of their synchronization, which enables preserving an overall consistency of the design. The proposed mechanism is illustrated by the example of the interaction of external and internal design processes performed on the shared environment. 2013 Elsevier Ltd. All rights reserved.
1. Introduction Designing a building is a complex task, in which one has to take into consideration a lot of different aspects. The architectural design of buildings may be considered in the context of either interior or exterior design. Each of those approaches has separate objectives, constraints and so on. In this paper we focus on differences which are also reflected in the properties of formal methods used in both areas. It should be remarked that exterior design term which is used in this article is understood as giving a certain geometric form to a building. In particular it may also include some specific features like external windows, doors, air conditioners or balconies. Analogously, interior design term refers to the geometric arrangement of internal walls and features (doors, windows, heaters and so on). Let us note that aesthetic or other, non functional requirements may be imposed on such design processes at the higher level, e.g. as corresponding applicability predicates (see Section 4). Each design task considered in this paper may be regarded as a compound of two sub-processes carried out in the external and internal environment, respectively. It is obvious that both sub-processes meet in some points, so it’s necessary to prepare the methodology ensuring the coherence between them, especially in the mentioned areas of contact. The consistency between interior and exterior designs is essential for achieving architectural goals. To enable automation of a design process an appropriate representation of a building has to be selected first. The representation ⇑ Corresponding author. E-mail addresses: [email protected] (L. (A. Se˛dziwy), [email protected] (B. Strug).
Kotulski),
[email protected]
0957-4174/$ - see front matter 2013 Elsevier Ltd. All rights reserved. http://dx.doi.org/10.1016/j.eswa.2013.07.043
must be flexible enough to store different types of data. It also has to allow for using a mechanism of updating/modifying a structure at any time. In this paper hypergraphs are used as the representation of a building structure. Different types of graphs were successfully used to represent designs at different stages of the design process. In this paper the hypergraph representation and transformation model are used as a basis for creating a formal layer for the system supporting computer aided design. Changes to a design model, made during the process lifecycle, can be achieved by applying graph transformations. In many real life design tasks the changes/updates can be carried out simultaneously on different parts of a design. Hence a model based on graph transformations can also be coupled with a multi-agent paradigm to enable the parallelization of these transformations and thereby to mimic the real life approach. It is also assumed in the paper that a design process is represented by productions (rules) of two independent graph grammars, describing operations performed on the interior and exterior, respectively. On the other hand, some productions of one grammar will trigger transformations accomplished by the second one. We introduce in the paper the synchronization mechanism which guaranties the consistent execution of two coupled productions, belonging to different graph grammars. The motivation for the work presented here is preparing the mechanism of coordination of two different and independent graph grammars, having productions operating on two contacting areas. The proposed approach is illustrated by the case study from the domain of building design, where it is used to ensure consistency of the design process. The paper is organized as follows. In the next section the overview of related works is briefly presented . Section 3 contains the
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
formal definition of a hypergraph representation used in the work. The notion of a hypergraph transformation is included in Section 4. In Section 5 we set up shared namespace for interior and exterior productions. The synchronization mechanism for the parallel application of both productions and the corresponding case study are presented in Section 6. Section 7 contains final conclusions.
2. Related work Graphs and their transformation rules create a solid and formal background in various areas of systems modeling. It can be used in order to specify and formally verify different aspects of software systems, like structure and behavior. This area has been continuously and systematically researched and developed for over 40 years (Rozenberg, 1997; Ehrig, Engels, Kreowski, & Rozenberg, 1999; Rozenberg & Ehrig, 1999). Most of the research, however, is based on the centralized graph representations, which traditionally position graph transformations and multi-agent systems into opposite sides. Such an approach often results in problems with effectiveness of the practical application of theoretical results (e.g., membership problem) for the graph formalism with large expression power. In many real situations, and especially in computer-aided design, operations are often limited to a small part of a graph representing the whole object. Moreover, some operations can be carried out simultaneously on different parts of a graph, having only to cooperate when working on some contact areas. Implementing such a system requires both the method to represent objects within the system and a method of generating, updating and maintaining these designs. In case of using graph based representation a way of generating, updating and maintaining graphs representing designs is needed. There are many methods for it that were researched. These methods include approach based on application of the theory of formal languages to the computer aided design (Rozenberg, 1997; Ehrig et al., 1999; Rozenberg & Ehrig, 1999), in particular the graph based representation jointly with graph grammars (Borkowski, Grabska, Nikodem, & and Strug, 2003; Grabska, Nikodem, & and Strug, 2004; Nikodem & Strug, 2004), and grammar systems (Csuhaj-Varjú, Dassow, Kelemen, & Pa˘un, 1994; Csuhaj-Varjú, Dassow, & Pa˘un, 1993; Csuhaj-Varju & Vaszil, 2001; Csuhaj-Varju, 2004; Dasso, Pa˘un, & Rozenberg, 1997; Simeoni & Staniszkis, 1999; MartÃn-Vide & Mitrana, 1998; Kelemen, 1991). Other methods used to generate and transform graphs representing designs include evolutionary computations that were used in different domains of design (Borkowski et al., 2003; Grabska et al., 2004; Nikodem & Strug, 2004). An approach to the distributed design based on simple graphs and using a multi-agent system was presented in Strug and Kotulski (2007), Kotulski and Strug (2008), Kotulski and Strug (2011). Maintaining data for building purposes has also been widely research, and BIM (Building Information Modelling) systems are commonly used (Eastman, Teicholz, Sacks, & Liston, 2008). The data contained within hypergraph structures used in this paper can be accessed by multiple applications. Information, which is stored in attributes of atoms can also be exported in different formats to be used by other applications accepting BIM formats, usually through the IFC (buildingSMART, 2005). Yet, standard BIM formats provide only partial support for structural relationships and they do not support multi-argument relations among elements. The CityGML semantic meta-model based on GML (Geography Markup Language) is a highly expressive language which allows modelling urban spaces with granularity varying from a geographical region to a building interior (CityGML, xxxx; Kolbe, 2009). One of its purposes is augmenting geometric-type data with the semantics of underlying objects. CityGML is also used as the data ex-
991
change format (see Chambelland & Gesquiere, 2012), enabling interoperability among different platforms, in particular BIM systems mentioned above or building ontology models (Métral, Falquet, & Karatzas, 2012). Putting together the description of both the external and internal structure of the building can be derived from different sources and its graph representation can have the form of a huge graph difficult to maintain together. Thus, the introduction of some kind of parallelism seems to be necessary (Kreowski & Kuske, 2011). But at the same time providing support for communication and cooperation for operations performed on different parts of a graph is vital in case shared elements are accessed. Assigning agents to be responsible for operating on parts of a graph structure seems to be a feasible and effective solution. Such an approach is used in the graph distribution toolkit called GRADIS (Kotulski, 2008a; Kotulski, 2008b; Kotulski & Sedziwy, 2010b; Kotulski & Sedziwy, 2010a; Kotulski & Sedziwy, 2012; Kotulski & Strug, 2012). GRADIS multi-agent environment supports: splitting a graph describing a problem, (called centralized graph) into smaller parts, (called local graphs), distributing (assigning) the local graphs to agents that take care for local graph modifications, and synchronizing and communicating among local graphs. Such an approach makes it possible to distribute and store local graphs on different computers and only access parts when they are needed. Yet in some cases we may not have a common graph as the external and internal design process are often carried out separately and result in different structures. Unifying them would be a costly process. yet a way of communication between this two structures is needed. The synchronization is the key issue in distributed processing problems. In the context of graph grammars (in both algorithmic and algebraic approach), it was considered in papers presenting GRADIS (GRAph DIStributed) multi-agent framework (Kotulski, 2008b; Kotulski & Sedziwy, 2010b). In those cases, however, one dealt with a homogeneous system having one grammar only, so no inter-grammar synchronization problems were present. For the GRADIS framework the polynomial, in terms of exchanged messages, complexity of the synchronization was proven in Kotulski and Sedziwy (2011). In this paper the main focus is on providing a way to synchronize the transformations between different grammars, which can be of different types and can see the same elements from different point of view and as elements of different graphs maintained for internal and external structure. The synchronization process is based on the shared elements, like name-spaces and coordinate systems, as well as the applicability predicates assigned to grammar transformations. The main contribution of this paper is thus the introduction of the synchronization mechanism for the heterogeneous transformations working on separate structures and following separate rules (represented by graph transformation).
3. Hypergraph representation In this section a notation related to hypergraphs and hypergraph grammars is introduced. This notation is used as the basis for the design model on which the transformations are carried out. Objects to be constructed are represented by hypergraphs, which are labelled and attributed. Our approach is based on a formal model of hypergraphs presented in Habel and Kreowski (1987), Minas (2002) and used for building description in Kotulski and Strug (2012). Simple graphs consist of nodes and edges connecting these nodes. Each edge in a simple graph connects exactly two nodes thus such a graph allows us to represent only binary relations between objects. Such a model is insufficient in many real life
992
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
problems, including design tasks. A hypergraph is an extension of a simple graph, which allows for the representation of multi-argument relations. A hypergraph consists of hyperedges and nodes. Hyperedges of the hypergraph are labelled, in case of design problems - by names of the corresponding relations and can be directed for the asymmetrical relations. Hypergraph nodes represent components of the design object. To represent features of components and relations between them, attributing of hyperedges and nodes is used. Values assigned to attributes specify the properties of objects represented by particular nodes and relations represented by hyperedges thus allowing us to generate an instance of the hypergraph. Let RE and RV be fixed alphabets of hyperedge and node labels, respectively. Let AV and AE denote sets of node and hyperedge attributes, respectively. Definition 1. A labelled and attributed hypergraph over R = RE [ RV is a system G = (V,E,lab,att), where: V is a finite set of nodes; E # P(V) is a finite set of hyperedges, such that "e 2 E: e is an ordered set of vertices; lab = (labV,labE) is a labeling function, where: labV:V ? RV, labE:E ? RE; att = (attV,attE) is an attributing function, where: attV:RV ? P(AV), attE:RE ? P(AE) and AV, AE are sets of node and hyperedge attributes respectively; The family of all labelled and attributed hypergraphs is denoted by H. Let val = (valV,valE) be a value assigning mapping, where: valV: AV V ? Da, valE:AE E ? Da assign a value to a given attribute a of a node/hyperedge, Da is referred to as a domain of a node/ hyperedge attribute. The set of all val functions will be denoted as VAL
Fig. 1. (a) Cuboid - the external building’s surface with the window w on the face f. Vertex O is the origin of the local coordinate system L (Lat and Lon stand for latitude and longitude, respectively), arrows represent base vectors of L (b) Surface hypergraph representing the cuboid; for the better clarity only the hyperedge representing O vertex was plotted.
3.2. Internal representation of buildings To represent the internal structure of a building hypergraphs are used in this paper. They are composed of nodes and hyperedges. Nodes correspond to design components, like walls, windows, areas etc., while hyperedges allow for expressing multi-argument relations between different object components. Nodes are labelled
Definition 2. An instance of a labelled and attributed hyperb ¼ ðG; v alÞ 2 H VAL. The family graph over R = RE [ RV is a pair G b will be denoted as H. b of all instances G 3.1. External representation of buildings On the basis of Definition 1 we introduce the hypergraph representation of a building’s external surface, basing on the model presented in Sedziwy (2012).
(a)
Definition 3. Let S be a polyhedron representing an external surface of a building, and GðSÞ ¼ ðV; E; lab; attÞ 2 H. G(S) is referred to as a surface hypergraph (SHY) of a polyhedron S, iff following conditions are fulfilled. 1. A set of vertices V = F [ W, where F is a set of nodes representing faces of S and W contains nodes representing external entities like windows, doors, attached lamps and so on. 2. E = AF [ AW [ H is a finite sum of edges such that: (a) AF # P2(F) represents all physical edges between polyhedron’s faces, (b) AW P2(F [ W) and "e 2 AW $!v 2 F$!w 2 W: e = {v,w}, S (c) H # i>2Pi(F) is a set of hyperedges representing all its physical vertices of S. We will denote the family of surface hypergraphs as Hs . Obviously, Hs # H. Example 1. An example of a surface hypergraph, representing the cuboid, is shown in Fig. 1.
(b) Fig. 2. An example of a flat diagram and its hypergraph representation.
993
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
1. l is a left side of the production, being a labelled hypergraph 2. r is an attributed hypergraph called a right side of the production b ! fTRUE; FALSEg, is a design predicate determining the 3. p : H production applicability. 4. eval is an evaluation function, which evaluates attributes of the right side of the production on the basis of the values of attributes of the subgraph L, of a current graph to which the left side of the production, l is matched. p
A production p will be also denoted as p : l ! r or in the ev al abbreviated form: p:l ? r.
Fig. 3. A 3D depiction of the design from Fig. 2.
by names of components they represent and hyperedges - by names of the relations among these components. Attributes are used to represent features of designs, like size, position, material or type. It may also be used to include information about particular brand of entity used in a given building. In case of hyperedges attributes represent parameters of a relation represented by a given hyperedge. For a floor layout such a property may, for example, indicate distance between two areas or type of connection. An example of such a floor layout diagram and its hypergraph representation is depicted in Fig. 2 a and b respectively. A 3D depiction of this design is shown in Fig. 3 (a 3D depiction obtained with Autodesk Homestyler Autodesk, xxxx). It has to be noted that this diagram represents only a part of a larger flat that, in turn, is a part of the whole floor. which in turn is a part of a multi-storey building. It has to be noted here that in Fig. 2 only labels for the nodes are shown. Yet, to each node a set of attributes is assigned. For example the set of attributes for the node labelled Wd contains such attributes like position, size, height, and a corresponding set of attributes for a node labelled with W contains such elements like type, nameWin, position, size, and others. To visualize an actual layout represented by a given hypergraph, each of attributes has to be assigned a value. By assigning a value we create an instance of a hypergraph. Thus the layout depicted in Figs. 2(a) and 3 is actually one of many possible instances of the hypergraph from Fig. 2(b). Remark on hyperedge drawing. There is no established way of visualizing hyperedges so in this paper a labeled hyperedge is drawn as a rectangle containing a label with lines connected to nodes of the hyperedge. For example in Fig. 2 a hyperedge labeled inL connects three nodes labeled W. To improve the readability of the figures the hyperedges connecting only two nodes are drawn as line segments, and their label is replaced by types of these segments. In Fig. 2a continuous line segment represents adj (adjacency relation) and a dashed one at (attachment relation). 4. Hypergraph transformations Hypergraphs representing structures of design solutions can be generated by hypergraph grammars. A hypergraph grammar is composed of a set of hyperedges with terminal and non-terminal labels, a set of hypergraph nodes, a set of productions and an axiom being its initial hypergraph. b be a family of instances of labelled, attributed Definition 4. Let H hypergraphs, then a grammar production is a tuple of the form p = (l,r,p,eval), where:
Application of the production p:l ? r to a given graph G (for example to the graph shown in Fig. 2)b is accomplished in following steps: a subgraph L # G, isomorphic with the left side of a production, i.e., with l, is established . Next L is removed from G and replaced by the right side of the production, i.e., by r. Finally one has to fix all hyperedges connecting previously G L with L. Those hyperedges have to be either removed or ‘‘reattached’’ to r. In this paper we use three rules of such a reattachment. 1. If explicit reattachment rules are provided for a given hyperedge e as a part of the production specification, we follow them. 2. If no rule is provided but all nodes of L to which a hyperedge e was incident are also present in r then e is reattached to those nodes. 3. If no rule is provided and any of nodes of L to which a hyperedge e was incident, is not retained in r then e is removed. The notation L(v) will be used to denote a node of a graph G (to which a production is applied), matching a node v belonging to the left hand side of the production. Similarly, L(’’B’’) will be used to denote a vertex of G, matching a node labelled with B from the left side of the production. In the case of the production shown in Fig. 5 the design predicate p is defined on the basis of attributes of L and it checks, for example, whether an attribute type of the node to which node v2 was matched equals external. More formally, p1 = {L(v2).type = external} is one of design requirements for this production. The edge reattachment rules are defined in such a way that all edges incident to the node L(v1), are reattached to the node w1, those attached to L(v2) - to w2 and those attached to the vertex matched to B are reattached to the node with the same label. All hyperedges attached to the node labelled Wd are removed. The last element of the production is the eval function which specifies the values of attributes of the elements of the right hand side of the production when it is inserted into the hypergraph being transformed. There are two possible way of establishing these values; either they are explicitly given with the right hand side of the production or the way of calculating them is given. For the production depicted in Fig. 4 attributes are established in the following way: 1. All values for the node labelled B are copied from L(B), i.e. from the node to which node B was matched. 2. All values for the node w1 are copied from L(v1), i.e. from the node to which node v1 was matched. 3. All values for the node w2 are copied from L(v2), i.e. from the node to which node v2 was matched. 4. All values for the node labelled Wd are explicitly given in the production (they are actually derived through the synchronization process, described below) An action performed on an object during a design process has to be made simultaneously at both levels: on external and internal
994
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
Fig. 4. External representation perspective. (a) Design action: moving the windows w from the face f1 to the new placement located on f3 (b) The production reflecting the design action shown in (a)
representation of a building. For this reason we have to apply a composite production consisting of transformations made on both hypergraph representations. Obviously, both productions have to be synchronized to preserve the consistency of a model. The example is moving a window to from the particular wall to another one. This operation may be permitted from the perspective of the interior architecture but illegal when taking into account constraints related to the outdoor design. An important step before applying such a transformation is determining at which level of a building description a composite production is initiated: external (for an exterior design priority) or internal (for an interior design) one. This particularization influences a synchronization process.
hyperedge (marked with dashed lines). Note that for the image clarity only this hyperedge is shown in (b) and remaining ones are omitted. Assume that a designer decides to change the placement of the window w from the face f1 to f3 (as marked with the empty rectangle in (a)). Such an operation, in the graph model, is represented by applying the production p to the surface hypergraph G(S) as shown in (b). The same action observed from the indoor perspective may be carried out according to the scheme presented in Fig. 5(see Fig. 6).
Example 2. Let us consider the external surface of the building shown in Fig. 4. To simplify, we assume its cuboidal shape. Particular faces of the building are denoted as f1,f2, . . . ,f6. In the hypergraph model they are mapped to hypergraph’s vertices. The sample building’s vertex, v1.3.5, is also marked in the figure. As other physical vertices, it is represented by a hypergraph’s
Fig. 5. An example of the production responsible for moving the window from the point of view of the internal representation
Fig. 6. A hypergraph after the application of the production from Fig. 4 to the hypergraph from Fig. 2(b)
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
It should be emphasized that from the architectural point of view some productions may be allowed for an indoor observer but forbidden for an external one. The example is moving the window w from the face f1 to f4 (the placement marked with the empty rectangle). This operation is not permitted from the outdoor, architectural, perspective due to the near presence of the neighbouring building. The complementary scenario is shifting a window on external face in such the way that its destination position overlaps with the location of a partition wall inside a building. These cases show that both productions, internal and external one, have to be agreed with respect to existing constraints.
Example 3. When the production from Fig. 4 is applied to the hypergraph depicted in Fig. 2(b) all hyperedges connected to the node labelled Wd are removed, while those connected to node v1are reattached to the one labelled w1, and similarly with those attached to node v2 in accordance with the reattachment rules associated with this production. It has to be noted here that while node v1can only be matched to node a in hypergraph from Fig. 2(b)node v2 can be matched to any of the nodes b,c and d.as in each case the selected subgraph is isomorphic with the left side of the production. Yet, only in case of matching node v2 to node b the design predicate yields TRUE and the production can be actually applied, as for nodes c and d the value of the attribute type is set to internal (as these nodes represent internal walls which can not contain windows). In this example there is only one node labelled Wd in the hypergraph being updated, so the matching of Wd is simple. In real life situation there are many windows in a building and thus the hypergraph would contain many nodes labelled Wd, so to avoid any ambiguity in addition to design predicates specified above the predicates based on geometrical values are checked. For this example such a predicate has to check the value of the attribute position in the hypergraph and compare it with the value of this attribute in the node Wd in the left side of the production. Only if this predicate returns TRUE the production can be applied. The resulting hypergraph is depicted in Fig. and the 3D view of the design in Fig. 7. 4.1. Parametrized transformations As it can be seen in the example above, shifting a window from one wall to another, may be accomplished by applying one of multiple productions, dependently on a type of a space enclosed by walls. For example different productions should be applied for a
995
Fig. 8. An example of a parametrized production
nodes labelled with B and Bt respectively. On the other side all those productions are structurally identical so one may reduce their number by introducing production parametrization. Let X be a set of parameters. A parametrized production is a pair pr = (p,f), where p is a production as defined above, and f is a matching relation, f:X ? P(RV), such that f(x 2 X) determines a set of possible (replaceable) labels of x. Such a parametrized production is depicted in Fig. 8. For this production X = {x}, f = {(x,{B,Bt,Lr,K})}.
5. Shared elements As the internal and external representations of the building can use different types of entities and thus different labelling and attributing schemes a number of shared elements must be agreed upon in order to be able to maintain communication and to synchronize processes. This elements can be of different types. Firstly, a common coordinate system must be agreed and a way to exchange geometric coordinates must be established. Secondly, names of attributes used by both external and internal transformation system have to be synchronized. Moreover the matching between labels of both external and internal hypergraphs have to be defined. It does not mean that the same names have to be used in both systems, but only that there is an unambiguous way of identifying elements that denote entities of the same type. 5.1. Coordinate systems In further considerations two types of coordinate systems will be used to describe geometry of a polyhedron S. A system of the first type (the absolute one) is any common known coordinate system, like WGS84, UTM or Lambert72. It may be assumed that such a system is linear within some reasonable neighbourhood of S, say, inside the radius R = 10,000 m. The coordinate system of the second type (local) is defined by: 1. setting some point, O, of a polyhedron S (or its neighbourhood) as an origin (Fig. 1aa); coordinates of O are given in the absolute system, 2. specifying a set of three linearly independent vectors (e.g., orthogonal ones), as a basis. To switch easily between these two types of coordinates we bound necessary information to a SHY modelling a polyhedron S: we will assign two special attributes to each edge, hyperedge and vertex. Let us consider the set of surface hypergraphs, Hs , and some GðSÞ 2 Hs . It is assumed that for all rV 2 RV and for all rE 2 RE, both attV(rV) and attE(rE) contain at least two attributes: 1. LocalOrigin holding absolute coordinates of an origin O of local coordinates of S, . 2. LocalBase holding a definition of a basis of a local coordinate system for a polyhedron S.
Fig. 7. The 3D depicton of the same design after the application of the production
b Additionally we assume that for a given instance GðSÞ
996
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
8v 2 V : v alV ðLocalOrigin; v Þ ¼ c1 ; 8v 2 V : v alV ðLocalBase; v Þ ¼ c2 ; 8e 2 E : v alE ðLocalOrigin; eÞ ¼ c1 ; 8e 2 E : v alE ðLocalBase; eÞ ¼ c2 ;
S = Sk,k 2 N where Sk is a selector which for a graph G chooses transition, t = (k,q,P), from a control point k, where q 2 N.
where constants c1 and c2 belong to a domain D. In other words, for a given polyhedron we define exactly one local coordinate system. The assumption formulated above allows for an unambiguous description of a polyhedron’s geometry: local coordinates of its components may be transformed into the absolute ones and vice versa. In case of the hypergraph representing the internal arrangements of the building two types of the coordinate systems are also needed. One has to place each element of building with respect to a selected point of the building. For this purpose LocalOrigin defined above is used. The second coordinate system is local to a building level and its origin is set to a StoreyOrigin. To enable communication between transformations modifying the external and internal representation of a building we assume that some attributes are visible and understood by both parties. Besides LocalOrigin attribute, introduced above also EntityType attribute is shared. It returns an object type (e.g., window, door etc.). Usually we bound a group of additional attributes to EntityType, which specify physical properties of an object, such as width or height. Since they depend strongly on an entity type we denote them collectively as EntityProperties. These data allow for expressing internal localizations in outdoor coordinates.
More intuitively, a derivation control diagram can be interpreted as a digraph which nodes are control points inside of which selectors are evaluated sequentially and thereby particular transitions between control points are selected. During such a transition either a production pRi is performed or a transition fails. The reason of a transition failure may be twofold: either a predicate pi value is FALSE or a subgraph of Hi, isomorphic to the left hand side of the production pRi can not be found. The evaluation of a derivation control diagram (denoted as E(D)) returns:
6. Synchronization process
pIi ) DRi ). The cohesion is defined in the transactional mode, i.e., pIi may be performed only if E DRi ¼ success, what means that
A starting point for further considerations is the example discussed in Section 5. We continue with analysis of two productions performed on internal and external hypergraph representations. Without loss of generality we can assume that the first of these productions, pI, is carried out by an initiator (operating on a hypergraph denoted by G) and the second one, pR, is made by a responder (operating on a hypergraph denoted by H). Both of them have to be performed. Now we would like to generalize this example. First we assume that an initiator executes a sequence of productions and either all of them can be accomplished or none of them will be executed. The second assumption is that a responder also executes a sequence of proper productions on a relevant graph. The first assumption means that there exists a sequence of productions pI1 ; . . . pIn such that: 81 6 i 6 n : pi ðGi Þ ¼ TRUE; and Giþ1 ¼ pIi ðGi Þ, where G1is an initial state of a hypergraph managed by an initiator. This sequence will be denoted as pI1 ; . . . ; pIn . The motivation for such a generalization is possibility of making design actions on a group of objects, e.g., shifting a row of external windows. The generalization implied by the second assumption is more complex. We have to ensure that for each initiator’s production, pIi , responder is able to perform a proper sequence of the productions, which are associated with pIi . To precise the term proper we use the notion of a derivation control diagram (see Kotulski & Strug, 2011).
success - if beginning in some starting control point (k 2 I) we are able to perform the productions ascribed to particular transitions and finally we reach some final control point (k0 2 F), failure - if none of the final control points is reachable from a starting control point, k 2 I. It may occur if particular transitions fail and/or particular selectors’ predicates are not fulfilled. With each graph grammar production, pIi , acting on an initiating side, we associate a cohesion derivation control diagram, DRi , controlling a derivation on a responder side (we will denote it as
some sequence of productions (on a responder side) described by derivation control diagram, can be performed. If E DRi ¼ failure for some i then none of productions given in pI1 ; . . . pIn is per I formed. Let us note that an action p1 ; . . . pIn can be described as a trivial form of a derivation control diagram with a simplified selector which points unconditionally the next transition. If we assume that the transition may fail when a corresponding evaluation returns FALSE (i.e., t = (k,q,p) fails iff E(D) = FALSE for p ) D) and that in the case of a nested cohesion (if pIi 2 DI and pIi ) DRi , see Fig. 9) a system guaranties the transactional execution of a sequence of productions at the initiator’s side then the problem of both generalizations is solved. 6.1. Case study The synchronization mechanism proposed in this paper was tested on the case of an operation of moving a window between two walls. This task is simple in itself but it implies a lot of different problems and thus provides a good test case; simple enough to be fully presented but at the same time complex enough to encompass many possible problems.
Definition 5. A derivation control diagram is a quintuple D = (N,I,F,T,S), where: N is the set of control points, I N and F N are sets of starting and final control points respectively, T is a set of transitions of the form t = (k,q,P), where: k,q 2 N are control points (transition occurs between k and q), P is either a production or £ symbol when no production is associated with this transition,
Fig. 9. Cohesion derivation control diagrams, DR1 ; DR2 ; . . . ; DRn , at the responder’s side, associated with the initiator’s productions controlled by the derivation control diagram DI.
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
997
Fig. 10. Example of a flat allowing for the transformations to be completed (left) and not allowing for it (right)
When the transformation system managing the external structure of a building initiates a window shifting then an appropriate production (depicted in Fig. 4) is triggered in the transformation system managing the internal structure of the building. The initiating system passes to the responder some information; in this case the source and target positions of the window to be moved. At the level of transformation systems these data are expressed as values of attributes of the left (source) and right (destination) side graphs of the production. Having relevant data the responder’s system tries to execute a transformation rule. There are three possible scenarios that have to be taken into account: 1. All design predicates return TRUE, the production is applied and returns success to the initiator. 2. Some design predicate fails, but the responder still tries to comply with the initiator’s demand by triggering subsequent local productions and after they are applied it returns succes. 3. As in the previous case but subsequent productions, triggered by the responder, failed and thus the system returns failure to the initiating system, what means that the transformation in the initiator’s system can not be performed. The first case was illustrated in the discussion of the production above. An example of the second case is illustrated in Fig. 10(left). In this case the wall to which the new window should be attached already contains the window, so the internal transformation system triggers other productions, in this case the one that makes the window smaller so that the new window can fit in. Fig. 10(right) illustrates one of the possible examples for the case 3. Here, the destination wall already contains two windows and the new one can not be fitted, thus the internal (responder’s) system returns failure to the initiating system. Hence the window can not be moved. 7. Conclusions In this paper the formal mechanism of synchronization for heterogeneous transformation systems was presented. This mechanism allows two separate transformation systems to communicate when they have to perform operations dealing with common elements of a building, but otherwise operating independently. The mechanism is based on shared elements: (i) a common reference coordinate system which allows for the proper identification of elements and (ii) matching mechanism for names of attributes and labels which have to be communicated. The matching mechanism is provided by an ontology mechanism, while coordinate systems are defined explicitly for systems. At this stage we consider a synchronization which either is carried out successfully (i.e., both transformation systems return TRUE) or fails altogether. Yet, in the example presented in the paper it would be an interesting option to allow the internal system to use some weighting mechanism to decide whether a window already present in the wall should be removed to make place for the new one. We also plan to extend data exchange mechanism between systems ant thereby to augment the interaction semantics.
References Autodesk. Autodesk homestyler, http://www.homestyler.com/. Borkowski, A., Grabska, E., Nikodem, P., and Strug, B., 2003. Searching for innovative structural layouts by means of graph grammars and esvolutionary optimization. In Proc. 2nd Int. Structural Eng. And Constr. Conf, pages 475–480. buildingSMART. 2005. Ifc specification, iso/pas. Chambelland, Jean-Christophe., and Gesquiere, Gilles., 2012. Complex virtual urban environment modeling from citygml data and ogc web services: application to the simfor project. pages 82901A–82901A–9. CityGML. http://www.citygml.org/. Csuhaj-Varju, E., 2004. Grammar systems: A short survey. In Proceedings of Grammar Systems Week 2004, pages 141–157. Csuhaj-Varjú, E., Dassow, J., Kelemen, J., & Pa˘un, Gh. (1994). Grammar Systems: A Grammatical Approach to Distribution and Cooperation. London: Gordon and Breach. Csuhaj-Varjú, E., Dassow, J., & Pa˘un, Gh. (1993). Dynamically controlled cooperating/distributed grammar systems. infsci, 69, 1–25. Csuhaj-Varju, E., & Vaszil, G. (2001). On context-free parallel communicating grammar systems: Synchronization, communication, and normal forms. TCS: Theoretical Computer Science, 255. Dasso, w J., Pa˘un, Gh., & Rozenberg, G. (1997). Grammar systems. In A. Salomaa & G. Rozenberg (Eds.). Handbook of formal languages (Vol. 2, pp. 155–213). BerlinHeidelberg: Springer. chapter 4. Eastman, C., Teicholz, P., Sacks, R., & Liston, K. (2008). BIM Handbook: A Guide to Building Information Modeling for Owners, Managers, Designers. Wiley. Ehrig, Hartmut, Engels, Gregor, Kreowski, Hans-Jörg, & Rozenberg, Grzegorz (Eds.). . Handbook of Graph Grammars and Computing by Graph Transformation. Applications, Languages and Tools (Vol. 2). Singapore: World Scientific. Grabska, E., Nikodem, P., and Strug, B., 2004. Evolutionary methods and graph grammars in design and optimization of skeletal structures. In 11th International Workshop on Intelligent Computing in Engineering. Habel and Kreowski., 1987. Some structural aspects of hypergraph languages generated by hyperedge replacement. In STACS: Annual Symposium on Theoretical Aspects of Computer Science. Kelemen, J. (1991). Syntactical models of cooperating/distributed problem solving. Journal of Experimental and Theoretical Artificial Intelligence, 3(1), 1–10. Kolbe, T. H. (2009). Representing and Exchanging 3D City Models with CityGML. In Jiyeong Lee & Sisi Zlatanova (Eds.), 3D Geo-Information Sciences. Lecture Notes in Geoinformation and Cartography (pp. 15–31). Berlin Heidelberg: Springer. ISBN 978-3-540-87394-5. Kotulski, Leszek (2008a). Distributed graphs transformed by multiagent system. In Leszek Rutkowski et al. (Eds.), Artificial Intelligence and Soft Computing - ICAISC 2008. LNCS (vol. 5097, pp. 1234–1242). Berlin Heidelberg: Springer. Kotulski, Leszek. (2008b). GRADIS - Multiagent Environment Supporting Distributed Graph Transformations. In Marian Bubak et al. (Eds.), Computational Science - ICCS 2008. LNCS (Vol. 5103, pp. 644–653). Berlin Heidelberg: Springer. Kotulski, L., & Se˛dziwy, A. (2010a). On the effective distribution of knowledge represented by complementary graphs. In Piotr Jedrzejowicz, Ngoc Thanh Nguyen, Robert J. Howlett, & Lakhmi C. Jain (Eds.), KES-AMSTA (1). Lecture Notes in Computer Science (Vol. 6070, pp. 381–390). Springer. ISBN 978-3-642-134791. Kotulski, Leszek, & Se˛dziwy, Adam (2010b). GRADIS - The multiagent environment supported by graph transformations. Simulation Modelling Practice and Theory, 18(10), 1515–1525. ISSN 1569-190X. Simulation-based Design and Evaluation of Multi-Agent Systems. Kotulski, Leszek, & Se˛dziwy, Adam (2011). Parallel graph transformations supported by replicated complementary graphs. In Proceedings of the 10th international conference on Adaptive and natural computing algorithms. ICANNGA’11 (Vol. Part II, pp. 254–264). Berlin, Heidelberg: Springer-Verlag. ISBN 978-3-642-20266-7. Kotulski, Leszek, & Se˛dziwy, Adam (2012). On the effective distribution and maintenance of knowledge represented by complementary graphs. T. Computational Collective Intelligence, 7190, 105–120. Kotulski, Leszek, & Strug, Barbara (2008). Using graph transformations in distributed adaptive design system. In Leonard Bolc, Juliusz L. Kulikowski, & Konrad W. Wojciechowski (Eds.), ICCVG. Lecture Notes in Computer Science (Vol. 5337, pp. 477–486). Springer. ISBN 978-3-642-02344-6. Kotulski, L., & Strug, B. (2011). Multi-agent system for distributed adaptive design. Key Engineering Materials, 486, 217–220.
998
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
Kotulski, L., & Strug, B. (2013). Supporting communication and cooperation in distributed representation for adaptive design. Advanced Engineering Informatics, 27, 220–229. Kreowski, Hans-Jörg, & Kuske, Sabine (2011). Graph multiset transformation: a new framework for massively parallel computation inspired by DNA computing. Natural Computing, 10(2), 961–986. MartÃn-Vide, C., and Mitrana, V., 1998. Cooperation in contextual grammars. In A. KelemenovÃ!, editor, Proceedings of the MFCS’98 Satellite Workshop on Grammar Systems, pages pp. 289–302. Métral, Claudine, Falquet, Gilles, & Karatzas, Kostas (2012). Ontologies for the integration of air quality models and 3D city models. URL http://arxiv.org/abs/ 1201.6511. Minas, M. (2002). Concepts and realization of a diagram editor generator based on hypergraph transformation. Science of Computer Programming, 44(2), 157–180. ISSN 0167-6423. URL http://www.elsevier.com/gej-ng/10/39/21/86/49/29/ abstract.html. Nikodem, P., & Strug, B. (2004). Graph transformations in evolutionary design. In Leszek Rutkowski, Jörg H. Siekmann, Ryszard Tadeusiewicz, & Lotfi A. Zadeh
(Eds.), ICAISC. Lecture Notes in Computer Science (Vol. 3070, pp. 456–461). Springer. ISBN 3-540-22123-9. Rozenberg, Grzegorz (1997). Handbook of Graph Grammars and Computing by Graph Transformations. Foundations (Vol. 1). World Scientific. ISBN 9810228848. Rozenberg, G., & Ehrig, H., et al. (Eds.). (1999). Handbook on Graph Grammars and Computing by Graph Transformation 3 (Concurrency). Singapore: World Scientific. Simeoni, M., & Staniszkis, M. (1999). Cooperating graph grammar systems. In Gh. Pa˘un & A. Salomaa (Eds.), Grammatical models of multi-agent systems (pp. 193–217). Amsterdam: Gordon and Breach. Se˛dziwy, Adam (2012). Representation of objects in agent-based lighting design problem. In Wojciech Zamojski et al. (Eds.), Complex Systems and Dependability. Advances in Intelligent and Soft Computing (vol. 170, pp. 209–223). Berlin Heidelberg: Springer. Strug, B., & Kotulski, L. (2007). Distributed adaptive design with hierarchical autonomous graph transformation systems. In Yong. Shi, G. Dick, Dongarra van Albada, Sloot Jack, & M. A. Peter (Eds.), ICCS (2). Lecture Notes in Computer Science (Vol. 4488, pp. 880–887). Springer. ISBN 978-3-540-72585-5.
Contents lists available at SciVerse ScienceDirect
Expert Systems with Applications journal homepage: www.elsevier.com/locate/eswa
Heterogeneous graph grammars synchronization in CAD systems supported by hypergraph representations of buildings Leszek Kotulski a, Adam Se˛dziwy a,⇑, Barbara Strug b a b
Department of Applied Computer Science, AGH University of Science and Technology, Al. Mickiewicza 30, 30-059 Krakow, Poland Department of Physics, Astronomy and Applied Computer Science, Jagiellonian University, Reymonta 4, 30-059 Krakow, Poland
a r t i c l e
i n f o
Keywords: Hypergraph representation of buildings Hypergraph transformation Building information modeling Graph grammar synchronization
a b s t r a c t The automation of the design process is an important property of computer aided design systems. One of the methods which support it is using graph grammars as a tool for representing the design process. In this paper we consider the coordination of two independent sub-processes: interior and exterior design. The problem of their coordination results from the fact that both actions may interfere. Assuming that sub-processes are modelled by means of two independent graph grammars, our goal is to create a mechanism of their synchronization, which enables preserving an overall consistency of the design. The proposed mechanism is illustrated by the example of the interaction of external and internal design processes performed on the shared environment. 2013 Elsevier Ltd. All rights reserved.
1. Introduction Designing a building is a complex task, in which one has to take into consideration a lot of different aspects. The architectural design of buildings may be considered in the context of either interior or exterior design. Each of those approaches has separate objectives, constraints and so on. In this paper we focus on differences which are also reflected in the properties of formal methods used in both areas. It should be remarked that exterior design term which is used in this article is understood as giving a certain geometric form to a building. In particular it may also include some specific features like external windows, doors, air conditioners or balconies. Analogously, interior design term refers to the geometric arrangement of internal walls and features (doors, windows, heaters and so on). Let us note that aesthetic or other, non functional requirements may be imposed on such design processes at the higher level, e.g. as corresponding applicability predicates (see Section 4). Each design task considered in this paper may be regarded as a compound of two sub-processes carried out in the external and internal environment, respectively. It is obvious that both sub-processes meet in some points, so it’s necessary to prepare the methodology ensuring the coherence between them, especially in the mentioned areas of contact. The consistency between interior and exterior designs is essential for achieving architectural goals. To enable automation of a design process an appropriate representation of a building has to be selected first. The representation ⇑ Corresponding author. E-mail addresses: [email protected] (L. (A. Se˛dziwy), [email protected] (B. Strug).
Kotulski),
[email protected]
0957-4174/$ - see front matter 2013 Elsevier Ltd. All rights reserved. http://dx.doi.org/10.1016/j.eswa.2013.07.043
must be flexible enough to store different types of data. It also has to allow for using a mechanism of updating/modifying a structure at any time. In this paper hypergraphs are used as the representation of a building structure. Different types of graphs were successfully used to represent designs at different stages of the design process. In this paper the hypergraph representation and transformation model are used as a basis for creating a formal layer for the system supporting computer aided design. Changes to a design model, made during the process lifecycle, can be achieved by applying graph transformations. In many real life design tasks the changes/updates can be carried out simultaneously on different parts of a design. Hence a model based on graph transformations can also be coupled with a multi-agent paradigm to enable the parallelization of these transformations and thereby to mimic the real life approach. It is also assumed in the paper that a design process is represented by productions (rules) of two independent graph grammars, describing operations performed on the interior and exterior, respectively. On the other hand, some productions of one grammar will trigger transformations accomplished by the second one. We introduce in the paper the synchronization mechanism which guaranties the consistent execution of two coupled productions, belonging to different graph grammars. The motivation for the work presented here is preparing the mechanism of coordination of two different and independent graph grammars, having productions operating on two contacting areas. The proposed approach is illustrated by the case study from the domain of building design, where it is used to ensure consistency of the design process. The paper is organized as follows. In the next section the overview of related works is briefly presented . Section 3 contains the
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
formal definition of a hypergraph representation used in the work. The notion of a hypergraph transformation is included in Section 4. In Section 5 we set up shared namespace for interior and exterior productions. The synchronization mechanism for the parallel application of both productions and the corresponding case study are presented in Section 6. Section 7 contains final conclusions.
2. Related work Graphs and their transformation rules create a solid and formal background in various areas of systems modeling. It can be used in order to specify and formally verify different aspects of software systems, like structure and behavior. This area has been continuously and systematically researched and developed for over 40 years (Rozenberg, 1997; Ehrig, Engels, Kreowski, & Rozenberg, 1999; Rozenberg & Ehrig, 1999). Most of the research, however, is based on the centralized graph representations, which traditionally position graph transformations and multi-agent systems into opposite sides. Such an approach often results in problems with effectiveness of the practical application of theoretical results (e.g., membership problem) for the graph formalism with large expression power. In many real situations, and especially in computer-aided design, operations are often limited to a small part of a graph representing the whole object. Moreover, some operations can be carried out simultaneously on different parts of a graph, having only to cooperate when working on some contact areas. Implementing such a system requires both the method to represent objects within the system and a method of generating, updating and maintaining these designs. In case of using graph based representation a way of generating, updating and maintaining graphs representing designs is needed. There are many methods for it that were researched. These methods include approach based on application of the theory of formal languages to the computer aided design (Rozenberg, 1997; Ehrig et al., 1999; Rozenberg & Ehrig, 1999), in particular the graph based representation jointly with graph grammars (Borkowski, Grabska, Nikodem, & and Strug, 2003; Grabska, Nikodem, & and Strug, 2004; Nikodem & Strug, 2004), and grammar systems (Csuhaj-Varjú, Dassow, Kelemen, & Pa˘un, 1994; Csuhaj-Varjú, Dassow, & Pa˘un, 1993; Csuhaj-Varju & Vaszil, 2001; Csuhaj-Varju, 2004; Dasso, Pa˘un, & Rozenberg, 1997; Simeoni & Staniszkis, 1999; MartÃn-Vide & Mitrana, 1998; Kelemen, 1991). Other methods used to generate and transform graphs representing designs include evolutionary computations that were used in different domains of design (Borkowski et al., 2003; Grabska et al., 2004; Nikodem & Strug, 2004). An approach to the distributed design based on simple graphs and using a multi-agent system was presented in Strug and Kotulski (2007), Kotulski and Strug (2008), Kotulski and Strug (2011). Maintaining data for building purposes has also been widely research, and BIM (Building Information Modelling) systems are commonly used (Eastman, Teicholz, Sacks, & Liston, 2008). The data contained within hypergraph structures used in this paper can be accessed by multiple applications. Information, which is stored in attributes of atoms can also be exported in different formats to be used by other applications accepting BIM formats, usually through the IFC (buildingSMART, 2005). Yet, standard BIM formats provide only partial support for structural relationships and they do not support multi-argument relations among elements. The CityGML semantic meta-model based on GML (Geography Markup Language) is a highly expressive language which allows modelling urban spaces with granularity varying from a geographical region to a building interior (CityGML, xxxx; Kolbe, 2009). One of its purposes is augmenting geometric-type data with the semantics of underlying objects. CityGML is also used as the data ex-
991
change format (see Chambelland & Gesquiere, 2012), enabling interoperability among different platforms, in particular BIM systems mentioned above or building ontology models (Métral, Falquet, & Karatzas, 2012). Putting together the description of both the external and internal structure of the building can be derived from different sources and its graph representation can have the form of a huge graph difficult to maintain together. Thus, the introduction of some kind of parallelism seems to be necessary (Kreowski & Kuske, 2011). But at the same time providing support for communication and cooperation for operations performed on different parts of a graph is vital in case shared elements are accessed. Assigning agents to be responsible for operating on parts of a graph structure seems to be a feasible and effective solution. Such an approach is used in the graph distribution toolkit called GRADIS (Kotulski, 2008a; Kotulski, 2008b; Kotulski & Sedziwy, 2010b; Kotulski & Sedziwy, 2010a; Kotulski & Sedziwy, 2012; Kotulski & Strug, 2012). GRADIS multi-agent environment supports: splitting a graph describing a problem, (called centralized graph) into smaller parts, (called local graphs), distributing (assigning) the local graphs to agents that take care for local graph modifications, and synchronizing and communicating among local graphs. Such an approach makes it possible to distribute and store local graphs on different computers and only access parts when they are needed. Yet in some cases we may not have a common graph as the external and internal design process are often carried out separately and result in different structures. Unifying them would be a costly process. yet a way of communication between this two structures is needed. The synchronization is the key issue in distributed processing problems. In the context of graph grammars (in both algorithmic and algebraic approach), it was considered in papers presenting GRADIS (GRAph DIStributed) multi-agent framework (Kotulski, 2008b; Kotulski & Sedziwy, 2010b). In those cases, however, one dealt with a homogeneous system having one grammar only, so no inter-grammar synchronization problems were present. For the GRADIS framework the polynomial, in terms of exchanged messages, complexity of the synchronization was proven in Kotulski and Sedziwy (2011). In this paper the main focus is on providing a way to synchronize the transformations between different grammars, which can be of different types and can see the same elements from different point of view and as elements of different graphs maintained for internal and external structure. The synchronization process is based on the shared elements, like name-spaces and coordinate systems, as well as the applicability predicates assigned to grammar transformations. The main contribution of this paper is thus the introduction of the synchronization mechanism for the heterogeneous transformations working on separate structures and following separate rules (represented by graph transformation).
3. Hypergraph representation In this section a notation related to hypergraphs and hypergraph grammars is introduced. This notation is used as the basis for the design model on which the transformations are carried out. Objects to be constructed are represented by hypergraphs, which are labelled and attributed. Our approach is based on a formal model of hypergraphs presented in Habel and Kreowski (1987), Minas (2002) and used for building description in Kotulski and Strug (2012). Simple graphs consist of nodes and edges connecting these nodes. Each edge in a simple graph connects exactly two nodes thus such a graph allows us to represent only binary relations between objects. Such a model is insufficient in many real life
992
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
problems, including design tasks. A hypergraph is an extension of a simple graph, which allows for the representation of multi-argument relations. A hypergraph consists of hyperedges and nodes. Hyperedges of the hypergraph are labelled, in case of design problems - by names of the corresponding relations and can be directed for the asymmetrical relations. Hypergraph nodes represent components of the design object. To represent features of components and relations between them, attributing of hyperedges and nodes is used. Values assigned to attributes specify the properties of objects represented by particular nodes and relations represented by hyperedges thus allowing us to generate an instance of the hypergraph. Let RE and RV be fixed alphabets of hyperedge and node labels, respectively. Let AV and AE denote sets of node and hyperedge attributes, respectively. Definition 1. A labelled and attributed hypergraph over R = RE [ RV is a system G = (V,E,lab,att), where: V is a finite set of nodes; E # P(V) is a finite set of hyperedges, such that "e 2 E: e is an ordered set of vertices; lab = (labV,labE) is a labeling function, where: labV:V ? RV, labE:E ? RE; att = (attV,attE) is an attributing function, where: attV:RV ? P(AV), attE:RE ? P(AE) and AV, AE are sets of node and hyperedge attributes respectively; The family of all labelled and attributed hypergraphs is denoted by H. Let val = (valV,valE) be a value assigning mapping, where: valV: AV V ? Da, valE:AE E ? Da assign a value to a given attribute a of a node/hyperedge, Da is referred to as a domain of a node/ hyperedge attribute. The set of all val functions will be denoted as VAL
Fig. 1. (a) Cuboid - the external building’s surface with the window w on the face f. Vertex O is the origin of the local coordinate system L (Lat and Lon stand for latitude and longitude, respectively), arrows represent base vectors of L (b) Surface hypergraph representing the cuboid; for the better clarity only the hyperedge representing O vertex was plotted.
3.2. Internal representation of buildings To represent the internal structure of a building hypergraphs are used in this paper. They are composed of nodes and hyperedges. Nodes correspond to design components, like walls, windows, areas etc., while hyperedges allow for expressing multi-argument relations between different object components. Nodes are labelled
Definition 2. An instance of a labelled and attributed hyperb ¼ ðG; v alÞ 2 H VAL. The family graph over R = RE [ RV is a pair G b will be denoted as H. b of all instances G 3.1. External representation of buildings On the basis of Definition 1 we introduce the hypergraph representation of a building’s external surface, basing on the model presented in Sedziwy (2012).
(a)
Definition 3. Let S be a polyhedron representing an external surface of a building, and GðSÞ ¼ ðV; E; lab; attÞ 2 H. G(S) is referred to as a surface hypergraph (SHY) of a polyhedron S, iff following conditions are fulfilled. 1. A set of vertices V = F [ W, where F is a set of nodes representing faces of S and W contains nodes representing external entities like windows, doors, attached lamps and so on. 2. E = AF [ AW [ H is a finite sum of edges such that: (a) AF # P2(F) represents all physical edges between polyhedron’s faces, (b) AW P2(F [ W) and "e 2 AW $!v 2 F$!w 2 W: e = {v,w}, S (c) H # i>2Pi(F) is a set of hyperedges representing all its physical vertices of S. We will denote the family of surface hypergraphs as Hs . Obviously, Hs # H. Example 1. An example of a surface hypergraph, representing the cuboid, is shown in Fig. 1.
(b) Fig. 2. An example of a flat diagram and its hypergraph representation.
993
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
1. l is a left side of the production, being a labelled hypergraph 2. r is an attributed hypergraph called a right side of the production b ! fTRUE; FALSEg, is a design predicate determining the 3. p : H production applicability. 4. eval is an evaluation function, which evaluates attributes of the right side of the production on the basis of the values of attributes of the subgraph L, of a current graph to which the left side of the production, l is matched. p
A production p will be also denoted as p : l ! r or in the ev al abbreviated form: p:l ? r.
Fig. 3. A 3D depiction of the design from Fig. 2.
by names of components they represent and hyperedges - by names of the relations among these components. Attributes are used to represent features of designs, like size, position, material or type. It may also be used to include information about particular brand of entity used in a given building. In case of hyperedges attributes represent parameters of a relation represented by a given hyperedge. For a floor layout such a property may, for example, indicate distance between two areas or type of connection. An example of such a floor layout diagram and its hypergraph representation is depicted in Fig. 2 a and b respectively. A 3D depiction of this design is shown in Fig. 3 (a 3D depiction obtained with Autodesk Homestyler Autodesk, xxxx). It has to be noted that this diagram represents only a part of a larger flat that, in turn, is a part of the whole floor. which in turn is a part of a multi-storey building. It has to be noted here that in Fig. 2 only labels for the nodes are shown. Yet, to each node a set of attributes is assigned. For example the set of attributes for the node labelled Wd contains such attributes like position, size, height, and a corresponding set of attributes for a node labelled with W contains such elements like type, nameWin, position, size, and others. To visualize an actual layout represented by a given hypergraph, each of attributes has to be assigned a value. By assigning a value we create an instance of a hypergraph. Thus the layout depicted in Figs. 2(a) and 3 is actually one of many possible instances of the hypergraph from Fig. 2(b). Remark on hyperedge drawing. There is no established way of visualizing hyperedges so in this paper a labeled hyperedge is drawn as a rectangle containing a label with lines connected to nodes of the hyperedge. For example in Fig. 2 a hyperedge labeled inL connects three nodes labeled W. To improve the readability of the figures the hyperedges connecting only two nodes are drawn as line segments, and their label is replaced by types of these segments. In Fig. 2a continuous line segment represents adj (adjacency relation) and a dashed one at (attachment relation). 4. Hypergraph transformations Hypergraphs representing structures of design solutions can be generated by hypergraph grammars. A hypergraph grammar is composed of a set of hyperedges with terminal and non-terminal labels, a set of hypergraph nodes, a set of productions and an axiom being its initial hypergraph. b be a family of instances of labelled, attributed Definition 4. Let H hypergraphs, then a grammar production is a tuple of the form p = (l,r,p,eval), where:
Application of the production p:l ? r to a given graph G (for example to the graph shown in Fig. 2)b is accomplished in following steps: a subgraph L # G, isomorphic with the left side of a production, i.e., with l, is established . Next L is removed from G and replaced by the right side of the production, i.e., by r. Finally one has to fix all hyperedges connecting previously G L with L. Those hyperedges have to be either removed or ‘‘reattached’’ to r. In this paper we use three rules of such a reattachment. 1. If explicit reattachment rules are provided for a given hyperedge e as a part of the production specification, we follow them. 2. If no rule is provided but all nodes of L to which a hyperedge e was incident are also present in r then e is reattached to those nodes. 3. If no rule is provided and any of nodes of L to which a hyperedge e was incident, is not retained in r then e is removed. The notation L(v) will be used to denote a node of a graph G (to which a production is applied), matching a node v belonging to the left hand side of the production. Similarly, L(’’B’’) will be used to denote a vertex of G, matching a node labelled with B from the left side of the production. In the case of the production shown in Fig. 5 the design predicate p is defined on the basis of attributes of L and it checks, for example, whether an attribute type of the node to which node v2 was matched equals external. More formally, p1 = {L(v2).type = external} is one of design requirements for this production. The edge reattachment rules are defined in such a way that all edges incident to the node L(v1), are reattached to the node w1, those attached to L(v2) - to w2 and those attached to the vertex matched to B are reattached to the node with the same label. All hyperedges attached to the node labelled Wd are removed. The last element of the production is the eval function which specifies the values of attributes of the elements of the right hand side of the production when it is inserted into the hypergraph being transformed. There are two possible way of establishing these values; either they are explicitly given with the right hand side of the production or the way of calculating them is given. For the production depicted in Fig. 4 attributes are established in the following way: 1. All values for the node labelled B are copied from L(B), i.e. from the node to which node B was matched. 2. All values for the node w1 are copied from L(v1), i.e. from the node to which node v1 was matched. 3. All values for the node w2 are copied from L(v2), i.e. from the node to which node v2 was matched. 4. All values for the node labelled Wd are explicitly given in the production (they are actually derived through the synchronization process, described below) An action performed on an object during a design process has to be made simultaneously at both levels: on external and internal
994
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
Fig. 4. External representation perspective. (a) Design action: moving the windows w from the face f1 to the new placement located on f3 (b) The production reflecting the design action shown in (a)
representation of a building. For this reason we have to apply a composite production consisting of transformations made on both hypergraph representations. Obviously, both productions have to be synchronized to preserve the consistency of a model. The example is moving a window to from the particular wall to another one. This operation may be permitted from the perspective of the interior architecture but illegal when taking into account constraints related to the outdoor design. An important step before applying such a transformation is determining at which level of a building description a composite production is initiated: external (for an exterior design priority) or internal (for an interior design) one. This particularization influences a synchronization process.
hyperedge (marked with dashed lines). Note that for the image clarity only this hyperedge is shown in (b) and remaining ones are omitted. Assume that a designer decides to change the placement of the window w from the face f1 to f3 (as marked with the empty rectangle in (a)). Such an operation, in the graph model, is represented by applying the production p to the surface hypergraph G(S) as shown in (b). The same action observed from the indoor perspective may be carried out according to the scheme presented in Fig. 5(see Fig. 6).
Example 2. Let us consider the external surface of the building shown in Fig. 4. To simplify, we assume its cuboidal shape. Particular faces of the building are denoted as f1,f2, . . . ,f6. In the hypergraph model they are mapped to hypergraph’s vertices. The sample building’s vertex, v1.3.5, is also marked in the figure. As other physical vertices, it is represented by a hypergraph’s
Fig. 5. An example of the production responsible for moving the window from the point of view of the internal representation
Fig. 6. A hypergraph after the application of the production from Fig. 4 to the hypergraph from Fig. 2(b)
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
It should be emphasized that from the architectural point of view some productions may be allowed for an indoor observer but forbidden for an external one. The example is moving the window w from the face f1 to f4 (the placement marked with the empty rectangle). This operation is not permitted from the outdoor, architectural, perspective due to the near presence of the neighbouring building. The complementary scenario is shifting a window on external face in such the way that its destination position overlaps with the location of a partition wall inside a building. These cases show that both productions, internal and external one, have to be agreed with respect to existing constraints.
Example 3. When the production from Fig. 4 is applied to the hypergraph depicted in Fig. 2(b) all hyperedges connected to the node labelled Wd are removed, while those connected to node v1are reattached to the one labelled w1, and similarly with those attached to node v2 in accordance with the reattachment rules associated with this production. It has to be noted here that while node v1can only be matched to node a in hypergraph from Fig. 2(b)node v2 can be matched to any of the nodes b,c and d.as in each case the selected subgraph is isomorphic with the left side of the production. Yet, only in case of matching node v2 to node b the design predicate yields TRUE and the production can be actually applied, as for nodes c and d the value of the attribute type is set to internal (as these nodes represent internal walls which can not contain windows). In this example there is only one node labelled Wd in the hypergraph being updated, so the matching of Wd is simple. In real life situation there are many windows in a building and thus the hypergraph would contain many nodes labelled Wd, so to avoid any ambiguity in addition to design predicates specified above the predicates based on geometrical values are checked. For this example such a predicate has to check the value of the attribute position in the hypergraph and compare it with the value of this attribute in the node Wd in the left side of the production. Only if this predicate returns TRUE the production can be applied. The resulting hypergraph is depicted in Fig. and the 3D view of the design in Fig. 7. 4.1. Parametrized transformations As it can be seen in the example above, shifting a window from one wall to another, may be accomplished by applying one of multiple productions, dependently on a type of a space enclosed by walls. For example different productions should be applied for a
995
Fig. 8. An example of a parametrized production
nodes labelled with B and Bt respectively. On the other side all those productions are structurally identical so one may reduce their number by introducing production parametrization. Let X be a set of parameters. A parametrized production is a pair pr = (p,f), where p is a production as defined above, and f is a matching relation, f:X ? P(RV), such that f(x 2 X) determines a set of possible (replaceable) labels of x. Such a parametrized production is depicted in Fig. 8. For this production X = {x}, f = {(x,{B,Bt,Lr,K})}.
5. Shared elements As the internal and external representations of the building can use different types of entities and thus different labelling and attributing schemes a number of shared elements must be agreed upon in order to be able to maintain communication and to synchronize processes. This elements can be of different types. Firstly, a common coordinate system must be agreed and a way to exchange geometric coordinates must be established. Secondly, names of attributes used by both external and internal transformation system have to be synchronized. Moreover the matching between labels of both external and internal hypergraphs have to be defined. It does not mean that the same names have to be used in both systems, but only that there is an unambiguous way of identifying elements that denote entities of the same type. 5.1. Coordinate systems In further considerations two types of coordinate systems will be used to describe geometry of a polyhedron S. A system of the first type (the absolute one) is any common known coordinate system, like WGS84, UTM or Lambert72. It may be assumed that such a system is linear within some reasonable neighbourhood of S, say, inside the radius R = 10,000 m. The coordinate system of the second type (local) is defined by: 1. setting some point, O, of a polyhedron S (or its neighbourhood) as an origin (Fig. 1aa); coordinates of O are given in the absolute system, 2. specifying a set of three linearly independent vectors (e.g., orthogonal ones), as a basis. To switch easily between these two types of coordinates we bound necessary information to a SHY modelling a polyhedron S: we will assign two special attributes to each edge, hyperedge and vertex. Let us consider the set of surface hypergraphs, Hs , and some GðSÞ 2 Hs . It is assumed that for all rV 2 RV and for all rE 2 RE, both attV(rV) and attE(rE) contain at least two attributes: 1. LocalOrigin holding absolute coordinates of an origin O of local coordinates of S, . 2. LocalBase holding a definition of a basis of a local coordinate system for a polyhedron S.
Fig. 7. The 3D depicton of the same design after the application of the production
b Additionally we assume that for a given instance GðSÞ
996
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
8v 2 V : v alV ðLocalOrigin; v Þ ¼ c1 ; 8v 2 V : v alV ðLocalBase; v Þ ¼ c2 ; 8e 2 E : v alE ðLocalOrigin; eÞ ¼ c1 ; 8e 2 E : v alE ðLocalBase; eÞ ¼ c2 ;
S = Sk,k 2 N where Sk is a selector which for a graph G chooses transition, t = (k,q,P), from a control point k, where q 2 N.
where constants c1 and c2 belong to a domain D. In other words, for a given polyhedron we define exactly one local coordinate system. The assumption formulated above allows for an unambiguous description of a polyhedron’s geometry: local coordinates of its components may be transformed into the absolute ones and vice versa. In case of the hypergraph representing the internal arrangements of the building two types of the coordinate systems are also needed. One has to place each element of building with respect to a selected point of the building. For this purpose LocalOrigin defined above is used. The second coordinate system is local to a building level and its origin is set to a StoreyOrigin. To enable communication between transformations modifying the external and internal representation of a building we assume that some attributes are visible and understood by both parties. Besides LocalOrigin attribute, introduced above also EntityType attribute is shared. It returns an object type (e.g., window, door etc.). Usually we bound a group of additional attributes to EntityType, which specify physical properties of an object, such as width or height. Since they depend strongly on an entity type we denote them collectively as EntityProperties. These data allow for expressing internal localizations in outdoor coordinates.
More intuitively, a derivation control diagram can be interpreted as a digraph which nodes are control points inside of which selectors are evaluated sequentially and thereby particular transitions between control points are selected. During such a transition either a production pRi is performed or a transition fails. The reason of a transition failure may be twofold: either a predicate pi value is FALSE or a subgraph of Hi, isomorphic to the left hand side of the production pRi can not be found. The evaluation of a derivation control diagram (denoted as E(D)) returns:
6. Synchronization process
pIi ) DRi ). The cohesion is defined in the transactional mode, i.e., pIi may be performed only if E DRi ¼ success, what means that
A starting point for further considerations is the example discussed in Section 5. We continue with analysis of two productions performed on internal and external hypergraph representations. Without loss of generality we can assume that the first of these productions, pI, is carried out by an initiator (operating on a hypergraph denoted by G) and the second one, pR, is made by a responder (operating on a hypergraph denoted by H). Both of them have to be performed. Now we would like to generalize this example. First we assume that an initiator executes a sequence of productions and either all of them can be accomplished or none of them will be executed. The second assumption is that a responder also executes a sequence of proper productions on a relevant graph. The first assumption means that there exists a sequence of productions pI1 ; . . . pIn such that: 81 6 i 6 n : pi ðGi Þ ¼ TRUE; and Giþ1 ¼ pIi ðGi Þ, where G1is an initial state of a hypergraph managed by an initiator. This sequence will be denoted as pI1 ; . . . ; pIn . The motivation for such a generalization is possibility of making design actions on a group of objects, e.g., shifting a row of external windows. The generalization implied by the second assumption is more complex. We have to ensure that for each initiator’s production, pIi , responder is able to perform a proper sequence of the productions, which are associated with pIi . To precise the term proper we use the notion of a derivation control diagram (see Kotulski & Strug, 2011).
success - if beginning in some starting control point (k 2 I) we are able to perform the productions ascribed to particular transitions and finally we reach some final control point (k0 2 F), failure - if none of the final control points is reachable from a starting control point, k 2 I. It may occur if particular transitions fail and/or particular selectors’ predicates are not fulfilled. With each graph grammar production, pIi , acting on an initiating side, we associate a cohesion derivation control diagram, DRi , controlling a derivation on a responder side (we will denote it as
some sequence of productions (on a responder side) described by derivation control diagram, can be performed. If E DRi ¼ failure for some i then none of productions given in pI1 ; . . . pIn is per I formed. Let us note that an action p1 ; . . . pIn can be described as a trivial form of a derivation control diagram with a simplified selector which points unconditionally the next transition. If we assume that the transition may fail when a corresponding evaluation returns FALSE (i.e., t = (k,q,p) fails iff E(D) = FALSE for p ) D) and that in the case of a nested cohesion (if pIi 2 DI and pIi ) DRi , see Fig. 9) a system guaranties the transactional execution of a sequence of productions at the initiator’s side then the problem of both generalizations is solved. 6.1. Case study The synchronization mechanism proposed in this paper was tested on the case of an operation of moving a window between two walls. This task is simple in itself but it implies a lot of different problems and thus provides a good test case; simple enough to be fully presented but at the same time complex enough to encompass many possible problems.
Definition 5. A derivation control diagram is a quintuple D = (N,I,F,T,S), where: N is the set of control points, I N and F N are sets of starting and final control points respectively, T is a set of transitions of the form t = (k,q,P), where: k,q 2 N are control points (transition occurs between k and q), P is either a production or £ symbol when no production is associated with this transition,
Fig. 9. Cohesion derivation control diagrams, DR1 ; DR2 ; . . . ; DRn , at the responder’s side, associated with the initiator’s productions controlled by the derivation control diagram DI.
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
997
Fig. 10. Example of a flat allowing for the transformations to be completed (left) and not allowing for it (right)
When the transformation system managing the external structure of a building initiates a window shifting then an appropriate production (depicted in Fig. 4) is triggered in the transformation system managing the internal structure of the building. The initiating system passes to the responder some information; in this case the source and target positions of the window to be moved. At the level of transformation systems these data are expressed as values of attributes of the left (source) and right (destination) side graphs of the production. Having relevant data the responder’s system tries to execute a transformation rule. There are three possible scenarios that have to be taken into account: 1. All design predicates return TRUE, the production is applied and returns success to the initiator. 2. Some design predicate fails, but the responder still tries to comply with the initiator’s demand by triggering subsequent local productions and after they are applied it returns succes. 3. As in the previous case but subsequent productions, triggered by the responder, failed and thus the system returns failure to the initiating system, what means that the transformation in the initiator’s system can not be performed. The first case was illustrated in the discussion of the production above. An example of the second case is illustrated in Fig. 10(left). In this case the wall to which the new window should be attached already contains the window, so the internal transformation system triggers other productions, in this case the one that makes the window smaller so that the new window can fit in. Fig. 10(right) illustrates one of the possible examples for the case 3. Here, the destination wall already contains two windows and the new one can not be fitted, thus the internal (responder’s) system returns failure to the initiating system. Hence the window can not be moved. 7. Conclusions In this paper the formal mechanism of synchronization for heterogeneous transformation systems was presented. This mechanism allows two separate transformation systems to communicate when they have to perform operations dealing with common elements of a building, but otherwise operating independently. The mechanism is based on shared elements: (i) a common reference coordinate system which allows for the proper identification of elements and (ii) matching mechanism for names of attributes and labels which have to be communicated. The matching mechanism is provided by an ontology mechanism, while coordinate systems are defined explicitly for systems. At this stage we consider a synchronization which either is carried out successfully (i.e., both transformation systems return TRUE) or fails altogether. Yet, in the example presented in the paper it would be an interesting option to allow the internal system to use some weighting mechanism to decide whether a window already present in the wall should be removed to make place for the new one. We also plan to extend data exchange mechanism between systems ant thereby to augment the interaction semantics.
References Autodesk. Autodesk homestyler, http://www.homestyler.com/. Borkowski, A., Grabska, E., Nikodem, P., and Strug, B., 2003. Searching for innovative structural layouts by means of graph grammars and esvolutionary optimization. In Proc. 2nd Int. Structural Eng. And Constr. Conf, pages 475–480. buildingSMART. 2005. Ifc specification, iso/pas. Chambelland, Jean-Christophe., and Gesquiere, Gilles., 2012. Complex virtual urban environment modeling from citygml data and ogc web services: application to the simfor project. pages 82901A–82901A–9. CityGML. http://www.citygml.org/. Csuhaj-Varju, E., 2004. Grammar systems: A short survey. In Proceedings of Grammar Systems Week 2004, pages 141–157. Csuhaj-Varjú, E., Dassow, J., Kelemen, J., & Pa˘un, Gh. (1994). Grammar Systems: A Grammatical Approach to Distribution and Cooperation. London: Gordon and Breach. Csuhaj-Varjú, E., Dassow, J., & Pa˘un, Gh. (1993). Dynamically controlled cooperating/distributed grammar systems. infsci, 69, 1–25. Csuhaj-Varju, E., & Vaszil, G. (2001). On context-free parallel communicating grammar systems: Synchronization, communication, and normal forms. TCS: Theoretical Computer Science, 255. Dasso, w J., Pa˘un, Gh., & Rozenberg, G. (1997). Grammar systems. In A. Salomaa & G. Rozenberg (Eds.). Handbook of formal languages (Vol. 2, pp. 155–213). BerlinHeidelberg: Springer. chapter 4. Eastman, C., Teicholz, P., Sacks, R., & Liston, K. (2008). BIM Handbook: A Guide to Building Information Modeling for Owners, Managers, Designers. Wiley. Ehrig, Hartmut, Engels, Gregor, Kreowski, Hans-Jörg, & Rozenberg, Grzegorz (Eds.). . Handbook of Graph Grammars and Computing by Graph Transformation. Applications, Languages and Tools (Vol. 2). Singapore: World Scientific. Grabska, E., Nikodem, P., and Strug, B., 2004. Evolutionary methods and graph grammars in design and optimization of skeletal structures. In 11th International Workshop on Intelligent Computing in Engineering. Habel and Kreowski., 1987. Some structural aspects of hypergraph languages generated by hyperedge replacement. In STACS: Annual Symposium on Theoretical Aspects of Computer Science. Kelemen, J. (1991). Syntactical models of cooperating/distributed problem solving. Journal of Experimental and Theoretical Artificial Intelligence, 3(1), 1–10. Kolbe, T. H. (2009). Representing and Exchanging 3D City Models with CityGML. In Jiyeong Lee & Sisi Zlatanova (Eds.), 3D Geo-Information Sciences. Lecture Notes in Geoinformation and Cartography (pp. 15–31). Berlin Heidelberg: Springer. ISBN 978-3-540-87394-5. Kotulski, Leszek (2008a). Distributed graphs transformed by multiagent system. In Leszek Rutkowski et al. (Eds.), Artificial Intelligence and Soft Computing - ICAISC 2008. LNCS (vol. 5097, pp. 1234–1242). Berlin Heidelberg: Springer. Kotulski, Leszek. (2008b). GRADIS - Multiagent Environment Supporting Distributed Graph Transformations. In Marian Bubak et al. (Eds.), Computational Science - ICCS 2008. LNCS (Vol. 5103, pp. 644–653). Berlin Heidelberg: Springer. Kotulski, L., & Se˛dziwy, A. (2010a). On the effective distribution of knowledge represented by complementary graphs. In Piotr Jedrzejowicz, Ngoc Thanh Nguyen, Robert J. Howlett, & Lakhmi C. Jain (Eds.), KES-AMSTA (1). Lecture Notes in Computer Science (Vol. 6070, pp. 381–390). Springer. ISBN 978-3-642-134791. Kotulski, Leszek, & Se˛dziwy, Adam (2010b). GRADIS - The multiagent environment supported by graph transformations. Simulation Modelling Practice and Theory, 18(10), 1515–1525. ISSN 1569-190X. Simulation-based Design and Evaluation of Multi-Agent Systems. Kotulski, Leszek, & Se˛dziwy, Adam (2011). Parallel graph transformations supported by replicated complementary graphs. In Proceedings of the 10th international conference on Adaptive and natural computing algorithms. ICANNGA’11 (Vol. Part II, pp. 254–264). Berlin, Heidelberg: Springer-Verlag. ISBN 978-3-642-20266-7. Kotulski, Leszek, & Se˛dziwy, Adam (2012). On the effective distribution and maintenance of knowledge represented by complementary graphs. T. Computational Collective Intelligence, 7190, 105–120. Kotulski, Leszek, & Strug, Barbara (2008). Using graph transformations in distributed adaptive design system. In Leonard Bolc, Juliusz L. Kulikowski, & Konrad W. Wojciechowski (Eds.), ICCVG. Lecture Notes in Computer Science (Vol. 5337, pp. 477–486). Springer. ISBN 978-3-642-02344-6. Kotulski, L., & Strug, B. (2011). Multi-agent system for distributed adaptive design. Key Engineering Materials, 486, 217–220.
998
L. Kotulski et al. / Expert Systems with Applications 41 (2014) 990–998
Kotulski, L., & Strug, B. (2013). Supporting communication and cooperation in distributed representation for adaptive design. Advanced Engineering Informatics, 27, 220–229. Kreowski, Hans-Jörg, & Kuske, Sabine (2011). Graph multiset transformation: a new framework for massively parallel computation inspired by DNA computing. Natural Computing, 10(2), 961–986. MartÃn-Vide, C., and Mitrana, V., 1998. Cooperation in contextual grammars. In A. KelemenovÃ!, editor, Proceedings of the MFCS’98 Satellite Workshop on Grammar Systems, pages pp. 289–302. Métral, Claudine, Falquet, Gilles, & Karatzas, Kostas (2012). Ontologies for the integration of air quality models and 3D city models. URL http://arxiv.org/abs/ 1201.6511. Minas, M. (2002). Concepts and realization of a diagram editor generator based on hypergraph transformation. Science of Computer Programming, 44(2), 157–180. ISSN 0167-6423. URL http://www.elsevier.com/gej-ng/10/39/21/86/49/29/ abstract.html. Nikodem, P., & Strug, B. (2004). Graph transformations in evolutionary design. In Leszek Rutkowski, Jörg H. Siekmann, Ryszard Tadeusiewicz, & Lotfi A. Zadeh
(Eds.), ICAISC. Lecture Notes in Computer Science (Vol. 3070, pp. 456–461). Springer. ISBN 3-540-22123-9. Rozenberg, Grzegorz (1997). Handbook of Graph Grammars and Computing by Graph Transformations. Foundations (Vol. 1). World Scientific. ISBN 9810228848. Rozenberg, G., & Ehrig, H., et al. (Eds.). (1999). Handbook on Graph Grammars and Computing by Graph Transformation 3 (Concurrency). Singapore: World Scientific. Simeoni, M., & Staniszkis, M. (1999). Cooperating graph grammar systems. In Gh. Pa˘un & A. Salomaa (Eds.), Grammatical models of multi-agent systems (pp. 193–217). Amsterdam: Gordon and Breach. Se˛dziwy, Adam (2012). Representation of objects in agent-based lighting design problem. In Wojciech Zamojski et al. (Eds.), Complex Systems and Dependability. Advances in Intelligent and Soft Computing (vol. 170, pp. 209–223). Berlin Heidelberg: Springer. Strug, B., & Kotulski, L. (2007). Distributed adaptive design with hierarchical autonomous graph transformation systems. In Yong. Shi, G. Dick, Dongarra van Albada, Sloot Jack, & M. A. Peter (Eds.), ICCS (2). Lecture Notes in Computer Science (Vol. 4488, pp. 880–887). Springer. ISBN 978-3-540-72585-5.