IRAC 4.2: Typing

4.2 Typing

The reader is referred to the definition of TYPING in the list of definitions in Section 10. This term is used throughout the remainder of Section 4 and is crucial to the understanding of both the requirement and the rationale. Typing is a powerful mechanism for detecting and preventing user error.

Objects have a type; an object type determines which attributes and relationships can be associated with an object of that type. Attributes have a type; an attribute type determines the form, format, number, and range of values legal for attributes of that type.

Relationships have a type; a relationship type determines the types and number of the objects participating in relationships of that type and the attributes associated with a relationship of that type.

In the abstract, an object type defines the set of relationships and attributes required of objects if they are to be of that type. To differentiate and allow access to those relationships and attributes each must be identifiable.

4.2A Types. The facilities provided by the PCIS shall enforce typing by providing that all operations conform to the type definitions which are in force at the time. Every object, relationship and attribute shall have a specific type to which all operations must conform.

Types cannot be discussed usefully in isolation from the functions that access objects of the type. These functions embody the type definitions; without them, the concept of type is of interest only to philosophers.

Typing is necessary to:

Interpret the bit-string containing a value in order to do operations on it.
Convert between representations of the same value on different hardware. This will be necessary if the distributed OMS supports mixed models of CPUs and for transport of information from one OMS to another.
Restrict operations, establishing discipline and structure. This concept is often called "consistency".

One would expect the PCIS designer to provide some means to examine the type definitions currently in force, although these are not explicitly required.

4.2B Rules about Type Definitions. The PCIS type definitions shall:

a) Associate attribute types with object types to which they apply.

b) Associate relationship types with object types they may connect.

c) Specify relationship types as either functional mappings (one-to-one or many-to-one) or relational mappings (one-to-many or many-to-many) or the corresponding concepts for N-ary relationships (if provided).

d) Permit multiple distinct relationship types among the same object types.

e) Associate attribute types with the relationship types to which they apply and specify which of these attribute types act as key attribute types.

f) Specify the set of allowable values for each attribute type.

g) Associate object types with the object types which may be their components.

h) Associate object types with the relationship types which may be their components.

The term "associate" is used to avoid any implied ordering in the definition of object types, relationship types and attribute types.

The manner in which type definitions are established is left to the PCIS designer. However, it is clear that:

Extensibility is a necessity
Users and projects will want to particularize the data structures to their needs

Objects and relationships have attributes; relationships connect two (or more) objects. Some of the attributes on relationships may be distinguished as key attributes of the relationship. Attributes of a relationship may act as key attributes if different relationships of a relationship type (for a single object) must have distinct values for the attributes. It is a PCIS design choice whether or not each key attribute separately must be distinct or the key attributes taken together must be distinct.

Relationships and objects may be components of composite objects; a composite object is not required to have any relationship components or object components.

4.2C Type Definition. The PCIS shall provide facilities for defining new object, relationship and attribute types.

There are no explicit requirements for:

Naming of type definitions
Storage of type definitions in a single collection
Restrictions on the creation of new definitions

All decisions in this area are intentionally left to the PCIS designers.

The word "new" is deliberately included to ensure that the set of type definitions can be extended while the PCIS implementation is in use.

4.2D Object-Orientation.

a) PCIS shall support mechanisms for the definition of abstract data types.

Abstract data type definitions provide a mechanism for function attachment to objects by means of object type definitions. Thus the object's data is encapsulated, and access to the data is only through defined operations, allowing the data to be hidden or protected; see the rationale of Requirement 4(h). For example, Section 4.4 operations can be specialized with behavior required for referential integrity and semantic integrity.

Encapsulation allows the internal data structure of an object to be altered, perhaps for performance reasons, without altering the access interface; this gives some degree of independence of tools from the detail of data structuring; data can be restructured without necessarily having to recompile or relink tools.

The requirement is not for all objects to have their data thus encapsulated. PCIS designers may choose to allow data not to be encapsulated, in which case data independence can be achieved through a sub-schema mechanism.

b) PCIS shall support extensions of abstract data types by subtyping (inheriting attribute types, relationship types and operations).

This requirement provides for inheritance of attribute types, relationship types and operations along the graph of object type definitions, and provides the extensibility required to introduce new types which specialize inherited behavior.

PCIS designers should consider implementation of real, virtual, and versioned (differential) types. The concepts of real, virtual, and versioned (differential) types are taken from [Postgress91] and are supported in some existing systems; for example, virtual classes are supported by Gemstone [Taylor91] and versioned types are supported by PCTE.

A virtual type, unlike a real type, has instances which do not necessarily have persistent attributes or links; the specialization of (possibly all) Section 4.4 operations and of retrieval/assignment operations allows phantom objects to appear to exist at the interface and tool level without there being any actual corresponding persistent data. Values returned by operations on such objects may be calculated. Alternatively, the operations of a virtual type may access data from an external database, for example, using SQL, thereby encapsulating this data and making the access of data independent of how it has been stored. This provides the potential for a transparent integration of DBMSs.

c) PCIS shall support user-definable operations with run-time binding and overloading implementation on subtypes.

Operations beyond those of Section 4.4 can be defined for environment, project, application, and tool purposes, and can be managed either by the object management system or within tools. Furthermore, the operations of Requirement 4.4A can be specialized on a per-type basis to meet specialized needs.

The overloading of existing operations on new subtypes is a means to support reusability. Adding new operations shall be possible without requiring programs to be recompiled or relinked. Therefore tools designed to work on some object types should be easily reused on the specialized object types, even if they have different implementation of their operations. Run-time binding is required for flexibility reasons. A user should be able to add new operations, subject to the same controls as of the typing structure.

PCIS designers should consider efficiency of execution of small frequently executed operations. Interpreted and specialized operation languages should be compatible between PCIS implementations.

PCIS designers should provide a means for operations to specialize or completely simulate attribute value retrieval and assignment (and similarly for adding or removing relationships), in addition to the minimal set of operations in Section 4.4.

4.2E Type Evolution. The PCIS shall provide mechanisms for evolution of type definitions including:

a) Derivation of new types from one or more existing types, with the inheritance of associated properties.

b) Changing existing types by changing their associated properties.

c) Removing obsolete types.

Users need to be able to define new types that are extensions of existing types, such that operations and tools that expect objects of one of the old (base) types will also accept and work correctly on objects of a new type. The new type must therefore have the same attributes and relationships that each of the bases does, plus any additional ones. Attribute types may have more restricted ranges in the new type than they did in the bases, but obviously may not be less restricted or different in any other way. The tool or operation should not need any kind of recompilation or other preparation to operate on the new type.

For example, if A is a base type and B and C are both extensions of it, it should be possible to define a type D which is an extension of both B and C. A tool that accepts A would also accept B, C, and D; a tool that accepts B would also accept D; and a tool which accepts C would also accept D. However, there may be conditions under which D cannot be formed, such as B and C each having an attribute with the same name but of different types.

The ability to define new types through derivation is not sufficient to support the need to change type definitions in that one may want to modify existing types that are known to a set of tools without modifying the tools that use the type.

Type changes also include the ability to redefine the structural characteristics of the data. For example, one may want to change a relationship from being optional to mandatory, in which case the PCIS must ensure that all objects that include such a relationship have, in fact, a value for the relationship.

The required change of type definitions is supposed to include the following:

Addition and removal of attribute types associated with an object type or relationship type
Extension and restriction of attribute value ranges
Addition and removal of relationship types associated with an object type
Addition and removal of component object types and component relationship types of an object type

The way of achieving such changes is left to the PCIS designers. It could be done by creating new versions of existing types, associating new types with existing types or updating the definitions of existing types. The important consideration in defining the mechanism is the ability to preserve existing tools and data as required by Requirement 4.2F.

4.2F Preserving Tools and Data. The mechanisms for evolving type definitions shall allow existing data and tools for one type definition to be used, in PCIS-defined circumstances, with data and tools for a related type definition. When type definitions are evolved, the PCIS should preserve data and shall maintain PCIS-defined data consistency.

The wording is intended to cover at least the following situations:

Use of existing data by a new tool which has been designed for a new type definition.
Use of existing tools on instances of new type definitions.

In either case the possibilities include:

The data has all of the properties which the tool expects (and perhaps some additional properties). Here the tool may "see" the data as though it only had the expected properties.
The data does not have all of the properties expected by the tool. Here the data might be implicitly, automatically or by the tool converted to the new type (perhaps with acquisition of default values or undefined values).

4.2G Visibility of Type Definitions. The PCIS shall provide facilities to manage the visibility of type definitions.

This requirement mandates provision of a mechanism whereby a user, tool or process can control which type definitions are applicable. It corresponds to a mechanism for allowing multiple views on the data base. Allowing multiple views and, in particular, the guarantee that some definitions will be visible to an executing tool are fundamental to the achievement of transportability and to allowing an environment to be self supporting:

When a tool has been developed on a given system, some specific, associated definitions (object, relationship or attribute types) will probably also have been defined. When two tools coming from different sources are installed on the same system, there is a high probability that some definitions will conflict. Views are the ideal way to resolve such conflicts.
The same requirement applies if it is desired that a given project be allowed to introduce its own definitions without having to refer to the system administration. This is part of the philosophy of local naming.

As an example, consider an Ada source module (for example, an ACVC test) which can be used as a compiler test, as a syntax directed editor test, as a complexity analyzer test, etc. The installation of tools from different suppliers may introduce several "test-result" relationship types into the environment. However, the various relationship types with that same identity may have nothing in common; in fact, they might not even have the same attributes. It might be necessary that all of the "test-results" be applied to the same object. Views would then be used to resolve any conflicts.

4.2H Dynamic Modification. The PCIS shall be implementable so that type definitions and visibility management may be defined or evolved while the PCIS implementation is in use by users other than those making the evolutions.

This requirement supports non-stop availability and use of an IPSE. Taking a system down to change typing information would have a very negative impact on the IPSE users. This set of requirements should be striving to promote continuous use, not impeding it. Also, the evolution of one user's private set of type definitions cannot be allowed to impact the operation of other users.

With today's focus on process-driven life-cycles, multiple configuration management paradigms, and use of frameworks to develop and produce all kinds of products, this requirement becomes important for another reason: the process of developing software, or hardware for that matter, has to be capable of adaptation, because products need to evolve rapidly in an increasingly volatile market. Therefore, a framework supporting process definitions must allow them to be easily changed.

Go forward to Section 4.3, Identification.