APICES - Rapid Application Development with Graph Pattern

Transcription

1 APICES - Rapid Application Development with Graph Pattern Ansgar Bredenfeld GMD Institute for System Design Technology D Sankt Augustin, Germany bredenfeld@gmd.de Abstract In this paper, we present the novel software design environment APICES. It is specifically tailored to support rapid application development based on network like data structures which are typical for CAD tools, system level design tools or DSP applications. APICES is based on graph patterns. These graph patterns offer high-level functionality far beyond manipulation of simple graphs consisting of nodes and edges. By making graph patterns re-usable within an object-oriented framework architecture and by offering multi-target code generators we are able to provide a powerful environment for prototyping and rapid development of graph-based applications. We demonstrate the productivity gains and the benefits of APICES by rapid application development of a multi-rate digital signal processing tool. 1. Introduction Re-use of software artifacts plays a central role to shorten software development cycles in order to minimize time-to-market. Recent work on design patterns [1][2] and object-oriented frameworks [3] focus at first on re-use of expert design knowledge and secondly on re-use of software components to achieve minimal development time and improved software quality. A shortcoming of general purpose object-oriented modeling tools like [4] is the missing support for data structures which are specific to system level design tools. On the other hand, we face a significant class of applications which are based on graphs, hyper graphs or network-like structures. Such structures are predominant in tools of many application domains, e.g. CAD, electronic design automation, system level design, or workflow. Unfortunately existing graph-oriented software environments, e.g. [5], do not support structuring concepts like multi-port components, instance and interface components, channelbased connectivity, macro construction and hierarchical component structures. These structuring concepts require a conceptual model on a higher level of abstraction than simple graphs consisting of nodes and edges. The objective of our work is to make these concepts reusable in an object-oriented generator environment in order to support rapid application development of system level design tools. Our software design environment APICES is conceptually based on re-usable and extensible graph patterns. It consists of tools for graphical model specification, multitarget code-generation, model centered GUI design and documentation generation. This paper is structured as follows. Section 2 gives an overview of the conceptual model behind APICES, namely graph patterns. Section 3 describes the architecture and tools of APICES and gives some facts and figures concerning the implementation. In section 4 and 5, we report on an application. We successfully used APICES for rapid development of a multi-rate digital signal processing editor/simulator. In section 6 we compare our system with related work before we end with conclusions and an outlook. 2. Graph patterns The starting point of our work was an analysis of typical design representations occurring in electronic design automation tools, i.e., in simulators, in schematic editors, in high-level synthesis tools and in tools for hardware/software co-design and digital signal processing. The design representations found include hierarchical net lists, different types of flow graphs - data flow as well as control flow -, process networks, finite state machines, State- Charts, etc.. Our analysis did not led to a single core model suitable for all these design representations but rather to a set of related models with varying features. Nevertheless, all models are very similar in nature, so that they are deriv-

2 onent External Figure 1. Abstract graph pattern. inheritance aggregation association 0..n 0..1 able from a common core model. We call this common core model abstract graph pattern [6]. Its object model in OMT [7] notation is shown in figure 1. Attributes and methods are omitted to improve legibility. Each variant derived from the abstract graph pattern differs with respect to its features concerning connectivity and hierarchy. We distinguish the following graph pattern variants. Their corresponding OMT notations are sketched in figure 2. Flat onent Graph flat component graphs with local connectivity have component instances which are specified by interface components. A macro is a construct to group related component instances, e.g. for partitioning purposes. onent instances are connected to other component instances locally within a macro by internal channels. s connect the ports of components. flat component graphs with global connectivity support channels between ports of components from different macros. These global connections are modeled by external channels. hierarchical component graphs with local connectivity have additionally macro instances. instances are occurrences of interface components which belong to a macro. They are used to construct folded hierarchical component structures. hierarchical component graphs with global connectivity additionally allow external channels between components in different macros. Graph pattern variants have a set of predefined graph pattern methods. A graph method has the same signature in all graph pattern variants, whereas their method implementations usually vary. Flat graph patterns have more simple method implementations than hierarchical graph patterns; patterns with local connectivity have more simple method implementations than patterns supporting global connectivity. Hierarchical onent Graph Local Connectivity External External Global Connectivity Figure 2. Graph pattern variants.

3 3. APICES environment The abstract graph pattern and its variants are the conceptual base for the software design environment API- CES. Our system consists of a tool set which allows to reuse graph patterns for prototyping and rapid development of graph-based applications Model editor APICES uses state-of-the-art object-oriented modeling concepts as its foundation. This includes object types, methods, typed attributes, different types of relationships (aggregation, association), data encapsulation, and inheritance. The graphical model editor allows to enter the application model by instantiating object types, attributes, inheritance relationships, aggregation relationships and association relationships. In this point, APICES is comparable to object-oriented modeling tools, e.g. [4]. The specific strength of APICES is its support of graph patterns. Graph patterns are simply instantiated in the application model as building blocks. Note, that predefined graph pattern methods are provided for each graph pattern instance. They directly offer manipulation functionality needed to construct and delete network structures, to handle connectivity, to construct and transform component hierarchies, to perform analysis operations, to specify the behavior of interface components and to simulate a network of component instances Code generators Starting from the application model, the code generators of APICES allow to produce code for several target languages. At present, we provide generators for: - a C++ class structure and fully implemented access methods for objects, attributes and relationships, - C++ class structures for each graph pattern instance including optimized predefined graph methods, - a data base schema and access code for an ObjectStore [8] database, - an extension to Tcl [9] which hooks all generated C++ or ObjectStore methods into Tcl, - a customization file for the GUI engine described below, - and a HTML-documentation of the application model. The overall implementation architecture of the APICES environment is shown in figure 3. It illustrates the components of the environment and the data flow between them. All parts belonging to the tool set are shaded. The architecture of the generated application is sketched in the right part of the figure. reads APICES docu method templates model templates mapping rules Framemaker hypertext HTML browser reads application docu model editor code generators APICES Tool user code (Tcl) GUI engine (Tcl/Tk) custom. file for GUI (Tcl) Tcl-wrapper code (C++) C++ sources ObjectStore sources 3.3. Model centered GUI design The model editor is used not only for the specification of the application model but also for the specification of the graphical user interface of the application. This approach allows the seamless integration of model design and GUI design which speeds up prototyping and application development dramatically. We provide simple GUI elements representing objects (rectangles, ovals, bitmaps, images, texts,...) and elements representing relationships (lines, arrows,...). Since our graph patterns are of a high level of abstraction, we are able to support graph pattern specific visualization. Therefore, we offer specific GUI elements for the object types of graph patterns (contexts, macros, interface components, component instances, macro instances, ports and channels) and for hierarchy visualization. The default appearance of networks may be changed by simple customization in the model editor. APICES generates a customization file for a GUI engine. The GUI engine provides means for graphical entry of inter-related objects and (hierarchical) component networks on a canvas. The canvas is subdivided into boxes. Objects may be interactively placed and moved in a box or they may be automatically layouted according to a layout strategy selected for a box. Since an object may appear in several boxes, multiple object views are possible. Two examples for views with different layout strategies are sketched in figure 4. Each object on the canvas has a context-sensitive popup menu. The menu entries, the graphical appearance and the layout of objects or graph pattern instances are customized with the model editor. Note, that the screen shots in File loads loads loads compile Tcl-wrapper compile compile application C++ class library OR ObjectStore library Figure 3. APICES architecture and data flow.

4 relationship specification on model level corresponding relationship visualization on canvas of the GUI source object type box1 target objects source object relationship target object type box2 source object target objects 3100 lines of code. The code generators are Perl and Tcl scripts invoked by the model editor. They access the template database (graph patterns, graph pattern methods) derived from the hypertext. The GUI engine is implemented in Tcl/Tk and comprises 1700 lines of code. It reads a generated customization file and optionally a file containing the application code of the user written in Tcl. At present, APICES is running on SUN (Solaris 2.4/ 2.5) and on PC (Linux or higher). Actual information is available at view1 container style this paper are examples for graphical user interfaces generated by APICES. This includes the model editor itself. An important feature for testing and debugging of complex applications is the capability of the GUI engine to trace all user interactions. Tracing allows to replay interaction sequences which is very helpful for reconstructing complex object configurations precisely. In addition, traces may be used as test patterns to validate the correctness of a generated application after model extensions APICES implementation view2 network style Figure 4. Views of objects in boxes. Graph patterns and their methods are specified in an object-oriented intermediate template form which can be processed by the code generators of APICES. The code generators transform the templates into the corresponding target language syntax (C++, ObjectStore, Tcl language extensions, HTML,...). Transformation rules define how to map templates to the specific syntax of each target language. Adding a new target language to the code generator requires to define a new set of transformation rules. All development documents of APICES are organized in a FrameMaker [10] hypertext document. These development documents comprise: templates for the code generators in intermediate form (graph patterns, graph pattern methods), transformation rules for the target languages, error messages, and documentation templates. Changes to a development document are propagated to all dependent documents by updating cross-references in the hypertext. This approach avoids redundancy in the development documents, it allows to keep all derived documents consistent and it simplifies maintenance, since changes are automatically propagated. We implemented an automatic cross-reference update using FrameMaker in batch mode. The core of the model editor is a C++ class library generated from the meta model of APICES. The model editor functionality is implemented in Tcl/Tk and comprises 4. Application example We used generated design representations for integrating a multi-level fault simulator with a high-level synthesis tool. The synthesis tool was constructed using several graph pattern instances (hierarchical net list, control flow graph with finite state machine, data flow graph). The interested reader is referred to [6] for a detailed description of that application. In this paper, we focus on another example to give an impression of the effort needed to develop a new design tool from scratch. We describe rapid prototyping of a multi-rate digital signal processing (DSP) tool which we needed for an industrial case study in the GSM domain. The tool consists of a graphical data flow editor and a multi-rate simulator. // initialize circuit Behaviour* beh = init_beh(); // create macro as container for processes Beh* mod = beh->create_instset_beh(); // instantiate processes from processbehaviours Process* p39 = mod->instantiate_comp_beh(_source); Process* p42 = mod->instantiate_comp_beh(_serpar); Process* p53 = mod->instantiate_comp_beh(_delay); Process* p58 = mod->instantiate_comp_beh(_pulsformer); Process* p63 = mod->instantiate_comp_beh(_pulsformer); Process* p68 = mod->instantiate_comp_beh(_quadmod); Process* p77 = mod->instantiate_comp_beh(_sink); Process* p84 = mod->instantiate_comp_beh(_para); // connect processes p39->connect_comp_beh(1, p42, 1); p42->connect_comp_beh(3, p63, 1); p42->connect_comp_beh(2, p53, 1); p42->connect_comp_beh(1, p77, 3); p53->connect_comp_beh(2, p58, 1); p58->connect_comp_beh(2, p68, 1); p63->connect_comp_beh(2, p68, 2); p68->connect_comp_beh(4, p77, 1); p68->connect_comp_beh(3, p84, 1); p77->connect_comp_beh(3, p39, 1); // simulation preparation IterProcess s = CreateIterProcess(); mod->resetprocess(); while (Process* _p = mod->nextprocess()) { if (_p->getstate()==1) s.insertiterprocess(_p); }; mod->sim_init_beh(s); Figure 5. Generated C++ circuit description.

5 Figure 6. APICES model editor. The application model of the data flow editor is depicted in figure 6. The generated GUI of the tool is shown in figure 7. A data flow is entered by instantiating component interfaces which are offered in the top part of the flow editor. The behavior of each component interface is specified in the model editor (figure 6). We extended the generated data flow editor with a converter that creates a circuit description in C++ for the data flow graph. Figure 5 shows the code of the circuit in figure 7. Calls to methods generated by APICES are underlined. The simulation tool consists of a simulation main loop, initialization code and result processing. The generated circuit description is included in the initialization code of the simulator. In addition, the simulator contains a FFT algorithm in order to transform simulation results from the time domain into the frequency domain. Simulation results are recorded, transformed and back-annotated to the data flow editor. The waveform in figure 7 shows the output of a GMSK (Gaussian minimum shift keying) quadrature phase modulator in the frequency domain. 5. Results We present the code sizes (in lines of code) to give an impression of the implementation effort needed to construct our tool from scratch. In addition, we give some time figures to illustrate the achieved simulation performance. Since we do not know of any comparable prototyping environment, we unfortunately are not able to benchmark our figures with existing systems. Figure 7. Generated data flow editor with output. The development of the application took four days up to the tested tool. The data flow editor is completely generated by APICES. The only code we had to add manually was the converter which transforms the data flow graph to the C++ circuit description and code which back-annotates output signals traced during simulation to the data flow graph. The code for both parts is 120 lines of Tcl only. The simulation main loop, the initialization code, the FFT algorithm and the tracing of simulation output sums up to 140 lines of manually written C++ code. Code generation and compilation of the data flow editor from the application model took 4 minutes. After this initial compilation only incremental compilation is required if a component behavior is modified. This takes 17 seconds including linking of the updated C++ circuit description with the simulation main loop. number of simulation steps without FFT [secs] including FFT of 3 output signals [secs] Table. 1. Simulation of circuit given in figure 5. The simulator performs in an order of 100k component evaluations per second. This depends of course on the behavior specification of the components. Table 1 gives sim-

6 ulation results using the circuit shown in figure 5. The simulation performance is 80k component instance evaluations per second. All timing figures are total elapsed time on a lightly loaded SUN SPARCStation Related work We subdivide related work into related methodologies, related graph tools and related software environments. On the methodology level, we consider design patterns to be related to our work. Their focus is on capturing recurrent patterns observed in software. They distinguish between re-use of software artifacts on various level of abstraction ranging from architectural patterns [2], over design patterns [1], to more implementation oriented idioms [2]. Our abstract graph pattern contains several design patterns. In this, it may be considered a composite design pattern. In contrast to work on design patterns we cover the generative tool aspect very intensively. Specific graph-oriented software environments like PROGRES [5] focus on formal specification of graph transformations. They are based on graph grammars which allow to define graph transformations using graph rewriting systems. Work in this domain does not concentrate on higher-level functionality as needed by graphbased applications in the EDA domain. Object-oriented frameworks like the well-known model-view-controller architecture or ET++ [3] are general purpose frameworks. They do not support graph patterns like our work does. Without support of graph patterns, our environment would be comparable to such general purpose frameworks. ared to specific application domain frameworks like the simulation framework Ptolemy [11], APICES is an environment tailored to support rapid prototyping of such frameworks. With respect to frameworks, our system is a generator for object-oriented application domain frameworks which are based on network-like data structures. 7. Conclusions and outlook In this paper, we presented APICES a novel software design environment for graph-based applications. It is specifically tailored to support prototyping and rapid development of applications using network-like data structures. Our approach combines re-usable graph patterns with an object-oriented framework architecture and multi-target code generators. It allows to derive all artifacts (implementation, GUI, documentation, test bed) from an application model on a very high-level of abstraction. APICES significantly reduces time and effort for application development. We demonstrate this by an application example from the digital signal processing domain. We constructed a multi-rate signal processing editor/simulator within 4 days with minimal amount of code to be written manually (120 lines of Tcl, 140 lines of C++). The code generators of APICES allow to generate a tool core with high simulation performance and an easy to use graphical data flow editor for design entry and back-annotation of simulation results. We demonstrate by this example, that APICES is best suited for rapid application development of specialized system-level design tools. Our future work will concentrate on the application of APICES to rapid prototyping projects. In addition, we are continuously extending the environment. This includes a code generator for Java, a web-based user interface and new graph methods. Currently, we are working on a generic simulation engine. This will result in new graph pattern variants which are directly executable. The application example in this paper is a first step in that direction. References [1] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, MA, 1995 [2] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Pattern-Oriented Software Architecture - A System of Patterns, John Wiley & Sons, Chichester, 1996 [3] A. Weinand, E. Gamma, R. Marty, ET++ - An Object- Oriented Application Framework in C++, in Proceedings of OOPSLA 88, Vol. 23, No. 11, 1988 [4] Rational Rose/C++, Version 4.0.5, Rational Software Corp., Santa Clara, CA, 1996 [5] A. Schürr, A. Winter, A. Zündorf, Graph Grammar Engineering with PROGRES, in Proceedings of the 4th Software Engineering Conference (ESEC), pp , 1995 [6] A. Bredenfeld, R. Camposano, Tool Integration and Construction Using Generated Graph-Based Design Representations, in Proceedings of the 32nd ACM/IEEE Design Automation Conference, pp , 1995 [7] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, Object-Oriented Modeling and Design, Prentice Hall, Englewood Cliffs, NJ, 1991 [8] C. Lamb, G. Landis, J. Orenstein, D. Weinreb, The ObjectStore database system, Communications of the ACM, Vol. 34, No. 10, pp , 1991 [9] J. K. Ousterhout, Tcl and the Tk Toolkit, Addison- Wesley, Reading, MA, 1994 [10] FrameMaker Release 5.5, Frame Technology Corporation, San Jose, CA, 1997 [11] J. T. Buck, S. Ha, E. A. Lee, D. G. Messerschmitt, Ptolemy: A Framework for Simulating and Prototyping Heterogeneous Systems, Int. Journal of uter Simulation, special issue on Simulation Software Development, vol. 4, pp , April, 1994.