A Component-Based Visual Environment Development Process G. Costagliola, R. Francese, M. Risi, and G. Scanniello Dipartimento di Matematica ed Informatica Università di Salerno - Via S.Allende - 84081 Baronissi (SA)
{gencos, francese, mrisi, gscanniello}@unisa.it
A. De Lucia RCOST –Dipartimento di Ingegneria Università del Sannio - Palazzo Bosco Lucarelli, Piazza Roma - 82100 Benevento
[email protected]
ABSTRACT We present the Component-Based Visual Environment Development (CB-VED) process for building visual language environments and introduce the Visual Language Desk (VLDesk) system supporting its implementation. The proposed approach is based on software reuse at different granularity levels and enables incremental development. The VLDesk exploits all the knowledge gained from the development of the Visual Language Compiler-Compiler tool extending its functionalities with many adjunctive features useful in the presented development process. One of the aims of this research consists of the application of software engineering techniques to the incremental development of visual language environments.
Keywords visual environment, visual language, methodology, development process, component development
1. INTRODUCTION It is common opinion that the effective use of a visual language requires a visual programming environment to support the given language by enabling the drawing and the processing of the visual language sentences [1,7]. Visual programming environments for specific application domains are usually implemented by using ad hoc techniques. On the other hand, by analyzing the characteristics of visual languages (VLs), it is possible to determine several common aspects. In particular, VLs are syntactically described by graphical objects (visual symbols), and by the relations holding between the objects involved into visual sentences. The formalization of such characteristics allows the definition of development processes and tools appropriate for the implementation of visual languages belonging to different application domains. Many high level tools have been proposed for the generation of visual environments. The main difference among them is given by the grammar formalism they adopt. As an example, DiaGen [11] is based on hypergraph grammars and allows the visual language designer to develop diagram editors. It consists of a framework of Java classes that let the designer edit and analyze
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, ot republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SEKE '02, July 15-19, 2002, Ischia, Italy. Copyright 2002 ACM 1-58113-556-4/02/0700...$5.00.
diagrams, and a generator program that can produce Java source code for most of the functionality of the diagram language. The interface of the target environment is very friendly, but the system does not provide an integrated visual environment for the generation of visual environments and most of the work has to be made by using a traditional editor; moreover, the types of available attaching points are limited. VisPro is an environment consisting of a set of visual programming tools [14]. It uses reserved graph grammars to express diagrammatic Visual Programming Languages. The VisPro framework customizes a target visual language by specifying some aspects of the target domain. VLPEG is a visual environment generator supporting a methodology for rapid prototyping based on the syntactic formalism of Symbol-Relation Grammars (SR). In [8] a brief description of the methodology supported by VLPEG is given. In this paper, we introduce the Component-Based Visual Environment Development (CB-VED) process for designing and implementing VLs by automatically generating visual programming environments. The various steps needed for generating a visual environment have been identified and formalized. The result of this study is a well defined methodology that provides guide lines for designing the formal models underlying the visual languages to be developed. To effectively build efficient visual environments using the proposed methodology, we have implemented the Visual Language Desk (VLDesk) System. VLDesk is an integrated environment that supports the visual language developer in all the phases of the CB-VED process. It exploits all the knowledge gained by the authors from the definition and implementation of the Visual Language Compiler-Compiler tool [3] and extends its functionalities by providing many adjunctive features useful in the CB-VED process. The proposed methodology is the result of an attempt at applying software engineering methods to the development of visual languages, such as prototyping and joint application development, incremental development, and component-based software engineering [12]. In the first phase of the process a first visual environment prototype is constructed jointly by a small number of analysts and users. In the following phases of the process the visual environment is incrementally developed. User validation can be performed on each increment. This enables to concentrate on a small part of the development of the visual environment and to reduce the risks. Reuse of visual language components is encouraged during the different phases of the development process and includes reuse of a full visual language or intermediate artifacts, such as graphical objects or grammar production rules. The rest of the paper is organized as follows. Section 2 describes our approach and its key components, while in Section 3 we present the details of the proposed development process and shows examples of visual environment construction. Finally, conclusions are given in Section 4.
- SEKE '02 - 327 -
environment. Users actively provide their expertise, support and assistance to the language developer.
2. THE APPROACH Four are the pillars we propose to effectively implement a visual language programming environment: the VLDesk, for the automatic generation of visual programming environments, people properly skilled, heavy user collaboration and the CBVED, a coherent development methodology that provides guidelines detailing how the various phases have to be accomplished. In the following, we illustrate each of the key components.
2.1. The Visual Language Desk system In this section we briefly describe the Visual Language Desk (VLDesk), a system for the automatic generation of visual programming environments supporting all the phases of the CBVED process. This system provides a “desk” where a developer can find an integrated set of tools supporting the whole process of visual language development. The main components of VLDesk are: the Symbol Editor, the Visual Production editor, the Textual Grammar Editor and the Language Inspector. The Symbol Editor supports the language developer in drawing the language visual symbols and allows him/her to associate the syntactic properties to each of them. The symbols of a given language are collected into a dictionary. The Visual Production editor is a visual component supporting the language designer in the visual grammar specification, by drawing the grammar rules. Such a specification produces a YACC-like definition of the visual environment. Since it does not completely describe the syntax and semantics of the given language the designer can further refine it by the Textual Grammar Editor. The lexical analyzer part for a symbol is automatically generated by selecting the symbol from the dictionary. In the case of hierarchical visual languages [5] VLDesk allows a designer to use the Language Inspector tool to easily navigate through the specifications of the component visual languages. A hierarchical visual language is a language whose vocabulary contains symbols that can be annotated with textual or visual sentences from the same or another visual language. As an example, a flowchart visual symbol can be annotated by textual Pascal-like code. Once the language specification has been provided, the tool automatically generates an integrated Visual Programming Environment (VPE), composed by a visual sentence editor and a compiler for processing them. The compiler is based on an efficient LR-like parser [6]. The VLDesk system maintains a repository of visual languages previously developed that can be reused.
2.2. The developer According to our approach, the language developer needs specific skills for appropriately using the VLDesk, such as basic knowledge of formal visual language theory and, in particular, expertise in the Extended Positional Grammar formalism [6] and YACC [10]. Moreover, he/she has to be skilled in Object Orientation programming.
2.3. The user The user is largely involved in the entire development process. He/she is an expert in the language domain but usually does not have skills, time and desire to develop a visual programming
2.4. The methodology The proposed methodology guides the designer during the development of a visual environment by using an incremental development process. A visual environment implements one or more visual languages, as in the case of a visual environment for UML that, for each project collects several sentences in the various UML diagrammatic languages. The phases of this development process, illustrated in Figure 1, can be summarized as follows. The first phase consists of using the VLDesk as prototyping tool. The analyst and the user work together, starting from a summary description of the visual environment characteristics. They identify the visual languages involved in the final environment and their interrelationships. For each language the analyst sketches the graphical aspect of the symbols and of the visual sentences. In this phase the analyst makes use of the VLDesk to produce a first visual environment mock-ups prototype [12] containing a palette for drawing sentences. This prototype facilitates the communication between the user and the analyst to discuss about the syntax and the semantics of the single visual languages. User Requirements
VL Component Library
Prototyping
Requirement Specification and Visual Language Diagram design
Development
Prototype
Visual Environment Specifications
Visual Environment
Figure 1. The Component Based Visual Environment Development process The developer details the requirements in the Visual Environment Specification document, where it specifies the user requirements and the relationships between the different visual languages of the Visual Environment. In particular, if a symbol of a visual language L can be annotated with a sentence of a visual language L’, then we have an annotation relation between L and L’. Figure 2 shows the example of visual language annotation diagram used in the case study presented in this paper and described in the following. The annotation relation between the Class Diagram and Statechart Diagram visual languages allows for drawing a class diagram and associating a dynamic behavior to each class in the diagram with a statechart. The recursive relation on the Statechart Diagram visual language indicates that a symbol of a statechart diagram can be annotated with another statechart diagram, obtaining a lower level description of the object behavior. The development phase in Figure 1 builds the Visual Environment in an incremental way, enabling reuse of available components.
- SEKE '02 - 328 -
ith increment
Class Diagram
Statechart Diagram
Such components include intermediate artifacts, such as graphical objects, grammar components, and semantic rules, or entire visual environments previously developed. Indeed, once developed, each visual environment is translated into a Visual Component Module (VCM). Each VCM is a node in the visual language annotation diagram. If an annotation relation exists between two visual language L and L’, then the a call might arise from the VCM of L to the VCM of L’. The main VCMs correspond to the source visual languages in the visual language annotation diagram.
VL Component Library
Symbol Development
Syntax Development
User Specification
Symbol Design
Symbol Implementation
Symbol Testing
Syntax Analysis
Syntax Design
Syntax Implementation
Syntax Testing
Semantics Analysis
Semantics Design
Semantics Implementation
Semantics Testing
Figure 4. Dependences between the steps of the i-th increment
Figure 2. A language annotation diagram
Prototype
Symbol Analysis
3. THE DEVELOPMENT PROCESS In this section we detail the proposed development process shown in Figure 1. In particular, as a case study, we will focus our attention on the development of a visual environment for documenting the static structure of a system and its dynamic behavior. To this aim, two well known visual languages will be employed: the UML Class Diagrams [13] and Statecharts Diagrams [9].
3.1. Prototyping Understanding the semantics and syntactic characteristics of a visual programming language is usually a hard task. As a consequence, if the language is not appropriately formalized, it is difficult to implement it as well as to establish exactly which features the visual language compiler should have. During a Joint Application Development session the symbol appearance is sketched by using the VLDesk symbol editor and the analyst implements a prototype of the visual environment that does not make syntactic and semantics checks. The mock-ups prototype released at the end of the first iteration allows for composing visual sentences with the defined symbols. Thus, the user can immediately try to draw sentences and refines its requirements on the symbol appearance and on the syntax and semantic of the visual languages. In this phase the analyst can identify in the VLDesk repository reusable Visual Component Modules that can be shown to the user.
Language Hierarchy Specification
Symbol Increments
Syntax Increments
Semantics Development Semantics Increments
Figure 3. The development process of a Visual Component The unavailable Visual Languages have to be implemented by developing their symbols, syntax and semantics, following the process depicted in Figure 3. Each phase produces a number of incremental versions of the product and its intermediate artifacts. Feedback loops between the phases allow the developer to add in incremental way new functionalities. As shown in Figure 4, each increment is the result of the application of the linear sequence of steps analysis-design-implementation-testing. Some steps of the various phases can be realized concurrently, but obviously there exists some dependences among them. As an example, for the ith iteration it is not possible to proceed to the semantics analysis if the syntax analysis has not been performed. Figure 4 displays the complete set of dependences between the steps of the ith increment.
3.2. Requirements specification and visual language diagram design In this phase the language developer formalizes the requirements, according to the discovered components. The proposed approach let a designer implement a visual language by trying to maximize the reuse of existing documentation and components. Referring to our case study, we decide to follow this guideline and represent the dynamic aspects of the object belonging to a given class by using Statecharts diagrams [9], previously implemented as shown in [2]. In this sense, we are able to reuse an entire visual language component, with its symbols, syntax and semantics. The final visual environment will present two visual languages, Class Diagram and Statechart Diagram related as shown in Figure 2.
3.3. Development of visual components In this section we describe the development process of a Visual Component that follows the phases depicted in Figure 3.
- SEKE '02 - 329 -
3.3.1 Symbol development
3.3.1.2 Symbol design and implementation
The symbol development phase produces an increment having a deeper specification of the symbol appearance and their syntactic attributes. The steps followed during each iteration are analysis, design & implementation and testing.
The symbol design & Implementation step focuses on how information is given to and captured by the user and, as a consequence, is a user-focused activity. As a matter of fact, the visual symbols define the ways in which the user interacts with the visual language. In our methodology each visual symbol is associated to a set of syntactic attributes. A visual sentence is formed by selecting a multiset of symbols and instantiating their syntactic attributes. As a very simple example, the sentence aaab has four symbols each of them having as a syntactic attribute a string position instantiated respectively to 1, 2, 3, and 4. The type of syntactic attributes associated with the symbols of a visual language and the type of relations that can be used between symbols are strongly related and define a syntactic model [5,6]. As an example, types of syntactic attributes such as attaching regions allow symbols to be connected through links while containment areas allow symbols to be included one into the other. Let us consider Figure 6 representing a visual sentence belonging to the UML class diagram. Such visual language can be described by a Graph syntactic model: the syntactic attributes of this model are attaching regions and the relations are connections between symbols. A region can be a point, a line or an area of a symbol to which links can be attached for creating connections. In Figure 6, each symbol has only one attaching region corresponding to its perimeter.
3.3.1.1 Symbol analysis The Symbol Analysis step refines the appearance of the main elements of the language. A visual language is usually employed for facilitating the communication between human and computers, or between humans. The symbol appearance has to be accurately designed because if it does not appropriately respect the meaning associated to the given symbol, the visual language is not easy to learn and use. In our case study, we have chosen to represent the static structure of a system by using Class Diagrams, where a Class Diagram is a collection of declarative model elements: classes, interfaces and their relationships. Building a class model involves identifying the classes that should exist in our system. As known, the class typologies are: simple, parameterized, abstract and standard [13]. The class icon element representing a standard class, is simply a rectangle divided into three divisions: the Top division contains the class name, the middle one contains the variable member list and the bottom division contains the member function list. Often, the last two divisions are omitted, and even if they are present, they do not show any attribute and method. In this case we have a simple class, whose appearance, drawn by the Symbol Editor, is shown in Figure 5. An abstract class is obtained by adding the property {abstract} on the class icon. UML class diagram relationships such as composition, inheritance, aggregation, association and dependency are represented by visual symbols.
Figure 6. A UML class diagram sentence
Figure 5. A VLDesk Symbol Editor screendump for the simple class symbol VLDesk supports the documentation of this step by associating a natural language description to each element of the language. As an example, by using this facility we can associate to the symbol shown in Figure 5 its meaning, i.e. "A simple class describes a set of objects with an equivalent role in the system" [13].
Other syntactic models can be employed to define and implement a visual language. The syntactic model Box defines the context of a given symbol through the coordinates of the upper-left and the lower-right vertices of its bounding box. In this model, visual sentences can be built by combining symbols through relations such as containment, overlapping, horizontal and vertical concatenations, etc. As another example, the statecharts can be modeled by using relations such as contain and sibling together with connections. In particular, the relation sibling binds two symbols to appear at the same nesting level. Figure 7 shows three symbols at the same level, respecting a valid sibling relation, and all of them are contained in the symbol Circle. The VLDesk Symbol Editor provides the designer with tools to associate a symbol with its syntactic attributes in a visual way. Proper palettes allow for adding attaching points, lines and areas, and containment areas of different shapes to a symbol.
- SEKE '02 - 330 -
Visual grammar design A Visual Grammar is a context-free-like grammar consisting of a terminal vocabulary a non-terminal vocabulary, a start symbol, and a set of visual productions. The terminal vocabulary is the set of all the visual symbols that can be found in an admissible visual sentence, and the non-terminal vocabulary is the set of symbols used as variables to describe combinations of terminals and nonterminals. The start symbol is the non-terminal from which the parsing process starts. A production has a non-terminal on the left hand side, and a combination of symbols and variables on the right hand side. The VLDesk system provides a visual environment for the specification of visual grammars. Figure 8 depicts a VLDesk screendump showing an example of visual production for the Statecharts language, where a dotted line arrow represents the production arrow. Figure 7. A Statecharts sentence representing the class Circle The annotation relation between Class and Statechart Visual Languages depicted in Figure 2 has to be specified by selecting which symbols of the Class visual language have to be annotated by a sentence belonging to Statecharts. Thus, it is possible to examine the dynamic behaviour of the objects belonging to a given class. The VLDesk symbol Editor has a feature allowing the developer to annotate a given symbol with a sentence of another visual language. During this phase the reuse of visual objects is encouraged. Each visual language has its own symbol repository. While defining a new language, VLDesk makes it possible to access symbols from previously defined languages and import them, together with their semantics, syntactic documentation and graphical representation.
3.3.1.3 Symbol testing The symbol testing step consists of verifying and validating the increment produced during this phase. Thus, the developer releases a running visual programming environment to the user and, with his/her support, validates the language requirements. In particular, he/she evaluates the symbol appearance expressiveness and the relations between the symbols.
3.3.2 Syntax development During this phase the syntactic structure of the visual languages to be implemented is defined in an incremental way. The designer may decide to re-use visual language specifications (previously defined) presenting similar syntactic structure. This can be done also in the case they have different graphical aspects.
3.3.2.1 Syntax analysis The syntax analysis step consists of the identification of a set of correct visual sentences.
3.3.2.2 Syntax design During the Language Syntax design the developer specifies the syntactic structure of well-formed visual languages. In particular, the syntactic specification is performed by considering two different levels: the visual grammar and the eXtended Positional Grammar.
Figure 8. Visual Production and associated XPG production Here, the non-terminal nodoiter [1] is recursively defined as a nodoiter [2]; the latter is connected to an arrow which is connected in turn to a simple class symbol. The dotted line labeled by ∆ indicates that the syntactic attributes of nodoiter [1] are the same as those of nodoiter [2]. In other words all that is attached to nodoiter [1] is also attached to nodoiter [2] after the rule application (or viceversa). eXtended Positional Grammar design In the last years, many efforts have been made in the direction of definition, characterization and parsing of visual languages. The eXtended Positional Grammar (XPG, for short) is the theoretical model underlying the VLDesk system for the definition and implementation of visual languages [6]. The VLDesk assists the language developer in the definition of the language syntax by using the Visual Grammar, and generates the XPG productions in an automatic way. Figure 8 shows the corresponding XPG production in the left-top corner of this figure. This rule states that the symbol nodoiter [1] derives a visual sentences formed by three symbols: nodoiter [2], ARROW, and CLASS. The notation indicates that the attaching region 1 of nodoiter [2] is connected to the first attaching point of ARROW. Similarly, indicates that the second attaching point of ARROW is connected to the attaching region 1 of CLASS. Moreover, classAnnotation indicates that the symbol CLASS is annotated with a visual language. The VLDesk also supports the language developer during the definition of the relations between the visual symbols.
- SEKE '02 - 331 -
Syntax reuse VLDesk encourages syntax reuse. As a matter of fact, reuse of the language syntax improves reliability, because these components have already been previously tested, and the design and implementation errors have been discovered and eliminated. The designer can reuse existing grammars even if they have been developed for different aims. In fact, it turns out that many visual languages share similar syntactic structures. Exploiting this feature, VLDesk generated environments can incorporate several different language compilers (actions) for the same visual language. The compilers share the same syntactic checks but implement different semantic actions. For example, an environment for flowcharts may be employed to translate the same sentence successively both in C and Java code.
3.3.2.3 Syntax implementation This phase makes use of: 1. 2. 3.
the knowledge about the visual languages involved and the annotation relationships they participate. an XPG grammar skeleton and the specification of the symbols of each language; the design of the semantics for each language and for the final environment.
Based on these inputs the developer has to build a visual environment by providing a YACC grammar with action rules for each language. In particular, if a symbol of a visual language L can be annotated with a sentence of a visual language L’, then the grammar for L has to specify in which context this can happen. In the following we will sketch how to obtain a YACC specification from an XPG grammar skeleton. As an example, the XPG production skeleton built on the visual production of Figure 8 is translated into the following YACC production:
The visual annotation associated to the symbol CLASS is coded through the non-terminal classAnnotation. The corresponding production is empty and contains an action to call the VCM of the appropriate visual language. In the following we show how the Class Diagram grammar makes a call to the VCM for the Statecharts: classAnnotation : { // Verify if a CLASS symbol is visually annoted if ( DbC.next ( new annoted (StackT(Top,graph), &DbC ))) { // Run the Statecharts VCM on the statechart sentence // associated to the CLASS symbol if(EXEC_VCM (statechartshandle) != 0) { yyerror ("An error is occurred in the VCM execution."); YYABORT; } DbC.limit.pop (); // Get output parameters from the VCM execution ……. } else { yyerror ("The sentence is not defined in the annotation window."); //YYABORT; } }
In order to simplify the translation of an eXtended Positional Grammar schema into a YACC grammar with action rules, the VLDesk Textual Grammar Editor provides a set of graphical interfaces where the developer simply specifies the main characteristics of the productions he needs to implement. Figure 9 shows how VLDesk assists the language developer during the generation of the r1_1 production.
nodoiter : nodoiter r1_1 ARROWS1 r2_1 CLASS classAnnotation { /*implementation of the ∆ rule*/ $$ = new LToken("nodoiter",1,0); (*$$).Reg(1)=(*$1).Reg(1)-(*$3).Reg(1); /* Semantic code */ ... }
where the relations and are coded as the nonterminals r1_1 and r2_1, respectively. For each of them an empty production is created with an action for retrieving the next symbol to be parsed: r1_1 : { Positional_Query = 1; if(! DbC.next(new joint(StackT(Top,graph),1,1,"ARROWS1",2,&DbC))) { Positional_Query = 0; } }
Here, the action queries the input sentence stored in DbC to retrieve an occurrence of the ARROW symbol connected to NODOITER through the r1_1 relation. The global value Positional_Query is set to 1 in case of success and 0 otherwise.
Figure 9. Definition of a relation Figure 10 shows how to specify a visual annotation. It also shows the language inspector windows, presenting the language annotation diagram, useful for navigating between languages.
3.3.2.4 Syntax testing and debugging During this phase both static and dynamic techniques are employed. Static techniques consists of analyzing and checking the requirements document, the visual productions, the extended positional grammar and the YACC specification. On the other hand, dynamic techniques or test, use a running visual language environment implementation.
- SEKE '02 - 332-
Semantics reuse Semantic actions previously developed for other visual languages can be retrieved into a semantic repository. Here, the language designer search for a semantic component by selecting a component name in the list of available components. Once a component has been chosen, it is possible to obtain examples showing the results of its applications and how to use it.
3.3.3.3 Semantics implementation
Figure 10. Visual annotation implementation Defect testing checks hidden defects of a visual programming environment before its delivery to the customer. To help the language developer, VLDesk integrates an interactive debugging tool that can be used for locating and discovering defects. The VLDesk debugger extends the classic definition of compiler debugger to the visual environment case. In particular, the VLDesk debugger shows the shift-reduce operations applied by the parser during each step of the parsing process. In case of an execution of a shift operation, the debugger shows the next symbol examined by the parser in the sentence, and outlines whether the shift operation succeeds. In case of a reduce operation, it shows the production the parser applies. Moreover, the debugger displays the variable contents associated to semantics actions. Let us summarize the main activities of the VLDesk debugger for the defect identification: • • •
activate the parsing process in debug modality; wait for a debug event generated by the parser; examples of debug events are the execution of a shift or reduce operation, the execution of another visual component module; decode and display the event information, i.e., the applied production and the state of the parser stack.
3.3.3
Semantics development
During this phase the semantics actions embedded into the grammar productions are specified and implemented in an incremental way. The developer adds one or more semantic rules to a visual language and rapidly produces an increment that implements it.
3.3.3.1 Semantics analysis The Semantics Analysis step associates the semantic action description to each visual symbol in natural language. Moreover, it gives a brief description explaining how visual symbols are grouped during the parsing, depending on the context.
3.3.3.2 Semantics design During this step the language developer designs the actions to be performed while parsing a visual sentence. Among the others, these actions may regard: 1. 2.
translating the source language in any other language (visual, textual, binary, etc.) providing a dynamic behavior to the input sentences, such as, coloring, moving and resizing symbols, introducing new symbols, etc.
Semantic rules have to be coded in C++ by using the Textual Grammar Editor. Once all the code has been generated the developer builds the final visual environment by selecting the VLDesk Build VCM command.
3.3.3.4 Semantics testing and debugging The VLDesk debugger is useful for detecting semantic routine defects. In particular, it handles the exceptions that can occur when a semantic action is executed.
4. CONCLUSIONS In this paper we have presented the development process for the rapid prototyping of visual languages supported by the Visual Language Desk System. VLDesk provides a “desk” where a developer can find an integrated set of tools supporting the whole process of visual language development. It extends the functionalities of the VLCC tool and it is based on the Extended Positional Grammars formalism. The CB-VED process we have proposed supports software reuse at different abstraction levels and allows to obtain a componentbased deployment relying on heavy user involvement and requiring a small group of highly skilled developers. Visual Environments are seen as reusable Visual Component and can be organized in such a way to associate a sentence of another visual language to a symbol of a given language. The final visual environment is constructed by generating the main Visual Component Modules. In the future we plan, among the other things, to obtain the complete YACC specification in an automatic way.
5. REFERENCES [1] M. Burnett, A. Goldberg and T. G. Lewis, Visual Object-Oriented Programming, Manning Publications Co., 1995. [2] G. Costagliola, V. Deufemia, F. Ferrucci, C. Gravino, “Implementing Statecharts using Extended Positional Grammars”, Statecharts Modeling Contest in Symposium on Human-Centric Computing Languages and Environments (HCC’01), Stresa, (2001) URL=http://www2.informatik.unierlangen.de/VLFM01 /Statecharts/CoDeFeGr.pdf. [3] G. Costagliola, A. De Lucia, S. Orefice, G. Tortora, “Automatic Generation of Visual Programming Environments”, IEEE Computer, pp.56-66, March 1995.
- SEKE '02 - 333 -
[4] G. Costagliola, A. De Lucia, S. Orefice, G. Tortora, A “Parsing Methodology for the Implementation of Visual Systems”, IEEE Transactions on Software Engineering, vol. 23, n. 12, pp. 177-199, December 1997. [5] G. Costagliola, A. De Lucia, S. Orefice, G. Polese, “A Classification Framework for the Design of Visual Languages”, to be published in the Journal of Visual Languages and Computing. [6] G. Costagliola and P. Polese, “Extended Positional Grammars”, Proc. of IEEE Symposium on Visual Language, Seattle, pp. 103-110, Sept. 2000.
[9] D. Harel and A. Naamad, “The Statemate Semantics of Statecharts”, ACM Trans. Soft. Eng. Method., Oct 1996. [10] S.C. Johnson, YACC: Yet another compiler-compiler, Unix Programmer's Manual Vol 2b, 1979. [11] M. Minas and G. Viehstaedt, “DiaGen: A Generator for Diagram Editor Providing Direct Manipulation and Execution of Diagrams”, Proc. 11th IEEE Symp. Visual Language, pp. 203-210. [12] I. Sommerville, Wesley, 1996.
Software
Engineering,
Addison
[7] F. Ferrucci, G. Tortora and G. Vitiello, “Visual Programming”, in Wiley Encyclopedia of Software Engineering, J.J. Marciniak E.D., 2nd edition.
[13] P. Stevens with R. Pooley, Using UML, Addison Wesley, 2000.
[8] F. Ferrucci, G. Tortora, M. Tucci and G. Vitiello, “A System for rapid prototyping of Visual Language Environment”, Proc. IEEE Symp. Human-Centric Computing, Stresa, 5-7 September 2002, pp.382-389.
[14] K. Zhang, D.Q. Zhang and J. Cao, “Design, Construction, and Application of a Generic Visual Language Generation Environment”, IEEE Transaction on Software Engineering, Vol. 7, No. 4, April 2001.
- SEKE '02 - 334 -
