- Email: [email protected]
Generation of UML package diagrams based on an attribute graph grammar
G Model
ARTICLE IN PRESS
JOCS-263; No. of Pages 10
Journal of Computational Science xxx (2014) xxx–xxx
Contents lists available at ScienceDirect
Journal of Computational Science journal homepage: www.elsevier.com/locate/jocs
Generation of UML package diagrams based on an attribute graph grammar Takaaki Goto a,∗ , Tadaaki Kirishima b , Tetsuro Nishino a , Takeo Yaku c , Kensei Tsuchida d a
Graduate School of Informatics and Engineering, The University of Electro-Communications, Japan College of Cornerstone Education, Oberlin University, Japan Department of Information Science, Nihon University, Japan d Faculty of Information Science and Arts, Toyo University, Japan b c
a r t i c l e
i n f o
Article history: Received 30 September 2013 Received in revised form 25 December 2013 Accepted 21 February 2014 Available online xxx Keywords: Graph grammar UML Package diagram SVG
a b s t r a c t Graphical representations are often used in software design and development because of their expressiveness. So far, various graphical program description languages have been reported. The Unified Modeling Language (UML), developed for modeling in software development was proposed recently, and in 2005 was standardized as the ISO/IEC 19501 standard. Some tools for drawing UML diagrams have been proposed in recent years. However, it is hard for developers to draw UML diagrams using the UML tool because diagram layouts generally should be manually adjusted. Of course, there are tools that can automatically provide layout diagrams, though, sometimes such functions provide unexpected layouts. In order to automate the drawing of these graphical representations aesthetically, a syntax for program diagrams must first be defined. We propose a framework for specifying these diagrams using a graph grammar, and a syntax-directed editor based on the graph grammar. © 2014 Elsevier B.V. All rights reserved.
1. Introduction Graphical representations are often used in software design and development because of their expressiveness. Various graphical program description languages have been reported, including the Hierarchical flowchart language (Hichart), Problem Analysis Diagrams (PAD), Hierarchical and Compact description charts (HCP), and Structured Programming Diagrams (SPD), and many Computer Aided Software Engineering (CASE) tools have been developed based on these languages [1–3]. On the other hand, the Unified Modeling Language (UML) for modeling in software development was proposed relatively recently compared with the above graphical program description languages, and in 2005 it was standardized as the ISO/IEC 19501 standard. UML has already been used in the analysis, design and implementation of many systems. It makes use of various types of diagrams, such as class and sequence diagrams, for designing processes in system development, from upstream processes to downstream processes. In order to automate the processing of
∗ Correspondence: Tel.: +81 42 443 5912. E-mail address: [email protected] (T. Goto).
these graphical representations using computers, a syntax for program diagrams must first be defined. Some tools for drawing UML diagrams have been proposed in recent years. However, it is hard for developers to draw UML diagrams using the UML tool because diagram layouts should be manually adjusted. Of course, there are tools that can automatically layout diagrams, though, sometimes such functions provide unexpected layouts. Then, in order to analyze the syntax of two-dimensional objects such as program diagrams, the relationships between each of the elements must also be described. Graph grammars are one possible effective means for implementing these methods. Graph grammars provide a formal method that enables rigorous definition of mechanisms for generating and analyzing graphs. Research on graph grammars has been done by Rozenberg [4] and others. Research has also been done on UML [5] and graph grammars and graph transformations with respect to UML [6–8]. However, these studies do not deal with syntax formalization for visual representation, and graph grammars for package diagram have not yet been proposed. Therefore, we provide a graph grammar for UML package diagram to propose theoretical fundamentals of UML. With regard to Web documents, XML and SVG have been proposed as standard document and graphical formats for the Web.
http://dx.doi.org/10.1016/j.jocs.2014.02.005 1877-7503/© 2014 Elsevier B.V. All rights reserved.
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model
ARTICLE IN PRESS
JOCS-263; No. of Pages 10
T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
2
X
Scalable Vector Graphics (SVG) [9] is a W3C recommendation and a language for describing two-dimensional graphics and graphical applications in XML. SVG can display graphical objects on any readily available Web browser. With these formats, users can share documents including graphical objects on the Web. We reported on the automatic generation of SVG files and incorporated the Hichart by using attribute graph grammars. The goal of this research is to generate UML package diagrams based on a graph grammar. We propose a framework for specifying these diagrams using a graph grammar, and a syntax-directed editor based on the graph grammar. Moreover we propose methods of calculating coordinates and generating SVG files based on attribute evaluation.
b
Y
γ v1
v0
v2
Fig. 1. An example of a production.
X α
a
2. Preliminary
β b
Y
γ v1
v2
v0
Fig. 2. An example of a production with the connection relation.
Here, we review the notations and definitions about graph grammars which we use in this paper. Moreover we explain a package diagram of UML.
H
H'
a
2.1. Graph grammars Graph grammars can generate graphs using production rule. Here we review some definitions for defining graph grammars. In this paper, we consider directed graphs without loops. A node on a graphs has attributes such as coordinates and cell size. Following definitions are based on [4], and [10]. First, we define “graph”. Definition 2.1. [4],[10] Let be an alphabet of node labels and be an alphabet of edge labels. A graph over and is a tuple H = (V, E, ), where V is the finite set of nodes, E ⊆ {(v, , w) | v, w ∈ / w, ∈ } is the set of edges, and : V → is the node labelV, v = def
ing function. E(v, w) = { ∈ | (v, , w) ∈ E}. The label tuple of two def
nodes v, w ∈ V is lab(v, w) = ((v), E(v, w), E(w, v), (w)). Next we define isomorphic so as to compare two graphs when we derive or analyze graphs based on graph grammar. Definition 2.2. [4] Two graphs H and K are isomorphic if there is a bijection f : VH → VK such that EK = {(f (v), , f (w)) | (v, , w) ∈ EH } and for all v ∈ VH , K (f (v)) = H (v). Definition 2.3. [4] The set of all concrete graphs over and is denoted as GR, , and the set of all abstract graphs is denoted as [GR, ]. A subset of [GR, ] is called a graph language. The graph grammar which we use in this paper contains connection information in the grammar. Definition 2.4. [4] A graph with (neighborhood controlled) embedding over and is a pair (H, C) with H ∈ GR, and C⊆ × × × VH × {in, out}. C is the connection relation of (H, C), and each element (, ˇ, , x, d) of C (with ∈ , ˇ, ∈ , x ∈ VH , and d∈ {in, out}) is a connection instruction of (H, C). A connection instruction (, ˇ, , x, d) will always be written as (, ˇ/, x, d). Two graphs with embedding (H, CH ) and (K, CK ) are isomorphic if there is an isomorphism f from H to K such that CK = {(, ˇ/, f(x), d) | (, ˇ/, x, d) ∈ CH }. The set of all graphs with embedding over and is denoted as GRE, . Definition 2.5. ([4]) An edNCE graph grammar is a six-tuple GG = ( , , , , P, S), where is the alphabet of node labels, ⊆ is the alphabet of terminal node labels, is the alphabet of edge labels, ⊆ is the alphabet of final edge labels, P is the finite set of productions, and S ∈ − is the initial nonterminal. A production is of the form X → (D, C) where X is a nonterminal node label, D is a graph over and , and C ⊆ × × × VD × {in, out} is the connection relation that is a set of connection instructions. A pair (D, C) is a graph with embedding over and .
α n1
X n2
n2, p'
a
β n1
b
γ n3
Y n4
Fig. 3. An example of applying a production rule.
NCE stands for Neighborhood Controlled Embedding. d of edNCE indicates that graph grammars generate directed graphs. And e of edNCE means that the generated graphs by the grammar have edge labels. An example of a production is shown in Fig. 1. In Fig. 1, a box is a nonterminal node and a filled circle is a terminal node. X, Y, and b are node labels and v0 , v1 , and v2 are node IDs. Nodes with same node labels can appear in a graph, while nodes with same node IDs will never appeared in a graph. The production of Fig. 1 indicates that, after the removal of a nonterminal node with the label X (mother node), embedding the graph consists of a terminal node with the label b and the nonterminal node with the label Y (daughter graph). Each production has connection instructions. The connection instruction of this production is (a, ˛/ˇ, v1 , in), however, this connection instruction is not described in the notation of Fig. 1. In Fig. 2, the production of Fig. 1 and its connection instruction are drawn simultaneously. The large box in Fig. 2 indicates the lefthand side, and the two nodes with the labels b and Y are on righthand side of the production of Fig. 1. An example of the application of the production is shown in Fig. 3. In Fig. 3, H = (VH , EH , H ) is a graph with VH = {n1 , n2 }, EH = {(n1 , ˛, n2 )}, H (n1 ) = a, and H (n2 ) = X. The production copy p of p is as follows: p : X → (D , C ) where X = H (n2 ), D = (VD , ED , D ) such that VD = {n3 , n4 }, ED = {(n3 , , n4 )}, D (n3 ) = b, D (n4 ) = Y and C = {(a, ˛/ˇ, n3 , in)}. In Fig. 3, H indicates the host graph and H is the resulting graph. At first, we remove the node X and the edges that connect with node X from host graph H. Next, we embed the daughter graph, including nodes b and Y. Then we establish edges between the nodes of the daughter graph and the nodes that were connected to the node X using the connection instructions on the production p . Therefore the edge label ˛ is rewritten as ˇ by the production p . Definition 2.6. ([11,12]) An attribute edNCE graph grammar is a six-tuple AGG = GG, Att, F, where 1.GG = ( , , , , P, S) is called an underlying graph grammar of AGG. Each production p in P is denoted by X → (D, C). 2. Each node symbol Y ∈ of GG has two disjoint finite sets Inh(Y) and Syn(Y) of inherited and synthesized attributes, respectively. The all attributes of symbol X is defined as Att(X) = Inh(X) ∪ Syn(X). set of Att = X∈ Att(X) is called the set of attributes of AGG. We assume
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model
ARTICLE IN PRESS
JOCS-263; No. of Pages 10
T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
3
Fig. 4. An example of a package diagram with members [13].
that Inh(S) =∅. An attribute a of X is denoted by a(X), and the set of possible values of a is denoted by V(a). 3. Associated with each production p = X0 → (D, C) ∈ P is a set Fp of semantic rules which define all the attributes in Syn(X0 ) X∈Lab(D) Inh(X). A semantic rule defining an attribute a0 (Xi0 ) has the form a0 (Xi0 ):= f( a1 (Xi1 ), · · · , am (Xim )). Here f is mapping from V (a1 (Xi1 )) × · · · × V (am (Xim )) into V (a0 (Xi0 )). In this situation, we say that a0 (Xi0 ) depends on aj (Xij ) for j, 0 ≤ j ≤ m in p. The set F =
p∈P Fp
Package1
is called the set of semantic rules of G.
Package2
Package3
Attribute values are calculated by evaluating attributes according to semantic rules on the derivation tree. 2.2. UML
Class1
UML is a notation for modeling object-oriented system development using diagrams. UML can be divided into structural diagrams and behavioral diagrams. Structural diagrams are used to describe the structure of what is being modeled and includes class, object, and package diagrams. Behavioral diagrams are used to describe the behavior of what is being modeled and include use-case, activity, and state-machine diagrams. Structure diagrams include class diagrams, which describe the static relationships between classes, and package diagrams, which group classes and describe relationships between packages and package nesting relationships. In this paper, we target package diagrams. A package indicates a namespace for its member. Package diagrams can describe dependencies among other packages. Moreover, package diagrams can illustrate membership using membership notation [13]. Fig. 4 illustrates an example of a package diagram with members described in [13]. The middle representation shows a package with some of the members within the borders. The right representation shows
Class2
Class3
Fig. 5. An example of a package diagram.
a package diagram using alternative membership notation. In this paper, we target membership notation for our graph grammar and syntax-directed editor. Fig. 5 shows an example of a package diagram using alternative membership notation. Boxes with rectangles at the upper left corners indicate the presence of a package. Boxes with three compartments represent classes, with each compartment representing its class name, its attributes, and its methods from top to bottom. A plus sign in a circle is used to represent the components the package contains. Package 1 contains Package 2 and Package 3, and Package 3 contains Class 2 and Class 3.
L lep
T
L
1
L
R
lep
T 1
2
1
2 0
0
0
Fig. 6. An example of a GGPD production rule.
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model JOCS-263; No. of Pages 10
ARTICLE IN PRESS T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
4
3. Graph grammar for UML package diagrams
G0:
S
In this section we describe our Graph Grammar for Package Diagrams (GGPD), for UML package diagram membership notation. UML package diagrams using membership notation can be described as tree-structured. We refer to our previous research of graph grammar for tree structures [14]. 3.1. Grammar overview
1 S
A
P1
1, P1'
G1: A
Definition 3.7. The Graph Grammar for Package Diagrams (GGPD), for UML package diagrams, is a six-tuple GGPD = (PD , PD , PD , PD , PPD , SPD ). Here, PD = { S, A, T, L, R, M, rop, sp, lep, rip, mip, lec, mic, ric } is a finite set of node labels, PD = { rop, sp, lep, rip, mip, lec, mic, ric } is a finite set of terminal node labels, PD = { ∗ }, PD = { ∗ }, PPD = { P1 , . . . , P17 } is a finite set of production rules, and SPD = { S }, is the initial non-terminal. In Definition 3.7, rop, sp, lep, rip, mip, lec, mic, ric, stands for “root of package”, “single package”, “left package”, “right package”, “middle package”, “left class”, “middle class”, “right class”, respectively. The GGPD generates package hierarchy diagrams. It is a contextfree grammar, and there are 17 production rules. There are three types of production in PPD , as shown in Fig. 6. In Fig. 6, nodes with capitalized labels indicate a nonterminal nodes, and nodes with uncapitalized labels indicate terminal nodes. Type 1 and Type 2 productions generate tree structures in a longitudinal direction and in a transverse direction, respectively. Type 3 productions substitute a nonterminal node for a terminal node. In Fig. 6(a), the production rule can be applied to a node labeled L, which is a non-terminal node, to generate a terminal node with the label lep, representing a package, and a non-terminal node labeled T. Our grammar generates directed graphs. However, the obtained graphs are drawn without arrows by assuming that the direction of each edge is from the top down. 3.2. Example of derivation Fig. 7 shows an example of a GGPD derivation. In this example, G0 is a graph with a node labeled S. The node ID is 1 (lower right of the node). Then the production rule P1 is applied to a non-terminal node labeled S with the node ID 1, which is the initial nonterminal node. That is, a mother node with label S and node ID 1 is removed, then embed a daughter graph in the P1 . In this case, the daughter graph is the node with the label A. This produces the nonterminal node labeled A with a node ID 2, to which the P3 production rule is applied. That is, a graph G1 consisting of a node with the node ID 2, is obtained. After application of the production P3 , the terminal node labeled rop and a non-terminal node labeled T are generated. We apply productions to obtain a graph that corresponds to UML package diagrams. We can obtain a derivation tree from the derivation sequence of production. Fig. 8 shows the derivation tree corresponding to Fig. 7. In Fig. 8, the labels show the names of the production rules. Another example of a package diagram resulting from applying the production rules is shown in Fig. 9.
2
A rop
P3
2, P3'
+ T
G2: rop
+
3
T 4
T L
P6
4, P6'
R
G3: rop
+ L
3 R 6
5
L
5, P8'
P8
lep
G4: rop
+
3 R
lep
6
7
R
6, P12'
P12
rip
G5: rop
+
3
rip
lep 7
8 Fig. 7. An example of a GGPD derivation.
4. Attribute evaluation In this section, we explain how to evaluate attributes. Attributes are used to hold values such as calculating coordinates and Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model
ARTICLE IN PRESS
JOCS-263; No. of Pages 10
T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
P1
generating SVG files. These attributes are evaluated on a derivation tree such as shown in Fig. 8, where the vertices are labeled by a production rules number. Each production rule has semantic rules for calculating the attribute’s values. Semantic rules can be defined formally and declaratively. Here we describe the details of attributes and semantic rules for X − Y coordinates and generating SVG.
P3 P6 P8
P12 4.1. Calculation of coordinates for diagrams
Fig. 8. A derivation tree corresponding to the tree in Fig. 7.
In order to lay out elements of package diagram such as package and class, we calculate attribute values using attribute evaluates. There are four attributes for layout diagrams such as tw (tree width), x, y, and nw (node width). Attribute tw is a synthesized attribute, and attributes x and y are inherited attributes. Attribute nw stores node widths that are used in calculating attribute tw. An attribute evaluate for attributes tw, x, and y are done as follows:
rop +
lep
rip +
1 Attribute evaluation for synthesized attribute tw is done on a derivation tree based on a bottom-up manner. 2 Attribute evaluation for inherited attribute x is done on derivation tree based on top-down manner. 3 Attribute evaluation for inherited attribute y is done on derivation tree based on top-down manner.
+
sc
5
lec
ric
First, we explain the attribute tw that calculates package diagram width. Semantic rules for the attribute tw are defined for such three types of productions.
Fig. 9. An example of package diagram resulting from derivation.
S
A
P1
tw(1)=tw(2)=15 2 1
A rop
P3
+
tw(2)=tw(4)=15 tw(3)=tw(4)=15
3
T 4 2
T
P6
L
R 5
tw(4)=tw(5)+GapX+tw(6) =15
6 4
R
L
P8
tw(6)=tw(8)=nw(8)=5
tw(5)=tw(7)=nw(5)=5
lep
P12 7
rip 8
5
6
Fig. 10. A derivation tree with semantic rules for tree width corresponding to the tree in Fig. 7.
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model
ARTICLE IN PRESS
JOCS-263; No. of Pages 10
T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
6
Two semantic rules tw(1) = tw(2) and tw(0) = tw(2) are defined for production rule Type I in Fig. 6. By synthesized attribute evaluation, when this attribute tw is used for this type I of production rules, tw(2) holds a max width of sub trees which is derived from the node. In order to synthesize tw(2)’s value to a superior attribute such as tw(1), tw(0), tw(2)’s value is set to tw(1) and tw(0). In this Type II of production in Fig. 6, attribute tw of a node on the left-hand side of the production rule holds summation of sub tree’s max width derived from node L and R and gap size between node L and R. Therefore the semantic rule of Type II production is defined as tw(0) = tw(1) + Gapx + tw(2). In this Type III of productions in Fig. 6, attribute tw of a node in left-hand side of the production rule holds the width of the terminal node in the right-hand side of the production. Therefore, the semantic rule of Type II production is defined as tw(0) = tw(1) = nw(1). Here, nw(1) indicates the width of the terminal node lep. Here, we show the process for the attribute evaluation process for attribute tw in Fig. 10. Because attribute tw is a synthesized attribute, attribute evaluation has been done in a bottom-up manner on the derivation tree. In the example in Fig. 10, each node on the derivation tree has traversed as follows P8 → P12 → P6 → P3 → P1 . In the P8 , a node size of terminate node labeled lep (in this case 5) is stored to tw(5) which is the node on the left-hand side of production rule, and tw(7), which is a node on the right-hand side of the production rule. P12 is processed in the same manner.
S
In the process of P6 , summation of tw(5), tw(6) and the gap between nodes 5 and 6 is substituted into tw(4). Moreover, in the process of P3 , tw(2) and tw(3) store the value of tw(4). P1 sets tw(2) to tw(1), then finally tw(1) has 15. This means that this case diagram width equals 15, and attribute tw of each node indicates the maximum widths of nodes located in the inferior portion of the node. Next, we review attribute x that calculates the horizontal location of each node. Because attribute x is an inherited attribute, attribute evaluation has been done in a top-down manner on the derivation tree. On calculating of attribute x, values are obtained using the criterial x-coordinate and tree width (attribute tw). Fig. 11 shows the calculation process of attribute x. In this case, attribute evaluation has been done in the following order: P1 → P3 → P6 → P8 → P12 In P1 , x(1) and x(2) are set to 0. In P3 , in order to calculate x coordinate of terminal node rop, criterial x-coordinate x(2), draw area size tw(3), and node width nw(3) are used to calculate. In this case, the terminal node rop locates on the center of diagram width. So as to obtain x(6), the x coordinate of node L (node 5) and tree width attribute of node L, and gap between node L and R are used to calculate. In the attribute evaluation for attribute y, attribute evaluation is done in a top-down manner. The calculation process of attribute y is described in Fig. 12. For P3 , y coordinate is added using gap Y when a production rule which generates a graph in vertical direction is applied.
A
P1
x(1)=x(2)=0 2 1
A rop
P3
+
x(3)=x(2)+tw(3)/2-nw(3)/2=0+7.5-2.5=5 x(4)=0
3
T 4 2
T
P6
L
R 5
x(5)=x(4)=0 x(6)=x(5)+tw(5)+GapX=0+5+5=10
6 4
R
L
P8
x(8)=x(6)=10
x(7)=x(5)=0
lep
P12
rip 8
7 5
6
Fig. 11. A derivation tree with semantic rules for x coordinate corresponding to the tree in Fig. 7.
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model
ARTICLE IN PRESS
JOCS-263; No. of Pages 10
T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
S
A
P1
7
y(1)=0 y(2)=y(1)=0
2 1
A rop
P3
+
y(3)=y(2)=0 y(4)=y(3)+GapY=0+5-5
3
T 4 2
T
P6
L
R 5
y(5)=y(4)=5 y(6)=y(4)=5
6 4
R
L
P8
y(8)=y(6)=5
y(7)=y(5)=0
lep
P12 7
rip 8
5
6
Fig. 12. A derivation tree with semantic rules for y coordinate corresponding to the tree in Fig. 7.
derivation tree
attribute evaluation
derivation tree with SVG
semantic rules for SVG
output: SVG file
Fig. 13. Flow of generating SVG files.
4.2. Generation of SVG documents for package diagrams We introduce the attribute SSVG which contains SVG source codes, as its value and representation correspond to the package diagram using alternative membership notation. SVG can display in browsers such as IE with an SVG plugin; therefore, we can embed generated SVG files into software documents such as HTML or XML. Fig. 13 illustrates the flow of generating SVG files. We can obtain a derivation tree after obtaining package diagrams using production rules. SVG source codes are generated by evaluating SSVG . The attribute evaluation is then performed in a bottom-up manner on derivation trees referring to semantic rules associated with
production rules. Through this process we can obtain a derivation tree with SVG information and SVG files. Fig. 14 gives an example of semantic rules for the SSVG attribute of a production. The left-hand side of the figure illustrates a production rule, and the right-hand side shows the semantic rules for the production rule. In the semantic rules part of Fig. 14, SSVG (1) is the semantic rule for the attribute of node 1 in the production part. SSVG (1) stores drawing information for node 1; that is, SSVG (1) includes a rect tag to draw rectangle. x(1), y(1), w(1), and h(1) have the value of node 1’s layout information. SSVG (2) stores all derivable drawing information from nonterminal node 2 with the label T. When attribute evaluation has been done on this production, SSVG (2)’s value is already decided because the evaluation of attributes is performed in a bottom-up manner on derivation trees. SSVG (0) stores a concatenation of SSVG (1) and SSVG (2); therefore, SSVG (0) has all drawing information derivable from the nonterminal node 0 with the label A. Fig. 15 gives a concrete example of the attribute evaluation of SSVG on the derivation tree corresponding to Fig. 8. The attribute evaluation is performed in a bottom-up manner on derivation trees. In this case, the attributes are evaluated in the following order: Production 8 → Production 12 → Production 6 → Production 3 → Production 1. On the process of Production 8, information of drawn node 7 with the label lep is stored with the attributes of SSVG (7). Then
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model
ARTICLE IN PRESS
JOCS-263; No. of Pages 10
T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
8
A rop
P3
+
1
T
• 2 0
Production rule
Semantic rules
Fig. 14. An example of semantic rules for the SSVG attribute of a production.
S
A
P1
SSVG(1)=SSVG(2) 2 1
A rop
P3
+
SSVG(3)=
3
T 4 2
T
P6
L
R 5
SSVG(4)=SSVG(5)•SSVG(6) 6 4
R
L
P8
lep 7 5
SSVG(7)=
P12
rip 8 6
SSVG(8)=
Fig. 15. A derivation tree with semantic rules for SVG corresponding to the tree in Fig. 7.
SSVG (7) is assigned to SSVG (5), which is an SSVG attribute of the nonterminal node 5 with the label L . The attribute evaluation of Production 12 has been done using the same process as Production 8. SSVG (8) stores information from node 8 with the label rip, and SSVG (8) is assigned to SSVG (6). In the next step, the attribute evaluation of Production 6 has been done. Here SSVG (4) stores the concatenation of SSVG (5) and SSVG (6), and then SSVG (4) has the drawing information from node 7 and node 8. In the next step, the attribute evaluation of Production 3 has been done. SSVG (3) stores drawing information from node 3 with the label rop, and the concatenation of SSVG (3) and SSVG (4) is assigned to SSVG (2). Then SSVG (2) has drawing information from node 3, node 7, and node 8.
Finally, Production 1 is evaluated. In this case, SSVG (2) is assigned to SSVG (1). Thus, SSVG (1) has all drawing information from the package diagram including nodes 3, 7, and 8. After post-processing, we can obtain the SVG file corresponding to G5 in Fig. 7. 5. UML package diagram editor In this section, we explain our prototype UML package diagram editor based on the grammar described in Section 3. The editor is a syntax-directed editor and was developed in Java. Fig. 16 shows a screenshot of the editor. In the editor, when a nonterminal node displayed on the editor screen is selected, a screen displaying the production rules that can
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model JOCS-263; No. of Pages 10
ARTICLE IN PRESS T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
Fig. 16. A screenshot of the package diagram editor.
9
Fig. 19. An example of applying production rules to the editor.
Fig. 17. A nonterminal node on the editor.
Fig. 20. The derivation tree display screen of the package diagram editor.
be applied to the nonterminal node is displayed. Figs. 17–19 show screen shots of when the non-terminal node with the node ID of 2 and the label A in the package diagram editor screen is clicked (Fig. 17), and the applicable production rules are displayed (Fig. 18). After choosing a production rule, the production rule is applied to the non-terminal node (Fig. 19). The applied production rules can also be displayed as a derivation tree, as shown in Fig. 20. When users execute an editor command, SVG files can be automatically generated by evaluating SVG attributes. The evaluation is executed by traversing on the derivation tree. Fig. 21 is an example of the display of a package diagram in SVG. 6. Discussion
Fig. 18. The production rule display screen of the package diagram editor.
The proposed method is about supporting UML modeling. We define a formal method for generating a package diagram of UML using a graph grammar. The proposed method can be applied to
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model JOCS-263; No. of Pages 10
ARTICLE IN PRESS T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
10
[11] T. Nishino, Advances in Software Science and Technology 1 (2012) 89–104. [12] T. Arita, K. Sugita, K. Tsuchida, T. Yaku, Proceeding of IASTED Applied Informatics (2001) 637–642. [13] O. M. Group, Omg unified modeling language (omg uml), infrastructure, v 2.1.2, http://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF/, 2007. [14] T. Kirishima, T. Goto, T. Yaku, K. Tsuchida, 2010 IEEE/ACIS 9th International Conference on Computer and Information Science (ICIS) (2010) 341–346. Takaaki Goto graduated with a Doctor of Engineering degree from Toyo University in 2009. He is a Project Assistant Professor at the Graduate School of Informatics and Engineering at The University of Electro-Communications. His main research interests are applications of open source software development, software development education, graph grammars, visual languages, and software development environments. He is a member of IEICE Japan, IPSJ, and IEEE.
Fig. 21. An example of the display of a package diagram in SVG.
design distributed and Web-based systems. Such systems need large and complicated diagrams, which are difficult to model by hand. Thus there is a need for formal methods to manipulate diagrams, such as our method. At present we target package diagrams only; however, our method can be employed to generate/analyze class diagrams. In addition, a parser for the diagrams, based on our graph grammar which is under construction, can analyze diagrams and provide useful information such as dependencies. Such information can be used to modify the systems to enhance their performance. 7. Conclusion In this paper, we have defined a graph grammar for generating the membership notation of UML package diagrams. We have also developed a syntax-directed diagram editor for the defined grammar. A future study issue is implementing syntactic analysis. The editor developed here is able to generate diagrams according to the grammar and of checking with the syntax through human intervention, but it is not able to determine, from an arbitrary input, whether a diagram conforms or not. By implementing syntactic analysis, generating UML package diagrams using membership notation can be realized from source code based on formal mechanisms. The application of this technology to the automatic generation of software documentation is another possibility.
Tadaaki Kirishima received M.E. and D.E. degrees from Toyo University in 2002, and 2011, respectively. He is currently a part-time Lecturer at J. F. Oberlin University and Toyo University. His main research interests are applications of graph grammars, and graph drawing.
Tetsuro Nishino graduated from department of Mathematics, Waseda University, and continued his research and obtained a D.Sc. in Mathematics in 1991. He was a researcher at Tokyo Research Laboratory, IBM Japan during 1984–1987. He was an Associate Professor at School of Information Science, Japan Advanced Institute of Science and Technology, Hokuriku during 1992–1994. In 1994, he joined at Department of Communications and Systems Engineering, The University of Electro-Communications as an Associate Professor and in 2006 he became a Professor. He received The Funai Information Technology Prize (2003) and IBM Faculty Award (2008). Takeo Yaku received his M.Sc. and D.Sc. degrees from Waseda University in 1972 and 1977, respectively. He has been a Professor at the Department of Computer Science and System Analysis of Nihon University since 1992. His research interests include software visualization, human interface, graph languages, and graph algorithms. He is a member of IEICE Japan, IEEE Computer Society, and ACM.
References [1] K. Harada, Structure Editor, Kyoritsu Shuppan (1987) (in Japanese). [2] Y. Adachi, Y. Miyadera, K. Sugita, K. Tsuchida, T. Yaku, Proceedings of The 20th International Conference on Software Engineering (ICSE’98) vol. 2 (1998) 74–79. [3] T. Goto, K. Ruise, T. Yaku, K. Tsuchida, IEICE Transactions on Information and Systems 92 (2009) 401–412. [4] G. Rozenberg, Handbook of Graph Grammar and Computing by Graph Transformation. Vol. 1, World Scientific Publishing, 1997. [5] L. Kotulski, D. Dymek, Computational Science ICCS 2008 5101 (2008) 86–395. [6] F. Hermann, H. Ehrig, G. Taentzer, Electron. Notes Theor. Comput. Sci. 211 (2008) 261–269. [7] J. Kong, K. Zhang, J. Dong, D. Xu, J. Syst. Softw. 82 (2009) 292–306. [8] D. Petriu, H. Shen, Computer Performance Evaluation: Modelling Techniques and Tools 2324 (1994) 183–204. [9] W3C, Scalable Vector Graphics (SVG), http://www.w3.org/TR/SVG/ [10] M. Kaul, Graph Grammars and Their Application to Computer Science 291 (2012) 326–342.
Kensei Tsuchida received M.S. and D.S. degrees in mathematics from Waseda University in 1984 and 1994, respectively. He was a member of the Software Engineering Development Laboratory, NEC Corporation in 1984–1990. From 1990 to 1992, he was a Research Associate of the Department of Industrial Engineering and Management at Kanagawa University. In 1992 he joined Toyo University, where he was an Instructor until 1995 and an associate professor from 1995 to 2002, and a Professor from 2002 to 2009 at the Department of Information and Computer Sciences, and since 2009 he has been a Professor of Faculty of Information Sciences and Arts. He was a Visiting Associate Professor of the Department of Computer Science at Oregon State University from 1997 to 1998. His research interests include software visualization, human interface, graph languages, and graph algorithms. He is a member of IPSJ, IEICE Japan and IEEE Computer Society.
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
ARTICLE IN PRESS
JOCS-263; No. of Pages 10
Journal of Computational Science xxx (2014) xxx–xxx
Contents lists available at ScienceDirect
Journal of Computational Science journal homepage: www.elsevier.com/locate/jocs
Generation of UML package diagrams based on an attribute graph grammar Takaaki Goto a,∗ , Tadaaki Kirishima b , Tetsuro Nishino a , Takeo Yaku c , Kensei Tsuchida d a
Graduate School of Informatics and Engineering, The University of Electro-Communications, Japan College of Cornerstone Education, Oberlin University, Japan Department of Information Science, Nihon University, Japan d Faculty of Information Science and Arts, Toyo University, Japan b c
a r t i c l e
i n f o
Article history: Received 30 September 2013 Received in revised form 25 December 2013 Accepted 21 February 2014 Available online xxx Keywords: Graph grammar UML Package diagram SVG
a b s t r a c t Graphical representations are often used in software design and development because of their expressiveness. So far, various graphical program description languages have been reported. The Unified Modeling Language (UML), developed for modeling in software development was proposed recently, and in 2005 was standardized as the ISO/IEC 19501 standard. Some tools for drawing UML diagrams have been proposed in recent years. However, it is hard for developers to draw UML diagrams using the UML tool because diagram layouts generally should be manually adjusted. Of course, there are tools that can automatically provide layout diagrams, though, sometimes such functions provide unexpected layouts. In order to automate the drawing of these graphical representations aesthetically, a syntax for program diagrams must first be defined. We propose a framework for specifying these diagrams using a graph grammar, and a syntax-directed editor based on the graph grammar. © 2014 Elsevier B.V. All rights reserved.
1. Introduction Graphical representations are often used in software design and development because of their expressiveness. Various graphical program description languages have been reported, including the Hierarchical flowchart language (Hichart), Problem Analysis Diagrams (PAD), Hierarchical and Compact description charts (HCP), and Structured Programming Diagrams (SPD), and many Computer Aided Software Engineering (CASE) tools have been developed based on these languages [1–3]. On the other hand, the Unified Modeling Language (UML) for modeling in software development was proposed relatively recently compared with the above graphical program description languages, and in 2005 it was standardized as the ISO/IEC 19501 standard. UML has already been used in the analysis, design and implementation of many systems. It makes use of various types of diagrams, such as class and sequence diagrams, for designing processes in system development, from upstream processes to downstream processes. In order to automate the processing of
∗ Correspondence: Tel.: +81 42 443 5912. E-mail address: [email protected] (T. Goto).
these graphical representations using computers, a syntax for program diagrams must first be defined. Some tools for drawing UML diagrams have been proposed in recent years. However, it is hard for developers to draw UML diagrams using the UML tool because diagram layouts should be manually adjusted. Of course, there are tools that can automatically layout diagrams, though, sometimes such functions provide unexpected layouts. Then, in order to analyze the syntax of two-dimensional objects such as program diagrams, the relationships between each of the elements must also be described. Graph grammars are one possible effective means for implementing these methods. Graph grammars provide a formal method that enables rigorous definition of mechanisms for generating and analyzing graphs. Research on graph grammars has been done by Rozenberg [4] and others. Research has also been done on UML [5] and graph grammars and graph transformations with respect to UML [6–8]. However, these studies do not deal with syntax formalization for visual representation, and graph grammars for package diagram have not yet been proposed. Therefore, we provide a graph grammar for UML package diagram to propose theoretical fundamentals of UML. With regard to Web documents, XML and SVG have been proposed as standard document and graphical formats for the Web.
http://dx.doi.org/10.1016/j.jocs.2014.02.005 1877-7503/© 2014 Elsevier B.V. All rights reserved.
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model
ARTICLE IN PRESS
JOCS-263; No. of Pages 10
T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
2
X
Scalable Vector Graphics (SVG) [9] is a W3C recommendation and a language for describing two-dimensional graphics and graphical applications in XML. SVG can display graphical objects on any readily available Web browser. With these formats, users can share documents including graphical objects on the Web. We reported on the automatic generation of SVG files and incorporated the Hichart by using attribute graph grammars. The goal of this research is to generate UML package diagrams based on a graph grammar. We propose a framework for specifying these diagrams using a graph grammar, and a syntax-directed editor based on the graph grammar. Moreover we propose methods of calculating coordinates and generating SVG files based on attribute evaluation.
b
Y
γ v1
v0
v2
Fig. 1. An example of a production.
X α
a
2. Preliminary
β b
Y
γ v1
v2
v0
Fig. 2. An example of a production with the connection relation.
Here, we review the notations and definitions about graph grammars which we use in this paper. Moreover we explain a package diagram of UML.
H
H'
a
2.1. Graph grammars Graph grammars can generate graphs using production rule. Here we review some definitions for defining graph grammars. In this paper, we consider directed graphs without loops. A node on a graphs has attributes such as coordinates and cell size. Following definitions are based on [4], and [10]. First, we define “graph”. Definition 2.1. [4],[10] Let be an alphabet of node labels and be an alphabet of edge labels. A graph over and is a tuple H = (V, E, ), where V is the finite set of nodes, E ⊆ {(v, , w) | v, w ∈ / w, ∈ } is the set of edges, and : V → is the node labelV, v = def
ing function. E(v, w) = { ∈ | (v, , w) ∈ E}. The label tuple of two def
nodes v, w ∈ V is lab(v, w) = ((v), E(v, w), E(w, v), (w)). Next we define isomorphic so as to compare two graphs when we derive or analyze graphs based on graph grammar. Definition 2.2. [4] Two graphs H and K are isomorphic if there is a bijection f : VH → VK such that EK = {(f (v), , f (w)) | (v, , w) ∈ EH } and for all v ∈ VH , K (f (v)) = H (v). Definition 2.3. [4] The set of all concrete graphs over and is denoted as GR, , and the set of all abstract graphs is denoted as [GR, ]. A subset of [GR, ] is called a graph language. The graph grammar which we use in this paper contains connection information in the grammar. Definition 2.4. [4] A graph with (neighborhood controlled) embedding over and is a pair (H, C) with H ∈ GR, and C⊆ × × × VH × {in, out}. C is the connection relation of (H, C), and each element (, ˇ, , x, d) of C (with ∈ , ˇ, ∈ , x ∈ VH , and d∈ {in, out}) is a connection instruction of (H, C). A connection instruction (, ˇ, , x, d) will always be written as (, ˇ/, x, d). Two graphs with embedding (H, CH ) and (K, CK ) are isomorphic if there is an isomorphism f from H to K such that CK = {(, ˇ/, f(x), d) | (, ˇ/, x, d) ∈ CH }. The set of all graphs with embedding over and is denoted as GRE, . Definition 2.5. ([4]) An edNCE graph grammar is a six-tuple GG = ( , , , , P, S), where is the alphabet of node labels, ⊆ is the alphabet of terminal node labels, is the alphabet of edge labels, ⊆ is the alphabet of final edge labels, P is the finite set of productions, and S ∈ − is the initial nonterminal. A production is of the form X → (D, C) where X is a nonterminal node label, D is a graph over and , and C ⊆ × × × VD × {in, out} is the connection relation that is a set of connection instructions. A pair (D, C) is a graph with embedding over and .
α n1
X n2
n2, p'
a
β n1
b
γ n3
Y n4
Fig. 3. An example of applying a production rule.
NCE stands for Neighborhood Controlled Embedding. d of edNCE indicates that graph grammars generate directed graphs. And e of edNCE means that the generated graphs by the grammar have edge labels. An example of a production is shown in Fig. 1. In Fig. 1, a box is a nonterminal node and a filled circle is a terminal node. X, Y, and b are node labels and v0 , v1 , and v2 are node IDs. Nodes with same node labels can appear in a graph, while nodes with same node IDs will never appeared in a graph. The production of Fig. 1 indicates that, after the removal of a nonterminal node with the label X (mother node), embedding the graph consists of a terminal node with the label b and the nonterminal node with the label Y (daughter graph). Each production has connection instructions. The connection instruction of this production is (a, ˛/ˇ, v1 , in), however, this connection instruction is not described in the notation of Fig. 1. In Fig. 2, the production of Fig. 1 and its connection instruction are drawn simultaneously. The large box in Fig. 2 indicates the lefthand side, and the two nodes with the labels b and Y are on righthand side of the production of Fig. 1. An example of the application of the production is shown in Fig. 3. In Fig. 3, H = (VH , EH , H ) is a graph with VH = {n1 , n2 }, EH = {(n1 , ˛, n2 )}, H (n1 ) = a, and H (n2 ) = X. The production copy p of p is as follows: p : X → (D , C ) where X = H (n2 ), D = (VD , ED , D ) such that VD = {n3 , n4 }, ED = {(n3 , , n4 )}, D (n3 ) = b, D (n4 ) = Y and C = {(a, ˛/ˇ, n3 , in)}. In Fig. 3, H indicates the host graph and H is the resulting graph. At first, we remove the node X and the edges that connect with node X from host graph H. Next, we embed the daughter graph, including nodes b and Y. Then we establish edges between the nodes of the daughter graph and the nodes that were connected to the node X using the connection instructions on the production p . Therefore the edge label ˛ is rewritten as ˇ by the production p . Definition 2.6. ([11,12]) An attribute edNCE graph grammar is a six-tuple AGG = GG, Att, F, where 1.GG = ( , , , , P, S) is called an underlying graph grammar of AGG. Each production p in P is denoted by X → (D, C). 2. Each node symbol Y ∈ of GG has two disjoint finite sets Inh(Y) and Syn(Y) of inherited and synthesized attributes, respectively. The all attributes of symbol X is defined as Att(X) = Inh(X) ∪ Syn(X). set of Att = X∈ Att(X) is called the set of attributes of AGG. We assume
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model
ARTICLE IN PRESS
JOCS-263; No. of Pages 10
T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
3
Fig. 4. An example of a package diagram with members [13].
that Inh(S) =∅. An attribute a of X is denoted by a(X), and the set of possible values of a is denoted by V(a). 3. Associated with each production p = X0 → (D, C) ∈ P is a set Fp of semantic rules which define all the attributes in Syn(X0 ) X∈Lab(D) Inh(X). A semantic rule defining an attribute a0 (Xi0 ) has the form a0 (Xi0 ):= f( a1 (Xi1 ), · · · , am (Xim )). Here f is mapping from V (a1 (Xi1 )) × · · · × V (am (Xim )) into V (a0 (Xi0 )). In this situation, we say that a0 (Xi0 ) depends on aj (Xij ) for j, 0 ≤ j ≤ m in p. The set F =
p∈P Fp
Package1
is called the set of semantic rules of G.
Package2
Package3
Attribute values are calculated by evaluating attributes according to semantic rules on the derivation tree. 2.2. UML
Class1
UML is a notation for modeling object-oriented system development using diagrams. UML can be divided into structural diagrams and behavioral diagrams. Structural diagrams are used to describe the structure of what is being modeled and includes class, object, and package diagrams. Behavioral diagrams are used to describe the behavior of what is being modeled and include use-case, activity, and state-machine diagrams. Structure diagrams include class diagrams, which describe the static relationships between classes, and package diagrams, which group classes and describe relationships between packages and package nesting relationships. In this paper, we target package diagrams. A package indicates a namespace for its member. Package diagrams can describe dependencies among other packages. Moreover, package diagrams can illustrate membership using membership notation [13]. Fig. 4 illustrates an example of a package diagram with members described in [13]. The middle representation shows a package with some of the members within the borders. The right representation shows
Class2
Class3
Fig. 5. An example of a package diagram.
a package diagram using alternative membership notation. In this paper, we target membership notation for our graph grammar and syntax-directed editor. Fig. 5 shows an example of a package diagram using alternative membership notation. Boxes with rectangles at the upper left corners indicate the presence of a package. Boxes with three compartments represent classes, with each compartment representing its class name, its attributes, and its methods from top to bottom. A plus sign in a circle is used to represent the components the package contains. Package 1 contains Package 2 and Package 3, and Package 3 contains Class 2 and Class 3.
L lep
T
L
1
L
R
lep
T 1
2
1
2 0
0
0
Fig. 6. An example of a GGPD production rule.
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model JOCS-263; No. of Pages 10
ARTICLE IN PRESS T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
4
3. Graph grammar for UML package diagrams
G0:
S
In this section we describe our Graph Grammar for Package Diagrams (GGPD), for UML package diagram membership notation. UML package diagrams using membership notation can be described as tree-structured. We refer to our previous research of graph grammar for tree structures [14]. 3.1. Grammar overview
1 S
A
P1
1, P1'
G1: A
Definition 3.7. The Graph Grammar for Package Diagrams (GGPD), for UML package diagrams, is a six-tuple GGPD = (PD , PD , PD , PD , PPD , SPD ). Here, PD = { S, A, T, L, R, M, rop, sp, lep, rip, mip, lec, mic, ric } is a finite set of node labels, PD = { rop, sp, lep, rip, mip, lec, mic, ric } is a finite set of terminal node labels, PD = { ∗ }, PD = { ∗ }, PPD = { P1 , . . . , P17 } is a finite set of production rules, and SPD = { S }, is the initial non-terminal. In Definition 3.7, rop, sp, lep, rip, mip, lec, mic, ric, stands for “root of package”, “single package”, “left package”, “right package”, “middle package”, “left class”, “middle class”, “right class”, respectively. The GGPD generates package hierarchy diagrams. It is a contextfree grammar, and there are 17 production rules. There are three types of production in PPD , as shown in Fig. 6. In Fig. 6, nodes with capitalized labels indicate a nonterminal nodes, and nodes with uncapitalized labels indicate terminal nodes. Type 1 and Type 2 productions generate tree structures in a longitudinal direction and in a transverse direction, respectively. Type 3 productions substitute a nonterminal node for a terminal node. In Fig. 6(a), the production rule can be applied to a node labeled L, which is a non-terminal node, to generate a terminal node with the label lep, representing a package, and a non-terminal node labeled T. Our grammar generates directed graphs. However, the obtained graphs are drawn without arrows by assuming that the direction of each edge is from the top down. 3.2. Example of derivation Fig. 7 shows an example of a GGPD derivation. In this example, G0 is a graph with a node labeled S. The node ID is 1 (lower right of the node). Then the production rule P1 is applied to a non-terminal node labeled S with the node ID 1, which is the initial nonterminal node. That is, a mother node with label S and node ID 1 is removed, then embed a daughter graph in the P1 . In this case, the daughter graph is the node with the label A. This produces the nonterminal node labeled A with a node ID 2, to which the P3 production rule is applied. That is, a graph G1 consisting of a node with the node ID 2, is obtained. After application of the production P3 , the terminal node labeled rop and a non-terminal node labeled T are generated. We apply productions to obtain a graph that corresponds to UML package diagrams. We can obtain a derivation tree from the derivation sequence of production. Fig. 8 shows the derivation tree corresponding to Fig. 7. In Fig. 8, the labels show the names of the production rules. Another example of a package diagram resulting from applying the production rules is shown in Fig. 9.
2
A rop
P3
2, P3'
+ T
G2: rop
+
3
T 4
T L
P6
4, P6'
R
G3: rop
+ L
3 R 6
5
L
5, P8'
P8
lep
G4: rop
+
3 R
lep
6
7
R
6, P12'
P12
rip
G5: rop
+
3
rip
lep 7
8 Fig. 7. An example of a GGPD derivation.
4. Attribute evaluation In this section, we explain how to evaluate attributes. Attributes are used to hold values such as calculating coordinates and Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model
ARTICLE IN PRESS
JOCS-263; No. of Pages 10
T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
P1
generating SVG files. These attributes are evaluated on a derivation tree such as shown in Fig. 8, where the vertices are labeled by a production rules number. Each production rule has semantic rules for calculating the attribute’s values. Semantic rules can be defined formally and declaratively. Here we describe the details of attributes and semantic rules for X − Y coordinates and generating SVG.
P3 P6 P8
P12 4.1. Calculation of coordinates for diagrams
Fig. 8. A derivation tree corresponding to the tree in Fig. 7.
In order to lay out elements of package diagram such as package and class, we calculate attribute values using attribute evaluates. There are four attributes for layout diagrams such as tw (tree width), x, y, and nw (node width). Attribute tw is a synthesized attribute, and attributes x and y are inherited attributes. Attribute nw stores node widths that are used in calculating attribute tw. An attribute evaluate for attributes tw, x, and y are done as follows:
rop +
lep
rip +
1 Attribute evaluation for synthesized attribute tw is done on a derivation tree based on a bottom-up manner. 2 Attribute evaluation for inherited attribute x is done on derivation tree based on top-down manner. 3 Attribute evaluation for inherited attribute y is done on derivation tree based on top-down manner.
+
sc
5
lec
ric
First, we explain the attribute tw that calculates package diagram width. Semantic rules for the attribute tw are defined for such three types of productions.
Fig. 9. An example of package diagram resulting from derivation.
S
A
P1
tw(1)=tw(2)=15 2 1
A rop
P3
+
tw(2)=tw(4)=15 tw(3)=tw(4)=15
3
T 4 2
T
P6
L
R 5
tw(4)=tw(5)+GapX+tw(6) =15
6 4
R
L
P8
tw(6)=tw(8)=nw(8)=5
tw(5)=tw(7)=nw(5)=5
lep
P12 7
rip 8
5
6
Fig. 10. A derivation tree with semantic rules for tree width corresponding to the tree in Fig. 7.
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model
ARTICLE IN PRESS
JOCS-263; No. of Pages 10
T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
6
Two semantic rules tw(1) = tw(2) and tw(0) = tw(2) are defined for production rule Type I in Fig. 6. By synthesized attribute evaluation, when this attribute tw is used for this type I of production rules, tw(2) holds a max width of sub trees which is derived from the node. In order to synthesize tw(2)’s value to a superior attribute such as tw(1), tw(0), tw(2)’s value is set to tw(1) and tw(0). In this Type II of production in Fig. 6, attribute tw of a node on the left-hand side of the production rule holds summation of sub tree’s max width derived from node L and R and gap size between node L and R. Therefore the semantic rule of Type II production is defined as tw(0) = tw(1) + Gapx + tw(2). In this Type III of productions in Fig. 6, attribute tw of a node in left-hand side of the production rule holds the width of the terminal node in the right-hand side of the production. Therefore, the semantic rule of Type II production is defined as tw(0) = tw(1) = nw(1). Here, nw(1) indicates the width of the terminal node lep. Here, we show the process for the attribute evaluation process for attribute tw in Fig. 10. Because attribute tw is a synthesized attribute, attribute evaluation has been done in a bottom-up manner on the derivation tree. In the example in Fig. 10, each node on the derivation tree has traversed as follows P8 → P12 → P6 → P3 → P1 . In the P8 , a node size of terminate node labeled lep (in this case 5) is stored to tw(5) which is the node on the left-hand side of production rule, and tw(7), which is a node on the right-hand side of the production rule. P12 is processed in the same manner.
S
In the process of P6 , summation of tw(5), tw(6) and the gap between nodes 5 and 6 is substituted into tw(4). Moreover, in the process of P3 , tw(2) and tw(3) store the value of tw(4). P1 sets tw(2) to tw(1), then finally tw(1) has 15. This means that this case diagram width equals 15, and attribute tw of each node indicates the maximum widths of nodes located in the inferior portion of the node. Next, we review attribute x that calculates the horizontal location of each node. Because attribute x is an inherited attribute, attribute evaluation has been done in a top-down manner on the derivation tree. On calculating of attribute x, values are obtained using the criterial x-coordinate and tree width (attribute tw). Fig. 11 shows the calculation process of attribute x. In this case, attribute evaluation has been done in the following order: P1 → P3 → P6 → P8 → P12 In P1 , x(1) and x(2) are set to 0. In P3 , in order to calculate x coordinate of terminal node rop, criterial x-coordinate x(2), draw area size tw(3), and node width nw(3) are used to calculate. In this case, the terminal node rop locates on the center of diagram width. So as to obtain x(6), the x coordinate of node L (node 5) and tree width attribute of node L, and gap between node L and R are used to calculate. In the attribute evaluation for attribute y, attribute evaluation is done in a top-down manner. The calculation process of attribute y is described in Fig. 12. For P3 , y coordinate is added using gap Y when a production rule which generates a graph in vertical direction is applied.
A
P1
x(1)=x(2)=0 2 1
A rop
P3
+
x(3)=x(2)+tw(3)/2-nw(3)/2=0+7.5-2.5=5 x(4)=0
3
T 4 2
T
P6
L
R 5
x(5)=x(4)=0 x(6)=x(5)+tw(5)+GapX=0+5+5=10
6 4
R
L
P8
x(8)=x(6)=10
x(7)=x(5)=0
lep
P12
rip 8
7 5
6
Fig. 11. A derivation tree with semantic rules for x coordinate corresponding to the tree in Fig. 7.
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model
ARTICLE IN PRESS
JOCS-263; No. of Pages 10
T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
S
A
P1
7
y(1)=0 y(2)=y(1)=0
2 1
A rop
P3
+
y(3)=y(2)=0 y(4)=y(3)+GapY=0+5-5
3
T 4 2
T
P6
L
R 5
y(5)=y(4)=5 y(6)=y(4)=5
6 4
R
L
P8
y(8)=y(6)=5
y(7)=y(5)=0
lep
P12 7
rip 8
5
6
Fig. 12. A derivation tree with semantic rules for y coordinate corresponding to the tree in Fig. 7.
derivation tree
attribute evaluation
derivation tree with SVG
semantic rules for SVG
output: SVG file
Fig. 13. Flow of generating SVG files.
4.2. Generation of SVG documents for package diagrams We introduce the attribute SSVG which contains SVG source codes, as its value and representation correspond to the package diagram using alternative membership notation. SVG can display in browsers such as IE with an SVG plugin; therefore, we can embed generated SVG files into software documents such as HTML or XML. Fig. 13 illustrates the flow of generating SVG files. We can obtain a derivation tree after obtaining package diagrams using production rules. SVG source codes are generated by evaluating SSVG . The attribute evaluation is then performed in a bottom-up manner on derivation trees referring to semantic rules associated with
production rules. Through this process we can obtain a derivation tree with SVG information and SVG files. Fig. 14 gives an example of semantic rules for the SSVG attribute of a production. The left-hand side of the figure illustrates a production rule, and the right-hand side shows the semantic rules for the production rule. In the semantic rules part of Fig. 14, SSVG (1) is the semantic rule for the attribute of node 1 in the production part. SSVG (1) stores drawing information for node 1; that is, SSVG (1) includes a rect tag to draw rectangle. x(1), y(1), w(1), and h(1) have the value of node 1’s layout information. SSVG (2) stores all derivable drawing information from nonterminal node 2 with the label T. When attribute evaluation has been done on this production, SSVG (2)’s value is already decided because the evaluation of attributes is performed in a bottom-up manner on derivation trees. SSVG (0) stores a concatenation of SSVG (1) and SSVG (2); therefore, SSVG (0) has all drawing information derivable from the nonterminal node 0 with the label A. Fig. 15 gives a concrete example of the attribute evaluation of SSVG on the derivation tree corresponding to Fig. 8. The attribute evaluation is performed in a bottom-up manner on derivation trees. In this case, the attributes are evaluated in the following order: Production 8 → Production 12 → Production 6 → Production 3 → Production 1. On the process of Production 8, information of drawn node 7 with the label lep is stored with the attributes of SSVG (7). Then
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model
ARTICLE IN PRESS
JOCS-263; No. of Pages 10
T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
8
A rop
P3
+
1
T
• 2 0
Production rule
Semantic rules
Fig. 14. An example of semantic rules for the SSVG attribute of a production.
S
A
P1
SSVG(1)=SSVG(2) 2 1
A rop
P3
+
SSVG(3)=
3
T 4 2
T
P6
L
R 5
SSVG(4)=SSVG(5)•SSVG(6) 6 4
R
L
P8
lep 7 5
SSVG(7)=
P12
rip 8 6
SSVG(8)=
Fig. 15. A derivation tree with semantic rules for SVG corresponding to the tree in Fig. 7.
SSVG (7) is assigned to SSVG (5), which is an SSVG attribute of the nonterminal node 5 with the label L . The attribute evaluation of Production 12 has been done using the same process as Production 8. SSVG (8) stores information from node 8 with the label rip, and SSVG (8) is assigned to SSVG (6). In the next step, the attribute evaluation of Production 6 has been done. Here SSVG (4) stores the concatenation of SSVG (5) and SSVG (6), and then SSVG (4) has the drawing information from node 7 and node 8. In the next step, the attribute evaluation of Production 3 has been done. SSVG (3) stores drawing information from node 3 with the label rop, and the concatenation of SSVG (3) and SSVG (4) is assigned to SSVG (2). Then SSVG (2) has drawing information from node 3, node 7, and node 8.
Finally, Production 1 is evaluated. In this case, SSVG (2) is assigned to SSVG (1). Thus, SSVG (1) has all drawing information from the package diagram including nodes 3, 7, and 8. After post-processing, we can obtain the SVG file corresponding to G5 in Fig. 7. 5. UML package diagram editor In this section, we explain our prototype UML package diagram editor based on the grammar described in Section 3. The editor is a syntax-directed editor and was developed in Java. Fig. 16 shows a screenshot of the editor. In the editor, when a nonterminal node displayed on the editor screen is selected, a screen displaying the production rules that can
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model JOCS-263; No. of Pages 10
ARTICLE IN PRESS T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
Fig. 16. A screenshot of the package diagram editor.
9
Fig. 19. An example of applying production rules to the editor.
Fig. 17. A nonterminal node on the editor.
Fig. 20. The derivation tree display screen of the package diagram editor.
be applied to the nonterminal node is displayed. Figs. 17–19 show screen shots of when the non-terminal node with the node ID of 2 and the label A in the package diagram editor screen is clicked (Fig. 17), and the applicable production rules are displayed (Fig. 18). After choosing a production rule, the production rule is applied to the non-terminal node (Fig. 19). The applied production rules can also be displayed as a derivation tree, as shown in Fig. 20. When users execute an editor command, SVG files can be automatically generated by evaluating SVG attributes. The evaluation is executed by traversing on the derivation tree. Fig. 21 is an example of the display of a package diagram in SVG. 6. Discussion
Fig. 18. The production rule display screen of the package diagram editor.
The proposed method is about supporting UML modeling. We define a formal method for generating a package diagram of UML using a graph grammar. The proposed method can be applied to
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005
G Model JOCS-263; No. of Pages 10
ARTICLE IN PRESS T. Goto et al. / Journal of Computational Science xxx (2014) xxx–xxx
10
[11] T. Nishino, Advances in Software Science and Technology 1 (2012) 89–104. [12] T. Arita, K. Sugita, K. Tsuchida, T. Yaku, Proceeding of IASTED Applied Informatics (2001) 637–642. [13] O. M. Group, Omg unified modeling language (omg uml), infrastructure, v 2.1.2, http://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF/, 2007. [14] T. Kirishima, T. Goto, T. Yaku, K. Tsuchida, 2010 IEEE/ACIS 9th International Conference on Computer and Information Science (ICIS) (2010) 341–346. Takaaki Goto graduated with a Doctor of Engineering degree from Toyo University in 2009. He is a Project Assistant Professor at the Graduate School of Informatics and Engineering at The University of Electro-Communications. His main research interests are applications of open source software development, software development education, graph grammars, visual languages, and software development environments. He is a member of IEICE Japan, IPSJ, and IEEE.
Fig. 21. An example of the display of a package diagram in SVG.
design distributed and Web-based systems. Such systems need large and complicated diagrams, which are difficult to model by hand. Thus there is a need for formal methods to manipulate diagrams, such as our method. At present we target package diagrams only; however, our method can be employed to generate/analyze class diagrams. In addition, a parser for the diagrams, based on our graph grammar which is under construction, can analyze diagrams and provide useful information such as dependencies. Such information can be used to modify the systems to enhance their performance. 7. Conclusion In this paper, we have defined a graph grammar for generating the membership notation of UML package diagrams. We have also developed a syntax-directed diagram editor for the defined grammar. A future study issue is implementing syntactic analysis. The editor developed here is able to generate diagrams according to the grammar and of checking with the syntax through human intervention, but it is not able to determine, from an arbitrary input, whether a diagram conforms or not. By implementing syntactic analysis, generating UML package diagrams using membership notation can be realized from source code based on formal mechanisms. The application of this technology to the automatic generation of software documentation is another possibility.
Tadaaki Kirishima received M.E. and D.E. degrees from Toyo University in 2002, and 2011, respectively. He is currently a part-time Lecturer at J. F. Oberlin University and Toyo University. His main research interests are applications of graph grammars, and graph drawing.
Tetsuro Nishino graduated from department of Mathematics, Waseda University, and continued his research and obtained a D.Sc. in Mathematics in 1991. He was a researcher at Tokyo Research Laboratory, IBM Japan during 1984–1987. He was an Associate Professor at School of Information Science, Japan Advanced Institute of Science and Technology, Hokuriku during 1992–1994. In 1994, he joined at Department of Communications and Systems Engineering, The University of Electro-Communications as an Associate Professor and in 2006 he became a Professor. He received The Funai Information Technology Prize (2003) and IBM Faculty Award (2008). Takeo Yaku received his M.Sc. and D.Sc. degrees from Waseda University in 1972 and 1977, respectively. He has been a Professor at the Department of Computer Science and System Analysis of Nihon University since 1992. His research interests include software visualization, human interface, graph languages, and graph algorithms. He is a member of IEICE Japan, IEEE Computer Society, and ACM.
References [1] K. Harada, Structure Editor, Kyoritsu Shuppan (1987) (in Japanese). [2] Y. Adachi, Y. Miyadera, K. Sugita, K. Tsuchida, T. Yaku, Proceedings of The 20th International Conference on Software Engineering (ICSE’98) vol. 2 (1998) 74–79. [3] T. Goto, K. Ruise, T. Yaku, K. Tsuchida, IEICE Transactions on Information and Systems 92 (2009) 401–412. [4] G. Rozenberg, Handbook of Graph Grammar and Computing by Graph Transformation. Vol. 1, World Scientific Publishing, 1997. [5] L. Kotulski, D. Dymek, Computational Science ICCS 2008 5101 (2008) 86–395. [6] F. Hermann, H. Ehrig, G. Taentzer, Electron. Notes Theor. Comput. Sci. 211 (2008) 261–269. [7] J. Kong, K. Zhang, J. Dong, D. Xu, J. Syst. Softw. 82 (2009) 292–306. [8] D. Petriu, H. Shen, Computer Performance Evaluation: Modelling Techniques and Tools 2324 (1994) 183–204. [9] W3C, Scalable Vector Graphics (SVG), http://www.w3.org/TR/SVG/ [10] M. Kaul, Graph Grammars and Their Application to Computer Science 291 (2012) 326–342.
Kensei Tsuchida received M.S. and D.S. degrees in mathematics from Waseda University in 1984 and 1994, respectively. He was a member of the Software Engineering Development Laboratory, NEC Corporation in 1984–1990. From 1990 to 1992, he was a Research Associate of the Department of Industrial Engineering and Management at Kanagawa University. In 1992 he joined Toyo University, where he was an Instructor until 1995 and an associate professor from 1995 to 2002, and a Professor from 2002 to 2009 at the Department of Information and Computer Sciences, and since 2009 he has been a Professor of Faculty of Information Sciences and Arts. He was a Visiting Associate Professor of the Department of Computer Science at Oregon State University from 1997 to 1998. His research interests include software visualization, human interface, graph languages, and graph algorithms. He is a member of IPSJ, IEICE Japan and IEEE Computer Society.
Please cite this article in press as: T. Goto, et al., Generation of UML package diagrams based on an attribute graph grammar, J. Comput. Sci. (2014), http://dx.doi.org/10.1016/j.jocs.2014.02.005