00001.tif

PDF

Download

Open document

Flip pages

Contact Us

Copy asset link

Request this asset

Transcript (if available)

Content GENERATING GRAPH EDITORS by Anthony S. Karrer A Dissertation Presented to the FACULTY OF THE GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (Computer Science) August 1993 Copyright 1993 Anthony S. Karrer UMI Number: DP22866 All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion. UMI uissertatiort ruDitsning UMI DP22866 Published by ProQuest LLC (2014). Copyright in the Dissertation held by the Author. Microform Edition © ProQuest LLC. All rights reserved. This work is protected against unauthorized copying under Title 17, United States Code ProQuest LLC. 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, Ml 48106- 1346 UNIVERSITY OF SOUTHERN CALIFORNIA THE GRADUATE SCHOOL UNIVERSITY PARK LOS ANGELES, CALIFORNIA 90007 This dissertation, written by ................. under the direction of h..i.$...... Dissertation Committee, and approved by all its members, has been presented to and accepted by The Graduate School, in partial fulfillm ent of re quirem ents for the degree of D O C TO R OF PH ILOSOPH Y Dean of G raduate Studies Pb.P- (J-P Date )MMIT,TEE r hatrperso ; Acknowledgements I have greatly appreciated the kind support th at I have received from many people \ I during the completion of my dissertation. I would first like to thank my families. M argaret ' jyour undying faith and love was and is an inspiration to do my best. Mom and Dad thank | you for all of the support th at you’ve given me both during this work and before. Grandma, Steve, Joe, Frances, Mary, Kathy, Kevin, Pat, Michael, Norah, Paul, Elizabeth, Teddy, ■ and Christopher thanks for keeping me sane by diverting my attention with Jeopardy, 1 volleyball, hockey games, late night Acquire, and a seemingly endless supply of other | * 1 ■events. ■ t ; i j I would also like to thank my advisor, Walt Scacchi, who was always willing to figure ! out technical and non-technicai problems. Thanks also to Dave Wile, Lewis Johnson, and : I Firdas Udwadia for providing valuable comments and interesting questions. Finally, I would like to thank the people at Loyola th at gave me support and guidance. ; I C o n ten ts i < 'A ck n o w led g em en ts ii L ist O f T ab les x L ist O f F ig u res x i A b str a c t x iv 1 In tr o d u ctio n 1 1.1 Term inology.................................................................................................................... 2 1.2 Problem A r e a ................................................................................................................ 5 1.3 A p p ro ach ....................................................................................................................... 9 1.4 S o lu tio n .......................................................................................................................... 11 1.5 Overview ....................................................................................................................... 14 2 R e la te d R esea rch 16 2.1 Language Design A p p ro a ch e s................................................................................... 16 2.2 Specification and Generation Techniques................................................................ 18 2.2.1 Program-Based Editor S p ecificatio n .......................................................... 19 2.2.1.1 S tru ctu re-B ased .............................................. 19 iii 2.2.1.2 C om m and-Based.................... 2.2.2 Language-Based Editor Specification . 2.2.2.1 Grammar-Based Specification 2.2.2.2 R u le -b ase d ............................. 2.3 Component Problems ....................................... 2.3.1 Autom atic L a y o u t................................. 2.3.2 A b stra c tio n .............................................. 2.3.3 V ie w s ........................................................ 2.3.4 Efficient R ed isp la y ................................. 2.3.5 Communication S u p p o rt....................... 2.4 S u m m a r y .............................................................. C o m p o n en t P ro b lem s 3.1 D ata D efin itio n .................................................... 3.2 A b stra c tio n ........................................................... 3.3 Visualization D e fin itio n .................................... 3.3.1 Graphic O b je c ts .................................... 3.3.2 Automatic L a y o u t ................................. 3.3.3 Multiple View T y p e s ............................. 3.3.4 S u m m a ry ................................................. 3.4 Efficient R e d isp la y .............................................. 3.5 Command D efin itio n ........................................... 3.5.1 C o m m a n d s .............................................. 3.5.2 Tools ................................................................................................................. 66 3.6 Communication S u p p o rt............................................................................................... 66 3.7 S u m m a r y ....................................................................................................................... 72 I 14 G E D L : O v erv iew , D a ta D efin itio n and A b str a c tio n 74 i | 4.1 Overview ....................................................................................................................... 75 l ■ 4.2 E d i t o r .............................................................................................................................. 84 ! 4.3 D a t a ................................................................................................................................. 85 4.3.1 Vertex and Edge D efinitions......................................................................... 86 4.3.2 A ttribute D efinitions...................................................................................... 88 4.3.3 Graph D efin itio n ............................................................................... 90 4.3.3.1 Connectivity Specification........................................................... 91 4.3.3.2 Graph F u n ctio n s............................................................................ 95 4.4 A b stra c tio n .................................................................................................................... 96 4.5 S u m m a r y ............................................................................................ 98 5 G E D L : V ie w s an d O p eration s 101 5.1 Views ................................................................................................................................ 101 5.1.1 Box and Line Graphics ...................................................................................102 5.1.2 Composite G ra p h ic s ......................................................................................... 106 5.1.3 C o n stra in ts ..........................................................................................................107 5.1.4 V ie w s ....................................................................................................................113 5.2 Operations .......................................................................................................................115 5.2.1 Tools and C o m m a n d s ...................................................................................... 116 v 5.2.2 Operation V isu alizatio n ................................................................................... 117 5.3 S u m m a r y ...........................................................................................................................120 6 G E D L : C o m m u n ica tio n , F u n ctio n s and E x p ressio n s 122 6.1 C om m unication.................................................................................................................122 6.1.1 External F u n ctio n s............................................................................................. 122 6.1.2 External O b je c ts .................................................................................................125 6.1.3 External C o n tro l................................................................................................ 126 6.2 Functions and E xpressions.............................................................................................127 6.2.1 O v e rv ie w ..............................................................................................................128 6.2.2 Control C o n stru cts............................................................................................. 129 6.2.3 Declarations and T y p e s ................................................................................... 129 6.2.4 D ata M anipulation E xpressions...................................................................... 130 6.2.5 Transactions ....................................................................................................... 131 6.3 Summary .................................................................................................................132 7 A G E D L T ran slator 134 7.1 A rchitecture....................................................................................................................... 134 7.2 Solving Constraint G ra p h s............................................................................................. 136 7.2.1 Generating the Low-Level Constraint Graph ............................................ 139 7.2.2 Solving Low-Level Constraints .......................................................................143 7.2.3 Examples of Constraint Graphs and Their S o lu tio n s .................................144 7.2.4 Speeding Up Constraint Graph Solutions...... .................................................149 7.2.4.1 Incremental Generation of Low-Level Constraint Graphs . 150 vi 7.2.4.2 Incremental Solution of Positions...................................................155 7.2.4.3 Independent Sets of C o n s tra in ts .................................................. 159 7.2.5 GEDL Translator Implementation of Constraint S o lu tio n ...................160 7.3 Communication S u p p o rt..............................................................................................160 7.3.1 External F u n ctio n s............................................................................................. 160 7.3.2 External O b je c ts ................................................................................................ 163 7.3.3 External C o n tro l................................................................................................ 164 7.4 S u m m a r y ........................................................................................................................ 165 8 S p ecify in g G raph E d ito rs U sin g G E D L 167 8.1 Constraint Graph E ditor/D ebugger.......................................................................... 169 8.2 Task-Dependence Graph E d ito r .............................. 171 8.3 Graph S e m a n tic s........................................................................................................... 173 8.3.1 Utilizing the Type H ie ra rc h y ....................................................................... 173 8.3.2 Further Global R u le s........................................................................................175 8.3.3 R elatio n sh ip s..................................................................................................... 176 8.4 A b stra c tio n .....................................................................................................................178 8.4.1 Abstraction D a t a .............................................................................................. 179 8.4.2 Multiple A b s tra c tio n s .....................................................................................182 8.5 L a y o u t............................................................................................................................... 187 8.6 C om m unication...............................................................................................................191 8.6.1 Establishing C o m m u n icatio n ........................................................................191 8.6.2 Communication Protocol ...............................................................................192 vii 8.6.3 External C o n tro l................................................................................................194 8.7 S u m m a r y ........................................................................................................................194 9 C o n clu sio n 196 9.1 C o n trib u tio n s................................................................................................................. 197 9.1.1 Characterization of Graph Editor G e n e ra tio n .............................................197 9.1.2 View Tree A rc h ite c tu re ...................................................................................198 9.1.3 D ata D efinition................................................................................................... 199 9.1.4 A b stra c tio n ..........................................................................................................199 9.1.5 Graphic Object D efinition............................................................................... 200 9.1.6 L ay o u t................................................................................................................... 200 9.1.7 C om m unication...................................................................................................201 9.2 Future Research Topics ...............................................................................................202 9.2.1 L ay o u t................................................................................................................... 202 9.2.2 Tool A rchitecture................................................................................................202 9.2.3 GEDL Paradigm . ....................................................................................... 203 A p p e n d ix A GEDL Language Syntax and D efinitions...........................................................................209 A .l Full GEDL S y n ta x ........................................................................................................209 A .2 GEDL Class H ierarchy................................................................................................. 215 A.3 Pre-Defined Constants, Functions, and A ttrib u te s................................................ 216 A p p e n d ix B Constraint Graph E d ito r/D eb b u g g er..................................................................................220 A p p e n d ix C Task-Dependence Graph Editor I I I L ist O f T ables 2.1 Generation Techniques Research 49 : [ 2.2 Component Problem R esearch 49 ' < I ‘ j 1 3.1 Component Problems and Possible A p p ro a ch e s 73 i x |List O f F igu res ( i 1.1 An Example Graph Editor - The Constraint Graph Editor/Debngger . . . 4 1.2 Task-Dependence Graph Editor ............................................................................ 6 I 2.1 Hierarchy of Generation Techniques ...................................................................... 18 I 2-2 Task Dependence Graph Item L ist............................................................................. 20 2.3 Graph Representation Language ............................................................................. 23 2.4 Sample Task-Dependence Graph in G R L ............................................................... 24 2.5 Node Specialization .................................................................................................... 25 2.6 TGE Class H ierarchy.................................................................................................... 27 2.7 Graspin Editor A rch itectu re....................................................................................... 31 2.8 Abstract Syntax Representation using G r a s p i n .................................................. 32 2.9 EDGE Abstraction V ie w s .......................................................................................... 37 2.10 Edge Concentration .................................................................................................... 39 2.11 Example of Views ....................................................................................................... 42 3.1 Two Views of Two Abstractions of a Task-Dependence G ra p h ......................... 57 3.2 View Tree with Abstraction Composition and Multiple V ie w s ......................... 59 4.1 View Tree .................................................................................................................... 75 xi 4.2 Propagation Example ................................................................................................. 77 4.3 A ttribute Specification Example ............................................................................. 89 4.4 Connectivity Specification E xam ple.......................................................................... 94 4.5 Element A sso c ia tio n .................................................................................................... 99 5.1 Examples of Border S ty le s.............................................................................................104 5.2 Examples of B o x e s ........................................... 105 5.3 A Constraint Graph Example (Y-Dimension O n ly ) ...............................................112 5.4 Operation V isu aliza tio n ................................................................................................ 118 6.1 The GEDL Class H ie ra rc h y ......................................................................................... 130 7.1 GEDL Translator System . . . ................................................................................135 7.2 An Example Layout Constraint Graph .................................................................. 138 7.3 Constraint Graph and Solution ( 1 ) .............................................................................145 7.4 Constraint Graph and Solution ( 2 ) .............................................................................146 7.5 Constraint Graph and Solution ( 3 ) .............................................................................147 7.6 Constraint Graph and Solution ( 4 ) ............................................................................ 148 7.7 Structures Used in Incremental Constraint Solution ...........................................152 7.8 Example of Propagating Constraint Modifications - Stage 1 ................................ 153 7.9 Example of Propagating Constraint Modifications - Stage 2 ................................ 154 7.10 Incremental Positioning Algorithm - No Positional Update .............................. 156 7.11 Incremental Positioning Algorithm - Effect on P o s itio n s .....................................157 8.1 The Constraint Graph E d ito r/D eb u g g er...................................................................169 xii 8.2 The Task-Dependence Graph Editor - No Composites ....................................... 171 8.3 The Task-Dependence Graph Editor - Multiple Views w / Composition Ab straction . ...................................................................................................................172 8.4 Connectivity Semantics in Conjunction with Calculated Relationship . . . . 178 8.5 Abstraction and View D ata Ownership and Associations .................................181 8.6 Composition Abstraction ............................................................................................183 8.7 Hidden Components through Composition Abstraction ....................................184 8.8 Possible View Tree in Process Model Editor ........................................................186 8.9 Composite Layout in an Organization C h a r t...........................................................188 8.10 Composite Tree Layout ...............................................................................................189 8.11 Compact Tree Layout .................................................................................................. 190 8.12 Communication Example ............................................................................................193 A bstract Software engineers use graphs to visualize and formalize many information domains, 'and there is considerable common capabilities among editors of these information domains. j ; Domain-specific graph editors, e.g., a data-flow diagram editor, are a powerful and im por ta n t part of software engineering techniques. However, such tools are hard to build, are often slow and ineffective, and become quickly out-dated as researchers develop new edit ing techniques. Furthermore, there is no guarantee th at the design and implementation of I these tools are applicable across information domains. i This dissertation addresses the problem of creating a graph editor generator. The key to this problem is finding effective solutions to several component problems including, data definition, abstraction, graphic objects, layout, and communication. The Graph Editor Description Language (GEDL) and its translator provide the ca pability to specify and generate graph editors. The key features of this language are its propagation-based architecture, graph connectivity semantics, generalized abstraction, constraint-based layout, composable graphic objects, and communication support. This dissertation also presents a GEDL translator and examples of its use in generating graph editors. The translator implements various techniques for improving the usability of resulting graph editors including incremental constraint solution and control communi cation. Working examples of a task-dependence graph editor and constraint graph editor are presented to demonstrate the viability of the GEDL language and its translator. C h a p ter 1 In tro d u ctio n A prim ary goal of software engineering is to suggest controlled methods th at can be used by software engineers to economically construct effective software products. Most current software engineering methods use a variety of graphs (a set of vertices and edges) to visualize and formalize information about a software project. Some examples include structured design charts, data-flow diagrams, object-hierarchies, derivation trees, graphic database schemata, hypertext webs, process models, organization charts, task-dependence graphs, finite state machines, linked lists, and flow charts. Numerous graph editors have been developed for these information structures, but they are useful only in their respective information domains. This speaks well for the usefulness of graph editors. However, such editors are expensive to build from scratch for every information domain, and there is no guarantee th at we will be able to apply the design and implementation across information domains. A reasonable question to ask is how can we build a graph editor generator. A graph editor generator must (1) be able to easily incorporate a variety of graph editing techniques such as autom atic layout, (2) be usable in a variety of information domains, and (3) incor- 1 porate new graph editing techniques as they become available. Two central capabilities form the basis of graph editor generators. First, the graph editor generator must provide a generic implementation of some core capabilities needed in all graph editors. Second, the , graph editor generator must provide a mechanism for specifying and generating domain- 1 specific graph editors, which also incorporate the core capabilities. However, there are no . such generators for graph editors at this time. Similarly, there is no comprehensive char acterization of what must be specified in order for such a generator to produce a graph • editor for a particular information domain. The key to developing a graph editor generator is finding effective solutions to several interesting component problems including, data definition, abstraction, layout, and com munication. So while the ultim ate goal of this dissertation is to address the problem of how is it possible to automatically generate graph editors, these smaller problems must be addressed to solve the larger problem. Before I begin to further discuss this topic, I will present some terminology used throughout this document. 1.1 T erm in ology In this document, a domain refers to a context in which some kinds of objects are m a nipulated. For example, task scheduling and analysis is a domain in which tasks and dependencies are manipulated. We can view domains at many levels of abstraction. For example, the domain of project management contains the domain of work task scheduling and analysis. An editor is a program that supports the manipulation of objects in a domain. A graph editor is a tool th at supports visual and interactive manipulation of graphs. A graph editor allows users to alter graph structure and information associated with vertices and edges in the graph. Most graph editors use a combination of graphics and text objects to visually . represent graph information. j To understand what a graph editor is, it is helpful to understand the distinction between a graph editor and a graphical editor. A graphical editor is primarily concerned with the editing of graphical and textual objects. These objects may (or may not) have an ; ^underlying representation as a graph. The graphics may be interpretable as a graph, but in most cases they are simply a set of graphical objects. A graph editor on the other hand ' is primarily concerned with the editing of a graph. A domain-specific graph editor is a graph editor supporting a particular information domain. Domain-specific graph editors exist for many domains, e.g., a task-dependence graph editor for the project management domain. Figure 1.1 shows an example of a domain-specific graph editor th at will be described later in the dissertation. Generation is the ability to specify and generate programs within a domain. Re searchers have suggested generation for a variety of domains including programming lan guages [62], compilers [52], software development environments [61], text editors [54], graphical editors [60], and graph editors [30]. In each of these domains, the generator supports some pre-existing capabilities and a m ethod of specifying new and modified ca pabilities. In this document, I will refer to the pre-existing capabilities as core capabilities, and the new functionality as the generated capabilities. The m ethod used to specify the generated capabilities is called the specification mechanism. A graph editor generator provides generation as the basis for constructing graph editors for a variety of domains. All graph editor generators provide (1) some domain-independent Graph Edit - (Untitled| 0 le Edit Io o l Sfiew W indow T ypes AddView Misc Help UserView HighLeveiXView HighLevetYView LowLevelYView Figure 1.1: An Example Graph Editor - The Constraint Graph Editor/D ebugger core capabilities th at will be useful in a variety of domain-specific graph editors, and (2) a specification mechanism th at allows the user to specify the domain-specific capabilities of the graph editor. Graph editor generators differ according to how they support each of these functions. The core capabilities are supported in different forms, but they must address the same basic component problems. The specification mechanisms differ in the 1 way th a t the user is able to specify new capabilities and how the core capabilities combine with domain-specific capabilities to form a domain-specific graph editor. Researchers have proposed several specification mechanisms including program-based, and language-based (see Chapter 2). Since graph editors are likely to exist as part of a larger system, the usefulness of a graph editor generator is highly dependent on its ability to communicate with external entities. An external entity is any process or object th at is separate from the graph editor process. For example, a graph editor th at displays and edits directory structures would have to communicate with the operating system. In this case, the operating system acts as an external entity. Now th at we have established a common definition of term s, we can better understand both the problem area and approach. 1.2 P ro b lem A rea To give a more concrete definition to the problem of generating graph editors, I will discuss an example used throughout this dissertation, a task-dependence graph editor. A task- dependence graph is a graph th at models the activities performed during a project. It is modeled as a graph G = (T,D), where T is a set of vertices representing tasks, and Eile Edit Tool View W indow T ypes M isc Help 9.1 J10 T ask D ependenceG raphV iew G raph E d it- (Untitled) Figure 1.2: Task-Dependence Graph Editor D is a set of directed edges representing precedence relationships between tasks. Tasks have attributes, namely an associated duration, a set of resources and a set of people. A critical path in a task-dependence graph is a path through the graph, where the sum of ' the activity duration is maximal. The length of the critical path determines the duration , of the project. The kinds of operations typically required on a task-dependence graph include adding and removing tasks, dependencies and sets of tasks and dependencies; computing the crit ical path; computing slack time for each task; creating composite tasks to hide refinements of specific tasks; multiple logical views of the graph including parts of the graph involv ing specific tasks or people; multiple representational views of the logical views possibly including a PERT chart view, a G antt chart view, and a textual view; reading, writing and printing all or parts of the task-dependence graph; and autom atically positioning the tasks and dependencies to produce understandable visualizations. An example of this kind of editor is shown in Figure 1.2. 6 By itself, designing a task-dependence graph editor with these capabilities is difficult. Autom atic positioning (or more commonly autom atic layout) for certain aesthetic criteria , i has been shown to be NP-hard [18, 55]. Providing the sub-graph abstraction based on | composition in conjunction with multiple views is also difficult to design. Both of these i problems are magnified by the time-critical nature of editing. Thus, part of the problem of developing domain-specific graph editors is simply providing effective solutions to difficult i design problems. Taking a broader view of the problem of building domain-specific graph editors, we can see th a t many of these editors have similar capabilities. Unfortunately, there is no ' guarantee th a t the design or code in one domain-specific graph editor will be reusable in another domain. This leads us to consider the problem of how is it possible to automatically generate graph editors across many information domains. This problem requires the development of a comprehensive characterization of graph editing, where th at characterization can serve as the basis of specification and generation. While the overall problem is finding a graph editor generator, it turns out th at the real problem is finding effective, integrable solutions to several smaller component problems. The component problems, introduced here, are further discussed in Chapters 2 and 3. The component problems are: 7 D a ta D efin itio n How can the data for the domain be described? For each domain, there will be a different model of the data describing the domain. Thus, a central requirement is support for modeling the data. This model must include the type of data, connec tivity semantics, and other domain-specific semantics. A b str a c tio n How can large, complex graphs be transformed into smaller and more manageable pieces? Often, the user is only interested in a particular part of the entire graph. Providing the graph of interest is the problem of abstraction. G rap h ic O b jects How can the graph data be transformed into graphical images? The most basic part of the visualization of graph data is the ability to define graphic objects and define how these graphic objects are related to elements in the data. L ayou t How can the graphical images be presented in a meaningful layout? This involves the difficult problem of automatically positioning graphics using various aesthetic criteria and integrating user-specified layout information. C o m m u n ic a tio n How can data and control be exchanged between graph editors and external entities? Since graph editors are likely to exist as part of a larger environment, they need to be able to communicate with external entities. While other researchers have addressed some of the component problems individually, no research has addressed them within the framework of solving the entire graph editor generation problem. Thus, their individual solutions may or may not be integrable to solve ! the problem. The remainder of this dissertation is concerned with presenting the component prob lems in further detail and addressing these problems through a comprehensive charac terization of graph editing. This characterization must include effective and integrable solutions to each of the component problems as well as a solution to the overall problem of generating graph editors. 1.3 A p p roach We approached the problem of graph editor generation by analyzing the component prob lems, finding effective solutions, and designing a language th at implements these solutions. This language can then be used to specify and generate domain-specific graph editors. This language also serves as a comprehensive characterization of graph editing applications. Before we consider the language itself, we need to first understand the context of the language design more fully. At the highest level, the goal of the language is to be used as the basis o f specification and generation of graph editors. However, it is also im portant to understand the more specific requirements for this language. The most fundamental of the language design requirements is to provide an imple m entation of solutions to the component problems as constructs in the language. These solutions must be integrable using higher level constructs so th at these solutions can be combined to form a codified solution to the graph editor generation problem. While this is the prim ary language design requirement, several other aspects of solving the problem through a language must also be considered. First, the fact th at the field of graph editing techniques is continually evolving, especially in abstraction and layout, ■ ; makes the language design much harder. The language requires a flexible approach, easily i allowing experim entation with and incorporation of new graph editing techniques. Another facet to the problem is designing a language th at is both portable and will support communication with external entities. This dichotomous problem plagues the I design of virtually all languages and this domain is no different. The first part of the dichotomy is th at the language designer wishes to make the language independent of any particular implementation of the language and hence as portable as possible. To m aintain portability the design should mention few if any implementation details and especially little characterization of items th at are external to the language. For example, if we were designing a general purpose programming language and wished to make it as portable as possible, then we would have few if any concurrency control constructs in the language specification. If it specified advanced concurrency control techniques as part of the language, then implementation of the language on top of particular operating systems could be inefficient or impossible. The second half of this dichotomy is th at almost all languages deal with the description of entities th at exist as part of a larger system. In order for a language to be useful, it must eventually support communication with external entities, and if the language designer truly wants to give significant support for communication, then it must make some assumptions about the eventual implementation of the language. 10 This dichotomy leads to an interesting issue in the design of a language for specifying and generating graph editors. A domain-specific graph editor is likely to exist as part of 1 a larger system, e.g., a software development environment. In these cases, the usefulness i of the graph editor is highly dependent on its ability to communicate with other elements | I of the system. At the same time, it is desirable to make the design of the language independent of communication techniques, thereby maintaining independence from its ' implementation and increasing its portability. ! To summarize, a language that solves the problem of graph editor generation must ■ provide a comprehensive characterization of graph editing through a set of constructs. These constructs allow editor specifiers to specify and generate graph editors across infor m ation domains. The key to this design is to provide constructs th at implement solutions to the component problems of abstraction, layout, etc. We must also consider the goals of integrating the resultant editors as part of a larger system, and experimenting with and incorporating new graph editing techniques. 1.4 S o lu tio n The G raph Editor Description Language (GEDL) is a solution to the problem of graph editor generation meeting the requirements of the previous section. Thus, this language can be used to specify graph editors, and an associated translator can produce working graph editors based on the specification. Some of the more interesting features of GEDL are: 11 • Propagation-Based Architecture One of the keys to the successful design of GEDL was the architecture of graph editors generated using GEDL and its translator. This architecture supports separate components connected through implicit propagation paths. Updates to the data in one of the components propagate through other members. This separation allows for easy integration of external entities. We believe th at this architecture can serve as a model for future CASE tools to support distribution, collaboration and component- based tools. • Graph Connectivity Semantics GEDL provides a few constructs that turn out to be surprisingly powerful and easy to use in specifying the legal graphs (meaningful graphs in a given domain). • Generalized Abstraction Support The abstraction mechanism in GEDL is not a specific kind of abstraction such as composition, but rather it provides the basis for specifying many different kinds of abstraction. • Constraint-Based Layout Specification Layout of graphic objects is done using a constraint language. Constraints are defined from various sources including general-purpose autom atic layout algorithms, domain- specific layout algorithms and the user. These constraints are solved to determine the actual position of graphic objects. 12 • Composable Graphic Objects GEDL defines box graphics, line graphics, composite graphics and simple, com- . I posable graphic items. Composition of simpler graphic objects into more complex graphics is used extensively. This approach provides for flexible definitions of graph- ; ics, independent sets of constraints, and multiple layout algorithms within a single visualization. • Communication Support GEDL constructs support external functions and external objects so th a t functions • and data can be separated from the GEDL generated editor. These constructs also provide the basis for externally generated control (driving the editor from a separate process). The GEDL translator accepts graph editor specifications and produces working graph editors such as the constraint graph editor shown in Figure 1.1. The GEDL translator provides the basis for evaluating the effectiveness of the GEDL language in specifying graph editors. Its most interesting aspect is how it solves critical implementation problems of the GEDL language (and graph editing in general). The two most im portant areas are: • Layout Constraint Solution The problem of efficiently solving layout constraints is im portant to building rea sonable graph editors. The GEDL translator implements incremental and non- incremental constraint solutions incorporating a variety of speed-up techniques. 13 • Communication and External Control The implementation of the communication and external control constructs in GEDL provide the basis for interesting and powerful forms of data and control communica tion. Using GEDL and its translator, I have built several example editors. These editors dem onstrate the usability of the language and translator in specific domains. They also give a better understanding and emphasis to the component problems. Given this brief overview of the solution to graph editor generation described in this dissertation, I will now present an overview of the remainder of this document. 1.5 O verview In Chapters 2 and 3, I present a more detailed discussion of the problem area and the component problems. Chapter 2 is a review of related research including alternative ap proaches to both generation (other than language-based) and to the component problems. C hapter 3 contains in-depth discussions of each of the component problems and possible approaches to their solution. Given these problems, I then describe the solutions adopted in this research. These solutions are presented through a language, a translator, and examples of its use in speci fying domain-specific graph editors. Chapters 4-6 contain descriptions of the syntax and semantics. The description of GEDL has been broken into chapters dealing with the data domain, user view, and functional descriptions, respectively. Chapter 7 describes some interesting aspects of the translator th a t generates graph editors based on GEDL specifi- cations. Chapter 8 discusses the use of GEDL in specifying graph editors with a focus on the component problems. In Chapter 9, I conclude this dissertation by reconsidering the implications of this i research to the problem area and to other areas of research. I also present some interesting , additional problems th at arise as a result of this research. 15 C h a p ter 2 R e la te d R esearch This review surveys research related to the design of a language for specifying and gen erating graph editors. In this review, I identify (1) possible approaches to designing the language, (2) approaches to generations, and (3) approaches to the component problems suggested by previous research. 2.1 L an gu age D esig n A p p roach es As languages have evolved over the years, the approaches to the language design have evolved as well. Early languages were designed primarily with efficiency of the resulting machine code in mind. More recent attem pts at language design, such as Ada, have focused attention on a variety of requirements for a language th at can be used to guide its design. However, few efforts specifically focus on the problem of defining an effective process for designing languages. Kennedy [32] suggested a process for designing imperative language constructs (pri marily control constructs). This process was to (1) define code performance objectives based on specific problems, (2) design language constructs to meet these objectives, (3) 16 test the constructs against the objectives by writing code, and (4) modify the elements of steps (l)-(3) repeatedly as required. Thus, the overall process of language design focused l on usability of the constructs to solve specific programming problems. | A similar approach is suggested in work by Bell [5]. In this case, the language design , was oriented towards programmers th at (1) have some programming experience and, (2) are creating autom ated graphical simulations. The language design process is term ed “problem-centered design with walkthrough feedbacks.” Basically, this process suggests th a t the language design should focus on the usability of the language to solve problems within the domain of the language. The process is to describe a set of problems and to use , these problems to define a set of questions that can be used to judge alternate language designs. However, rather than an iterative or prototypical approach, this process suggests completely separate language designs be compared. The language design process used in GEDL relies on problem-centered design incor porating iterative design updates. Constructs emerge as graph editors are specified in the language. This process requires a flexible language and a highly modifiable translator. To get the flexibility and modifiability, we have used an object-oriented programming lan guage, C + + , as the “interm ediate language” of translation. Translation is implemented as automated specialization, which proved to be an effective means of supporting the iterative design updates. A more complete discussion of this language design process can be found in [28]. 17 Program-Based Generation Language-Based Command-Based Structure-Based Grammar-Based Rule-Based Figure 2.1: Hierarchy of Generation Techniques 2.2 S p ecifica tio n and G en era tio n T ech n iq u es In this section, I will review a variety of techniques proposed by researchers as the basis of specifying and generating editors. Generation has been used in a variety of domains including programming languages [62], compilers [52], software development environments [61], text editors [54], graphical editors [60], and graph editors [30]. While these different domains have significantly different core capabilities, they all must address the problem of specifying domain-specific capabilities and then generating the related product from the specification. In reviewing these efforts, I have identified two categories of generation techniques, namely whether the specification language used is a domain-specific language (language- based) or a general-purpose programming language (program-based). W ithin both of these categories, there are significant sub-categories. For example, a language-based approach can use a rule-based language, a grammar-based language, or a specification language. A program-based approach might use an object-oriented language or an im perative language, etc. Program-based generation can be further classified through the m ethod of attaching specification to core capabilities. The two most common forms axe command-based and structure-based. This hierarchy of generation approaches is shown in Figure 2.1. 18 The following two sections review and categorize various approaches to specifying domain-specific editors. The first section reviews efforts th at use a program-based ap proach. The second section reviews language-based approaches. 2 .2 .1 P r o g r a m -B a s e d E d ito r S p e c ific a tio n Program-based editor specification provides a set of capabilities and an interface in a general-purpose programming language. This interface could be a library of routines th at the editor specifier is able to call within source code, or a set of routines th at the editor specifier must create to fill in the missing parts of the code, or both. The central issue in designing a program-based editor specification approach is how to present the core capabilities. The two prim ary approaches have been to (1) allow the user to create instances of a set of types and then have the core capabilities operate over these types (structure-based), and (2) allow users to create or modify commands and attach domain-specific functionality to these commands (command-based). 2 .2 .1 .1 S tr u c tu r e -B a se d The Ite m L ist [10] is a data-structure which can be used to describe graphical editor data with connectivity between graphical elements. Once an instance of the ItemList is created, a set of routines can be called which manipulate the data and provide viewing and editing capabilities. Extensions are designed around a four phase cycle which consists of command entry, command interpretation, display update and clean-up. Each cycle corresponds to a new version in the structure. Displaying an ItemList consists of the steps propagate, form at, erase, and redraw. The propagate and format routines are domain-specific and 19 r t" Name Class Class Class Class Class Depends Task Task Depends "Sample" Task Source Source Name "Reqs' Name "Design" Name "Code" Duration Duration Duration Target Target Figure 2.2: Task Dependence Graph ItemList are associated with an item according to its type. Thus, the editor specification includes definitions of the propagate and format routines for all types of items. The Item List is defined as a set of items. An item is a set of attribute-value pairs where the values can be strings, integers, floating point values, lists of values or a special NULL value. Each of these pairs is called a property. The basic operations provided are for creating items and ItemLists, putting and getting properties, and iterating over ItemLists. An Item List is implemented through a special header item. Thus, the Item List can have properties associated with it as a whole as well as with its components. Figure 2.2 shows a graphical depiction of one possible ItemList. The Item List itself is denoted by the double circle. To support incremental redisplay, the ItemList also includes a version number for each of the properties. A current version number is maintained in a global variable. Thus, 20 updating properties is done by inserting a new property with, the current version number at the head of the list. However, it does not remove other properties even if they have the same attribute. Retrieving values works by scanning the property list from head to tail for I i the first property with a matching attribute name and a version th at is less than or equal j to the current version. Modifications are made with non-decreasing version numbers. i Connectivity semantics are supported by allowing properties to refer to other items. Thus, edges would always have properties for the two vertices they connect. Connectivity is enforced through domain-specific methods for handling propagation. Thus, when a vertex changes position the edges which connect it to other vertices must be notified through the propagate routine associated with the vertex. Dependencies rely on the propagate and format part of redisplay for notification that i the items it connects have moved. This additional programming burden for the user results from the fact th at the ItemList does not assume a graph structure for its data. Thus, our description of dependencies is not a specialization of an edge, but rather is a specialization of a graphical object which can be either edges or vertices. The IS I-G ra p h e r [49] is a LISP-based visualization and editing tool for graph data. It is similar to the ItemList approach in that you specify graph data using a particular structure and the system uses this information in a particular way to display and edit the data. In the ISI-Grapher implementation, the graph data is specified as a function, son s, th at returns a hierarchical relationship between vertices. As in the Item List, the ISI-Grapher allows additional domain-specific semantics to be associated with particular vertices and edges by creating domain-specific methods which are autom atically invoked during the edit-display cycle. 21 U n id ra w [60] provides a set of C + + classes which provide the basis of specifying domain-specific graphical editors. A domain-specific editor is created by specializing the base classes. E D G E [44] is an extensible graph editor built in C + + on top of X windows. It is ■ designed around four m ajor classes: e d ito r , graph, node and edge. These classes are best described by considering the external representation language suggested by EDGE originally called the Graph Representation Language (GRL). This language is depicted in Figure 2.3. An example of its use to describe a task-dependence graph is shown in . Figure 2.4. The node class defines a set of standard node attributes such as w idth and height as well as a set of operations such as add and draw. A full list of these attributes and operations can be seen by looking at the GRL under the node class. An extension to the node class is made by creating a class which specializes it. Because the node class uses “virtual” functions, any redefinition of operations in the specialized class will be picked up automatically. For example, in the task-dependence graph editor we would want to associate a duration with the task. This would require the definition of a new class which inherits from the node class and adds an integer attribute. Additionally, we would need to redefine the drawing routine in order to display this additional information. Figure 2.5 depicts these extensions as they would be specified in EDGE. In EDGE, the functions for creating, editing and printing are table driven. The tables contain descriptions of the attributes associated with nodes and edges. These tables are created autom atically based on the C + + class definitions. The tables are needed to alle viate the problem of having to add code which specifically instantiates and m anipulates 22 ! width height ]x-spacing Jx -offset y-offset algorithm ] frequency] ^ {straight co n strain t]* ^ |2 -1 /2 lD jscale | - {layout [ ■ graph orientiation viewing -s t a tus relative input output redraw create zoom -in zoom -out width height borderwidth / / \ anchor-points / J color font label position node add delete edit draw action show composition width j thickness color direction routing j font j j position | edge label add delete I edit idraw action inode - - {edge [overview | [node-template] [edge-template] editor Figure 2.3: Graph Representation Language graph: layout.algorithm: sugi_constraints node.borderwidth: 5 edge.arrowstyle: line edge.arrowheight: 10 nodes: title: "Start" title: "Requirements" title: "Design" title: "Code" title: "Test" title: "Finish" endnodes: edges: source: "Start" target: "Requirements" source: "Requirements" target: "Design" source: "Design" target: "Code" source: "Code" target: "Test" source: "Test" target: "Finish" endedges: constraints: endconstraints: endgraph: Requirements Start Design Code Test Finish Figure 2.4: Sample Task-Dependence Graph in GRL 24 #include "node.h" // definition of generic node type class Task: public node { public: void drawQ; int duration; graph: layout.algorithm: sugi_constraints node.borderwidth: 5 edge.arrowstyle: line edge.arrowheight: 10 nodes: title: "Start" duration: 0 title: "Requirements" duration: 5 title: "Design" duration: 6 title: "Code" duration: 7 title: "Test" duration: 4 title: "Finish" duration: 0 endnodes: edges: source: "Start" target: "Requirements" source: "Requirements" target: "Design" source: "Design" target: "Code" source: "Code" target: "Test" source: "Test" target: "Finish" endedges: constraints: endconstraints: endgraph: Figure 2.5: Node Specialization I I Start: 0 Requirmnts: 5 Design: 6 Code: 7 Test: 4 Finish: 0 25 Task instances rather than node instances. The edge class defines a set of standard edge attributes, such as line thickness and the nodes it connects, as well as a set of operations such as add and draw. Edges are extended in the same way as nodes and are supported by autom atic table generation. The graph class specifies, among others, the set of nodes and edges, a width and height, and an orientation. It also specifies operations for reading and writing, and redrawing. The editor class provides a window and a set of commands for m anipulating the graph, . nodes and edges. In response to commands, the user interface simply invokes the appro priate operation associated with one of the other classes. Thus, extensions to the set of available commands are made with respect to extensions of the graph, node or edge classes rather than the editor class. For example, if we wanted to define a command which would calculate the critical path for a task-dependence graph, we would describe this by creat ing a new a c tio n operation associated with our specialization of the graph class. The a c tio n operation is called autom atically whenever an object is selected in the viewing area. This extension could also be done autom atically after each command by specializing redraw -graph routine to include the calculation of the critical path. T G E (T ree/G raph Editor) [30] is an extensible graph editor whose extension mecha nism is similar in nature to EDGE. Extensions are made by creating a set of subclasses which describe the domain- specific portions of the editor. The prim ary contribution of TGE is a set of classes which provide a better basis for extension than the four classes provided in EDGE. This class hierarchy is shown in Figure 2.6. In particular, the TG E design incorporates a separation of subjects and views. The subject classes defined by TG E are similar to the classes defined in EDGE. However, 26 C lass ArcList NodeList G raphPic NodePic ArcPic nteractor DialogBox Editor Stateview PullDownMenu EditBox C om m ands ArcEdit NodeEdit Figure 2.6: TG E Class Hierarchy the view information is completely separated and is put in classes which correspond to each of the subject classes. In other words, there is both a node class and a node view class. The node class would contain information which fully describes the node. In the task-dependence graph example, this would be the name of the task, duration, resources and people. The node view class contains information which describes how the node should be displayed. In this example, it would contain data specifying the node’s location and operations for rendering an image of the node. Unlike EDGE, TG E requires the user to specifically instantiate subclasses of the edge and vertex class by specializing command and tool operations. In ED G E,-this was done autom atically by updating a set of tables which are used by the code to drive the operations requiring instantiation. 27 2 .2 .1 .2 C o m m a n d -B a sed While most editor generation approaches include specification of domain-specific com mands, most do not use command specialization as the prim ary means of attaching domain- specific capabilities. E M A C S [54] is an example of a command-based extensible text editor. It allows domain-specific commands to be created which m anipulate the text. Its widespread pop- ' ularity and use underscore the practical utility of command-based extensibility. O b ject M ak er is a commercial product from M ark V Systems designed to address much of the same market as Software-Through-Pictures [61], namely expandable, cus tomizable software development environments based on graphical editors. Object Maker supports customization of its editor by associating rules with specific commands. These rules are invoked whenever the command is invoked and control the effect of the command. 2 .2 .2 L a n g u a g e -B a s e d E d ito r S p e c ific a tio n Language-based editor specification utilizes a language th at is designed to specify and generate editors. These languages can take a wide variety of forms. In this review, I have classified language-based efforts into two categories, namely, gram m ar-based and rule-based. Grammar-based languages support the specification of the data th at the editor m anipulates with a language grammar. Most often, these grammars are annotated with additional attributes th a t specify characteristics of the editor. A rule-based language allows specification of the editor’s capabilities and the language th at it m anipulates as a set of rules governing editor operations. 28 2.2.2.1 G ram m ar-B ased Specification The best known examples of grammar-based editor specification are in the domain of language-directed editor generation. The classic examples of these efforts are the Synthe- . | sizer Generator [47], GANDALF [42] and MENTOR [11]. These efforts focused on the 1 generation of language-directed editors or environments consisting of a set of language- directed editors. In each case, an editor is created through a specification of the gram m ar of the language to be edited. I The S y n th e siz e r G e n e ra to r generates a language-directed editor from a specification of a language’s abstract syntax, context-sensitive relationships, display form at, input syn tax and transform ation rules. The Synthesizer G enerator’s Specification Language (SSL) is based on an attributed gram m ar with production rules. It is easiest to understand the [ capabilities of the Synthesizer Generator by studying SSL. SSL perm its the specification of various aspects of a language-directed editor includ ing the abstract syntax, context-sensitive relationships, display form at, input syntax and transform ation rules. The abstract syntax and context-sensitive relationships of the lan guage are specified using an attributed grammar with production rules which is similar to YACC [24] specifications. This part of the SSL specification limits users to actions that are syntactically and semantically correct according to the specification. SSL also supports an attribute grammar based specification of the display of a lan guage and the legal forms of input. This is called the unparsing scheme in SSL terminology. Basically, the unparsing specification associates display formats such as the textual repre sentation, indentation and line feeds with language constructs. It also specifies the regions which can accept input. 29 The form of input is defined by a set of input rules which describe a concrete input gram m ar associated with various input regions. This is analogous to the specification of lexical analysis of a language, but it is specific to the input within certain regions since .input is sensitive to the surrounding language constructs. The final part of an SSL specification are the transform ations associated with a gram- .mar. Transform ation declarations specify rules for restructuring an object when patterns are m atched. This can be used for tem plate based input and for more complex language transform ations. All transform ations are chosen by the user based on the current set of legal transform ations. SSL specifications are analogous to specifications required in graph editor generators in various ways. In general, graph editor generators m ust be able to specify the form of the graphs and their associated data as well as the legality of specific graphs. This is analogous to the specification of the abstract syntax and context-sensitive portions of a language. Clearly SSL specifications are insufficient for specifying the characteristics of a graph editor. However, in work by G ottler [19], a programmed attributed graph gram m ar [41, 14] is suggested as the basis of specifying diagram editors. Basically, such a specification of an editor would describe the legal transformations to the graph. These transform ations are described as (1) a “left-side” structure or pattern th at must exist in the current graph, (2) context information such as connectivity of the left-side elements, and (3) a “right-side” which describes the resultant graph produced by the transform ation. Furtherm ore, these graph productions can be augmented with attributes and actions in the same way that BNF productions are augmented in a textual language. Visualizations C om m ands G raph Data G raph Data A bstract Syntax R epresentation U ser Interface C oncrete S yntaxes Sem antics: Action R outines Figure 2.7: Graspin Editor Architecture G ra p h -E d [21] is a graph grammar editor. It allows users to describe graph grammars I using three different kinds of grammars. In turn, the graph gram m ar can be used to control certain aspects (primarily connectivity) of other graph editing. G ra sp in [37] supports the creation of editors through the specification of the abstract syntax, concrete syntax and semantics of graphical languages as well as a set of extended commands. Figure 2.7 shows the architecture of a Graspin-based domain-specific editor. At the heart of the Graspin system is an ADT which implements an abstract syntax for a graphical language. In fact, the normal abstract syntax tree has been replaced by a tree annotated with additional links representing various connections between abstract constructs. Thus, the abstract syntax tree is actually a graph. Figure 2.8 depicts how a task-dependence graph is conceptually represented in this implementation. The semantics of the graphical language are the next building block. The semantics are described using action routines associated with various constructs in the abstract syntax. These routines are called whenever an editing operation is applied to a construct. 31 T ask -D ep en d en ce G raph N am e R equirem ents' T ask Duration N am e 'Design' TaskList T ask Duration N am e 'Code' T ask Duration S ource D ependency T arget D ependencyList S ource D ependency T arget Figure 2.8: A bstract Syntax Representation using Graspin This approach to the specification of semantics is similar to programmed attributed graph grammars. However, the ADT approach does not support the specification of context- sensitive information associated with the left-side of the production. The concrete syntaxes specify the appearance of a graph in terms of the textual and graphical representations. A set of commands for displaying the construct are associated , with each abstract syntax construct. For example, in a graphical view of a task-dependence graph, we would associate a box drawing routine with the task construct and would asso ciate a line drawing routine with the dependency construct. Commands are associated with each grammar production. Thus, each production is considered a kind of command, and the set of available commands at any point depends on the current set of legal productions. Commands result in a set of suggested changes which m ust be checked against the syntax and semantics of the graphical language as described previously. 2 .2 .2 .2 R u le -b a se d A rule-based approach to specifying domain-specific graph editors relies on a language for associating rules with various operations and/or objects which the editor m anipulates. The M e ta -E R A [40] system supports the specification of an editor through definition of an ERA model of the information domain and a set of rules which enforce semantics beyond the ERA model. Rules are associated with each entity, relationship and attribute. The editor checks all updates against the rules to ensure correctness of the resulting data. Changes to d ata is made through a set of pre-defined operations which are based on the ERA model. For example, the user can choose to add an entity and its relationships. 2.3 C o m p o n en t P ro b lem s In the previous section, I presented overall approaches to generation. Now, we will turn our attention to research which addresses some of the component problems. In particular, I further describe each of the component problems and evaluate alternative approaches found in related research. 2 .3 .1 A u t o m a t ic L a y o u t A utom atic layout algorithms are designed to free users from manually placing nodes and edges. They generally incorporate a variety of heuristics for generating aesthetically pleas ing displays of graphs. However, the term aesthetically pleasing is difficult to define and in fact differs from graph to graph and from user to user. Some of the issues might include minimum width, minimum edge crossings, grouping of logically coupled nodes, and many others. This problem is quite difficult, and some aesthetic requirements lead to N P-hard problems (polynomial-time algorithms are not likely to exist) [18, 22, 23]. There are many layout algorithms incorporating techniques such as iteration and leveling [56, 50, 17], grid drawings [4], force-directed placement [12], etc. A good survey paper is [13] which also discusses algorithms related to different kinds of graphs. A detailed discussion of these algorithms is beyond the scope of this dissertation. Instead, I will review how various graph editor generators address the problem of layout. It is im portant to point out th at graph editor generators will have a slightly different perspective on the requirements related to autom atic layout. In particular, graph editing is interactive so th at good response time of a layout algorithm is im portant. Furtherm ore, user-defined constraints on positioning are likely to be incorporated in layout. Therefore, 34 the focus of this review is how layout is incorporated in graph editor generators rather th an specific layout algorithms. G R O W [3] is an object-oriented system for constructing graphical interfaces. The GROW system uses inheritance, graphical dependencies and composition to structure a I graphical interface. The graphical dependencies are used both to manage updates to graph ical objects when the data they are associated with is changed, and to relate attributes of graphical objects to support positioning constraints such as m aintaining connectivity. The graphical dependencies of GROW form a dependency lattice which relates graphi cal objects to other graphical objects so th at the dependencies can be enforced. Whenever an attrib u te is updated, the dependent attributes are also updated. Updates are recur sively propagated through the lattice. The dependency lattice must be acyclic. This requirem ent may make some global constraints impossible to represent in this model, e.g., minimizing edge crossing. D A G [17] is a program which accepts a textual description of a graph and generates a Postscript [1] or Pic [33] rendering of the graph. The user is able to specify graphical attributes of both nodes and edges including, shape, size, label and color. The m ain feature of DAG is its layout algorithm which is similar to Sugiyama’s [56] and Rowe’s [50] hierarchical layout algorithms. The DAG layout algorithm accepts commands which constrains the layout. These commands include (1) separation between levels and between nodes on a level and (2) control of the level assignment for nodes. These con straints are not as general as the constraints in GEDL and are used at a very different level as we will see later. E D G E [44] has also provided significant contributions to the study and implementa- 35 tion of graph layout algorithms, especially in the context of graph editing. The EDGE ■ design provides four layout algorithms which are translated into constraints. These layout ' algorithms trade-off speed versus aesthetics versus graph types (acyclic, cyclic, tree). The EDGE approach to integrating user and application-defined constraints is different ! from DAG and other layout algorithm designs. In EDGE, the autom atic layout algorithm, the user, and the application all generate constraints with specific priorities for conflict resolution. Taken together, they specify the placement of graphic objects in a visualization. This is a different approach than modifying the functionality of the layout algorithm based on constraints as done in DAG. The EDGE approach also incorporates layout stability in its layout algorithms. Layout stability is designed to keep nodes close to their original position after a change. This elim inates the disorientation associated with drastic changes to the view of a graph associated with unstable layout algorithms. The EDGE approach is to keep stability constraints as low priority constraints which are relaxed in the vicinity of a change. Two recent efforts by Henry [20] and Messinger [38] both suggest using composition as the basis of layout. In particular, Henry’s work is especially interesting in th a t it is concerned with interactive layout of large graphs using composed layout algorithms and user definable layout characteristics. The combination of interactive display and large graphs is an im portant and difficult challenge. 2 .3 .2 A b s t r a c t io n Even with adequate layout algorithms, the sheer number of nodes and edges in some graphs may make graphical display completely useless. Typically, such graphs are black with edges 36 IN 0 X O R C A R R Y O U T IN 0 r O U T CARRY IN 0 r I C A R R Y O U T (a ) B la c k B ox (b) G ray-B ox (c ) W h jte-B o x Figure 2.9: EDGE Abstraction Views an d /o r display vertices which are no more than dots in order to fit them on a com puter display. In order to address this problem, the concept of abstraction has been proposed. A bstraction is simply hiding of irrelevant detail in order to make the visualization more readable. E D G E [44] proposes two specific kinds of abstraction facilities. The first abstraction mechanism is called subgraph abstraction which allows users to group a subset of the nodes and edges. This subset can be abstracted as a single node or may be exploded to reveal its contents. EDGE defines three views of abstraction called the black, gray and w hite box views and are shown in Figure 2.9. An alternative to the black, white and gray views is a view where rather than showing the subset “in-place,” the subset is shown in an alternate viewing area. This option is not possible in EDGE because of its inherent lim itation to a single view. This problem will be discussed in more detail later. The subgraph abstraction approach is surprisingly general when used in a domain- specific graph editor. For example, in the task-dependence editor, we could theoretically define our abstraction to be able to hide away a set of tasks which are then viewed as a single larger-grained task with a duration of the length of the critical path for the set ' of subtasks. The EDGE literature does not make it clear how to associate d ata and operations with abstractions. Its seems th at the definition of graph must serve as the abstraction definition. Thus, all operations on a graph also must serve as operations for an abstraction and vice versa. This makes coding more difficult and does not allow for more than one abstraction to be active at any time. In the case of EDGE, this is not really a problem since only one view (and hence one abstraction) is possible at any time. The second kind of graph abstraction supported in EDGE is edge concentrations. To reduce the number of edges without changing connectivity information, EDGE allows a set of edges to be directed into and out of an edge concentration node. This is shown in Figure 2.10. The semantics of a cluster node is th at each input node is connected to each output node. These two kinds of abstraction allow for specific abstraction, but are not a generalized abstraction mechanism. A generalized abstraction mechanism can be used to define both of these kinds of abstractions. The EDGE authors correctly point out th at abstractions are a difficult combination of both d ata structures and layout algorithms. H e n r y [20] suggests another kind of abstraction called subgraph selection. In this case, a particular part of the graph is selected by the user through algorithms or through m anually choosing a particular region. The algorithms can select such things as all leaf nodes, a particular kind of vertex and edge type, or a particular depth. W hatever the 38 n d s .h A a r /1 n c U jfe /strin g » . h | p u a r /tn c lu d e /c tjjp e .h j j c t o o U .h J ^tgxchfc.h | j tciruK ars.h ctooU .c llt«xchfc.c I I verbal**.c 11 error 3. c c*os.c te*chars.c b e fo r e (3 3 c ro s s in g s ) c t o o l s . h l f7 u sr/'in c lu d e '/* td io .h / u*i» / i re 1 ude/c t yp«. h sc-0 ec-1 /u s r / 1 nc 1 tideAtr I ngs. h ©c-3 c to o la .c after (3 crossings) Figure 2.10: Edge Concentration 39 criteria, the subgraph becomes the graph of interest and is presented to the user. 2 .3 .3 V ie w s The capability to simultaneously m aintain multiple visualizations of the same set of in form ation is called “multiple views.” Most graphic interface designers support multiple ‘ views of d ata by separating data from view in separate data structures. This allows the , d ata to be m anipulated independently of the views of the data, and the views respond to changes to the data. The C h iro n [31] user-interface toolkit exemplifies this approach. In Chiron, d ata is specified without any knowledge of its visualization. View types are associated with a type of data. Once a data instance is created, views which are associable with th at type of data I can be instantiated and associated with that instance of the data. W hen a change to the d ata occurs, the views are notified of the changes autom atically by the Chiron system. In term s of how this relates to graph editors, T G E takes an approach similar to Chiron for separating subject classes from viewing classes. In the TG E approach, there is both a node class and a node view class as part of the core capabilities. A domain-specific editor would specialize the node and node view classes. In the task-dependence graph example, the task class would have the attributes for the name of the task, duration, resources and people. The task view class would have attributes and operations which describes how instances of the task class should be displayed. In this example, it would contain data specifying the node’s location and operations for rendering an image of the node. The Ite m L is t provides an interesting alternative approach to the im plem entation of multiple views. Each view of an ItemList is implemented as a special kind of Item List called 40 a ViewList. Thus, each view has its own ItemList (the ViewList), a shared Item List, and may have individual items in its ViewList link to items in the shared Item List through a special attribute called ITEM. If an attribute is not found in the views item , then the ! shared item will be searched for the attribute. Figure 2.11 depicts an Item List with two views. Interestingly, the separation of viewing information from subject information is not the approach used in the Item List. Instead, the ItemList is used to separate shared information from non-shared information. In most cases, this will result in a separation similar to the subject and view separation used in TGE. The use of the ItemList to separate views from subjects requires modifications to a couple of the previously discussed basic features. First, adding new versions of properties m ust be done with respect to either the shared copy or the view copy of any property. Similarly, value retrieval must be specified in terms of either the shared Item List or both the view and shared ItemLists. Another required modification is in the redisplay algorithm. This algorithm needs to propagate the changes made in a shared ItemList to its corresponding views. Each shared item has a corresponding, user-defined m ethod for handling propagation. This m ethod is designed to m ark all of the view items which might need to be changed based on updates to the shared item . This represents a significant lim itation for the use of the Item List in attem pting to describe subjects which do not know about their corresponding views. Once all view item s have been marked with propagated changes, the view will have a form at m ethod called which is intended to allow it to respond to the changes in the subject. This is the intended location of autom atic layout algorithms although none are provided. 41 Name Class Class Class Class Class Depends Task Task Depends Task 'Sample' Source Source Name Name Name "Design' 'Reqs' "Code" Target Duration Duration Target Duration Name Name Class Class Class Class Task Task "View-1 Task Task Color Color Color Green Color Green Blue Blue ITEM ITEM ITEM ITEM Figure 2.11: Example of Views Thus, the redisplay algorithm consists of the steps propagate, form at, erase and redraw. Unfortunately, this design has a serious lim itation in th at form atting cannot propagate changes themselves. In other words, there is no support for having propagation cause other propagations. This means th at autom atic layout algorithms would have to be very 1 lim ited. In particular, they would only be able to affect those items which have been modified. 2 .3 .4 E ffic ie n t R e d is p la y Efficient redisplay is not presented in this dissertation as a component problem. The reason for this is two-fold. First, efficient redisplay is not seen by the editor specifier directly. In other words, there are generally no constructs in the language which specifically address this issue. Second, the issue is one of practical im portance, but can be solved by simply finding a com puter which is fast enough. On the other hand, this issue needs to be treated in any im plem entation of a graph editor generator. Graph editing is an interactive task by nature. As such, it requires fast updates to the visualization based on changes to the graph data. Therefore, while I do not include the problem of efficient updates as a component problem, I certainly address the problem throughout the remainder of the dissertation. Most often efficiency improvement techniques utilize incremental updates. Incremental updates are changes to the objects associated with an editor and/or their representation which do not require m anipulating the entire set of data. This issue is orthogonal to the issues of abstraction, multiple views, and autom atic layout since each of these might be increm ental or non-incremental. For example, an incremental viewing approach would redraw only the elements which require redrawing based on the last set of changes to the inform ation m anipulated by the editor. This approach also requires increm ental layout and increm ental positioning solutions. Several user-interface toolkits, e.g., I n te r v ie w s [35] and O b ject G r a p h ic s [43], sup port increm ental redisplay algorithms. These toolkits allow the user to notify the user- interface about damaged screen regions. Then, in response to a request to redisplay the screen, only those graphic objects which have changed are actually redrawn. To support incremental redisplay, the Item L ist includes a version num ber for each o f , the properties. By comparing the previous version with the present version, a redisplay operation can determine w hat has changed. For efficiency reasons, the Item List tracks all properties which have been modified during the current set of changes under a special attrib u te M ODIFIED. Thus, the display algorithm is able to make minimal changes to the display. Its algorithm is basically: fo r each m o d ified item i f th e m o d ified p rop erty c o n ta in s an a ttr ib u te th a t a f f e c t s th e d is p la y im age, th en s e t drawing c o lo r to w hite decrem ent v e r s io n draw th e item s e t drawing c o lo r to b lack increm ent v e r sio n draw th e item 2 .3 .5 C o m m u n ic a t io n S u p p o r t Domain-specific graph editors are likely to exist as part of a larger system, and in these sys tem s, the usefulness of the graph editor is highly dependent on its portability and its ability to communicate control and data with other elements of the system, i.e., external entities 44 (see Section 1.1). The mechanism for specifying and generating domain-specific graph editors m ust include a technique for specifying and generating communication support be tween the graph editor and external entities. In this section, I present some communication support approaches which have been suggested by previous research. ; Some graph editor generators avoid many communication support problems by making their generator specific to a particular framework. These editors can only communicate ■ with the framework. G erm [7] is a m eta-system for browsing and editing which assumes ! an underlying entity-relationship-attribute (ERA) model and database. Similarly, in the E A R A /G I [46], an extended ERA model is used as the external entity for a graph editor m eta-system . In each of these systems, the graph editor generator is specific to the under lying framework. However, because a large number of domain-specific graph editors are needed on this framework, the power of a generator-based approach may still be practical. Furtherm ore, if the framework itself is portable, then the graph editor generator can be ported as well. In any case, these example are definitely restricted in their portability by their close association with a particular framework. A more general approach to the communication problem is to support control and inform ation flow w ithout depending on a particular framework. The approaches which seem reasonable and have been used are (1) external forms and (2) program m ing language interfaces (also called application program interfaces or APIs). There have been many graph editor generators which have communication support based on based on external forms. An external form is a language which can be used by external entities to encode information which the editor can later consume. D A G [17] is a program th at draws directed graphs by reading a list of vertices and 45 edges, computing a layout and then writing a PIC or PostScript description of the picture. Additional drawing instructions can be connected to vertices and edges. In this case, the external forms are the input language of DAG and the output forms (PostScript and P IC ).' E D G E [44] provides a slightly more interesting kind of external form. The G ra p h ! Representation Language (GRL) is used to describe graphs which are consumed by EDGE. However, GRL is a different language for each domain. For example, all attributes of a vertex type in a particular domain are part of the GRL language for th a t domain. The use of external forms is a limited form of communication since the external entity is lim ited to creating an external form instance, but cannot control how the editor consumes this information. In this case, the external entity can actively provide inform ation for the consumption of the editor, but cannot control editor actions. Furtherm ore, external forms do not support incremental updates to the graph because an entirely new set of d ata is provided by the external entity each time. This leads to unstable views and inefficiency during updates to the graph. Note th at an external form does not inherently run counter to increm ental updates. Increm ental updates could be provided as part of an external form by including a language for specifying changes to the graph d ata such as is suggested in GEDL. Another approach to supporting communication is to provide a general purpose pro gram m ing language as the basis of specifying the external characteristics of the system. TG E [30] is an extensible graph editor built using C + + and Interview s [35], an object- oriented X window toolkit. TG E provides an extensive class hierarchy and utilizes virtual functions so th a t any redefinition of operations in specializations will be picked up auto matically. Domain-specific graph editors are built by creating a set of subclasses through 46 hand-crafted C + + programming. Using TG E, the editor specifier can modify the function ality of TG E to support any external entities supported by C + + and Interview s (virtually any), although no existing classes directly address communication issues. The Ite m L ist [10] is a data-structure which can be used to describe graphical editor d a ta with connectivity between graphical elements. Once an instance of the Item List is created, a set of routines can be called which m anipulate the data and provide viewing and editing capabilities. In this case, the programming language utilizes a passive set of procedures and functions which implement the core of the graph editor generator. Again the editor specifier can communicate with virtually any external entity through hand crafted code. The IS I-G ra p h e r approach is somewhat the inverse of the Item List. In the ISI- G rapher, the core of the editor invokes routines which are domain-specific. In the Item List, the direction of calls are opposite, namely from the domain-specific code to the core. This directionality has a m ajor im pact on the feel of using the graph editor generator and on its ultim ate ability to handle certain communication requirements. In the case where domain-specific code calls the core capabilities, the editor specifier is left w ith much greater flexibility in the specification of communication. The cost of this flexibility is a much harder job specifying the editor and less support for how the communication code should operate. In an editor where the core calls a pre-defined set of functions which must be implemented by the editor specifier, the interface between the core and domain-specific parts is much more constrained and thus is easier to specify. One of the problems with both of these approaches is th at the specification language and the im plem entation language are the same. Thus, the specification language is closely 47 tied to the platform and often this design yields non-portable graph editor generators. For example, TG E requires X-Windows [51] and Unix [48]. This means th a t a MicroSoft W indows-based TG E is unlikely, and even if it did exist, m ajor rewrites axe required to port TG E-based graph editors from one translator to the other. Another approach to specifying graph editors which eliminates this problem is using a different language to specify the domain-specific capabilities. Until GEDL, this has only been attem pted through programmed attributed graph gram m ars (see Section2.2.2.1). Generally, gram m ar-based graph editor generators do not specifically address the prob lem of communication. Graspin provides what amounts to an external form through its concrete syntax specification. However, these editors restrict control flow from the action routines associated with constructs to external entities. This means th at communication is restricted in the same m anner as with other external forms. On the other hand, language-based specification of the graph editors does have the advantage of independence of the implementation of the language from the language itself. Thus, a graph editor specification language might be far more portable than a program- based approach to graph editor generation. However, until GEDL the problem of commu nication of d ata and control had not been addressed. 2.4 S u m m a ry In this review, we have seen th at approaches to generation have taken a wide variety of forms. We have also seen th at there are a variety of approaches to addressing some of the component problems. Tables 2.1 and 2.2 summarize these research efforts. There are some very im portant component problems (or aspects of component prob- 48 Problem Approach Examples K ey Issues/Problems Program - Based Structure- Based ItemList, EDGE, ISI-Grapher, TGE Often hard to integrate sepa rate capabilities. Command- Based Object Maker Hard to define d ata and graphics. Language- Based Grammar- Based Graspin Difficult to build interface us ing gram m ar. Rule-Based Met a-ERA Difficult to build interface us ing rules. Table 2.1: Generation Techniques Research Problem Approach Examples Key Issues/Problems D ata Definition Graph Grammars Graspin Program m ed attributes are re quired to associate complex semantics. Functional ISI-Grapher Requires program m er to build types to define data. Structures EDGE, TGE, ItemList No connectivity rules. A bstraction Subgraph EDGE, Henry Specific, not general mechanisms. Edge Concentration EDGE Layout Fixed Layout DAG and many others No integration of user and ap plication defined criteria. Constraint- Based EDGE Efficient solutions to constraints are needed. Communication Framework Germ Editors are tied to framework. External Form DAG, EDGE No control flow is possible. A PI TGE, ItemList, ISI-Grapher Directionality is concern. Table 2.2: Component Problem Research 49 lems) which have not been addressed in any of the reviewed research efforts. First, none of the efforts have presented a general approach to abstraction. EDGE has provided two specific kinds of abstractions, but a domain might require a different kind of abstraction. Second, none of the efforts have supported the capability of having multiple views of : m ultiple abstractions of a graph. All previous work cited here has had a tight coupling of abstraction w ith viewing. This results in the same kind of problem th a t results from tight coupling of d ata and views. In particular, an abstraction can have only one visualization. Third, even though editing generally occurs in small increm ental updates, none of the efforts have addressed incremental algorithms for updating data, abstractions, layouts and t redisplay. For example, even if an incremental redisplay algorithm is p art of the core capabilities, a small change to the graph can still cause the layout algorithm to generate a large set of new positions (the layout algorithm is neither stable nor increm ental) and thus the increm ental redisplay is almost irrelevant in the face of non-incremental updates to the display. A language for specifying and generating graph editors must be capable of specifying domain-specific capabilities related to each of these areas. At the same tim e, the specifi cations should not be so complex as to make the language unusable. In the next chapter, I will present an in-depth discussion of the component problems and how a language for specifying and generating domain-specific graph editors might address them . 50 C h a p ter 3 C o m p o n en t P ro b lem s My approach to the problem of generating graph editors is to design a language and translator which can be used to specify and generate domain-specific graph editors. The m ost fundam ental of the language requirements is to provide integrable solutions to the component problems, and to provide these solutions as constructs in the language. In this chapter, I present an in-depth discussion of each of the component problems and possible approaches to their solution. 3.1 D a ta D efin itio n For each domain, there will be a different model of the d ata which describes the domain. Thus, a central requirement for a language which supports graph editor specification and generation, and the starting point for a graph editor specifier, is the ability to model the inform ation which comprises the domain. I will call this kind of model a domain data model, and instances of the model domain data. For example, in the task-dependence graph editor, the types Task and Dependency are the domain d ata model and a particular set of tasks and dependencies would be domain data. 51 The model used to describe a domain data model is the graph editor generator’s meta model. In the task-dependence graph editor, the meta-model would be used to describe w hat it means to be a task and dependency, and how instances of these two types can be combined to form a task-dependence graph. Note th at these levels of abstraction (m eta model, data model, data), are the same as those used in database theory. For example, Entity-Relationship (ER) [45] is a meta-model which can be used to describe data models which are in turn used to control data. One im portant distinction must be made before considering the problem of design ing a meta-model. This distinction is related to the various roles people perform when interacting with a graph editor generator system. These roles are • the language designer, who defines the language and consequently the meta-model, • the editor specifier, who uses the meta-model to build a specification of the domain data model, and • the editor user, who uses the domain-specific graph editor to m anipulate d ata which conforms to the domain data model. Thus, the problem of designing a meta-model is th at the language designer m ust create a m eta-m odel th a t the editor specifier can use to describe an inform ation domain and ultim ately can be used as the basis of developing the entire editor. Now, we can consider what a meta-model must provide. The definition of the information domain in terms of a graph consists both of specifying the type of inform ation th a t is modeled and the set of legal graphs th at can be achieved within the domain. In this section, I will present a general theory of d ata definition in 52 term s of a meta-model in a language for graph editor specification and generation. In ; the next chapter, I will present a particular set of language constructs which address data 1 definition. A domain d ata model is a graph type GT = (VT , ET , CR ), where GT is composed of | a set of vertex types, V T , a set of edge types, ET , and a set of connectivity rules, CR, which specify the allowable relationships between edges and vertices. Both vertices and edges can have associated d ata in the form of attributes. Thus, a vertex type and an edge type are the combination of a name and a list of attribute types. A vertex is an instance of some vertex type. An edge is an instance of an edge type and by definition has two associated vertices. Vertices and edges can be separated in different types according to their attributes. The connectivity rules describe the set of legal graphs within an information domain. Two basic approaches have been suggested for specifying the set of legal states of a language including graph languages. One approach is to define a set of legal transform ations T, where for all elements of T, T(G) = G' and for all legal graphs G, G' is also a legal graph. Thus, given an initial legal graph, only legal graphs can be achieved. This is the approach used in syntax-directed editors since all edits axe transform ations which enforce syntactically correct results. This is also the approach used in gram m ar-based graph editors such as Graspin [37]. The second option is to allow a set of transform ations T where for all elements of T, Ti(G) = G' and G' is not guaranteed to be legal. Instead, a legality function L is defined where L(G) = true if the graph G is legal. In general L is a set of rules which are applied to the graph to ensure its correctness. This form of editing is called syntax-checked editing. 53 Actually, some syntax-directed editors, e.g., the Synthesizer Generator [47], allow a; combination of syntax-directed and syntax-checked editing. In particular, the Synthesizer G enerator allows unchecked input for some constructs in the language, b ut the syntax i checking operations are applied upon completion of the input before more input can be j attem pted. Thus, the overall effect is th at of syntax-directed editing where only small tim e spans of incorrect programs can result. In term s of graph languages, a syntax-directed approach would require the use of graph transform ations as discussed in Section 2.2.2.1. Basically, a graph transform ation consists of a specification of a legal starting state and the resulting transform ation on the graph. , .Thus, for each possible graph G, there are a set of possible transform ations as defined by checking the start states of the transform ations. W hen the user chooses a transform ation, ; the resulting graph is also legal. A syntax checking approach is likely to look more like a set of rules which check the correctness of the graph. Each of these rules will be applied at specific times of the editing session to determine graph correctness. This was the approach used in rule-based languages (see Section 2.2.2.2). A language-based approach to graph editor specification might use either of these ap proaches. In fact, both approaches have advantages and disadvantages. Using a transform ation- based approach implies th at all changes are syntactically correct. Some inform ation do mains may not be conducive to this approach because some intermediate states are needed in a series o f edits which are not syntactically correct. On the other hand, a syntax-checking approach generally faces the problem of specify ing the rules which govern both graph legality (also required in syntax-directed) and the 54 , tim e o f application of these rules. The tim e of application is the point during editing when the rules are applied to check for correctness. In the syntax-directed approach, time of ap plication is irrelevant since all transform ations are legal. In the syntax-checked approach, the tim e of application can be at every change, after a series of changes, or interactively specified. It is unlikely th a t the rules would be applied at every change since the flexibility of having interm ediate illegal states was the purpose of the syntax-checked approach in the first place. The hybrid approach used in the Synthesizor Generator can be applied to graph editing as well. In graph editing, we would allow some edits to occur outside of syntax-direction, b ut these edits would ultim ately be checked to enforce graph correctness. This requires the graph editor to provide both transform ation definitions as well as checking rules. Furtherm ore, the editor must define where each form of editing is used. Probably, there will be a well-defined period when syntax-direction can be relaxed. 3.2 A b str a c tio n A bstraction is the ability to hide irrelevant detail from the user. The most common kind of abstraction is composition abstraction. In this form, the user is presented with a composite vertex which represents all of its children. This leaves the graph meaningful to the user without overloading the display with unim portant details. In a graph editor abstraction is accomplished on two levels. First, the graph type definition must include special kinds of graph elements, i.e., vertex and edge types, which are intended to abstract other graph elements but still leave the graph meaningful. This means th a t p art of defining an abstraction is specifying the additional vertex and edge 55 types th at can be used to in the abstraction. For example, defining composition abstraction requires the definition of a composite vertex type and a child edge type. The second p art of abstraction is the ability to view the abstracted graph in a special way th a t hides the unnecessary details. For example, if we wished to view a particular subgraph as a single node, then a special kind of view could be established which translates th a t subgraph into a single visual element. The standard treatm ent of abstraction is to consider it an aspect of visualization. This approach leaves a couple of significant problems for the editor designer. First, the editor designer will be forced to build very specific layout algorithms which include determ ining the set of non-hidden graphic objects and then doing a normal layout. This would require extra com putation at each application of autom atic layout. Second, the designer would be hard pressed to come up with an approach to multiple views of multiple abstractions. In other words, we might wish to view two separate parts of our task-dependence graph in both a simple transform ational view and a highly specialized view such as text with indentation for composition. This requires a tree of information as shown in Figure 3.1. In this case, the two abstractions are subsets of the entire graph, and the views are two approaches to the viewing of the abstraction. An alternative view of abstraction is introduced in this dissertation. This view is th at an abstraction is a function which operates over the data and returns only the d ata of interest. In other words, an abstraction is an aspect of the data domain. This is similar to the separation of d ata and views, which is already a well established user-interface concept [31]. It is based on the realization th at data and its visualization are separate concepts which should be treated separately. Similarly, the relationship between data, abstraction 56 Graph A bstraction-1 Abstraction-2 View-4 Figure 3.1: Two Views of Two Abstractions of a Task-Dependence Graph and views is th a t they are related in the same m anner as views and data are related, but it is advantageous to consider them as separate entities in an editor. The im portant concept for an abstraction is its meaning. An instance of an abstrac tion consists of an abstraction function A (G ) = G' which translates a graph G into an , abstracted graph G '. Note th at this definition suggests th at abstraction should be treated as a transformation rather than as simply a subgraph operation. Thus, an abstraction might add information to the graph. This would seem to be a lim ited definition of abstraction in th at part of abstraction i is establishing the relationship between elements of a graph th at abstract other graph elements, e.g., composite vertices, and the rest of the graph. However, a command which establishes an abstraction may consist both of adding inform ation, such as a composite vertex, to G before G' is established and establishing the interest of the user in the child vertices. This definition of abstraction can be used to establish a tree of abstractions where each , abstraction can either be over the underlying graph or over a graph produced by another abstraction (see Figure 3.2). In other words, given that abstractions are simply trans form ations which themselves produce graphs, we should be able to compose abstraction functions. One of the interesting points about this definition of abstraction is th a t it implies th at the abstraction function A m ust be instantiated at run-tim e. For example, composition abstraction requires th at the function be different based on which composites axe currently abstracting their children and which are not. However, the instantiated abstraction can be based on a generic abstraction function defined by the editor designer. This generic 58 Data Domain Visualization Domain View View G raph View A bstraction A bstraction A bstraction A bstraction A bstraction Figure 3.2: View Tree with A bstraction Composition and Multiple Views abstraction defines a graph generating function G A(G , AD ) = (G', A D ') where additional input information is available through abstraction d ata AD . This inform ation can be specified at run-tim e so th at the abstraction function can operate differently over the G to G' transform ation. 3.3 V isu a liz a tio n D efin itio n In addition to modeling the information which describes the domain and transform ation to the graph d ata which provide the specific set of data of interest to the user (abstractions), a graph editor specification language m ust support specification of the visualization of the information domain. The basic capability of visualization is support for the specification of a function F (G ) — V , where G is a graph-based model of the inform ation dom ain as described through the data and abstraction definitions, and V is a set of graphical objects which render a picture of the associated graph. There are a number of issues related to the function F which I will discuss in the following sections. 3 .3 .1 G r a p h ic O b j e c t s The central capability of the visualization function F is to be able to generate a set of graphic objects which, taken together, form a visualization of the graph. Furtherm ore, ■ j since the user interacts only with the graphical objects and does not directly m anipulate the underlying data, the graphical objects represent the graph data and are the interface to the graph data as far as the user is concerned. Graphic objects are entities such a boxes, lines, text, bitm aps, circles, etc. We call a set of these graphical objects a “picture.” Associated with these objects are inform ation p such as line thickness, fill pattern, etc. The underlying graph d ata must not be dependent on the graphical objects in order to support multiple views. However, the graphic objects are dependent on the underlying data. W hen a change is made to the underlying data, the graphical objects may need to be updated. Changes to graphical objects may or may not be reflected in the underlying data. For example, if a user is allowed to change the viewing characteristics of a particular graphic object through operations, e.g., zooming in or out, these operations will have no effect on the underlying data. 3 .3 .2 A u t o m a t ic L a y o u t Layout is the problem of positioning graphical objects in a way th a t is aesthetically pleas ing and meaningful to the user. This is a difficult problem because' the definition of aesthetically pleasing and meaningful differs among graph types, application dom ain, and users. Furtherm ore, some definitions of aesthetically pleasing, e.g., minimizing edge cross- 60 ings, lead to N P-hard problems [18]. For this reason, most layout algorithms use heuristic approaches. This problem is made even more difficult because positioning inform ation can be de rived from several sources including the user, application (editor), autom atic layout algo rithm and stability algorithms. The user might specify positioning information by request ing th a t the visualization be changed in some way which affects the position of graphical objects. This is typically a move or re-size operation. The application might create po sitioning inform ation by specifying application-specific positions, e.g., place critical path vertices near the center. The editor might also incorporate autom atic layout algorithms and stability algorithms which are used to position the graphics in a general manner. There are two basic ways which other researchers have proposed as a means of in tegrating these alternate sources of positioning information. [46] and [57] suggest th at general layout algorithms should be developed which accept graph data, constraints and aesthetic criteria, then integrate this information with the general approach to layout in order to produce position information. This approach combines the entire problem into a single conceptual function, L (G O ) = P , where GO are the graphic objects and P is the positioning information. Of course, the function L would require additional param eters which describe user-defined constraints, layout type, etc. However, at this point it is not clear exactly w hat the input to this function would be. Furtherm ore, it is not clear how the expanded version of this function could be efficiently implemented. The other approach to integrating sources of layout inform ation is suggested by [44], which we call the constraint-based approach. It suggests th at each source of layout inform a tion produce competing and prioritized requests in term s of a single constraint language. A constraint solver is then used to decide how these constraints should be satisfied in order to generate positions. If we take the second approach to integrating the sources of layout inform ation, then ■ ( (layout consists of a set of layout functions T i , i 2) •••> Tn- Each function accepts a set of | graphic objects and produces a set of constraints, i.e., Li{GO) = C. The positioning constraints, C \, C2, Cm , each have a specific priority and describe aspects of the final layout. The layout functions i , are created dynamically and probably represent a particu lar source of layout information. In most cases, a general layout algorithm , e.g., Sugiyama’s hierarchical layout [56], will produce a large set of medium to low priority constraints. The user and application will define functions which produce higher priority constraints. For example, the user might be able to move a graphic to a particular position. This would create a function which produces a constraint to keep th a t graphic in th at location. Most likely this constraint will be higher priority than other constraints. Once the set of competing constraints has been generated, it m ust be solved to deter- , mine the actual position of the graphics. A constraint solver consists of a function C S which takes the constraints and generates the positions of each of the graphical objects, i.e., C S {C \, = P t,..-,P n - The prim ary concern when dealing with constraint-based integration of layout information is that the constraint solver m ust be implemented effi ciently. 3 .3 .3 M u lt ip le V ie w T y p e s Up to this point, I have been assuming th a t there is a single view type for any graph. Actually, there can be many different visualization functions which result in possibly many 62 visualizations. For example, in the task-dependence graph, a hierarchical view and a predecessor-successor view are both reasonable. Accordingly, multiple views can exist simultaneously. Thus, the visualizations must result from a set of visualization functions. 1 The user will have a particular set of views active at any point. In order to have separate views, positional information and graphic inform ation asso ciated with different views must be kept separate. This requires each view to have its own set of graphic objects, a layout or set of layout functions, and a constraint m anager to position the graphical objects. This also requires th at the positions of graphical objects are associated with the graphical objects themselves and not with the underlying data. 3 .3 .4 S u m m a r y The result of each of these definitions of aspects of visualization is that visualization is a composition of function applications. The visualization function F (G ) = V where G is the graph d ata and V is the visualization is actually a multi-step process. F consists of Fg0(G) = GO where G is the graph data and GO are a set of graphic objects. Taking the constraint-based approach, F also defines Fl (GO) — C where the graphic objects are used to define C, a set of constraints. Finally, F contains a function F c s(C ,G O ) = P which positions the graphic objects in the visualization. 3 .4 E fficien t R ed isp la y Because the changes to the underlying graph d ata in a graph editor are likely to occur only in small increm ents, changes to the data which the editor controls will often be small. It would be advantageous to support incremental algorithms whenever possible in order 63 to minimize the com putation tim e in calculating the effect of changes to editor data. Each of the previous functions is described in a non-incremental fashion. In other words, any change requires application of the function to the entire set of data. A language which supports incremental algorithms m ust support the specification of ] functions which operate only over changes (As) to the d ata and calculate the proper set of resulting d ata as well as the change th at resulted. i I The heart of the incremental update problem is th a t a change to the graph becomes a ! A G rather than simply an entirely new graph. Thus, a function which accepts a A G and generates the new set of graph data must exist. An increm ental algorithm for controlling abstraction requires th a t the abstraction func tion AA exist where A A (A G , A A D ) = (AG'^ A A D '). Thus, changes to the underlying , graph d a ta will cause each of the abstractions to respond to As to the graph they are abstracting and will appropriately update their graph and propagate any changes they have m ade to their graph. An increm ental viewing algorithm requires changes to various aspects of the view function F. In particular, we need a function A F (A G ,V ) = ( 7 ',A E ) where A G is a change to the graph and V ' is a new visualization. There m ust also be a new set of layout functions A L \ ,A L 2 ,...,A L n where each A L {(A G O ,C ) — AC{ where AG O is a set of changes to graphic objects and A C = UAC, is a set of changes to the constraints. There also needs to be a A C M (A C ) = A P which create a set of updates to the positions of the graphic objects. Finally, each of the changes ( V ',A C ,A P ) m ust be converted into a new visualization (V ,C ,P ). 64 3.5 C o m m a n d D efin itio n In order to request changes to the underlying graph data, a set of operations m ust exist. These operations are available through the user-interface and may include various inter- I I actions with the visualization. The result of an operation is a change to the graph data 1 which results in changes to the views of the data and possibly to the set of currently legal operations. Operations are of two basic forms, tools and commands. One issue th a t im pacts all operations is how to determ ine what set of operations are available. Given any particular state of the graph only a limited set of operations may be available. One approach to , availability is to define a set of rules associated with each command which m ust be satisfied before the command can be chosen. This supports both a post-condition and pre-condition approach to operation availability specification. The other approach is to use syntax-directed editing based on graph gram m ars. In this approach, the set of available operations are those th at can have their “left-sides” satisfied. This approach forces the graph editor to use syntax-directed editing. It also does not allow for operations which do not operate over the graph data, e.g., zooming in or out. 3 .5 .1 C o m m a n d s A command is a function F ( G ,S ) = (A G ,A A D ,A V ) where G and S are the graph and the editor state respectively, and A G , A A D , and A V are changes to the graph, abstraction d ata and the views respectively. In addition, a command has an associated pre-condition, P , which is used to determine the availability of the command. 65 3 .5 .2 T o o ls A tool operation is a combination of a command and a direct m anipulation [53] of graphic objects. Thus, a tool combines a direct m anipulation function, D M , with the F and P of a command. The direct m anipulation function must support the definition of various > anim ated effects such as grasp, wield and release. Furtherm ore, the effect of the command associated with a tool is more complicated in th at it must also take into account the effect of the direct m anipulation function. Thus, a tool’s prim ary function is F (G , S, D M ( V )) = (A G , AT, A S) where DM(V) = (A G ', A S ', A V '). A tool operation may also include the use of a very specialized D M function such as a pop-up editor. In this case, the D M function will create a window which supports specialized interaction such as attribute editing. 3 .6 C o m m u n ica tio n S u p p ort Before I present a general description of the communication support problem, I will first present a concrete example of communication requirements in a specific domain. The original design of GEDL only supported communication in the form of file I/O initiated by the graph editor user. The problem of designing GEDL to support more powerful forms of communication with external entities arose from creating graph editors to serve as a presentation/evolution mechanism in ARIES, an environment supporting the acquisition and formalization of system requirements [25, 26]. Thus, I will use this example as a specific instance of the requirements related to the communication problem. ARIES is built on a central knowledge base which stores inform ation related to re- 66 quirem ents specifications. Prior to the use of GEDL-based graph editors, a variety of presentation mechanisms supported notations th at allow interaction with the underlying knowledge base. These notations included functional decomposition diagrams, uses dia gram s, inheritance diagrams and state-transition diagrams. Thus, a presentation mecha- | nism uses a particular notation to view a specific part of the knowledge base, which I call the graph of interest. GEDL was suggested as the basis of generating graph editors replacing many of the • original presentation mechanisms because of the cost of developing graph editors from scratch and the poor support th at the resulting editors had for autom atic layout, abstrac tion, m ultiple views and efficient redisplay. Since the knowledge base is used to store information which is m anipulated by the graph editors, the prim ary external entity for the graph editors is the knowledge base. The inform ation m anipulated by the graph editors is extracted from the knowledge, base through queries. The user interacts w ith the graphical depiction of the graph through the operations and tools defined for the graph editor. Some operations in the graph editor require changes to the underlying knowledge base. The approach taken in the ARIES presentation mechanisms was to (1) request an update to the knowledge base, (2) regenerate the graph of interest through queries, and (3) regenerate the presentation of the new graph. This kind communication is seen in many domains. It is a circular update cycle where the editor acts as the update interaction mechanism. However, the communication problems in ARIES are more complex than the average case. The first p art of the complex communication is an interesting m ethod of specifying the changes available to the user during an editing session. All changes to the knowledge 67 | base occur through invoking transformations. The possible transform ations available for any particular graph depends on the state of the knowledge base. In ARIES, an evolution mechanism m ust determine the effect th at the user desires, where effects are a characteri zation of the modification. Each different graph editor will have a fixed set of effects which the user can choose/dem onstrate. Based on the chosen effect, there are a variable number of possible ways which the effect can be achieved. This set of transform ations cannot be determ ined until runtim e. Thus, while the editor specifier can state the set of effects, the result of choosing an effect is dependent on communication with the knowledge base. In response to a request for an effect, the knowledge base m ust be queried to find a list of possible transform ations which can cause the effect. The user then can select from the list of transform ations in order to choose the transform ation by which the effect is achieved. For example, a State Transition Diagram is used to represent a set of states and events which cause transitions between these states. In an editor for this diagram type, the user is able to request the effect of an additional event. The event is a transition between states (an edge). The effect of an additional event can be achieved by a variety of transformations. Each of the transform ations have the net effect of adding an event to the graph. Thus, a list of the transform ations which yield additional events is presented to the user for selection. Once the user has selected one of these transform ations, the update is m ade to the knowledge base by requesting the transform ation. This transform ation might be very complex which leads us to the second kind of complexity. The second form of complex communication arises from the fact th at the graph editor and the knowledge base m aintain separate copies of the graph which m ust be kept consis 68 tent. The ARIES presentation mechanisms insured consistency by regenerating the graph of interest after each transform ation. This has two drawbacks. First, it is costly, especially for large graphs. Second, the state of the presentation is lost which makes it unstable. In order to address these problems, the graph of interest m ust be changed as the result of transform ations rather than regenerated. This requires the knowledge base to inform the graph editor of updates to the graph of interest. The flow of the changes to the graph of interest can be achieved by involving (1) user interaction, (2) polling of the knowledge base, or (3) control flow from the knowledge base to the graph editor. Certainly, in a system th a t might have many sources of updates to the knowledge base, the third alternative is best. This requires both information and control flow from the knowledge base to the graph editor. Now th at I have presented a concrete example of the problems surrounding communi cation support, I will consider this area in a more general sense. The problem of designing a language which both supports portability and external interfaces is prim arily a question of the required level of communication. In other words, a language might be capable of supporting a few kinds of interaction w ith external entities and still not sacrifice po rta bility. However, as the level of required communication increases, the portability of the language is likely to suffer and the design of the language becomes more difficult. In the context of graph editor generators, the required level of communication between a domain-specific graph editor and the rest of the system can vary greatly. The following list suggests an ordering of levels of communication required between the graph editor and other elements of the system: • N o n e 69 This level of communication would result in virtually useless graph editors where the only way of “communicating” with other elements of the system is through I/O of which the editor is unaware. For example, a screen dump or a video image could ‘ serve as a crude form of communicating with the editor. • E d ito r to E x te r n a l E n tity C o m m u n ic a tio n A usual characteristic of a graph editor is the ability to use the persistence mechanism j of the framework. A framework is most likely an operating system, but some graph ; editors are built on top of other kinds of frameworks, e.g., an object managem ent system. In any case, a framework will have some persistence mechanism, be it ; files or objects. A framework will also have some mechanism for invoking actions of other elements of the system. For example, the framework can be used by the : editor to print the current visualization of the graph. Thus, editor to framework communication generally implies th a t editor to external entity communication can be established as well. The key feature of this level of communication is th a t the editor has the ability to utilize services provided by the external entity through an interface provided by the external entity. The external entity is only able to “communicate” with the graph editor through invocation level operations. Finer grain requests to the editor are not supported. • In fo r m a tio n In te r c o m m u n ic a tio n Fine-grain communication between external entities and the editor begins w ith the ability of external entities to send information to the editor. A classic example of this 70 kind of system would be a directory graph editor. Because the graph might change , outside of the communication between the user and the graph editor, the framework ' I m ust be able to inform the graph editor of changes. While this example could be : solved by the graph editor continuously searching the directory tree for changes, it j would be terribly inefficient. Furtherm ore, there are cases where the editor might not have direct access to the information from the external entity. In both cases, the framework should be able to inform the graph editor of information which is relevant to the editor. The difference between this category of communication and the previous is somewhat precarious. Prim arily it hinges on the active participation of the external entity in providing inform ation without direct control over the actions of the editor. • C o n tr o l a n d In fo r m a tio n In te r c o m m u n ic a tio n A much more powerful form of communication between the graph editor and external entities is the ability to send information back and forth, and also to effect specific changes in the other system. This might seem similar to information intercom m uni cation. However, information intercommunication can be achieved by allowing the user to periodically request more information from the external entity. This means th at the editor is still in control of the system and the flow of inform ation. In con trol intercom m unication, the user and the rest of the system are able to control the functions of the editor. Thus, information flow to the editor could be accompanied by a control flow which requests th at the editor handle the new inform ation. This would elim inate the need for user interaction or polling in the flow of inform ation 71 from the external entity to the editor. 3 .7 S u m m a ry In this chapter, I have further defined each of the component problems and identified ' possible approaches to these problems. This information is summarized in Table 3.1. This inform ation represents the first critical step in developing a solution to the problem of generating graph editors. This step is to identify the nature of the component problems , and alternative frameworks for addressing these problems. W hile these frameworks are not solutions in and of themselves, they do represent a path to follow in building the solutions. Given these alternatives, my next steps are to choose a particular approach, find a particular solution using th at approach, and build up mechanisms for utilizing the solution. Since my overall solution is presented as a language design, the particular solutions to each of these problems are built-up as constructs in the language. I will now present GEDL, which implements solutions to these problems through a particular set of constructs. 72 Problem Approaches Summary D ata Definition - G raph Type Definition Vertex and Edge Types Standard. Real issue is legality of connections. D ata Definition - G raph Legality Syntax-Directed Too restrictive. Some updates require il legal interm ediate states. Syntax- Checked Key issue is when to apply checking. Does not give any definition to kinds of operations. Relaxed Syntax-Directed Improves flexibility. Gives definition to timing. A bstraction Aspect of Visualization Visualization Does not allow multiple views of multiple abstractions or abstractions of abstrac tions. Layout is more complex Aspect of D ata Do main (Transformation) Must establish relationship between data, abstraction, and view. Transform ation function must be dynamically established and modified. Visualization Graphic Objects Coupled with D ata No multiple views. Separate from D ata Must be associated w ith and respond to data. Visualization - Integrating Layout Sources General Layout Difficult to implement. Not clear w hat input is. Not clear how it functions. Constraint-Based Efficient solution of constraints is needed. Efficient Redisplay Versioning Type coupling of data and view. Space expensive. D elta Functions Requires integration throughout defini tion of generation. Commands Availability Grammar-Based Not flexible. Hard to specify visualization only operations. Rule-Based Supports pre-condition and post-condition availability. Communication None Only screen dumps are possible. Editor to external entity Fine-grain communication is not possible. Information Intercommunication User must request d ata updates. Often done with external forms. Control and Information Intercommunication Requires sophisticated im plem entation. Table 3.1: Component Problems and Possible Approaches 73 C h a p te r 4 G E D L : O v erv iew , D a ta D efin itio n an d A b str a c tio n The Graph Editor Description Language (GEDL) can be used as a basis for specifying and generating domain-specific graph editors. In builds upon concepts and capabilities intro- i duced previously for TG E [30], but the focus is now aimed at the autom ated generation of graph editors from GEDL specifications rather than from hand-crafted programs. GEDL provides a set of constructs which are the carrier of particular approaches and solutions to the problems discussed in the previous chapter. It is im portant to note th at GEDL is not itself the solution to the problem of graph editor generation. R ather, GEDL represents one possible set of constructs which describe my solution. In other words, the solution itself is made evident through GEDL. As the GEDL constructs are presented, it becomes clear what my solutions are to the problems described in the previous chapter. In this chapter, I will present an overview of the GEDL language. Then, I will introduce specific GEDL constructs for defining the data domain. The following two chapters will describe other aspects of the GEDL language. A full description of the GEDL syntax can be found in Appendix A. A complete description of two editors specified with GEDL can be found in Appendixes B and C. 74 Vlew-1 Abstraction-1 Graph View-3 Abstraction-2 View-4 Figure 4.1: View Tree 4.1 O v erv iew The design of GEDL is object-based. There are five main classes of objects which are used to describe GEDL-based editors, namely data, abstractions, views, operations and editors. I refer to these parts of the GEDL language as components. Along with the definition of components, we also must be able to define vertex, edge, and graphic types. I refer to these as elements. 75 In order to give an overview of the GEDL specification language and its approach to the problem area, I must first describe the architecture of a graph editor which is generated by the GEDL translator. The key element in the architecture is the concept of a view tree, see Figure 4.1. The root of a view tree is the GEDL graph data object which contains j the graph d ata being m anipulated in the graph editing session. The children of the graph d ata will be abstractions, and then views. An abstraction is a transform ation on the graph which leads to a new graph of interest. For example, composition abstraction might lead to a subgraph where some parts of the underlying graph are hidden as composites. A view is a transform ation from a graph (either an abstraction or the base graph) into a set of graphical objects which represent the graph. Figure 4.1 shows an example of a view tree th at might exist during a graph editing session. In this case, two composition abstractions are being used to transform the un derlying graph. One hides one part of the graph and the other hides another p art of the graph. Two kinds of views are being used to view the graph data. One kind of view is a simple one-to-one mapping from graph data elements to graphical elements where boxes represent vertices and lines represent edges. The other view is a specialized view of the graph data where text represents vertices and edges are represented by indentation and order. Changes to the graph editor state are implemented through propagation. All changes are requested through small increm ental requests, such as “add a vertex to the graph,” called deltas. In response to a delta, an appropriate delta function associated with one of the described GEDL objects is invoked. The delta function may (and in most cases will) 76 Original AddVertex(V) Abstraction-1 AddVertexi View-1 Graph AddVertex(V) GO Abstraction-2 No Update Figure 4.2: Propagation Example change its data. For example, the add v e rte x delta will result in a call to the graph’s AddVertex function which will probably result in the graph adding th at vertex to its data. In response to the change of the graph data, the delta will be propagated to the children of th at object in the view tree through invocation of the appropriate delta function. An example of propagation is shown in Figure 4.2. This example shows a request for adding a vertex to the graph data. This results in a call to the AddVertex function associated with the graph. This function updates the graph d ata and propagates the changes to the two abstractions. Thus, each abstraction will receive an AddVertex delta. 77 In response, one abstraction decides to ignore the new vertex and the other adds it. The latter action causes its views to receive an AddVertex delta. This, in tu rn , causes an update to the view with the appropriate graphical data. The propagation of small changes like AddVertex is controlled through a transaction model. Transactions are associated with a particular component, e.g., a graph. A transac tion groups a set of deltas. In response to a commit of a transaction, these changes will be propagated. This transaction model is used to compose deltas into larger kinds of changes J as in [15]. Given this architecture for a GEDL generated editor, we can now consider the specifi cation language. The highest level component in a GEDL specification is an editor. The editor is prim arily a composition of data, abstraction, view and operation specifications. It also allows the specification of editor state attributes. A set of attributes of the state of an editing session is built-in, e.g., whether the graph has been modified. Additional domain specific state inform ation can be specified in the editor specification. Furtherm ore, the display of this state information in a state display can be specified. The central capability in any graph editor generator is ability to define a model of the domain using a graph meta-model. The definition of the information domain in term s of a graph consists both of specifying the type of information th at is modelled and also the set of legal graphs th at can be achieved within the domain. In GEDL, d ata definition consists of describing the vertex and edge types and a def inition of how the graph type responds to various requests for change in the graph. For example, to introduce the Task vertex type in a task-dependence graph, we would do the following: 78 I v e r te x Task i s e d it a b le : name : s t r in g ; d u ra tio n : in t ; p r iv a t e : c r i t i c a l : b o o l; end v e r te x Task; A graph specification consists of attribute, connectivity, and delta function specifica tions. The connectivity specification states the allowable connections between vertices for each of the edge types and also global connectivity constraints regarding cycles and trees. The delta function specification use the GEDL expression language to update the set of vertex and edge instances in response to deltas. In GEDL, these deltas are handled by a small and simple set of delta functions: • Create • AddVertex • AddEdge • DeleteVertex • DeleteEdge • Touch Vertex • TouchEdge • ReconnectEdge • BeginTransaction • Com m itTransaction • A bortTransaction • Set - A ttribute access • Get - A ttribute access In many domain-specific graph editors, the im plem entation of these functions is simply to allow the operation to occur, and this is the default if no value for the function is specified. 79 In the GEDL language, an abstraction definition describes a kind of abstraction which is instantiable w ithin operations. An abstraction must have the ability to be created and respond to deltas in the graph. This leads to basically the same definition as the graph. ■ However, the abstraction will have a very different role in a graph editor. Namely, it will attem pt to restrict propagation of certain vertices and edges (or even ju st transform them ) such th at the graph produced by the delta functions of the abstraction is the graph of interest to the user. View specifications consist of views and graphics where a graphic is a simple graphical element or a composite graphic. A simple graphic element can either be a box graphic which is basically a box containing some graphic elements, or a line graphic which connects two boxgraphics. For many editors, each vertex type will have an associated box graphic type and each edge type will have an associated line graphic type. Thus, the rendering of a vertex and edge would be the rendering of the composition of graphic components which are associated w ith them . Simple graphics can make use of other graphic objects such as boxes, lines, text, bitm aps, circles, etc. Associated w ith these objects are inform ation such as line thickness, fill pattern, color, etc. A composite graphic is responsible for a particular set of graphics including simple graphics and other composite graphics forming a hierarchy of graphic images. This requires th a t it respond to new graphic objects, changes to underlying graph d ata associated with graphic objects it controls, and deletion of graphic objects. However, the biggest function of a composite graphic is controlling the positioning of its m ember graphics. Layout (or positioning) of graphical objects m ust accept positioning constraints from an autom atic layout algorithm, the user and the domain-specific graph editor. In GEDL, integration of these various sources of positioning information is supported by a constraint m anager. ■ Taking this approach leads to the problem of developing a constraint m anager which can generate positions for graphical objects based on a prioritized list of constraints. O ther ; researchers [36, 63] have tackled similar problems. The constraint resolution problem for graphical object layout is actually quite complex since it involves non-linear circular . equations. However, we have the advantage of a lim ited set of constraint types and can easily have a full ordering of constraints in term s of priority. Given these lim itations to ■ the problem, I have designed algorithms which incrementally or non-incrementally solve ' the constraints in ways th at ensure th at higher priority constraints are satisfied when they conflict w ith lower priority constraints. In order to support more efficient positioning, we have designed GEDL to support the creation of sets of constraints which can be solved independently. This is done by associating a separate set of constraints with each composite graphic. In response to changes in its graphics, a composite will generate a series of changes to the constraints which ultim ately govern the positions of its graphics. The positions which the constraint m anager generates are relative to the positioning of the composite. Thus, the composite graphics form a tree of independent sets of positioning constraints so th a t changes to the graph, abstractions and graphical d ata will affect only a lim ited p art of the entire set of constraints. Actually, the changes might affect the positions of every graphic, but a limited set of relative positions would be calculated. The use of composite graphics to control the layout of its children also supports separate layout algorithms for separate parts of the graph. For example, in an organization chart 81 we m ight want to have certain types of organizational units displayed horizontally and other parts vertically. This can be achieved by defining two different types of composite graphics, each with a separate approach to constraining its children. A view basically governs how changes to the graph d ata will affect the composite j graphics. Associated with each view is a tree of graphics starting with a particular type of composite graphic. Thus, the definition of a view is the definition of graphic object types, and the definition of a set of functions to deal with creation of the view and how it responds to changes to the d ata which it is viewing. In order to request changes to the state of the graph data, abstractions or views, a . set of operations must exist. These operations are available through the user-interface and may include various interactions with the visualization. In GEDL, operations are of ' two basic forms, tools and commands. A tool uses direct m anipulation of the graphical depiction to dem onstrate a desired change. A command is a menu selectable operation. All GEDL editors can utilize a set of pre-defined operations including file m anipulation, select, view control (zooming), edit, and cut-and-paste. Given any particular state of the graph only a lim ited set of operations may be available. This can be modelled as a set of rules associated with each command which m ust be satisfied before the command can be chosen. In GEDL, every tool and com m and has a pre-condition function which is used to determ ine when it can be invoked. W hen they are invoked, then the operation expression is evaluated in order to update the state of the editing session. In addition to the standard expression language, a tool operation may also include the use of a very specialized direct m anipulation (DM) functions, e.g., D M select, DMmove, 82 DMedit. Each of these functions are pre-defined and have a standard flavor. However, m ost types of direct m anipulation which are required in specific domains can be supported ' through these primitive functions. For example, if we want to enforce th a t every vertex I is connected to the main graph, then a vertex_add tool would include a move operation using the vertex graphic and a move operation using a line graphic. One of the more im portant roles of operations is the m anipulation of the viewing tree. As the user edits a graph, specific abstractions and views will be created and destroyed. 1 The operations m ust control these requests by m anipulating the view tree. The interface to the view tree is simply a special kind of graph which can be m anipulated like any other , kind of graph data. Communication is supported in GEDL in two ways. The first m ethod is to allow ex ternal function declarations. The form of these functions and the m anner of incorporating ■ them into editors is translator dependent. However, the basic idea is th a t code w ritten in a general-purpose programming language th at has the full support of the target platform can be incorporated into a GEDL editor. The second m ethod GEDL provides for communication is the ability to declare external components of the editor. These external components can execute concurrently w ith the rest of the editor and communicate through delta inform ation. This gives considerable flexibility to the im plem entation of domain-specific components. Now th a t I have presented an overview of GEDL editors and the constructs which are used to specify them , I will now present these constructs in detail. 83 4 .2 E d ito r An editor specification is prim arily a composition of data, abstraction, view and com m and specifications. Its main contribution is the specification of additional editor state attributes. A set of attributes of the state of an editing session are built-in, e.g., w hether the graph has been modified. A dditional domain specific states can be specified in the editor specification as attributes of the editor. Furtherm ore, the display of this state inform ation in a state bar can be specified. <EDIT0R> ::= e d it o r <ID> i s [ <0PTI0N>* ] [ <ATTRIBUTE>* ] <DATA DEFINITION <ABSTRACTION DEFINITION> <GRAPHIC DEFINITION> <OPERATION DEFINITION <STATE BAR DEFINITION> end e d ito r <ID> ; The editor specification also contains options for pre-defined attributes of the editor including whether updates are propagated incrementally or all at once, the kind of commu nication th a t should be built-in to the system and w hat debugging features are available to the user. In particular, during debugging of a graph editor, the editor specifier can open a specialized editor which visualizes and edits constraint graphs. The constraint graph editor/debugger is described in more detail in C hapter 8. <0PTI0N> ::= o p tio n se r v e r <STRING C0NST> 5; ’ I o p tio n c l i e n t <STRING C0NST> ’ ; ’ I o p tio n cdebug <STRING C0NST> J; 5 I o p tio n in crem en ta l on 5;* I o p tio n in crem en ta l o f f ’ ; ’ For example, the options found in the task-dependence graph editor and the constraint graph editor are: 84 e d it o r C onstraintG raphE ditor i s o p tio n s e r v e r " C onstraint" ; e d it o r TaskDependenceGraphEditor i s o p tio n cdebug "C onstraint" ; o p tio n in crem en ta l on; These options establish th a t the constraint graph editor will listen to connections for “C onstraint” , and th a t the task-dependence editor will attem pt to find the constraint debugger at th a t address. The task-dependence editor also specifies th at increm ental updates should be used where possible. The im pact of this option will be described later. A ttributes associated with editor components contain values for each instance of the component type. The editor attributes are no exception. In the editor, attributes are global values associated with the entire editor. Thus, they act like state inform ation L 4 .3 D a ta This section describes the m eta-model provided in the GEDL language. As described in C hapter 3, the m eta-model m ust be capable of describing the domain d ata model which includes vertex and edge types, and connectivity rules. In GEDL, the combination of vertex, edge and graph specifications form a domain d ata model. D ata definition in GEDL consists of the specification of various vertex and edge types and a graph type definition. Vertex and edge type definitions are available to all other 1 In th e G EDL im plem entation discussed in this dissertation, im plem entation of editor attributes are kept in a specialization of the S ta te class. 85 components of the editor specification, i.e., abstractions, views and operations. For this reason, they are defined at the top-level rather than as part of the graph definition. <DATA_DEFN> ::= <VERTEX_DEFN>* <EDGE_DEFN>* <GRAPH_DEFN> 4 .3 .1 V e r t e x a n d E d g e D e f in it io n s Vertex and edge definitions introduce a new kind of Element with a set of associated attributes. The pre-defined type Element serves as the parent type of all vertex, edge and graphic types. <VERTEX> ::= v e r te x <ID> [ i s a <ID> ] IS [ <PERSISTENCE> ] [ a t t r ib u t e s [ e d ita b le ’ : ’ <ATTRIBUTE_DECL>* ] [ p r iv a te ’ : ’ <ATTRIBUTE.DECL > * ] end a t t r ib u t e s ’ ; ’ ] <EDGE> edge <ID> [ i s a <ID> ] IS [ <PERSISTENCE> ] [ a t t r ib u t e s [ e d ita b le ’ : ’ <ATTRIBUTE_DECL>* ] [ p r iv a te ’ : ’ <ATTRIBUTE_DECL>* ] end a t t r ib u t e s ’ ; ’ ] end edge <ID> * ; ’ For example, a Task vertex type would be declared as follows: v e rte x Task i s sav e a b le e d ita b le : Name : s t r i n g ; D u ratio n : i n t ; p r i v a t e : C r i t i c a l : b o o l; I EndDate : i n t ; 'en d v e rte x Task; The new element type introduced by an edge or vertex definition is either a direct descendant of the V ertex or Edge type or it is a specialization of an existing type through the i s a construct. Inheritance in this case implies th a t the attributes of base types are inherited. The hierarchy of element types was not originally p art of the GEDL design. However, it was found th at reuse of GEDL specifications was much easier using the hier archy. For example, if critical path analysis is available over all vertices of type Task, then future GEDL editors can utilize critical path analysis by making their vertices a subclass of Task. Furtherm ore, specification of functions became easier with less redundancy. Finally, the specification of connectivity semantics is much easier with the hierarchy. For these reasons, it was added to the GEDL design. The definition of an edge only specifies the associated attributes, but does not specify the kinds of vertices it will connect. The connectivity semantics are described in the graph specification. This implies th at separate components of the graph editor, e.g., abstractions, might apply different connectivity semantics to the element types. The specification of a vertex or edge also gives its persistence. The persistence tells whether the vertex and edge type will be stored when the graph is saved. Generated edge and vertices are generally not made persistent. For example, in the task-dependence editor, im plicit successors between composite tasks are not persistent because they are 87 generated. The default persistence is volatile which indicates they are not saved. <PERSISTENCE> p e r s is t e n t I sa v ea b le I v o l a t i l e l A ttributes are the d ata associated with the type. A ttributes can either be e d it a b le or 1 p r iv a te . The editable attributes will be directly editable through a pop-up edit window. For example, in the task-dependence graph the name and duration of a task would be editable, but its end attrib u te should be private. It is made private because it is calculated i autom atically as part of the update of the critical path. Thus, when the user applies an edit action to a task, the editor will provide a view of all attributes, but only the editable attributes can be modified directly by the user, see Figure 4.3. The private attributes • are not directly changed by the user, but rather can only be affected by internal editor functions. 4 .3 .2 A t t r ib u t e D e f in it io n s A ttributes are used to associate d ata with elements such as vertices, edges and graphics, as well as GEDL components, such as graphs, abstractions and views. The scope of attrib u te names extends from their declaration to the end of the editor specification. The attrib u te names are the same as field names in record types. <ATTRIBUTE_DECL> ::= <ID> <TYPE> Because the edit tool only acts on the underlying graph data, it only makes sense to talk about attributes being editable and private for the elements which make up the graph data. Thus, the concept of editable and private, and the related reserved words, are only v e r te x Task i s sa v e a b le e d i t a b l e : Name : s t r in g ; D uration : in t ; p r iv a t e : C r it ic a l : b o o l; EndDate : in t ; end v e r te x Task; EndDate: i q IE I Critical Duration: m Name: Reqs Cancel Figure 4.3: A ttribute Specification Example applicable to attributes of vertices and edges, and then axe only really meaningful for the; vertices and edges of the graph itself. A ttributes are accessible to operations through get and set functions and their associ- ! ated constructs. Each attribute declaration introduces two new functions, Get<name> and I Set<name>, where <name> is the name of the attribute. For example, a function could include code which accessed a Task vertex as follows: T a s k ln s t. S etD u ra tio n (1 0 + T a sk In st.G etD u ra tio n Q ) 4 .3 .3 G r a p h D e f in it io n A graph definition consists of a specification of the rules governing connections between edges and vertices, a set of attributes of the graph and a set of functions which are re sponsible for responding to deltas. <GRAPH> ::= e x te r n a l graph <ID> I graph <ID> [ is a <ID> ] i s <CONNECTIVITY> [ a t t r ib u t e s <ATTRIBUTE_DECL> * end a t t r ib u t e s ’ ; ’ ] <FUNCTION_DECLARATION>* end graph <ID> ’ ; ’ For example, the beginning of the declaration of the task-dependence graph is as fol lows: graph TaskDependenceGraph i s c o n n e c t iv it y i s l o c a l r u l e s : S u ccesso r : Task -> Task : 1; 90 I m p lic itS u c c e s so r : Com positeTask -> CompositeTask : 1; C h ild : Com positeTask -> Task I Com positeTask : 1; g lo b a l r u l e s : dag : Task , S u ccesso r; dag : Com positeTask , Im p lic itS u c c e sso r ; t r e e : Com positeTask I Task , C hild; end c o n n e c tiv ity ; a t t r ib u t e s EndDate : i n t ; end a t t r ib u t e s ; The reserved word e x te r n a l is used in association with communication with external entities and will be discussed in Section 6.1. A graph type can inherit the attributes, connectivity semantics and functions of a another graph type through the i s a clause. This supports reuse by allowing the inheritance and specialization of existing graph types. The rem aining parts of the graph specification will be discussed in the following sec tions. 4 .3 .3 .1 C o n n e c tiv ity S p e c ific a tio n The connectivity semantics is a set of rules which enforce characteristics of the graph which can be created by the user. This is directly related to the problem of defining syntax checking operations as described in Section 3.1. <CONNECTIVTTY> ::= c o n n e c tiv ity i s lo c a l r u le s *:> <EDGE_COW NECT_RULE>* g lo b a l r u le s ’ :» <GLOBAL_CONNECT_RULE>* end c o n n e c tiv ity *;* In GEDL, two kinds of rules can be specified, namely local and global. A local rule 91 is associated w ith a set of edge types and specifies the kinds of vertices it can connect and how m any edges can exist between any two instances and still satisfy the rule, i.e., a cardinality constraint. W hen an add edge delta is applied to a graph, the new edge is checked against each of the local rules until it satisfies a rule. If it does not satisfy any rules, then the AddEdge delta will be rejected. Most likely, this will result in the entire transaction failing. The only modifications th a t need to be checked against the local rules are edge additions. Global rules however require checking the graph resulting from a transaction as described below. The syntax for of a local rule is: <EDGE_CONNECT_RULE> ::= <ELEMENT_LIST> ’ <ELEMENT_LIST> <ELEMENT_LIST> <CARD> <CARD> ::= I 1 <ELEMENT_LIST> ::= ’*» I <ID> { ’I’ <ID> }* where the rule implies th at an edge of one of those types can begin at an instance of any of the vertex types in 1 and can end at an instance of any of the vertex types in 2 assuming th a t it also satisfies the cardinality restriction. The list of “ I” separated identifiers implies th a t any of the types can be used in th at slot. The cardinality specification restricts the number of edges of th a t type which can exist between any two instances and still satisfy the rule. A “ i ” cardinality implies zero or one edge. A cardinality implies zero or more edges. A global rule further restricts the allowable graphs by giving restrictions on the form of the graph as a whole. These restrictions cannot be determined by considering only new 92 edges. Instead the entire graph m ust be considered. For this reason, the global rules are verified only at the completion of a transaction. Checking the result of an entire transaction also allows for the combination of adding vertices and edges to be treated as an atomic ' < operation so th a t connectivity rules can be enforced over a set of deltas. If a graph which j results from a transaction violates any global rule, then the transaction is rejected. This implies th a t at the end of all deltas th at are p art of a transaction, the connectivity rules ■ of the graph (global and local) will be true. The combination of the transaction model and the connectivity semantics allow for the expression of connectedness requirements. For example, a graph editing application might require th at all vertices be connected to the graph through some edge type. The operation th a t adds this kind of vertex consists of creating a vertex first and then creating the edge. If the transaction is treated atomically, then the update can be viewed as atom ic and thus ' it is allowed by the connectivity semantics. If the operation is non-atomic, then the add vertex would fail because the new vertex is not connected. <GLQBAL_CONNECT_RULE> ::= <GLOBAL_TYPE> » : J <ELEMENT_LIST> *,» <ELEMENT_LIST> »;» <GLOBAL.TYPE> ::= D A G I TREE I C O N N EC TED The basic meaning of a global rule is th at the edge types in the first o r l i s t m ust not create a cycle, violate the tree property or result in a disconnected graph when considering the vertex types in the second o r l i s t . Note th at in the case of local rules, only a single rule m ust be satisfied, where in the case of global rules, all rules m ust be satisfied. As an example of connectivity semantics, consider the connectivity rules and the 93 C h ild : Com positeTask -> Task I Com positeTask : 1 ; Succ : Task -> Task : 1 ; Im p lic itS u c c : Com positeTask -> Com positeTask : 1 ; D A G : Succ : Task ; T ree : C h ild : Com positeTask | Task ; D A G : Im p lic itS u c c : Com positeTask ; Req Des J Cod Tes Mnt 5 11 H I S 23 28 Figure 4.4: Connectivity Specification Example graph shown in Figure 4.4. In this example, we have three edge types, C h ild , Succ, and Im p lic itS u c c , and two vertex types, Com posite and Task. The current graph is legal according to the connectivity rules. Note th a t implicit successors are shown w ith the dotted line, child links head from composite tasks to the child task, and successor links are in between the tasks. As an example of the enforcement of rules, I will consider a few possible changes. If we attem pt to add another successor edge from Req to D esign, this satisfies the type requirem ents associated with Succ, but it will fail because of the cardinality constraint of 1. Adding a successor from Req to the composite task Mnt will fail because it does not satisfy the type requirements associated with Succ. If we add a Succ from Cod to Req, then we will have introduced a cycle. This will fail due to the requirem ent th at the graph be a directed acyclic graph over successors and tasks. If we had added th a t edge in the other direction, then we will have satisfied a local rule and will have satisfied all of the Dev Mnt global rules. Thus, this addition would be allowed. W hile the set of rules expressible by the connectivity semantics is lim ited, typical connectivity semantics are easily expressed using these rules. Furtherm ore, if more complex semantics are required, the user can embed those semantics as p art of the graph functions as discussed in the next section. 4 .3 .3 .2 G ra p h F u n ctio n s The graph functions provide semantics for the graph beyond it simply being a collection of vertices and edges following a specific set of connectivity semantics. The m ethod used to control the graph is to properly update the set of vertex and edge instances in response to deltas. In GEDL, these deltas are handled by a small and simple set of delta functions (see Section 4.1). Each of these functions has a default meaning which is assumed if no specification is given. Thus, the function declarations of the graph would include these functions or would inherit the operations from its parent graph type. An actual definition of a graph will likely use default values for most of these functions. The default value is “make an appropriate change to the the graph data.” These changes result in propagation of the change to the next component in the view tree, as shown in Figure 4.2. The expressions which implement these functions can utilize a variety of graph m anip ulation functions. These functions are described in Appendix A. One of the key design decisions in GEDL was to keep the deltas and the delta functions small. Using the classification in [15], we provide only ’’basic” updates. However, ’’ele m entary” updates which enforce the context-sensitive syntax of the graph language can 95 be obtained through composition of the basic updates in operations using transactions. 4 .4 A b str a c tio n A bstraction is the ability to hide irrelevant detail from the user. O ther researchers sup port abstraction by providing pre-defined ways of hiding certain inform ation. For example, ED G E [44] provides composition abstraction and edge concentration abstraction (see Sec tion 2.3.2). However, for many domain-specific graph editors, a specific inform ation hiding technique will not be able to handle domain-specific requirements. For example, in a task- dependence graph, a composite vertex should have a duration of the sum of the length of its critical p ath vertices. In GEDL, I have taken a more general approach to the problem of abstraction by viewing abstraction as a transform ation which occurs in the d ata domain. In the GEDL language, an abstraction definition describes a type of abstraction which is instantiable within operations. An abstraction m ust have the ability to be created and respond to deltas in the graph. This leads to basically the same definition as the graph. However, the abstraction will have a very different role in a graph editor. Namely, it will attem pt to restrict propagation of certain vertices and edges (or even ju st transform them ) such th at the graph produced by the delta functions of the abstraction is the graph of interest to the user. <ABSTRACTION> ::= e x te r n a l a b s tr a c tio n <ID> I a b s tr a c tio n <ID> [ i s a <ID> ] i s <CONWECTIVITY> [ a t t r ib u t e s <ATTRIBUTE_DECL>* end a t t r ib u t e s ’; ’ ] <FUNCTION_DECLARATION>* end a b str a c tio n <ID> ’ ; ’ For example, the task-dependence graph editor describes a composition abstraction which allows the user to hide all vertices which are sub-tasks of a composite task. This , definition looks similar to the graph definition, but its functions include Hide and Expose. Its definition is: a b s tr a c tio n C om p osition A b straction i s — c o n n e c t iv it y i s same as u n d erly in g graph c o n n e c tiv ity i s lo c a l r u le s : S u ccesso r : Task -> Task : one; I m p lic itS u c c e s s o r : Com positeTask -> Com positeTask : one; C h ild : Com positeTask -> Task I Com positeTask : one; g lo b a l r u l e s : dag : Task , S u ccesso r; dag : Com positeTask , Im p lic itS u c c e sso r ; t r e e : Com positeTask | Task , C hild; end c o n n e c tiv ity ; — Expose s e t s th e a t t r ib u t e o f th e com p osite ta s k to — non -hidd en and ex p o ses one l e v e l o f c h ild r e n , fu n v o id Expose(C : Com positeTask) = i f (g e t C.Hidden == TRUE) th en An abstraction is placed in the view tree when it is created by an operation. Once it is a member of the view tree, it will receive propagated changes whenever a transaction is com m itted in the immediately previous member in the viewing chain. An abstraction can also be called directly by operations (generally to change the attributes which determ ine how the transform ation will operate). Each abstraction owns its set of vertices and edges. These vertices and edges will generally have a one-to-one association with elements in the graph which it abstracts. 97 This is modeled through association links as shown in Figure 4.5. Each element will have an A ssociatedW ith link which points to the elem ent(s) in the ■ previous component to which it corresponds. It also has an Assoc link which points to the elem ent(s) th at are A ssociatedW ith it. These links can be m anipulated in the same ! m anner th at edges are m anipulated in any kind of graph. Typically, they are used in order to handle propagation within a particular component. These links will become im portant 1 I when we look at the creation of abstractions and views in C hapter 8. i 4 .5 S u m m a ry 1 In this chapter, I have presented an overview of the GEDL language constructs for de scribing the d ata domain. These constructs dem onstrate my approach to the problems of d a ta definition and abstraction definition. D ata definition is addressed by allowing the user to specify a hierarchy of vertex, edge and graph types. This is a pretty standard solution. However, the solution to defining legal graphs is unique. I have taken a hybrid approach by providing a language for expressing syntax-checking rules and defining exact points when they will be applied. However, flexibility is achieved through the use of transactions to delay the final check. In this way, operations can combine a set of deltas to form a single, syntacticaily-correct transform ation. A bstraction obviously takes the transform ation approach th a t I have introduced in this dissertation. The key to this solution is establishing the separation of the issue of abstraction from the issue of visualization and at the same time m aintaining the proper associations. Since propagation and association are directly supported by the architecture 98 Vertex-1 Vertex-2 Graph Vertex-1 Edge-1 Vertex-2 Abstraction-1 Line-1 Line-2 Box-3 Box-1 Box-2 View-2 Box-1 Line-1 Box-2 View-1 Vertex-1 Box-1 Abstraction-2 View-3 Figure 4.5: Element Association 99 of GEDL editors, the burden of m aintaining associations is greatly reduced in this solution. Overall, this solution gives greater flexibility and allows experim entation w ith various forms of abstraction. 100 C h a p te r 5 G E D L : V ie w s an d O p era tio n s This chapter presents the visualization and operations constructs in GEDL. Together, these constructs are used to create the user’s view of the graph editor. 5.1 V ie w s View definition combines an association of graphic objects with d ata objects, the definition of how they are composed into separate pictures (if at all) and how a separate picture is laid out for visualization. In GEDL, visualization is supported through the definition of three kinds of classes, namely views, composite graphics and graphics. The entire graphics definition is: <GRAPHICS_DEFN> ::= <GRAPHIC>* <COMPOSITE_GRAPHIC>* <VIEW>* A graphic is a simple graphical component such as a box, line, or a composite graphic. A composite graphic is responsible for a particular set of graphics including simple graphics and other composite graphics forming a tree of graphic images. A view is responsible for handling propagation of changes from the graph (or abstraction) and assigning the delta 101 ; to be handled by one or more composite graphics. We will examine each of these classes in the following sections. 5 .1 .1 B o x a n d L in e G r a p h ic s The visualization of a graph is created through the composition of a series of box and line ■ graphics. A box graphic is a box containing graphic items. A line graphic connects two boxgraphics and has a midpoint which is itself a box graphic. The syntax for defining box ’ and line graphics is: <GRAPHIC> ::= lin e g r a p h ic <ID> [ is a <ID> ] i s [ a t t r ib u t e s <ATTRIBUTE_DECL>* end a t t r ib u t e s ’ ; 5 ] <LINE_L00K>* end lin e g r a p h ic <ID> ’ ;* I boxgrap h ic <ID> [ is a <ID> ] i s [ a t t r ib u t e s <ATTRIBUTE_DECL>* end a t t r ib u t e s ’ ;’ 1 <B0X_L00K>* end boxgraphic <ID> ’ ; ’ The heart of this definition is the description of the looks associated w ith each graphic type. An instance of a graphic type will generally be associated w ith a particular instance of an element type. As the element type is modified through changes to the graph data, the associated graphic type may change its look. For example, a task visualization may use thicker lines when its associated task vertex is critical. The syntax for describing looks 102 <BOX_LOOK> ::= lo o k <ID> IS <B0X> end lo o k <ID> »;> <LINE_L00K> ::= lo o k <ID> IS <LINE> [ <B0X> ] end lo o k <ID> ’ Note th a t a single box or line graphic can have a list of these looks. The default (initial) look is the first look th a t is specified. The look of a graphic can be changed by setting the value of its look attribute. M ultiple looks are used in the task-dependence graph editor to describe the visualiza tion of critical and non-critical task boxes. This specification is: b oxgrap h ic TaskBox i s a BaseG raphic i s a t t r ib u t e s TaskName : s tr in g ; EndDate : in t ; end a t t r ib u t e s ; lo o k T askW onC ritical i s hbox t e x t a t t r ib u t e TaskName; t e x t a t t r ib u t e EndDate; end hbox end lo o k T ask N on C ritical; lo o k T a s k C r itic a l i s b order brush s o l i d 3; c o lo r red ; - - b o ld /r e d l i n e hbox t e x t a t t r ib u t e TaskName; t e x t a t t r ib u t e EndDate; end hbox end lo o k T a sk C r itic a l; end boxgrap h ic TaskBox; The non-critical look uses the default border, which is black with a w idth of one. The critical look uses a border th a t is red with a width of three. Thus, critical vertices will be highlighted in the visualization. A box graphical item , <B0X>, consists of a border specification and a list of box ele m ents. The syntax of th at specification is: hbox end hbox hbox border brush width 5; ' end hbox □ hbox border pattern light-gray; end hbox hbox border brush dashed 1; end hbox hbox border pattern gray ; end hbox Figure 5.1: Examples of Border Styles <B0X> ::= hbox [ <B0RDER> ] <BOX_ELEMENT>* end hbox I vbox [ <B0RDER> ] <BOX_ELEMENT>* end vbox The border specification describes how the box will be outlined and filled. Its syntax is: <B0RDER> ::= border [ <PATTERN> ] [ <BRUSH> ] [ c o lo r <CQ LO R> ] <PATTERN> ::= c le a r I gray I b la ck <BRUSH> ::= brush <LINESTYLE> <EXP> ’ ; J <LINESTYLE> ::= s o l i d I dashed I d o tte d <C0L0R> ::= b la ck I b lu e | g reen I red I cyan Box elements are entities such a boxes, lines, text, bitm aps, circles, etc. Associated with these objects are inform ation such as line thickness, fill pattern, color, etc. The syntax of these specifications is: <BOX_ELEMENT> ::= <TEXT> I <BITMAP> I <SPACE> I <LINE> I <B0X> <TEXT> ::= t e x t <TEXT_STYLE> <TEXT_VALUE> ’ <TEXT_STYLE> ::= normal I b o ld I u n d e r lin e I grayed I in v e r te d m agenta I y e llo w I <C0NSTANT> Figure 5.1 shows some examples of borders and fill patterns th at can be used. The second p art of the specification of a box graphical item is the list of box elements. 104 hbox text bold "asdf' end hbox hbox space 5; line brush solid 2; end hbox <TEXT_VALUE> : ' <BITMAP> ::= b <SPACE> ::= sp Examples of boxes created using GEDL are shown in Figure 5.2. Note th at both horizontal 1 and vertical composition of box elements is possible. Furtherm ore, composition of box elements themselves is possible. This approach allows a small and relatively simple set of i » graphic items to be combined to form very complex graphics. The specification of line graphical items is considerably simpler. Their syntax is: <LINE> ::= l i n e <BRUSH> [ c o lo r <C0L0R> ] [ arrow head ] Note th a t the use of line graphical items is only part of the line graphic specification. The line graphic specification also contains a box graphic item used as its center point and as a means of labeling a line. As an example of a line specification, consider the following defined in the constraint graph editor: lin e g r a p h ic RangeLine i s lo o k Normal i s 105 asdf hbox border brush solid 0; bitmap "center.bmp"; end hbox hbox text "asdf; line brush solid 3; text ''asdf'; end hbox asdf asdf Figure 5.2: Examples of Boxes := a t t r ib u t e <ID> I <C0NSTANT> hbox hbox text ''asdf'; line; text ''asdf'; end hbox hbox text “asdf'; line; text ’ 'asdf’; end hbox end hbox asdf asdf asdf asdf itm ap <ID> ’ ; ’ ace <C0NSTANT> 5; 5 l i n e brush s o lid 1; c o lo r b la ck ; arrowhead hbox t e x t "r"; end hbox end lo o k Normal; end lin e g r a p h ic RangeLine; In this case, there is only one look. This look consists of a black line connecting two vertices. It will have a label of “r” near its m idpoint. 5 .1 .2 C o m p o s it e G r a p h ic s A composite graphic handles the visualization of a set of graphics. It m ust respond to new graphic objects, changes to underlying graph data associated with graphic objects it controls, and deletion of graphic objects. The syntax for specifying a composite graphic is: <COMPDSITE_GRAPHIC> ::= com posite g ra p h ic <ID> [ i s a <ID> ] i s C a t t r ib u t e s <ATTRIBUTE_DECL>* end a t t r ib u t e s ’ ; ’ D <FUNCTION_DECLARATION>* end com p osite g rap h ic C IO ’ ;' The syntax of a composite graphic is similar both to components as well as elements. It contains characteristics of both kinds. It m ust respond to deltas in associated components like other component types. However, it m ust also be p art of a visualization like other graphic elements. Because composite graphics are not directly members of the view tree, we treat them as elements. However, propagation of deltas is handled by views and composites such th a t they are also treated as components in many ways. 106 Each composite graphic has a position in the visualization, and all of its graphic mem bers (including other composites) are positioned relative to base position of the composite graphic. Thus, the composite graphics form a tree of independent sets of positioning con straints so th a t changes to the graph, abstractions and graphical d ata will affect only a lim ited part of the entire set of constraints. This supports a variety of capabilities including, independent sets of constraints for faster constraint solution and multiple layout algorithms within a single visualization. These capabilities will be discussed in Sections 7.2 and 8.5 respectively. Overall, the biggest role of a composite graphic is to control the positioning of its members. In GEDL this is achieved through the creation and m anipulation of layout constraints. Constructs for m anipulating constraints are described in the next section. 5 .1 .3 C o n s t r a in t s As was noted in C hapter 3, there are two basic ways which other researchers have pro posed as a means of integrating alternative sources of positioning inform ation. [46] and [57] suggest th a t general layout algorithms should be developed which accept graph data, con straints and aesthetic criteria and integrate this information with the base layout in order to produce position inform ation. [44] suggests th a t each of these sources produce com pet ing and prioritized requests in terms of a single constraint language. A constraint manager is then used to decide how these constraints should be satisfied in order to generate posi tions. In GEDL, I decided to take the second approach in order to foster experim entation in layout. 107 Taking the second approach leads to the problem of developing a constraint m anager which can generate positions for graphical objects based on a prioritized list of constraints. The solution of positioning constraints that is used in GEDL is described in Section 7.2. A nother problem th at is raised by providing a constraint language as the basis of positioning is th at of building layout algorithms based on the constraints. Most layout algorithm s are w ritten such th a t the output of the algorithm is a specific position for each graphical element. In a constraint based solution, the positioning inform ation generated by all layout sources (layout algorithm, application and user) are specified as a set of constraints and solving these constraints generates the positions for the graphical elements. Thus, an additional level of abstraction is provided by the constraints. This abstraction m ust be used as the basis of writing layout algorithms as described in Section 8.5. In this section, I present the kinds of constraints th at can be specified and how the GEDL language supports m anipulation of those constraints. The underlying representation of constraint information is as a constraint graph. This is a pre-defined specialization of the graph type th at uses pre-defined vertex and edge types to represent all constraint information. The types which form the basis of the constraint graph (shown in their relative position in the GEDL class hierarchy) are: O bject Component Graph C onstraintM anager Elem ent V ertex G C onstraintV ertex G B oxGr aph i cV e r t ex GDim ensionedVertex GCent erV e r t ex GRangeVertex Edge G C onstraintEdge GRangeEdge GBeforeEdge GCenterEdge GEqualEdge GNeighborEdge ! GMarginEdge Instances of the C onstraintM anager class are constraint graphs associated with par ticular composite graphics. The constraint graph will govern positions of the GraphicBox .instances th a t are p art of the composite graphic. ; Composite graphics can treat the constraint graph the same as any other kind of graph and apply standard m anipulation functions. Thus, knowledge of graph m anipulations in GEDL will also apply to constraint graph m anipulation. In addition, the composite graphic can m anipulate the graph through GEDL constructs which are design to make some constraint graph m anipulations significantly easier. These constructs are: <CQNSTRAINT_OP> ::= add c o n s tr a in t <DIM> <EXP> <CONSTRAINT_TYP> <EXP> ’ ,» <EXP> [ 5,» <EXP> ] I d e le t e c o n s tr a in t <EXP> I d e le t e c o n s tr a in t [ <CONSTRAINT_TYP> ] <EXP> , <EXP> <CONSTRAINT_TYPE> ::= b e fo r e I c e n te r I n eigh b or I equal I le ftm a r g in I rig h tm a rg in I range <DIMENSION> ::= x I y The add constraint operation accepts a dimension, a priority, a constraint type, and either two box graphics or two constraint vertices. The optional expression is used in range constraints where the first expression is a box graphic or constraint vertex and the second and third expressions are the starting and stoping points of the range. 109 The delete constraint operation accepts either a particular constraint edge or two box graphics and a constraint type. In the case of a single constraint edge, th at edge is remove from the constraint graph. If th at edge is a center, m argin or range edge, then the associated constraint vertex may be deleted (if it is now disconnected). The delete ! constraint operation with two box graphics will delete all constraints1 between those box graphics which satisfy the constraint type restriction. The kinds of constraints th at can be used are: • Before A before constraint says th at the first box graphic m ust be before the second box graphic. Depending on the dimension, this can either be left (x) or above (y). • Equal An equal constraint says th a t the two box graphics should be placed at the same point in the dimension. • Neighbor A neighbor constraint says th at the two box graphics should be placed next to each other, but not overlapping. This can be thought of as a before constraint which goes in either direction. • Center A center constraint exists between a set of vertices. All of the input vertices positions are used as the basis for centering all of the output vertices. A center vertex is used 1T h e delete operation will only delete im m ediate constraints. Thus, deleting a before constraint betw een two box graphics does not guarantee that an indirect before constraint does not still exist. to collect the input to output relationship. • Range A range constraint fixes a box graphic’ s position to some area of the dimension. • Left and Right Margin Margin constraints position box graphics to be fixed on the left or right margin. The effect of the above constraints can be better understood through recognition of the two basic types of constraints, namely relative and absolute. Relative positioning constraints (before, equal, neighbor, center) state a relationship between box graphics th a t should hold no m atter where they appear. Absolute positioning constraints (range, left m argin and right m argin) fix a box graphic to a particular place in the dim ension irregardless of any other positioning requirements. C onstraints are given priorities in order to resolve conflicts between contradictory con straints. For example, if two box graphics are related by before constraints in both di rections, then either of the before constraints may be satisfiable, but certainly not both. Therefore, the constraint with the higher priority will be given precedence and the other constraint will be ignored. If the priority of the two constraints are equal, then an arbitrary decision will be m ade as to which constraint will be satisfied2. If m anipulations of the constraints are needed beyond adding and removing constraints (such as queries), the constraint graph itself must be m anipulated. The representation of the constraint graph will be further discussed in Section 7.2. For now, I will simply say th at each box graphic in the composite graphic will have a corresponding GBoxGraphicVertex 2Older constraints are prefered over newer constraints in order to im prove stability 111 O peration Dim Pri Cons Boxl Box2 Pos add constraint y 4 before 0 1 add constraint y 3 before 1 2 add constraint y 2 before 2 0 add constraint y 1 center 8 0 add constraint y 1 center 7 0 add constraint y 1 center 6 0 add constraint y 2 before 6 7 add constraint y 2 before 7 8 add constraint y 5 range 6 100 add constraint y 5 range 7 200 AT GT AT GT GT (d) Low Level Y View (a) U se r View (b) High Level Y View Figure 5.3: A Constraint Graph Example (Y-Dimension Only) in the constraint graph. Before, equal and neighbor constraints are represented as edges between GBoxGraphicVertex instances. Range, margin and center vertices are used to represent those constraints and corresponding edges are used to represent the relationship to box graphics. A small constraint graph and how it was generated through GEDL commands is shown in Figure 5.3. In order to support more efficient positioning and multiple layout algorithm s, we have designed GEDL to support the creation of sets of constraints which can be solved inde pendently. This is done by associating a separate set of constraints with each composite graphic. In response to changes in its graphics, a composite will generate a series of changes to the constraints which ultim ately govern the positions of its graphics. The 112 positions which, the constraint manager generates are relative to the positioning of the composite. Thus, the composite graphics form a tree of independent sets of positioning constraints ; so th a t changes to the graph, abstractions and graphical d ata will affect only a lim ited p art of the entire set of constraints. Actually the changes might affect the positions of every graphic, but a limited set of relative positions would be calculated. The use of composite graphics to control the layout of it’s children graphics also sup ports separate layout algorithms for separate parts of the graph. For example, in an organization chart we might want to have certain types of organizational units displayed horizontally and other parts vertically. This can be achieved by defining two different types of composite graphics, each with a separate approach to constraining its children. The use of multiple layout algorithms is dem onstrated in Section 8.5. 5 .1 .4 V ie w s In addition to the definition of graphic object types, the view definition also includes the definition of how the view will be created and how it will respond to changes to the data which it is viewing. A view’s most im portant role is governing how changes to the graph d a ta will affect the composite graphics. Associated with each view is a tree of graphics starting with a particular type of composite graphic. Thus, the definition of a view is the definition of graphic object types, and the definition of a set of functions to deal w ith creation of the view and how it responds to changes to the d ata which it is viewing. Its syntax is: <VIEW> ::= e x te r n a l view <ID> I view <ID> [ i s a <ID> ] i s g rap h ic <ID> ’ ; ’ 113 [ a t t r ib u t e s <ATTRIBUTE_DECL>* end a t t r ib u t e s ’ ; ’ ] <FUNCTION_DECLARATION>* end view <ID> * ; ’ An example of a view definition is: view HighLevelXView i s g ra p h ic H ighL evelC om posite; fu n v o id I n it O = l e t R : Com posite = G etR ootO ; in s e t R as H ighL evelC om posite.D im to XConst end s e t end l e t end fu n I n it ; end view HighLevelXView; This view is associated with the composite graphic type H ighLevelC om posite. The I n i t function is defined to initialize values associated with the composite. The I n i t function is autom atically invoked when the view is created as part of an operation. In other words, if the editor contains an operation for adding a view, then the operation will include code which instantiates the view and adds it to the view tree. As p art of instantiating it, the I n i t function will be called. Like abstraction, views are based on propagation of deltas. In this case, the abstractions (or graph) will make a set of changes through their delta functions, and the view will have those changes propagated to the appropriate delta functions. The view will respond to changes to the d ata objects with a set of calls to delta functions in the composite graphics. The default is to call the delta function associated with the root composite graphic, and 114 generally this is sufficient. In these cases, the body of the view function is trivial, as dem onstrated in both example graph editors in the Appendixes. The view definition also contains a specification of the graphic type th a t is the root ■ composite for the view. This m ust be done so th at the initial composite can be auto- j m atically instantiated as part of creating a view. Also included in instantiating a view is . creating a window for its output and inserting it into the view tree. 5.2 O p era tio n s All changes to the state of the graph editor are originated through the invocation of operations or through external entities. Operations are available through the user-interface and may include various interactions w ith the visualization. The use of external entities to control state change is discussed in Section 6.1. In GEDL, the definition of <OPERATTQNSJDEFN> consists of defining a set of attributes and functions which are available to all operations, a set of commands and tools (<0PERATI0N>), and a set of menus which provide the interface to the commands. The syntax of this defi nition is: <QPERATIOMS_DEFM> ::= o p e r a tio n s [ a t t r ib u t e s < ATTRIBUTE _ DEC L > * end a t t r ib u t e s ’ ;* ] <FUNCTIDN_DECLARATION>* <0PERATI0N>* <M ENU>* end o p e r a tio n s ’ ; ’ 115 5 .2 .1 T o o ls a n d C o m m a n d s i i An operation is either a tool or a command. A tool uses direct m anipulation [53] of the graphical depiction to dem onstrate a desired change. A command is a menu selectable operation. The syntax of operation definition is: <0PERATI0N> ::= command <ID> [ is a <ID> ] i s <FUNCTIOM_DECLARATIDM>* end command C IO ’ ; ’ I t o o l < IO [ i s a C IO ] i s CBITMAP> : <FUNCTION_DECLARATION>* 1 end t o o l C IO ’ ; * i In and of itself, the syntax of commands and tools are not very revealing. The im por tan t element left out of the syntax is th at the functions P r e c o n d itio n and E xecu te can !be defined to give the functionality of the operation. The P r e c o n d itio n function is called when an operation is invoked to check whether the operation is available. If it returns true, then E xecute is called. The E xecute function contains the code which causes changes to the state of the editor. For example, consider the following operation th a t is part of the constraint graph editor specification: command AddUserView i s fu n b o o l E xecute () = l e t VT : ViewTree = GetVTQ ; G : Graph = GetGraphO; V : UserView = new UserView; in VT->AddView(V,G) end l e t end fun E xecu te; end command AddUserView; W hen this command is invoked, its E xecute function is called. This function creates a 116 new view of type UserView. It this adds it to the view tree and associates it directly with the graph. All GEDL editors provide a set of pre-defined operations including file m anipulation, select, view control (zooming), cut-and-paste, etc. If a specification includes specialization of the existing operations, then the specialized definition will be used instead of the base GEDL definition. This technique provides a similar look-and-feel across domain-specific editors w ithout the loss of flexibility. 5 .2 .2 O p e r a tio n V is u a liz a t io n In order to invoke operations, the user m ust be presented a visualization of the operations. In GEDL this is done through a menu-bar and a tool-bar, see Figure 5.4. Changes to the the interface as presented to the user is m ade through the specification of (1) new tool types and (2) menus. A tool type specification includes the specification of a bitm ap which will be added to the toolbar. W hen the bitm ap is chosen (or the tool type menu is selected with th at tool) and the user clicks the left mouse button in a view, then the tool’s pre-condition is checked and if it is true, the execute function w ith its direct m anipulation functions are used to control the user’s interaction. The direct m anipulation functions, e.g., D M select, DMmove, DMedit, have a standard interaction technique. However, m ost types of direct m anipulation which are required in specific domains can be supported through the combination of these prim itive functions. For example, if we want to enforce th at every vertex is connected to the m ain graph, then a vertex add tool would include a move operation using the vertex graphic and a move operation using a line graphic. State-Bar Graph Edit - (Untitled) File Edit Tool View W indow T y p es AddView U ser View High Level X View High Level V View Low Level X View Low Level Y View UserView Menu-Bar \ New Pulldown Menu - Created w/ Following Code menu AddView "Add View" is AddUserView: "User View"; AddHighLevelXView : “High Level X View"; AddHighLevelYView : “High Level Y View"; AddLowLevelXView : "Low Level X View"; AddLowLevelYView : "Low Level Y View"; end menu AddView; Figure 5.4; Operation Visualization 118 \ V- / ■ Menu specifications actually come in two flavors. One kind of menu is a checked menu which allows the user to choose the current type of a variety of options. The tool select menu is an example of this. The other kind of menu is a command menu th at allows the user to invoke commands through a menu. The syntax of these specifications is: i <M EN U > ::= menu <ID> <C0NSTANT> [ checked ] i s <M ENU_ELEM ENT>* end menu <ID> ’ ; ’ <M ENU_ELEM ENT> ::= <ID> <C0M STANT> I <C0NSTANT> ’ :» <CDNSTANT> ' ; ' I SEPARATOR <ID> »;» Checked menus allow the user to choose between a set of constant values. Operations can find out about the current state of a checked menu by calling a function Get<ID> associated with the S ta te class. The <ID> is the identifier of the checked menu or the immediately previous separator. The first constant value is returned. The second constant value contains a string which is presented in the menu. Command menus (check is not used) contain a list of command identifiers and strings which are presented in the menu. In response to the selection of th at menu item , the com m and will be invoked. This involves checking its pre-condition and executing its execute function. The implementation of the execute functions of commands and tools generally will / include functionality th at is not found anywhere else in the editor such as view tree m a nipulation and transaction manipulation. Let’s consider each of these im portant types of capabilities. As the user edits a graph, specific abstractions and views will be created and destroyed. The operations must control these requests by manipulating the view tree. The interface 119 to the view tree is simply a special kind of graph which can be m anipulated like any other ' kind of graph data. However, the effect of changing the view tree is built-in to the GEDL j system and cannot be built using GEDL specifications themselves. | Transactions are provided as a means of combining small changes to the graph editor ■ data into larger atomic changes. Transactions are presented in Section 6.2, but it is im portant to note th at transactions are initiated by operations. Thus, it is the operations th a t begin the propagation cycle by initiating and committing a transaction over a graph editor component. 5.3 S u m m ary In this chapter, I have presented the GEDL constructs for visualization and operations. I have also presented my particular approach and partial solutions of the problems of graphic object, layout, and operation availability. Graphic object description utilize two im portant features, looks and composition. Looks represent an approach to changing state of graphics without having to tear-down and re-establish associations between the data domain and the visualization domain. Composition of graphics is done at two different levels. First, composition is used to build complex looks for individual graphic items from very simple graphic elements. Composition is also used to treat groups of complex graphic items as a single unit of visualization. This is done to support more efficient solution of constraint graphs and separate layout algorithms for different parts of the visualization. Operation availability is addressed in this dissertation through the association of a function which is basically the same as rule-based (although the form of specification is 120 different). This allows menus and tools to be controlled through both pre-condition and post-condition forms of availability control. In the next chapter, I will present the GEDL constructs for describing and associating functionality. 121 ; C h a p ter 6 G E D L : C o m m u n ica tio n , F u n ction s and E x p ressio n s This chapter presents the communication, function and expression constructs. Taken together, these constructs allow the editor specifier to associate and describe semantics of the graph editor beyond the declarative forms suggested in the previous two chapters. 6.1 C o m m u n ica tio n In order to support communication with external entities, the design of GEDL had to be extended to include two new concepts, namely external objects and external functions. In addition, the implementation of the main function of GEDL generated editors had to be constrained. In the following sections, I will present this part of the GEDL design. 6 .1 .1 E x t e r n a l F u n c tio n s One of the first extensions to GEDL is the ability to define functions as external. Thus, any of the object definitions, e.g., graph definition, abstraction definition, etc., can contain a function declaration which states th at the implementation of the function is external. The following example shows a directory tree definition based on external functions. 122 v e r te x F i le i s p r iv a te : Name : s t r in g = end v e r te x F ile ; edge I s l n i s i — no data end edge I s ln ; graph D irT ree i s a ttr ib u te s p r iv a te : RootName : s t r in g = R ootV ertex : V ertex; end a t t r ib u t e s ; — T his e x te r n a l fu n c tio n w i l l retu rn tru e a non-NULL ! — l i s t o f e n t r ie s i f Name i s a d ir e c to r y . e x te r n a l fu n l i s t o f s t r in g GetEntries(Nam e : s t r in g ) ; — R e c u r siv e ly add a su b tree to th e graph fun v o id AddRest(G : Graph; S ta rtV ertex : V ertex) = f o r a l l S : s t r in g in G e tE n tr ie s(G e tA ttr ib u te (S ta r tV e r te x , Name)) su ch th at l e t N V : V ertex = C r e a te V e r te x (F ile ); N E : Edge = C reateE d ge(In ,N V .S tartV ertex) in s e t NV.Name to S end s e t add v e r te x N V add edge N E end l e t end f o r a l l end fu n AddRest; fun b o o l C reate(G : Graph) = l e t R V : V ertex = new F ile ; in s e t RV.Name to g e t G.RootName end s e t s e t G.RootVertex to R V end s e t AddRest(G,RV) ~ TRUE end l e t end fun C reate; end graph D irT ree; 123 The interesting facet of this example is th at the external function is very simple, re- , quiring a single system call and some text manipulations. This is a good starting point for a discussion of the division between the specification of “external” in GEDL and the ^implementation of this part of the language in the GEDL translator (see Section 7.3). 1 There are two m ajor issues in the implementation of external functions. First, the external function m ust be callable by other GEDL functions in some manner. The GEDL , language specification must state what kinds of param eterization is allowed and any dif ferences between external and internal functions as far as the approach to calling them. The second issue is how an external function can interface with other parts of the GEDL editor. In other words, an external function might want to get the value of an attrib u te of a Vertex if th at vertex is passed to the external function. I The specification of external functions in GEDL is as follows: • All external functions axe callable in the same manner as any internal function. • Particular translators may restrict the kinds of param eters which can be passed to ex ternal functions, but this must include the primitive types. Thus, it is recommended th at editor specifications restrict external function interfaces to the primitive types. However, particular translators may support additional types of param eters. The implementation of different types of param eters must be explicitly defined in the translator guide. • All calls from external functions back to internal functions is dependent on the trans lator implementation. The prim ary problem for calls back to internal functions is th at they must be specific to a particular instance. External function implementa- 124 tion which only supports primitive type param eters will not be able to support calls from external functions back to internal functions since instances cannot be named. If the translator allows more sophisticated param eter types, then the translator may i optionally allow calls to functions based on the param eters. Thus, all information i about instances of interest to the external function m ust be made available to the external function through param eters. However, this can be achieved by simply passing the entire view tree which can be used through a series of calls to reach any particular instance. One of the interesting capabilities of declaring functions as external is the ability to have the propagation functions handled by external functions. However, even if all of the functions of a particular object are declared as external, the internal structures provided by GEDL are still used to store the data. In some cases, this is redundant. In the next section, we will consider a construct for removing this redundancy. 6 .1 .2 E x t e r n a l O b je c ts Often graph editors will deal with information which is stored external to the graph editor. For example, a directory browser’s graph data exists in the file system. In the example in the previous section, the entire directory tree is duplicated as internal data in the editor. Even if all of the delta functions of the graph were external, the graph object would still control a set of vertices and edges th at are internal. In order to support external objects, GEDL allows the declaration of graph, abstrac tion, composite, view, and command as e x te rn a l. The details of implementing these objects is translator dependent similar to external functions. The difference between ex 125 ternal objects and external functions is th at the representation of the data is completely hidden from the rest of the GEDL editor in external objects. Overall, external objects and external functions are highly dependent on the GEDL (translator. Thus, if portable GEDL specifications are desired, then the external entity’s responsibilities should be minimized. Otherwise, significant portions of the GEDL speci fication may have to be changed if a different translator is used. I 6 .1 .3 E x t e r n a l C o n tr o l As was mentioned previously, the two means of initiating changes to the state of the graph editor are operations and externally controlled events. The combination of external functions and external objects support some communication, but given only these two capabilities, there is no way for an external source of information to directly make changes to the editor. In order to support this capability, GEDL supports communication in the form of remote procedure calls (RPCs). This requires two kinds of constructs, connection control and message passing. Connections are based on a client-server model. One of the options you can set for a GEDL editor is a name that it intends to use from external communication. The syntax of this is: <0PTI0N> ::= o p tio n s e r v e r <C0NSTANT> I o p tio n c l ie n t <C0NSTANT> * ; 3 The constant value is the name that the server or client will use for establishing con nections. In addition to these options, the following functions are defined: v o id C onnect() v o id SetAutoServerO nQ v o id S etA utoS erverO ff() v o id G etN extC lientD ataO v o id H a n d leC lien tR eq u est(strin g ) v o id SendT oG lient() v o id SetA utoC lientO nQ v o id S etA u to C lien tO ff() v o id G etN extServerD ataO v o id H an d leS erverR eq u est(strin g) v o id SendToServerO Two modes of communication are defined, auto-call and single message. The SetA uto functions allow setting the current mode. In the auto-call mode, whenever a message is . sent from the client or server, the appropriate Handle function is autom atically invoked. In < the single message mode, the client and server can poll the message queue using GetNext functions. An example of using this kind of communication is described in Section 8.6. Details of the implementation of this protocol is described in Section 7.3. 6.2 F u n ction s an d E x p ression s In this section, I present the syntax and semantics of functions and expressions. This section is brief in its treatm ent. A more detailed treatm ent can be found in [27]. Many of the previous components relied on the definition of functions. Functions are defined as follows: <FUNCTION_DECLARATION> ::= [ e x te r n a l ] fun <TYPE> <ID> * ( ’ [ <ID> : <TYPE> { »,» <ID> : <TYPE> }* ] ’ ) ’ ’ I fu n <TYPE> <ID> ’ ( ’ [ <ID> : <TYPE> { <ID> : <TYPE> }* ] ’ ) ’ ’ ’ = ’ <EXP> end fun <ID> »;» In the following sections, we will examine the body of function definitions, namely expres sions. 127 6.2.1 O verview There are no statem ents in GEDL, but expressions may have side-effects. However, side- effects are lim ited to affecting the object which the expression is related. Thus, the side- effects are both limited in scope and highlighted. ! The body of a function is a single expression whose value is the return value of the function. However, sequential expression evaluation is possible. The kinds of expressions ' are shown in the following production rule: <EXP> ::= <EXP> »"» <EXP> I l e t <VARIABLE_DECLARATION_LIST> in <EXP> end l e t I i f <EXP> th en <EXP> [ e l s e <EXP> ] end i f | f o r a l l <VARIABLE_DECLARATION> in <EXP> su ch th at <EXP> end f o r a l l I e x i s t s <VARIABLE_DECLARATION> in <EXP> su ch th at <EXP> end e x i s t s I fin d o n e <VARIABLE_DECLARATIOW > in <EXP> su ch th a t <EXP> end fin d o n e I f i n d a l l <VARIABLE_DECLARATIOW > in <EXP> su ch th a t <EXP> end f i n d a l l I <CONSTRAINT_DP> I <EXP> <BINARY_0P> <EXP> I <UNARY_0P> <EXP> I »(» <EXP> » ) ’ I <ID> I <CDNSTANT> | [ <ID> »->» ] <ID> ’ ( ’ [ <EXP> { »,» <EXP> }* ] ’ ) ’ I v o id I <EXP> i s a <ID> I <EXP> s u b c la s s o f <ID> I <EXP> as <ID> I <AT0MIC_0P> I <N0WAT0MIC_0P> I s e t [ <EXP> ».* ] <ID> to <EXP> end s e t I g e t [ <EXP> ’ . ’ ] <ID> I d etach <EXP> from <EXP> end d etach I add <EXP> to <EXP> end add I new <ID> [ a sso c <EXP> ] I new <ID> <EXP> ’ , ’ <EXP> I new <ID> <EXP> * , 5 <EXP> I abort tr a n s a c tio n I s t a r t tr a n s a c tio n <ID> I commit tr a n s a c tio n <ID> 128 6 .2 .2 C o n tr o l C o n s tr u c ts The operator is used to sequentially evaluate two expressions where the result of the first expression is ignored. Thus, the first expression is evaluated purely for its side-effect. i The l e t expression is used to add declarations to the current environment whose scope is from the declaration to the end of the let expression. The result of evaluating the let expression is the result of evaluating the subexpression in the environment plus the new declarations. The i f , f o r a l l , e x i s t s , fin d o n e, and f in d a ll are used for conditional evaluation and expression composition. The f o r a l l expression is used to check th at a given expression is true for all elements of a list. The e x i s t s expression evaluates to true if any element of the list satisfies the expression. The fin d o n e and f i n d a ll expressions are used to return the first or all elements of a set which satisfies an expression. 6 .2 .3 D e c la r a t io n s a n d T y p e s A variable declaration binds a name to the value of the expression. The syntax of variable declarations are as follows: <VARIABLE_DECLARATION> ::= <ID> <TYPE> [ ’= ’ <EXP> ] <VARIABLE_DECLARATION_LIST> : := i. <VARIABLE_DECLARATIOW > > + The syntax of types is as follows: <TYPE> ::= l i s t o f <TYPE> I in t | b ool I s t r in g | f l o a t I v o id I <ID> There are several pre-defined type identifiers in GEDL and they are organized in an object- oriented hierarchy, as shown in Figure 6.1. State Component Operation Object E d ito r Operations Command ConstraintManager Abstraction ViewT ree Vertex Element Edge Graphic ViewTreeVertex GConstraintVertex GCenterVertex GRangeVertex GBoxGraphicVertex GDimensionedVertex GRangeEdge GBeforeEdge „ _ GCenterEdge GConstraintEdge GEqualEdge GNeighborEdge Box \ \ GMarginEdge Line \ CompositeGraphic Figure 6.1: The GEDL Class Hierarchy The i s a and su b c la sso f operators are used to test whether the value returned by an expression is a member of a particular class or if it is a member of a sub-class of some type. In both of these expressions, the <ID> must be a type name. The as operator is used to type cast values from one type to another. This is primarily used in conjunction with types in the hierarchy and does not imply any conversion of the value. 6 .2 .4 D a t a M a n ip u la tio n E x p r e s s io n s The s e t and g e t operators are used to update and retrieve attribute values respectively. The d e tac h and add operators are used to remove and add values to lists. The new operator, in all its forms, is used to create instances of classes. 130 The <ATOM IC_OP> and <NOMTOMIC_OP> expressions are used within components to update their data. The atomic operations result in actually updating the information without invoking any interm ediate function. The non-atomic operations will invoke the atom ic delta function which corresponds to the operation. In most cases, the atomic delta function will simply use the atomic construct to update the data. The syntax of these operations is: <AT0MIC_0P> ::= atom ic add boxgraphic <EXP> I atom ic add lin e g r a p h ic <EXP> I atom ic add com posite g rap h ic <EXP> I atom ic touch grap h ic <EXP> I atom ic d e le te graphic <EXP> I atom ic add v e r te x <EXP> I atom ic add edge <EXP> I atom ic d e le te v e r te x <EXP> I atom ic d e le te edge <EXP> I atom ic touch v e r te x <EXP> I atom ic touch edge <EXP> <N0NATQMIC_0P> ::= add v e r te x <EXP> I add edge <EXP> I d e le te v e r te x <EXP> I d e le te edge <EXP> I tou ch v e r te x <EXP> I tou ch edge <EXP> 6 .2 .5 T r a n s a c tio n s Transactions are controlled through the s ta r t, abort and commit operators. The s t a r t operator initiates a transaction over a component. Typically, the component is the graph, but it may be an abstraction or a view in the case of direct modification of these compo nents. The commit and abort expressions are used to finish transactions. A commit will cause the global connectivity rules to be checked. If the rules are satisfied, the changes become perm anent and are propagated to the children in the view tree. Actually, the changes are propagated as p art of a transaction th at is begun on the children in the view tree. An abort will cause any changes th a t are part of the transaction to be undone. Specifically, ! all atomic updates are revoked. 6.3 S u m m ary In this chapter, I have finished the presentation of GEDL constructs with a description of communication, functions and expressions. The communication constructs allow the editor specifier to associate pieces of data and functionality with external entities. The function and expression constructs are used to build semantic descriptions which cannot be described using the constructs in the previous two chapters. The capability to build functions associated with each of the components in a GEDL editor is of critical im portance to creating usable editors. For example, building the task- dependence editor requires describing what a critical task and the critical path are. There is no clear way to do this with a purely declarative approach to specifying graph editors. On the other hand, providing functions and expressions greatly reduces the ease with which a graph editor can be specified. Generally, declarative constructs are much easier to use than making the same assertion in a functional construct. I don’t mean this as a general attack on functional programming, but rather I am suggesting th at, where possible, we want to anticipate the kinds of choices that editor specifiers will want to make and offer constructs to declare their decision rather than implement it functionally. Since it is not possible to anticipate all specifications, supporting functional specification is a necessary evil. 132 The trade-off between functional and declarative specification suggests a path for future research as well. In particular, as specifications are created, we can imagine gradually I 8 .transitioning specifications from functional to declarative descriptions. For example, if we I find th at the concept of critical path is common, then a new construct which allows the user to autom atically include critical path could be added to the language. I Overall, the GEDL language represents a set of design choices th at I have made. These i I choices are a carrier of the solutions to the problem of graph editor generation. In order i to dem onstrate the viability of GEDL as a vehicle for solving the problem, I need to dem onstrate its usability. This is done in the next two chapters. First, I will consider how GEDL can be translated into working graph editors. Then, I will present examples of editors and specification issues which arise from using GEDL and the translator. 133 C h a p ter 7 A G E D L T ran slator The utility of GEDL is highly dependent on its ability to be used in specification and generation of graph editors. In this chapter, I discuss the architecture of a translator for the GEDL language and some interesting aspects of the translator im plem entation. In particular, I consider the problems and solutions faced in solving layout constraint graphs and providing communication mechanisms. Before I discuss these aspects of the GEDL translator, I present the architecture of the translator system. 7.1 A rc h itectu re The design of a system for automatically generating graph editors based on a GEDL description is shown in Figure 7.1. The GEDL translator was built using Lex [34] and YACC [24]. The translator is capable of accepting all legal graph editor specifications and producing a set of domain-specific C + + classes. These classes specialize the GEDL base classes and define the domain-specific functionality of the editor. The GEDL base classes contain code which implements many of the core capabilities required in most graph editors. These 134 Editor Specifier GEDL Language Designer Editor User GEDL Base Classes YACC Borland C++ 3.1 for Windows Whitewater ObjectGraphics Classes Lex Borland C++ Classes GEDL Spec GEDL Translator Domain-Specific Classes Domain-Specific Graph Editor Specification IBM PC (386,486) MS-Windows MS-DOS Figure 7.1: GEDL Translator System 135 classes are designed in a way that provides reasonable interfaces for the GEDL translator to use. This means th at the job of the translator is to accept GEDL specifications and translate them into specializations of the base classes. For most constructs in the GEDL language, this is a straight-forward process. For example, the translation of a vertex type definition results in the creation of a class which describes this type. Some constructs in GEDL require considerable C + + code to be generated. For example, the connectivity semantics require ten to twenty lines of C + + code for each rule. On the other hand, the expression language is generally maps constructs in GEDL onto one or two lines of C + + code. This process of translation through automated specialization turned out to be an ef fective approach to designing a language using problem-centered design with iterative updates. This language design approach is describe in more detail in [28]. The idea using autom ated specialization was based on our previous experience with building class libraries for extensible graph editors [30]. Given this architecture, many of the problems of translating GEDL into executable form are m ade straight-forward. However, there are a few aspects of this translator system th at turned out to be sufficiently difficult to merit further discussion. These aspects are discussed in the following sections. 7.2 S o lv in g C on strain t G raphs As was noted in Chapter 3, there are two basic ways which other researchers have proposed as a means of integrating alternative sources of positioning information, general layout [46, 57] and constraint-based layout [44]. 136 In GEDL, I decided to take the second approach in order to foster experim entation with layout algorithms. Taking the second approach leads to the problem of developing a constraint solution ; function which can generate positions for graphical objects based on a prioritized list of ; constraints. In this section, I will examine an implementation of a constraint solver for GEDL constraint graphs. Other researchers [36, 63] have tackled similar but different problems. The constraint resolution problem for graphical object layout is actually quite complex since it involves non-linear circular equations. However, this domain has the advantage of a limited set of constraint types and can easily have a full ordering of constraints in terms of priority. Given these lim itations to the problem, I have designed an algorithm which solves the constraints j in a way th at ensures that higher priority constraints which conflict with lower priority constraints are satisfied. Using this algorithm as a basis, I have also developed algorithms for incrementally solving the constraints. I will examine each of these algorithms and other enhancements in the following sections. The first im portant observation in describing the solution technique used in the trans lator is th at the constraints are representable as a constraint graph. A constraint graph is a specialization of the graph type th at uses pre-defined vertex and edge types to represent all constraint information. An example of a layout constraint graph is shown in Figure 7.2. The creation and solution of layout graphs will be discussed in detail in this section. The im portant observation is th at the algorithm described in this section is really an algorithm for solving layout constraint graphs. 137 8 (a) User View (b) High Level Y View AT GT GT GT GT (d) Low Level Y View b (c) High Level X View EQ EQ (e) Low Level X View Figure 7.2: An Example Layout Constraint Graph 138 The algorithm for solving a layout constraint graph is based on a two step process. The first step is to resolve conflicts in the layout constraint graph and produce a new layout graph th at has an easier solution. The second step is obviously to solve the new constraint graph. Thus, when we discuss this algorithm we are actually going to be m anipulating two different graphs1. I call these graphs the high level constraint graph and the low level constraint graph. The high level graph contains all of the constraints th a t have been provided by the various sources (application, user, layout algorithm) possibly including contradictory constraints. The low level constraint graph contains the same set of vertices as the high level constraint graph, but the edges of the high level constraint graph have been translated into lower level constraints which are solvable. The low-level constraint graph will have an edge for every edge in the high-level constraint graph except for those high-level edges which make the constraint graph unsolvable. In order to describe the constraint graph solution algorithm, I need to describe two basic operations: (1) producing the low-level graph based on the high-level graph, and (2) converting the low-level graph into positions for box graphics. Note th at the each of these steps are done for each dimension independently. In other words, the algorithm involves four steps, two for each dimension. 7 .2 .1 G e n e r a t in g t h e L o w -L e v e l C o n s tr a in t G r a p h Producing the low-level constraint graph associated with a dimension involves considering each constraint (edge) in the high-level graph for th at dimension in priority order and attem pting to add it to the low-level graph. In pseudo-code form this approxim ated by: xT he actual im plem entation only uses one graph. However, it can be visualized as two distinct graphs by separating the high and low level constraints as is done in the constraint graph editor 139 SolveD im ension(D im ension dim) : d e le t e a l l lo w -le v e l edges fo r each h ig h - le v e l edge ( in p r io r it y order) i f i t s correspon d in g lo w -le v e l edge does n ot c o n tr a d ic t an e x is t in g lo w -le v e l edge th en add th e corresponding lo w -le v e l edge end i f end fo r each For most of the high-level edges, the corresponding low-level edge is an obvious trans lation. For example, before edges in the high-level graph will be translated into G T edges in the low-level graph. One im portant exception is the handling of neighbor edges. A neigh bor edge will establish an IGT, immediately greater than, relationship. This relationship can be established in either direction. The actual direction of the relationship will be based on either (1) any current relationship th at establishes one box graphic is greater than the other, or (2) an arbitrary choice. The arbitrary choice could be made significantly better by waiting until lower priority constraints are added and seeing if a particular constraint establishes a greater than relationship. Determining whether a new low-level constraint is contradicted by the current con straint graph is fairly simple. Functions exist which can determine if a particular relation ship holds between any two vertices. For example, the GreaterThan function will perform a breadth-first search of all incident G T, IGT and E Q edges attem pting to link the start vertex with the edge vertex. If no such link can be found, then the relationship is not established by the current graph. This does not necessarily imply th at the inverse relation holds, i.e., a false result of GreaterThan does not imply a LessThanOrEqual relationship. The following list shows all of the relationships th at can be tested. The description th at is associated with each suggests the search strategy th at is used to attem pt to establish 140 the relationship. • G reaterThanO rEqual A v e r te x VI i s g r e a te r than or equal to V2 i f f (a) th e r e i s a d ir e c t GT,IGT,EQ c o n s tr a in t, or (b) i t i s GT,IGT, or E Q to a v e r te x which i s G TE to V2. • N otlm m ediatelyG reaterThan A v e r te x VI i s not im m ediately g r e a te r than a v e r te x V2 i f f (a ) th e r e e x i s t s a v e r te x V3 where VI GT/IGT V3 and V3 GreaterThan V2, or (b) th e r e e x i s t s a v e r te x V3 where VI E Q V3 and V3 NotlmmediatelyGT V2. • G reaterThan A v e r te x VI i s g r e a te r than a v e r te x V2 i f f (a ) VI i s d ir e c t ly G T or IGT V2 or (b) VI i s equal to a v e r te x which i s G T V2 (o r) (c ) VI i s G T or IGT a v e r te x which i s g r e a te r than or equal to V2 • Equal Two v e r t ic e s are equal i f f th e r e i s an e q u a lity c o n s tr a in t betw een them , or th e r e i s a ch ain o f v e r t ic e s th a t are a l l equal such th a t V l=V i=. . . =Vk=V2 Mote: Equal on ly lo o k s in one d ir e c t io n . • Related T his fu n c tio n lo o k s fo r any r e la tio n s h ip betw een VI and V2, but on ly heads in one d ir e c tio n . 141 • FixedPosition A v e r te x i s f ix e d when i t has an a t or ce n te r c o n s tr a in t or i s r e la te d to someone th a t has an at or c e n te r c o n s t r a in t . Given these functions, determining contradiction is fairly easy. The contradiction rules depend on the type of the high-level constraint th at is being asserted into the low-level graph. The following list details these rules. • Before A before constraint is contradicted by (1) any contradictory greater than relationship, (2) an equal relationship, or (3) both vertices are already fixed. • Equal An equal constraint is contradicted by (1) any greater than relationship or (2) both vertices are already fixed. • Neighbor A neighbor constraint is contradicted by (1) an interm ediate vertex in a greater than relationship, (2) an equal relationship, or (3) both vertices are already fixed. • Center A center constraint which fixes a vertex is contradicted by (1) any relationship to a fixed vertex, or (2) a relationship to any of the input vertices. A center constraint which adds an input is contradicted by a relationship to any of the output vertices. ! • Range, Left Margin, Right Margin I I All types of range constraints are contradicted by any relationship to a fixed vertex. ] In summary, generating the low-level constraint graphs consists of priority order a t te m p ts to add the appropriate low-level constraint. The additional low-level constraint * will be added if no existing relationship contradicts the new constraint. The result of the j first phase of solution is a low-level constraint graph with no contradictory constraints. I l 7 .2 .2 S o lv in g L o w -L e v e l C o n s tr a in ts I | Solving low-level constraint graphs consists of traversing the low-level graph and determin- | I ing the position of each box graphic vertex. It turns out th at solvable low-level constraint ; graphs are directed, acyclic graphs or DAGs. The root vertices are either absolute position- , I ing vertices (range, left margin, right margin) or relatively positioned th at have no input | t I I constraints. The basic algorithm consists of a depth-first traversal progressing in a par- J I ticular direction (leftward or rightward). The two support functions, S e tP o sitio n R ig h t and S e tP o s itio n L e ft, assign positions to the box graphics in the low-level graph heading in a particular direction and starting at a vertex which has a known position. j The solution algorithm begins by assigning an initial leftmost position to all vertices. : Second, all range and margin vertices are used to establish initial positions for a set of vertices. Third, the solved vertices are used as input to the depth first traversal. Finally, if any vertices remain unsolved, then additional root vertices will be chosen in an iterative fashion based on having no input edges until all vertices are solved. The only time th a t th e ; final step is needed is when there are no absolute positioning constraints for a disconnected portion of the graph or for the entire graph. 143 | The S e tP o sitio n R ig h t and S e tP o s itio n L e ft provide a depth first traversal which i ;attem pt to solve as much of the graph as possible. The following pseudo-code outlines 'their operation: i jS etP o sR ig h t(so lv ed v e r te x V ): [ fo r each in c id e n t edge w ith V as th e second v e r te x sw itc h (ty p e o f (in c id e n t ed ge)) ca se CNTREdge: i f a l l o f th e in p u ts to th e ce n te r c o n s tr a in t are now so lv e d th en p o s it io n th e cen tered v e r te x based on average o f in p u ts S e tP o sR ig h t(cen tered v e r te x ) I I ca se GTEdge: ! c a lc u la t e p o s it io n ' i f (new p o s it io n i s g r e a te r than p rev io u s p o s it io n ) th en i s e t p o s it io n to t h is p o s it io n ; S e tP o sitio n R ig h t(n e w ly p o s itio n e d v e r te x ); c a se IGTEdge: c a lc u la t e p o s it io n s e t p o s it io n to t h is p o s it io n S e tP o sitio n R ig h t(n e w ly p o s itio n e d v e r te x ); c a se EQEdgeEdgeClass: c a lc u la t e p o s it io n s e t p o s it io n to t h is p o s it io n S etP o sitio n R ig h t(n e w ly p o s itio n e d v e r te x ) S e tP o sitio n L e ft(n e w ly p o s itio n e d v e r te x ) | end sw itch end f o r each 7 .2 .3 E x a m p le s o f C o n s tr a in t G r a p h s a n d T h e ir S o lu tio n s In Figures 7.3-7.6, a series of solutions to constraint graphs are shown. These figures I were generated by the constraint graph editor/debugger that is described in Chapter 8. Basically, this example of a GEDL-generated graph editor is capable of viewing, editing 144 0 0 GT GT (a) U ser View (b) High Level Y View (d) Low Level Y View I 1 Figure 7.3: Constraint Graph and Solution (1) i i | and debugging constraint graphs. I ! i _ j i The edge labels in the constraint graph views indicate the kind of edge (constraint), i The vertex labels indicate either a box graphic number or use a bitm ap to suggest the kind I , of vertex (center, range or margin). In the actual editor, these are color coded as well, so differentiation is much easier. Figure 7.3 shows a very simple constraint graph for the Y dimension only. The con- i 1 i straints which I have specified in the high-level constraint graph are simply th a t 0 appears ! before 1 which appears before 2. The equivalent low-level constraint graph is generated , i as shown. Solving the low-level constraint graph depends on (1) placing 0 at the top most position (since no boxes are fixed), and (2) traversing the DAG (in reverse order of the j I arrows) in order to position each of the other boxes relative to the first. Figure 7.4 shows a more interesting constraint graph. In this constraint graph (the high level Y graph), there is a contradictory cycle of before constraints. There is no way | th a t all of the before constraints can be satisfied. Therefore, in generating the low level' constraint graph, one of the high level constraints was ignored. In this case, each of the 145 GT GT i ' (a) User View (b) High Level Y View (d) Low Level Y View j Figure 7.4: Constraint Graph and Solution (2) i ' j high level constraints are of equal priority (not shown in the figure), so a decision is made i to not include the most recently added constraint. In fact, all constraints are added to the | i ! I priority-ordered list of constraints in FIFO order. This maintains better stability between j i [views. i . Figure 7.5 shows a much more interesting constraint graph with both X and Y con straints. The translation from high level to low level constraints is generally straight- | i I forward with a couple of exceptions. One exception is the before cycle th at was present in j Figure 7.4 and is resolved in the same manner. Another exception is the combination o f ! range constraints over 6 and 7. These range constraints fix 6 to a position of 100, and 7 to a position of 200. Looking at the low level Y view, we can see th at the range constraint on ! 7 is not present. This is caused by the fact that 7 is related to 6, and 6 is fixed by its range constraint. One of the three constraints must not be present in the low-level constraint graph. The solution of both the low-level X and the low-level Y constraint graphs is slightly more interesting than the previous examples. In the Y dimension, both range vertices are 146 □ 0 □ 0 0 (a) User View 0 c c r 6 (b) High Level Y View 1 2 r 7 8 (c) High Level X View AT GT GT GT GT (d) Low Level Y View GQ: GQ (e) Low Level X View Figure 7.5: Constraint Graph, and Solution (3) 147 AT GT AT GT GT (a) U ser View (b) High Level Y View | Figure 7.6: Constraint Graph and Solution (4) i I used as starting points of the depth-first traversal. The steps of the solution are as follows: 1 I 1 1. 6 is set by the range position. ! I I 2. 7 and 8 are set by the greater than constraints in order. 3. 0 is set because all of the inputs to the center constraint are now satisfied. 0 is positioned to the average of the 6, 7, and 8 vertices. 4. 1 and 2 are set by the greater than constraints. I In the X dimension, finding the start vertices is slightly more complex. In fact, two vertices are eventually used as root vertices. If vertices remain unsolved after the solution is ! applied starting at range vertices, the first unsolved vertex which has no incoming incident i i edges will be chosen. W ith no outgoing edges, the vertex is placed in the leftmost position , (everything else must be greater or equal). In this case, edges 0 and 1 will be chosen as root vertices. The traversal once the root vertices are found is trivial. Figure 7.6 is the same as Figure 7.5 except th at the priorities of the two range con straints have been placed above the before constraint. This changes the resulting low level graph such th at there is no greater than relation. The traversal of the low-level graph 148 jto find positions is similar to the previous example, but both range vertices are used to j I f 'eventually fire the center constraint. I i 7 .2 .4 S p e e d in g U p C o n s tr a in t G r a p h S o lu tio n s I The previous solution to the constraint graph requires regenerating and solving the low- ; level constraint graphs on every change to the high-level constraint graph. This is com putationally expensive for large constraint graphs, i.e., pictures with lots of boxes and ' f ( l dines or pictures with complex relationship characteristics. The com putational cost of the • ! ! I previous solution consists of both the com putational cost of generating the low-level graph ' i land of solving the low-level graph. I r | Creating the low-level graph is highly dependent on the checks of relationships between vertices such as G reaterThanO rEqual. These checks require traversing the low-level con- 1 straint graph in one direction over specific types of constraints. This means th at the cost 1 of a single relationship check 0(\v\ -f- |e|) where |u| is the num ber of low-level vertices and , i ■ |e| is the num ber of low-level edges. However, the solution is slightly faster since the num- ber of vertices and edges is actually only those that have been created up to th at point. ' This would not average one half of the final number since we may need to check on some . i _ I ; failures. The solution is also slightly faster because we only traverse some of the kinds of ' I edges not all types. In any case, the relationship checks are fundamentally 0 (\v\ + |e|). j i The process of creating the low-level constraint graph involves processing each of the edges in the high-level graph and using the relationship checks to determine the legality ! of each possible new low-level edge. Thus, the total com putational cost of creating the i low-level graph is 0 (\E \) * 0 (|u | + |e|), where \E\ is the num ber of high-level edges. This ! complexity is therefore 0(\E\2). The algorithm for solving the low-level constraint graph and generating positions is a I isimple traversal of the low-level graph. Thus, its cost is 0 (\v\ + |e|). This means th at the i |to tal cost of the solution is still 0 (\E \2). I For applications which deal with small graphs or applications which can handle only t i I solving the constraint graph periodically during execution, this may be acceptable. How ev er, for many applications, interactive positioning is desired and fairly large numbers of I constraints are expected in the constraint graphs. Thus, various speed-up techniques are I needed. The following sections describe algorithms intended to improve on the perfor- 'm ance of the previous solution w ithout changing the input or results. i i i \ 7 .2 .4 .1 In c r e m e n ta l G e n e r a tio n o f L ow -L evel C o n stra in t G rap h s The obvious place to attem pt to chop time is to not regenerate the low-level graph and i resolve it every time. An incremental algorithm could be used which would accept changes to the high-level constraint graph and would appropriately modify the low-level constraint i graph and update any changed positions. i Incrementally modifying the low-level constraint graph involves a couple of changes to ■ the non-incremental algorithm. If we treat all changes to the high-level constraint graph as 1 either adding or deleting a constraint, then the incremental algorithm can be implemented , as two prim ary functions, namely A ssertC o n stra in t and R etra ct C o n stra in t. Asserting a constraint requires checking for existing contradictory low-level constraints. If there are no contradictory constraints, then simply add the appropriate low-level con straint. If a contradiction is found, then a decision’ is made between the new low-level 150 .constraint and the existing contradictory relationship based on priorities. , Making this decision requires a modification to the relationship checking functions. i ;The functions now m ust return the constraint th at is part of the relationship and has the i » lowest priority. Given these relationship checks, A ss e rtC o n stra in t involves iteratively ‘testing for contradictory relationships until either (1) a contradictory relationship is found I whose lowest priority constraint is higher than the constraint being asserted, or (2) no con tradictory relationships are found. On each iteration th at finds a contradictory constraint of lower priority, the constraint is saved in a list of constraints. If it turns out th at the new I ■ constraint is asserted, then each of the contradictory constraints are retracted. If it turns out th at the new constraint is not asserted, then nothing is done with the contradictory I constraints, except noting th at they contradict the new constraint 2. J R etracting a constraint is actually a more complex change to the basic approach since we had previously only worried about adding constraints. Retracting a constraint should give all of the constraints which it had previously prevented from being asserted a new chance to be asserted. This is done by associating with each constraint in the high-level constraint graph, a fist of edges which contradict this edge. This list is kept in both of the contradictory edges. Whenever a constraint is retracted, we attem pt to see if any of its contradictory constraints can be asserted. Note th at reasserting an edge involves first checking its own contradictory edges for an existing higher-priority contradictory edge which is currently asserted and then using A ss e rtC o n stra in t to either find a new contradictory edge or to assert it. 2[36] and [63] both discuss similar approaches for increm entally solving constraint equations. W hile the basic idea of propagating the effects based on priorities is the sam e, th e kind of constraint graph dealt w ith in each case m akes the algorithm s different. Range Vertex Associated Low-Level Constraint Associated Graphic BoxG raphicVertex BoxGraphic Range ,2 AT " 1 Range-100,100 Range-100,100 GT Befor s,2 Low-Level Cc istraint GT User’ s View Low-Level Constraints Y-Dimension Only High Level Constraints Y-Dimension Only Constraint Figure 7.7: Structures Used in Incremental Constraint Solution Figure 7.7 shows the structures th a t are used in this incremental generation of the , low-level constraints. One additional relationship which is shown in the figure, but hasn’t been described is the bidirectional link between high-level constraints and their low-level counter-parts. This is used to assist in retracting and asserting in order to convert low- level contradictory edges into their corresponding high-level edge. Note th at only asserted high-level edges will have a low-level edge counter-part. Evaluating the com putational complexity of this algorithm turns out to be much harder than evaluating the previous algorithm. The relationship checks are the same in com putation cost since the search still traverses the graph is the same way (the change only requires an additional param eter and a return value). However, the way in which A sse rtC o n stra in t uses the relationship checks is very different from our previous algo rithm ’s used of relationship checks. In particular, A sse rtC o n stra in t iteratively tests for the existence of constraints which contradict the new constraint. If the new constraint is 152 Before, 1 Before,3 Before,2 High Level C onstraints GT GT Low-Level C onstraints Y-Dimension Only Y-Dim ension Only ! Figure 7.8: Example of Propagating Constraint Modifications - Stage 1 asserted, then a list of contradictory constraints are retracted. This in turn may reassert constraints which had previously been unasserted because they were contradicted by the I . ! . constraint th at has now been retracted. ; I An example of this situation is shown in Figures 7.8 and 7.9. In Figure 7.8, the con straints have priorities of one, two and three. Thus, the constraint between 1 and 2 is not ; asserted. In Figure 7.9, a new constraint has been added which contradicts the constraint ; i between 3 and 1. The new constraint has a priority of four so th at the existing constraint j is retracted. Because the existing constraint had previously contradicted the non-asserted constraint, th at constraint is re-asserted. In this case, the re-assertion succeeds. It is J ; possible both that the reassertion might fail, or it might cause another round of retraction and assertion. Overall, this means th at a single assertion (or retraction) may cause a series of asser tions or retractions propagating their effects through the low-level graph. The propagation of an update may take a while, but will eventually reach a steady state. Specific kinds 153. Before,4 Before, 1 Before,3 Before,2 High Level C onstraints GT GT GT Low-Level C onstraints Y-Dimension Only Y-Dimension Only I I Figure 7.9: Example of Propagating Constraint Modifications - Stage 2 j I ;of graphs are likely to suffer from delays due to propagating updates. These graphs are , ■ heavily connected, highly contradictory, or unstable graphs. Heavily connected graphs . i have many redundant constraints. Highly contradictory graphs have a lot of constraints which contradict other constraints. Unstable graphs have many contradictory constraints ; i w ith the same priority (making it rather arbitrary which set of constraints will be asserted j i at any particular time). This problem turns out not to be as im portant in practice. Most ! of the constraints are generated by a layout algorithm, and the layout algorithm can be designed not to produce a graph which is highly contradictory or unstable. The bottom line is that the cost of assertion and retraction is highly dependent on ‘ J the particulars of the graph. In most cases it will be the cost of one to three relationship , checks, 0 (|u | + |e|). However, it can be much more costly. This means th a t for alm ost' all constraint graphs, the cost of incremental updates to the low-level constraint graph is i significantly better than non-incremental updates. ; There is one additional note on the relative cost of incremental versus non-incremental; solutions. For some applications and layout algorithms, many modifications are made j to the high-level constraint graphs based on a single user command. In these cases, re- j ; generating and resolving the low-level constraint graphs becomes more com putationally I I competitive since several asserts and the associated propagations would be required in the increm ental algorithm. I ! One interesting effect of using the incremental algorithm is th at neighbor constraints I can be solved more effectively. In the non-incremental algorithm, neighbor constraints would be chosen in an arbitrary direction if no higher priority constraint had already established a greater than relationship between the vertices. In the increm ental solution, | all of the currently asserted low-level edges will be used when checking the greater than i (relationship. This allows for the possibility th at a lower priority constraint can choose the J ' direction of the eventual implementation of the neighbor constraint. Thus, the incremental j * . - I algorithm turns out to be better than the non-incremental algorithm in attempting to satisfy , I I the largest set of constraints. However, because of the propagation costs, we probably don’t I i want to use the assertion and retraction m ethod in the non-incremental solution. 1 j i 7 .2 .4 .2 In c r e m e n ta l S o lu tio n o f P o sitio n s While incrementally producing the low-level constraint graphs provides the biggest speed I improvement for constraint resolution, another candidate improvement is speeding up the ! generation of positions based on the low-level constraint graphs. The technique used in incremental positioning is similar to the technique used in the increm ental modification of low-level constraint graphs. Basically, the input to an in crem ental solution is the addition or deletion of low-level constraints (edges). This is 155 I I i [ 7 i — i i 2 3 U ser's View Figure 7.10: Incremental Positioning Algorithm - No Positional U pdate analogous to constraint assertion and retraction in the previous algorithm. In this case, ithe two functions are AddLowLevelConstraint and D eleteL ow L evelC onstraint. i ] The AddLowLevelConstraint function must accept a specification of a new constraint ; and update the positions of any vertices that are changed by the new constraint. The .im plem entation of this function depends on the kind of low-level constraint th at was added, t i.e., relative or absolute. In the case of a relative constraint, e.g., before, the function (a) determines if either of the vertices are fixed (note both cannot be fixed) and (b) sets the position of the non-fixed (or the smaller if neither is positioned) to the new position. In some cases the new constraint will not be sufficient to update the position of either vertex. This is shown in Figure 7.10. Because the new constraint is enforced by the combination of the two previous constraints, no updates occur. In most cases, the new constraint will update one of the position of one vertex (never both), and will propagate the effect of the change using the traversal of the non-incremental positioning algorithm. This kind of update is shown in Figure 7.11. 156 New C onstraint Before, 1 Before,3 Before, 2 High Level C onstraints GT GT Low-Level C onstraints Y-Dimension Only Y -Dim ension Only New Constraint R ange R ange 100,100 Before, 1 Before, 2 High Level C onstraints AT R ange 100,100 G T Low-Level C onstraints | Y-Dimension Only Y-Dimension Only ; Figure 7.11: Incremental Positioning Algorithm - Effect on Positions i The increm ental algorithm handles the addition of absolute constraints by setting the , newly positioned vertex and propagating the change using the non-incremental traversal j i ! . algorithm. In rare cases where the absolute position is satisfied by the existing position, ' no change is made. I The D eleteL ow L evelC onstraint turns out to be much trickier to handle. The problem 1 i is th at the deleted constraint may change the anchor (root) and path which was used to , i finally set the position of the vertex. It is im portant to note here th a t several different j anchors and paths might attem pt to position a vertex. The greatest position found is actually used. Thus, when a constraint is deleted which was used to set the position of a ) ■ vertex, a new anchor and path must be found. Luckily, we can rely on the fact th at vertices which are less than or equal to us and have a constraint which enforces this relationship w ill' remain less than or equal. The deletion then can be handled by finding outgoing GT and IGT edges and setting the position of the vertex to the greatest result of these constraints j 'and the positions of the adjacent vertices. If no outgoing G T or IGT edges exist, then this j ! vertex m ust be a left margin vertex and can be positioned as such. Given the new position j i j 'based on this algorithm, we must also traverse the graph using the same approach as in the add constraint. i The com putational cost of the incremental algorithm is superior to the non-incremental I algorithm when dealing with the addition of a single constraint especially in the cases where ! either (a) the traversal is halted early due to redundant constraints or (b) the traversal [ I j j ! | only involves a few vertices and edges because it begins in a relatively high region (not j j i ;much to traverse). In the average case, the increm ental algorithm is only slightly superior. ■ l j This result is dependent on only considering the addition of a single constraint. How- . ever, it is likely th at applications will generate several constraints in response to updates. 1 i ; Furtherm ore, the increm ental version of the low-level graph creation and its related prop agation causes several updates to the low-level graph in response to a single addition or deletion of a high-level constraint. Thus, in terms o f practical computational savings, it\ turns out that the incremental positioning algorithm is almost never superior to the non- incremental positioning algorithm. j 1 J However, the incremental positioning algorithm does suggest two changes to the non- increm ental algorithm to improve its utility and com putational costs. First, the vertices which don’t move at all during a solution don’t need to be redrawn. One of the computa- , tional costs th a t we have not considered up to this point is th at of rendering the graphic images. It turns out th at this is a significant portion of the cost of layout. However, if only those images which have moved are redrawn, then the cost of layout is greatly reduced. In C hapter 2, this was called increm ental redisplay. 158 Second, another aspect of the incremental algorithm is the ability to provide the ap plication with more stable layout without detracting from the performance of the layout j algorithm. Previous work, e.g., [6], had used additional constraints as the basis of providing j i stability. This adds to the complexity of layout and to the cost of solving constraints. Using the incremental algorithm, we could provide stability by limiting the traversal of j the graph to a depth of N, where N is the stability factor. This capability is available for use with both the incremental and non-incremental algorithm. In the increm ental algorithm, stability would limit the effect of the new position for the vertex during the traversal. In the non-incremental algorithm, traversal would occur as normal, but when a change of I < position is encountered, then effect of th at change would be limited to a specific depth, i This not only improves stability, but it also decreases the cost of positioning and redisplay. ! I 7 .2 .4 .3 In d e p e n d e n t S e ts o f C o n stra in ts t As was mentioned in Chapter 4, each composite graphic has its own set of constraints | i (constraint graph). This design was chosen for two reasons. First, each composite can; 1 1 then use its own layout algorithm. This technique is further examined in Section 8 .5 .; ' Second, the com putational cost of constraint solutions are heavily dependent on the size and complexity of constraint graphs. Separating the constraints into independent se ts! greatly reduces the cost of updating low-level constraints and solving their positions. ; Two additional capabilities were needed in order to support this approach. First, we; needed the ability to have graphics positions be relative to the position of the composite graph. This means th at when a composite graphic appears as a member of the constraints of a higher level composite, if it is repositioned, then all of its components are repositioned. 159. j Second, we needed to be able to compute the size of composite graphics in order to correctly ihandle the relative positioning constraints over composite graphics. This turns out to be i a simple m atter in terms of implementation. ' i 7 .2 .5 G E D L T r a n s la to r I m p le m e n t a t io n o f C o n s t r a in t S o lu t io n i . . . ' ! In order to compare the cost of various constraint solution algorithms, the GEDL translator | i was implemented with both the incremental and non-incremental generation of low-level j I ] constraint graphs. The application can choose which m ethod is used at run-tim e. The i i | i positioning algorithm that is provided is the non-incremental algorithm. J f j Because non-incremental positioning can be used with increm ental low-level constraint | ; i 'graph generation, we also provide the ability to control when the positions are solved. Applications will generally do it after each update, or will allow the user to control when j they are solved. This improves the interactive nature of the program through better I I performance and more stable updates. \ I , I 7.3 C o m m u n ica tio n S u p p ort i As presented in Section 6.1, the design of GEDL includes constructs for external functions i and external objects. In this section, I describe how the GEDL translator implements these constructs and the net effect of their availability. 7 .3 .1 E x t e r n a l F u n c tio n s There are two m ajor issues in the implem entation of external functions. First, the external function m ust be callable by other GEDL functions in some manner. The GEDL language 160 \ translator m ust state what kinds of param eterization is allowed and any differences between i I I 'external and internal functions as far as the approach to calling them. ! I J i The second issue is how an external function can interface with other parts of the j j GEDL editor. In other words, an external function might want to get the value of an attrib u te of a vertex if th a t vertex is passed to the external function. j ! In the translator, all types and calls back to internal functions are supported. The t | : im plem entation of these capabilities is specific to this translator. Actually, it is specific to , i ! ;the choice of C + + as an interm ediate language. ! i ; J I , j The translator implements all types as classes in C + + and instances as instances of ■ ! the corresponding class. Param eterization is done by passing references to instances. This J i i f , allows all types to be passed to external functions and for external functions to call internal ! functions using dynamic binding. This implies th at all external functions must be initially implemented as C + + , but might interface to other languages through simple stubs. As an example, I will consider a modification to the example in Section 6.1. In the 1 I ' previous case, the external function G etE n tries accepted the name of the directory. In , ■ the new definition, the function accepts a vertex. I P rev io u s D e fin itio n : 1 — T h is e x te r n a l fu n c tio n w i l l retu rn tr u e a non-NULL — l i s t o f e n t r ie s i f Name i s a d ir e c to r y . e x te r n a l fu n l i s t o f s t r in g GetEntries(Nam e : s t r in g ) ; New D e fin itio n : — e x te r n a l fu n c tio n which a cce p ts a v e r te x typ e e x te r n a l fu n l i s t o f s t r in g G etE ntries(V : F i le ) ; The change of interest is th at the external function G etE n tries now accepts a pa- 161 jram eter of type F ile rather than simply its Name attribute. The name is the piece of t ] (needed information, so the external function must additionally make a call back to the I I G e tA ttrib u te function. The implementation of GetEntries might be: j# in clu d e < sy s /d ir .h > ,'PCharList D irT ree: .-G etE ntries(¥ : F ile ) i ! char* N; j in t fd .n r e a d ; s t r u c t d ir e c tx { in o _ t d_ino; i char d_name[DIRSIZ+1] ; i J > d lin k ; t /* c a l l back * / N = V->G etNam e(); i f ( ( f d = o p en (N ,0 )) == - i ) ] r e tu rn FALSE; 1 w h ile ((n rea d = r e a d ( fd ,& d lin k ,s iz e o f(s tr u c t d ir e c t ) ) == ( s iz e o f ( s t r u c t d ir e c t ) ) { /* . . . f i l l in E n tr ie s w ith d ir e c to r y in fo rm a tio n * / > ! I r e tu rn TRUE; I !> I J The interesting part of this example is seeing a call back to an internal function a n d ' various choices th at have been made in the translator about the im plem entation of p rim -; , t I I 1 itive types. For example, the implementation of list types is done using C + + tem p lates.; All GEDL types and user-defined types will have a corresponding list type. Given external functions, most of the required communication capabilities are supported, but a couple of other additions to GEDL are still needed. • (7 .3 .2 E x t e r n a l O b j e c t s I i ,One of the interesting capabilities of declaring functions as external is the ability to have the I 'propagation functions handled by external functions. However, even if all of the functions Jof a particular object are declared as external, the internal structures provided by GEDL I are still used to store the data. In some cases, this is redundant. I i For example, the graph data for a directory browser exists in the file system. In the i previous examples, the entire directory tree is duplicated as internal d ata in the editor. ; ] Even if all of the delta functions of the graph were external, the graph object would still { control a set of vertices and edges th at are internal. | If we want to remove this redundancy, then there must be a way to declare everything j ■ I I as being external. As described in Section 6.1, GEDL supports the declaration of graph, ,abstraction, composite, view, and command as e x te rn a l. The translator has a limited role in handling external objects. Specifying a GEDL object as external means th at the translator will generate external references for the functions which handle propagation or : other interfaces to the object. At link time, these external references m ust be resolved. Thus, external objects are similar in flavor to the external functions and their interface. The only immediate difference is th a t the representation of the d ata is completely hidden , from the rest of the GEDL editor. However, in practice the use of external objects is very , different as will be discussed in Section 8.6. Overall, external objects and external functions are highly dependent on the translator. • Thus, if portable GEDL specifications axe desired, then the external entity’s responsibilities should be minimized. Otherwise, significant portions of the GEDL specification may need to be changed if a different translator is used. 163 i The combination of external functions and external objects support up to the second level of communication. There is no way, given only these two capabilities, for an external 4 I ’source of information to directly make changes to the editor. In order to address this I |capability, the m ethod of initiating change, the main-loop, must be changed. j ; [ ,7 .3 .3 E x t e r n a l C o n tr o l S I j The GEDL main-loop basically accepts a request for some command or tool operation and ; ! ! performs the requested operation. The result of the operation may change many aspects of the state of the editor. In a simple GEDL translator, this main-loop would be implement ! by waiting for user input and then translating the input into the proper operations. This i kind of main-loop would preclude the ability for an external entity to invoke operations 'directly since the wait for new work is purely based on user generated events. In order to accept competing requests for action from the user and from external , entities, some change to the ’ ’get next operation” protocol must be used. This more sophisticated main-loop m ust accept input from either the user or from external sources and translate these alternate sources into operations. j i I I The im plem entation of this protocol is highly platform dependent. In this transla- : i tor, competing sources of input are easily handled. Since all input is through call-back I functions and external entities can easily generate call-backs based on message passing, 1 the com peting sources of input becomes a trivial m atter. Whichever call-back function is called first will be the next source of input. The request for action from external sources is l done by an operating system level communication using message passing. In combination with the call-back nature of the windowing system, these messages act like RPCs. The 164 ! MS-Windows platform provides a conversation-based mechanism supporting this form of communication. The use of this protocol in graph editors is described in Section 8.6. i I I I 7.4 S u m m ary In this chapter, I have presented the architecture and im plem entation issues for a GEDL j 1 translator. The architecture of the translator provides an im portant contribution to the ; i < language design process used in GEDL. ; i The most interesting aspect of the translator is the implementation of the constraint ! | solver. Efficiently solving constraints was the prim ary problem with choosing constraint- | | I based integration as a solution to the layout problem. The constraint solution presented j j I in this chapter and the results of using the translator dem onstrate th at constraints can be 1 ! J efficiently solved. While the solution of constraint graphs is a contribution by itself, a more im portant [ i contribution of the work on the GEDL translator was the incremental algorithm for solving j I constraint graphs. This algorithm not only significantly improves the performance of the constraint solver, but it actually is able to satisfy a larger set of constraints than the non-incremental algorithm while m aintaining the prioritization. Another im portant, but negative, contribution was the finding th at incremental positioning is generally a poor alternative unless stability is a critical concern. Even then, there is a good possibility of other approaches yielding more effective solutions. A final contribution in the area of constraint-based layout is the use of independent sets of constraints through the composite graphic construct. This provides the possibility of very efficient layout and also allows for multiple layout algorithms in a single view. 165 ‘ j This chapter also dem onstrates how the communication mechanisms described in the i i jprevious chapter can be implemented. In particular, the ability to provide an implemen tation of d ata and control intercommunication is dem onstrated. This is im portant for the usability of GEDL-generated graph editors within a larger environment. Given the GEDL language and an example of a translator for this language, we can now consider examples and issues in using it to specify and generate graph editors. 166 | C h a p ter 8 i i j S p e cify in g G rap h E d ito rs U sin g G E D L ! j Given GEDL and the translator described in the previous chapters, the final aspect of t l GEDL th at needs to be examined is its usability in specifying domain-specific graph editors. I i j The design of the GEDL language was based on iteratively defining an informal syntax and i operational semantics of the language and then attem pting to use it to describe domain- j , specific graph editors with a variety of capabilities. This design approach was used in order ' to improve the likelihood that GEDL would be effective in specifying domain-specific graph , I editors. The following domains were considered when iteratively defining GEDL: j I • Organization Charts j • D ata Flow Diagrams | • ERA Schema • Directory Hierarchies • Project Management (Task-Dependence Graph) • Petri Nets • Finite State Machines • State Transition Diagrams • H ypertext • Genealogy 167 ' • Function Call Hierarchies , I i • Configuration Management I < • Faceted Classification • Idea Outlines • Menu Hierarchies • Process Models I j • Structured Design Charts i • Flow C harts I • Constraint Graphs • View Trees These examples have a wide range of complexity and requirements. They were chosen t I i i | with the purpose of testing the usability of a variety of different possible language con- [ I structs. Furtherm ore, they were part of the process of determining the requirements for a i ! language for graph editors. 1 In applying successive versions of the language to these domains, a set of commonly ; ^needed capabilities emerged as well as a set of exceptions to these common needs. The j : following sections consider various common needs and how GEDL is used to support them , j ; i They also consider how various exceptional cases can be handled in GEDL. 1 | j R ather than attem pting to describe implementations of each of these domain-specific j I graph editors, I will present two graph editors and will present interesting aspects of using GEDL to address key concepts for graph editor specification languages. Therefore, these ' sections leave many aspects of various editors unspecified (for brevity’s sake). See the appendices for full specifications of two example editors, the Task-Dependence Editor in Appendix C and the Constraint Graph Debbugger/Editor in Appendix B. 168 G raph Edit-[Untitled) file Edit lo o l View W indow T y p es AddView Misc Help i l H HighLevelXView UserView HighLevetWiew LowLevelYView Figure 8.1: The Constraint Graph Editor/Debugger 8.1 C on strain t G rap h E d ito r /D e b u g g e r The constraint graph editor/debugger is an interesting example of the unexpected usability of graph editor generators. In order to work on the development of a solution for constraint graphs, I developed an editor which can be used to represent, edit, visualize and solve constraint graphs. This editor is shown in Figure 8.1. This editor can also serve as a specialized debugging tool. There are hooks included in the constraint manager associated with every composite graphic which can be used to 169 communicate with the constraint graph debugger. This means th at other editors can be i debugged using this editor. | J i j The capabilities of the constraint graph editor are briefly: I j • Multiple Abstractions A constraint graph includes five overlapping kinds of inform ation, namely, user, high- ' level X, high-level Y, low-level X, and low-level Y. This information is all present j in the underlying graph, but the constraint graph editor supports separation of the I | information using abstractions for each kind of data. J • Multiple Views ! I The constraint graph editor allows multiple views of each of the different kinds of j | | • abstractions. I I ; • Constraint Graph Solution The constraint graph editor contains an implementation of the constraint graph ! 1 solution algorithm. This allows the user to experiment with various constraint graphs t j and see the resulting low-level graphs and the user view. • Debugging The constraint graph editor can serve as a debugger for other editors. It is defined as a server so th at other editors can request th at it display and edit th a t editors constraint graph. The task-dependence graph editor is an example of an editor th at i uses the constraint graph editor as a debugger of its layout. E Z P n I □ G raph Edit - (Untitled) T ask D ep en d en ceG rap h V iew File Edit Tool View W indow T ypes M isc Help J5 34 J8 38 7 " J10 43 J1 10 J2 J4 15 22 J6 32 \ J3 17 39 / J7 29 Figure 8.2: The Task-Dependence Graph Editor - No Composites 8.2 T a sk -D ep en d en ce G rap h E d itor The task-dependence graph editor is designed to dem onstrate the capability of GEDL to be used in a variety of domains which look similar to task-dependence graphs. These domains include PERT charts, process models, state transition diagrams, d ata flow, etc. The GEDL-generated task-dependence graph editor is shown in Figure 8.2. This editor dem onstrates several interesting capabilities. The following is a brief de scription of some of these capabilities: • Composite Tasks In addition to the standard tasks and dependencies, the editor includes composite ! tasks which are used to form a hierarchical decomposition of a project. An example of a task-dependence graph which includes composite tasks is shown in Figure 8.3. | • Composition Abstraction Composition abstraction is used to hide all of the children of a composite task. The Graph Edit - (Untitled) File Edit Tool View W indow T y p es M isc Help Figure 8.3: The Task-Dependence G raph Editor - Multiple Views w / Composition Ab straction user is allowed to choose an Expose or Hide on any composite task. These operations allow the user to hide off subtrees in the graph which frees the user from unnecessary detail. • Automatic Layout A variation of the Sugiyama hierarchical layout algorithm [56] is used to generate constraints for positioning the tasks. • User-Defined Constraints The Sugiyama layout can be modified by the user through move operations. This puts a high-priority range constraint which fixes the position of th at box graphic. • Constraint Debugging 172 J The constraint graph editor/debugger can be started from the task-dependence graph 1 I | editor as a way to edit the current constraint graph. This serves more as a debugging i tool during development of the task-dependence editor, but it could also be used to fine tune constraint graphs during normal editing sessions. j8.3 G rap h S em a n tics One of the im portant issues in defining a graph editor is being able to express the semantics of the graph data. In GEDL, semantics expression is done through the edge and vertex 'ty p e hierarchies, connectivity semantics and through the delta function definitions. Given I T hat the graph semantics can include function definitions, it is not surprising th a t all of the dom ains’ graph semantics can be defined using GEDL. A more interesting question is ‘ how and how hard it is to describe non-trivia! graph semantics. In this section, we will consider this question through several examples of semantics expression. 8 .3 .1 U t iliz in g t h e T y p e H ie r a r c h y One of the advantages of having the type hierarchy for data types in GEDL is the ability to express rules in a cleaner and more concise manner. A global and local rule is checked ■ against all instances of a class and instances of subclasses. This makes expression of certain kinds of rules much simpler. ! i i For example, consider the constraint graph editor/debugger. The specification of thej i i local rules is: lo c a l r u l e s : GraphicEdge : BoxG raphicVertex -> BoxG raphicVertex : one; 173 CenterEdge CenterEdge RangeEdge MarginEdge NeighborEdge EqualEdge BeforeEdge IGTEdge GTEdge EQEdge NEEdge CNTREdge CNTREdge ATEdge BoxGraphicVertex -> C enterV ertex : many; C enterV ertex -> BoxGraphicVertex : many; BoxGraphicVertex -> RangeVertex : many; BoxGraphicVertex -> L eftM arginV ertex I R ightM arginV ertex : many; BoxGraphicVertex BoxGraphicVertex BoxGraphicVertex -> BoxG raphicVertex : many; -> BoxGraphicVertex : many; -> BoxGraphicVertex : many; BoxGraphicVertex -> BoxGraphicVertex : many; BoxGraphicVertex -> BoxGraphicVertex : many; BoxGraphicVertex -> BoxG raphicVertex : many; BoxGraphicVertex -> BoxGraphicVertex : many; BoxGraphicVertex -> C enterV ertex : many; C enterV ertex -> BoxGraphicVertex : many; BoxGraphicVertex -> RangeVertex : many; j The connectivity for NeighborEdge, EqualEdge, and BeforeEdge are exactly the same, J This is because they are all really a vertex type th at relates two box graphic vertices, called ; r e la tiv e c o n s tr a in ts . If the type hierarchy included a type R elativeE d ge as the parent of each of these types, then the constraints over R elativeE d ge could replace three existing ' constraints. P r e v io u s : NeighborEdge EqualEdge BeforeEdge BoxGraphicVertex -> BoxGraphicVertex : many; BoxGraphicVertex -> BoxG raphicVertex : many; BoxGraphicVertex -> BoxGraphicVertex : many; ■ New: R elativeE d ge : BoxGraphicVertex -> BoxGraphicVertex : many; This capability also aids in the reuse of GEDL code in th at connectivity constraints ' can be enforced over the base types in the base graph class. 174 ;8.3.2 Further G lobal R ules ! I The set of global rules available in GEDL (Tree, DAG, and Connected) are intended as examples of the kinds of global rules th at are possible. Obviously, there are many types of l l ! global graph connectivity requirements th a t cannot be expressed using these rules. Even i 'if we added a large number of global connectivity rules, undoubtedly, there would still be I 'cases th a t could not be expressed with the rules. Thus, a basic question arises of how to ! i !express global semantic rules that cannot be represented through existing global rules. ! | | | For example, consider the problem of expressing the rule th at for a given vertex type | [ V and edge type E the graph must not be biconnected. A graph G is biconnected if for j 1 every distinct triple of vertices v,w,a there exists a path between v and w not containing j I a [2]. A graph G which is not biconnected must have at least one articulation point which i 1 | effectively divides the graph in two1. j i The requirement th a t the graph have at least one articulation point (not bi-connected) | ' i I ! cannot be expressed using either the local or global connectivity constraints. However, | t ; p art of the requirement can, namely th a t the graph must be connected. In order for a I ; graph to have an articulation point and not be biconnected, it must be connected. Thus, j I , the global rule: co n n ected : V , E ; would be part of the graph specification. The remainder of the semantic requirement must be handled through modifications to the delta functions. In general, the function which contains this semantic requirement is either AddEdge j 1 T his kind of graph was used in [9] to restructure software designs extracted from code. 175 [or Com m itTransaction. Modifications to the AddEdge function can check each addition 1 jto the graph for its legality. Modifications to the Com m itTransaction function can check j L n entire transaction for its legality based on the new graph. In the case of checking j biconnectivity, we would want to modify Com m itTransaction for two reasons. First, ■ adding an edge which tem porarily biconnected the graph can be allowed as long as another ' i edge was deleted before the commit. Second, the commit transaction function is called ! after the global graph rules have been checked. Thus, we can be assured th a t the graph is ' : j ' connected. I } I 18.3.3 R e la tio n s h ip s j I I j In this section, we will look at is how can we express rules which express some constraint : : I ,on the relationship between certain vertex and edge types. For example, in the task- j ! dependence graph a composition hierarchy coexists with a directed acyclic graph of task j and dependency. Thus, an implicit relationship exists between composite tasks in terms ' of their dependence. If we keep this relationship implicit, then we are limited in two ways; j ( 1 ) we cannot visualize the relationship directly since there is no direct representation in J the graph; and (2) we cannot perform other semantic checks such as the acyclic nature o f . i these implicit dependency links across composite tasks. For these two reasons, we are m otivated to introduce an explicit relationship (an edge) between the two composite tasks which represent their dependence. In the task editor this is done by introducing a new edge type: - - The im p lic it su c c e sso r lin k betw een com posite ta s k s edge I m p lic itS u c c e s so r i s 1 p r iv a te : C r it ic a l : b o o l; 176, end edge I m p lic itS u c c e sso r ; i I We also need to introduce code associated with the AddEdge and D eleteE dge delta func tions which introduce and remove Im p lic itS u c c e sso r edges in the graph correspond ing to this implicit relationship. This code is presented in Appendix C as the functions i lA d d lm p licitS u cc and D e le te lm p lic itS u c c . ■ One other change to the graph description we wish, is to restrict the connectivity of I implicit successors with the following local and global rules: ! lo c a l r u l e s : ' I m p lic itS u c c e sso r : CompositeTask -> CompositeTask : one; g lo b a l r u le s : t dag : CompositeTask , Im p lic itS u c c e sso r ; I I ! These rules show th at Im p lic itS u c c e sso r edges can only connect one composite task to one composite task, and th at they form a directed acyclic graph over composite tasks. The ' global rule has a significant im pact on the interaction between the tree of composite tasks , and the DAG of tasks and dependencies. In particular, the rule restricts composite tasks i , from containing tasks which are both predecessors and successors of another composite 1 . task. For example, consider the dependency graph shown in Figure 8.4. In this graph, the implicit successor link between Dev and Mnt has been added because of the dependency , ! between Cod and Tes. If we attem pt to add another task as the child of Dev and as the t , successor of Tes or Mnt, we will get an error message th at the graph violates the dag property over implicit successors. Note th at this new graph is not illegal according to either the tree property over composition or the dag over dependencies. Overall, making the relationship between the composite tasks explicit provides solu tions to both of the problems introduced at the beginning of this section. In practice, these 177 Mnt Dev Tes Des Cod Mnt Req I Figure 8.4: Connectivity Semantics in Conjunction with Calculated Relationship j : kinds of relationships are most often domain-specific and are not easy to generalize. For this reason, the use of GEDL functions as the basis of specification may be an appropriate ! j mechanism. Furtherm ore, being able to introduce explicit relationships in the graph data ' | allows other components of the editor to be unaware of the mechanism th at is used to j introduce this relationship. J ! 8 .4 A b str a c tio n i As presented in Section 2.3.2, several abstraction mechanisms have been suggested by ; previous researchers most notably composition and edge concentration [44] and subgraph : I selection [20]. Each of these mechanisms provide powerful approaches to the problem of I i allowing the user to w hittle down the graph to a particular graph of interest. W ith GEDL, I take a different approach from previous work on abstraction by a t tem pting not to restrict the editor specifier to any particular set of abstraction techniques, b u t rather to give a framework for specifying whatever abstraction technique is appropri- i ate for the domain. From this viewpoint, any particular abstraction technique should b e ’ specifiable using GEDL. Again, one of the biggest goals of GEDL is to understand what graph editing, and in this case abstraction, is all about. Thus, the real question for GEDL is not what abstraction mechanism it supports, but how GEDL can be used to implement | i i known algorithms and experiment with new techniques. j The basic approach in GEDL to dealing with abstraction is to (1) treat it as a trans- 1 i j form ation and (2) keep it similar to graph specification. It is a transform ation in the sense j th a t graph d ata changes are propagated to the abstraction which results in a new graph, j I : I ;The resulting graph is generally related to the original graph, but is transform ed to be the | graph of interest (or at least closer to the graph of interest). The abstraction is simply a j transform ation from one graph onto another graph as was suggested in Section 3.2. ' i I Because of propagation, abstraction syntax turns out to be the same as graph syntax. | ' 1 , I , However, the motivation and likely specifications for graphs and abstractions are very dif- | i .ferent. A graph will be concerned with representing the entire graph including inform ation ; ith a t may not be of interest to the user. An abstraction is concern with transform ing the i underlying graph d ata into a new graph th at is of interest to the user. ' In order to get a feel for abstraction specification in GEDL, I will present the imple- ; m entation of various aspects of composition abstraction as is used in the task-dependence j graph editor. The full GEDL source code for this editor is found in Appendix C. j i I I 8 .4 .1 A b s t r a c t io n D a t a ; I The first aspect of specifying a graph and an abstraction is the specification of the types of d ata which it m anipulates. The syntax for specifying abstraction d ata and graph data is exactly the same and most often, the graph d ata and abstraction data will share the same definitions. However, the graph and the abstraction do not share the same instances of the data. The relationships between the instances is shown in Figure 8.5. This figure shows 179 I 1 th a t each component will own its own elements. In order to support multiple copies of : i ■elements, propagation autom atically creates copies of elements. This frees the abstractions j | I ifrom having to explicitly copying attributes of graph d ata elements into its own elements. I In many types of abstraction, the graph data will require additional attributes to j .represent abstraction properties, e.g., hidden. This can be handled in one of two ways. \ Either the necessary attributes and new types are added to (1) both the graph d ata and i .abstraction data, or (2) only the abstraction data. L et’s consider these approaches in the ; context of composition abstraction as is done in the task editor. The specification of the CompositeTask type as needed by the graph d ata is: v e r te x CompositeTask i s sa v ea b le { e d ita b le : Name : s tr in g ; p r iv a te : I - - updated by d ata manager in c r i t i c a l 1 - - path c a lc u la tio n j D uration : i n t ; \ C r it ic a l : b o o l; EndDate : i n t ; end v e r te x CompositeTask; j i ' However, if we want to allow the user to arbitrarily restrict the display of the sub-tree which falls under a particular composite task, then we need to add an attrib u te which ; represents the current interest of the user. This is done by adding the following attribute: j i v e r te x Com positeTask i s sa v ea b le > p r iv a te : i — u sed in C om position A b stra c tio n o n ly ! Hidden : b o o l; end v e r te x CompositeTask; Now, the question is w hether this additional attribute should be associated with graph data. The answer is th at if we wish to have multiple abstractions existing at the same time, t 180; Box-1 Box-2 Vertex-1 View-1 Edge-1 Box-1 Line-1 Vertex-1 Abstraction-1 Box-2 Line-2 Box-3 Edge-1 View-2 Vertex-2 Graph Box-1 Vertex-1 View-3 Abstraction-2 Figure 8.5: Abstraction, and View D ata Ownership and Associations then we want each abstraction to have its own value for the Hidden attribute. Because i GEDL creates a copy of the composite task in each abstraction, it is irrelevant whether the ' ! graph d ata also includes this attribute. Including it wastes a little space, but creating an entirely new type, e.g., H ideableC om positeTask, which is basically an exact copy of the :graph’s composite task may not be worth the conceptual overhead for the editor specifier. I j Once we have included this attribute in our abstraction data, then the im plem entation of the abstraction and operations for controlling the abstraction becomes rather easy. The ■ abstraction implementation involves hiding and exposing the children of a composite task based on the value of the attribute. In this case, hiding and exposing is simply adding j I t | jthe children of the composite to the abstraction or removing the children of the composite ; jfrom the abstraction. This is shown in Figure 8.6. In A b stra c tio n -1 , the children of A j are hidden, and in A b stra c tio n -2 , the children of B are hidden. The im plem entation of \ 1 1 the functions A ddC hildren and RemoveChildren are shown in Appendix C. : i The operations which control the abstractions are provided as Hide, Expose which j i . change the Hidden attribute associated with a composite task and triggers a call to the ( I appropriate abstraction function for adding or removing children. Thus, the user can select | t any particular tree as the graph of interest, and can hide subtrees by selecting a composite ■ task and choosing hide. A simple example of this is show in Figure 8.7. I 8 .4 .2 M u lt ip le A b s t r a c tio n s Treating abstraction as a transform ation on a graph has the interesting side-effect of; allowing for multiple views of multiple abstractions. The usual treatm ent of abstraction is th a t it is a function of the view, and therefore, there is no separation between views. 182’ View-1 Abstraction-1 View-2 Graph View-3 Figure 8.6: Composition Abstraction 183 j Figure 8.7: Hidden Components through Composition A bstraction \ I 'an d abstraction. The treatm ent of abstraction as a transform ation of graph d ata which j results in new graph d ata has two advantages. First, multiple views of a particular graph t i of interest does not require redundant representation of the abstraction attributes. If views are tightly coupled to abstraction, then each view will require redundant representation of | i w hat is of interest to the user. In composition abstraction this is the h id d en attributes. This is not necessarily just a problem of wasted space. It may also be a problem of keeping ' redundant data consistent. W hen the user hides the children of a composite, the other \ i views m ust be updated to show this new “non-interest” of the user. j : i Just as separating data from views is a good idea because of allowing multiple views 1 of a single data source, separating abstracted data from views is a good idea because of ■ allowing multiple views of the same abstraction. Second, this approach allows for the composition of abstractions. One of the im por tan t features of the Unix operating system is the ability to compose tools through pipes. 1 | The reason th at this is an effective technique is th a t many tools act as filters (transfer-1 i . | iinations) on data which produces the same kind of data (streams of characters). The I GEDL approach is similar where abstractions act like filters of graph d ata which eventu- j 1 | ally transform the underlying graph into a graph of interest. The flexibility inherent in .this approach is especially attractive because of the broad range of filtering th at can be 'used for graph transform ation. i ' The use of composition of abstraction occurs often in our experience with creating ; i domain-specific graph editors. One of the graph editors we created is a process model i \ ' editor based on the A rticulator process meta-model [39]. This model provides a set of I 'base classes, a hierarchy of user-defined subclasses, and instances of those classes which | I form a directed graph similar to the task-dependency graph (including both composition ! I I jand dependency). A graph editor to support this domain needed to be able to focus the < ■user on one of these aspects of the entire graph. In other words, the user can specify 1 th a t only the class hierarchy is of interest. This will hide all other vertex and edge type I instances. Furtherm ore, the user will often wish to use composition abstraction to hide ^ i particular parts of the class hierarchy. Thus, the user often wanted to compose selection ! abstraction and composition abstraction to obtain the graph of interest. Figure 8.8 shows a possible view tree in the process model editor. We can think o f 1 the first level of abstraction as a partition of the graph into various sets of types th at a re ; of mostly independent. This technique is common and quite simple using GEDL. In fa c t,: this is used in the constraint graph editor/debugger to separate each of the five kinds of • data. Another point of interest in this figure is the re-use of composition abstraction. In 185 Abstraction Pre-Defined Type Hierarchy Abstraction Composition View Tree View Tree Abstraction Composition Abstraction User-Defined Type Hierarchy Abstraction Composition View Tree Graph Process Model Abstraction Task Hierarchy View Tree Abstraction Composition Abstraction Task Description View DAG View DAG Abstraction Task Description View DAG Figure 8.8: Possible View Tree in Process Model Editor 186 ithis case, it is applied to the type hierarchy tree. The positioning of the composition abstraction shows th a t the user can restrict the tree to a particular subtree. The user can also create multiple views of a composition abstraction. This allows independent zooming, I ! panning and scrolling over the same graph data. : I | I ‘ j i 8.5 L ayou t j 1 j i i The specification' of layout in GEDL consists of generating a set of constraints which ultim ately control the position of box graphics and their corresponding line graphics. In ,this section, I will discuss how layout algorithms can be created using the constraints and constructs in GEDL. Previous research [44] has suggested how constraints can be used jto implement known layout algorithms such as Sugiyama’s [56], ISI G rapher’s [49], etc. * R ather th an further discussing the translation of these algorithms into constraint based i algorithm s, I will concentrate on what GEDL provides towards easier im plem entation of i . these layout algorithms, or even more efficient /effective layout algorithms. j ! Previous research into graph layout generally suggests a single layout algorithm be applied to the entire graph to produce the visualization. The research presented in this dissertation and independently suggested in [20] points out th at the composition of lay o u t, algorithm s is an effective tool in visualization. j 1 As an example, consider the visualization of an organization chart as is shown inj Figure 8.9. This visualization is produced by utilizing two different layouts. One lay out is used in C om posite-1 through C om posite-7. This layout horizontally positions lower level members using before constraints. A completely different layout is used in C om posite-8 through Com posite-11. In this layout the members are placed in a more 187 ASK Software President Frances Development Vice President Joe Macintosh Chief Engineer Kathy Staff -Elizabeth -T eddy -M argaret Composite-8 Composite-4 IBM Chief Engineer Pat Staff -Christopher -Kevin -Paul Composite-9 Composite-5 Composite-2 Business Vice President Mary Advertising Manager Michael Staff t Kirsten Hillary Composite-10 Composite-6 Sales Manager Norah Staff .Paul .Patrick .Biz Composite-11 Composite-7 Composite-3 Composite-1 Figure 8.9: Composite Layout in an Organization C hart X-Equal Y-Before X -C ehtqr Y-Equal Y-Equal X -C enter X -C enter X -C enter X-Equal Y-Before X-Equal X-Equal Blank Blank Blank Blank X -C enter A SK Softw are P resident Arthur B usiness Vice P resident Steve D evelopm ent Vice P resident A nnette Em ploym ent Vice P resid en t F ran ces Figure 8.10: Composite Tree Layout com pact, vertically-positioned visualization. These two forms of visualization would not ! i be possible if GEDL did not provide for separate sets of constraints associated with each composite graphic. j i i i In order to produce a set of composites th at are capable of this organization chart j ■ layout, we must define two different composite types, a composite tree and a co m p act1 . tree. Figure 8.10 shows the composite tree layout used in C om posite-l-C om posite-7. The figure shows the kinds of constraints th at exist using this layout. This layout uses what are called blank boxes. A blank box is simply a place holder fo r, endpoints of line graphics. This allows lines to “bend.” 189; X-Equal Y-Before X-Before Y-Equal X-Equal Y-Before Y-Equal X-Equal Y-Before X-Before Y-Equal Staff T eresa Sydney Jim Blank Blank Blank Figure 8.11: Compact Tree Layout j Another technique used in this layout is constraints between box graphics and com- : i 1 i Iposite graphics. These are resolved in the same m anner as all other constraints, but the j I 1 I effect of updating the position of a composite is to change all of its members. ; One last im portant point relates to the role of line graphics in composite based layout. i I Line graphics (not shown in the figure) have no im pact on the positioning of box graphics j or composites. They may connect any box graphics including members of different com posites, as is done in this layout. Their endpoints are based on the final positions of the | I box graphics they connect. i Figure 8.11 shows the second composite graphic layout. This is a straight-forward use of constraints, box graphics with no borders, and blanks. I In both of these layouts, the solution of the entire set of constraints is quite fa s t' I since there are relatively few constraints in each composite. Most modifications to the graph d ata will only require modification to the constraints or box graphics in one or two 'composites. This implies th at only one or two sets of constraints will be solved. i j ! ' These two composite classes would be used to instantiate a tree of composites as is 1 (suggested by the bounding boxes in the figure. New graphic members would be added I i i |according to their relationship to the existing composites. | The net effect of including composite graphics is to support multiple layouts in a single I ! view and improve the performance of constraint solving by decomposing the constraint I graph into independent sets. t r 1 8.6 C o m m u n ica tio n i 'As was discussed in C hapter 1, the problem of providing a language which is both portable and which supports communication and control for external entities is hard. In GEDL, l the user is allowed to (1) define functions and objects which are external, and (2) control , : i editing operations from external events. In this section, I will examine the use of the GEDL approach in creating a communication and control link between the task-dependence graph i i i editor and the constraint graph editor/debugger. 1 I 8 .6 .1 E s t a b lis h in g C o m m u n ic a tio n i j The first problem for providing communication is to establish the communication link. 1 GEDL provides significant support for this by suggesting a client-server model with string- based names associated w ith the server. A server editor, such as the constraint graph editor, declares a name by which clients can connect to it. This is done in the editor options. For example, ) 191: o p tio n se r v e r "C onstraint"; I * The client editor also needs to declare its intent to act as a client and use th a t server | i process by including a declaration like: i I i o p tio n c l i e n t "C onstraint" ; i The client editor then simply needs to connect to the server through a call to the j (Connect function. This protocol currently only supports a single server process for any > I ! ! j client, but could easily be expanded to multiple different servers through m ultiple option ; J declarations and multiple, parameterized connect calls. ! I < t I I I ’ 1 8 .6 .2 C o m m u n ic a t io n P r o t o c o l ! . i 1 There are two modes of communication defined for the client-server communication path, I ' I | i auto-call and single message. In the auto-call mode, whenever a message is sent between , I ,the processes, the Handle function is invoked automatically. In the single message mode, | 1 i the process m ust explicitly request each additional message from the other process. I In the task-dependence to constraint graph editor communication, the auto-call mode 1 is used. This is established during the initiation of the connection by the task-dependence graph editor. The following operation is invoked when the user requests a connection , through the pull-down menu. command S ta r tC o n str a in tE d ito r i s ! fu n b o o l E xecute () = C onnect() SetA utoC lientO nO " 1 SetA utoServerO nO i end fun E xecute; 1 end command S ta r tC o n str a in tE d ito r ; Task-Dependence Graph Editor U ser-R eq u ested Modification "add ed g e A bs G raph View 'add ed g e C om posite "add c o n s tra in t... 'add e d g e ...' String-B ased Com m unication Path 'add c o n stra in t...' Constraint Graph Editor/Debugger View G raph O perations Function Call H andleC lientR equest(...) 'add e d g e ...' Figure 8.12: Communication Example ; The SetA utoC lientO n and SetAutoServerOn establishes the communication mode as j i . . . . . 1 iauto-call for both directions of communication. This means th at the operations implemen- I jtation of H a n d led ien tR eq u est will be invoked in response to a message from the client j I I to the server. This communication path is shown in Figure 8.12. In both the task-dependence and constraint graph editors, the im plem entation of the j ; Handle functions is external. Their implementation is simply to translate a string which j i I ' 1 , i | expresses a request for a delta into appropriate calls to the delta functions of the graph 'com ponent. The simplicity and symmetry of these functions suggest th at further automa- f tion of communication is possible, see Section 9.2. Overall, the communication between 'these processes is a string-based flow of deltas to the constraint graphs of the two editors. i I I | 8 .6 .3 E x t e r n a l C o n tr o l j 1 I , One of the interesting aspects of the GEDL implementation of communication is the ! ease w ith which external control can be established. In particular, since no main-loop is 1 ; specified within a GEDL specification, there is no code th at is required for alternate sources , i ■ of control. This is possible because all control flow Tesults in the invocation of functions in I t the operations irregardless of the source of those calls (user-interface or external entities). 1 j . f 8 .7 S u m m a ry The purpose of this chapter was to dem onstrate the use of GEDL in specifying graph edi tors. As GEDL is used, the viability of this dissertations solution to the problem of graph editor generation is dem onstrated. In other words, we can specify and generate interesting i examples of graph editors using GEDL as shown in the constraint graph editor/debugger 194 and the task-dependence graph editor. In addition to dem onstrating the overall usability of GEDL, this chapter presents the viability of individual solutions to component problems. The problem of specifying graph semantics is partially solved by adopting the rule-based approach exemplified in the connectivity semantics of GEDL. We have also seen th at this is greatly assisted by the ! ! 'availability of the type hierarchy and the fact th at obvious points such as AddEdge and j Commit exist for attaching semantic checking code. I 1 ( The solution to abstraction of treating it as a transform ation turns out to be both I straight-forward to use and implement. Composition abstraction in the task-dependence I i ;graph editor dem onstrates this fact. We also found in our experience with a process model j i ! 'editor th a t composition of abstraction was a useful mechanism. I j j Efficiently solving constraint graphs was a m ajor concern for the solution taken in | i ; I this dissertation. In the last chapter, I presented mechanisms for handling this issue, j Another issue is the usability of constraints in the specification of layout information. 1 J The im plem entation of various layout algorithms in example editors shows th at general | layout algorithms can be translated into constraint-based layout algorithms. Furtherm ore, because of the composite graphic construct, we can actually use multiple general layout algorithms within a single visualization. Finally, this chapter dem onstrates the use of the communication constructs. In par ticular, this chapter has presented the control and data communication used to provide a constraint graph debugger. 195 i I J C h a p ter 9 : i l t C o n clu sio n i I I ! The focus of this dissertation is finding a solution to the graph editor generation problem. I I However, in order to find a solution to this problem it is necessary to address several I !component problems including, data definition, abstraction, layout, and communication, j ! ( 1 j j This dissertation has identified a solution to the graph editor generation problem, j I 'nam ely designing a language and translator which can be used to specify and generate i i graph editors. While previous researchers have provided rule-based and gram m ar-based languages, the comprehensive language defined in this dissertation is a new approach. By , undertaking a comprehensive characterization of graph editing through this language, I j I . was forced to address each of the component problems. Previous research in this area addresses some, but not all of the component problems within a single framework. ! This work has provided several contributions to graph editing research and provides I considerable insight into where further research is needed. In the following sections, I ' briefly review these contributions and discuss future research topics which result from this work. 196 ;9.1 C o n trib u tio n s ^Experimentation with GEDL supports the m ajor claim of this dissertation, namely, it !is possible to develop a graph editor generator which addresses all of the component problems and produces working, effective graph editors. In particular, we have found ■that a solution to the problem based on a language for specifying and generating graph j : ! editors is a viable approach. The key aspect of this solution is identifying solutions to ; t 'th e component problems of d ata definition, abstraction, graphic object definition, layout j S and communication. Experim entation with GEDL suggests th at the solutions to these j j component problems presented in this dissertation are viable. | i * * I I While further research will undoubtedly improve the language design and implemen- i i | ta t ion, this dissertation has dem onstrated the feasibility of developing a comprehensive! : . . . . ! | graph editor generator. This result provides im portant contributions to fields of graph ; i , editing and graph editor generation. Particular contributions are discussed in the follow-; j ‘ ing sections. I 9 .1 .1 C h a r a c t e r iz a t io n o f G r a p h E d it o r G e n e r a tio n The main contribution of this research is a comprehensive characterization of graph editor > , generation through the design of a language for specifying and generating graph editors, i This provides several contributions to research in the problem area including, | • a definition of central requirements for graph editor generators and graph editors, • a mechanism for suggesting additional requirements and techniques in a meaningful way, namely as additional language concepts and constructs, 197 j • a basis for determining the correctness of im plem entation, and I j • a basis for comparing alternative approaches through the use of criteria in program- ! ming language design and user-interface design. I j I j Each of these benefits of characterization work towards the goal of understanding and | I further researching this field. We need this kind of treatm ent if we are ever to funda- t 'm entally understand graph editing and other kinds of tools. Until we attem pt to create ! j significant graph editors using graph editor generators, we can’t really understand the | 1 ! 'dom ain and its lim itations. Furthermore, as we discover new graph editing techniques, i | we need a mechanism to discuss and understand the im pact of the technique. I do not ) > i I ; | claim th a t the language presented in this dissertation and its translator is the best possible | : . ! graph editor generator. However, by pointing out weaknesses in GEDL and suggesting en- ( i | hancements, we prove the effectiveness of GEDL as a research and communication vehicle, a characterization of this domain. 9 .1 .2 V ie w T r e e A r c h it e c tu r e ' One of the most im portant design decisions made during the development of GEDL was the j overall architecture of domain-specific editors based on the view tree. This architecture , im pacts the capabilities of graph editors in a variety of ways. First, external entities ' can exist independent of the main editor code. Communication through propagation is I a natural and effective integration technique. This is also related to the choice of d e lta s; : as the update mechanism. Previous work suggested communication using external forms I i which require transmission of the entire set of data at each change. The use of small deltas j provides the basis for incremental updates throughout graph editors. 1 198, A second im pact of this architecture is support for multiple views of m ultiple abstrac- ' I | itions and the composition of abstractions. Both of these techniques support experimenta- j jtion and effective im plem entation of abstraction and viewing techniques. ^ ; I 9 .1 .3 D a t a D e f in it io n I I jD ata definition relates to three main issues, defining the types of vertices and edges, ! defining legal forms of graphs, and defining additional graph semantics. Defining the types of vertices and edges is supported in GEDL through specification of a hierarchy of I I j element types. ! | Defining legal forms of graphs in GEDL is done through a unique, hybrid approach th a t provides syntax-checking rules and defines exact points when they will be applied, i 1 Flexibility is achieved through the use of transactions to delay the global rule checks. In ' this way, operations can combine a set of deltas to form a single, syntactically-correct transform ation. Overall, this approach was found to be easy to use and effective for j I ; I , defining connectivity semantics. j Additional graph semantics must be defined using the functions associated with the graph component. GEDL assists in this by defining an expression language and providing obvious points to add these specifications. 9 .1 .4 A b s t r a c t io n 1 ' Previous work has suggested several powerful abstraction mechanisms. GEDL has intro- I duced an entirely new solution to abstraction in graph editor generators, namely treating. | abstraction as a transform ation. This solution means th at GEDL provides a generalized abstraction construct which can be used as the basis of defining and experimenting with I various abstraction techniques. The GEDL definition of abstraction as a transform ation also provides the basis for abstraction composition and multiple view of multiple abstrac- i i jtions. 9 .1 .5 G r a p h ic O b j e c t D e f in it io n This dissertation provides two key solutions to defining the graphic objects necessary for ■visualizing the graph, namely composition and looks. Composition is provided as a means * ,of building complex and interesting graphic objects from a relatively small set of primitive I 'graphics. Looks are provided to allow graphics to change their appearance without having I I i I I 'to tear-down and re-establish the associations with d ata domain objects. I I | 9 .1 .6 L a y o u t Once a set of graphic objects have been defined, the central problem for creating effective j visualizations of graphs is to place the pictures which represent the graph in a meaningful m anner. Since meaningful will vary from user to user, it is im portant to be able to integrate user, application and general layout information in determ ining final positions. | The solution taken in this work is to use a single constraint language for expressing each ’ source of positioning information. The most im portant issue that results from this approach is finding an efficient con straint solver. The constraint graph solution mechanism and the results of using the translator’s constraint graph solver dem onstrate th at constraints can be efficiently solved. i i While the solution of constraint graphs is a contribution by itself, a more im portant J contribution of the work on the GEDL translator was the increm ental algorithm for solving ■ constraint graphs. This algorithm not only significantly improves the performance of the ' constraint solver, but it actually is able to satisfy a larger set of constraints than the ' non-increm ental algorithm while m aintaining the prioritization. Another im portant, but i negative, contribution was the finding th at incremental positioning is generally a poor ! alternative unless stability is a critical concern. Even then, there is a good possibility of j !other approaches yielding more effective solutions. : i ! I Another contribution is the use of independent sets of constraints through the com- j | ; jposite graphic construct. This provides the possibility of very efficient layout algorithms 1 i i i which use composition. Messinger [38] has shown th at composition-based layout can be ; ; i I efficient and effective in visualizing large graphs. | A final contribution towards solving the layout problem is th a t the solution presented ; in this dissertation allows for multiple general layout algorithms within a single view, j 1 i I ; These layouts can operate independent of each other. Recent work by Henry [20] sug- | t gests th a t multiple layouts within a visualization is im portant for understandability. The ! composition-based solution of layout provides a means of further exploring H enry’s thesis, j i | 9 .1 .7 C o m m u n ic a t io n ■ The communication problem is th at we need to create graph editors which exist as p art of a larger system. The solution provided in this dissertation is to allow the editor specifier to create external functions and objects and to provide functions which can be used to ' establish and control the communication paths. This solution provides a basis for creating complex communication, as exemplified in the constraint graph editor/debugger. i i9.2 F u tu re R esea rch T opics i i j W hile the prim ary contribution of this work is providing solutions to the problem area, it also makes a contribution by re-defining the problem based on our experience. As we ; ! \ i gained experience with designing GEDL, its translator and example editors, we found new j 'problem s th at also should be addressed. In the following sections, I briefly introduce some of these problems and other possible future research topics. 9 .2 .1 L a y o u t The effectiveness of the constraint solution presented in this dissertation is somewhat j j m itigated by the level of effort required to develop layout algorithms using constraints. It [ ! i is not also easy to effectively implement known layout algorithms using constraints. One candidate solution for further research is to consider higher level constructs which can be , 1 ; used to easily build layout algorithms. These constructs might still have constraints as I their eventual im plem entation and integration technique. This area is also ripe for study on the effect of integrating various layout techniques using constraints. j I 9 .2 .2 T o o l A r c h it e c t u r e We feel th a t the view tree architecture provides many of the necessary attributes of tool architectures suggested by various work including M eta-environments [29], process-models l [16, 8], tool communication environment [58], and frameworks [59]. Each of these other < . research efforts require integration of the tool with other components and control from. ! I 202' external sources. I J This architecture might also serve as the basis of designing components which can ■be inserted into the view tree framework to form new editors. For example, composition r abstraction might be a separate component th at could be inserted in a variety of situations. J This is similar to the Unix approach to tool composition. i j Another area th at would be interesting to study is multi-user collaboration and dis trib u tio n . The view tree architecture is ideal for pursuing both collaborative graph editor I ^generation and distributed graph editor generation. Furtherm ore, the architecture might I | • be applicable to other kinds of tools and even as the basis for environment creation as i I | suggested in [29]. 1 9 .2 .3 G E D L P a r a d ig m i The overall approach to the problem of graph editor generation suggested by this disser tation is one of language design. There is some question as to whether this introduces a i new paradigm of languages. We are particularly interested in pursuing other kinds of tools using the language design approach used in creating GEDL. 203 R efere n c e L ist ! [1] Adobe Systems, Inc. PostScript: Language Reference Manual. Addison-Wesley Pub- j lishing Company, 1985. ! [2] A. Aho, J. Hopcraft, and J. Ullman. The Design and Analysis o f Computer Algo rithms. Addison-Wesley Publishing Company, 1974. [3] Paul S. Barth. An Object-Oriented Approach to Graphical Interfaces. A C M Trans actions on Graphics, 5(2): 142-172, April 1986. [4] Carlo Batini, Enrico Nardelli, and Roberto Tamassia. A layout algorithm for data flow diagrams. IE E E Transactions on Software Engineering, SE-12(4):538-546, April 1986. [5] Brigham Bell. Using Programming Walkthroughs to Design a Visual Language. PhD ; thesis, University of Colorado-Boulder, Departm ent of Com puter Science, February j 1992. ! [6] Karl-Friedrich Bohringer and Frances Newbery Paulisch. Using constraints to achieve stability in autom atic graph layout algorithms. In Proceedings o f the SIG C H I (Special Interest Group Computer Human Interaction) ’90, Seattle, WA, April 1-5 1990. [7] Glenn Bruns. Germ: A M etasystem for Browsing and Editing. Technical Re port MCC Technical Report STP-122-88, M CC/Software Technology Program , ! Austin, X, April 12 1988. ' [8] R. F. Bruynooghe, J. Parker, and J.S. Rowles. PSS: a system for process enact- I ment. In Proceedings of the First International Conference on the Software Process, . pages 128-141, 1991. j [9] Song C. Choi. SO FTM AN : A n Environment Supporting the Engineering and Reverse ■ Engineering of Large Scale Software Systems. PhD thesis, University of Southern ( California, February 1989. I [10] Roger B. Dannenberg. A structure for efficient update, increm ental redisplay and, undo in graphical editors. Software Practice and Experience, 20(2):109-132, February 1990. [11] V. Donzeau-Gouge et al. Programming Environments Based on Structured Editors: The Mentor Experience. In David Barstow, Howard Shrobe, and Erik Sandewall, editors, Interactive Programming Environments, pages 128-140, McGraw Hill Book ■ Co., New York, 1984. I 204 j[12] P. Eades. A heuristic for graph drawing. Congressus Numeratium, 42:149-160, 1984. [13] Peter Eades and Roberto Tamassia. Algorithms fo r Autom atic Graph Drawing: An Annotated Bibliography. Technical Report CS-89-09 (Revised Version), Brown Uni versity, D epartm ent of Computer Science, Providence, RI, October 1989. I i j I [14] H artm ut Ehrig. Tutorial introduction to the algebraic approach of graph grammars. | In Proceedings of the 3rd International Workshop on Graph Grammars and Their i Applications - Lecture Notes in Computer Science 291, pages 3-14, Springer-Verlag, 1986. ; i i [15] Gregor Engels. Elementary actions on an extended entity-relationship database. In Proceedings o f the fth International Workshop on Graph Grammars and Their A p plications - Lecture Notes in Computer Science 532, pages 344-362, Springer-Verlag, M arch 1990. : [16] E SF Technical Reference Guide. ESF - Eureka Software Factory, 1989. '[17] E.R. Gansner, S. C. North, and K. P. Vo. DAG: a program th at draws directed graphs. Software—Practice and Experience, 18(11):1047-1062, November 1988. [18] M. R. Garey and D. S. Johnson. Crossing number is NP-complete. S IA M Journal on | Algebraic and Discrete Methods, 4(3):312-316, September 1983. I [19] H erbert Gottler. Graph grammars and diagram editing. In Proceedings of the 3rd International Workshop on Graph Grammars and Their Applications - Lecture Notes ' in Computer Science 291, pages 216-230, Springer-Verlag, December 1986. j ; [20] Tyson Rombauer Henry. Interactive Graph Layout: The Exploration of Large Graphs. , PhD thesis, Dept, of Com puter Science, University of Arizona, Tucson, July 1992. , t ! [21] Michael Himsolt. Graphed : an interactive tool for developing graph grammars. ] In Proceedings of the 4th International Workshop on Graph Grammars and Their ■ Applications - Lecture Notes in Computer Science 532, pages 61-65, Springer-V erlag,: M arch 1990. 1 i ' [22] David S. Johnson. The NP-completeness column: an ongoing guide. Journal o/; ; Algorithms, 0(3):381-395, December 1982. [ [23] David S. Johnson. The NP-completeness column: an ongoing guide. Journal of Algorithms, 0(3):89-99, March 1982. [24] S. C. Johnson. YACC: Yet Another Compiler Compiler. Bell Laboratories Computing Science Technical Report 32, July 1975. [25] W .L. Johnson. Deriving specifications from requirements. In Procee.dings of the 10th International Conference on Software Engineering, pages 428-437, 1988. [26] W .L. Johnson, M artin S. Feather, David R. Harris, and Kevin M Benner. Represen tation and presentation of requirements knowledge. October 1991. USC-ISI Report. 205 [27] Anthony S. Karrer. Gedl reference manual. March 1993. Loyola M arymount Univer- ] : sity. j j [28] Anthony S. K arrer. Language design using autom ated specialization. March 1993. , j Loyola M arymount University. j |[29] Anthony S. K arrer and Walt Scacchi. M eta-environments for software production. In- > ternational Journal o f Software Engineering and Knowledge Engineering, 3(1), March 1993. ![30] Anthony S. K arrer and W alt Scacchi. Requirements for an Extensible Object-Oriented j T ree/G raph Editor. In A C M SIG G RA PH Symposium on User-Interface Software and j Technology, pages 84-92, October 1990. I [31] Rudolph Keller et al. Chiron-1 : A User Interface Development System Tailored to ' Software Environments. Technical Report T R UCI-90-06, Dept, of Inform ation and ! Com puter Science, University of California, Irvine, June 1990. j 1 [32] S tarrett C. Kennedy. Engineering Development of Computer Languages. A C M SIG- j ^ P L A N Notices, 22(3):49-58, March 1987. ! 1 [33] Brian W. Kernighan. PIC: a language for typesetting graphics. Software—Practice ! | and Experience, 12(1):1-21, December 1982. j :[34] M. E. Lesk and E. Schmidt. Lex - A Lexical Analyser G enerator. Bell Laboratories | \ Computing Science Technical Report 39, October 1975. I ,[35] M ark A. Linton, John M. Vlissides, and Paul R. Calder. Composing User Interfaces ; with Interviews. Computer, 22(2):8-22, February 1989. ; [36] John H. Maloney, Alan Borning, and Bjorn N. Freeman-Benson. Constraint technol ogy for user-interface construction in ThingLab II. In Proceedings of the Conference on Object-Oriented Programming Systems, Languages and Applications, pages 381- 1 388, O ctober 1989. j 1 [37] Stefano Mannucci, Bruno M ojana, et al. Graspin: a structured development environ- ! m ent for analysis and design. IE EE Software, 6(6):35-43, November 1989. ( [38] Eli Benjamin Messinger. Automatic Layout o f Large Directed Graphs. PhD thesis, j University of W ashington, Departm ent of Com puter Sciences, July 1989. T R Number , 88-07-08. I [39] P. Mi and W. Scacchi. Process integration for case environments. IE E E Software, 9(2), March 1992. [40] I. Miyamoto. A prototyping tool for graphical software engineering tools. A C M SIG SO F T Software Engineering Notes, 12(4):45-51, October 1987. [41] Manfred Nagl. A tutorial and bibliographical survey on graph grammars. In Proceed ings o f the 1st International Workshop on Graph Grammars and Their Applications - Lecture Notes in Computer Science 73, pages 70-126, Springer-Verlag, 1979. t 206 I [42] David Notkin. The GANDALF Project. The Journal o f System s and Software, 1 5(5):91-105, May 1985. '[43] Object Graphics fo r C++. W hitewater, 1991. [44] Frances Newbery Paulisch and W alter F. Tichy. EDGE: An Extendible Graph Editor. Software Practice and Experience, 20(S 1):63 - 88, June 1990. [45] P.P.Chen. The entity-relationship model: toward a unified view of data. A C M Trans actions on Database System s, March 1976. [46] L. Beth Protsko, Paul G. Sorenson, J. Paul Tremblay, and Douglas A. Schafer. Gener- j ation of software diagrams. IE E E Transactions on Software Engineering, 17(1):1-21, j January 1991. ,[47] Thom as Reps and Tim Teitelbaum. The Synthesizer Generator. In Proceedings o f the A C M SIG SO F T /SIG P L A N Software Engineering Symposium on Practical Software Development Environments, April 1984. i i [48] D. M. Ritchie and K. Thompson. The Unix Time-Sharing System. Communications I of the ACM , July 1974. [49] Gabriel Robins. The ISI Grapher: A Portable Tool for Displaying Graphs Pictorially. In Symboliika ’81, pages 1-18, August 1987. [50] Lawrence A. Rowe, Michael Davis, EH Messinger, Carl Meyer, Charles Spirakis, and Allen Tuan. A browser for directed graphs. Software—Practice and Experience, 17(1):61— 76, January 1987. [51] R obert W. Scheifler and Jim Gettys. The X window system. A C M Transactions on ' Graphics, 5(2):79-109, April 1986. j [52] R. S. Scowen. Babel and SOAP: applications of extensible compilers. Software— ! Practice and Experience, 3(l):15-28, January 1981. j [53] Ben Shneiderman. Direct manipulation: a step beyond programming languages. IE E E Computer, 16(8):57-69, August 1983. [54] Richard Stallman. EMACS: the extensible, customizable self- docum enting display editor. In Proceedings o f the A C M Sigplan/SIGOA Symposium on Text Manipulation, June 1981. [55] J. A. Storer. On minimal-cost planar embeddings. Networks, 14(2):109-125, 1984. [56] Kozo Sugiyama, Shojiro Tagawa, and Mitsuhiko Toda. M ethods for visual under standing of hierarchical system structures. IE E E Transactions on Systems, Man, and< Cybernetics, SMC-11(2):109-125, February 1981. [57] R oberto Tamassia, Guiseppe Di B attista, and Carlo Batini. A utom atic graph drawing and readability of diagrams. IE E E Transactions on Systems, Man, and Cybernetics, 18(1):61— 79, Jan/F eb 1988. 207, ; [58] George Tatge. HP SoftBench. In FedCASE ’89, 1989. " j [59] Ian Thom as. PC TE interfaces: supporting tools in software engineering environments, i j IE E E Software, November 1989. ^ i [60] John M. Vlissides. Generalized Graphical Object Editing. PhD thesis, Stanford Uni- i ! versity, 1990. [61] Anthony I. W asserman and Peter A. Pircher. A graphical, extensible integrated i environment for software development. In Proc. A C M S IG SO F T /SIG P L A N Software , Engineering Symposium on Practical Software Engineering Environments, pages 131- i i 142, December 1986. i '[62] N. W irth. From m odula to oberon. Software— Practice and Experience, 18(7), July | 1988. j [63] Bradley T. Vander Zanden. A n Incremental Planning Algorithm fo r Ordering Equa- ' tions in a Multilinear System of Constraints. Technical Report 88-910, D epartm ent of Com puter Science, Cornell University, April 1988. I I » 208 F l } I A p p e n d ix A G E D L L an gu age S y n ta x an d D efin itio n s | This appendix contains a description of the full GEDL syntax, the full GEDL class hiearchy and the minimum set of pre-defined constants, functions and attributes. This is intended to provide a more in depth specification than in described in Chapters 4-6. A .l F u ll G E D L S y n ta x The following EBNF (extended Backus-Naur form) description of GEDL gives the full syntax of the language. In this EBNF description, non-terminals are surrounded by < > and are uppercase letters. Terminals are in lowercase letters. '<BINARY_0P> ::= ’+> I | >*’ I > /’ I ’* * ’ I ,=J t ’ <’ I ’ > ’ j | ’ < = ’ | ’ > = ’ | >!=> | ’&&’ | ’ || > . <UNARY_0P> ::= ’ + ’ I I » !» <EXP> ::= <EXP> <EXP> I l e t <VARIABLE_DECLARATION_LIST> in <EXP> end l e t I i f <EXP> th en <EXP> [ e l s e <EXP> ] end i f I f o r a l l <VARIABLE_DECLARATION> in <EXP> su ch th a t <EXP> end f o r a l l I e x i s t s <VARIABLE_DECLARATION> in <EXP> su ch th a t <EXP> end e x i s t s I fin d o n e <VARIABLE_DECLARATION> in <EXP> su ch th a t <EXP> end fin d o n e I f i n d a l l <VARIABLE_DECLARATION> in <EXP> su ch th a t <EXP> end f i n d a l l I <C0NSTRAIMT_0P> I <AT0MIC_0P> I <N0NAT0MIC_0P> I <EXP> <BINARY_0P> <EXP> I <UNARY_0P> <EXP> I ’ ( ’ <EXP> » ) ’ I <ID> I <ID> as <ID> I <C0NSTANT> I [ <ID> ] <ID> »(» [ <EXP> { ’ f » <EXP> >* ] » ) ’ 1 v o id I s e t [ <EXP> ’ .* ] <ID> to <EXP> end s e t 209 | I g e t [ <EXP> *.» ] <ID> ! | d etach <EXP> from <EXP> end d etach j I add <EXP> to <EXP> end add ; | new <ID> [ a sso c <EXP> ] j | new <ID> <EXP> ’ ,» <EXP> I abort tr a n s a c tio n j | s t a r t tr a n s a c tio n <ID> i | commit tr a n s a c tio n <ID> I <EXP> i s a <ID> I <EXP> s u b c la s s o f <ID> i <AT0MIC_0P> ::= atom ic add boxgraphic <EXP> I atom ic add lin e g r a p h ic <EXP> I atom ic add com posite grap h ic <EXP> j I atom ic touch grap h ic <EXP> j | atom ic d e le te grap h ic <EXP> I I atom ic add v e r te x <EXP> i . I atom ic add edge <EXP> I atom ic d e le te v e r te x <EXP> I atom ic d e le te edge <EXP> I atom ic touch v e r te x <EXP> I atom ic touch edge <EXP> <N0WAT0MIC_0P> ::= add v e r te x <EXP> I add edge <EXP> I d e le t e v e r te x <EXP> I d e le t e edge <EXP> I tou ch v e r te x <EXP> I tou ch edge <EXP> <CONSTRAINT_QP> ::= add c o n s tr a in t <DIM> <EXP> <CONSTRAINT_TYP> <EXP> * ,' <EXP> [ ’ , ’ <EXP> ] I d e le te c o n s tr a in t <EXP> I d e le te c o n s tr a in t [ <CONSTRAINT_TYP> ] <EXP> , <EXP> <CONSTRAINT_TYPE> ::= b e fo r e I c e n te r I neighbor I equal I le ftm a r g in I righ tm argin I range <DIMENSIQN> ::= x | y <VARIABLE_DECLARATION> ::= <ID> ’ <TYPE> [ ’= ’ <EXP> ] <VARIABLE_DECLARATION_LIST> ::= { <VARIABLE_DECLARATION> »;» > + <FUNCTION_DECLARATION> ::= 210 C e x te r n a l ] fun <TYPE> <ID> ’ ( ’ [ <ID> : <TYPE> { »,» <ID> : <TYPE> >* ] *) I fu n <TYPE> <ID> ’ ( ’ [ <ID> : <TYPE> { <ID> : <TYPE> }* ] ’ ) ’ = ’ <EXP> end fu n <ID> »;» <TYPE> ::= l i s t o f <TYPE> I in t | b o o l | s t r in g | f l o a t I v o id I <ID> i<0PTI0N> ::= o p tio n se r v e r <C0NSTANT> j | o p tio n c l i e n t <C0NSTANT> ’ ; ’ i I o p tio n cdebug ’ ; ’ I o p tio n in crem en ta l on ’ ; ’ I o p tio n in crem en ta l o f f ’ ; ’ <CONSTANT_DEFN> ::= co n sta n t <ID> <TYPE> <EXP> 5 <EDIT0R> ::= e d ito r <ID> i s ; <0PTI0N>* <CONSTANT_DEFN>* <ATTRIBUTE_DEFW> <FUNCTION_DECLARATION>* <DATA_DEFW > <ABSTRACTION_DEFN>* <GRAPHICS_DEFN> <DPERATIOMS_DEFW > end e d ito r <ID> ’ ; 5 <DATA_DEFN> ::= <VERTEX_DEFN>* <EDGE_DEFN>* <G RAPH _DEFW > <VERTEX> ::= v e r te x <ID> [ i s a <ID> ] IS [ <PERSISTENCE> [ a t t r ib u t e s [ e d ita b le ’ :* <ATTRIBUTE_DEGL>* ] [ p r iv a te ’ : ’ <ATTRIBUTE_DECL>* ] end a t t r ib u t e s ’ ; ’ ] end v e r te x <ID> * ; ’ <PERSISTEMCE> ::= p e r s is t e n t I sa v ea b le | | v o l a t i l e <EDGE> ::= edge <ID> [ is a <ID> ] IS [ <PERSISTEMCE> ] | [ a t t r ib u t e s [ e d ita b le ’ : ’ <ATTRIBUTE_DECL>* ] [ j p r iv a te ’ : 5 I <ATTRIBUTE_DECL>* ! ] end a t t r ib u t e s ’ ; ’ ] end edge <ID> ’ ; ’ <ATTRIBUTE_DECL> ::= <ID> <TYPE> <GRAPH > ::= e x te r n a l graph <ID> I graph <ID> [ is a <ID> ] i s i <COMNECTIVITY> [ a t t r ib u t e s : <ATTRIBUTE_DECL>* end a t t r ib u t e s 5; 5 : ] | <FUWCTION_DECLARATION>* end graph <ID> * ;* <CQNNECTIVITY> ::= c o n n e c tiv ity i s lo c a l r u le s 5: ’ <EDGE_CONNECT_RULE>* g lo b a l r u le s » : ’ <GLOBAL_CONNECT_RULE>* end c o n n e c tiv ity ’ ; ’ <EDGE_CONNECT_RULE> ::= <ELEMENT_LIST> »:» <ELEMEWT_LIST> »->' <ELEMENT_LIST> * : ’ <C ARD > <CARD> ::= »*» I 1 <ELEMENT_LIST> ::= * *» I <ID> -CM’ <ID> >* 212 !<GLOBAL_CONNECT_RULE> <GLOBAL_TYPE> | <ELEMENT_LIST> ’ , ’ i <ELEMENT_LIST> ’ ;» I f '<GLOBAL_TYPE> ::= D A G I TREE i <ABSTRACTIOW > e x te r n a l a b s tr a c tio n <ID> I a b s tr a c tio n <ID> [ i s a <ID> ] i s <CONNECTIVITY> ! [ , a t t r ib u t e s ' <ATTRIBUTE_DECL>* 1 end a t t r ib u t e s * ; ’ I ] ; <FUNCTION_DECLARATION>* t end a b s tr a c tio n <ID> ’ ;5 i<GRAPHICS_DEFN> ::= <GRAPHIC>* ; <COMPOSITE_GRAPHIC>* j <VIEW>* ! i<VIEW> ::= e x te r n a l view <ID> | | view <ID> [ is a <ID> ] i s grap h ic <ID> ’ i E ! a t t r ib u t e s <ATTRIBUTE_DECL>* end a t t r ib u t e s 1; 5 ] <FUNCTION_DECLARATION>* end view <ID> ’ ; ’ ■ <GRAPHIC> ::= lin e g r a p h ic <ID> [ i s a <ID> ] i s [ a t t r ib u t e s < ATTRIBUTE.DECL > * end a t t r ib u t e s 5; ’ ] <LINE_L00K>* end lin e g r a p h ic <ID> ’ ; 1 | boxgraphic <ID> [ is a <ID> ] i s c a ttr ib u te s <ATTRIBUTE_DECL>* j end a t t r ib u t e s ’ ; ’ I ] , <BOX_LOOK>* ! end boxgraphic <ID> ’ ; ’ <COMPOSITE_GRAPHIC> ::= com p osite g rap h ic <ID> [ i s a <ID> ] i s [ a t t r ib u t e s < ATTRIBUTE _DE C L > * i end a t t r ib u t e s ’ ; ’ i ] ! <FUNCTION_DECLARATION>* ; end com posite grap h ic <ID> 5; ’ I I !<B0X_L00K> ::= lo o k <ID> IS <B0X> end look <ID> * | I<LINE_L00K> ::= lo o k <ID> IS <LINE> [ <B0X> ] end lo o k <ID> I ■ <B0X> ::= hbox [ <B0RDER> ] <BOX_ELEMENT>* end hbox I | vbox [ <B0RDER> ] <BOX_ELEMENT>* end vbox ■ <B0RDER> ::= border [ <PATTERN> ] [ <BRUSH> ] [ c o lo r <C0L0R> ] <BOX_ELEMENT> : <TEXT> I <BITMAP> I <SPACE> I <LINE> I <B0X> <PATTERN> ::= c le a r I gray I b lack <BRUSH> ::= brush <LINESTYLE> <EXP> »;» ;<LINESTYLE> ::= s o lid I dashed I d o tte d ' <C0L0R> ::= b la ck I b lu e I green I red I cyan I m agenta I y e llo w I <C0ISTANT> 1 <TEXT> ::= t e x t <TEXT_STYLE> <TEXT_VALUE> ’ <TEXT_STYLE> ::= normal I b o ld I u n d e r lin e I grayed I in v e r te d ■ <TEXT_VALUE> ::= a t t r ib u t e <ID> I <C0NSTANT> <BITMAP> ::= bitmap <ID> ’ ; 5 ! <SPACE> ::= space <C0NSTANT> c --------------------— “ — -----------------------------------------------------------------------------------1 i<LINE> ::= l i n e <BRUSH> [ c o lo r <C0L0R> ] [ arrowhead ] | ! I ;<OPERATIONS_DEFN> ::= o p e r a tio n s | ; c a t t r ib u t e s <ATTRIBUTE_DECL>* I end a t t r ib u t e s * ; ’ ] <FUNCTION_DECLARATIQN>* < OPERATIONS <M ENU>* end o p e r a tio n s ’ ; ’ <M EN U > ::= menu <ID> <C0NSTANT> [ checked ] i s <M ENU_ELEM ENT>* I end menu <ID> ’ ; ’ ;<M EN U _ELEM EW T> ::= <ID> <C0NSTANT> I SEPARATOR <ID> » ; 5 I <0PERATI0N> ::= command <ID> C is a <ID> ] i s j <FUNCTION_DECLARATION>* i end commeind <ID> ’ ; ’ 1 | t o o l <ID> [ is a <ID> ] i s <BITMAP> <FUMCTIQN_DECLARATION>* end t o o l <ID> ’ ; ’ A .2 G E D L C lass H ierarch y The GEDL language is based on the specialization of various classes within the specification language. The full set of classes th at are defined as part of GEDL are as follows (note that indentation indicates subclass relationship with the previous class): O bject S ta te Component E d ito r Graph C onstraintM anager ViewTree A b str a c tio n View O perations O peration 215 , Command Tool Element I V ertex I ; View TreeVertex \ [ G C onstraintV ertex ' t GBoxGraphicVertex I GDimensionedVertex I GCenterVertex GRangeVertex ; Edge l GConstraintEdge I GRangeEdge I GBeforeEdge GCenterEdge j GEqualEdge i GNeighborEdge > GMarginEdge Graphic j Box i L ine I I I Com posite j I I , A .3 P re -D efin ed C o n sta n ts, F u n ctio n s, an d A ttr ib u te s , The following constants must be pre-defined in any GEDL translator im plem entation. j ? C on stan ts: XDIM : in t = 0 YDIM : in t = 1 The following functions over the corresponding class must be pre-defined in any GEDL j translator implementation. F u n c tio n s: E lem en t: l i s t o f Element G etA ssociatedW ithO l i s t o f Elem ent G etA ssocO E dge: V ertex G etF irstV ertex O V ertex G etSecondV ertex G raph ic: in t GetXPosQ in t GetYPosQ 216 v o id O ffse tX P o s(in t) v o id O ffse tY P o s(in t) v o id S e tX P o s(in t) v o id S e tY P o s(in t) L ine: Box G etF irstB oxO Box GetSecondBoxQ Component: l i s t o f Graphic G etS elected G rap h icsQ Component G etA ssociatedC om ponent() S ta te G etS ta teO Graph GetGraphO ViewTree GetViewTreeO b o o l Member(Element) s t r in g I t o S t r ( in t ) v o id E r r o r (str in g ) Graph: l i s t o f V ertex G e tV er ticesO l i s t o f Edge G etEdgesO l i s t o f V ertex G etP red ecesso rs(V ertex ) l i s t o f V ertex G e tS u ccesso rs(V ertex ) l i s t o f Edge G etln cid en tE d g es(V ertex ) l i s t o f Edge G e tln cid en tE d g esT h isF irst(V ertex ) l i s t o f Edge G etln cid en tE d gesT h isS econ d (V ertex) in t G etN um C onnections(V ertex, V ertex ) V iew : Compos i t eG raphic GetRootO v o id S e tC a p tio n (str in g ) V iew T ree: v o id AddView(View,Component) v o id A ddA bstraction(A bstraction,C om ponent) V iew TreeV ertex GetViewVertex(Component) Component GetComponent(ViewTreeVertex) View GetCurrentViewO Elem ent GetAssociatedGraphD at a (Elem ent) O peration: S ta te G etS ta teO Graph GetGraphO O perations G etO perationsO ViewTree GetViewTreeO v o id SetA utoServerO nO v o id SetA utoS erverO ffO v o id G etW extC lientD ataO v o id H a n d leC lien tR e q u est(strin g ) v o id S en d T oC lien t() v o id SetA utoC lientO nO v o id S etA u to C lien tO ff() v o id G etN extServerD ataO v o id H a n d leS erv erR eq u est(strin g ) v o id SendToServerO v o id C onnect() l i s t o f Graphic G etS elected G rap h icsQ v o id E r r o r (str in g ) O p er a tio n s: S ta te G etS ta teO Graph GetGraphO ViewTree GetViewTreeO l i s t o f Graphic G etS elected G rap h icsO v o id SetA utoServerO nO v o id S etA u toS erverO ff0 v o id G etN extC lientD ataO v o id H a n d leC lien tR e q u est(strin g ) v o id SendT oC lient() v o id SetA utoC lientO nO v o id S etA u to C lien tO ff() v o id G etN extServerD ataO v o id H an d leS erv erR eq u est(strin g ) v o id SendToServerO v o id C onnect() v o id E r r o r (str in g ) C om positeG raphic: C onstraintM anager GetCMQ l i s t o f Graphic GetMembersO l i s t o f L ine G etL ineG raphicsQ l i s t o f Box G etBoxG raphicsO C onstraintM anager: C o n stra in tV ertex G etA ssociated V ertex(G rap hic) C en terV ertex G e tC en terV ertex (C o n stra in tV ertex ,C o n stra in tV ertex ) v o id S etIn c r e m e n ta l(b o o l) v o id S o lv e () C o n str a in tV e r te x : Graphic G etA ssociated G rap h ic() C on stra in tE d g e: in t G e tP r io r ity O v o id S e t P r io r it y ( in t ) S ta te : in t GetMouseXO in t GetMouseYO b o o l M od ified O The following is a list of the attributes which must be defined for the pre-defined GEDL classes. A t t r ib u t e s : C on stra in tE d g e: in t Dim 219 iA p p en d ix B C o n stra in t G rap h E d ito r /D e b b u g g e r :This chapter contains the full source for the constraint editor/debugger. I — C onstraintG raphE ditor/D ebugger - i ” i — T his e d ito r im plem ents th e in crem en tal c o n s tr a in t graph s o lu t io n . !— I t a ls o s e r v e s as a debugger f o r o th er e d it o r s . I t d o e sn ’t add !- - any la y o u t in fo rm a tio n . I t r e l i e s on th e o th er e d ito r to p ro v id e i - - la y o u t in th e U serView, or th e e d ito r u s e r . i - - Author: A. Karrer D ate: 1 /1 6 /9 3 - - GEDL: v 0 .5 0 - - R e v isio n s: e d ito r C onstraintG raphE ditor i s : o p tio n se r v e r "C onstraint"; — D im ensions c o n sta n t XConst : in t = 0; c o n sta n t YConst : in t = 1; c o n sta n t CenterC onst : in t = 0 c o n sta n t B eforeC onst : in t = 1 c o n sta n t N eighborC onst : in t = 2 c o n sta n t EqualConst : in t = 3 c o n sta n t MarginConst : in t = 4 c o n sta n t RangeConst : in t = 5 co n sta n t AnyConst : in t = 6 — — * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * — — D ata/Graph D e fin itio n s 220 v e r te x C o n stra in tV ertex i s p r iv a te : Num : in t ; — Unique i d e n t i f i e r from o th e r apps end v e r te x C on strain tV ertex; v e r te x BoxG raphicVertex is a C o n strain tV ertex i s sa v ea b le e d it a b le : Kind : s tr in g ; - - la b e ls g ra p h ics from o th er apps p r iv a te : XPos : i n t ; YPos : i n t ; S olved : b o o l; end v e r te x BoxG raphicVertex; v e r te x D im ensionedV ertex i s a C o n strain tV ertex i s p r iv a t e : Dim : in t ; end v e r te x D im ensionedV ertex; v e r te x C enterV ertex i s a D im ensionedV ertex i s p r iv a te : S olved : b o o l; end v e r te x C enterV ertex; v e r te x RangeVertex is a D im ensionedV ertex i s e d it a b le : S ta r t : in t ; End : i n t ; end v e r te x RangeVertex; v e r te x L eftM arginV ertex is a D im ensionedVertex i s end v e r te x L eftM arginV ertex; v e r te x R ightM arginV ertex i s a D im ensionedV ertex i s end v e r te x R ightM arginV ertex; — Edge Types edge C onstraintE dge i s p r iv a te : Dim : i n t ; Num : i n t ; end edge C onstraintE dge; edge GraphicEdge i s a C onstraintE dge i s sa v ea b le p r iv a t e : 221 Kind : s tr in g ; end edge GraphicEdge; edge HighLevelEdge i s a C onstraintE dge is e d ita b le : P r io r it y : i n t ; p r iv a t e : C o n tr a d icts : l i s t o f HighLevelEdge; A sserted : b o o l; LowLevel : C on strain tE d ge; end edge HighLevelEdge; edge CenterEdge is a HighLevelEdge i s end edge CenterEdge; edge RangeEdge is a HighLevelEdge i s end edge RangeEdge; edge MarginEdge i s a HighLevelEdge i s end edge MarginEdge; edge NeighborEdge is a HighLevelEdge i s end edge NeighborEdge; edge EqualEdge is a HighLevelEdge i s end edge EqualEdge; edge BeforeEdge i s a HighLevelEdge i s end edge BeforeEdge; edge LowLevelEdge is a C onstraintE dge i s p r iv a t e : H ighL evel : HighLevelEdge; end edge LowLevelEdge; edge IGTEdge i s a LowLevelEdge i s end edge IGTEdge; edge GTEdge i s a LowLevelEdge i s end edge GTEdge; edge EQEdge i s a LowLevelEdge i s end edge EQEdge; edge NEEdge i s a LowLevelEdge i s end edge NEEdge; edge CNTREdge i s a LowLevelEdge i s end edge CNTREdge; edge ATEdge i s a LowLevelEdge i s end edge ATEdge; graph C onstraintG raph i s c o n n e c tiv ity i s l o c a l r u le s : GraphicEdge : BoxGraphicVertex -> BoxGraphicVertex : one; CenterEdge : BoxGraphicVertex -> C enterV ertex : many; CenterEdge : C enterV ertex -> BoxGraphicVertex : many; RangeEdge : BoxGraphicVertex -> RangeVertex : many; MarginEdge : BoxGraphicVertex -> L eftM arginV ertex I R ightM arginV ertex : many; NeighborEdge : BoxGraphicVertex -> BoxG raphicVertex : many; EqualEdge : BoxGraphicVertex -> BoxG raphicVertex : many; BeforeEdge : BoxGraphicVertex -> BoxG raphicVertex : many; IGTEdge : BoxGraphicVertex -> BoxG raphicVertex : many; GTEdge : BoxGraphicVertex -> BoxG raphicVertex : many; EQEdge : BoxGraphicVertex -> BoxG raphicVertex : many; NEEdge : BoxGraphicVertex -> BoxG raphicVertex : many; CNTREdge : BoxGraphicVertex -> C enterV ertex : many; CNTREdge : C enterV ertex -> BoxGraphicVertex : many; ATEdge : BoxGraphicVertex -> RangeVertex : many > g lo b a l r u l e s : t r e e : BoxGraphicVertex , GraphicEdge ; t r e e : C enterV ertex I BoxGraphicVertex , CenterEdge ; t r e e : C enterV ertex | BoxGraphicVertex , CNTREdge ; end c o n n e c tiv ity ; a t t r ib u t e s S ep a ra tio n : in t ; Num : i n t ; end a t t r ib u t e s ; fun v o id C reate 0 = s e t S ep a ra tio n to 30 end s e t " s e t Num to 1000 end s e t end fu n C reate; — These fu n c tio n s are implemented as C++ u sin g th e — b u i l t - i n s o lu tio n s to th e c o n s tr a in t graph, e x te r n a l fu n v o id A ssertH ighL evelE dge(E : H ighL evelEdge); e x te r n a l fu n v o id R etractH ighL evelE dge(E : H ighL evelE dge); fu n v o id A ddC onstraint(T : i n t , VI : V ertex , V2 : V ertex , D : i n t , P : in t ) = i f (T == B eforeC onst) th en l e t M E : BeforeEdge = new BeforeEdge VI,V2; in add edge N E s e t NE.Dim to D end s e t s e t M E .P riority to P end s e t " s e t NE.LowLevel to NULL end s e t s e t N E .A sserted to f a l s e end s e t “ AssertH ighLevelEdge(M E) end l e t e l s e i f (T ~~ N eighborC onst) th en l e t M E : NeighborEdge = new NeighborEdge VI,V2; in add edge N E “ s e t NE.Dim t o D end s e t s e t N E .P r io r ity to P end s e t " s e t NE.LowLevel to NULL end s e t “ s e t N E .A sserted to f a l s e end s e t A ssertH ighLevelEdge(NE) end l e t e l s e i f (T == EqualC onst) th en l e t N E : EqualEdge = new EqualEdge VI,V2; in add edge N E s e t NE.Dim to D end s e t s e t N E .P r io r ity to P end s e t s e t NE.LowLevel to NULL end s e t s e t N E .A sserted to f a l s e end s e t A ssertH ighLevelEdge(NE) end l e t e l s e i f (T == C enterC onst) th en l e t W E : CenterEdge = new CenterEdge V I,¥2; in add edge W E s e t WE.Dim to D end s e t " s e t W E .P riority to P end s e t " s e t WE.LowLevel to W U L L end s e t " s e t W E.Asserted to f a l s e end s e t " As s ertH ighLevelEdge(WE) end l e t end i f end i f end i f end i f end fu n A ddC onstraint; fu n v o id D elete C o n stra in t(E : HighLevelEdge) = i f (E != W U LL) th en s e t E .P r io r ity to - i end s e t R etractH ighL evelE dge(E ) l e t EL : l i s t o f HighLevelEdge = g e t E .C o n tr a d ic ts; in f o r a l l C : HighLevelEdge in EL su ch th a t d etach E from g e t C .C o n tra d icts end d etach end f o r a l l end l e t " d e le te edge E end i f end fun D e le te C o n str a in t; fu n b o o l AddVertex (V : V ertex) = i f (V i s a C o n stra in tV ertex ) th en add v e r te x V TRUE e l s e FALSE end i f end fu n AddVertex; fun b o o l AddEdge ( E : Edge ) = 225 add edge E i f (E i s a HighLevelEdge) then s e t E as HighLevelEdge . LowLevel to M U L L end s e t " s e t E as HighLevelEdge . A sser te d to f a l s e end s e t ~ A ssertH ighL evelE dge(E as H ighLevelEdge) end i f ' TRUE end fu n AddEdge; fu n b o o l D eleteE dge ( E : Edge ) = i f (E is a HighLevelEdge) then s e t E as H ig h L ev elE d g e.P rio rity to -1 end s e t " R etractH ighL evelE dge(E as H ighLevelEdge) " l e t EL : l i s t o f HighLevelEdge = g e t E as H igh L evelE d ge.C on trad icts; in f o r a l l C : HighLevelEdge in EL su ch th at d etach E as HighLevelEdge from g e t C .C on trad icts end d etach end f o r a l l end l e t end i f d e le te edge E TRUE end fu n AddEdge; fu n b o o l TouchEdge ( E : Edge ) = i f (E i s a HighLevelEdge) then i f (g e t E as H ighL evelE d ge.A sserted) th en RetractHighLevelEdgeCE as HighLevelEdge) end i f A ssertH ighL evelE dge(E as HighLevelEdge) end i f " tou ch edge E " TRUE end fun AddEdge; — These fu n c tio n s are im plem ented as C++ u sin g th e - - b u i l t - i n s o lu tio n s to th e c o n s tr a in t graph. - - O r ig in a lly , th e s e fu n c tio n s were im plem ented as — stand ard G E D L cod e, but th a t code has been changed — in to C++ fo r e f f ic ie n c y r e a so n s, e x te r n a l fun v o id SolveLow LevelQ ; 226 e x te r n a l fu n v o id SolveLowLevelDim(Dim : i n t ) ; e x te r n a l fun v o id SolveA t(D im : i n t , V L : l i s t o f V ertex ); e x te r n a l fun v o id SetPosR ight(D im : in t , V : C o n stra in tV erte x ); e x te r n a l fun v o id SetP osL eft(D im : in t , V : C o n stra in tV erte x ); e x te r n a l fun v o id SolveC enter(D im : in t , C V : C en terV ertex); e x te r n a l fun LowLevelEdge NotIm m ediatelyGreaterThan(Dim : i n t , V : C o n stra in tV ertex , V2 : C o n stra in tV ertex , LowestEdge : LowLevelEdge); e x te r n a l fun LowLevelEdge GreaterThanOrEqual(Dim : i n t , V : C o n stra in tV ertex , V2 : C o n stra in tV ertex , LowestEdge : LowLevelEdge); e x te r n a l fun LowLevelEdge GreaterThan(Dim : i n t , V : C o n stra in tV ertex , V2 : C o n stra in tV ertex , LowestEdge : LowLevelEdge); e x te r n a l fun LowLevelEdge Equal(Dim : i n t , V : C o n stra in tV ertex , V2 : C o n stra in tV ertex , LowestEdge : LowLevelEdge); e x te r n a l fu n LowLevelEdge R elated(D im : i n t , V : C o n stra in tV ertex , V2 : C o n stra in tV ertex , LowestEdge : LowLevelEdge); e x te r n a l fu n LowLevelEdge F ixed P osition (D im : i n t , V : C o n stra in tV ertex , LowestEdge : LowLevelEdge) e x te r n a l fu n LowLevelEdge F ix ed P o sitio n L eft(D im : in t , V : C o n stra in tV ertex , LowestEdge : LowLevelEdge) e x te r n a l fu n LowLevelEdge F ixed P osition R igh t(D im : i n t , V : C o n stra in tV ertex , LowestEdge : LowLevelEdge) e x te r n a l fu n v o id SetPos(V : V ertex , Dim : i n t , NewPos : i n t ) ; e x te r n a l fu n in t GetPos(V : V ertex, Dim : i n t ) ; end graph C onstraintG raph; G raphic/C om posite/V iew D e fin itio n s s i c * * * * * * * * * * s i t * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - boxgraphic Box i s a t t r ib u t e s Num : i n t ; Kind : s tr in g ; end a t t r ib u t e s ; lo o k Normal i s border brush s o l i d 1; c o lo r red; hbox t e x t a t t r ib u t e Num; t e x t a t t r ib u t e Kind; end hbox end lo o k Normal; end boxgraphic Box; boxgraphic RangeBox i s a t t r ib u t e s Num : i n t ; end a t t r ib u t e s ; lo o k Normal i s border brush s o lid i; c o lo r b la ck hbox t e x t a t t r ib u t e Num; bitmap Range; end hbox end lo o k Normal; end boxgraphic RangeBox; boxgraphic CenterBox i s a t t r ib u t e s Num : i n t ; end a t t r ib u t e s ; lo o k Normal i s border brush s o lid 1; c o lo r green hbox t e x t a t t r ib u t e Num; bitmap C enter; end hbox end lo o k Normal; end boxgraphic CenterBox; boxgraphic MarginBox i s a t t r ib u t e s Num : i n t ; L eftR ig h t : s tr in g ; end a t t r ib u t e s ; lo o k Normal i s border brush s o lid 1; c o lo r b la ck hbox t e x t a t t r ib u t e Num; bitm ap LeftM; end hbox end lo o k Normal; end boxgraphic MarginBox; lin e g r a p h ic L ine i s a t t r ib u t e s Kind : s tr in g ; end a t t r ib u t e s ; lo o k Normal i s l i n e brush s o lid 1; c o lo r red; arrowhead hbox t e x t a t t r ib u t e Kind; end hbox end lo o k Normal; end lin e g r a p h ic L ine; lin e g r a p h ic RangeLine i s lo o k Normal i s l i n e brush s o lid 1; c o lo r b lack ; arrowhead hbox t e x t "r"; end hbox end lo o k Normal; end lin e g r a p h ic RangeLine; lin e g r a p h ic C enterL ine i s lo o k Normal i s l i n e brush s o lid 1; c o lo r green; arrowhead hbox t e x t "c"; end hbox end lo o k Normal; end lin e g r a p h ic C enterL ine; lin e g r a p h ic MarginLine i s lo o k Normal i s l i n e brush s o lid 1; c o lo r b la ck ; arrowhead hbox t e x t "m"; end hbox end lo o k Normal; end lin e g r a p h ic M arginLine; lin e g r a p h ic EqualLine i s lo o k Normal i s l i n e brush s o lid 1; c o lo r b lu e; arrowhead hbox t e x t "e"; | end hbox ' end lo o k Normal; end lin e g r a p h ic EqualLine; lin e g r a p h ic N eighborLine i s i lo o k Normal i s | l i n e brush s o lid 1; c o lo r b lu e; arrowhead hbox t e x t "n"; ; end hbox end lo o k Normal; end lin e g r a p h ic N eighborLine; * I lin e g r a p h ic B eforeL in e i s j lo o k Normal i s | l i n e brush s o lid 1; c o lo r b lu e; arrowhead | hbox ! t e x t "b"; end hbox end lo o k Normal; end lin e g r a p h ic B eforeL ine; lin e g r a p h ic IGTLine i s lo o k Normal i s l i n e brush s o lid 1; c o lo r b la ck ; arrowhead hbox t e x t "IGT"; end hbox end lo o k Normal; end lin e g r a p h ic IGTLine; lin e g r a p h ic GTLine i s 1 lo o k Normal i s l i n e brush s o lid 1; c o lo r b lack ; arrowhead hbox t e x t "GT"; end hbox end lo o k Normal; end lin e g r a p h ic GTLine; lin e g r a p h ic EQLine i s lo o k Normal i s l i n e brush s o lid 1; c o lo r b la ck ; arrowhead hbox t e x t "EQ"; end hbox end lo o k Normal; end lin e g r a p h ic GTLine; lin e g r a p h ic NELine i s lo o k Normal i s l i n e brush s o lid i ; c o lo r b la ck ; arrowhead hbox t e x t "NE"; end hbox end look Normal; end lin e g r a p h ic NELine; lin e g r a p h ic CNTRLine i s lo o k Normal i s l i n e brush s o lid 1; c o lo r b la ck ; arrowhead hbox t e x t "C"; end hbox end lo o k Normal; end lin e g r a p h ic CNTRLine; lin e g r a p h ic ATLine i s lo o k Normal i s l i n e brush s o lid 1; c o lo r b la ck ; arrowhead hbox t e x t "AT"; end hbox end lo o k Normal; end lin e g r a p h ic ATLine; - - W e assume th a t th e V ertex w i l l alrea d y have i t s X,Y s e t . - - t h i s e d ito r does i s u se th o se v a lu e s by f ix i n g th e X and - - p o s it io n s v ia a range c o n s tr a in t, com p osite gra p h ic UserCom posite i s fun b o o l AddVertex (V :V ertex) = i f (V is a BoxGraphicVertex) th en l e t B : Box = new Box a sso c V; in s e t B.Num to g e t V as C onstraintV ertex.N um end s e t A ll s e t B.Kind to g e t V as BoxG raphicVertex.K ind end s e t atom ic add boxgraphic B I j 1 l e t XPos : in t = g e t V as BoxG raphicVertex.X Pos; YPos : in t = g e t V as BoxG raphicV ertex.Y Pos; ] in add c o n s tr a in t X 1 range B , XPos, XPos " | add c o n s tr a in t Y 1 range B , YPos, YPos 1 end l e t end l e t end i f I i TRUE ; end fu n AddVertex; - - Must be very c a r e fu l on ty p e names, s in c e t h i s e d ito r - - u se s th e same name fo r ty p es as th e a c tu a l c o n s tr a in t - - graph (c o n s tr a in t manager) (minus th e G p r e f i x ) . i i - - The X,Y p o s it io n s may have been changed by th e c l i e n t , or — th e u s e r . D e le te p rev io u s range c o n s tr a in ts and add new ! — range c o n s tr a in ts . j fu n b o o l TouchVertex (V :V ertex) = ! i f (V is a BoxG raphicVertex) th en l e t C M : ConstraintM anager = GetCM(); EL : l i s t o f Element = V -> G etA ssociated W ith (); in f o r a l l E : Element in E L su ch th a t i f (Member(E)) th en i f (E is a Box) th en l e t B G : Box = E; C V : G C onstraintV ertex = C M ->G etA ssociatedVertex(BG ); in f o r a l l E : Edge in CM->GetIncidentEdges(CV) su ch th at i f (E is a GRangeEdge) th en d e le te c o n s tr a in t E as GRangeEdge end i f end f o r a l l l e t XPos : in t = g e t V as BoxG raphicVertex.X Pos; 232 YPos : in t = g e t V as BoxG raphicVertex.Y Pos in add c o n s tr a in t X 1 range B G , XPos, XPos " add c o n s tr a in t Y 1 range B G , YPos, YPos end l e t end l e t end i f end i f end f o r a l l end l e t end i f TRUE end fu n TouchVertex; fun b o o l AddEdge (E:Edge) = i f (E is a GraphicEdge) th en l e t L : Line = new Line a sso c E; in i f (L != M ULL) then s e t L.Kind to g e t E as GraphicEdge.Kind end s e t atom ic add lin e g r a p h ic L end i f end l e t end i f TRUE end fu n AddEdge; end com p osite g rap h ic UserCom posite; com p osite gra p h ic H ighLevelC om posite i s a t t r ib u t e s Dim : i n t ; end a t t r ib u t e s ; fu n b o o l AddVertex (V :V ertex) = i f (V is a BoxGraphicVertex) th en l e t B : Box = new Box a sso c V; in s e t B.Num to g e t V as C onstraintV ertex.N um end s e t s e t B.Kind to g e t V as BoxG raphicVertex.K ind end s e t atom ic add boxgraphic B l e t XPos : in t = g e t V as BoxG raphicV ertex.X Pos; YPos : in t = g e t V as BoxG raphicV ertex.Y Pos; in add c o n s tr a in t X 1 range B , XPos, XPos " add c o n str a in t Y 1 range B , YPos, YPos end l e t end l e t e l s e i f (V i s a D im ensionedV ertex) th en i f (g e t V as D im ensionedV ertex.Dim == g e t Dim) th en i f (V is a RangeVertex) th en l e t B : RangeBox = new RangeBox a sso c V; in s e t B.Num to g e t V as C onstraintV ertex.N um end s e t atom ic add boxgraphic B end l e t e l s e i f (V is a C enterV ertex) th en l e t B : CenterBox = new CenterBox a sso c V; in s e t B.Num to g e t V as C on stra in t V ert ex . Niim end s e t atom ic add boxgraphic B end l e t e l s e i f ((V is a LeftM arginV ertex) I I (V is a R ightM arginV ertex)) th en l e t B : MarginBox = new MarginBox a sso c V; in s e t B.Num to g e t V as C onstraintV ertex.N um end s e t atom ic add boxgraphic B end l e t end i f end i f end i f end i f 234 end i f end i f TRUE end fu n AddVertex; fun b o o l AddEdge (E:Edge) = i f (E is a HighLevelEdge) th en l e t D : in t = g e t E as HighLevelEdge.Dim; Dim : in t = g e t Dim; in i f (D == Dim) th en i f (E is a MarginEdge) th en l e t L : MarginLine = new MarginLine a sso c E; in i f (L != NULL) th en atom ic add lin e g r a p h ic L end i f end l e t e l s e i f (E is a RangeEdge) th en l e t L : RangeLine = new RangeLine a sso c E; in i f (L != NULL) th en atom ic add lin e g r a p h ic L end i f end l e t e l s e i f (E is a CenterEdge) then l e t L : C enterL ine = new C enterLine a sso c E; in i f (L != NULL) th en atom ic add lin e g r a p h ic L end i f end l e t e l s e i f C E is a EqualEdge) th en l e t L : EqualLine = new EqualLine a sso c E; 235 in i f (L != M U LL) th en atom ic add lin e g r a p h ic L end i f end l e t e l s e i f (E i s a NeighborEdge) th en l e t L : N eighborLine = new N eighborLine a sso c E; in i f (L != M U LL) th en atom ic add lin e g r a p h ic L end i f end l e t e l s e i f (E i s a BeforeEdge) th en l e t L : B eforeL in e = new B eforeL in e a sso c E; in i f (L != M ULL) then atom ic add lin e g r a p h ic L end i f end l e t end i f end i f end i f end i f end i f end i f end i f end l e t end i f TRUE end fun AddEdge; end com p osite g rap h ic H ighL evelC om posite; com p osite g rap h ic LowLevelComposite i s a t t r ib u t e s Dim : i n t ; end a t t r i b u t e s ; fu n b o o l AddVertex (V :V ertex) = 236 i f (V is a BoxGraphicVertex) th en l e t B : Box = new Box a sso c V; in s e t B.Num to g e t V as C onstraintV ertex.N um end s e t s e t B.Kind to g e t V as BoxG raphicVertex.K ind end s e t atom ic add boxgraphic B l e t XPos : in t = g e t V as BoxG raphicV ertex.X Pos; YPos : in t = g e t V as BoxG raphicV ertex.Y Pos; in add c o n s tr a in t X 1 range B , XPos, XPos " add c o n s tr a in t Y 1 range B , YPos, YPos end l e t end l e t e l s e i f (V i s a D im ensionedV ertex) th en i f (g e t V as D im ensionedV ertex.Dim == g e t Dim) th en i f (V is a RangeVertex) th en l e t B : RangeBox = new RangeBox a sso c V; in s e t B.Num to g e t V as C o n stra in tV erte x . N um end s e t atom ic add boxgraphic B end l e t e l s e i f (V is a C enterV ertex) th en l e t B : CenterBox = new CenterBox a sso c V; in s e t B.Num to g e t V as C onstraintV ertex.N um end s e t atom ic add boxgraphic B end l e t e l s e i f ((V is a LeftM arginV ertex) I I (V is a R ightM arginV ertex)) th en l e t B : MarginBox = new MarginBox a sso c V; in s e t B.Num to g e t V as C onstraintV ertex.N um end s e t atom ic add boxgraphic B end l e t end i f end i f end i f end i f end i f end i f TRUE end fun AddVertex; fu n b o o l AddEdge (E:Edge) = i f (E i s a GraphicEdge) th en TRUE e l s e i f (E is a LowLevelEdge) then l e t D : in t = g e t E as LowLevelEdge.Dim; Dim : in t = g e t Dim; in i f (D == Dim) th en i f (E is a GTEdge) then l e t L : GTLine = new GTLine a sso c E; in i f (L != NULL) th en atom ic add lin e g r a p h ic L end i f end l e t e l s e i f (E i s a IGTEdge) th en l e t L : IGTLine = new IGTLine a sso c E; in i f (L != NULL) th en atom ic add lin e g r a p h ic L end i f end l e t e l s e i f (E is a CNTREdge) th en l e t L : CNTRLine = new CNTRLine a sso c E; 238 in i f (L != NULL) th en atom ic add lin e g r a p h ic L end i f end l e t e l s e i f (E i s a EQEdge) then l e t L : EQLine = new EQLine a sso c E; in i f (L != NULL) th en atom ic add lin e g r a p h ic L end i f end l e t e l s e i f (E i s a NEEdge) then l e t L : NELine = new NELine a sso c E; in i f (L != NULL) th en atom ic add lin e g r a p h ic L end i f end l e t e l s e i f (E i s a ATEdge) then l e t L : ATLine = new ATLine a sso c E; in i f (L != NULL) th en atom ic add lin e g r a p h ic L end i f end l e t end i f end i f end i f end i f end i f end i f end i f end l e t end i f end i f 239 TRU E end fun AddEdge; end com posite grap h ic LowLevelComposite; view UserView i s g ra p h ic U serCom posite; end view UserView; view HighLevelXView i s g ra p h ic H ighLevelC om posite; fu n v o id I n it Q = l e t R : Com posite = G etR ootO ; in s e t R as H ighLevelC om posite.D im to XConst end s e t end l e t end fun I n i t ; end view HighLevelXView; view HighLevelYView i s g ra p h ic H ighL evelC om posite; fun v o id I n it Q = l e t R : Composite = G etR ootO ; in s e t R as HighLevelCom posite.Dim to YConst end s e t end l e t end fu n I n i t ; end view HighLevelYView; view LowLevelXView i s gra p h ic LowLevelComposite; fu n v o id I n it Q = l e t R : Com posite = G etR ootO ; in s e t R as LowLevelComposite.Dim to XConst end s e t end l e t end fu n I n it ; end view LowLevelXView; 240 I view LowLevelYView i s g ra p h ic LowLevelComposite; fu n v o id I n it O = l e t R : Composite = G etR ootO ; in s e t R as LowLevelComposite.Dim to YConst end s e t end l e t end fu n I n it ; end view LowLevelYView; »-»— >|c3|c)te3|c9{e3|c$$:fcsjc$3|e:tc3|<3t':|cs|e$3|c$$3|c3|«)|e9|c3tc:fe»ic3|c9lc:fe))c$ $ $ $ $ £ $ $ $ $ $ $ $ $ $ $ £ $ £ $ $ £ $ $ $ $ $ $ $ $ ------ ! O perations D e fin itio n s i , o p e r a tio n s fu n v o id I n it () = j l e t V : UserView = new UserView; ] V T : ViewTree = GetVTO; I G : Graph = GetGraphO; ' in ! VT->AddView(V,G) end l e t SetA utoC lientO nO SetAutoServerO nO end fun I n i t ; e x te r n a l fu n v o id SendAddlnfo(V : V e r te x ); - - C a lled when u ser r e q u e sts th e a d d itio n o f a v e r te x , fu n b o o l AddVertexOp (V : V ertex) = l e t VT : ViewTree = GetVTO; G : C onstraintG raph = GetGraphO; in i f l e t V w : View = V T->G etCurrentView(); in i f (V is a D im ensionedV ertex) then i f ((Vw is a HighLevelXView) II (Vw is a LowLevelXView)) th en s e t V as D im ensionedVertex.Dim to XConst end s e t TRUE e l s e 241 i f ((Vw is a HighLevelYView) I| (Vw is a LowLevelYView)) th en s e t V as D im ensionedVertex,D im to YConst end s e t ~ TRU E e l s e FALSE end i f end i f e l s e TRUE end i f end l e t th en i f (V i s a C on strain tV ertex) th en — The u ser w i l l add v e r t ic e s s t a r t in g at 1000. l e t M : in t = g e t G.Num; in s e t V as C onstraintV ertex.N um to N end s e t s e t G.Num to N+l end s e t end l e t end i f i f (V i s a BoxG raphicVertex) th en l e t S : S ta te = G e tS ta te O ; X : in t = S->G etM ouseX(); Y : in t = S->G etM ouseY(); in s e t V as BoxGraphicVertex.XPos to X end s e t s e t V as BoxGraphicVertex.YPos to Y end s e t end l e t end i f TRUE e l s e FALSE end i f end l e t end fu n AddVertexOp; fun b o o l AddEdgeOp (E : Edge) = l e t VT : ViewTree = GetVTO; G : C onstraintG raph = GetGraphO ; Vw : View = V T->G etCurrentView(); in i f (E is a C onstraintE dge) th en 242 — The u ser w i l l add v e r t ic e s s t a r t in g a t 1000. l e t N : in t = g e t G.Num; in s e t E as C on strain tE d ge. Num to N end s e t ~ s e t G.Num to N+l end s e t end l e t i f ((Vw is a HighLevelXView) | | (Vw i s a LowLevelXView)) th en s e t E as C on strain tE d ge. Dim to XConst end s e t TRUE e ls e i f ((Vw is a HighLevelYView) II (Vw is a LowLevelYView)) then s e t E as C onstraintE dge.D im to YConst end s e t TRUE e l s e FALSE end i f end i f e ls e TR U E end i f end l e t end fu n AddEdgeOp; e x te r n a l fu n v o id H andleC lientR equest(R equest : s t r in g ) ; e x te r n a l fu n v o id H andleServerR equest(R equest : s t r in g ) ; command AddUserView i s fu n b o o l E xecute () = l e t V T : ViewTree = GetVTO; G : Graph = GetGraphO; V : UserView = new UserView; in VT->AddView(V,G) end l e t end fun E xecute; end command AddUserView; command AddHighLevelXView i s fu n b o o l E xecute () = l e t V T : ViewTree = GetVTO; G : Graph - GetGraphO ; V : HighLevelXView = new HighLevelXView; xn VT->AddView(V, G) end l e t end fun E xecute; end command AddHighLevelXView; command AddHighLevelYView i s fu n b o o l E xecute () = l e t V T : ViewTree = GetVTO; G : Graph = GetGraphO; V : HighLevelYView = new HighLevelYView; in VT->AddView(V,G) end l e t end fu n E xecute; end command AddHighLevelYView; commeind AddLowLevelXView i s fun b o o l E xecute () = l e t V T : ViewTree = GetVTO; G : Graph = GetGraphO; V : LowLevelXView = new LowLevelXView; in VT->AddView(V, G) end l e t end fun E xecute; end command AddLowLevelXView; command AddLowLevelYView i s fun b o o l E xecute () = l e t VT : ViewTree = GetVTO; G : Graph = GetGraphO; V : LowLevelYView = new LowLevelYView; in VT->AddView(V,G) end l e t end fun E xecute; end command AddLowLevelYView; command SolveLowLevel i s fu n b o o l E xecute 0 = l e t 244 G : Graph = GetGraphO; C G : C onstraintG raph = G as C onstraintG raph; in s t a r t tr a n s a c tio n C G ~ CG->SolveLowLevelO commit tr a n s a c tio n C G end l e t end fun E x ecu te; end command SolveL ow L evel; command G etC lien tD ata i s fu n b o o l E xecute () = l e t S : s t r in g = G etN ex tC lien tD a ta Q ; in i f (S != NULL) th en H an d leC lien tR equ est(S ) end i f end l e t end fu n E xecute; end command G etC lientD ata; menu Types "Element Types" checked i s BoxGraphicVertex L eftM arginV ertex R ightM arginV ertex C enterV ertex : RangeVertex : sep a ra to r Edges ; GraphicEdge MarginEdge CenterEdge RangeEdge BeforeEdge EqualEdge NeighborEdge IGTEdge "Graphic Vertex" ; "L eft Margin Vertex" "Right Margin V ertex' "Center Vertex" ; "Range Vertex" ; GTEdge EQEdge NEEdge CNTREdge ATEdge end menu Types; "Graphic Edge" ; "Margin Edge" ; "Center Edge" ; "Range Edge" ; "Before Edge" ; "Equal Edge" ; "Neighbor Edge" "IGT Edge" ; "G T Edge" "EQ Edge" "NE Edge" "CNTR Edge" "AT Edge" ; menu AddView "Add View" i s AddUserView : "User View" AddHighLevelXView AddHighLevelYView AddLowLevelXView AddLowLevelYView end menu AddView; "High L evel X View "High L evel Y View "Low L evel X View" "Low L evel Y View" menu Misc "Misc" i s SolveLowLevel : "Solve Low Level" ; sep a ra to r Edges ; G etC lien tD ata : "Get C lie n t D ata"; end menu M isc; end o p e r a tio n s; end e d ito r C onstraintG rap h E ditor; A p p e n d ix C T a sk -D ep en d en ce G rap h E d itor This chapter contains the full source for the task-dependence graph editor. — TaskDependenceGraph - T h is e d ito r m an ip u lates a task-d ep en d en ce graph. In in c lu d e s co m p o sitio n a b s tr a c tio n , autom atic in c lu s io n o f d ep en d en cies betw een co m p o sites, autom atic la y o u t, and c a lc u la tio n o f th e c r i t i c a l path w ith v is u a liz a t io n . — Author: A. Karrer — D ate: 9 /1 7 /9 2 - - GEDL: v 0 .5 0 — R e v is io n s : e d it o r TaskDependenceGraph i s o p tio n c l i e n t "C onstraint"; — d ata d e f in it io n s v e r te x Task i s sa v ea b le e d it a b le : Name : s tr in g ; D uration : in t; p r iv a te : - - updated by d ata manager in c r i t i c a l — path c a lc u la tio n C r it ic a l : b o o l; EndDate : i n t ; end v e r te x Task; — Com posite Task d u ration i s th e d iffe r e n c e betw een — th e e a r l i e s t c h ild s t a r t and th e l a t e s t c h ild — end. — End Date i s th e l a t e s t End Date o f c h ild r e n . - - Com posite Task i s c r i t i c a l i f f a c h ild ta s k i s — c r i t i c a l . v e r te x CompositeTask i s sa v ea b le e d it a b le : Name : s tr in g ; p r iv a te : - - updated by d ata manager in c r i t i c a l — path c a lc u la tio n D uration : i n t ; C r it ic a l : b o o l; EndDate : in t; — used in C om position A b stra c tio n on ly Hidden : b o o l; end v e r te x CompositeTask; edge S u ccesso r i s sa v ea b le p r iv a te : C r it ic a l : b o o l; end edge S u ccesso r; — Com posite co n n ectio n from parent to c h ild edge C hild i s sa v ea b le end edge C hild; — The im p lic it su c c e sso r lin k betw een com posite ta sk s edge Ir a p lic itS u c c e sso r i s sa v ea b le p r iv a te : C r it ic a l : b o o l; end edge I m p lic itS u c c e s s o r ; graph TaskDependenceGraphGraph i s c o n n e c tiv ity i s lo c a l r u l e s : S u ccesso r : Task -> Task : one; Im p lic itS u c c e s so r : CompositeTask -> CompositeTask : one; C hild : CompositeTask -> Task I CompositeTask : one; g lo b a l r u le s : dag : Task , S u ccesso r; dag : CompositeTask , Im p lic itS u c c e sso r ; t r e e : CompositeTask I Task , C hild; end c o n n e c tiv ity ; a t t r ib u t e s EndDate : in t; 248 end a t t r ib u t e s ; - - fin d a l l v e r t ic e s w ith no p red ece sso rs fun l i s t o f V ertex G e tS ta r tV e r tic e sO = f i n d a l l V : V ertex in G etV erticesO su ch th at f o r a l l E : Edge in GetEdgesQ su ch th a t i f (E i s a S u ccesso r) th en E->G etSecondV ertex() != V e ls e TRUE end i f end f o r a l l end f in d a l l end fun G e tS ta r tV e r tic e s ; — i s th e v e r te x an end v e r te x fu n b o o l IsEndV ertex (C : Elem ent) = i f (C su b c la s so f V ertex) th en f o r a l l E : Edge in GetEdgesQ su ch th at i f (E is a S u ccesso r) then E -> G etF irstV ertex () != C as V ertex e ls e TR U E end i f end f o r a l l e l s e FALSE end i f end fun IsEndV ertex; fu n l i s t o f V ertex G etP redecessors(V : V ertex) f i n d a l l P : V ertex in G etV er ticesO su ch th at e x i s t s E : Edge in GetEdgesQ su ch th at E is a S u ccesso r & & E -> G etF irstV ertexO = E ->G etSecondV ertex() == V end e x i s t s end f in d a ll end fu n G etE ndV ertices; fu n l i s t o f V ertex G etSu ccessors(V : V ertex) = f i n d a l l S : V ertex in G etV er ticesO su ch th a t e x i s t s E : Edge in GetEdgesO su ch th at E is a S u ccesso r & & E -> G etF irstV ertex () == V && E ->G etSecondV ertex() == S end e x i s t s end f in d a l l end fu n G etE ndV ertices; fu n l i s t o f V ertex G etE ndV ertices() = f i n d a l l V : V ertex in G etV er ticesO su ch th a t IsEndVert e x (V) end f i n d a l l end fun G etE ndV ertices; fu n v o id UpdateGraphEndDateO = l e t EV : l i s t o f V ertex = G etE ndV ertices(); in s e t EndDate to 0 end s e t f o r a l l V : V ertex in EV su ch th at i f (V i s a Task) th en i f (g e t V as Task.EndDate > g e t EndDate) th en s e t EndDate to g e t V as Task.EndDate end s e t end i f end i f end f o r a l l end l e t end fun UpdateGraphEndDate; fu n v o id UpdateEndDates(C : Elem ent) = i f (C i s a Task) th en f o r a l l S : Edge in GetEdgesO su ch th a t i f (S is a S u ccesso r) th en i f (C as V ertex == S -> G e tF ir stV e r te x ()) 250 th en UpdateEndDates(S) end i f end i f end f o r a l l e l s e — /* C i s an Edge * / i f (C i s a S u ccesso r) th en l e t E : Edge = C as Edge; FV : Task = E -> G e tF ir stV e r te x (); SV : Task = E ->G etSecondV ertex() ; in l e t NewEnd : in t = g e t FV.EndDate + g e t SV .D uration in i f (NewEnd > g e t SV.EndDate) th en s e t SV.EndDate to NewEnd end s e t end i f UpdateEndDates(SV) end l e t end l e t end i f end i f end fun UpdateEndDates; fun v o id UpdatePredVertex(V : V ertex , E : Edge) = l e t V2 : V ertex = E -> G etSecondV ertex(); in i f (V is a Task) th en i f ( ( g e t V as Task.EndDate + g e t V2 as T ask .D u ration ) (g e t V2 as Task.EndDate)) th en s e t E as S u c c e sso r . C r it ic a l to TRUE end s e t s e t V as T a s k .C r itic a l to TRU E end s e t f o r a l l NE : Edge in GetEdgesO su ch th at i f (NE is a S u ccessor) th en i f (N E->G etSecondVertex() == V) then U pdateP redV ertex(N E ->G etF irstV ertex(),N E ) end i f end i f end f o r a l l end i f end i f end l e t end fu n U p d ateP red V ertices; fu n v o id U p d a teC ritica lP a th () = f o r a l l V : V ertex in G e tV er ticesO su ch th a t i f (V i s a Task) th en touch v e r te x V s e t V as T ask. C r it ic a l to FALSE end s e t end i f end f o r a l l f o r a l l E : Edge in GetEdgesO su ch th at i f (E i s a S u ccesso r) then touch edge E s e t E as S u c c e s s o r .C r itic a l to FALSE end s e t end i f end f o r a l l l e t SV : l i s t o f V ertex = G e tS ta r tV e r tic e s O ; in f o r a l l V : V ertex in SV su ch th at i f (V i s a Task) th en s e t V as Task.EndDate to g e t V as T ask.D uration end s e t UpdateEndDates(V) end i f end f o r a l l end l e t UpdateGraphEndDate() l e t EV : l i s t o f V ertex = G etE ndV ertices( ) ; in f o r a l l V : V ertex in EV su ch th at i f (V is a Task) th en i f (g e t V as Task.EndDate == g e t EndDate) th en 252 s e t V as T a s k .C r itic a l to TRUE end s e t " f o r a l l E : Edge in GetEdgesO su ch th at i f (E i s a S u ccesso r) then l e t FV : V ertex = E -> G etF irstV ertex( ) ; SV : V ertex = E -> G etS econ d V ertex(); in i f (g e t SV as T a s k .C r itic a l) then UpdatePredVertex(FV.E) end i f end l e t end i f end f o r a l l end i f end i f end f o r a l l end l e t end fun U p d a teC ritica lP a th ; - - T his fu n c tio n retu rn s any im pl su c c e sso r edge th a t — co n n ects th e two v e r t ic e s . fun Edge G etIm plSuccC onnection(V l : V ertex , V2 : V ertex) fin d o n e E : Edge in GetEdgesO su ch th a t (E is a I m p lic itS u c c e sso r ) && (E -> G etF irstV ertex () == && (E ->G etSecondV ertex() == V2) end fin d o n e end fu n G etlm plSuccC onnection; — T his fu n c tio n retu rn s tr u e i f th e two v e r t ic e s are — con n ected v ia a Im p lic itS u c c e sso r Edge. fu n b o o l Im plSuccC onnects(V l : V ertex, V2 : V ertex) = e x i s t s E : Edge in GetEdgesO su ch th at (E i s a I m p lic itS u c c e sso r ) & & (E -> G etF irstV ertex () == & & (E ->G etSecondV ertex() == V2) end e x i s t s end fun Im plSuccC onnects; — T his fu n c tio n retu rn s th e C hild Edge which p o in ts in to — (v o id i s retu rn ed i f none) fun Edge ParentEdge(V : V ertex) = fin d o n e E : Edge in GetEdgesO su ch th a t (E is a C hild) & & (E ->G etSecondV ertex() == V) end fin d o n e end fun ParentEdge; — T his fu n c tio n w i l l retu rn th e parent o f V i f any, i f none, — th en v o id i s retu rn ed . fun V ertex GetParent(V : V ertex) = l e t E : Edge = P arentE dge(V ); in i f (E != v o id ) then E -> G etF irstV ertex () e l s e v o id end i f end l e t end fun G etParent; — T his fu n c tio n w i l l add im p lic it su c c e sso r lin k s — betw een two com posite ta s k s i f i t i s needed. - - I t i s c a lle d when an edge (o f any ty p e) i s added. - - I t retu rn s f a l s e i f th e add edge i s u n su c c e ssfu l - - b ecau se o f a c o n s tr a in t v io la t io n . fun b o o l A d d Im p licitS u ccessors(E :E d ge) = i f ((E is a S u ccesso r) I I (E is a I m p lic itS u c c e s so r )) th en l e t Vi : V ertex = E -> G e tF ir stV e r te x (); V2 : V ertex = E -> G etSecondV ertex(); PV1 : V ertex = G etP a ren t(V I); PV2 : V ertex = G etP aren t(V 2); in i f ((PV1 != v o id ) & & (PV2 != v o id )) then i f (PV1 != PV2) th en i f ( !Im plSuccC onnects(PV l,PV 2)) then l e t E : Im p lic itS u c c e sso r = new Im p lic itS u c c e sso r PVi , PV2 ; in s e t E .C r it ic a l to FALSE end s e t i f add edge E th en A d d lm p licitS u ccesso rs(E ) e ls e FALSE — add edge f a i l e d 254 end i f end l e t e ls e TRUE — le g a l im p lic it succ end i f e l s e TRUE — le g a l im p lic it succ end i f e ls e TRUE — le g a l im p lic it succ end i f end l e t e l s e i f (E i s a C hild) then l e t C : V ertex = E -> G etS econ d V ertex(); P : V ertex = E -> G e tF ir stV e r te x (); in i f f o r a l l Pred : V ertex in G etP redecessors(C ) su ch th at l e t PPred : V ertex = G etP a ren t(P red ); in i f (PPred != v o id ) th en i f (PPred != P) th en i f ( ! Im plSuccC onnects(PP red,P )) then l e t E : I m p lic itS u c c e sso r = new I m p lic itS u c c e s so r PPred , P ; in s e t E .C r it ic a l to FALSE end s e t i f add edge E then A d d lm p licitS u ccesso rs(E ) e l s e FALSE — add edge f a il e d end i f end l e t e ls e TRUE - - le g a l im p lic it succ end i f e l s e TRUE - - le g a l im p lic it succ end i f e ls e TRUE — le g a l im p lic it succ end i f end l e t 255 end f o r a l l th en f o r a l l Succ : V ertex in G etSuccessors(C ) su ch th at l e t PSucc : V ertex = G etP a ren t(S u cc); in i f (PSucc != v o id ) th en i f (PSucc != P) th en i f (!Im plSu ccC on n ects(P ,P S u cc)) then l e t E : Im p lic itS u c c e sso r = new Im p lic itS u c c e sso r P , PSucc in s e t E .C r it ic a l to FALSE end s e t i f add edge E th en A d d lm p licitS u ccesso rs(E ) e l s e FALSE — add edge f a il e d end i f end l e t e l s e TRUE — le g a l im p lic it succ end i f e l s e TRUE — le g a l im p lic it succ end i f e l s e TRUE — le g a l im p lic it succ end i f end l e t end f o r a l l e l s e FALSE end i f end l e t e ls e FALSE — unknown Edge typ e end i f end i f end fu n A d d lm p licitS u ccesso rs; — T his fu n c tio n w i l l d e le te im p lic it su c c e sso r lin k s — betw een two com posite ta s k s i f i t i s needed. — I t i s c a lle d when a v e r te x (o f any ty p e ) i s d e le te d fu n v o id D eleteIm plSuccV ertex(V : V ertex) = i f ((V i s a Task) I I (V is a C om positeTask)) th en l e t P : V ertex = G etP aren t(V ); in f o r a l l Pred : V ertex in G etP redecessors(V ) su ch th at l e t PPred : V ertex = G etP aren t(P red ); in i f (PPred != v o id ) then i f (PPred != P) then l e t E : Edge = G etIm plSuccC onnection(P P red,P ); in i f (E != v o id ) then d e le te edge E end i f end l e t end i f end i f end l e t end f o r a l l f o r a l l Succ : V ertex in G etSuccessors(V ) su ch th a t l e t PSucc : V ertex - G etP a ren t(S u cc); in i f (PSucc != v o id ) th en i f (PSucc != P) then l e t E : Edge = G etIm plSuccC onnection(P,PSucc) ; in i f (E != vo id ) th en d e le te edge E end i f end l e t end i f end i f end l e t end f o r a l l end l e t end i f end fun D eletelm p lS u ccV ertex; - - I t i s c a lle d when an edge (o f any ty p e ) i s d e le te d . fu n v o id D eleteIm plSuccE dge(E :E dge) = i f ((E i s a S u ccesso r) | | (E is a Im p lic itS u c c e s so r )) th en l e t VI : V ertex = E -> G e tF ir stV e r te x (); V2 : V ertex = E -> G etS econ d V ertex(); PV1 : V ertex = G etP a ren t(V I); PV2 : V ertex = G etP aren t(V 2); in i f (CPVl != v o id ) & & (PV2 != v o id )) then i f (PVi != PV2) then l e t IS : Edge = G etIm plSuccC onnection(PV l,PV 2); in i f (IS != v o id ) then d e le te edge IS end i f end l e t end i f end i f end l e t e l s e i f (E i s a C hild) then l e t C : V ertex = E -> G etSecondV ertex(); P : V ertex = E -> G e tF ir stV e r te x (); in f o r a l l Pred : V ertex in G etP red ecessors(C ) su ch th at l e t PPred : V ertex = G etP aren t(P red ); in i f (PPred != v o id ) th en i f (PPred != P) th en l e t IS : Edge = G etIm plSuccC onnection(P P red,P ); in i f (IS != v o id ) then d e le te edge IS end i f end l e t end i f end i f end l e t end f o r a l l f o r a l l Succ : V ertex in G etSuccessors(C ) su ch th at l e t PSucc : V ertex = G etP a ren t(S u cc); in i f (PSucc != v o id ) th en i f (PSucc != P) th en l e t IS : Edge = G etIm plSuccC onnection(P,PSucc) in i f (IS != v o id ) then d e le te edge IS end i f end l e t end i f end i f end l e t end f o r a l l end l e t end i f end i f end fun D eletelm plSuccE dge; fu n v o id C reate () = s e t EndDate to 0 end s e t end fun C reate; fu n b o o l AddVertex (V :V ertex) = i f (V i s a Task) th en s e t V as T ask.D uration to 0 end s e t s e t V as Task.Name to "?" end s e t ~ s e t V as Task.EndDate to 0 end s e t s e t V as T a s k .C r itic a l to FALSE end s e t add v e r te x V U p d a teC ritica lP a th O e l s e i f (V is a CompositeTask) th en s e t V as C om positeT ask.D uration to 0 end s e t s e t V as CompositeTask.Name to end s e t s e t V as CompositeTask.EndDate to 0 end s e t s e t V as C o m p o siteT a sk .C ritica l to FALSE end s e t s e t V as C om positeTask.H idden to FALSE end s e t add v e r te x V U p d a teC ritica lP a th O end i f end i f ” TRUE end fu n AddVertex; fun b o o l AddEdge (e:E dge) = i f (e i s a S u ccesso r) th en s e t e as S u c c e s s o r .C r itic a l to FALSE end s e t i f add edge e th en i f A d d lm p lic itS u c c e sso r s(e ) th en U p d a teC ritica lP a th O TRUE e l s e FALSE end i f e ls e FALSE end i f e l s e i f (e is a C hild) then i f add edge e then i f A d d lm p lic itS u c c e sso r s(e ) then U p d a teC ritica lP a th O ~ TRUE e l s e FALSE end i f e ls e FALSE end i f e ls e FALSE — unknown edge typ e end i f end i f end fu n AddEdge; fu n b o o l D eleteV ertex (v :V ertex ) = d e le t e v e r te x v D eletelm p lS u ccV ertex(v) U p d a teC ritica lP a th O ~ TRUE end fu n D eleteV ertex ; fun b o o l D eleteE dge (e:E dge) = d e le te edge e D eletelm p lS u ccE d ge(e) U p d a teC ritica lP a th O TRUE end fun D eleteE dge; fun b o o l TouchVertex (v :V ertex ) = tou ch v e r te x v U p d a teC ritica lP a th O " TRUE end fu n D eleteV ertex ; end graph TaskDependenceGraphGraph; a b s tr a c tio n C om position A b straction i s — c o n n e c tiv ity i s same as u n d erly in g graph c o n n e c tiv ity i s lo c a l r u l e s : S u ccesso r : Task -> Task : one; I m p lic itS u c c e sso r : CompositeTask -> CompositeTask : one C hild : CompositeTask -> Task I CompositeTask : one; g lo b a l r u l e s : dag : Task , S u ccessor; dag : CompositeTask , Im p lic itS u c c e sso r ; tr e e : CompositeTask I Task , C hild; end c o n n e c tiv ity ; — AddChild i s c a lle d on each c h ild o f a CompositeTask th a t — has j u s t been exposed. The c h ild and i t s a s s o c ia te d edges — must be added. I f i t i s a C om positeTask, th en i t sh ould — be h id d en . fun v o id AddChildCV : V ertex, E : C h ild , P : Com positeTask) = l e t G : Graph = G etA ssociatedC om ponent( ) ; in i f (V is a Task) then l e t NewV : Task = new Task a sso c V; NewE : C hild = new C hild a sso c E; in add v e r te x NewV add edge NewE end l e t e l s e i f (V is a Com positeTask) th en l e t NewV : CompositeTask = new CompositeTask a sso c V; NewE : C hild = new C hild a sso c E; in add v e r te x NewV s e t NewV.Hidden to TRUE end s e t tou ch v e r te x NewV ~ add edge NewE end l e t end i f end i f end l e t end fu n AddChild; — RemoveChildren removes a l l o f th e c h ild r e n o f th e — com posite v e r te x and th e a s s o c ia te d ed ges, fun v o id RemoveChildren(C : CompositeTask) = l e t S : l i s t of Edge = G etln cid en tE d g es(C ); in f o r a l l E : Edge in S su ch th at i f ( (E -> G etF irstV ertex () == (C as V ertex )) & & (E i s a C h ild )) then l e t SV : V ertex = E ->G etSecondV ertex(); in i f (SV i s a CompositeTask) then RemoveChildren(SV as CompositeTask) end i f d e le te v e r te x SV — d e le te edge i s autom atic end l e t end i f end f o r a l l end l e t end fu n RemoveChildren; — Expose s e t s th e a ttr ib u te of th e com posite ta s k to — non-hidden and exp oses one l e v e l o f c h ild r e n , fun v o id Expose(C : CompositeTask) = i f (g e t C.Hidden == TRUE) then s e t C.Hidden to FALSE end s e t l e t G : Graph = GetAssociatedCom ponentQ ; V L : l i s t o f V ertex = C -> G etA ssoc(); in i f (Empty(VL)) then ErrorC'No a s so c ia te d com posite ta sk in graph." ) e ls e f o r a l l V : V ertex in V L su ch th a t 262 i f ( ! (V i s a Com positeTask)) then E rror("N on-com posite a s s o c ia te d w ith co m p o site." ) e l s e l e t EL : l i s t o f Edge = G -> G etIn cid en tE d g esT h isF irst(V ); in f o r a l l E : Edge in EL su ch th at i f (E is a C hild) th en l e t SV : V ertex = E -> G etSecondV ertex(); in AddChild(SV,E as C hild.C ) end l e t end i f end f o r a l l end l e t end i f end f o r a l l end i f end l e t ~ touch v e r te x C end i f end fun Expose; — Hide s e t s th e a ttr ib u te o f th e com posite ta sk to — hidden and d e le te s a l l o f i t s c h ild r e n from th e — a b s tr a c tio n . fun v o id Hide(C : CompositeTask) = i f (g e t C.Hidden == FALSE) th en s e t C.Hidden to TR U E end s e t RemoveChildren(C) touch v e r te x C end i f end fu n Hide; — T his fu n c tio n must be s l i g h t l y d if f e r e n t in order to — handle adding a c h ild under a com posite th a t i s hidden, fun b o o l AddEdge(E : Edge) = i f (E is a S u ccesso r) th en l e t AbsE : S u ccessor = new S u ccesso r a sso c E; in add edge AbsE end l e t 263 e l s e i f (E i s a C hild) th en l e t FV : V ertex = E -> G e tF ir stV e r te x (); EL : l i s t o f Element = F V -> G etA ssociatedW ith(); in f o r a l l V : Element in EL su ch th at i f (V i s a CompositeTask) then i f (g e t V as Com positeTask.H idden) th en RemoveChildren(V as CompositeTask) end i f end i f end f o r a l l l e t AbsE : C hild = new C hild a sso c E; in add edge AbsE end l e t end l e t e l s e i f (E is a Im p lic itS u c c e sso r ) then l e t AbsE : Im p lic itS u c c e sso r = new Im p lic itS u c c e sso r in add edge AbsE end l e t end i f end i f end i f end fun AddEdge; end a b s tr a c tio n C om positionA bstraction; - - g rap h ic o b je c t d e f in it io n s boxgraphic BaseGraphic is a t t r ib u t e s L evel : i n t ; end a t t r ib u t e s ; a sso c lo o k Normal i s hbox t e x t a t t r ib u t e L evel; end hbox end lo o k Normal; end boxgraphic B aseG raphic; i boxgraphic TaskBox is a BaseGraphic i s a t t r ib u t e s TaskName : s tr in g ; EndDate : in t; end a t t r ib u t e s ; lo o k T ask N on C ritical i s hbox t e x t a t t r ib u t e TaskName; t e x t a t t r ib u t e EndDate; end hbox end lo o k T askN onC ritical; ! lo o k T a sk C r itic a l i s border brush s o lid 3; c o lo r red; - - b o ld /r e d l i n e 1 hbox t e x t a t t r ib u t e TaskName; t e x t a t t r ib u t e EndDate; end hbox end lo o k T a sk C r itic a l; end boxgraphic TaskBox; boxgraphic CompositeTaskBox i s a t t r ib u t e s TaskName : s tr in g ; EndDate : in t ; end a t t r ib u t e s ; lo o k C om positeN onC ritical i s border brush s o lid 1; c o lo r b lu e; hbox t e x t a t t r ib u t e TaskName; t e x t a t t r ib u t e EndDate; end hbox end lo o k C om positeN onC ritical; lo o k C o m p o siteC ritica l i s border brush s o lid 3; c o lo r b lu e; hbox t e x t a ttr ib u te TaskName; t e x t a ttr ib u te EndDate; end hbox end look C o m p o site C r itic a l; lo o k CompositeHidden i s border brush s o lid 5; c o lo r b lack ; hbox t e x t a ttr ib u te TaskName; t e x t a ttr ib u te EndDate; end hbox end lo o k CompositeHidden; end boxgraphic CompositeTaskBox; lin e g r a p h ic S u ccessorL in e i s lo o k S u ccesso rN o n C ritica l i s l i n e arrowhead end lo o k S u ccesso rN o n C ritica l; lo o k S u c c e s s o r C r itic a l i s l i n e brush s o lid 3; c o lo r red; arrowhead end lo o k S u c c e s s o r C r itic a l; end lin e g r a p h ic S u ccessorL in e; lin e g r a p h ic C hildL ine i s lo o k ChildNormal i s l i n e c o lo r b lu e; arrowhead — b o ld li n e end lo o k ChildNormal; end lin e g r a p h ic C hildL ine; lin e g r a p h ic Im p lic itS u c c e sso r L in e i s lo o k Im p lic itS u c c e sso r N o n C r itic a l i s l i n e brush dashed 1; arrowhead end lo o k Im p lic itS u c c e sso r N o n C r itic a l; lo o k I m p lic itS u c c e s s o r C r itic a l i s l i n e brush dashed 1; c o lo r red; arrowhead end lo o k I m p lic itS u c c e s s o r C r itic a l; end lin e g r a p h ic Im p lic itS u c c e sso r L in e ; com posite g rap h ic TaskDependenceGraphChart i s fu n l i s t o f BaseGraphic G etA 110nLevel(I : in t ) = l e t VL : l i s t o f BaseGraphic = f i n d a l l G : Graphic in GetMembersO 266 su ch th a t i f (G is a BaseG raphic) th en (g e t G as B aseG raphic.L evel) == I e l s e FALSE end i f i end f i n d a l l ; ' in , V L end l e t | end fu n G etA llO nL evel; fu n BaseGraphic FindL astO nL evel(I : in t) = l e t V L : l i s t o f BaseGraphic = G etA llO n L ev el(I); j C M : C onstraintM anager = GetCMO; ;L : BaseG raphic = ! fin d o n e G : BaseGraphic in V L su ch th a t l e t V : G C onstraintV ertex = CM ->G etA ssociatedV ertex(G ); in ! ! ( e x i s t s E : Edge in C M ->G etIncidentE dgesT hisFirst(V ) ■ su ch th a t i f (E is a GBeforeEdge) then (g e t E as GBeforeEdge.Dim) == YDIM e ls e ! FALSE end i f end e x i s t s ) end l e t end fin d o n e; in L end l e t end fun FindLastOnLevel; — T his fu n c tio n w i l l update th e Y b efo re c o n s tr a in ts so — th a t th e v e r te x i s removed from i t s cu rrent l e v e l , fu n v o id RemoveFromLevel(V : BaseGraphic) = l e t C M : C onstraintM anager = GetCMO; A : G C onstraintV ertex = C M ->G etA ssociatedV ertex(V ); EBefore : GConstraintEdge = fin d o n e E : Edge in CM ->GetIncidentEdgesThisSecond(A) su ch th a t i f (E is a GBeforeEdge) th en (g e t E as GBeforeEdge.Dim) == YDIM e l s e FALSE end i f end fin d o n e; E A fter : GConstraintEdge = fin d o n e E : Edge in C M ->G etIncidentE dgesT hisFirst(A ) su ch th a t i f (E is a GBeforeEdge) th en (g e t E as GBeforeEdge.Dim) == YDIM e l s e FALSE end i f end fin d o n e; in i f (E Before != NULL) th en i f (E A fter != NULL) then l e t Cl : G C onstraintV ertex = E B efo re -> G etF ir stV ertex (); C2 : G C onstraintV ertex = E A fter-> G etS econ d V ertex(); in add c o n str a in t y 2 b efo re C1,C2 end l e t d e le t e c o n s tr a in t EBefore d e le te c o n s tr a in t EA fter e l s e d e le te c o n s tr a in t EBefore end i f e l s e i f (E A fter != NULL) th en d e le te c o n s tr a in t EA fter end i f end i f end l e t end fu n RemoveFromLevel; fun l i s t o f LineG raphic GetPredLines(BG : BoxGraphic) f i n d a l l L : LineG raphic in G etL ineG raphicsO su ch th a t i f (L i s a S u ccessorL in e) then L->GetSecondBox() == B G e l s e FALSE end i f end f in d a ll end fu n G etS u ccesso rL in es; fun l i s t o f LineG raphic G etSuccessorLines(BG : BoxGraphic) = f i n d a l l L : LineG raphic in G etL ineG raphicsO I su ch th at ! i f (L is a S u ccessorL in e) then L -> G etF irstB ox() == B G ; e l s e ; FALSE end i f end f i n d a ll end fun G etS u ccessorL in es; fun l i s t o f BoxGraphic G etSuccessorBoxes(BG : BoxGraphic) = j l e t iSL : l i s t o f LineG raphic = G etSuccessorL ines(B G ); in f i n d a l l T : BoxGraphic in GetBoxGraphics() su ch th a t i f (T is a TaskBox) then t ! e x i s t s L : LineG raphic in SL su ch th at L->GetSecondBox() == T end e x i s t s i e l s e FALSE end i f end f i n d a l l end l e t end fun G etS u ccessorB oxes; — T his fu n c tio n w i l l retu rn th e l a s t su c c e sso r o f a v e r te x . — But w i l l not retu rn N B as th e l a s t su c c e ss o r . fun BoxGraphic G etLastSuccessor(BG : BoxGraphic, N B : BoxGraphic) l e t C M : ConstraintM anager = GetCMO ; in fin d o n e G : BoxGraphic in G etSuccessorBoxes(BG ) su ch th a t i f (G i s a TaskBox) th en i f (G != NB) then l e t V : G C onstraintV ertex = CM ->G etAssociatedVertex(G) ; in ! ( e x i s t s E : Edge in CM ->G etIncidentEdgesThisSecond(V) su ch th at (E i s a GBeforeEdge) & & (g e t E as GBeforeEdge . Dim == YDIM) end e x i s t s ) end l e t e l s e FALSE end i f e ls e FALSE end i f end fin d o n e end l e t end fun G etL a stS u ccesso r; — T his fu n c tio n w i l l put V in to L ev el. fun v o id AddToLevel(V : BaseG raphic, L evel : i n t , AssocV : BaseG raphic) = l e t C M : ConstraintM anager = GetCMO ; in i f (AssocV == NULL) th en l e t L V : BaseGraphic = F ind L astO n L evel(L evel); in i f (LV != NULL) then i f (LV != V) then l e t Cl : G C onstraintV ertex = C M ->G etA ssociatedVertex(LV); C2 : G C onstraintV ertex = C M ->G etA ssociatedV ertex(V ); in add c o n s tr a in t y 2 b e fo r e C1,C2 end l e t end i f end i f end l e t e l s e — F i r s t , recon n ect th e b e fo r e s so th a t th e AssocV — no lo n g er i s used as b e fo r e , l e t A V : G C onstraintV ertex = C M ->G etA ssociatedV ertex(A ssocV ); EBefore : l i s t o f Edge = f i n d a l l E : Edge in C M ->G etIncidentEdgesThisFirst(A V) 270 su ch th at i f (E is a GBeforeEdge) th en (g e t E as GBeforeEdge.Dim) == Y D IM e l s e FALSE end i f end f in d a ll ; in f o r a l l EB : l i s t o f Edge in EBefore su ch th at l e t Cl : G C onstraintV ertex = E B ->G etSecondV ertex(); C2 : G C onstraintV ertex = C M ->G etA ssociatedV ertex(V ); in add c o n str a in t y 2 b e fo r e C2,C1 end l e t ~ d e le t e c o n s tr a in t EB as GBeforeEdge end f o r a l l end l e t " - - Now add th e b efo re betw een AssocV and V. l e t Cl : G C onstraintV ertex = C M ->G etA ssociatedV ertex(A ssocV ); C2 : G C onstraintV ertex = C M ->G etA ssociatedV ertex(V ); in add c o n s tr a in t y 4 b efo re C1,C2 end l e t end i f s e t V .L evel to L evel end s e t end l e t end fun AddToLevel; fun v o id A ddN eighborC onstraints(V l : BaseG raphic, V2 : BaseG raphic) = l e t C M : ConstraintM anager ~ GetCMO ; AVI : G C onstraintV ertex = C M ->G etA ssociatedV ertex(V l); AV2 : G C onstraintV ertex = C M ->G etA ssociatedV ertex(V 2); Succ : l i s t o f LineGraphic = G etS u ccesso rL in es(V I); IncidentE dgesV l : l i s t o f Edge = C M ->G etIncidentEdges(A V l); Pred : l i s t o f LineG raphic = G etP redL ines(V 2); IncidentEdgesV 2 : l i s t o f Edge = CM->GetIncidentEdges(AV2) ; in 271 in f o r a l l L : LineG raphic in Succ su ch th at l e t SB : BoxGraphic = L->G etSecondB ox(); SV : G C onstraintV ertex = C M ->G etA ssociatedV ertex(SB ); — Find e x is t in g c o n s tr a in t betw een V2 and o th er su c c e sso r C : Edge = fin d o n e E2 : Edge in IncidentEdgesV 2 su ch th at i f (E2 is a GNeighborEdge) th en i f (E 2 -> G etF irstV ertex() == (AV2 as V ertex )) th en E 2->G etSecondV ertex() == (SV as V ertex) e ls e E 2-> G etF irstV ertex () == (SV as V ertex) end i f e l s e FALSE end i f end fin d o n e; i f (C == NULL) th en l e t Cl : G C onstraintV ertex = SV; C2 : G C onstraintV ertex = AV2; in i f (Cl != C2) then add c o n s tr a in t y 5 neighbor Ci,C2 end i f end l e t e l s e l e t CE : GNeighborEdge = C; P : in t = C E -> G etP rio rity (); in C E ->S etP riority(P + 2) end l e t end i f end l e t end f o r a l l f o r a l l L : LineG raphic in Pred su ch th at l e t SB : BoxGraphic = L -> G etF irstB o x (); SV : G C onstraintV ertex = C M ->G etA ssociatedV ertex(SB ); 272 m — Find e x is t in g c o n s tr a in t betw een V2 and o th er su c c e sso r C : Edge = fin d o n e E2 : Edge in IncidentE dgesV l su ch th at i f (E2 is a GNeighborEdge) th en i f (E 2-> G etF irstV ertex() == (AVI as V ertex )) th en E2->G etSecondV ertex() == (SV as V ertex) e ls e E 2-> G etF irstV ertex() == (SV as V ertex) end i f e ls e FALSE end i f end fin d o n e; i f (C == NULL) then l e t Cl : G C onstraintV ertex = SV; C2 : G C onstraintV ertex = AVI; in i f (Cl != C2) then add c o n s tr a in t y 5 neighbor C1,C2 end i f end l e t e l s e l e t C E : GNeighborEdge = C; P : in t = C E -> G etP rio rity (); in C E ->SetP riority(P + 2) end l e t end i f end l e t end f o r a l l end l e t end fun A ddN eighborC onstraints; fu n b o o l AddVertex (V :V ertex) = i f (V is a Task) th en l e t B : TaskBox.= new TaskBox a sso c V; in s e t B.TaskName to g e t V as Task.Name end s e t 273 s e t B.EndDate to g e t V as Task.EndDate end s e t atom ic add boxgraphic B - - Don’t th in k t h is i s same le v e l as 0 s e t B .L ev el to -1 end s e t AddToLevel(B as BaseGraphic,0,NULL) end l e t e l s e i f (V is a CompositeTask) then l e t B : CompositeTaskBox = new CompositeTaskBox a sso c V; in s e t B.TaskWame t o g e t V as CompositeTask.Name end s e t s e t B.EndDate to g e t V as CompositeTask.EndDate end s e t s e t B.Look to C om positeN onC ritical end s e t atom ic add boxgraphic B end l e t end i f end i f TRUE end fun AddVertex; fun v o id D eleteP reviou sN eigh b orC on strain ts(G : BoxGraphic) = l e t C M : ConstraintM anager = GetCMO ; V : G C onstraintV ertex = CM ->G etA ssociatedV ertex(G ); EL : l i s t o f Edge = CM ->G etIncidentEdges(V ); in f o r a l l E : Edge in EL su ch th at i f (E is a GNeighborEdge) then l e t N E : GNeighborEdge = E; in d e le te c o n str a in t N E end l e t end i f end f o r a l l end l e t end fun D eleteP rev io u sN eig h b o rC o n stra in ts; fu n b o o l AddEdge (E:Edge) = i f (E is a S u ccesso r) th en l e t L : S u ccessorL in e = new S u ccessorL in e a sso c E; in atom ic add lin e g r a p h ic L end l e t — Need to p la c e V2 to r ig h t o f VI l e t VI : V ertex = E -> G e tF ir stV e r te x (); BG1 : BaseGraphic = fin d o n e E : Element in V l-> G etA ssociatedW ith() su ch th at E i s a BaseGraphic end fin d o n e; V ILevel : in t = g e t BG1.Level; V2 : V ertex = E ->G etSecondV ertex(); BG2 : BaseGraphic = fin d o n e E : Element in V 2->G etA ssociatedW ith() su ch th at E i s a BaseGraphic end fin d o n e; V2Level : in t = g e t BG2.Level; in i f (V2Level > V IL evel) then — V2 i s alread y to th e r ig h t o f Vi add c o n s tr a in t x 2 b efo re BG1.BG2 e ls e — V2 needs to change l e v e l RemoveFromLevel(BG2) D eleteP reviousN eigh b orC on strain ts(B G 2) — Put V2 im m ediately r ig h t of Vi add c o n str a in t x 2 b e fo r e BG1,BG2 add c o n s tr a in t x 2 neigh b or BG1,BG2 — In se r t V2 in to cu rrent le v e l l e t VLast : BaseGraphic = G etL astSuccessor(B G i3BG2); NewLevel : in t = (g e t BG 1.Level) + 1; in 275 AddT oLevel(BG 2, NewLevel, VLast) end l e t end i f ~ — A sso c ia te V2 w ith oth er su c c e sso r s o f VI AddNeighborConstraints(BG1,BG2) " — Add in th e cen ter c o n str a in ts l e t C M : ConstraintM anager = GetCMO; CV1 : G C onstraintV ertex = CM ->G etAssociatedVertex(BGl) CV2 : G C onstraintV ertex = CM ->GetAssociatedVertex(BG2) C : GCenterVertex = CM->GetCenterVertex(CVl,NULL); in i f (C != NULL) th en add c o n str a in t y 3 ce n te r CV2,C e l s e add c o n str a in t y 3 cen ter CV2,CV1 end i f end l e t end l e t e l s e i f (E is a C hild) then l e t L : C hildL ine = new C hildL ine a sso c E; in atom ic add lin e g r a p h ic L end l e t e ls e i f (E i s a Im p lic itS u c c e sso r ) th en l e t L : Im p licitS u cc esso rL in e = new Im p licitS u cc esso rL in e a sso c E; in atom ic add lin e g r a p h ic L end l e t end i f end i f end i f TRU E end fu n AddEdge; fun b o o l TouchVertex (V :V ertex) = i f (V is a Task) th en l e t A L : l i s t o f Element = V -> G etA ssociatedW ith(); in f o r a l l E : Element in A L su ch th at i f (E is a TaskBox) then i f (g e t V as T a s k .C r itic a l) then s e t E as TaskBox.Look to T a sk C r itic a l end s e t e l s e s e t E as TaskBox.Look to T askN onC ritical end s e t end i f s e t E as TaskBox . TaskName to g e t V as Task.Name end s e t s e t E as TaskBox. EndDate to g e t V as Task.EndDate end s e t end i f end f o r a l l end l e t e l s e i f (V is a CompositeTask) th en l e t A L : l i s t o f Element = V -> G etA ssociatedW ith(); in f o r a l l E : Element in A L su ch th at i f (E is a CompositeTaskBox) th en i f (g e t V as Com positeTask.Hidden) then s e t E as CompositeTaskBox.Look to CompositeHidden end s e t e l s e i f (g e t V as C om p ositeT a sk .C ritica l) th en s e t E as CompositeTaskBox.Look to C o m p o siteC ritica l end s e t e ls e s e t E as CompositeTaskBox.Look to C om positeN onC ritical end s e t end i f end i f 277 s e t E as CompositeTaskBox . TaskName to g e t V as CompositeTask.Name end s e t s e t E as CompositeTaskBox. EndDate to g e t V as CompositeTask.EndDate end s e t end i f end f o r a l l end l e t end i f end i f TRUE end fun TouchVertex; fun b o o l TouchEdge (Ed:Edge) = i f (Ed i s a S u ccesso r) then l e t A L : l i s t o f Element = E d ->G etA ssociated W ith (); in f o r a l l E : Element in A L su ch th at i f (E is a S u ccessorL in e) th en i f (g e t Ed as S u c c e s s o r .C r itic a l) th en s e t E as SuccessorL ine.L ook to S u c c e s s o r C r itic a l end s e t e l s e s e t E as SuccessorL ine.L ook to S u ccesso rN o n C ritica l end s e t end i f end i f end f o r a l l end l e t e l s e i f (Ed is a Im p lic itS u c c e sso r ) then l e t A L : l i s t o f Element = Ed->G etA ssociatedW ith() in f o r a l l E : Element in A L su ch th at i f (E is a Im p licitS u cc esso rL in e) th en i f (g e t Ed as I m p lic itS u c c e s s o r .C r itic a l) I then s e t E as Im p licitS u ccesso rL in e.L o o k to i I m p lic itS u c c e s so r C r itic a l end s e t j e l s e ' s e t E as Im p licitS u ccesso rL in e.L o o k to ' Im p lic itS u c c e sso r N o n C r itic a l end s e t end i f , end i f I end f o r a l l end l e t . end i f i end i f " TRUE end fu n TouchEdge; end com posite grap h ic TaskDependenceGraphChart; i I view TaskDependenceGraphView i s gra p h ic TaskDependenceGraphChart; I end view TaskDependenceGraphView; i o p era tio n s fun v o id I n it () = l e t I V T : ViewTree = GetVTO; i G : Graph = GetGraphO; V : TaskDependenceGraphView = new TaskDependenceGraphView; A : C om positionA bstraction = new C om positionA bstraction; in VT->AddAbstraction(A,G) VT->AddView(V,A) end l e t end fu n I n i t ; fu n ViewTreeVertex G etAbsVertexO = l e t V T : ViewTree = GetVTO; V : V ertex = V T->G etView Vertex(); AbsVList : l i s t o f V ertex = V T ->G etP redecessors(V ); in i f (Em pty(AbsVList)) then ErrorC'No a b str a c tio n a s so c ia te d w ith view") v o id e ls e fin d o n e A : V ertex in AbsVList su ch th at i f (A is a ViewTreeVertex) then 279 l e t C : Component = VT->GetComponent(A as V iew T reeV ertex); in C is a C om positionA bstraction end l e t e l s e FALSE end i f end fin d on e end i f end l e t end fu n GetAbsVertex; fu n C om positionA bstraction GetAbsO = l e t V : ViewTreeVertex = GetAbsVertexO ; VT : ViewTree = GetVTO; in i f (V == v o id ) then Error("Cannot fin d a b s tr a c tio n ." ) ~ v o id e ls e VT->GetComponent(V) end i f end l e t end fun GetAbs; — These fu n c tio n s are used fo r communication w ith — th e c o n s tr a in t graph e d ito r . e x te r n a l fun v o id SendAddVertexInfo(V : V e r te x ); e x te r n a l fun v o id SendAddEdgelnfoCE : E d ge); e x te r n a l fu n v o id SendD eleteV ertexInfo(V : V e r te x ); e x te r n a l fun v o id SendD eleteE dgeInfo(E : Edge); e x te r n a l fu n v o id SendTouchVertexInfo(V : V e r te x ); e x te r n a l fun v o id SendTouchEdgeInfo(E : E d ge); e x te r n a l fun v o id H andleC lientR equest(R equest : s t r i n g ) ; e x te r n a l fun v o id H andleServerR equest(R equest : s t r in g ) ; command Compose i s fu n b o o l E xecute () - l e t SG : l i s t o f Graphic = G etS elected G rap hicsO ; VT : ViewTree = GetVTO; Ops : NewOps = GetOpsO; in i f (Empty(SG)) then Error("M ust s e l e c t a Composite Task b e fo r e t h i s o p e r a tio n ." ) 280 e ls e f o r a l l S : Graphic in SG su ch th at l e t E : Element = V T~>G etAssociatedG raphData(S); in i f (E i s a CompositeTask) then l e t A : C om positionA bstraction = O ps->G etA bs(); in i f (A != v o id ) then i f (A is a C om positionA bstraction) then s t a r t tr a n s a c tio n A " A->Expose(E as CompositeTask) commit tr a n sa c tio n A e ls e ErrorC'Mot a com p osition a b s tr a c tio n .'1 ) end i f e l s e ErrorC'No a b str a c tio n a s s o c ia te d w ith v ie w .1 ') end i f end l e t e ls e Error("Can on ly s e le c t Composite Tasks") end i f end l e t end f o r a l l end i f end l e t end fun E xecute; end command Compose; command Decompose i s fu n b o o l E xecute () = l e t SG : l i s t o f Graphic = G etS elected G rap hicsQ ; V T : ViewTree = GetVTO; Ops : NewOps = G etO psO ; in i f (Empty(SG)) then Error("M ust s e le c t a Composite Task b e fo r e t h i s o p e r a tio n ." ) e ls e f o r a l l S : Graphic in SG su ch th at l e t E : Element = VT->G etA ssociatedG raphD ata(S); in i f (E i s a CompositeTask) then l e t A : C om positionA bstraction = O ps->G etA bs(); 281 in i f (A != vo id ) then i f (A is a C om positionA bstraction) th en s t a r t tr a n s a c tio n A ~ A->Expose(E as CompositeTask) " commit tr a n sa c tio n A e ls e Error("Not a com p osition a b s tr a c tio n ." ) end i f e ls e ErrorC'Wo a b str a c tio n a s so c ia te d w ith v ie w ." ) end i f end l e t e ls e Error("Can on ly s e le c t Composite Tasks") end i f end l e t end f o r a l l end i f end l e t end fun E xecute; end command Decompose; command Expose i s fun b ool E xecute () = l e t SG : l i s t o f Graphic = G etS elected G rap hicsO ; V T : ViewTree - GetVTO; Ops : WewOps = G etO psO ; in i f (Empty(SG)) then ErrorC'Must s e le c t a Composite Task b e fo r e t h is o p e r a tio n ." ) e ls e f o r a l l S : Graphic in SG su ch th at l e t EL : l i s t o f Element = S -> G etA sso c(); in f o r a l l E : Element in EL su ch th at i f (E is a CompositeTask) th en l e t A : C om positionA bstraction = O ps->G etA bs(); in i f (A != v o id ) th en i f (A is a C om positionA bstraction) then s t a r t tr a n sa c tio n A A->Expose(E as CompositeTask) 282 commit tr a n sa c tio n A e ls e Error("Not a com p osition a b s tr a c tio n ." ) end i f e l s e ErrorC'Mo a b str a c tio n a s so c ia te d w ith v iew ." ) end i f end l e t e ls e Error("Can on ly s e le c t Composite Tasks") end i f end f o r a l l end l e t end f o r a l l end i f end l e t end fun E xecute; end command Expose; command Hide i s fun b o o l E xecute () = l e t SG : l i s t o f Graphic = G etS elected G ra p h icsO ; V T : ViewTree = GetVTO; Ops : NewOps = GetOpsO ; in i f (Empty(SG)) then ErrorO'Must s e le c t a Composite Task b e fo r e t h i s o p e r a tio n ." ) e ls e f o r a l l S : Graphic in SG su ch th at l e t EL : l i s t o f Element = S -> G etA sso c(); in f o r a l l E : Element in EL su ch th at i f (E is a CompositeTask) then l e t A : C om positionA bstraction = O ps->G etA bs(); in i f (A != vo id ) th en i f (A is a C om positionA bstraction) th en s t a r t tr a n sa c tio n A A->Hide(E as CompositeTask) commit tr a n s a c tio n A e ls e ErrorC'Wot a com position a b s tr a c tio n ." ) end i f 283 e l s e E rror{ "No a b s tr a c tio n a s so c ia te d w ith view , end i f end l e t e ls e ErrorC'Can on ly s e le c t Composite Tasks") \ end i f | end f o r a l l end l e t end f o r a l l end i f end l e t end fun E xecute; end command Hide; ^ command AddTaskDependenceGraphView i s fu n b o o l E xecute () = , l e t VT : ViewTree = GetVTO; G : Graph = GetGraphO ; V : TaskDependenceGraphView = new TaskDependenceGraphView; in , VT->AddView(V,G) end l e t end fun E xecute; end command AddUserView; command S ta r tC o n str a in tE d ito r i s fu n b o o l E xecute () = C onnectO SetA utoC lientO nQ SetAutoServerO nQ end fun E xecute; end command S ta rtC o n stra in tE d ito r ; menu Types "Element Types" checked i s Task : "Task" ; CompositeTask : "Composite Task" ; sep a ra to r Edges ; S u ccesso r : "Successor" ; C hild : "Child" ; end menu T ypes; menu Misc "Misc" i s AddTaskDependenceGraphView : "Add View" ; sep a ra to r A b stra ctio n ; Hide : "Hide"; Expose : "Expose"; sep a ra to r Connect ; S ta r tC o n str a in tE d ito r : " Start C on strain t Editor" end menu M isc; end o p e r a tio n s; end e d ito r TaskDependenceGraph;

Linked assets