6. User-Defined Attributes

In the most general sense, the format of an entity definition is the following:

[object | operation] name is
attribute-name : attribute-value
. . .
end name

In the examples thus far, built-in attributes have been discussed. For an object, the built-in attributes are: components, operations, equations, and description. For an operation, built-in attributes are components, inputs, outputs, preconditions, postconditions, and description.

A user-defined attribute specifies additional relational or descriptive information about an object or operation. Consider the following example:

module M;
    define object attribute scheduled_by, coordinated_by, special_note;

    object Meeting is
        components: StartTime, EndTime, Attendees, ... ;
        scheduled_by: StaffPerson;
        coordinated_by: Manager;
        description: (* A meeting represents ... *);
        special_note: (* Ask our system analyst if this is correct *);
    end Meeting;

    object StaffPerson is ... ;
    object Manager is ... ;
end M

This example illustrates how attributes are defined and used. Before use, an attribute must be defined in a define clause of the following general form:

define [object | operation] attribute attr-name,...

Such a definition allows the listed attr-names to appear within entity definitions. In the example above, scheduled_by, coordinated_by, and special_note are defined object attributes. Note that object and operation attributes are separately declared, so if the same attribute is desired for both objects and operations, two separate define declarations must be given.

Once defined, an attribute can be put to two uses: (1) to define formal relations between entities -- a relational attribute; (2) to augment an entity definition with special-purpose comments -- a commentary attribute. These two uses are specified by the following two syntactic forms, respectively:

attr-name : entity-name,...

attr-name : SpecL comment

In the Meeting example above, scheduled_by and coordinated_by are relational attributes; special_note is commentary.

A relation between entities specifies a non-hierarchical connection. To understand such connections, it is instructive to compare relational attributes to the built-in SpecL component relation. Consider the following alternative to the Meeting specification above, where no relational attributes are used:

module M




    object Meeting is
        components: StartTime, EndTime, Attendees,
                        scheduled_by:StaffPerson, coordinated_by: Manager;
    end Meeting;




    object StaffPerson is ... ;
    object Manager is ... ;
end M

Here, what were formerly specified as relations are now components of the meeting. The relational versus hierarchical specifications define different conceptual views. In the relational specification, the scheduled_by and coordinated_by objects are not part of the Meeting as in the hierarchical definition. While the difference is subtle, it can be important in terms of constructing an accurate view a system being specified.

The distinction between relational versus hierarchical specifications can be further clarified by considering bi-directional relations. Here is a further refinement of the Meeting example:

module M;
    define object attribute scheduled_by, coordinated_by, special_note;
    define object attribute scheduler_of, coordinator_of;




    object Meeting is
        components: StartTime, EndTime, Attendees, ... ;
        scheduled_by: StaffPerson;
        coordinated_by: Manager;
        description: (* A meeting represents ... *);
        special_note: (* Ask our system analyst if this is correct *);
    end Meeting;




    object StaffPerson is
        ...
        scheduler_of: Meeting
    end StaffPerson;




    object Manager is ... ;
        ...
        coordinator_of: Meeting
    end Manager;


end M

Here a bi-directional scheduling relation has been established between Meeting and StaffPerson. A similar bi-directional coordinating relation has been specified between Meeting and Manager. Such relations would be more awkward to specify using hierarchical components, and the hierarchy would be inappropriate in the sense that none of the objects participating in the relations is conceptually part of the others.

Commentary attributes are particularly useful to describe meta-properties of a requirements specification. The intention of the special_note attribute above is to supply a temporary annotation for use during the development of the specification. While it is possible to use the built-in description field for such commentary, it is clearly more awkward to do so, as the following version of Meeting illustrates:

module M;
    define object attribute scheduled_by, coordinated_by;




    object Meeting is
        components: StartTime, EndTime, Attendees, ... ;
        scheduled_by: StaffPerson;
        coordinated_by: Manager;
        description: (* A meeting represents ...
                SPECIAL_NOTE: Ask our system analyst if this is correct *);
    end Meeting;




    object StaffPerson is ... ;
    object Manager is ... ;
end M

It should be noted that there is a fully functional notation that can be substituted for the use of relational attributes. In this sense, relational attributes can be viewed as "syntactic sugar" for an equivalent functional definition. Details of the equivalence are discussed in Appendix C. Relational attributes are provided in SpecL for specifiers who find relational notation conceptually convenient. Those users who would prefer to use a fully functional notation, while retaining the expressive power of relations, should consult Appendix C.

Prev: modules | Next: formal-specs | Up: index | Top: index