A Framework for Modeling and Implementing Visual ...

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0

A Framework for Modeling and Implementing Visual Notations With Applications to Software Engineering GENNARO COSTAGLIOLA, VINCENZO DEUFEMIA, and GIUSEPPE POLESE Universita´ di Salerno

We present a framework for modeling visual notations and for generating the corresponding visual programming environments. The framework can be used for modeling the diagrammatic notations of software development methodologies, and to generate visual programming environments with CASE tools functionalities. This is accomplished through an underlying modeling process based on the visual notation syntactic model of eXtended Positional Grammars (XPG, for short), and the associated parsing methodology, XpLR. In particular, the process requires the modeling of the basic elements (visual symbols) of a visual notation, their syntactic properties, the relations between them, the syntactic rules to formally define the set of feasible visual sentences, and a set of semantic routines performing additional checks and translation tasks. Such a process is completely supported by the VLDesk system, which enables the automatic generation of an editor for drawing visual sentences, as well as a processor for their recognition, parsing, and translation into other notations. The proposed framework also provides the basis for the definition of a meta-CASE technology. In fact, we can customize the generated visual programming environment in terms of the supported visual notation, its syntactic properties, and the translation rules. We have used this framework to model several diagrammatic notations used in software development methodologies, including those of the Unified Modeling Language. Categories and Subject Descriptors: D.1.7 [Programming Techniques]: Visual Programming; D.2.2 [Software Engineering]: Design Tools and Techniques—Computer-aided software engineering (CASE); State diagrams; D.3.4 [Programming Languages]: Processors—Parsing; Translator writing systems and compiler generators; F.4.2 [Mathematical Logic and Formal Languages]: Grammars and Other Rewriting Systems—Grammar types; Parsing General Terms: Algorithms, Design, Languages Additional Key Words and Phrases: LR parsing, meta-CASE, metamodeling, software engineering models, UML, visual grammars, visual notations

This article is a revised and extended version of a paper presented at the IEEE Symposium on Visual Languages 2000. Authors’ address: Dipartimento di Matematica e Informatica, Universita´ di Salerno, Via Ponte don Melillo, 84084 Fisciano(SA), Italy; email: {gcostagliola,deufemia,gpolese}@unisa.it. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or direct commercial advantage and that copies show this notice on the first page or initial screen of a display along with the full citation. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of this work in other works requires prior specific permission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 1515 Broadway, New York, NY 10036 USA, fax: +1 (212) 869-0481, or [email protected]. C 2004 ACM 1049-331X/04/1000-0001 $5.00 ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004, Pages 1–57.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

2

•

December 8, 2004

22:0

G. Costagliola et al.

1. INTRODUCTION A software design methodology is mainly characterized by the process it defines, and by the set of notations, most of which are visual, used to model the different aspects of a software system, at different levels of abstractions. Typical notations used in waterfall methodologies include entity-relationship diagrams, SADT diagrams, dataflow diagrams, flow charts, and so forth, whereas those used in object-oriented methodologies include class diagrams, state diagrams, and so on. Moreover, all methodologies might include textual notations typically used to describe data dictionaries and artifacts close to the final code. Software engineers have often been skeptical of the real usefulness of software design methodologies, and on the real improvements they yield in software productivity. Nevertheless, researchers have made considerable efforts to develop new models, techniques, and tools to broaden the usage of design methodologies among software developers. A first attempt in this direction is represented by CASE tools [Bell and Sharon 1995; Chmura and Crockett 1995; Fisher 1992; McClure 1989], which provide automated support for the different phases of software design methodologies. CASE tools are typically tailored on a specific methodology, or upon a single technique comprised of one or more methodologies. Their goal is to provide editors with the notations used in design methodologies, possibly with some checking mechanisms to verify their syntactic correctness. Moreover, CASE tools should perform the mapping of notations onto lower-level notations as prescribed by the development process being used. More advanced tools might provide reverse engineering capabilities, that is, mapping of lower-level notations into higher-level notations. In the 80s, CASE technology raised particular attention and expectations from managers of companies involved in the development and maintenance of large software systems. However, they did not succeed in improving software productivity and in broadening the usage of design methodologies, mainly due to their tight coupling with the underlying methodologies, forcing software developers to follow the working philosophy imposed by the tools. Software developers really needed flexible tools that could be customized to their software development process [Coad and Yourdon 1991]. The need to have flexible CASE tools led to the development of meta-CASE technologies [Alderson 1991; Kelly et al. 1996; Sorenson et al. 1996], providing the means to customize the software design methodology and to automatically generate CASE tools supporting them. The construction of CASE tools requires the capability to generate visual editors supporting given diagrammatic notations. Some tools merely provide hardwired visual editors. More advanced tools provide ways to enforce the syntactic and semantic correctness of diagrams, possibly with code generation facilities. To this end, several researchers have exploited visual language grammars to model the syntax of visual notations, deriving new methods for implementing visual editors. Some of these do not exploit parsers, and, therefore, they build advanced editors supporting the construction of diagrams according to the syntax-directed paradigm. On the other hand, methods based on parsers exploit compiler generator techniques to construct freehand editors automatically. In ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0

A Framework for Modeling and Implementing Visual Notations

•

3

the literature, there are several arguments in favor of one or the other approach ¨ 1997; Serrano 1995]. In particular, it is recog[Minas 1997; Rekers and Schurr nized that although the syntax-directed approach prevents the user from drawing syntactically or semantically incorrect diagrams, it constrains the editing process too much, and potentially reduces the user’s ability to abstractly reason about the drawings s/he wants to compose. Whereas, freehand editors present users with an unconstrained modeling environment, which is regarded more and more as an important part of the future CASE tools [Jarzabek and Huang 1998]. In fact they allow diagram restructuring, and incorrect sketch drawing without any interference. In this article we present a new framework for modeling visual notations and for generating the visual programming environments supporting them. It consists of a grammar formalism, called eXtended Positional Grammars (XPG, for short) [Costagliola and Polese 2000], a parsing methodology, called XpLR parsing, which taken together represent the backbone of the presented framework, and a process for modeling visual notations. Moreover, we describe the Visual Language Desk (VLDesk) system, which provides automated support for the phases of the modeling process underlying the framework. The XPG grammar formalism can be effectively used for modeling both visual and textual notations in a seamless way. It extends Positional Grammars [Costagliola et al. 1997] with mechanisms for handling contextual information, enabling us to model a broader class of visual languages, which includes the diagrammatic notations used in software engineering. Moreover, the associated XpLR parsing methodology includes conflict-handling techniques, enabling us to efficiently parse grammars that would otherwise undergo a tedious conflictcleaning process, making them more complex and less intuitive. The VLDesk system contains tools that simplify the specification of XPGs and the associated conflict-handling rules. In particular, it provides a symbol editor to visually specify notation layouts and attributes of visual symbols, and a grammar editor to visually specify the XPG and the semantic actions that must be undertaken for correctly parsed visual sentences. At the end of this specification process, VLDesk automatically generates a freehand visual editor for the specified notation and the corresponding compilers to provide the semantic checks and the translation tasks. The framework, together with VLDesk, can be proficiently used for modeling the visual notations of software design methodologies and for generating associated CASE tools that have the capability to enforce syntactic and semantic correctness of visual notations in a freehand editing style. Thus, in the article we focus on the use of the presented framework for customizing software design processes and the tools supporting them. Under this scenario, our approach is mainly targeted to software methodology users, who are professionals working for tool vendors, or companies managing complex software projects. They can be assisted by a staff of professionals who help them in implementation tasks, such as compiler construction and testing activities. Nevertheless, software engineers who have some compiler construction skills can still use the approach. The framework supports methodologists in the specification of the software development process, including the ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

4

•

December 8, 2004

22:0


notations with their syntactic and semantic properties, and in the automatic generation of the corresponding CASE tools. The user need not specify them from the beginning, because s/he can choose to modify the process and the notations used within existing software development methodologies. In fact, in some ways it is possible to combine the modeled notations with existing CASE tools to speed up the engineering process, provided that the tool vendor allows for the export or import information in a known format, such as SVG [Ferraiolo 2001]. Thus, the framework provides a high degree of flexibility and a loose coupling between development methodologies and CASE tools, which can potentially increase their usage, possibly resulting in a positive impact on software productivity. The article is organized as follows. In Section 2, we present an approach for describing visual notations. In Section 3, we present the proposed framework, emphasizing its three main components: the modeling process, the eXtended Positional Grammars, and the XpLR methodology. Section 4 describes the VLDesk system used to generate CASE tools for the visual notations modeled with our framework. In Section 5, we survey related approaches. Finally, conclusions and further research are discussed in Section 6. A complete example showing the XPG grammar for modeling UML statechart diagrams is given in Appendix section, and the detailed algorithms for constructing XpLR parsing tables are described in Appendix section. 2. AN APPROACH FOR DESCRIBING VISUAL NOTATIONS In this section, we present an approach to formally describe visual notations, [Costagliola et al. 2002; Costagliola and Polese 2000]. A visual notation is a visual language, since it is formed by a set of visual symbols from an alphabet and a set of feasible visual sentences over these symbols. A feasible visual sentence of a language L is a set of visual symbols related to one and other according to the syntax of L. The approach presented below can be used to describe many different classes of visual languages [Costagliola et al. 2002]. In this article, we will mainly focus on its use to describe visual languages of software design methodologies. 2.1 Visual Symbols A visual symbol vs (vsymbol, for short) is a graphical object with an associated type name and a set of attributes. As a graphical object it has a physical appearance, with size, color, shape, and so forth. The type name allows us to refer to a vsymbol through a string when needed; the set of attributes can be classified in syntactic and semantic attributes. The syntactic attributes are used to relate vs to other vsymbols, and their values depend on the “position” of the vsymbol in the sentence. The semantic attributes describe the semantic interpretation of a vsymbol. As an example, let us consider the vsymbol describing the decision element of a flowchart. In this case, the graphical object is , that is, a rhombus and three little circles (attaching points); a possible type name is DECISION. The syntactic attributes keep track of the links connected to each attaching point, ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

5

Fig. 1. A flowchart (a) and an activity diagram (b).

whereas the semantic attributes qualify DECISION. as the condition block of a conditional or loop statement in a flowchart. 2.2 Visual Sentences A visual alphabet is a set of vsymbols. A visual sentence (vsentence, for short) over is a set of vsymbols with their syntactic attributes completely instantiated. Informally, a vsentence can be seen as a set of vsymbols arranged on a two-dimensional space, and possibly related through special relationships. One way to represent relationships is by instantiating the syntactic attributes of vsymbols. Examples of vsentences are given in Figure 1. In particular, the vsymbols of Figure 1(a) are “flowchart” blocks. They are related by means of connecting lines, represented by storing information for attaching points within the syntactic attributes of vsymbols. In the activity diagram of Figure 1(b), relations involve attaching regions (highlighted by thicker lines) other than attaching points. It is easy to note that attaching points can be seen as a special case of attaching regions. Thus, definitions and discussions on attaching regions also apply to attaching points. Relations can be of two different types: connection and geometric [Costagliola et al. 2002]. A connection relation is specified on a sequence of a finite number of attaching regions. Visual sentences can be built by connecting attaching regions of vsymbols through links or arrows. One or more links can be attached to an attaching region. As an example, the vsymbol On in Figure 2(a), semantically representing a superstate in a statechart [Harel 1988], has one attaching region ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

6

•

December 8, 2004

22:0


Fig. 2. A visual sentences with both geometric and connection relations (a) and a visual sentence with explicit relations (b).

represented by its borderline, and the two arrows on and off are attached to it. A geometric relation between vsymbols is specified on the coordinates of the upper-left and the lower-right vertices of their bounding boxes. Vsentences can be built by composing vsymbols through relations such as containment, sibling, right-to, and so on. As an example, the vsymbol NotOn in Figure 2(a) is related to the two vsymbols Standby and Off in its bounding box through the containment relation. As another example, the vsymbol a in the string bacb is related to the vsymbol c through the right-to relation. In this case, right-to is the visual counterpart of the string concatenation relation. Notice that a designer may consider a graphical object in a sentence as a relation rather than a vsymbol. In this case, it is called explicit relation. For example, in Figure 2(b), the edges representing roads between cities may be considered as explicit connection relations. On the other hand, relations are implicit when they have no visual representation. For example, in Figure 2(a), both the connection relation between arrow vsymbols and state vsymbols, and the containment relation between states are not explicitly represented. 2.2.1 Classification of Spatial Relation Types. Starting from the two basic types of relations connection, and geometric, it is possible to derive more specialized subtypes of relations, as shown in Figure 3. In particular, the relations of type Graph are line and arrow connections, and are typically used in vsentences representing graph structures. Specifically, they act on attaching regions of the vsymbols they connect. The relations of type Plex are a subtype of Graph relations, since they are connection relations involving attaching points of vsymbols [Feder 1971]. The relations of type Box are a subtype of Geometric relations. They correspond to spatial compositions of three types: inclusion, intersection, and spatial concatenation, all defined on the vertices of the vsymbols bounding boxes. Relations of type Iconic are similar to these, but they do not include inclusion and intersection. Finally, it is recognized that the only feasible relation in string languages is the right concatenation between characters. Visual notations can be classified based upon the types of relations instantiated in their visual sentences [Costagliola et al. 2002]. Thus, we can have visual notations of type Graph, Iconic, and so on. Nevertheless, there are visual ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

7

Fig. 3. A hierarchy of spatial relation types.

notations whose vsentences instantiate relations from more than one type of relation. These are classified as hybrid visual notations [Costagliola et al. 2002]. As an example, the statechart in Figure 2(a) uses arrows between nodes, which are of type Graph, and the containment relation, which is of type Box. Thus, we can say that statecharts notation is a hybrid Graph/Box visual notation. However, statecharts could also be modeled through the hybrid combination Connection/Geometric. Nevertheless, we prefer to model each visual notation at the lowest possible level in the hierarchy because lower-level relation types are more abstract and are conceptually closer to the primitives of the modeled notations. In fact, in the extreme case, one could model all the visual notations as Geometric by considering their vsymbols as pixels and their vsentences as matrices of pixels related through relations of type Geometric. However, this poorly characterizes the modeled notation, since it does not highlight its peculiarities. It is easy to show that through the Graph and Box types of relations and their hybrid combination, it is possible to model most visual notations used in software design methodologies, including those used in Web and multimedia design methodologies. As an example, the notation class Graph allows us to model SADT diagrams [Ross and Schoman Jr. 1977], class diagrams, EntityRelationships diagrams [Chen 1985], Petri nets, emerging notations for Web engineering like Web site maps (see Figure 4(a)), IEC Function Block Diagrams [IEC 1993], and so forth. The class Box allows us to model GANTT charts, Nassi-Shneiderman diagrams [Nassi and Shneiderman 1973], multimedia presentation layouts (see Figure 4(b)) [Cruz and Lucas 1997], and so on. Finally, the combination Graph/Box allows us to model statechart diagrams, SSADM diagrams [Goodland and Slater 1995], UML deployment diagrams, SDL [Fargemand and Olsen 1994], and so forth. 2.2.2 Hierarchical Visual Sentences. A vsymbol of a visual language can be annotated with a visual sentence from the same or a different visual notation to provide a detailed description of it. As an example, Figure 5 describes a UML class diagram containing two classes, Person and Traditional Person, combined in a generalization/specialization hierarchy. Each class is annotated with a statechart diagram that describes its dynamic behavior. Also the vsymbols of the annotating language can, in turn, be annotated, yielding a hierarchy of visual ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

8

•

December 8, 2004

22:0


Fig. 4. A Web site map (a) and a multimedia presentation layout (b).

notations. In our approach, the annotation is seen as a logic relation between two notations. Note that the annotating notation need not be diagrammatic. As a matter of a fact, a vsymbol could also be annotated by a string language such as a high-level textual specification. Annotations lead to the definition of hierarchical visual notations, [Costagliola et al. 2002]. More formally, a hierarchical visual notation is a visual language whose vocabulary contains vsymbols that are annotated with textual or visual sentences from the same or another language, yielding homogeneous or heterogeneous hierarchies of visual languages, respectively. Hierarchical visual language support is a vital aspect in software engineering. In fact, most software development methodologies rely upon a hierarchical combination of different visual notations. As an example, SADT diagrams use boxes to represent activities, each of which can, in turn, be annotated with another SADT diagram describing the details of the activity [Ross and Schoman Jr. 1977]. Similarly, visual symbols of a flowchart can be annotated by textual code. 2.3 Representation of Visual Sentences We consider three ways to syntactically represent a visual sentence: attributebased, relation-based, and linear. We will see that these representations can be converted one into the other, even though the conversions may not be one-toone. 2.3.1 Attribute-Based Representation. In the attribute-based case, a vsentence is represented by explicating the syntactic attributes of the vsymbols composing it. Let us examine how this representation method applies to the visual languages in the class hierarchy of Figure 3. In the case of visual languages from the class String, we can materialize the value of the attribute position of a ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

9

Fig. 5. A visual sentence with two annotations.

vsymbol, which represents the position index of the vsymbol in a string; in the case of Plex visual languages, the attaching points of a vsymbol v are numbered and represented by an array ap[1], . . . , ap[n]. The value of ap[i] is given by a unique label assigned to the link, plugged into attaching point i of v; in the case of Graph visual languages, the attaching regions of a vsymbol v are numbered and represented by an array aps[1], . . . , aps[n] of sets. The value of aps[i] is the set of labels of the links plugged into attaching region i of v. Figure 6(a) shows the attribute-based representation of an activity diagram by considering the link labeling provided in Figure 6(b). 2.3.2 Relation-Based Representation. Given a visual sentence vs, let us consider a set R of binary relation identifiers. A labeled graph on R and vs, G R,vs = (N , E), is defined as follows: — each node in N identifies a distinct vsymbol in the sentence vs, — a labeled edge (x, y, REL) is in E iff REL ∈ R holds between subsets of syntactic attributes from the vsymbols x and y, respectively. Definition 2.1. Let R and vs be a set of binary relation identifiers and a visual sentence, respectively. A relation-based representation of vs with respect to R is any labeled graph G R,vs that is connected. In the following, we will denote a labeled graph G R,vs by listing its labeled edges in the format REL(x, y). As an example, let us consider the visual sentence in Figure 6(b). It can be modeled according to the visual language class Graph, by using a class of relations of type LINK i, j defined as follows: a vsymbol x is in relation LINK i, j with a vsymbol y if and only if attaching point i of x is connected to attaching point j of y, that is, if and only if ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

10

•

December 8, 2004

22:0


Fig. 6. Attribute-based representation (a) of the activity diagram in Figure 1(b), based on the link labeling in (b).

apsx [i] ∩ aps y [ j ] = ∅. Under these assumptions, the relation-based representation of the activity diagram of Figure 6(b) is given by the set: {LINK 1,1 (Start, Activ1), LINK 1,2 (Activ1, Sync1), LINK 2,1 (Sync1, Activ2), LINK 2,1 (Sync1, Activ3), LINK 2,1 (Activ2, Cond), LINK 2,1 (Cond, Activ4), LINK 3,1 (Cond, Activ5), LINK 2,1 (Activ4, Mux), LINK 2,2 (Activ5, Mux), LINK 3,1 (Mux, Sync2), LINK 2,1 (Activ3, Activ6), LINK 2,1 (Activ6, Sync2), LINK 2,1 (Sync2, Activ7), LINK 2,1 (Activ7, Halt)}.

2.3.3 Linear Representation. Definition 2.2. Given a visual sentence vs = {x1 , . . . , xn } and a set of relation identifiers R, a linear representation of vs with respect to R is the pair (G R,vs , P ) where: (1) G R,vs is a relation-based representation of vs with each relation in R invertible; (2) P is a permutation ( y 1 , y 2 , . . . , y n ) of the vsymbols in vs such that for each y i with 1 < i ≤ n, there exists at least an index k such that 1 ≤ k < i and an edge in G R,vs on y k and y i . This means that each vsymbol is connected to at least one of the vsymbols preceding it in the permutation. A linear representation (G R,vs , P ) will be denoted in the following as the string y 1 R1 y 2 R2 y 3 . . . Rn−1 y n , where each R j is a nonempty sequence of type: hm with m ≥ 1. REL1h1 , . . . , RELihi , . . . , RELm ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

11

Each RELihi in R j denotes the pair (RELihi , hi ), where RELi ∈ R or RELihi = REL−1 with REL ∈R, RELi labels the edge ( y j −hi , y j +1 ) in G R,vs , and it relates syntactic attributes of y j +1 with syntactic attributes of y j −hi , with 0 ≤ hi < j . In the rest of the article, we will denote REL01 simply as REL1 . Notice that, since G R,vs is connected and the relations are invertible, it is always possible to find at least one linear representation for vs. As an example, let us consider the activity diagram in Figure 6. If we consider its relation-based representation given above, then the permutation of vsymbols: (Start, Active1, Active2, Active3, Active4, Active5, Active6, Active7, Sync1, Sync2, Cond, Mux, Halt) leads to the following linear representation: Start LINK 1,1 Activ1 LINK 2,1 Sync1 LINK 2,1 Activ2 LINK 12,1 Activ3 LINK 12,1 Cond LINK 2,1 Activ4 LINK 13,1 Activ5 LINK 12,1 , LINK 2,2 Mux LINK 42,1 Activ6 LINK 13,1 , LINK 2,1 Sync2 LINK 2,1 Activ7 LINK 2,1 Halt.

Alternatively, the permutation (Halt, Activ7, Sync2, Activ6, Activ3, Mux, Activ5, Activ4, Cond, Activ2, Sync1, Activ1, Start) leads to the following linear representation: Halt LINK 1,2 Activ7 LINK 1,2 Sync2 LINK 1,2 Activ6 LINK 1,2 Activ3 LINK −2 1,3 Mux −1 −5 Activ4 LINK , LINK Cond LINK Activ2 LINK , LINK LINK 2,2 Activ5 LINK −1 1,2 1,2 1,2 1,2 1,3 1,2 Sync1 LINK 1,2 Activ1 LINK 1,1 Start.

However, the former linear representation appears to be more intuitive, since it provides a way to sequence symbols that coincides with one of the possible execution orders of the activities instantiated in this diagram. Thus, the semantics of a visual sentence can drive the construction of one of its linear representations. 3. THE FRAMEWORK FOR THE SPECIFICATION AND IMPLEMENTATION OF VISUAL NOTATIONS In this section, we illustrate the proposed framework by presenting its three main parts: the process for modeling and implementing visual notations, the formalism of eXtended Positional Grammars, and the XpLR technique for parsing visual notations modeled through XPGs. 3.1 The Modeling and Implementation Process As noted previously, in the context of software development our framework is mainly intended for software methodology users. Such professional figures can accomplish their work and duties in several different ways, depending on the type and the size of the software-related industrial context in which s/he is employed. For instance, in the context of CASE tool construction companies, a professional can use our framework to sketch and rapidly prototype software development notations, processes, and so on. Large software manufacturing industries might employ dedicated professionals who are responsible for analyzing and possibly modifying the software development process, its underlying notations and tools. Smaller software companies, often cannot afford a dedicated employee for these kind of tasks. However, in these smaller companies, ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

12

•

December 8, 2004

22:0


Fig. 7. The process underlying the framework for modeling and implementing visual languages.

we often found software engineers spending part of their time working on similar tasks in simpler software development processes. In all cases, in order to proficiently use our framework the methodologist needs to have some compilerconstruction skills, such as those usually acquired during a one-term graduate level compiler-construction course. The design of a software development process requires the specification of its phases, and for each phase, the profile of the professional to accomplish it (software engineer, programmer, etc.), the notations, and possibly the tools s/he should use. Our framework focuses on the last two aspects, that is, the modeling of visual notations and the generation of CASE tools supporting them, providing the means for them to cooperate with existing tools. In particular, the methodologist can accomplish these tasks by following the process shown in Figure 7. First of all, in the Visual Notation Design phase the methodologist needs to derive the Icon Dictionary of the visual notation being designed. After analyzing the requirements, the methodologist tries to maximize the reuse of existing visual notation specifications. For each notation that has to be constructed or extended, the methodologist needs to produce a final Icon Dictionary. The Icon Dictionary contains the set of icons and visual sentences characterizing the notation, and their semantic interpretation. As an example, Figure 8 shows a portion of the Icon Dictionary for statecharts. The methodologist also needs to provide a visual editor to allow a target user (a software engineer and/or other professional involved in the target software design process) to perform usability tests on the Icon Dictionary. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

13

Fig. 8. A portion of the Icon Dictionary for statechart language.

The whole Visual Notation Design phase is iterative. This means that if tests reveal usage impediments, the methodologist might decide to review the Icon Dictionary and to repeat usability tests on the new version. During the Visual Notation Syntactic Modeling phase, the methodologist refines the specification of the visual symbols according to the attribute-based representation approach. In particular, s/he specifies syntactic attributes, and a first set of semantic attributes. Then, s/he analyzes the Icon Dictionary and specifies the XPG grammar modeling the sentences of the visual notation, possibly reusing previous specifications with similar syntactic structures. The final XPG specification is used to automatically generate a prototype of a graphical visual editor with parsing functionalities for the designed notation. The methodologist tests this prototype by analyzing both the correctness of the parser and usage feedbacks from target users. In fact, while in the previous phase, the methodologist evaluated usability in terms of symbol and sentence intuitiveness; at this point, s/he is also concerned with the difficulties that users encounter in composing syntactically correct visual sentences. The methodologist might decide to review visual sentences causing frequent syntactic errors for their formulation. The review might start from the Visual Notation Design phase, or might simply focus on the XPG specification. In the last case, the methodologist might refine the syntax specification in an incremental way. During the Semantics Implementation and Code Generation phase, the methodologist analyzes the semantic aspects of the modeled notation and specifies additional semantic attributes for its vsymbols. Such attributes will be used when interpreting a successfully parsed visual sentence before translating it into a sentence of a different notation (textual or visual), as prescribed in the given software development process. The specification produced in this phase is used to automatically generate a visual programming environment, including a visual editor and a compiler for the visual notation which is submitted to the target user for a final comprehensive testing phase. Possible usability or correctness remarks raised at this time might require a review process starting from any of the previous phases. Nevertheless, a sound design practice should prevent the necessity to start the review from initial phases. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

14

•

December 8, 2004

22:0


3.2 Extended Positional Grammars Let us now describe the XPG grammar formalism that is used in our framework to model the syntax of the notations to be designed. Extended Positional Grammars are a direct extension of Positional Grammars (PGs) [Costagliola et al. 1997]. The latter have been successfully used to model and implement several important visual languages, including languages from the classes Iconic, Plex, and Box. However, PGs were not suitable to model some critical visual languages such as those belonging to the class Graph, since it does not provide mechanisms to cope with context, which are necessary for modeling many of the notations in this class. This was a considerable limitation, preventing, in part, the application of PGs to some important application fields, such as software engineering. In fact, most of the visual notations used in software design methodologies are based on the class Graph. Examples are class diagrams [Rumbaugh et al. 1998], Petri nets, statechart diagrams, activity diagrams, and so on. XPG overcomes this limitation, also thanks to the introduction of particular conflict-handling techniques within the parser, as described in subsection 3.3. In fact, as opposed to grammars for string languages, grammar formalisms modeling visual sentences are more likely to run into ambiguities. Without ad hoc conflict-handling techniques such grammar formalisms could not be effectively used for modeling many practical visual languages. In order to avoid conflicts, the designer would have to produce complex grammars, even for simple visual notations. There has been a previous attempt to extend the pLR parsing technique with mechanisms for dealing with noncontext-free languages [Costagliola et al. 1995]. In particular, the derivation mechanism of positional grammars was modified in order to enable the multiple visits of the same instance of a nonterminal during the parsing. However, this approach complicated the specification of a visual notation, since it required an additional specification of constraints over some nonterminal symbols which also entailed the modification of the parser. On the contrary, XPGs provides a natural extension of PGs that simplifies the grammar specification task, while enhancing the expressive power. An Extended Positional Grammar is the pair (G, PE), where PE is a positional evaluator, and G is a particular type of context-free1 string attributed grammar (N , T ∪ POS, S, P ) where: — N is a finite nonempty set of nonterminal vsymbols; — T is a finite nonempty set of terminal vsymbols, with N ∩ T = ∅; — POS is a finite set of binary relation identifiers, with POS ∩ N = ∅ and POS ∩ T = ∅; — S ∈ N denotes the starting vsymbol; — P is a finite nonempty set of productions having the following format: A → x1 R1 x2 R2 . . . xm−1 Rm−1 xm , , , 1 Here,

“context-free” means that the grammar productions are in “context-free” format and does not refer to the computational power of the formalism.

ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

15

where A is a nonterminal vsymbol, x1 R1 x2 R2 . . . xm−1 Rm−1 xm is a linear representation with respect to POS, where each xi is a vsymbol in N ∪ T, and each R j is partitioned in two sub-sequences hk+1 with 1 ≤ k ≤ n. REL1h1 , . . . , RELkhk , RELk+1 , . . . , RELnhn The relation identifiers in the first subsequence of an R j are called driver relations, whereas the ones in the second subsequence are called tester relations. Driver relations are used during syntax analysis to determine the next vsymbol to be scanned, whereas tester relations are used to check whether the last scanned vsymbol (terminal or nonterminal) is properly related to previously scanned vsymbols. Without loss of generality we assume that there are no useless vsymbols, and no unit and empty productions [Aho et al. 1987]. is a set of rules used to synthesize the values of the syntactic attributes of A from those of x1 , x2 , . . . , xm ; is a set of triples (T j , Cond j , j ) j =1,..,t , t ≥0, used to dynamically insert new terminal vsymbols in the input visual sentence during the parsing process. In particular, — T j is a terminal vsymbol to be inserted in the input visual sentence; —Cond j is a precondition to be verified in order to insert T j ; — j is the rule used to compute the values of the syntactic attributes of T j from those of x1 , . . . , xm . As a consequence, if for each production A → x1 . . . xm , , of a grammar G, the number of triples in whose conditions can simultaneously evaluate to true is less than m − 1, then the convergence of the parsing algorithm based on G is guaranteed. Informally, a positional evaluator PE is a materialization function which transforms a linear representation into the corresponding visual sentence in the attribute-based representation and/or graphical representation. In the following we characterize the languages described by an extended positional grammar XPG = ((N , T ∪ POS, S, P ), PE). We write α ⇐ β, and say that β reduces to α in one step, if there exist δ, γ , A, η such that (1) A → η, , is a production in P , (2) β = δηγ , (3) α = δ A πγ , where A is a vsymbol whose attributes are set according to the rule , and π results from the application of . i

We also write α ⇐ β to indicate that the reduction has been achieved by ∗ applying production i. Moreover, we write α ⇐ β and say that β reduces to α, if there exist α0 , α1 , . . . , αm (m ≥ 0) such that α = α0 ⇐ α1 ⇐ . . . ⇐ αm = β. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

16

•

December 8, 2004

22:0


The sequence αm , αm−1 , . . . , α0 is called a derivation of α from β. ∗

— a positional sentential form from S is a string β such that S ⇐ β; — a positional sentence from S is a string β containing no nonterminals and ∗ such that S ⇐ β; — a visual sentential form (visual sentence) from S is the result of evaluating a positional sentential form (positional sentence) from S through PE. The language described by an XPG, L(XPG), is the set of the visual sentences from the starting vsymbol S of XPG. Without loss of generality, let us assume that XPG has no empty productions. Given the two pairs (x, k) and ( y, j ), where x ∈ N ∪ T , y ∈ T , k is a syntactic attribute of x, and j is a syntactic attribute of y, we say that ( y, j ) is reachable from (x, k) if and only if one of the following situations occurs: (1) x = y; (2) there exists a production x → x1 R1 x2 . . . xi . . . Rm−1 xm , , in P such that attribute k of x is synthesized from attribute h of x1 by means of , and ( y, j ) is reachable from (x1 , h). If ( y, j ) is reachable from (x, k), we also say that y is reachable from x. The new features of Extended Positional Grammars, as opposed to Positional Grammars, include the use of multiple driver relations and the introduction of rules to dynamically modify the input visual sentence. It is easy to show that these features considerably improve the expressive power of positional grammars. In the following we show an example of XPG grammar modeling the state transition diagram language. A more complex example of XPG modeling is provided in Appendix section, where we specify the complete XPG for the UML statechart diagrams language. Example 3.1 (XPG Modeling of State Transition Diagrams). The XPG for State Transition Diagrams is characterized as follows. Let STD be the name of the grammar, the set of nonterminals is N = {Graph, Node}, where each vsymbol has one attaching region as syntactic attribute, and Graph is the starting vsymbol of STD, that is, S = Graph. The set of terminals is T = {NODEI, NODEIF, NODEF, NODEG, EDGE, PLACEHOLD}. The terminal vsymbols NODEI, NODEIF, NODEF, NODEG have one attaching region as a syntactic attribute. They represent, the initial, the initial and final, the final, and the generic node, respectively, of a state transition diagram. The terminal vsymbol EDGE has two attaching points as syntactic attributes corresponding to the start and end points of the edge. Finally, PLACEHOLD is a fictitious terminal vsymbol to be dynamically inserted in the input sentence during the parsing process. It has one attaching region as syntactic attribute. The vsymbols are graphically depicted in Figure 9. Here, each attaching region is represented by a dashed line for the nonterminals, and by a bold line for the terminals, and is identified by the number 1, whereas the two attaching points of EDGE are represented by bullets and are each identified by a number. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

17

Fig. 9. The vsymbols for the grammar STD.

In the following, the notation Vsymi denotes the attaching point i of the vsymbol Vsym. The set of relations is given by P O S = {LINK h,k , any}, where the relation identifier any denotes a relation that is always satisfied between any pair of vsymbols, whereas LINK h,k is defined as in Section 2.3, and will be denoted as h k to simplify the notation. Moreover, we use the notation h k when describing the absence of a connection between two attaching areas h and k. In Figure 10, we provide the set of productions for describing state transition diagrams. In addition to the textual version of the productions, on the righthand side of the figure, we provide a user-friendly visual version, which helps the language designers model and reason on the visual notations specified. In particular, in the visual format, we replace terminal and nonterminal vsymbols with their iconic representations as given in Figure 9, and arrange them on a two-dimensional space in a way that satisfies the grammar relations. Moreover, icons for vsymbols on the left-hand side are placed in a rectangular box together with the associated rules. A similar structure is used for the vsymbols introduced through rules, with the only difference that the box includes a third area containing the associated pre-condition. Also this box is put on the left-hand side, provided that the production has a rule. Notice that Graph1 = Graph 1 − EDGE1 indicates set difference and is to be interpreted as follows: the attaching area 1 of Graph has to be connected to whatever is attached to the attaching area 1 of Graph , except for the attaching point 1 of EDGE. Moreover the notation |Node1 | indicates the number of connections to the attaching area 1 of Node. The superscripts are used to distinguish different occurrences of the same vsymbol. According to these rules, a state transition diagram is described by a graph defined as — an initial node (production 1), or as — an initial-final node (production 2) or, recursively, as — a graph connected to a node through an outgoing (production 3) or incoming (production 5) edge, or as — a graph with a loop edge (production 4). A node can be either a generic node (production 7) or a final node (production 8). The need for productions 6 and 9 will be clarified in the following example. Suppose we have to model the help module of a software package. Figure 11 shows the state transition diagram describing the behavior of this help module. When the user enters the software package, this goes into state 1. At this point, a window pops up, allowing the user access to the help module by clicking on the Show Tips option, or refuse help support and go directly to the package ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

18

•

December 8, 2004

22:0


Fig. 10. Textual and visual versions of STD productions.

functions (state 3) by clicking on the No Tips option. If s/he chooses the first option, the package enters state 2, where a help page is displayed. In this state, the user can decide to exit tips and access other package functions (state 3), or to show the next help page and to remain in state 2. Figures 12 (a–h) show the steps to reduce the state transition diagram of this help module through the extended positional grammar STD shown in Figure 11. In particular, dashed ovals indicate the handles to be reduced, and their labels indicate the productions to be used. The reduction process starts by applying production 1 to the initial state transition diagram. This causes the terminal NODEI, representing state 1, to be reduced to the nonterminal Graph. Due to the rule of production 1, Graph inherits all the connections of NODEI. Similarly, the application of production 7 replaces the unique NODEG of Figure 12(a) with the nonterminal Node. Figure 12(b) shows the resulting visual sentential form, and highlights the handle for the application ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

19

Fig. 11. The state transition diagram for a help module.

Fig. 12. The reduction process for a state transition diagram.

of production 3. The vsymbols Graph, EDGE, and Node are then reduced to the new nonterminal Graph. Due to the rule of production 3, the new Graph is connected to all the remaining edges attached to the old Graph. Moreover, due to the rule, since |Node| = 4 > 1, a new node PLACEHOLD is inserted in the input, and it is connected to all the remaining edges attached to the old Node. Figure 12(c) shows the resulting visual sentential form. After the application of productions 8 and 3, the visual sentential form reduces to the one shown in Figure 12(e). Then, production 6 reduces the nonterminals, Graph and PLACEHOLD, to a new nonterminal, Graph. By applying the rule of production 6, the new Graph inherits all the connections to PLACEHOLD (see Figure 12(f)). The subsequent application of productions 9, 4 and 3 reduces the original state transition diagram to the starting vsymbol in Figure 12(h), confirming that the visual sentence associated to the initial state transition diagram belongs to the visual language L(STD). 3.3 The XpLR Parser We now describe the XpLR parsing technique that is used in our framework to generate parsers for the visual notations modeled through XPGs. The XpLR parsing technique extends the pLR technique presented in Costagliola et al. [1997]. It is a technique for implementing visual systems based upon XPGs and LR parsing. As in pLR parsing, an XpLR parser scans the input in a nonsequential way, driven by the relations used in the grammar. In particular, ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

20

•

December 8, 2004

22:0


Fig. 13. The architecture of an XpLR parser.

the XpLR technique differs from the pLR one in that it handles the rules, and provides algorithms to eliminate conflicts arising during the construction of the parsing table. The components of an XpLR parser are shown in Figure 13 and are detailed in the following sections of the article. 3.3.1 The Input. The input to the parser is a dictionary, named D p , storing the attribute-based representation of a picture as produced by the visual editor. No parsing order is defined on the graphical objects in the dictionary. The parser retrieves the objects in the dictionary through a find operation, driven by the relations in the grammar. The parser implicitly builds and parses a linear representation from the input attribute-based representation. If the input picture contains explicit relations, that is, the relations have a graphical representation, its attribute-based representation is augmented with an array, COUNTER, containing an entry for each explicit relation. The entry, COUNTER(r) for an explicit relation labeled r with degree n contains the value n − 1. This value indicates the number of binary relations describing r in any relative representation of the picture. During the parsing phase, all the visited tokens, and the traversed explicit binary relations, are marked in order to guarantee that each object and each explicit relation be considered once at most. The marking of an explicit binary relation REL labeled r is done by decreasing the entry COUNTER(r) by 1. The 0-entry of the dictionary always refers to the end-of-input symbol EOI. Similar to the usual end-of-string marker, the end-of-input symbol EOI is returned to the parser, if and only if the input has been completely visited, that is, all the input tokens have been parsed, and all the explicit relations have been traversed. These conditions are signaled by having all the tokens marked and COUNTER(r) = 0 for each explicit relation r, respectively. 3.3.2 The Stack. An instance of the stack has the general format s0 X 1 s1 X 2 s2 . . . X m sm , where sm is the stack top, X i is a grammar vsymbol, and si is a generic state of the parsing table. The parsing algorithm uses the state on the top of the stack, and the vsymbol currently under examination, to access a specific entry of the parsing table in order to decide the next action to execute. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

21

Fig. 14. An XpLR(0) parsing table.

3.3.3 The XpLR Parsing Table. An XpLR parsing table is composed of a set of rows and is divided into three main sections: action, goto, and next. Each row is composed of an ordered set of one or more subrows, each corresponding to a parser state. The action and goto sections are similar to the ones used in LR parsing tables for string languages [Aho et al. 1987], whereas the next section is used by the parser to select the next vsymbol to be processed. An entry next[k] for a state k contains a pair, (Rdriver , x), which drives the parser in selecting the next vsymbol y that is reachable from x, by using the sequence of driver relations Rdriver . Figure 14 shows the parsing table for the grammar STD given in Example 3.1. An action entry has one of the following four types of actions: i (1) a sequence A1 , . . . , An where each Ai (i > 0) has the format “Rtester : shift i i state ”, and Rtester is a possibly empty sequence of tester relations. More1 n over, all the relations Rtester , . . . , Rtester are mutually exclusive. As an example, the entry (1.1, EDGE) in Figure 14 contains the sequence 1 2: sh5, 1 2: sh6; (2) reduce by a grammar production (i) A → β, shown in the table as ri; (3) accept; (4) error shown as an empty entry.

A goto entry contains a sequence B1 , . . . , Bn , where each Bi (i > 0) has the i i : statei ”, Rtester is a possibly empty sequence of tester relations. format “Rtester 1 n Moreover, all the relations Rtester , . . . , Rtester are mutually exclusive. A shift or goto action is executed only if all the relations in the corresponding Rtester are true, or if Rtester is empty. As an example, let us consider the XpLR(0) parsing table in Figure 14. If the current state corresponds to subrow 1.2, and the vsymbol currently scanned is EDGE, then the parser executes the conditioned action (1 1: sh6), that is, if the relation 1 1 does not hold between EDGE and the first vsymbol below the stack top, then the parser shifts EDGE and goes ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

22

•

December 8, 2004

22:0


Fig. 15. A graphical representation of state 1 of the parsing table in Figure 14.

to state 6. Once in state 6, the parser launches a query on the input, based on the entry next[6] = (1 1, Node). The query will search the input for a terminal vsymbol v, derivable from Node, such that v is in relation 1 1 with the vsymbol EDGE scanned in the previous step. The entry (start, S) in the column next, where S is the starting vsymbol, is a special pair and it is used at the beginning of the parsing process to retrieve the first vsymbol to be parsed. This vsymbol depends on the nature of the language. As an example, in the parsing table of Figure 14, (start, Graph) searches the input for the initial node of the state transition diagram. The entry (end, EOI) is another special pair, and it is used to check whether the whole input sentence has been parsed. If all the vsymbols have been analyzed and all the explicit relations have been considered, then the query returns the end-of-input marker EOI. When a query is launched on the pair (any, PLACEHOLD), the parser will search the input for a reintroduced vsymbol PLACEHOLD. Such vsymbol could not be related to the vsymbols previously analyzed. The XpLR parsing table has a slightly different structure with respect to the pLR parsing table. In particular, each state is now possibly partitioned into a sequence of substates: in our example state 1 is partitioned into four ordered substates. Thus, when the parser is in state 1, it has recognized a nonterminal Graph and it will proceed parsing the visual sentence by looking for: (1) an outgoing edge or a self-edge (corresponding to state 1.1) of Graph as shown in Figures 15(a)-(b); or (2) an incoming edge of Graph (state 1.2) as shown in Figure 15(c); or (3) a reintroduced vsymbol PLACEHOLD (state 1.3) as shown in Figure 15(d); or (4) the end-of-input marker EOI (state 1.4). Consequently, the order of the substates in a state depends on the syntax of the language to be parsed. In general, the language implementer may need to modify the order of the substates accordingly. Obviously, partitioning a state in a sequence of ordered substates prevents all the conflicts caused by the introduction of rules in the grammars, and some shift-reduce and reduce-reduce conflicts that could occur when building the XpLR parsing table. Notice that the sequence order affects the recognized language. To this end, we can adopt heuristics to control this phenomenon at grammar specification time. In particular, a heuristic prescribes that when partitioning a state one considers shift actions before reduce one. Shift actions on reintroduced vsymbols should be considered after shift actions on the remaining vsymbols. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

23

The algorithms for the construction of parsing tables are given in Appendix section. A conflict manifests itself in a parsing table when multiple actions, with tester relations not mutually exclusive, are contained in a single entry of the action or goto parts. A parsing table may present shift-shift, gotogoto, and positional conflicts. A shift-shift conflict occurs whenever multiple and not mutually exclusive conditioned shift actions are present in a single entry of the action part. Analogously, a goto-goto conflict occurs whenever multiple and not mutually exclusive conditioned goto actions appear in a single entry of the goto part. A positional conflict occurs whenever multiple values (REL, x) are present in a single entry of the next column, with the same relation REL. An extended positional grammar for which it is possible to construct an XpLR(0) parsing table without conflicts is said to be an XpLR grammar. Ambiguities in non-XpLR grammars are handled by adding heuristics. Shift-shift and goto-goto conflicts are solved by ordering the conditioned actions present in the same entry. The order is the same used to partition the states into a sequence of substates. The parser tests the action conditions sequentially and executes the first action whose condition is verified. Analogously, positional conflicts are solved by ordering the values (REL, x) in the same entry of the column next. The parser invokes the function Fetch Vsymbol on each value of the sequence, until a new vsymbol is returned. 3.3.4 The XpLR Parsing Program. In order to illustrate the XpLR parsing program, we define the two functions Fetch Vsymbol and Test. The former uses the stack and the input as global data structures and takes its arguments from the column next of the parsing table. The latter is used to validate the tester relations between vsymbols. It takes as input an action condition from the action or goto part of the parsing table and returns a boolean value. Function Fetch Vsymbol(NEXT) begin case NEXT of NEXT = (start, S): return the row index in D p to the first object to parse NEXT = (end, EOI): if all the objects have been marked as visited and COUNTER(r) = 0 for each explicit relation r then return the row index 0 in D p pointing to the end-of-input symbol EOI else return null; h NEXT = (Rdriver , x), where Rdriver = REL1 1 , . . . , RELnhn and hi each RELi acts on a syntactic attribute ki of x for i = 1 to n let z i be the (hi )-th object below the stack top let next seti = {b | b is in D p , it is not marked as visited, it has an attribute j such that (b, j) is reachable from (x, ki ), z i RELi b holds, and the relation RELi acts on a syntactic attribute of z i and the syntactic attribute j of b, respectively } if ∩i=1...n next seti contains exactly one object b then for each explicit relation RELi in Rdriver do decrease by 1 the entry in the array COUNTER corresponding to the explicit relation z i RELi b ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

24

•

December 8, 2004

22:0


mark the corresponding entry in D p as visited return the row index of b in D p else if ∩i=1...n next seti contains more than one object b emit “run-time conflict” and exit else return null; NEXT = null: return null; endcase end

Let us describe how the function works on the table in Figure 14. In particular, the relations Rdriver in the next column are as follows: — the special relation start: in this case Fetch Vsymbol returns the index in D p of the first vsymbol of the visual sentence to parse; — the special relation end: in this case Fetch Vsymbol returns the index in D p of the EOI vsymbol only if all the vsymbols and all the explicit relations of the visual sentence have been visited; — a relation h k, with z h j b holding between the vsymbol z on the stack top, and exactly one nonvisited vsymbol b in D p with syntactic attribute j such that (b, j ) is reachable by (x, k). In other words, when NEXT = (h k, x): (1) if x is a terminal vsymbol, Fetch Vsymbol returns the index in D p of a nonvisited vsymbol whose name is x and whose k-th syntactic attribute is linked to the h-th syntactic attribute of z. (2) if x is a nonterminal vsymbol, Fetch Vsymbol returns the index in D p of a nonvisited terminal vsymbol b whose j -th syntactic attribute is linked to the h-th syntactic attribute of z. The couples (x, k) and (b, j ) are such that b is a terminal that begins a positional sentence derived from x, and the k-th syntactic attribute of x is synthesized from j by successively applying the rules in the derivation; or — a relation any: in this case Fetch Vsymbol(any, PLACEHOLD) returns the index in D p of an unmarked terminal vsymbol PLACEHOLD. If no object is found then Fetch Vsymbol returns null. On the other hand, if more than one vsymbol is found, then the parser cannot proceed because it cannot decide which token to analyze deterministically. As a consequence, the function issues a run-time conflict message and stops the execution of the parser. The occurrence of this type of conflict might prevent the recognition of syntactically correct input visual sentences. At the end of this section, we analyze the run-time conflicts and give some heuristics to solve such problem. The function Test that follows verifies that the grammar vsymbol to be pushed on the stack top is properly related to a grammar vsymbol already in the stack. Function T est(COND) let COND = (RELi , x) where x is either a terminal or a non-terminal let z be the i-th object below the stack top if z REL x holds then begin if REL is an explicit relation then decrease by 1 the entry in the array COUNTER corresponding to the ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

25

explicit relation z REL b return true end else return false

In the following, we give the complete XpLR(0) parsing algorithm. Algorithm 3.2. The XpLR(0) Parsing Algorithm. Input: A visual sentence in attribute-based representation and an XpLR(0) parsing table. Output: A bottom-up analysis of the visual sentence if this is syntactically correct, an error message otherwise. Method: Start with the state 0 on the top of the stack. repeat forever let s be the state on the stack top if there exists at least a substate sb of s such that Fetch Vsymbol(next[sb]) is not null then let f sb be the first of such substates in s set s = f sb set ip = F etch V s ymbol (next[ f sb]) let b the grammar vsymbol pointed by ip if action[s, b] = “accept” then “success” and exit; if action[s, b] is a non empty sequence seq of conditioned shifts of type “Rt : shift s ” then while seq is not empty do extract the current first element “Rt : shift s ” from seq if Rt is empty or Test(RELh , b) is true for each RELh ∈ Rt then push b and then s on the stack and exit from the while loop; endwhile if no element has been pushed on the stack then emit “syntax error” and exit; else emit “syntax error” and exit; else if there exists at least a substate sb of s such that next[sb] is empty then let f sb be the first of such substates in s set s = f sb let b a terminal vsymbol if action[s, b] = reduce A → x1 R1 x2 R2 . . . Rm−1 xm , , then compute the syntactic attributes of the vsymbol A according to the synthesis rule , insert vsymbols according to rule , if present, and pop 2 ∗ m vsymbols from the stack let s be the new state on the stack top if goto[s , A] is a non empty sequence seq of conditioned gotos of type “Rt : s” then while seq is not empty do extract the current first element “Rt : s

” from seq if Rt is empty or Test(RELh , A) is true for each RELh ∈ Rt then push A and then s

on the stack output the production A → x1 R1 x2 R2 . . . Rm−1 xm , , exit endwhile if no element has been pushed on the stack then emit “syntax error” and exit; endif endif ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

26

•

December 8, 2004

22:0


else emit “syntax error” and exit; else emit “syntax error” and exit; endrepeat

At each step, the XpLR parsing program checks the entries next[sb] of the parsing table corresponding to the substates of state s on the top of the stack. If at least one of Fetch Vsymbol(next[sb]) is not null, then the pointer ip, used to scan the input, is updated to point to the next terminal b =Fetch Vsymbol(next[sb]). In this case, either the input picture is accepted (action[s, b] = “acc”) with b being the end-of-input marker EOI, or b is shifted on the stack top (action[s, b] = “R: shift s ”). Whenever a shift action is required and the action condition R is not empty, then each relation RELihi in R is tested between the (hi )-th object below the stack top and the object b to be shifted. Otherwise, if Fetch Vsymbol(next[sb]) is null for a substate sb of state s, then a reduce action is required. In this case, the pointer ip is not updated and it points to the last terminal b shifted on the stack top. The reduction action[s, b] = “reduce A → x1 R1 x2 R2 . . . Rm−1 xm , , ” is accomplished by popping 2 ∗ m elements out of the stack, calculating the syntactic attributes of A as specified by , inserting vsymbols according to the rule, and pushing A on the stack top. If s is the state on the stack top after popping the 2 ∗ m elements, then the next state s

of the parser is given by the entry goto[s , A]. Also in this case, the goto action may be triggered by an action condition to be verified between objects below the stack top and the object A. It is easy to reproduce the reduction process in Figure 12 by applying Algorithm 3.2 on the XpLR(0) parsing table in Figure 14. Let us now analyze the time complexity to parse a visual sentence containing n vsymbols, and with m vsymbols inserted during the parsing. For a fixed grammar, the time complexity is O((n + m)(n ∗ tq ∗ tr ∗ t )), where tq is the time required to perform the function Fetch Vsymbol (on next[s]), tr is the time to test each relation, and t is the time to synthesize each syntactic attribute. The parameters m, tq , tr and t may vary from a constant to O(n). Thus, the time complexity of the XpLR parser is polynomial. 3.3.5 Handling Run-Time Conflicts. The absence of conflicts in an XpLR parsing table for a language L does not guarantee that any visual sentence in L is accepted by the corresponding XpLR parser. In fact, the parser might still run into conflicts, called run-time conflicts, while parsing a vsentence. Let be a visual sentence in L(XPG), where XPG = (G, P E), generated by applying PE to a positional sentence s ∈ L(G). At each step of the parsing process, the function Fetch Vsymbol takes as argument the pair (RELihi , x) from the column next of the parsing table to inquire about in the input dictionary. For the parsing program to execute correctly in a deterministic way, there must be a single terminal xi , reachable from x, that is detected and returned by Fetch Vsymbol. However, in the case, where Fetch Vsymbol detects more than one terminal on the pair (RELihi , x), a “run-time conflict” message is returned, and the parsing program halts. As an example, let us consider the sentential form in Figure 16 obtained during the reduction process described in Example 3.1 (see Figure 12(e)). The parser produces this form by reaching state 1.3. In the next step, the execution ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

27

Fig. 16. A visual sentential form.

of Fetch Vsymbol on the pair (any, PLACEHOLD) retrieves two occurrences of the terminals PLACEHOLD and, as a consequence, detects a run-time conflict. It is obvious that grammars that exhibit run-time conflicts are undesirable because they are not suitable for XpLR parsing. In Costagliola et al. [2001], an algorithm has been introduced to statically verify, during the construction of the parsing table, whether or not a positional grammar would produce run-time conflicts. (Such an algorithm can also be applied to XpLR grammars.) In particular, whenever the algorithm detects a conflict, it returns the set of items causing the conflict. Therefore, this technique allows a designer to have feedback in the early phases of the syntax definition of the visual language and gives him/her information on how and where to intervene in order to solve the conflict. As a matter of fact, whenever the algorithm detects a run-time conflict, the language designer analyzes the relation R causing the conflict and verifies if the scanning order of the vsymbols producing the conflict, that is, belonging to the set detected by Fetch Vsymbol(NEXT), is relevant or not to the correct parsing of the sentence. In the case, where it is not relevant, any of the detected vsymbols can be chosen as the next input. As an example, the relation any used in the STD grammar is such that every PLACEHOLD can be chosen as the next vsymbol to be parsed. In general, when the algorithm statically detects a “nonrelevant run-time conflict” in a particular set of items, the language designer must explicitly tag the involved relation in the XPG with a ‘*’. In order to support such an approach, the function Fetch Vsymbol must be modified to take into account the tagged relations. The modification consists of the addition of the following new case: h

∗ ∗ NEXT= (Rdriver , x), where Rdriver = REL1 1 , . . . , RELnhn ∗ and each RELi i acts on a syntactic attribute ki of x let z i be the (hi )-th object below the stack top for i = 1 to n do let next seti = { b | b is in D p , it is non marked as visited, it has an attribute j such that (b, j ) is reachable from (x, ki ), z i RELi b holds, and the relation RELi acts on a syntactic attribute of z i and the syntactic attribute j of b, respectively } if ∩i=1...n next seti is non-empty then randomly select an object b from ∩i=1...n next seti for each RELi in Rdriver that is an explicit relation do decrease by 1 the entry in the array COUNTER corresponding to the explicit relation z i RELi b mark the corresponding entry in D p as visited return the row index of b in D p else return null; h


P1: IAZ ACMJ018-02

ACM-TRANSACTION

28

•

December 8, 2004

22:0


Fig. 17. The VLDesk system.

Although the relations used to model many popular visual languages are applied in contexts so that the relations are tagged, this technique cannot always be applied. In these cases, the language designer must modify the grammar in order to solve the conflict analogously to what would happen when using traditional compiler-compiler tools such as YACC [Johnson 1978]. It is worthwhile to notice that the run-time conflicts problem is similar to that of confluence and termination of graph transformation systems [Heckel et al. 2002]. In both cases, the solution is a static analysis to detect the rules that can potentially lead to a nondeterministic behavior. In particular, in Heckel et al. [2002], the critical pair analysis has been applied to graph transformation systems. 4. USING THE FRAMEWORK FOR CASE TOOLS GENERATION In this section, we briefly summarize the Visual Language Desk (VLDesk) [Costagliola et al. 2003], a system providing automated support for the modeling process of the proposed framework. The system implements the concept of meta-CASE [Alderson 1991], since the visual programming environments it generates can be used as CASE tools for the modeled visual notations. In fact, VLDesk allows us to choose the visual notations we need, letting us specify how to combine them to generate a customized software development process supported by CASE tools. Changes to the visual notations or to the development process can be effectively executed within VLDesk by acting on the XPG model associated with the notations. VLDesk provides a “desk” where a methodologist can find an integrated set of tools supporting the whole process for modeling and implementing visual notations. The architecture of VLDesk is shown in Figure 17. Its main components are the Symbol Editor, the Grammar Editor, the Language Inspector and the Visual Programming Environment Generator. The Symbol Editor supports the Visual Notation Design phase of the modeling process (see Section 3.1). In particular, it assists the methodologist in the complete definition of vsymbols, enabling him/her to draw their physical aspect, together with their syntactic attributes, and possible visual or textual annotations attachable to the vsymbols, in order to place them in a hierarchy of visual ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

29

Fig. 18. Definition of a statechart state with the Symbol Editor.

notations. Moreover, in this phase, the Symbol Editor provides visual/textual editing areas for specifying semantic interpretations of vsymbols that it will store in the Icon Dictionary. Once all the vsymbols have been specified, the VLDesk generates a visual editor supporting the freehand editing of visual sentences using the defined vsymbols, but it does not provide interpretation functionalities yet. The methodologist can use the visual editor to complete the Icon Dictionary and to validate the look and feel of the designed visual notation, possibly with the assistance of the target user (software engineers, in our case). Figure 18 shows the definition of the vsymbol State in the statechart diagrams language using the VLDesk Symbol Editor. The methodologist may recall the appropriate palette to define the physical aspect of the vsymbol (I palette button), and attaching/containment areas on it (II or III palette, respectively). As an example, the attaching area palette highlighted in Figure 18 allows a methodologist to define as attaching areas: points, lines, curves, circles, squares, circumferences, perimeters, and so forth. Once completely defined, the vsymbol State is inserted into a palette of terminals. Moreover, by clicking on the language annotation palette, it is possible to annotate a vsymbol with any of the already defined visual notations or a textual language. Finally, the methodologist uses the Symbol Editor during the Visual Notation Syntactic Modeling phase of the modeling process to refine the specification of the visual symbols, by specifying additional syntactic attributes, and a first set of semantic attributes. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

30

•

December 8, 2004

22:0


Fig. 19. The VLDesk Textual Grammar Editor.

The Grammar Editor supports the methodologist during the Visual Notation Syntactic Modeling phase, by providing tools to assist him/her in the construction of an XPG grammar modeling the sentences of the visual notation. Specifically, the methodologist can invoke either a visual or a textual grammar editor to enter an XPG. The former provides visual aids to simplify the grammar specification. However, we have observed that users often prefer the text editor once they gain familiarity with the XPG notation. The methodologist also uses the Grammar Editor in the Semantics Implementation and Code Generation phase, by writing semantic routines and associating them to the productions of the XPG grammar. Semantic routines are small pieces of code written in C++ that accomplish semantic checks and translation tasks, and are each executed when the parser reduces the associated XPG production. Additionally, each semantic routine can contribute to the construction of a syntax structure summarizing the information of the input visual sentence, which can be used to statically verify particular properties of the visual notation. As an example, we can verify the behavior of reactive systems modeled through statecharts. Finally, semantic routines can be used to provide a dynamic behavior to the input sentences, such as, coloring, moving and resizing symbols, and so on. Figure 19 shows the Grammar Editor main window. The palette of terminals includes all the vsymbols that have been specified with the Symbol Editor. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

31

Fig. 20. The VLDesk Visual Grammar Editor.

The Viewer window is the textual grammar editor that allows modifying or directly editing the XPG grammar together with the semantic rules in YACC format. The figure also shows the Language Inspector window which provides direct support for handling the hierarchical combination of visual notations. It allows the methodologist to easily navigate through the hierarchy of visual notations in order to check their specifications. In Figure 19, the Language Inspector window shows that the STATECHARTS notation has a vsymbol that is annotated with the notation Classes, which has, in turn, a vsymbol annotated with the notation Claspec. The latter has, in turn, a vsymbol annotated with Claspec itself and STATECHARTS. By clicking on a notation name in the window, it is possible to recall its specification characteristics in the main window. This allows the methodologist to visually navigate through the notation specifications in a simple and intuitive way. Alternatively, the methodologist can visually specify the grammar by using the Visual Grammar Editor. As an example, Figure 20 shows the visual specification of the production 3 from the XPG for state transition diagrams given in Example 3.1. Figure 19 also shows semantic routines for the construction of a syntax tree. Alternatively, the methodologist can specify semantic routines by using a special purpose visual programming environment. The latter provides graphic palettes containing icons for vsymbols and their attributes as well as Icons for specifying control flow. As the methodologist selects icons from the palettes, a text editor shows the underlying C++ program that is being constructed. This allows the methodologist to switch between visual and textual programming in a seamless way, while keeping the visual and textual versions of the semantic routine consistent. Figure 21 shows a screen dump of the visual programming environment during the construction of a semantic routine for the grammar ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

32

•

December 8, 2004

22:0


Fig. 21. The visual programming environment supporting the construction of semantic routines.

production shown in Figure 20, while constructing a VPE for deterministic state transition diagrams. In particular, the highlighted routine verifies that the labels on nodes’ outgoing edges are all different. Once all the XPG grammars and the semantic routines are provided in YACC format, the build language command under the menu Visual CM Project causes VLDesk to compile the whole project, yielding the corresponding Visual Programming Environment (VPE). The latter is composed of a visual editor based on the palette of terminals built with the Symbol Editor, plus the XpLR-based compiler generated from the XPG grammar and the associated semantic routines. The VLDesk system maintains a repository of previously developed visual notations that can be reused to derive new ones, or to combine them in a new hierarchy. Each VLDesk-generated environment can be used as a CASE tool for the implemented visual notation. In fact, each VPE provides a visual editor to facilitate the freehand composition of the visual sentences, and a compiler performing syntactic and semantic checks, other then translation tasks. Moreover, a certain number of facilities are common to all the generated visual programming environments, while others are specific to the relation types used to model the visual notation. Common editing facilities are the ones that can be found ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

33

Fig. 22. The final VPE implementing the grammar specification given in Appendix section.

in most frontend CASE tools. Additionally, VLDesk enables the generation of visual editors supporting facilities that are specific to the given visual notation class. This is done by generating customized menus, palettes, and buttons. As an example, for notations modeled through the Graph class, VLDesk generates a customized palette containing two types of connection icons: tight connections and loose connections. When a vsymbol is moved over the plane it loses its loose connections, while it preserves its tight connections. Figure 22 shows the VPE generated from the grammar specification of Appendix section. After drawing a statechart, a user can compile it by using the flash button, and successively read the compilation log in the Output window. For successfully parsed vsentences, the compiler triggers the semantic routines, which in this VPE translate the statechart diagrams into the XML Model Interchange (XMI) format [Object Management Group 2003b], a standard file format for saving and loading UML designs. Figure 22 shows a portion of the XMI code generated for the edited statechart. We have also built a VPE for the main visual notations of UML. In this case, we have provided semantic routines to trace dependencies across diagram boundaries, and translate the whole UML project into a C++ skeleton that represents a raw version of the final application [Musto et al. 2001]. In order to enable the interoperability between the generated environment and existing CASE tools, VLDesk allows us to generate editors and parsing ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

34

•

December 8, 2004

22:0


components that communicate through the W3C’s SVG (Scalable Vector Graphics) XML 2D-graphics standard format [Ferraiolo 2001]. In this way, the methodologist can choose either to generate the whole environment with VLDesk, or to generate the parsing component only. In both cases, the generated visual environments can accept input visual sentences from external CASE tools, as long as these are provided in the SVG format. This provides considerable advantages to the methodologist since s/he can design his/her development process, and support its phases through a combination of existing CASE tools and VLDesk-generated tools. The only requirement is that all the tools should be able to import and/or export the visual sentences in the standard SVG format. 5. RELATED WORK Software engineering researchers are paying considerable attention to the specification and modeling of notations used in software engineering. This has led to the development of metamodeling approaches, which have been embedded in several metaCASE environments [de Lara and Vangheluwe 2002; Ebert et al. 1997; Ferguson et al. 2000; Kelly et al. 1996; Sorenson et al. 1996]. In general, metamodeling approaches are sufficiently simple to use because metalanguages are similar to the languages they model, so that they might be easily understood and deployed. However, their empirical and informal descriptions are not sufficient for verifying certain properties of the notations they model. In order to solve this problem, they have been combined with formal specification languages, such as Z [Diller 1992] and OCL [Object Management Group 2003a], providing the ability to express constraints in a textual form in order to restrict the number of meaningful notations. In spite of these extensions, we still need to include additional mechanisms to enable model translation, such as code generation. Finally, none of the metamodeling techniques supports grammar specification for formal textual descriptions, such as process specifications, data dictionaries [Yourdon 1989], or textual grammars [Walden and Nerson 1995]. These aspects are particularly important for the modeling of notations used in certain tasks of software design methodologies, such as those for generating prototypes, program code, or for visualizing available data and program structures. As opposed to metamodeling, grammar-based approaches are, on the average, more difficult to learn, and might require that the user undergo specification and development phases that can sometimes be particularly complex. Nevertheless, these problems have often been overcome through automated support tools. Moreover, grammar-based approaches are more general, and often rely on rigorous syntax and semantics, which provide powerful mechanisms to fully specify visual notations and their properties, including translation rules. In addition, our syntactic framework based on XPGs uses concepts and mechanisms similar to the ones used in language theory which are familiar to a wide community of users. Its power and preciseness allows us to completely model the notations and the corresponding CASE tools for all the tasks of software design methodologies, including those involving text and hybrid visual/text notations mentioned previously. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

35

Table I. Grammar-Based Approaches for Modeling Visual Notations

In the literature, there are many different grammar-based approaches for specifying diagrammatic languages [Marriott and Meyer 1998]. Their underlying grammars can be classified into two categories, depending on the strategy they use to handle information about the spatial layout of symbols. A first category uses attributes on visual symbols. Other than XPGs, in this category we find Relational Grammars (RGs) [Wittenburg 1992; Wittenburg and Weitzman 1998], Constraint Multiset Grammars (CMGs) [Marriott 1994], and Picture Layout Grammars (PLGs) [Golin 1991]. A second category uses relationships among visual symbols at a high level of abstraction. In this category we have Symbol-Relation Grammars (SRs) [Ferrucci et al. 1996], Hypergraph Grammars Minas [1997, 2002], and Layered Graph Grammars (LGGs) Rekers and ¨ [1996, 1997]. Some of these grammar formalisms fall into the category Schurr of graph grammars, since they model visual sentences as graph-like structures. Regarding the parsing techniques, several grammar formalisms support orderfree pictorial parsers that process the input objects according to no-ordering criterion. Examples include the formalisms of PLGs, RGs, LGGs, and CMGs. In general, and in the worst case, an order-free parser proceeds with a purely bottom-up enumeration. To limit the parsing computational cost, subclasses of PLGs, CMGs, and RGs have been defined to provide the corresponding parsers with predictive capabilities that restrict the search space. To further improve parsing efficiency, predictive pictorial parsers have also been defined. In this category, we have pLR parsers [Costagliola et al. 1997], based on Positional Grammars, and the one presented in Wittenburg [1992], based on RGs. A predictive pictorial parser processes the input symbols according to an ordering criteria specified in the grammar. In general, the broader the class of languages to be treated, the less efficient the parsing algorithm is. Table I summarizes the characteristics of the main grammar-based approaches for modeling visual notations. They are compared with our approach based on the type of formalism, the parsing approach, the modeling power, and the parsing complexity. The modeling power refers to the capability of the approach to model general purpose visual languages. To express this characteristic we have used the classification hierarchy of Figure 3. The parsing complexity refers to the computational cost of the parsing phase, which also ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

36

•

December 8, 2004

22:0


includes the scanning complexity. For completeness, we also list in the table the tools supporting the different approaches, together with two characteristic features, such as the visual/textual environment specification paradigm, and the freehand/syntax-directed editing styles supported. An overall analysis of the table reveals that all the surveyed approaches are supported by tools, and that most of the order-free parsers yield an exponential complexity. The only two approaches in this category that have a polynomial parsing complexity have the drawback of a limited modeling power. We also notice that several approaches are graph-based. These all share the advantages of an intuitive and powerful grammar formalism for constructing and manipulating graph-like languages. However, those that do not have modeling limitations yield a high parsing complexity. This is mainly due to the fact that they parse visual notations by using parallel bottom-up algorithms, which process all nodes of the input graph simultaneously, and update a subset of all partial matches ¨ 1996]. of a single production in each basic recognition step [Rekers and Schurr Furthermore, these algorithms need a second phase to extract a consistent set of production instances out of the set of all production instances created in the first phase. Such exhaustive analysis is highly inefficient, especially in cases of many local matches that are not part of a complete solution. Another cause of parsing inefficiency is the complexity of the scanning phase, which precedes the parsing process. In this phase, the scanner reads the picture objects as they are drawn in order to construct and store the whole graph of spatial relations between them. The complexity of this task depends on the type of relations instantiated in the visual notation, which becomes high for notations using implicit relations between vsymbols [Minas 2000]. Let us now examine the specific characteristics of each of the surveyed graph-based approaches. Layered Graph Grammars (LGGs) are Context-sensitive graph grammars using Contextelements to extend the left-and right-hand sides of productions ¨ 1997], which also yield an exponential space complexity. [Rekers and Schurr The associated PROGRES tool supports the design of graph structures and the ¨ et al. 1999]. It exploits a implementation of graph manipulation tools [Schurr graphical syntax for relevant language constructs. The textual language it uses to specify semantic actions of its production rules is less powerful than existing general purpose programming languages (e.g., C, C++, Java), which limits the functionality of the generated visual environment. Moreover, PROGRES has limited visual object construction means, and cannot produce free-hand editors but only syntax-directed editors. Reserved Graph Grammars (RGGs) are formalisms for modeling diagrammatic visual notations. They provide a polynomial parsing algorithm for grammars satisfying a particular constraint, namely the local confluence criterion. This is a rather restrictive constraint which prevents the processing of ambiguous visual language representations such as statecharts. The associated VisPro supports the generation of visual programming environments in a Lex/Yacc fashion [Zhang et al. 2001]. To do this, it requires a lexicon and a grammar specification phase to construct a visual notation. During the former, the user defines the visual objects and a visual editor, while during the latter, s/he specifies an ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

37

RGG for modeling the language syntax, using either a visual and/or a textual environments specification. Contextual Layered Graph Grammars (CLGGs) extend the modeling power of LGGs by combining them with conditions for rules like negative application conditions (NACs) [Bottoni et al. 2000]. If the parsing algorithm is applied to a locally confluent set of rules, it behaves like the one for RGGs, otherwise it behaves like the nave parsing algorithm with backtracking for LGGs. Critical pair analysis is used to detect conflicting rules in an attempt to reduce the complexity of the parsing approach. Specifically, delaying the application of conflicting rules during the parsing process might reduce the need for backtracking. Nevertheless, this does not reduce the implicit complexity of the parser, because the worst-case remains exponential. There are two systems supporting this approach: Attribute Graph Grammars (AGG) and GenGED. The AGG system is a graph transformation environment, consisting of visual editors for graphs, rules, and graph grammars, as well as a visual interpreter for algebraic graph transformations [Bardohl et al. 2002; Ermel et al. 1999; Taentzer 2000]. It might be used without its GUI as a general purpose graph transformation engine. GenGED is a system built upon AGG [Bardohl 2002], and exploits its parsing and graph transformation features. It provides for the visual definition of visual notations and environments by including the definition of editing operations within a visual editor, as well as for the visual definition of analysis features in terms of a parse grammar and a simulation grammar, respectively. The transformation of diagrams is necessary for syntax-directed editing, as well as for parsing and simulation. The graphical constraints defined with respect to the concrete syntax (the layout) are solved by the constraint solver ParCon. This additional effort is not required in VLDesk because constraints are implicitly derived from the syntactic attributes of vsymbols, which are immediately available when modeling visual notations through prebuilt classes. The hypergraph grammar model proposed by Minas [1997] allows a restricted use of context-sensitive elements in the right-hand sides of productions that makes it possible to model general graph structures. It uses the same parser for context-sensitive RGGs, but with relaxed restrictions. The associated tool DiaGen generates diagram editors combining freehand with syntax-directed editing [Minas 2002]. The tool asks the user to provide an input specification of the visual language, which can be textual or visual [Minas 2003], and generates a set of Java classes that, combined with a Java library, enable the construction of the final visual environment. An analysis module based on hypergraph transformations and grammars verifies the structure and syntactic correctness of diagrams during the editing process. In order to create the hypergraph model for the edited diagram, DiaGen uses a scanning method that seeks overlapping attachment areas, and it does not take into account implicit relations that might occur between nonoverlapping symbols. Picture Layout Grammars (PLG) view a visual sentence as a multiset of visual symbols with attributes containing positional information about them. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

38

•

December 8, 2004

22:0


The associated parsing algorithm has the drawback that it works under certain restrictions that cannot always be checked at run-time. As a consequence, it cannot be guaranteed that the PLG parser produces correct results, nor that it terminates. Moreover, PLGs do not allow an easy integration of textual and graphical languages. A visual environment generation tool based on this grammar formalism is the Visual Programmer’s Workbench (VPW) [Rubin et al. 1990], which enables the generation of visual programming environments such as iconic languages and some diagrammatic languages. Constraint Multiset Grammars (CMGs) are closely related to PLGs [Chok and Marriot 2003]. They are based on multiset rewriting, where a nonterminal symbol in a multiset can be rewritten by a grammar production whenever the attributes of the symbols in the multiset satisfy a given constraint, describing relationships among visual symbols. In addition to PLGs, a CMG production can specify constraints over the attributes of any symbol in the current sentential form, which give CMG the power of context-sensitive attribute multiset grammars. Moreover, the possibility of specifying negative constraints allows for the specification of visual languages through deterministic CMGs which reduces the parsing inefficiency. Several additional methods are presented in the literature to reduce CMG’s parser inefficiency, like a bottom-up parser for a deterministic subclass of constraint set grammars [Chok and Marriot 1995; Marriott 1994], and one for cycle-free constraint set grammars without negative constraints [Chok and Marriot 1995]. The Penguin system is an example of a visual programming environment generator based on CMGs. Its main characteristic is a Prolog-like incremental parsing technique, which allows the presence of incorrect, intermediate visual sentences, yielding a user-friendly paradigm for visual sentences manipulation. Symbol-Relation Grammars (SR) views a visual sentence as a set of symbol occurrences and a set of relational items over symbol occurrences [Ferrucci et al. 1996]. The drawback of this approach is that the membership problem for the whole class of SR languages is NP-hard, although several subclasses have been defined in order to reduce parsing inefficiency. The associated tool Visual Language Programming Environment Generator (VLPEG) provides automated support for the specification and implementation of visual languages, including diagrammatic languages. In conclusion, the strong point of our approach with respect to the surveyed approaches is that our approach has the capability to provide an efficient parser without limiting the modeling power. 6. CONCLUSIONS AND FURTHER RESEARCH We have presented a framework for modeling and implementing visual notations used in software engineering. The framework relies on a new grammar formalism (XPG), and a new LR-based technique (XpLR) which allow us to model and parse a broad class of visual notations, encompassing those used in software development methodologies. We also describe the VLDesk system, a tool providing automated support for the phases of the modeling process prescribed in the proposed framework. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

39

The framework provides an effective way to specify customized software development processes, and to rapidly generate tools supporting them through the VLDesk system. The latter allows us to generate flexible CASE tools that can be easily modified and can effectively interoperate with existing tools. Moreover, the system provides an extensible set of visual notation classes, enhancing the modeling of new visual notations and the generation of visual programming environments supporting them. Our future investigations will be conducted in two directions: the XPG/XpLR methodology, and the VLDesk system. Regarding the former, we need to perform further theoretic studies on the expressive power of XPG grammars and on the recognition power of the XpLR parser. So far, we have been able to show them by following an empirical method, that is, by modeling and parsing many practical visual languages. In particular, we have been able to model visual notations used in widely-used software design methodologies, those used in emerging multimedia and Web development methodologies [Isakowitz et al. 1995; Conallen 1999; Chang 2000], in workflow management systems, and in E-business specification tools [Chang et al. 2003]. Regarding the VLDesk system, we can further improve the meta-CASE capabilities of VLDesk by allowing the specification and integration of existing CASE tools within a process modeling language. This will allow a designer to specify his/her own software development process, the methods, and the tools s/he intends to use in each phase, and have the system generate the whole development workbench based on the specified process. Regarding CASE interoperability, parsing errors for vsentences composed in external CASE tools are currently communicated in a textual format. We are investigating the possibility of enhancing their communication by combining them with a visual format. In particular, we intend to include the visual error patterns within the SVG representation of the input vsentence, so that the external CASE tools can visualize the original vsentence with the overlaid visual error patterns. Other improvements concern the editor of the generated CASE tools. Specifically, we have devised a paradigm for composing vsentences which extends freehand styles with mechanisms to provide immediate syntax feedbacks to the software engineer without interrupting his/her work [Costagliola and Deufemia 2003]. Once included in the VLDesk, these mechanisms will enable the generation of CASE tools with enhanced parsing feedbacks, without the need of syntax-directed editing. APPENDIXES SECTION. MODELING UML STATECHART DIAGRAMS THROUGH XPGS In this appendix, we show how Extended Positional Grammars can be used to specify UML statechart diagrams. This language is derived from the original proposal by Harel [1988], with modifications incorporated in order to include object-oriented features. It models the states of an object and how an object moves from state-to-state for its entire lifetime. The OMG Unified Modeling Language Specification states that “statechart diagrams represent the behavior ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

40

•

December 8, 2004

22:0


Fig. 23. Java thread life cycle.

of entities capable of dynamic behavior by specifying its response to the receipt of event instances. Typically, it is used for describing the behavior of class instances, but statecharts may also describe the behavior of other entities such as use-cases, actors, subsystems, operations, or methods.” [Object Management Group 2003a]. UML statechart diagrams are a very rich Graphical specification formalism obtained as an extension of conventional finite-state machines with more powerful concepts such as hierarchy of states, orthogonality, interlevel transitions and so forth. [Harel 1988], and are considered a good testbed for evaluating the ¨ 2001]. effectiveness of visual language specifications, [Minas and Schurr There are five different kinds of entities in a statechart diagram: statevertices, transitions (arcs), events, conditions and actions. As described in Object Management Group [2003a], statevertices may be states, pseudostates, stub states or synch states. The states (shown in Figure 23 as rectangles with rounded corners) may be composite (such as Alive in Figure 23), simple (such as Created and Dead in Figure 23), or final. Composite states may be OR-States or ANDStates. OR-States, contain a set of other states (substates) that are related to each other by “exclusive-or”. AND-States contain at least two unnamed concurrent OR-States, separated by dashed lines. Simple states are those that have no substates (they are at the bottom of the hierarchy). A final state (shown in Figure 23 as a circle surrounding a small solid filled circle) represents the completion of an activity in the enclosing state. A state may have associated internal transitions that depict what activities the object will be doing while it is in that state. The general format for the internal transitions is: event-signature ‘[’ guard-condition ‘]’ ‘/’ actionexpression, where the event-signature describes an event that is an occurrence that may trigger an action, the guard-condition is a boolean expression, the ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

41

Fig. 24. The graph associated with the statechart diagram of Figure 23.

action-expression is executed, if and when the event occurrs. As an example, in Figure 26, the state Working has two internal transitions. The first transition entry/i++ specifies that the counter i is incremented upon entry to the state Working, the second exit/i−− specifies that the counter i is decremented upon exit from the state Working. The pseudostates kinds are: initial, deepHistory, shallowHistory, join, fork, junction and choice. Each OR-State (as well as the statechart diagram itself) contains exactly one initial pseudostate, which is shown in Figure 26 as a small solid-filled circle. Transitions connect states and may be labeled by a transition string that has the same format as internal transitions of the states. As an example, in Figure 23 the transition from the state Running to the state Waiting is labeled with the transition string formed by the event wait and the action release lock. To simplify the statechart diagram language description the deepHistory indicator, the stub states, and synch states will not be considered in the following discussion, moreover, we consider statechart diagrams where the initial pseudostates are connected only to states. It is widely recognized that the main difficulties for modeling statecharts derive from the presence of interlevel transitions (like the transition labeled with the event run returns in Figure 23), multiple source/multiple target transitions, join/fork connectors, and history connectors. In order to capture the interlevel transitions, the extended positional grammar proposed in this section first determines the hierarchy of states, and then analyzes the transitions among states. After the first phase, the statechart diagram is transformed into an internal format, represented by a graph formed by states and transitions. As an example, Figure 24 shows the graph associated with the statechart in Figure 23. Now, we focus our attention on the first phase. In order to describe how a state is contained in a superstate, we introduce a spatial relation contains. To this aim, we associate to the states a containment area as a syntactic attribute. Such a containment area corresponds to the rectrangular area representing the state. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

42

•

December 8, 2004

22:0


Fig. 25. The terminals for the grammar SD.

Thus, the containment relation is defined as: A contains B, if and only if the containment area of A is the closest containment area that contains B, where A and B are states of a statechart diagram. As an example, from Figure 23 Alive contains Joined holds because there are no states that contain Joined and are contained in Alive. Moreover, the states of a statechart diagram can be related through a sibling relationship whenever either the states are contained in the same superstate, or they are not contained in superstates. Such relationship can be described by a spatial relation, named sibling, defined as: A sibling B, if and only if, (1) there exists C such that C contains A and C contains B, or (2) there do not exist C and D with C contains A and D contains B, where A, B, C and D are states of a statechart diagram. As an example, Running sibling Waiting holds because Alive contains Running and Alive contains Waiting. Moreover, Alive sibling Dead holds because the condition 2 is satisfied. The extended positional grammar S D = ((N , T ∪ P O S, S, P ), P E) for UML statechart diagrams has the following characteristics. The set of nonterminals is given by N = {StateDiagram, Hierarchy, HSeqState, SeqState, IState, Initial, Diagram, State, Connector, Component, Comp, MultiGraph, Graph, Sync, Node}, where the first eleven vsymbols have one containment area as syntactic attribute, and the others have one attaching region as syntactic attribute. The set of terminals is given by T = {INITIAL, STATE, CONCURRENT, FINAL, HISTORY, JUNCTION, CHOICE, FORK JOINT, EDGE, NEW F J , NEWSTATE, PLACEHOLD} and are graphically depicted in Figure 25. Here, each attaching

region is represented by a bold line and identified by a number, each containment area is represented by a light gray area, while the attaching points are represented by bullets. The terminal vsymbol INITIAL has one attaching region as syntactic attribute and represents the initial pseudostate. The terminal vsymbol STATE has one attaching region and one containment area as syntactic attribute, and represents the state of a statechart diagram. The terminal vsymbol CONCURRENT has one containment area as syntactic attribute, and it represents the concurrent substate contained in an AND-State. The terminal vsymbol FINAL has one attaching region as syntactic attribute and represents a final state. The terminal vsymbols HISTORY, JUNCTION, and CHOICE have one attaching region as syntactic attribute and they represent the history state indicator, the junction point (which is used to merge and split transitions), and ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

43

Fig. 26. A statechart diagram that models the behavior of a job processing environment.

the dynamic choice point, respectively. The terminal vsymbol FORK JOIN has two attaching regions as syntactic attributes, corresponding to the incoming transitions and outgoing transitions, and it represents synchronization, forking, or both. The terminal vsymbol EDGE has two attaching points as syntactic attributes, corresponding to the start and end points of the transition. Finally, NEWSTATE, NEW FJ, and PLACEHOLD are fictitious terminal vsymbols to be dynamically inserted in the input sentence during the parsing process. The set of relations is given by P O S = {LINKi,j , sibling, contains, any}, where LINKi,j is defined as in Section 2.3. Next, we provide the set of productions of the first phase to determine the hierarchy of states in the statechart diagrams. (1) StateDiagram → Hierarchy any MultiGraph (2) StateDiagram → Hierarchy (3) Hierarchy → IState sibling HSeqState :(Hierarchyarea =IStatearea ); (4) Hierarchy → IState :(Hierarchyarea =IStatearea ); (5) HSeqState → SeqState sibling HISTORY :(HSeqStatearea =SeqStatearea ); (6) HSeqState → SeqState :(HSeqStatearea =SeqStatearea ); (7) SeqState → Diagram sibling SeqState :(SeqStatearea =Diagramarea ); (8) SeqState → Diagram :(SeqStatearea =Diagramarea ); (9) IState → Initial contains Hierarchy :(IStatearea =Initialarea ); (10) IState → Initial :(IStatearea =Initialarea ); (11) IState → Initial contains Component :(IStatearea =Initialarea ); (12) Initial → INITIAL 1 1 EDGE 2 1 STATE :(Initialarea =STATEarea ); :{(NEWSTATE;|STATE1 | > 0; NEWSTATE1 =STATE1 −EDGE2 )} (13) Diagram → State :(Diagramarea =Statearea ); (14) Diagram → Connector :(Diagramarea =Connectorarea );

(16) State → STATE :(Statearea =STATEarea ); :{(NEWSTATE;|STATE1 | > 0; NEWSTATE1 =STATE1 )} (17) State → STATE contains Component :(Statearea =STATEarea ); :{(NEWSTATE;|STATE1 | > 0; NEWSTATE1 =STATE1 )} (18) State → FINAL :(Statearea =∅); :{(NEWSTATE;|FINAL1 | > 0; NEWSTATE1 =FINAL1 )} (19) Connector → JUNCTION :(Connectorarea =∅); :{(NEWSTATE;|JUNCTION1 | > 0; NEWSTATE1 =JUNCTION1 )} (20) Connector → CHOICE :(Connectorarea =∅); :{(NEWSTATE;|CHOICE1 | > 0; NEWSTATE1 =CHOICE1 )} (21) Connector → FORK JOIN :(Connectorarea =∅); :{(NEW FJ;|FORK JOIN1 | > 0; NEW FJ1 =FORK JOIN1 , NEW FJ2 =FORK JOIN2 )} (22) Component → Comp sibling Component :(Componentarea =Comparea ); (23) Component → Comp sibling Comp


P1: IAZ ACMJ018-02

ACM-TRANSACTION

44

•

December 8, 2004

22:0


(15) State → STATE contains Hierarchy :(Statearea =STATEarea ); :{(NEWSTATE;|STATE1 | > 0; NEWSTATE1 =STATE1 )}

:(Componentarea =Comparea ); (24) Comp → CONCURRENT contains Hierarchy :(Comparea =CONCURRENTarea );

Productions 1 and 2 describe a statechart diagram as a hierarchy of states (first phase of the reduction process) represented by the nonterminal Hierarchy, and an optional set of transitions between states (second phase) represented by the nonterminal MultiGraph. A Hierarchy is formed by an initial state (Istate) and an optional sequence of states and/or connectors (HSeqState) as described in productions 3 and 4. An initial state is obtained by linking an initial pseudostate to a state (production 12), and it can be: — an initial simple state (production 10), or — an initial OR-State (production 9) which is formed by the nonterminal Initial with a Hierarchy in its containment area, or — an initial AND-State (production 11) which is formed by the nonterminal Initial with a nonterminal Component in its containment area. A Component is formed by at least two nonterminals Comp, where each one is a terminal CONCURRENT with a Hierarchy in its containment area (productions 22-24). The productions 5 and 6 define a HSeqState as formed by the nonterminal SeqState and an optional history indicator. SeqState is a sequence of states and/or connectors related through the sibling relation (productions 7-8). A state can be a simple state (production 16), or an OR-State (production 15), or an AND-State (production 17), or a final state (production 18). A connector can be a junction connector (production 19), a dynamic choice connector (production 20), or a fork/join connector (production 21). During the first phase, the terminals with incident links are reintroduced as described in the rules and reanalyzed in the second phase. Figure 26 shows the statechart diagram describing the behavior of a job processing environment. In the following, we show the steps to reduce such a statechart diagram with the extended positional grammar SD. Figures 27 (a–i) shows the first phase of the reduction process. In particular, the process starts by applying production 12 to the initial state Working. This causes the reduction of vsymbols INITIAL, EDGE, and STATE to the nonterminal IState. Due to the rule of production 12, since |STATE1 | = 3, a new state NEWSTATE is inserted in the input and inherits all the connections of STATE, except for the connection to EDGE. Similarly, the application of production 16 reduces the vsymbol STATE representing the state Waiting with the nonterminal State, and the rule inserts in the input sentence a new state NEWSTATE. Figure 27(b) shows the resulting visual sentential form and highlights the handles for the application of productions 12, 16 and 18, respectively, to the initial states, to the state Sending, and to the final states contained in the AND-State, and also for the application of production 10 to the nonterminal Initial and of production 13 to the nonterminal State. The resulting visual sentential form is shown in Figure 27(c). After the application of several productions, the reduction process reduces the AND-State to the nonterminal Diagram that will be reduced with the nonterminals SeqState to the nonterminal HSeqState by ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

45

Fig. 27. The first phase of the reduction process for the statechart diagram in Figure 26.

applying productions 7 and 6. Figure 27(g) shows the resulting visual sentential form with the handle for the application of production 3. Figure 27(i) shows the visual sentential form resulting from the first phase of the reduction process of the statechart diagram in Figure 26. It is composed from the nonterminal Hierarchy and a nonconnected graph obtained by reintroducing new states during the reduction. In general, a node of the nonconnected graph can be either the terminal NEWSTATE, or the terminal NEW FJ. Now, we provide the set of productions of the second phase to analyze the transitions between pairs of such states. These can be easily obtained by modifying the productions of the grammar for state transition diagrams introduced in Example 3.1. As a matter of fact, with productions 25 and 26, we describe a nonconnected graph as formed by one or more graphs, where each one is a state transition diagram with no initial node and no final node (productions 27-31). Finally, we add the productions for the fork/join connector (productions 32-37). (25) MultiGraph → Graph any MultiGraph :(MultiGraph1 =Graph1 ); ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

46

•

December 8, 2004

22:0


(26) MultiGraph → Graph :(MultiGraph1 =Graph1 ); (27) Graph → NEWSTATE :(Graph1 =NEWSTATE1 ); (28) Graph → Graph 1 1,1 2 EDGE 2 1 Node :(Graph1 =Graph 1 −EDGE1 ); :{(PLACEHOLD;|Node1 | > 1; PLACEHOLD1 =Node1 −EDGE2 )} (29) Graph → Graph 1 1,1 2 EDGE :(Graph1 =(Graph 1 −EDGE1 )−EDGE2 ); (30) Graph → Graph 1 2,1 1 EDGE 1 1 Node :(Graph1 =Graph 1 −EDGE2 ); :{(PLACEHOLD;|Node1 | > 1; PLACEHOLD1 =Node1 −EDGE1 )} (31) Graph → Graph any PLACEHOLD :(Graph1 =Graph 1 +PLACEHOLD1 ); (32) Graph → Graph 1 1,1 2 EDGE 2 1 Sync :(Graph1 =Graph 1 −EDGE1 ); (33) Graph → Graph 1 2,1 1 EDGE 1 2 Sync :(Graph1 =Graph 1 −EDGE2 ); (34) Sync → NEW FJ 2 1,2 2 EDGE 2 1 Node :(Sync1 =NEW FJ1 ,Sync2 =NEW FJ2 −EDGE1 ); :{(PLACEHOLD;|Node1 | > 1;PLACEHOLD1 =Node1 −EDGE2 )} (35) Sync → NEW FJ 1 2,1 1 EDGE 1 1 Node :(Sync1 =NEW FJ1 −EDGE2 ,Sync2 =NEW FJ2 ); :{(PLACEHOLD;|Node1 | > 1;PLACEHOLD1 =Node1 −EDGE1 )} (36) Sync → Sync 2 1,2 2 EDGE 2 1 Node :(Sync1 =Sync 1 ,Sync2 =Sync 2 −EDGE1 ); :{(PLACEHOLD;|Node1 | > 1;PLACEHOLD1 =Node1 −EDGE2 )} (37) Sync → Sync 1 2,1 1 EDGE 1 1 Node :(Sync1 =Sync 1 −EDGE2 ,Sync2 =Sync 2 ); :{(PLACEHOLD;|Node1 | > 1;PLACEHOLD1 =Node1 −EDGE1 )} (38) Node → NEWSTATE :(Node1 =NEWSTATE1 ); (39) Node → PLACEHOLD :(Node1 =PLACEHOLD1 );

Figure 28(a–h) shows the steps to reduce the visual sentential form of Figure 26(i) through the productions shown previously. The reduction process starts by applying production 27 to one node of each graph. This causes the terminals NEWSTATE to be reduced to the nonterminal Graph. Due to the rule of production 27, Graph receives all the connections of NEWSTATE. Similarly, the application of production 38 reduces the remaining NEWSTATE of Figure 28(a) with the nonterminal Node. Figure 28(b) shows the resulting visual sentential form, and highlights the handle for the application of productions 28 and 30. The vsymbols Graph, EDGE, and Node are then reduced to the new nonterminal Graph. Due to the rules of productions 28 and 30, the new Graph is connected to all the remaining edges attached to the old Graph. Moreover, due to the rule, since |Node| = 2 > 1 for the graph on the left, a new node PLACEHOLD is inserted in the input, and it is connected to all the remaining edges attached to the old Node. Figure 28(c) shows the resulting visual sentential form. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

47

Fig. 28. The second phase of the reduction process of the statechart diagram in Figure 26.

After the application of productions 28 and 26, the visual sentential form reduces to the one shown in Figure 28(d). Then, production 31 reduces the nonterminals Graph and PLACEHOLD to a new nonterminal Graph. By applying the rule of production 31, the new Graph receives all the connections to PLACEHOLD (see Figure 28(e)). Moreover, production 25 reduces the nonterminals MultiGraph and Graph to a new nonterminal MultiGraph, and production 39 reduces PLACEHOLD to a new nonterminal Node. The subsequent application of productions 30, 25 and 1 reduces the original statechart diagram to the starting vsymbol in Figure 28(h), confirming that the visual sentence associated with the initial statechart diagram belongs to the visual language L(SD). It is worth noting that badly formed statechart diagrams are also in SD. The language L(SD) can be restricted to well-formed statechart diagrams by modifying and adding new productions to the grammar SD. As an example, in a well-formed statechart diagram, final states cannot have any outgoing transitions. Such property is captured by modifying the rule in production 18 so that a new state, named NEWFS, is reintroduced in the input sentence. The production becomes: (18 ) State → FINAL :(Statearea = ∅); :{(NEWFS;|FINAL1 | > 0;NEWFS1 =FINAL1 )}

Consequently new productions must be introduced for the second phase of the reduction process to manage the vsymbol NEWFS. The productions consider only incoming transitions for such vsymbol as shown in the following. (40) Graph → Graph 1 1,1 2 EDGE 2 1 NEWFS :(Graph1 =Graph 1 −EDGE1 ); :{(NEWFS ;|NEWFS1 |>1;NEWFS 1 =NEWFS1 −EDGE2 )} ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

48

•

December 8, 2004

22:0


(41) Sync → NEW FJ 2 1,2 2 EDGE 2 1 NEWFS :(Sync1 =NEW FJ1 ,Sync2 =NEW FJ2 −EDGE1 ); :{(NEWFS ;|NEWFS1 |>1;NEWFS 1 =NEWFS1 −EDGE2 )} (42) Sync → Sync 2 1,2 2 EDGE 2 1 NEWFS :(Sync1 =Sync 1 ,Sync2 =Sync 2 −EDGE1 ); :{(NEWFS ;|NEWFS1 |>1;NEWFS 1 =NEWFS1 −EDGE2 )}

Now we show how to modify the grammar in order to analyze the text of the transitions associated with the edges and with the states. In particular, the string transitions can be modelled by using textual annotations, so the terminal vsymbols STATE and EDGE have also one textual annotation as syntactic attribute, and the set of relations POS is extended by adding the relations annotated-by and right-to. The former denotes a relation that is satisfied between a vsymbol and a sentence, whereas the latter is the visual counterpart of the string concatenation relationship as described in Section 2, and can be defined as: u right-to v, if and only if vheadx = utailx + 1 and vhead y = utail y , where u, v ∈ N ∪ T , and head or tail are the syntactic attributes specifying their position in the plane. The productions must take into account the new annotation relation so the terminal vsymbol EDGE must be substituted by the nonterminal Edge which has two attaching points as syntactic attributes. As an example, production 12 becomes: (12 ) Initial → INITIAL 1 1 Edge 2 1 STATE :(Initialarea =STATEarea ); :{(NEWSTATE;|STATE1 | > 1;NEWSTATE1 =STATE1 −Edge2 )}

In the following we provide the subset of productions for describing the string transitions annotating the terminal vsymbol EDGE. (43) Edge → EDGE annotated-by Label :(Edge1 =EDGE1 ,Edge2 =EDGE2 ); (44) Edge → EDGE :(Edge1 =EDGE1 ,Edge2 =EDGE2 ); (45) Label → Event right-to Condition right-to Action :(Labeltext =Eventtext +Conditiontext +Actiontext ); (46) Label → Condition right-to Action :(Labeltext =Conditiontext +Actiontext ); (47) Label → Event right-to Action :(Labeltext =Eventtext +Actiontext ); (48) Label → Event right-to Condition :(Labeltext =Eventtext +Conditiontext ); (49) Label → Event :(Labeltext =Eventtext ); (50) Label → Condition :(Labeltext =Conditiontext ); (51) Label → Action :(Labeltext =Actiontext ); (52) Event → EVENT :(Eventtext =EVENTtext , Eventhead =EVENThead , Eventtail =EVENTtail );

(53) Event → EVENT right-to ( right-to ListParam right-to ) :(Eventtext =EVENTtext + ‘(’ + ListParamtext + ‘)’, Eventhead =EVENThead , Eventtail =ListParamtail +1); (54) Condition → [ right-to COND right-to ] :(Conditiontext =‘[’ + CONDtext + ‘]’, Conditionhead =CONDhead −1, Conditiontail =CONDtail +1); (55) Action → / right-to ACT :(Actiontext =‘/’ + ACTtext , Actionhead =ACThead −1,Actiontail =ACTtail ); (56) ListParam → Param right-to , right-to ListParam :(ListParamtext =Paramtext + ‘,’ + ListParam text , ListParamhead =Paramhead , ListParamtail =ListParam tail ); (57) ListParam → Param :(ListParamtext =Paramtext ,ListParamhead = Paramhead , ListParamtail =Paramtail ); (58) Param → NAME right-to : right-to TYPE :(Paramtext =NAMEtext +‘:’+TYPEtext , Paramhead =NAMEhead ,Paramtail =TYPEtail );

Productions 43 and 44 describe a transition as formed by the terminal vsymbol EDGE and an optional annotating string transition (Label). The general ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

49

format for the transition strings is event-signature ‘[’ guard-condition ‘]’ ‘/’ action-expression, where event-signature is event-name ‘(’ comma-separatedparameter-list ‘)’, and a parameter has the format parameter-name ‘:’ typeexpression. Thus productions 45–58 describe a string transition as the string concatenation of event, condition, and action. The nonterminal Label has a string as syntactic attribute referred to as text. The nonterminals Event, Condition, Action, ListParam, and Param, together with the terminals, have three syntactic attributes: a string referred to as text, and two positions in the plane, named head and tail. Notice that Label text = Eventtext + Actiontext indicates string concatenation and is to be interpreted as follows: “the text of Label is obtained by the concatenation of the text of Event and the text of Action”. In order to describe the internal transitions associated with the states, the terminal vsymbol STATE must be substituted by the nonterminal AnnState which has one containment area as syntactic attribute. As an example, production 27 becomes: (27 ) State → AnnState contains Hierarchy :(Statearea =AnnStatearea ); :{(NEWSTATE;|AnnState1 |>0;NEWSTATE1 =AnnState1 )}

The productions describing internal transitions annotated to the terminal vsymbol STATE are shown in the following: (59) AnnState → STATE annotated-by SeqLabel :(AnnStatearea =STATEarea ); :{(NEWSTATE;|STATE1 |>0; NEWSTATE1 =STATE1 )} (60) AnnState → STATE :(AnnStatearea =STATEarea ); :{(NEWSTATE;|STATE1 |>0; NEWSTATE1 =STATE1 )}

(61) SeqLabel → Label right-to SeqLabel :(SeqLabeltext =Labeltext +SeqLabel text , SeqLabelhead =Labelhead , SeqLabeltail =SeqLabel tail ); (62) SeqLabel → Label :(SeqLabeltext =Labeltext , SeqLabelhead =Labelhead , SeqLabeltail =Labeltail );

The nonterminal SeqLabel has three syntactic attributes: a string referred to as text, and two positions in the plane, named head and tail. SECTION. CONSTRUCTING XPLR(0) PARSING TABLES In this section, we present the algorithms for the construction of an XpLR(0) parsing table. Let us start by providing the notion of item. An XpLR(0) item of an extended positional grammar is a production without the and rules, and with a dot at some position of the right-hand side. However, a dot can never be placed between a relation identifier and the terminal or nonterminal vsymbol to its right. As an example, the production A → X R1 Y R2 Z, , leads to the following four types of XpLR(0) items: [A → · X R1 Y R2 Z] [A → X · R1 Y R2 Z] [A → X R1 Y · R2 Z] [A → X R1 Y R2 Z ·] ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

50

•

December 8, 2004

22:0


Intuitively, an item indicates how much of a production has already been examined during the parsing process and what is yet to come. For instance, the item [Graph → Graph · 1 1,1 2 EDGE from the grammar of Example 3.1 means that the nonterminal Graph has already been seen, and a terminal EDGE in relation 1 1,1 2 with Graph is expected next. A collection of sets of XpLR(0) items provides the basis for constructing XpLR(0) parsers. To construct such a collection for a grammar, we define an augmented grammar and three functions, closure, partition and goto. Given an extended positional grammar G with start vsymbol S, its augmented extended positional grammar G is derived from G by adding the new start vsymbol S and the production S → S. The Closure Operation If I is a set of items for a grammar G, then closure(I ) is the set of items constructed from I by the two rules: (1) Initially, every item in I is added to closure(I ). (2) If A → α · R B β with α = , or A → · B β is in closure(I ), and B → γ is a production, then add the item B → · γ to I , if it is not already there. We apply this rule until no more new items can be added to closure(I ). Intuitively, given a set of items I containing an item with a dot before a nonterminal B, the function CLOSURE adds to I all the items with B in the left-hand side and the dot preceding the first object of the right-hand side. This means that if the nonterminal object B is expected next, then any object starting a positional sentential form from B is expected next. The function closure can be computed as follows. Function CLOSURE(I ) begin J = I; repeat for each item [A → α · R B β] with α = or [A → · B β] in J and each production B → γ in G such that B → · γ is not in J do add [B → · γ ] to J until no more items can be added to J return J ; end.

The Partition Operation If J is a set of XpLR(0) items then Partition(J ) splits J in an ordered sequence of XpLR(0) item sets. The function groups the items having the same driver relation following the dot, so each set of the sequence can be identified by a driver relation. The order of the sets in the sequence depends on the syntax of the language to be parsed, and the language implementer may need to modify it accordingly. Moreover, each complete item (i.e., of type [A → X R1 Y R2 Z ·]) in J is inserted at the end of the sequence in the same order as the corresponding productions in the XPG grammar. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

51

The function partition can be computed as follows. Function PARTITION(J ) begin let D be any ordered sequence Rdriver1 , . . . , Rdrivern of all the different driver relations following the dots in the items in J if n ≤ 1 then return {J } else for i = 1 to n do Ji = {items | items = [A → α x · Rdriveri , Rtesteri β ] ∈ J } let m the number of complete items in J for i = 1 to m do Jn+i = {items | items = [A → α x · ] ∈ J } return J1 , . . . , Jn+m ; endelseif end

The Goto Operation The third useful function is goto(I, x, R), where I is a set of items, x is a grammar vsymbol and R is a sequence of tester relations. goto(I, x, Rtester ) is defined to be the closure of the sequence of sets of items obtained by applying the partition operation to the set of all items [A → α Rdriver , Rtester x · β], such that [A → α · Rdriver , Rtester x β] is in I. Intutively, once a grammar object x has been seen, the function GOTO determines the ordered sequence of sets of items containing the objects that can be seen next. Function GOTO(I , x, Rtester ) begin if Rtester = ∅ then let J ={ [A → α Rdriver x · β] | α = and [A → α · Rdriver x β] ∈ I } ∪ { [A → x · β] | [A → · x β] ∈ I } else let J = { [A → α Rdriver , Rtester x · β] | α = , and [A → α · Rdriver , Rtester x β] ∈ I } set J1 , . . . , Jm = PARTITION(J ) where m is the length of the returned sequence return CLOSURE(J1 ), . . . , CLOSURE(Jm ) end.

The Set-of-Items Construction We are now ready to give the algorithm to construct C, the collection of sequences of XpLR(0) item sets for an augmented grammar G ; the algorithm is shown in the following. Algorithm A.1 Construction of the Sets of XpLR(0) Items. Input: An augmented extended positional grammar G . Output: The collection of sequences of XpLR(0) item sets. Method: Sequences of item sets are constructed by the main procedure ITEMS, which in turn calls the two functions CLOSURE and GOTO. Procedure ITEMS(G ) begin let C = {CLOSURE({[S → · S]})} repeat


P1: IAZ ACMJ018-02

ACM-TRANSACTION

52

•

December 8, 2004

22:0


for each item set I belonging to a sequence in C, each vsymbol x such that there exists [A → α · Rdriver x β] ∈ I or [A → · x β] ∈ I and GOTO(I , x, ∅) is not included in C do C = C∪ GOTO(I , x, ∅) for each item set I belonging to a sequence in C, and each vsymbol x and each sequence of tester relations Rtester = ∅ such that [A → α · Rdriver , Rtester x β] ∈ I and GOTO(I , x, Rtester ) is not included C do C = C ∪ GOTO(I , x, Rtester ) until no more sets of items can be added to C end.

The collection of sequences of XpLR(0) item sets of an augmented extended positional grammar G are incrementally constructed by the main procedure ITEMS, starting from the initial set containing the item [S → · S]. Similar to the LR case, the sequence of sets of XpLR(0) items correspond to the states of a finite automaton for viable prefixes [Aho et al. 1987], where the transitions are determined by the function GOTO. In the following we give an example of construction of the sets of XpLR(0) item sets. Example section.1. The collection of sequences of XpLR(0) item sets for the grammar of Example 3.1 is described in the following. The notation (goto j ) to the right-hand side of an item K = [A → α · Rdriver , Rtester x β] indicates the sequence of item sets I j returned by GOTO(K , x, Rdriver ). I0 J01 = { S → · Graph Graph → · NODEI Graph → · NODEIF Graph → · Graph 1 1,1 2 EDGE 2 1 Node Graph → · Graph 1 1,1 2 EDGE Graph → · Graph 1 2,1 1 EDGE 1 1 Node Graph → · Graph any PLACEHOLD I1 J11 = { Graph → Graph · 1 1,1 2 EDGE 2 1 Node Graph → Graph · 1 1,1 2 EDGE J12 = { Graph → Graph · 1 2,1 1 EDGE 1 1 Node J13 = { Graph → Graph · any PLACEHOLD J14 = { S → Graph · } I2 J21 = { Graph → NODEI · } I3 J31 = { Graph → NODEIF · } I4 J41 = { Graph → Graph 1 1,1 2 EDGE · 2 1 Node Node → · NODEG Node → · NODEF Node → · PLACEHOLD I5 J51 = { Graph → Graph 1 1,1 2 EDGE · } I6 J61 = { Graph → Graph 1 2,1 1 EDGE · 1 1 Node Node → · NODEG

(goto 1) (goto 2) (goto 3) (goto 1) (goto 1) (goto 1) (goto 1)} (goto 4) (goto 5)} (goto 6)} (goto 7)}

(goto 8) (goto 9) (goto 10) (goto 11)}

(goto 12) (goto 9)


P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0

A Framework for Modeling and Implementing Visual Notations Node → · NODEF Node → · PLACEHOLD

•

53

(goto 10) (goto 11)}

I7 J71 = { Graph → Graph any PLACEHOLD · } I8 J81 = { Graph → Graph 1 1,1 2 EDGE 2 1 Node · } I9 J91 = { Node → NODEG · } I10 J101 = { Node → NODEF · } I11 J111 = { Node → PLACEHOLD · } I12 J121 = { Graph → Graph 1 2,1 1 EDGE 1 1 Node · }

Sequence I1 is the only one formed by more than one set. The function Partition has split the set of items into four subsets using the ordered sequence of driver relations D = {1 1,1 2,any}. The XpLR Parsing Table Construction Now we shall show how to construct an XpLR parsing table. In an XpLR parsing table, each state corresponds to a sequence of item sets, and is partitioned into as many substates as the number of different item sets contained in its sequence. In the following, we will denote with i.k the k-th substate of state i. Algorithm A.3 Constructing an XpLR(0) parsing table. Input: An augmented extended positional grammar G . Output: The XpLR(0) parsing table for G . Method: (1) Construct C = {I0 , I1 , . . . , Im }, the collection of ordered sequences of sets of XpLR(0) items as described in Algorithm section. (2) Substate i.k of the parser is constructed from the set of items Jk in the ordered sequence Ii . The entries for substate i.k of the parsing table action and next parts are determined as follows: SHIFT ENTRIES — If [A → α · Rdriver a β] or [A → · a β] is in Jk of the sequence Ii and GOTO(Ii , a, ∅) = I j then set action[i.k, a] = “T: shift j ” (a is required to be a terminal) where T stands for a condition which returns always true. — If [A → α · Rdriver , Rtester a β] is in Jk of the sequence Ii and GOTO(Ii , a, Rtester ) = I j then set action[i.k, a] = “Rtester : shift j ” (a is required to be a terminal). REDUCE ENTRIES — If [A → α · ] is in Jk of the sequence Ii then set action[i.k, a] = “reduce A → α” for each terminal a. NEXT and ACCEPT ENTRIES — Whenever [A → α · Rdriver , Rtester x β] is in Jk of the sequence Ii insert (Rdriver , x) in next[i.k]. — If [S → · S] is in Jk of the sequence Ii then insert (Start, S) in next[i]. If [S → S ·] is in Ii then insert (end, EOI) in next[i] and “accept” in action[i, EOI]. (3) The entries for substate i.k and the nonterminals X of the goto part are determined as follows: — If [A → α · Rdriver , Rtester X β] is in Jk of the sequence Ii and GOTO(Ii , X , Rtester ) = I j then insert “Rtester : j ” in goto[i.k, X ]. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

54

•

December 8, 2004

22:0


— If [A → α · Rdriver X β] or [A → · X β] is in Jk of the sequence Ii and GOTO(Ii , X , ∅) = I j then insert “T: j ” in goto[i.k, X ].

The action and goto parts of the XpLR parsing table are constructed as in the LR parsing tables. The action conditions and the entries in the column next are constructed as follows: — a shift or goto action in substate i.k has a sequence of tester relations Rtester as an action condition if and only if the set of items Jk of the sequence Ii corresponding to state i contains an item with a dot preceding a sequence Rtester . — the entry next[i.k] contains the pair (Rdriver , x) if and only if the set of items Jk of the sequence Ii corresponding to state i contains an item with a dot preceding a sequence Rdriver , Rtester , and the vsymbol x. REFERENCES AHO, A., SETHI, R., AND ULLMAN, J. 1987. Compilers Principles ,Techniques, and Tools (Series in Computer Science). Addison-Wesley. ALDERSON, A. 1991. Meta-CASE technology. In Software Development Environments and CASE Technology. Lecture Notes in Computer Science, vol. 509. Springer-Verlag, 81–91. BARDOHL, R. 2002. A visual environment for visual languages. Sci. Comput. Program. 44, 2 (Aug.), 181–203. BARDOHL, R., ERMEL, C., AND WEINHOLD, I. 2002. AGG and GenGED: Graph transformationbased specification and analysis techniques for visual languages. In Proceedings of Graph ¨ Transformation-Based Tools (GraBaTs’02) (Barcelona, Spain), T. Mens, A. Schurr, and G. Taentzer, Eds. ENTCS 72. Elsevier. BELL, R. AND SHARON, D. 1995. Creating integrated environments. IEEE Softw. 12, 2 (March), 76–85. ¨ , A., AND TAENTZER, G. 2000. Efficient parsing of visual languages based on BOTTONI, P., SCHURR critical pair analysis and contextual layered graph transformation. In Proceedings of 16th IEEE Symposium on Visual Languages. IEEE Computer Society Press, Seattle, WA, 59–60. CHANG, S. 2000. Multimedia Software Engineering. Kluwer Academic Publishers. CHANG, S. K., POLESE, G., THOMAS, R., AND CIBELLI, M. 2003. Visual authorization modeling with applications to electronic commerce. IEEE Multimedia Magazine 10, 1 (March), 44–54. CHEN, P. 1985. Database design based on entity and relationship. In Principles of Database Design, S. B. Yao, Ed. Prentice-Hall, NJ, 174–210. CHMURA, A. AND CROCKETT, H. D. 1995. Point counterpoint: What’s the proper role for CASE tools. IEEE Softw. 12, 2 (March), 18–20. CHOK, S. AND MARRIOT, K. 1995. Parsing visual languages. In Proceedings of the 18th Australian Computer Science Conference. Australian Computer Science Communication, vol. 17. 90– 98. CHOK, S. AND MARRIOT, K. 2003. Automatic generation of intelligent diagram editors. ACM Trans. Comput.-Hum. Interact. 10, 3 (Sept.), 244–276. COAD, P. AND YOURDON, E. 1991. Object Oriented Analysis. Yourdon Press Computing. CONALLEN, J. 1999. Modeling web application architectures with UML. Comm. ACM 42, 10 (Oct.), 63–70. COSTAGLIOLA, G., DE LUCIA, A., OREFICE, S., AND POLESE, G. 2002. A classification framework to support the design of visual languages. J. Vis. Lang. Comput. 13, 6 (Dec.), 573–600. COSTAGLIOLA, G., DE LUCIA, A., OREFICE, S., AND TORTORA, G. 1995. Efficient parsing of data flow graphs. In Proceedings of 7th International Conference on Software Engineering and Knowledge Engineering (SEKE’95). Rockville, MD, 226–233. COSTAGLIOLA, G., DE LUCIA, A., OREFICE, S., AND TORTORA, G. 1997. A parsing methodology for the implementation of visual systems. IEEE Trans. Softw. Eng. 23, 12 (Dec.), 777–799. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

55

COSTAGLIOLA, G. AND DEUFEMIA, V. 2003. Visual language editors based on LR parsing techniques. In Proceeding of SIGPARSE/ACL 8th International Workshop in Parsing Technologies (Nancy, France). 79–90. COSTAGLIOLA, G., DEUFEMIA, V., FERRUCCI, F., AND GRAVINO, C. 2001. On the pLR parsability of visual languages. In Proceedings of IEEE International Symposium on Human-Centric Computing Languages and Environments (HCC’01) (Stresa, Italy), IEEE Computer Society Press. 49–50. COSTAGLIOLA, G., FRANCESE, R., RISI, M., TORTORA, G., AND DE LUCIA, A. 2003. Rapid development of process modeling tools. In Proceedings of the 5th International Conference on Enterprise Information Systems (ICEIS’03) (Angers, France). 301–306. COSTAGLIOLA, G. AND POLESE, G. 2000. Extended positional grammars. In Proceedings of 16th IEEE Symposium on Visual Languages. IEEE Computer Society Press, Seattle, WA, 103– 110. CRUZ, I. AND LUCAS, W. 1997. Delaunay M M : A visual framework for multimedia presentation. In Proceedings of 13th IEEE Symposium on Visual Languages. IEEE Computer Society Press, 216–223. 3 DE LARA, J. AND VANGHELUWE, H. 2002. AToM : A tool for multi-formalism and meta-modelling. In 5th International Conference FASE 2002 (Grenoble, France). Lecture Notes in Computer Science, vol. 2306. Springer-Verlag, 174–188. DILLER, A. 1992. Z: An Introduction to Formal Methods. John Wiley, NY. EBERT, J., SUTTENBACH, R., AND UHE, I. 1997. Meta-CASE in practice: A case for KOGGE. In Proceedings of 9th International Conference CaiSE’97. Lecture Notes in Computer Science, vol. 1250. Springer-Verlag, 203–216. ERMEL, C., RUDOLF, M., AND TAENTZER, G. 1999. The AGG approach: Language and environment. In Handbook on Graph Grammars and Computing by Graph Transformation: Applications, Languages, and Tools, H. Ehrig, G. Engels, H. Kreowski, and G. Rozenberg, Eds. World Scientific Press, Singapore, 551–604. FARGEMAND, O. AND OLSEN, A. 1994. Introduction to SDL-92. Comput. Netw. ISDN Syst. 26, 1143– 1167. FEDER, J. 1971. Plex languages. Inform. Sci. 3, 225–241. FERGUSON, R., HUNTER, A., AND HARDY, C. 2000. Metabuilder: The diagrammer’s diagrammer. In Proceedings on Diagrams 2000. Lecture Notes in Computer Science, vol. 1889. Springer-Verlag, 407–421. FERRAIOLO, J. 2001. Scalable vector graphics (SVG) 1.0 specification. Tech. rep., W3C Recommendation. (Sept.). FERRUCCI, F., PACINI, G., SATTA, G., SESSA, M., TORTORA, G., TUCCI, M., AND VITIELLO, G. 1996. Symbol-relation grammars: A formalism for graphical languages. Inf. Comput. 131, 1 (Nov.), 1–46. FISHER, A. S. 1992. CASE: Using Software Development Tools, 2nd Ed. John Wiley and Sons, NY. GOLIN, E. 1991. Parsing visual languages with picture layout grammars. J. Vis. Lang. Comput. 2, 4 (Dec.), 371–394. GOODLAND, M. AND SLATER, C. 1995. SSADM Version 4: A Practical Approach. McGraw-Hill. HAREL, D. 1988. On visual formalisms. Comm. ACM 31, 5 (May), 514–530. ¨ HECKEL, R., KUSTER , J., AND TAENTZER, G. 2002. Confluence of typed attributed graph transformation systems. In Proceedings of 1st International Conference on Graph Transformation (Barcelona, Spain). A. Corradini, H. Ehrig, H.-J. Kreowski, and G. Rozenberg, Eds. Lecture Notes in Computer Science, vol. 2505. Springer-Verlag. 161–176. IEC. 1993. Part 3: Programming languages, IEC 1131-3. Tech. rep., International Electrotechnical Commission, Geneva. ISAKOWITZ, T., STOHR, A., AND BALASUBRAMANIAN, E. 1995. RMM: A methodology for structured hypermedia design. Comm. ACM 38, 8 (May), 34–44. JARZABEK, S. AND HUANG, R. 1998. The case for user-centered CASE tools. Comm. ACM 41, 8 (Aug.), 93–99. JOHNSON, S. 1978. YACC: Yet Another Compiler Compiler. Bell Laboratories, Murray Hills, NJ. KELLY, S., LYYTINEN, K., AND ROSSI, M. 1996. MetaEdit+: A fully configurable multi-user and multitool CASE and CAME environment. In Proceedings 8th International Conference CAiSE’96, ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

56

•

December 8, 2004

22:0


P. Constantopoulos, J. Mylopoulos, and Y. Vassiliou, Eds. Lecture Notes in Computer Science, vol. 1080. Springer-Verlag, 1–21. MARRIOTT, K. 1994. Constraint multiset grammars. In Proceedings of 10th IEEE Symposium on Visual Languages. IEEE Computer Society Press, St. Louis, MO, 118–125. MARRIOTT, K. AND MEYER, B. 1998. Visual Language Theory. Springer-Verlag, NY. MCCLURE, C. 1989. CASE is Software Automation. Prentice-Hall, Englewood Cliffs, NJ. MINAS, M. 1997. Diagram editing with hypergraph parser support. In Proceedings of 13th IEEE Symposium on Visual Languages (Isle of Capri, Italy). IEEE Computer Society Press, 226–233. MINAS, M. 2000. Hypergraphs as a uniform diagram representation model. In Proceedings of 6th International Workshop on Theory and Application of Graph Transformations (TAGT’98). Lecture Notes in Computer Science, vol. 1764. Springer-Verlag, Paderborn, Germany, 281–295. MINAS, M. 2002. Concepts and realization of a diagram editor generator based on hypergraph transformation. Sci. Comput. Program. 44, 2 (Aug.), 157–180. MINAS, M. 2003. Bootstrapping visual components of the DiaGen specification tool with DiaGen. In Proceedings of International Workshop on Applications of Graph Transformations with Industrial Relevance (AGTIVE’03). Charlottesville, VA, 391–405. ¨ , A. 2001. Statecharts modeling contest. Symposia on Human-Centric ComMINAS, M. AND SCHURR puting Languages and Environments (HCC’01). MUSTO, A., POLESE, G., COSTAGLIOLA, G., AND TORTORA, G. 2001. Syntactic modeling of UML diagrams and their automatic transformation into RDBMS based models. In Proceedings of WTUML: Workshop on Transformations in UML (Genova, Italy). NASSI, I. AND SHNEIDERMAN, B. 1973. Flowchart techniques for structured programming. ACM SIGPLAN Notices 8, 8 (Aug.), 12–26. OBJECT MANAGEMENT GROUP. 2003a. UML specification version 1.5. Tech. rep., OMG. OBJECT MANAGEMENT GROUP. 2003b. XML metadata interchange (XMI) specification version 2.0. Tech. rep., OMG. ¨ , A. 1996. A graph based framework for the implementation of visual enREKERS, J. AND SCHURR vironments. In Proceedings 12th IEEE International Symposium on Visual Languages (Boulder, CO). IEEE Computer Society Press, 148–157. ¨ , A. 1997. Defining and parsing visual languages with layered graph gramREKERS, J. AND SCHURR mars. J. Vis. Lang. Comput. 8, 1 (Feb.), 27–55. ROSS, D. AND SCHOMAN JR., K. 1977. Structured analysis for requirement definition. IEEE Trans. Softw. Eng. 3, 1 (Jan.), 6–15. RUBIN, R., WALKER II, J., AND GOLIN, E. 1990. Early experience with the visual programmer’s workbench. IEEE Trans. Softw. Eng. 16, 10 (Sept.), 1107–1121. RUMBAUGH, J., JACOBSON, I., AND BOOCH, G. 1998. The Unified Modeling Language Reference Manual (Object Technology Series). Addison-Wesley. ¨ ¨ , A., WINTER, A., AND ZUNDORF , A. 1999. The PROGRES approach: Language and environSCHURR ment. In Handbook on Graph Grammars and Computing by Graph Transformation: Applications, Languages, and Tools, H. Ehrig, G. Engels, H. Kreowski, and G. Rozenberg, Eds. World Scientific Press, Singapore, 487–550. SERRANO, J. A. 1995. The use of semantic constraints on diagram editors. In Proceedings 11th IEEE International Symposium on Visual Languages (Darmstadt, Germany). IEEE Computer Society Press. 211–216. SORENSON, P. G., FINDEISEN, P. S., AND TREMBLAY, J. P. 1996. Supporting viewpoints in Metaview. In Proceedings of Viewpoints’96 (San Francisco), ACM. 237–241. TAENTZER, G. 2000. AGG: A tool environment for algebraic graph transformation. In Proceedings of the International Workshop on Applications of Graph Transformations with Industrial Relevance (AGTIVE’99). Lecture Notes in Computer Science, vol. 1779. Springer-Verlag, 481–490. WALDEN, K. AND NERSON, J.-M. 1995. Seamless Object-Oriented Software Architecture: Analysis and Design of Reliable Systems. Prentice-Hall, Englewood Cliffs, NJ. WITTENBURG, K. 1992. Earley-style parsing for relational grammars. In Proceedings 8th IEEE International Workshop on Visual Languages (Seattle, WA). IEEE Computer Society Press, 192–199. ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004.

P1: IAZ ACMJ018-02

ACM-TRANSACTION

December 8, 2004

22:0


•

57

WITTENBURG, K. AND WEITZMAN, L. 1998. Relational grammer: Theory and practice in visual language interface for process modeling. In Visual Language Theory, Marriot, and Meyers 1998. Springer-Verlag, NY 193–217. YOURDON, E. 1989. Modern Structured Analysis. Prentice-Hall, Englewood Cliffs, NJ. ZHANG, K., ZHANG, D., AND CAO, J. 2001. Design, construction, and application of a generic visual language generation environment. IEEE Trans. Softw. Eng. 27, 4 (Apr.), 289–307. Received October 2002; revised November 2003 and June 2004; accepted August 2004


A Framework for Modeling and Implementing Visual ...

A Framework for Modeling and Implementing Visual ...

Suggest Documents

TOWARDS IMPLEMENTING A FRAMEWORK FOR MODELING ...

a framework for assessing and implementing cloud

eTOXlab, an open source modeling framework for implementing ...

A Systematic Framework for Implementing Concurrent ...

A framework for implementing social manufacturing ...

A Generic Framework for Implementing Real-Time

A Framework for Implementing Realistic Custom ...

A practical framework for implementing Quality by

A Framework for Implementing Realistic Custom

a framework for implementing quick response ...

implementing a sustainable livelihoods framework for ... - CiteSeerX

ASL: A Framework for Modeling and

A framework for modeling and simulating energy

A framework for scientific data modeling and

A conceptual modeling and simulation Framework for

An Experimental Framework for Implementing and

A Framework for Visual Notation Exchange - CiteSeerX

A Framework for Uncertainty-Aware Visual Analytics

a Visual Framework for Multimedia Presentation - Computer

A VISUAL ANALYTICS FRAMEWORK FOR LARGE ... - Cumincad

MViews: A Framework for Developing Visual Programming ...

A Framework for Visual Information Retrieval

Simbrain: A visual framework for neural network

A geometric framework for nonlinear visual coding