Additional Constraints for OPM Schemas

1. Metaclasses

   There are four system defined metaclasses: DATABASES, CLASSES, SCLASSES, and SPROTOCOLS. Users are not allowed to change the content of these metaclasses.

2. Controlled Value Classes

   A controlled value class either consists of enumerated atomic string values or numeric ranges, but not both. A range is either a number or an interval specified by lower and upper bounds.

3. Classes
   1. There are six mutually exclusive types of classes:
      1. primitive value classes (e.g., INTEGER, CHAR(n), etc.);

      2. controlled value classes;

      3. base object classes;

      4. specialization object classes (subclasses of base object classes);

      5. atomic (non-expandable) protocol classes; and

      6. expandable protocol classes.

   2. Class names are globally distinct.

   3. Superclasses of a specialization object class must be base object classes or other specialization object classes.

   4. Each specialization hierarchy forms a directed acyclic graph.

   5. Base object classes and protocol classes can be associated with identifier attributes.

   6. Specialization object classes can either have explicitly specified identifier attributes, or inherit the identifiers from their generic (super) classes.

   7. If a subclass is specified as: isa* , then cannot have common instances with other subclasses of (that are not subclasses of ).

   8. A protocol expansion consists of only atomic protocol classes and/or expandable protocol classes.

   9. A protocol expansion graph is acyclic, that is, if a protocol class is involved in the expansion of protocol class , then cannot be involved in the expansion or any sub-protocols of .

4. Attributes
   1. All local attributes of a class must have distinct names.

   2. User specified object or protocol attribute names cannot be identical to OWNER or STATUS attribute names.

   3. Inherited attributes in a subclass are overridden by local attributes with the same names.

   4. The name for a tuple tuple attribute is optional. However, each component attribute in the tuple tuple must have a distinct name.

   5. Nested tuple tuple attributes are not allowed.

   6. A simple or component attribute can only be specified as the inverse of another non-derived simple (single-valued or set-valued) attribute.

   7. Attributes with list of values cannot be associated with inverse constraints.

5. Value Classes
   1. Each attribute must be associated with a value class.

   2. A value class of a simple or component attribute can be of one of the following six types:
      1. a controlled value class;

      2. a primitive value class;

      3. a user defined type (or named primitive value class);

      4. a single object class, or a union of several object classes;

      5. a single protocol class, or a union of several protocol classes;

      6. CLASSES system metaclass.

6. Identifiers
   1. A specialization class can either have an explicitly defined identifier, or inherit identifier(s) from its superclass(es).

   2. An identifier can consist of one or more simple, tuple or component attributes.

   3. Identifier attributes must be specified as not null, and single-valued.

   4. If an attribute identifier of class is associated with another class as its value class, then is said to be id-dependent on . A class cannot be id-dependent on another class if is (transitively) id-dependent on , that is, id-dependency graphs must be acyclic.

   5. Identifier attributes cannot be specified as input, output or derived attributes.

   6. Either an entire tuple attribute is an object identifier, or none of the component attributes in the tuple are part of an identifier.

7. Representative Attributes
   1. Each class can have a set of simple or component attributes to be specified as its representative ( REP) attributes.

   2. A specialization class will inherit REP attributes from its superclasses if this class does not have explicitly specified REP attributes.

   3. Each REP attribute must be single-valued.

8. Input and Output Attributes
   1. Input and output attributes can be associated only with protocol classes.

   2. Input or output attributes must be simple attributes that are not specified as attribute identifiers nor as derived attributes.

   3. If a protocol P is specified as expanded into several sub-protocols, then the input attributes of P must be subsets of input attributes of the sub-protocols, and the output attributes of P must be subsets of output attributes of the sub-protocols. (Some input/output attributes can be hidden from the higher level protocol.)

   4. Input and output attributes of sub-protocols are related to input and output attributes of higher level protocol using input is-a , and output is-a statements.

   5. Input and output connections between sub-protocols are specified using input from via statements. If attribute A is an input attribute of protocol class , and the specification for A contains an input statement of the form input from via , , ,

      then

      1. If is a sub-protocol of protocol class involved in the expansion of , then must also be a sub-protocol of involved in the same protocol expansion, and must immediately precede in the protocol expansion.

      2. must be an output attribute of .

      3. For every , : must be a simple or component attribute of class , where is a value class of attribute .

9. Derived Attributes

   Derived simple attributes can be defined using one and only one of the following derivation rules:

   1. attribute composition;

   2. arithmetic expression;

   3. aggregate functions; or

   4. user specified.

10. Arithmetic Expression or Aggregate Function Derived Attributes
    1. A derived attribute A of object or protocol that is specified using an arithmetic expression or an aggregate function, must be a simple, non-identifier attribute. Additionally, if is a protocol class, then A cannot be specified as an input or output attribute of .

    2. An arithmetic expression involved in the specification for derived attribute A of object or protocol class can involve operators, constants, and other single-valued non-derived numeric (simple or component) attributes of .

    3. An aggregate function involved in the specification for derived attribute A of object or protocol class can involve only multi-valued non-derived (simple or component) attributes of , or composition path derived attributes of . Aggregate functions min, max, sum and average can be applied only to numeric attributes (i.e., attributes associated with primitive numeric value classes).

11. Attribute Composition Derived Attributes
    1. Only locally defined (i.e., not inherited), non-derived, simple or component attributes can be involved in attribute compositions.

    2. A simple attribute A of object or protocol class can be associated with an attribute composition derivation consisting of one or (union of) several paths specifications of the following form:

       [] [] [], where

       1. each (1 k n) is an object or a protocol class name;

       2. each (1 k n) is either an attribute name or an attribute name preceded by ``!'' (indicating an attribute inverse), and
          • If is the name of an attribute, C, not preceded by ``!'', then C must be a non-derived, simple or component attribute that is explicitly associated (i.e., not inherited) with (a) if k =1 or (b) if ;
            • if C is associated with a value class consisting of a single object or protocol class, , then is either or a subclass of ;

            • if C is associated with a value class consisting of a union of object or protocol classes, then must be included in this value class.

          • If is the name of an attribute, C, preceded by ``!'', then C must be a non-derived, simple or component attribute that is explicitly associated (i.e., not inherited) with .
            • if C is associated with a value class consisting of a single object or protocol class, , then (a) if k = 1 then ; or (b) if then ;

            • if C is associated with a value class consisting of a union of object or protocol classes, then (a) if k = 1 then must be included in this value class, or (b) if then must be included in this value class.

12. Versions

    1. Identifier attributes cannot be versioned attributes.

    2. A non-versioned abstract attribute can refer only to generic objects (therefore keyword ``specific'' cannot be used in value class definition for non-versioned attributes.)

    3. A non-versioned abstract attribute cannot be specified as an inverse of a versioned attribute; a versioned abstract attribute cannot be specified as an inverse of another attribute.

    4. Derivation for non-versioned arithmetic or aggregate function derived attributes can consists of only non-versioned local attributes, and derivation for versioned arithmetic or aggregate function derived attributes can consist of only versioned local attributes.

13. Permissions
    1. If a schema supports permission modeling, then both OWNER and STATUS attributes must be specified.

    2. The OWNER attribute is a single-valued, abstract, non-null attribute that can be associated with an optional attribute description, an optional attribute example specification, and optional domain-specific properties.

    3. The STATUS attribute is a single-valued, controlled or primitive, non-null attribute that can be associated with optional attribute default, description, example speciification and domain-specific properties. The STATUS attribute must be associated with integer base data type; an object is considered as released if its status value is greater than 0, otherwise it is non-released.

    4. OWNER attribute and STATUS attributes must have distinct names; they cannot be the same as any user-specified attribute names defined in this schema.

    5. All object classes belonging to the same class hierarchy must all be specified with permissions on or off.

    6. Attribute inverse constraints are not allowed in a schema that supports permission modeling.