PRIMER RECORRIDO: DEL ESPACIO RECORRIDO AL ESPACIO BORDADO

relationship model that corresponds to

type

(

e

). If

e

is multi-valued,

ars

must be multi-valued, ordered and lead to the class that corresponds to the base type of

type

(

e

).

For each reference relationship

rrs

that refers in the entity relationship model from class

erc

i

to

erc

j there has to be a semantic relationship between

c

(

erc

i) and

c

(

erc

j). The rst name

n

1 of

rrs

determines the explicit link

e

of the corresponding semantic relationship. The name

of

e

must be

n

1. The type of

e

depends on the cardinality of

rrs

. If

rrs

is single-valued, the

type of

e

must be

c

(

erc

j), otherwise the type is a set type with

c

(

erc

j) as base type. If a

second name

n

2 is given for

rrs

, we assume that the tool builder needs the implicit link for

the relationship and require that there is an implicit link

i

dened in the semantic relationship section of

c

(

erc

j) whose name equals

n

2. The type of

i

must be

c

(

erc

i). Vice versa, for each

explicit link dened for class

erc

i, there must be a reference relationship to the class in the

entity relationship model that corresponds to the type or base type of the link. The name of the explicit link must be equal to the rst name of the reference relationship. If the explicit link has a corresponding implicit link, the name of the implicit link must match the second name of the relationship.

7.2.2.2 Constraint Handling

The entity relationship editor supports the creation and deletion of new subsystems and the various kinds of reference relationships. It supports the creation of abstract classes in order to dene common properties of several subclasses. It then supports the introduction and deletion of inheritance relationships. The denition of properties that are common to all subclasses of an abstract class may be moved to the abstract class. We consider this as property generalisa- tion. The reverse command, i.e. property specialisation, transfers the property denition to all subclasses that are leaves in the inheritance hierarchy. Moreover, subsystem and relationship names can be expanded and changed. The editor supports navigation through the decompo- sition hierarchy in terms of zoom-in/zoom-out commands. These navigation commands are oered for subsystems. The graphical layout of the diagram can be modied and, in particular, classes can be moved to lower- or upper-level subsystems. These operations will automatically insert ports as required by the static semantic constraints.

An initial diagram that represents a tool in the entity relationship model of an environment is created together with the ENBNF denition of the tool. Change propagations of the ENBNF editor ensure that the entity relationship model is kept consistent with the ENBNF denition. Note that terminal and non-terminal classes cannot be created or deleted in the entity rela- tionship editor. Also aggregation relationships cannot be created or deleted, they can only be

generalised or specialised, which does not impact the abstract syntax.

The entity relationship editor performs a number of change propagations to preserve inter- document consistency constraints to inheritance diagrams and class interfaces. The tool builder can change names of aggregation relationships in the entity relationship editor. These changes are propagated to the abstract syntax sections of the target class of the changed relationship in order to change the child name accordingly. In addition, the tool builder can create new reference relationships and modify or delete existing ones. These commands require propa- gations to semantic relationship sections of class interfaces. If a new reference relationship is created, a new explicit link is inserted into the semantic relationship section of the class where the reference relationship starts. Expanding or changing the rst name of the reference rela- tionship expands or changes the name of the explicit link. Expanding the second name creates a new implicit link in the semantic relationship section of the target class of the reference relationship. Deleting a reference relationship triggers deletion of the corresponding explicit and implicit links. Finally, the tool builder can create, change or delete attributes of a class. These commands trigger the changes to be made in the attribute section of respective class interfaces.

The introduction of new inheritance relationships are propagated from the entity relationship model to inheritance diagrams. Similarly deletion of inheritance relationships in the entity relationship model triggers a propagation that deletes the relationship from the inheritance diagram as well.

We have dened above an editing command that allows for generalisation of properties. The generalisation command can move the denition of a property

p

that is dened for all sub- classes of an abstract class

erc

from the subclasses

erc

1

;:::;erc

nto

erc

. Without any further

action, this would reveal inconsistencies in class interfaces. Therefore, the declarations of

p

in

c

(

erc

1)

;:::;c

(

erc

n) are removed and inserted into

c

(

erc

). In particular, this command simpli-

es the actions that are required for the generalisation of properties. Likewise, specialisation is handled in such a way that denitions are moved from the abstract class to its non-terminal and terminal subclasses.

Upon creation of a new abstract class, this class is inserted into the inheritance diagram during a change propagation. Creation or deletion of inheritance relationships causes change propagations that insert or delete the inheritance hierarchy from the inheritance diagram.

7.2.3 Inheritance Diagram Editor

An initial inheritance hierarchy for increment classes is established by change propagations from the entity relationship editor. This inheritance hierarchy might be edited by further introducing new abstract increment classes and redening the inheritance relationships of generated increment classes. Creation of further non-terminal or terminal increment classes or deletion of classes that were contained in the initial inheritance hierarchy is not supported. The entity relationship model does not include non-syntactic classes that are used to dene attribute types, since these do not contribute to the denition of navigation paths. Non- syntactic classes can, therefore, be created with the inheritance diagram editor as subclasses of predened non-syntactic classes. Since these editing commands are oered, further inter- document consistency constraints have to be dened.

7.2.3.1 Consistency Constraints

Each class

c

in the inheritance diagram that is not predened must be rened by a class

c

(

c

) with an interface and a specication. If the class is an abstract increment class (it has subclasses), it must have an abstract increment class interface. If it does not have subclasses and does not dene or inherit outgoing aggregation relationships,

c

(

c

) must be a terminal class. If it does not have subclasses, but denes or inherits outgoing aggregation relationships, it must be dened by a non-syntactic class. If it is a subclass of a predened non-syntactic class, it must be rened by a non-syntactic class.

The inheritance relationships dened in the inheritance diagram must be reected in the in- heritance sections of the class interface denitions. Therefore, for each inheritance relationship that denes class

c

i as a subclass of

c

j, there must be an entry in the super class list of the

inheritance section of

c

(

c

i) that denes the name of

c

(

c

j).

7.2.3.2 Constraint Handling

For an abstract increment class of a non-syntactic class

c

that is created in the inheritance diagram, a class interface denition

c

(

c

) has to be dened. The interface will be an abstract increment interface if the class in the inheritance diagram was an increment class and it will be a non-syntactic interface otherwise. The creation of this interface will further cause a propagation by the class interface editor that also creates a class specication document. Likewise, if a class

ac

is deleted, the class interface

c

(

ac

) will also be deleted. This deletion will, as a follow-on propagation, also delete the respective class specication.

Creation or deletion of an inheritance relationship that denes

c

i as subclass of

c

j will change

the inheritance section of

c

(

c

i). If a new relationship is created in the inheritance diagram, the

name of

c

j will be added in the inheritance section of

c

i. In the case of a deletion, the name

of

c

j will be deleted from the inheritance section of

c

i.

7.2.4 Class Interface and Specication Editors

Class interfaces dene the external behaviour of a class. This external denition is then rened in the internal class specication. While the inter-document constraints we discussed above were always between dierent types, we now have inter- as well as intra-type consistency constraints. The import interfaces and inheritance sections in class interfaces impose intra- type inter-document consistency constraints on other class interface denitions. Inter-type consistency constraints require, for instance, each property or method imported by a class specication to be exported by the respective interface or the explicit methods dened in the interface of a class to be specied in the method section of the specication.

For reasons of brevity, we cannot address the constraints in full detail here. They are formally dened in Appendix A. We, therefore, restrict ourselves to discussing the way the interface editor propagates changes to other class interfaces in order to deal with intra-type constraints and to other specications in order to deal with inter-type constraints.

The existence of a class specication depends on the existence of the interface of a class. The class interface editor, therefore, propagates the creation of a class to the class specication

editor in order to create a class there as well. When a class interface is deleted, the class specication must also be deleted.

Initial class names are determined with the entity relationship and inheritance editors. If names are changed there, they will propagate the change to the interface view. The interface editor will, in turn, propagate the change further to

all inheritance sections of subclasses,

all import interfaces of class interface denitions that imported the class, and all import interfaces of class specication that imported the class.

The interfaces, in turn, will propagate the change further to property types, local variable types, method parameter and result types where the class might be used as a type name. If the entity relationship editor propagates the change of a property name to the interface editor, the change must be propagated further to all interfaces of subclasses that inherit the property. In addition, all specications of subclasses that use the name in semantic rules, methods or interactions must be informed so as to change the property name there as well. The name may in addition have been imported in client class specication. Then the name change must be propagated to those imports from where it is further propagated to the places where it is used.

Any explicit method of a class interface must have a body dened in the specication of the class. Upon creation of a method in the interface a place holder is created in the specication as well. Any change to an explicit method such as creation, change or deletion of a parameter, changes to the result type are propagated to the respective method in the class specication.

7.3 Summary

We have dened a number of inter-document consistency constraints between the dierent document types that were identied for the specication of tools. The constraints are dened between a determining and a dependent document type. They dene paths for propagating changes from a determining into a dependent document. The dierent paths are summarised in Figure 7.3.

Each rectangle represents a document type and an arrow represents a propagation path from a determining document type to a dependent type. The annotations of arrows denote the sub- ject of a propagation. Classes and aggregation relationships are created by the ENBNF editor in the entity relationship model. Furthermore, it creates the inheritance relationships between increment classes and predened classes in the inheritance diagram. Finally, it directly creates regular expressions and unparsing scheme denitions in the class interface. The entity rela- tionship editor, in turn, propagates the denition of classes to the inheritance diagram editor. Moreover, it creates properties, i.e. attributes, abstract syntax children and semantic relation- ships in the respective class interface. The inheritance diagram editor generates class interfaces and also determines their inheritance sections. Finally, changes to property and method deni- tions are propagated from the interface editor to the respective class specications. In this way a tool builder can incrementally dene a tool specication at dierent levels of abstraction; the tool builder can choose the appropriate level of abstraction for the particular concern that has to be dened. While working on a document at a higher level of abstraction, fragments for tool

Classes,Inheritance_{relationships} Inheritance Diagram Editor E/R Editor Interface Editor Specification Editor Regular expressions, Unparsing schemes Classes, Aggregation relationships Classes, Inheritance sections Properties Inheritance relationships

for pre−defined classes

Classes, Properties, Methods

ENBNF Editor

Figure 7.3: Propagation Paths

specications are created, modied or deleted by the environment in lower-level documents. It is our strong belief that the denition of our tool specication environment, as exemplied here, can be generalised to environments for many software processes. Any software process model will include documents at dierent levels of abstraction. High-level documents are, for instance, data ow diagrams, petri nets or informal requirements denitions. At lower levels, documents such as architecture diagrams and component interface denitions will be dened and at even lower levels programming languages will be dened that are used to implement components. These documents will be written in a formal language of some sort. They will always include redundant information. To cope with this redundancy, propagation paths should be dened from the higher levels of abstraction into the lower levels. At lower levels, violations of inter-document consistencies should be visualised in order to guide users so as to enable them to produce statically correct software. The implementation of these inter-document consistency constraints and the propagation paths at the appropriate level of abstraction, in turn, will be supported by the GOODSTEP tool specication languages and the GENESIS environment.

In document Memorias de mi madre Una práctica artística narrada entre pasos y puntadas (página 54-66)