Attributes

Globally visible attributes are dened in the entity relationship model. Beyond these, we may have to dene attributes that are only locally visible, i.e. that are not exported and, therefore, cannot be accessed from other increment classes. In addition, the entity relationship model does not yet declare attribute types. This is because attribute types are not important in the early stage of a tool development. To prevent unnecessary complexity, our notion of entity relationship diagrams does not include types. When it comes to accessing attributes

in behavioural denitions, however, the consistency of the access must be checked in order to exclude specication errors. We need the notion of types for that purpose. The class interface denition, therefore, includes an attribute section in order to rene attribute denitions from the entity relationship model.

An attribute denition declares a name and a type of an attribute. All types that have been declared by inheritance or import within the class denition interface may be used here. In that way, we provide a rich variety of language constructs for dening the structure of attributes. Non-syntactic classes can also be used to impose a particular behaviour on attribute types. We do not address non-syntactic classes any further here. Refer to the appendix for a detailed discussion. In general non-syntactic classes provide the expressive power of an object-oriented language including multiple inheritance, construction of types and encapsulation with methods. As an example, consider the following example from the Groupie interface editor denition.

ABSTRACT INCREMENT INTERFACE Module; ...

ATTRIBUTES

DefinedNames:SymbolTable; END ATTRIBUTES;

...

This attribute section denes an attribute DefinedNames. Its type is the non-syntactic class SymbolTable. A SymbolTable is an association between character strings and increments. As

soon as a new identier is declared within a module, a static semantic constraint denition will establish an association between the value of the identier and the increment that declares the identier. This association is then further used during semantic analysis and inter-document consistency checks.

Attributes are inherited from super classes. Attribute types can be redened by including a declaration, with the inherited attribute name into the attribute section of the subclass. Redenition of attributes is required for the same reason as for relationships. In the above example, the symbol table is inherited by the dierent module types. In type collection modules, however, only type names are included in the symbol table. We might want to exploit this knowledge and redene DefinedNames to become a TypeTable. The redenition

also has to be covariant to exclude type errors. In the example this means that TypeTablehas

to be a subclass of SymbolTableand then all operations that are available for symbol tables

are available on the type table, too.

For the notion of covariant redenition of attributes, however, we need to dene the notion of subtypes. Therefore, we need to distinguish single- and multi-valued types. In the single-valued case, atomic types do not have any subtypes. If the type is a class, all subclasses are subtypes of the type. In the multi-valued case, those types are subtypes of a given type

t

that are constructed with the same type constructor applied to a subtype of the base type of

t

. Then redenitions are safe for the same reason as for relationships. Note that the type system is considerably simplied compared to the type system of

O

2

C

due to the fact that we were able

to omit nested types. In particular, the notion of subtypes in

O

2

C

is much more complicated

because several levels of nesting have to be considered rather than one level in our case. A tool builder can prevent other importing classes from accessing an attribute by restricting its visibility and declaring it as hidden. This contributes to the software engineering princi- ple of information hiding. To do so the attribute declaration is preceeded by the keyword

tributes are also declared in subclasses. We do not want to support selective inheritance, because this is inherently unsafe. Assume, for instance, that class Increment declares an at-

tribute HIDDEN Errors:SET OF ERROR TYPE as well as operations to add or delete errors from

that set. Some subclass, say ADTModule, inherits the operations. Without inheriting the at-

tributeErrors, the inherited operations would have no attribute to operate on and would have

to raise a run-time error.

The redenition of attributes must not change the attribute's visibility. Due to polymorphism there is no way to decide statically whether such a change in visibility is safe. Consider again the above example. Suppose now that Errors was exported by Increment. If the visibility

was changed to HIDDEN in subclass ADTModule and an object of ADTModule was assigned to a

property e whose static type is Increment, the attribute access e.Errors would be statically

valid because Increment exports Errors. At run-time, however, the access would be invalid

because the increment erefers to an object of class ADTModule, which hides the attribute. As

we have not found any situation where this unsafe redenition would be required, we exclude it.

The denition of attributes may also cause name clashes due to multiple inheritance. Also incorrect repeated inheritance might occur if the attribute type is redened in one super class but not in the others. These situations are dened in a similar way to relationships and not considered here further.

In document Tool specification with GTSL (Page 148-150)