A Framework for Modeling and Implementing Visual Notations With Applications to Software Engineering

Transcription

1 A Framework for Modeling and Implementing Visual Notations With Applications to Software Engineering GENNARO COSTAGLIOLA, VINCENZO DEUFEMIA, and GIUSEPPE POLESE Universitá disalerno 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 Authors address: Dipartimento di Matematica e Informatica, Universitá di Salerno, Via Ponte don Melillo, Fisciano(SA), Italy; {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 USA, fax: +1 (212) , or permissions@acm.org. C 2004 ACM X/04/ $5.00 ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 4, October 2004, Pages

2 432 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

3 A Framework for Modeling and Implementing Visual Notations 433 the literature, there are several arguments in favor of one or the other approach [Minas 1997; Rekers and Schürr 1997; Serrano 1995]. In particular, it is recognized 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

4 434 G. Costagliola et al. 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 A, and the detailed algorithms for constructing XpLR parsing tables are described in Appendix B. 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,

5 A Framework for Modeling and Implementing Visual Notations 435 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. In the following, we will use the term vsymbol also to refer to the type associated to a vsymbol. 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

6 436 G. Costagliola et al. Fig. 2. A visual sentences with both geometric and connection relations (a) and a visual sentence with explicit relations (b). representing a superstate in a statechart [Harel 1988], has one attaching region 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 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

7 A Framework for Modeling and Implementing Visual Notations 437 Fig. 3. A hierarchy of spatial relation types. visual notations of type Graph, Iconic, and so on. Nevertheless, there are visual 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, Entity- Relationships 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 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

8 438 G. Costagliola et al. 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.wewill see that these representations can be converted one into the other, even though the conversions may not be one-toone 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

9 A Framework for Modeling and Implementing Visual Notations 439 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] isgiven by a unique label assigned to the link, plugged into attaching point i of v;inthe 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) 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) isine 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, byusing 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

10 440 G. Costagliola et al. Fig. 6. Attribute-based representation (a) of the activity diagram in Figure 1(b), based on the link labeling in (b). aps x [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)} Linear Representation. Definition 2.2. Given a visual sentence vs ={x 1,..., x n } and a set of relation identifiers R, alinear 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 )ofthe 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 R 1 y 2 R 2 y 3...R n 1 y n, where each R j is a nonempty sequence of type: REL h 1 1,..., RELh i i,..., REL h m m with m 1.

11 Each REL h i i A Framework for Modeling and Implementing Visual Notations 441 in R j denotes the pair (REL h i i, h i ), where REL i R or REL h i i = REL 1 with REL R, REL i labels the edge ( y j hi, y j +1 )ing R,vs, and it relates syntactic attributes of y j +1 with syntactic attributes of y j hi, with 0 h i < j. In the rest of the article, we will denote REL 0 1 simply as REL 1. 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.asanexample, 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 1 2,1 Activ3 LINK1 2,1 Cond LINK 2,1 Activ4 LINK 1 3,1 Activ5 LINK1 2,1, LINK 2,2 Mux LINK 4 2,1 Activ6 LINK 1 3,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 LINK 2,2 Activ5 LINK 1 1,2 Activ4 LINK 1 1,3, LINK 1,2 Cond LINK 1,2 Activ2 LINK 5 1,2, LINK 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,

12 442 G. Costagliola et al. 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.

13 A Framework for Modeling and Implementing Visual Notations 443 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.

14 444 G. Costagliola et al. 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-free 1 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 x 1 R 1 x 2 R 2...x m 1 R m 1 x m,, Ɣ, 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.

15 A Framework for Modeling and Implementing Visual Notations 445 where A is a nonterminal vsymbol, x 1 R 1 x 2 R 2...x m 1 R m 1 x m is a linear representation with respect to POS, where each x i is a vsymbol in N T, and each R j is partitioned in two sub-sequences ( REL h 1 1,..., RELh k h k, REL k+1 k+1,..., ) RELh n n with 1 k n. 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 x 1, x 2,..., x m ; Ɣ 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 x 1,..., x m. As a consequence, if for each production A x 1...x m,, Ɣ 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 Ɣ. We also write α i β 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 = β.

16 446 G. Costagliola et al. 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,wesay that ( y, j )isreachable from (x, k) if and only if one of the following situations occurs: (1) x = y; (2) there exists a production x x 1 R 1 x 2...x i...r m 1 x m,, Ɣ in P such that attribute k of x is synthesized from attribute h of x 1 by means of, and ( y, j )isreachable from (x 1, h). If ( y, j )isreachable 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.

17 A Framework for Modeling and Implementing Visual Notations 447 Fig. 9. The vsymbols for the grammar STD. In the following, the notation Vsym i denotes the attaching point i of the vsymbol Vsym. The set of relations is given by POS ={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 Graph 1 = Graph 1 EDGE 1 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 Node 1 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

18 448 G. Costagliola et al. 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

19 A Framework for Modeling and Implementing Visual Notations 449 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,

20 450 G. Costagliola et al. 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 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 The Stack. An instance of the stack has the general format s 0 X 1 s 1 X 2 s 2... X m s m, where s m is the stack top, X i is a grammar vsymbol, and s i 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.

21 A Framework for Modeling and Implementing Visual Notations 451 Fig. 14. An XpLR(0) parsing table 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, (R driver, x), which drives the parser in selecting the next vsymbol y that is reachable from x, byusing the sequence of driver relations R driver.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: (1) a sequence A 1,..., A n where each A i (i > 0) has the format Rtester i : shift state i, and Rtester i is a possibly empty sequence of tester relations. Moreover, all the relations Rtester 1,..., Rn tester are mutually exclusive. As an example, the entry (1.1, EDGE) infigure 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 B 1,..., B n, where each B i (i > 0) has the format Rtester i : statei, Rtester i is a possibly empty sequence of tester relations. Moreover, all the relations Rtester 1,..., Rn tester are mutually exclusive. A shift or goto action is executed only if all the relations in the corresponding R tester are true, or if R tester 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

22 452 G. Costagliola et al. 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)inthe 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.

23 A Framework for Modeling and Implementing Visual Notations 453 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 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; NEXT = (R driver, x), where R driver = REL h 1 1,..., RELhn n and each REL h i i acts on a syntactic attribute k i of x for i = 1ton let z i be the (h i )-th object below the stack top let next set i ={b b is in D p,itisnot marked as visited, it has an attribute j such that (b, j) isreachable from (x, k i ), z i REL i b holds, and the relation REL i acts on a syntactic attribute of z i and the syntactic attribute j of b, respectively } if i=1...n next set i contains exactly one object b then for each explicit relation REL i in R driver do decrease by 1 the entry in the array COUNTER corresponding to the explicit relation z i REL i b

24 454 G. Costagliola et al. mark the corresponding entry in D p as visited return the row index of b in D p else if i=1...n next set i 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 R driver in the next column are as follows: the special relation start:inthis case Fetch Vsymbol returns the index in D p of the first vsymbol of the visual sentence to parse; the special relation end: inthis 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 )isreachable 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: inthis 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. Onthe 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 Test(COND) let COND = (REL i, 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

25 A Framework for Modeling and Implementing Visual Notations 455 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: Avisual sentence in attribute-based representation and an XpLR(0) parsing table. Output: Abottom-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 fsbbe the first of such substates in s set s = fsb set ip = Fetch Vsymbol(next[ fsb]) 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 R t : shift s then while seq is not empty do extract the current first element R t : shift s from seq if R t is empty or Test(REL h, b) istrue for each REL h R t 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] isempty then let fsbbe the first of such substates in s set s = fsb let b a terminal vsymbol if action[s, b] = reduce A x 1 R 1 x 2 R 2...R m 1 x m,, Ɣ 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] isanon empty sequence seq of conditioned gotos of type R t : s then while seq is not empty do extract the current first element R t : s from seq if R t is empty or Test(REL h, A) istrue for each REL h R t then push A and then s on the stack output the production A x 1 R 1 x 2 R 2...R m 1 x m,, Ɣ exit endwhile if no element has been pushed on the stack then emit syntax error and exit; endif endif

26 456 G. Costagliola et al. 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] ofthe 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 REL h i i in R is tested between the (h i )-th object below the stack top and the object b to be shifted. Otherwise, if Fetch Vsymbol(next[sb]) is null for a substate sbof 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 x 1 R 1 x 2 R 2...R m 1 x m,, Ɣ isaccomplished 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 t q t r t )), where t q is the time required to perform the function Fetch Vsymbol (on next[s]), t r is the time to test each relation, and t is the time to synthesize each syntactic attribute. The parameters m, t q, t r and t may vary from a constant to O(n). Thus, the time complexity of the XpLR parser is polynomial 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, PE), 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 (REL h i i, 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 x i, 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 (REL h i i, 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

27 A Framework for Modeling and Implementing Visual Notations 457 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: NEXT= (Rdriver, x), where R driver = RELh 1 1,..., RELhn n and each REL h i i acts on a syntactic attribute k i of x let z i be the (h i )-th object below the stack top for i = 1tondo let next set i ={b b is in D p,itisnon marked as visited, ithas an attribute j such that (b, j )isreachable from (x, k i ), z i REL i b holds, and the relation REL i acts on a syntactic attribute of z i and the syntactic attribute j of b, respectively } if i=1...n next set i is non-empty then randomly select an object b from i=1...n next set i for each REL i in R driver that is an explicit relation do decrease by 1 the entry in the array COUNTER corresponding to the explicit relation z i REL i b mark the corresponding entry in D p as visited return the row index of b in D p else return null;

28 458 G. Costagliola et al. 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

29 A Framework for Modeling and Implementing Visual Notations 459 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.

30 460 G. Costagliola et al. 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.

31 A Framework for Modeling and Implementing Visual Notations 461 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

32 462 G. Costagliola et al. 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

33 A Framework for Modeling and Implementing Visual Notations 463 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

34 464 G. Costagliola et al. 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.

35 A Framework for Modeling and Implementing Visual Notations 465 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 Schürr [1996, 1997]. Some of these grammar formalisms fall into the category 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