IRAC Preface |
1 Introduction |
2 General Design Objectives |
3 General Syntax and Semantics of the Abstract Specification |
4 Object Management System |
5 Program Execution Facilities |
6 Input and Output |
7 Protection and Security |
8 Requirements for Tool Management and Services for Tools |
9 Ancillary Requirements |
10 Definitions |
Submission of Comments
The reader is referred to the definition of
in the list of definitions in
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
Typing is necessary to:
One would expect the PCIS designer to provide some means to examine the
type definitions currently in force, although these are not explicitly
- 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".
4.2B Rules about Type Definitions. The PCIS type definitions shall:
a) Associate attribute types with object types to which they
b) Associate relationship types with object types they may
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
d) Permit multiple distinct relationship types among the same
e) Associate attribute types with the relationship types to which
they apply and specify which of these attribute types act as key
f) Specify the set of allowable values for each attribute type.
g) Associate object types with the object types which may be their
h) Associate object types with the relationship types which may be
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:
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.
- Extensibility is a necessity
- Users and projects will want to particularize the data
structures to their needs
Relationships and objects may be components of composite objects; a
composite object is not required to have any relationship components or
4.2C Type Definition. The PCIS shall provide facilities for defining
new object, relationship and attribute types.
There are no explicit requirements for:
All decisions in this area are intentionally left to the PCIS
- Naming of type definitions
- Storage of type definitions in a single collection
- Restrictions on the creation of new definitions
The word "new" is deliberately included to ensure that the set of type
definitions can be extended while the PCIS implementation is in use.
a) PCIS shall support mechanisms for the definition of abstract
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
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
b) PCIS shall support extensions of abstract data types by
subtyping (inheriting attribute types, relationship types and
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
and are supported in some existing systems; for example, virtual classes are
supported by Gemstone
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
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
c) PCIS shall support user-definable operations with run-time
binding and overloading implementation on subtypes.
Operations beyond those of
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
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
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
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
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
- 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
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:
In either case the possibilities include:
- 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
- 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
- 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:
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.
- 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.
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
Go forward to
Section 4.3, Identification.