C IDER: A Component-Based Toolkit for Creating Smart Diagram Environments Anthony R. Jansen, Kim Marriott, and Bernd Meyer School of Computer Science and Software Engineering Monash University, Victoria 3800, Australia Email: tonyj,marriott,berndm @mail.csse.monash.edu.au Abstract— Smart Diagram Environments (SDEs) are software applications that use structured diagrams to provide a natural visual interface that behaves as if the computer “understands” the diagram. Unfortunately, despite their potential usefulness, SDEs are not easy to build. We present CIDER a Java toolkit for building SDEs which greatly simplifies this task. CIDER is a generic component-based system which is designed to be easily embedded in Java applications. It provides automatic interpretation of diagrams as they are constructed and manipulated, structure preserving manipulation, and a powerful transformation sys- tem for specifying diagram manipulations and user interaction. CIDER’s main innovation is its component-based approach to SDE development which provides substantially increased architectural flexibility to the application programmer. I. I NTRODUCTION Smart Diagram Environments (SDEs) are software applica- tions that use structured diagrams to provide a natural visual interface [8]. Such an interface behaves as if the computer “understands” the diagram, for example by providing manip- ulation that takes into account the diagram’s structure and its intended semantics. SDEs are useful in a wide variety of applications such as high-level query languages for spatial information systems, CAD systems, diagrammatic theorem provers, and on-line education. They are particularly useful in domains where well-established diagrammatic notations are in use, such as UML in software engineering or circuit diagrams in electronic engineering. As a simple example, consider an SDE that is designed to teach students about Finite State Automata (FSAs). It would allow the students to create and modify FSA diagrams, it would visually demonstrate how to construct a FSA from a regular expression and whether a particular input string belongs to the language of the FSA, and visually demonstrate how to construct a deterministic FSA from a non-deterministic FSA, and how to minimise it. It might also provide automatic layout and beautification (i.e. “pretty printing”). Unlike a standard graphics editor such as xfig the SDE would understand the structure of FSAs and automatically interpret the FSA diagram drawn by the user. In principle, the user constructs these diagrams through basic drawing operations from primitive graphical objects, such as lines and circles. Of course, in an ideal system additional support and high-level, composite graphical objects may be available where this simplifies the interaction. As an example consider the FSA shown in Figure 1. The SDE should identify the possible transitions and recognise that the two concentric circles on the right of the diagram and the text, S3, that lies within them forms a single unit which represents a final state. Later if one of the circles or the text is moved during user editing the other components of the state should move with it as well as any transitions to or from the state. The user should be warned if they have drawn an invalid FSA, for instance if there is an unlabelled transition or no start state. SDEs are potentially very useful, but unfortunately not easy to build. Luckily, there are a number of common functions that every SDE has to provide and implementing these subtasks can be supported by generic software tools. In particular, most SDEs have to provide modelling of the diagram components, interpretation, structure preserving manipulation, visual trans- formation and layout/beautification. A logical approach is to build a generic SDE system which provides these capabilities but which is then customised for a particular diagrammatic language based on a formal high-level specification of that language. This is the idea behind the tools DIAGEN [10], GENED [4], RECOPLA [9], PENGUINS [3] and GENGED [1]. However, given the potential usefulness of SDEs, it is interest- ing to ask why these system are not commonly used (except by those who developed them). We believe a major reason is the lack of architectural flexibility of the above systems. They all severely restrict how the SDE application programmer must write the remainder of the application and also the application GUI. The problem is that they provide a large single system which “wraps around” the main application code. This appears to be the wrong approach, as the main application code and not the user-interface should take center stage. The RECOPLA system explored a different approach by completely separating the front-end from the application and coupling them via inter- process communication. However, such a loose coupling has its own problems when, for example, code needs to be shared S1 S2 S3 b a a b Fig. 1. A simple finite state automaton.