Integrity Constraints in the Multi-paradigm Language ... - CiteSeerX

Download PDF
3 downloads 0 Views 108KB Size Report
Comment
Feb 13, 1998 - that the person gets a boarding pass that contains the per- son's flight coupon and leaves his or her luggage at the counter. Furthermore he or ...
Integrity Constraints in the Multi-paradigm Language PROGRES Manfred Münch, Andy Schürr, Andreas Winter [email protected]

Declarative Systems and Software Engineering Group Technical Report DSSE-TR-98-2 February 13 1998

Department of Electronics and Computer Science University of Southampton Highfield, Southampton, SO17 1BJ, United Kingdom

published in:

Integrity Constraints in the Multi-paradigm Language PROGRES M. Münch

A. Schürr, A. Winter

Dept. of Electronics and Computer Science University of Southampton, Highfield, Southampton, SO17 1BJ, United Kingdom email:[email protected]

Lehrstuhl für Informatik III, RWTH Aachen Ahornstr. 55, D-52074 Aachen, Germany email: [andy|winter]@i3.informatik.rwth-aachen.de http://www-i3.informatik.rwth-aachen.de/people/{andy|winter}

Abstract: PROGRES is a multi-paradigm visual programming or executable specification language, which has a well-defined static type concept. It supports programming with graph rewriting systems. An integrated type-checker is able to check the static semantics of a specification. This paper presents the integration of static integrity constraints to the language which allow to check a specification’s integrity at run-time.

compile-time whether rules produce inconsistent data configurations or not. In contrast to rule-based languages there are some visual dataflow languages which have a static type concept. Such a static type concept enables the system to validate a program at compile-time. PROGRES combines the well-known class diagrams of object-oriented languages with graph rewriting rules. Its language is statically typed, i.e. we have a two-level polymorphic type system with the ability of multiple inheritance. With the help of type information an integrated analyzer can assert the correctness of a specification regarding its static semantics. That means that rules produce only graphs which fulfil the requirements of the specified class diagrams, i.e. edges in a graph may only connect nodes of a determined type etc. Incorrect expressions are marked and an appropriate error message is given to the user.

Keywords & Phrases: graph rewriting systems, visual programming languages, static/active integrity constraints

1. Introduction At the beginning research on visual programming languages dealt with graph grammars and graph rewriting systems. Some early visual programming languages such as Plan2D [3] are indeed graph rewriting languages. Although the development of visual programming languages and the research on graph grammars separated more and more ideas have been developed recently to combine both of them again. Graph grammars are often used for the definition of the syntax and semantics of visual languages like in DiaGen [7]. Beyond that there are a still growing number of visual languages that rely directly on the graph rewriting paradigm, such as Ludwig2 [11] or GOOD [9].

The integrated analyzer is a powerful tool. However, most (static) integrity constraints are not definable as a class diagram. Therefore we need a separate constraint definition language. OOA/OOD languages usually either use informal constraint definitions or first order logic for this purpose. In PROGRES we integrated an approach which is similar to the Object Constraint Language OCL of the Unified Modelling Language UML (see [12] for further details concerning UML and OCL). The difference to this approach is that we do not only offer a textual constraint definition language, but denote our constraints graphically, too.

Graph rewriting languages are a subclass of increasing importance of visual languages because of their ability to describe complex operations in a visual way with a precise semantics. A number of applications can be found e.g. in Computer Integrated Manufacturing systems [17]. Engineers who model many things with graphs and are not used to program a computer every day benefit from this kind of languages.

This paper presents the integration of integrity constraints into the PROGRES programming language. The main design goal was to support the user to debug a specification at run-time. We have also adopted the idea of active integrity constraints from active database systems. This allows the user to specify a repair action if a constraint is not met.

In this paper we will focus on PROGRES (PROgramming with Graph REwriting System). It is a visual programming language in the sense that it has a graphoriented data model and a graphical syntax for its most important language constructs. We distinguish between data definition and data manipulation and do not rely on the rule-oriented programming paradigm for all purposes.

In the next section related work will be discussed. Section 3 introduces the reader to the PROGRES language. Section 4 discusses the integrity constraints. Section 5 deals with active constraints, an extension of the static integrity constraints. In section 6 the evaluation strategy of constraints will be discussed. Section 7 deals with the results of these new features and shows the possibilities for future research.

Most rule-based visual programming languages are untyped languages, i.e. processed data is only implicitly defined by the set of their rules. Even those languages which combine rules with class diagrams do not check at 1

2. Related Work

rewritten in equivalent horn clause logic expressions. However, these constraints are only a subset of the constraints we want to be able to define in PROGRES. Another serious disadvantage of G-Log is that there is no implementation yet.

The semantics of PROGRES is developed on the basis of the logic-based graph grammar theory (see [8]). One of the main purposes of the system is to generate visual programming environments. PROGRES is a visual programming language itself enriched by some textual language constructs. In the same class of languages VAMPIRE [6] can be found. It has also a graphical class editor to construct a hierarchy for a rule-based visual programming language. As in PROGRES the “objects” (icons or nodes, resp.) can be attributed. The purpose of VAMPIRE to generate visual programming environments is the same as of our system. However, VAMPIRE does not have a rigid type concept and comes without any type checking tools. DiaGen is another language which relies directly on graph rewriting [7]. In DiaGen a hypergraph parser is implemented which can guarantee the syntactical correctness of a given diagram. In contrast to PROGRES the DiaGen language does not have any type concept or integrity constraints. The same arguments are valid for Ludwig2 [11] as well as GOOD [9]. Other rule-oriented languages are Agentsheets [13] and ChemTrains [2]. Although the user of either of these languages is able to draw rules on a high level of abstraction neither support their users to check the well-formedness of rules by any kind of typing system. Also other conditions to certify the correct behaviour of a program are not provided. Therefore, all these systems postpone the recognition of programming errors to run-time and suffer from the same disadvantages as any untyped or weakly typed programming language. Constraint languages are well-known in database systems. Since many years constraints are used in active database systems in order to ensure the integrity of a database [1, 16]. C. Bauzer Medeiros gives a good definition of those integrity constraints in [1]: An integrity constraint in a database environment is a statement of a condition that must be met in order to maintain data consistency. Bauzer Medeiros presents a language called ALICE/RL (Assertion Language for Integrity Constraint Expressions/ Rule Language). This language (or a variation of it) is used in active database environments and consists of Event-Condition-Action triples where an action is triggered if the condition holds after the occurence of a specified event. This action can be seen as a sort of repair action. The ideas of defining a condition which has to be met and otherwise executing a repair action has directly been transferred to PROGRES. The disadvantage of ALICE/RL is that it allows its users only a textual definition of first order logic expressions instead of a visual representation for its constraint expressions. A visual representation of constraints is supported by the language G-Log (see [10]). G-Log constraints can be

Another inspiring approach for this work was the integration of graphical constraints to graph grammars based on the category theory [4]. Although some ideas could be taken over this approach aims for different goals such as verification of graph grammars. Furthermore there is no implementation currently available. We will discuss the visual representation of constraints w.r.t. visual programming with the graph rewriting system PROGRES.

3. The PROGRES Language A PROGRES specification is composed of two parts. The first part describes the static properties of a class of graphs. The second part defines the operations that can be applied to the graph. Operations are graph manipulations which are denoted as graph rewriting rules. In the following we will present both parts of a specification. The first part describes the class diagram of a graph consisting of the definitions for nodes and edges of this graph. Nodes are considered to be independent objects. These nodes are defined by classes. Classes can be either abstract, i.e. without any instances, or concrete. It is also possible to construct an inheritance hierarchy over classes. The example in fig. 1 shows an abstract class AIRCRAFT. The two classes Boeing737 and Boeing747 inherit all properties of this class (denoted by dashed lines). Also the class Gate inherits the properties of the abstract class AIRPORT_ENTITY.

Fig. 1: Definition of a class diagram

Node classes can contain attribute definitions. These attribute definitions can also be redefined in subclasses 2

2. Replace the selected redex by a copy of its right-hand side, but preserve all those nodes and their context and attribute values which are shared among its left- and right-hand side.

(which has not been done in the example of fig.1). In PROGRES there are different kinds of attributes: • intrinsic attributes: at run-time arbitrary assignments can be made to these attributes. The values must conform to the type of the attribute. They can contain integer values, boolean values etc. • derived attributes: these attributes contain values which are computed by the specified evaluation function. That means that no explicit value is assigned to these attributes but its value is computed implicitly. This includes derived relations between different nodes. Fig. 1 shows an example of a node class definition with attribute definitions. In this figure two abstract node classes are defined: AIRCRAFT and AIRPORT_ENTITY. Abstract node classes are represented by rectangular boxes. The former definition contains several attributes such as Max_Weight, Range, Airline etc. These attributes are all intrinsic attributes. This is modelled by circles which are connected by a single line to the node class definition. The type of the attributes is attached to the circles, the name of this attribute to the connecting line. Furthermore this graph schema contains several edge-type definitions. E.g. a node of the class PERSON may be connected to a node of the class AIRCRAFT (which can also be a node of a subclass of AIRCRAFT, i.e. Boeing737 or Boeing747, of course) by the edge sits_in. This edge describes that a person is sitting in an aircraft. Boeing737 and Boeing747 are concrete classes which inherite all properties of the abstract class AIRCRAFT (denoted by the dashed is_a-edge). Concrete classes are represented by rectangular boxes with round edges. Edges represent binary relationships between nodes. Their definition contains the type (“identifier”) of the edge and the two node classes that serve as the source, resp. target, class of this edge. In contrast to nodes, edges cannot be considered as independent objects. They do not possess attributes or identifiers and they are implicitly deleted if their source or target will be deleted. Paths can be defined in the declarative part of a specification to express derived relations between nodes. Their syntax and semantics is not discussed here. For further details please refer to [15]. After the class diagram is defined in the first part of a specification, in the second part of a specification the operations on a graph are described. This graph is called the hostgraph. The operations can be divided into two different language constructs: productions and transactions. Modifications of a graph are realized by productions. These are graph rewriting rules which are denoted diagrammatically. All productions have a left-hand side and a right-hand side. The application of such a production is divided into two parts: 1. Find a subgraph, termed redex, in a given hostgraph that matches the production’s left-hand side.

Fig. 2 and 3 show some examples for productions.

Fig. 2: The production Check_In

The production in fig. 2 describes the usual check in procedure at an airport. A person holding (a valid) flight coupon and probably one or more suitcases waits at the counter to check in. If this configuration can be found in the hostgraph the production can be executed. That means that the person gets a boarding pass that contains the person’s flight coupon and leaves his or her luggage at the counter. Furthermore he or she passes on to wait at the gate for boarding the aircraft. The rectangular solid boxes denote nodes in the hostgraph which have to be found. Nodes with dashed lines are optional, i.e. the specified production can be executed although these nodes have not been found. Double rectangulars match a set of nodes. In this production the node with identifier ‘2 on the lefthand side, which is of the class LUGGAGE, matches a set of nodes of maximal size (which may also be empty - indicated by a dashed border of the rectangle). The arrows represent edges in the graph. On the left-hand side of the production a graph pattern is identified and replaced by the graph pattern which is specified on the right-hand side of our production. The notation x’ = ‘x means that these nodes are replaced identically. Nodes which appear on the left-hand side only will be deleted (see fig.3), even if they are shared, and nodes that appear on the right-hand side only are newly created (e.g. the boarding pass in fig. 2). The same happens to edges. The new subgraph is embedded automatically, unless otherwise stated (see [15]). Identically replaced nodes will be embedded into the graph preserving any edges to nodes which were not matched by 3

the production. Dangling edges which can occur if a node is deleted will be removed.

These are the most important features of the PROGRES language to understand the explanations in the following.

The next example shows the boarding procedure in fig. 3. If there is an aircraft standing at a gate and a passenger holding a boarding pass is waiting there this passenger may board the aircraft. He gives away his boarding pass, i.e. it will be deleted from the hostgraph, and makes himself comfortable in the aircraft. Note that nodes are independent objects and must be explicitly deleted by a production. There is no garbage collector which deletes ’unconnected’ nodes implicitly.

4. Integrity Constraints This section addresses the integrated constraints. First the different forms of passive constraints will be explained which allow for an integrity check of a specification. After that active constraints will be presented in the next section. Active constraints are extended by an action that can be triggered if a specified condition does not hold. The PROGRES environment supports the user with many useful tools. One of the most powerful ones is the analysis tool. It works incrementally and because of the strict type concept it is capable of checking the static semantics with the help of more than 300 consistency rules. Although this tool covers many sources of errors one of the most important cannot be checked: the "integrity" of a specification. That means that the user cannot ensure that the graph which is built up by his specification always meets some conditions beyond the type consistency. This is a major deficiency for large specifications. For this reason a couple of different constraint expression have been added to PROGRES. As aforementioned there are two different classes of constraints: passive constraints and active constraints. The former can be partitioned into four groups: • graphical global graph consistency conditions • textual global graph consistency conditions, which are not addressed in this paper • local (textual) constraints of node classes, which are called constraint attributes • textual (graphical) pre- and postconditions to productions and transactions

Fig. 3: Boarding a plane

Another language construct that is available in the operational part of a specification are transactions. Transactions are denoted textually and provide deterministic as well as nondeterministic control structures to combine operations. Fig. 4 shows a transaction which prepares an aircraft to be ready for take off. First the passengers have to check in and after that they board the aircraft and the luggage is loaded into it. The latter two operations are connected by the nondeterministic and-operator. That means that the order of the evaluation is not important in contrast to the deterministic ’&’ (concatenation)-operator. These operations are executed as long as there is a passenger waiting at the check in counter. After that the aircraft is ready to depart.

4.1. Global Graph Consistency Global graph consistency conditions (which will be called global constraints in the following) enable the user of the PROGRES system to specify graph patterns which have to be present in a hostgraph at any time or which may never appear. This has the same semantics as an existentially quantified expression. It is also possible to specify an universally quantified expression. We will demonstrate these different possibilities by a couple of examples.

Fig. 4: Transaction for making the aircraft ready for the take-off

Fig. 5: Existentially quantified constraint

4

The first example (fig. 5) shows a constraint with an existentially quantified semantics. This constraint claims that there must be (at least) one Airport, one Gate and one Check-In Counter in the hostgraph. These objects must be linked together by the specified edges. Otherwise it is not possible to serve an aircraft and the passengers. The textually denoted condition to this constraint expresses that there must be a minimum number of employees working at this airport to run all services properly. First the specified graph pattern is matched to the hostgraph. After that the textually defined condition is evaluated for all found matches. If there is no such graph pattern where this condition holds the constraint is not met. Certainly, this kind of specifying constraints is not enough to express all possible conditions which must hold on a graph. Particularly with global constraints it is very helpful to be able to postulate universally quantified expressions. Fig. 6 shows a constraint which denotes the following first order logic formula:

the help of constraints the user is able to find those errors and correct them in the specification. 4.2. Pre- and Postconditions Constraints are a general instrument to check the integrity of a hostgraph. A disadvantage of global constraints is that they always have to be fulfilled. For many purposes it would be very helpful to have conditions which are valid for only one operation. The application of some operations require a certain state of the hostgraph which is very difficult to express in terms of a global constraint. This is the reason why we have integrated preconditions to operations into the PROGRES language. Consider the example of fig. 4. This operation may only be applied to a hostgraph if there is an aircraft waiting at a gate. Otherwise it would not make any sense to board a plane or to load luggage into it. This transaction requires a certain state of the hostgraph. Fig. 7 describes this situation.

∀ Aircraft : Transports(Aircraft, Luggage ) → (∃Person: owns(Person, Luggage) ∧ sits_in(Person, Aircraft)).

This formula claims that for all aircrafts that transport luggage there must be a person who owns this luggage and is a member of the set of persons sitting in the aircraft.

Fig. 6: Universally quantified constraint

Note that the owns-edge was never affected, i.e. deleted or changed, by the productions Check_In or Boarding. In PROGRES the predicates of the formula above are represented by edges and the variables by nodes (independent objects). Thereby every match of the for-part of the constraint in fig. 6 must be extendible to a match of the ensurepart of that constraint. This is denoted by the nodes ‘1 and ‘2 in the ensure-part of the constraint. These are the same nodes which have been matched in the for-part. In summary one can say that graphs can contain semantical faults made by the specifier although the graph was built up conforming to the class diagram (see fig. 1). With

Fig. 7: Precondition to the transaction from fig. 4

To check the integrity of a single operation it is necessary to have postconditions as well. With postconditions the user is able to check if this operation has modified the hostgraph in the way he wanted it to be changed. If we consider the same transaction it should be made sure that 5

every piece of luggage which is owned by a passenger is in the aircraft and not left behind at the check-in office. The ensure-part of the transaction in fig.7 models this situation. This postcondition expresses that there may be no ownsedge (crossed-out edge) from any passenger sitting in the aircraft to a piece of luggage which is still at the check-in office. Both, pre- and postcondition call a test which may not fail. Otherwise the pre- or postcondition is not met. That means that there must be a match of the specified graph pattern in the hostgraph. Note that tests are always existentially quantified. The transaction and the tests shown in fig. 7 make use of parameters which can be passed to every operation in PROGRES. An expression like ‘x = Plane (as shown in both tests) claims that the match of this node must be exactly the node given in the parameter. (Appropriate values for those variables can be obtained by calling tests or productions with out-parameters; i.e. tests or productions can assign a node or a set of nodes to a variable and return it to the calling operation for further use). If a constraint, a pre- or a postcondition is not met the execution of the specification will immediately be stopped. The user will be informed with an appropriate message that a constraint, pre- or postcondition is not met and the relevant part of the specification will be highlighted.

In the following section we will present active constraints. These constraints are an extension of integrity (or passive) constraints. After that we will discuss some implementation details regarding the constraint checking algorithm.

5. Active Constraints In section 2 we have already discussed that active database management systems often use the language ALICE/RL or derivations of this language to denote constraint expressions. In this language the expressions consist of an EventCondition-Action triple. Integrity constraints, as introduced in section 4, can be compared with a combination of an event and a condition only. The action in ALICE/RL gives the user the chance to specify an operation which repairs the unfulfilled condition. This makes sense because the specifier often knows what is wrong if a constraint (or a condition) is not met. In PROGRES we have added such repair actions to global and local constraints. The example in fig. 9 shows the constraint of fig. 6. It expresses that every item of luggage in an aircraft must be owned by a passenger who sits in this aircraft. If the evaluation algorithm can identify any luggage that has no owner then the repair action is called. In this case the luggage will be unloaded.

4.3. Constraint Attributes Until now all constraints were associated with either the hostgraph or operations (pre- and postconditions). Beyond that it is also possible to bind a constraint to node classes. Therefore another kind of attribute, the constraint attribute, has been added to the language. Of course all constraint attributes have to be of boolean type. As with every other attribute, constraint attributes can be redefined as well. It is possible to define abstract constraint attributes, i.e. without an evaluation function, at node classes. The function will be bound at a subclass to this attribute. Fig. 8 shows such a situation. The NameOkattribute e.g. checks whether the attribute Name is not equal to the empty string.

Fig. 9: Universally quantified constraint with repair action

This process will be repeated as often as necessary. Only if the repair action was called but could not repair anything and the constraint is still unfulfilled, the execution will stop. This recursive process guarantees that all erroneous subgraphs will be repaired. Of course, such a repair action can violate another constraint again. The task to care about the termination problem is left to the user of the PROGRES language. In the following section we will discuss some topics concerning the evaluation strategy for constraints. We will see that another extension has been made to a PROGRES statement. Beyond that the flow of evaluation will be shown.

Fig. 8: Defining constraint attributes

Constraint attributes can be defined graphically as well. We have chosen the textual version here to demonstrate the use of the evaluation functions. 6

6. Evaluation Strategy

Only the evaluation of global constraints is limited to the section where the constraint is defined. This evaluation strategy does not affect local constraint attributes. These constraints are always evaluated, no matter to which section the graph modifying operation belongs. The reason is that nodes can be manipulated, i.e. created, deleted or the values of attributes may be modified, in every part of the specification. Therefore we cannot limit the evaluation to a certain set of nodes (e.g. the nodes which were matched and modified by an operation) but we have to check every possibly affected node in the hostgraph.

In PROGRES there is a language construct called section with which a specification can be partitioned into several syntactical units. Sections are not like a module. They are of a purely syntactical nature and do not determine the scope of operations. However, in connection with constraints sections are not only syntactical units anymore. There are some operations and some constraints in a specification that do not relate to each other. Assume you specify a constraint as in fig. 9 and the production Check_In as in fig. 3. This production is never able to modify the hostgraph in a way such that the aforementioned constraint becomes invalid. The reason is that the check-in production never creates or deletes a sits_in, transports or ownsedge. Beyond that this production does not create any new aircraft, a person or a piece of luggage nor does it delete one of these objects. That means neither the for-part nor the ensure-part of the constraint in fig. 9 is affected by the check-in production. Practice has shown that many specification writers divide their specifications vertically, i.e. thematically, by the use of sections. Therefore we decided to make an approximation of all possible detectable constraint violations, i.e. we check only those constraints that belong to the same section as the specified operations. Furthermore it makes sense to check the constraints of sections that contain the current section as a subsection. Fig. 10 illustrates this. The production Boarding in this example is checked against all constraints of the first section such as No_Forbidden_Luggage and Passengers_aboard. Transaction Make_Aircraft_ready on the other hand is checked against the constraint No_Forbidden_Luggage only because the section Passenger_Boarding is a subsection to section Aircraft_on_Ground. So any constraint defined in this subsection does not influence the semantics of any operation outside of this section. Therefore the production Land_Aircraft is only checked against the constraint Free_Runway. The advantage of this approach is a considerably better run-time behaviour and a clearer structure of large specifications. The complexity of the graph-pattern search algorithm which is the main defining quantity of the run-time behaviour will be discussed in the next section.

7. Implementation Aspects The PROGRES programming environment currently consists of about 750,000 lines of code, including the DBMS GRAS and the graphical user interface. It is available as free software on Solaris2 for Sun Workstations and on Linux for PC1. PROGRES is used for different purposes around the world. Meanwhile there are very large specifications which consist of about 200 pages and rewrite rules with more than 70 nodes on the left- and right-hand side. An integrated interpreter enables PROGRES to animate a specification. For this reason the system translates the specification into intermediate abstract graph rewriting code. This code may be executed directly by an integrated abstract graph rewriting machine, which is a conventional stack machine enriched by graph rewriting operations and backtracking capabilities. It is also possible to store and resume debugging sessions, to undo or redo sequences of graph modifications and to recompile and execute modified parts of the specification incrementally. Beyond that the PROGRES system can compile the abstract graph rewriting code to C source code. The biggest specifications generate about 100,000 lines of C code. The C code  accompanied by the environment’s graphoriented DBMS GRAS [5] and a Tcl/Tk-based user interface  may be used as a rapid prototype. In this way we could develop many useful visual environments for CIM [17], software engineering systems [8] and also visual programming languages like BDL [14]. The constraints which are presented in this paper have been added recently. Currently we are waiting for feedback of our user community. One of the most important issues is the efficiency of the constraint checking algorithm. As we have already discussed, global constraints are only checked against the operations in the according section. The main defining quantity for the run-time behaviour of the constraint checking algorithm is the graph-pattern search algorithm. This algorithm has a complexity of O(nk) where n is the number of nodes in the hostgraph and k the number of nodes to be matched. The overall complexity of constraint

section Aircraft_on_Ground constraint No_forbidden_luggage [...] section Passenger_Boarding constraint Passengers_aboard [...] production Boarding [...] end; transaction Make_Aircraft_ready [...] end; section Approaching_Aircraft constraint Free_Runway [...] production Land_Aircraft [...] end;

Fig. 10: Sections as constraint checking units

1. http://www-i3.informatik.rwth-aachen.de/research/progres

7

checking is therefore (#constraints) * O(nk). However, an integrated search planner often reduces the worst-case complexity considerably [18]. It computes a partial order for searching nodes in a graph and proposes the cheapest evaluation order. Therefore all presented examples in this paper have a complexity of O(n). Nevertheless, constraint checking is a very expensive operation and can be switched off by the user of the PROGRES system. In PROGRES local constraint attributes at node classes have to be defined textually but can be evaluated much more efficiently using a kind of incremental attribute evaluation algorithm. The complexity is O(# maybe affected nodes). These nodes are determined by an attribute dependancy graph. The attributes AgeOk and NameOk of our example (see fig. 8) are only checked for those nodes where the value of the relevant attributes was changed.

References [1]

[2]

[3]

[4]

[5]

8. Conclusion and Future Work

[6]

In this paper we presented the integration of constraints, pre- and postconditions to the PROGRES language. There are two main classes of constraints: integrity constraints and active constraints that allow for event controlled programming. All kinds of discussed constraints are available in the current implementation of the PROGRES system. It supports validation of specification in several ways: • The syntactical correctness of a specification is guaranteed by a syntax-directed editor and parser • An integrated analyzer can guarantee that all parts of a specification are well-typed • Integrity constraints as well as pre- and postconditions of rules allow a run-time checking of the specification • An automatic verification of a subset of PROGRES specifications is feasible but its description is out of the scope of this paper (cf. [4]). Constraints are also interesting for generating a prototype from a specification. With the help of these constraints the user can make sure that the prototype will not produce an erroneous hostgraph. This leads to much safer generated visual programming environments. Currently we are integrating a module concept into the PROGRES language. Its modules will play about the same role for the constraint checking algorithm as the sections which have been presented in section 6. Furthermore, PROGRES will be modified in the future such that graph schemas are defined using the UML class diagram notation and modules become UML packages (see [12]). The constraints will play the role of UML’s OCL expressions (cf. section 1). The main future goal is to blend the standard object oriented modelling notations with visual programming with graph rewriting rules.

[7]

[8]

[9]

[10]

[11]

[12] [13]

[14]

[15]

[16]

[17]

[18]

8

C. Bauzer Medeiros, M. J. Andrade: Implementing Integrity Control in Active Data Bases, Journal of Systems Software, Vol. 27, 1994, pp. 171-181 B. Bell, C. Lewis: ChemTrains: A Language for Creating Behaving Pictures, Proceedings of the IEEE Symposium on Visual Languages, 1993, pp. 188-195 E. Denert, R. Franck, W. Streng: Plan2D - Towards a TwoDimensional Programming Language, LNCS 26, pp. 202213, Springer Verlag, Berlin, 1974 R. Heckel, A. Wagner: Ensuring consistency of conditional graph grammars - a constructive approach, Proc. of SEGRAGRA ’95 "Graph Rewriting and Computation", Electronic Notes of TCS, 2, 1995, http://www.elsevier.nl/locate/ entcs/volume2.html N. Kiesel, A. Schürr, B. Westfechtel: GRAS, a Graph-Oriented Database System for (Software) Engineering Applications, in Information Systems, vol. 20, no. 1, Oxford: Pergamon Press, 1995, pp. 21-51 D. W. McIntyre: Visual Tools for Generating Iconic Programming Environments, Proceedings of the IEEE Symposium on Visual Languages, 1992, pp. 162-168 M. Minas, G. Viehstaedt: DiaGen - A Generator for Diagram Editors Providing Direct Manipulation and Execution of Diagrams, M. Nagl (ed.): Building tightly integrated (Software) Development Environments: The IPSEN Approach, LNCS, 1170, Springer Verlag, Berlin, 1996 J. Paredaens, J. v.d. Bussche, M. Andries, M. Gemis, M. Gyssens, I. Thyssens, D. van Gucht, V. Sarathy, L. Saxton: An Overview of GOOD, SIGMOD Record, 21(1), 1992, pp. 49-53 J. Paredaens, P. Peelman: G-Log, A Declarative Graphical Query Specification Language, Dept. Wiskunde en Informatica, UIA, Antwerpen, TR 91-16, March 1991 Joseph J. Pfeiffer, Jr.: Ludwig2: Decoupling Program Representation From Processing Models, in Proceedings of the IEEE Symposium on Visual Languages, 1995, pp. 133-139 Rational Software Corporation: UML Semantics, Version 1.1, 1997, http://www.rational.com A. Repenning, W. Cytrin: Agentsheets: Applying GridBased Spatial Reasoning to Human-Computer Interaction, Proceedings of the IEEE Symposium on Visual Languages, 1993, pp. 77-82 A. Schürr: BDL - A Nondeterministic Data Flow Programming Language with Backtracking, Proceedings of the IEEE Symposium on Visual Languages, 1997, pp. 148-153 A. Schürr, A. Winter, A. Zündorf: Visual Programming with Graph Rewriting Systems, in Proceedings of the IEEE Symposium on Visual Languages, 1995, pp. 195-202 S. D. Urban, A. M. Wang: The Design of a Constraint/Rule Language for an Object-Oriented Data Model, Journal of Systems Software, Vol. 28, 1995, pp. 203-224 B. Westfechtel: A Graph-Based System for Managing Configurations of Engineering Design Documents, International Journal of Software Engineering and Knowledge Engineering, Vol. 6, No. 4, pp. 549-583, 1996 A. Zündorf: Graph Pattern Matching in PROGRES, In Proceedings of the Fifth Internatlional Workshop on Graph Grammars and Their Application to Computer Science, LNCS 1073, pp. 454-468, Springer Verlag, Berlin, 1996