SECTION 4

OBJECT MANAGEMENT SUPPORT

Security mechanisms, and data consistency mechanisms shall apply to all PCIS facilities required in this section.

The general requirements for the PCIS object management support are the following:

a) The PCIS shall support mechanisms for retaining data.

b) The PCIS shall support mechanisms for retaining relationships among data and properties of data.

This section uses the term data in a general sense; data are the means by which information is represented. The general requirements talk about relationships and properties without mandating any particular way in which data are organized. The specific requirements are written in terms of a specific organization of data where objects represent abstract concepts and attributes contain specific items of data. The general requirements referring to data, therefore, do not take account of the model.

A software project involves many pieces or items of data. Facilities for data management are a central PCIS feature. The PCIS acts as the repository for all information associated with a project throughout its life-cycle. Note that there is no intention here to imply any particular granularity of the treatment of data by the use of the words, "pieces" or "items". These terms are used in a simple colloquial sense. Pieces of data may or may not be composed of other pieces, and so on until the ultimate binary digit (bit) of data are reached. Similarly pieces of data might be aggregated into pieces, and these aggregations may or may not intersect. The structure of data are considered in subsequent sections.

Data might include the text of a piece of program source, of test data, of documentation, or of a schedule. Data might also be the date a piece of text was created, the name of the author, information as to the piece of data from which some object code was compiled, or which pieces of data contain other pieces of data.

The data model supports the way that the environment user and tools view project data. It is important that the capabilities provided to do this support a natural expression of the data that closely models the toolwriter's understanding of the problem on which he is working. This includes the ability to represent the objects in which the user is interested and to represent the relationships (dependencies) among these objects.

c) The PCIS shall support mechanisms for operating upon data, including identifying data, examining data, modifying data, deleting data, and creating new data.

The terms operating, deleting and creating data are used here in a general colloquial sense to illustrate the kinds of things required. More specific operations are considered, in the next section, in terms of a specific model.

d) The PCIS shall support mechanisms for defining certain operations and conditions as legal, enforcing the definitions, and changing definitions of legality.

This introduces the concept of legality with regard to operations and conditions and stipulates that the definition of what is legal should be open to extension by some mechanism. This requirement is purposely stated in extremely general terms and could include:

The ability to prevent change operations (for configuration control purposes)
Security and confidentiality facilities
Data typing (this aspect is considered further below).

It should be noted that some operations or conditions may be illegal for some users, processes or data, but may be legal for others; prohibitions are not necessarily universal.

e) The PCIS shall support mechanisms for describing data for retaining such descriptions and for operating upon such descriptions. Descriptions of the data shall be separated from the data described.

An important aspect of data management, which is more widely recognized as a crucial aspect of modern programming languages, is the separation of the structure and rules about data from the data itself. This concept is so widely accepted for programming languages that it is not normally felt necessary to justify it. However some of the main reasons are rehearsed here:

Data, particularly in a database, is normally operated on by many users. Making the structure of and rules about the data explicit means that the users have a common understanding about the nature of the data.
In any significant software project, there will be many different kinds of data and many specific operations. The majority of the operations can sensibly only be applied to a few of the kinds of data. It may not be unduly restrictive to specify that an individual operation must apply to a single kind of data. Unfortunately, a user may request any operation on any piece of data. An important goal of the facilities offered by the PCIS is to minimize the effects of human fallibility by refusing to perform operations that do not make sense.
There is a need selectively to allow or prohibit certain operations on certain data requested by certain users or processes.

f) The PCIS shall support mechanisms for developing new data descriptions by inheriting (some of) the properties of existing data descriptions.

The requirement to be able to derive new descriptions from existing ones results from the observation that there are natural ways in which some items of data are related to others and the conviction that the support mechanisms should conform to this natural "way of the world". While it is possible to develop such new descriptions independently of the existing ones, there are many advantages to providing support for this within the object management mechanisms. An orderly, supported means of deriving such related descriptions, avoids the problems associated with ad hoc processes. The ability to inherit properties of the descriptions also will reduce the proliferation of independent relationships and properties in the object base. Perhaps most importantly, this capability will make it easier for users and projects to tailor the OMS to their own needs and to organize the structures of their data in natural ways.

One of the most important aspects of the inheritance of properties of data descriptions is that this allows tools which operate on an existing type to be used unchanged on new types which are descendants of or derived from existing types. For example, we may have an editor which operates on a type "text". If we derive a new type "Ada-source" from type "text", then the editor should still work on this type and correctly manipulate the attributes of this type, although the more specialized type may have additional attributes.

g) The PCIS shall separate the relationships and properties of data from the existence of the abstractions about which the relationships and properties are recorded.

This serves to establish a distinction between an item of data and a relationship in which it participates or the values of any of its properties, effectively asserting that the identity and persistence of an item of data are distinguished from and potentially lasts longer in time than the particular values of any of its properties or relationships. That is, the values of the relationships and properties may change over time without changing the data item itself.

h) PCIS shall support mechanisms for the definition of abstract data types with operations.

Wherever needed, it must be possible to enrich the structural semantics of data with operations. This is a requirement to support object-oriented techniques on object types. There are advantages in hiding or encapsulating data either as a way to protect programs from internal data structure modifications or to restrict access through controlled operations. There are also advantages in describing the visible and stable structure of data through their attributes and relationships. It is therefore not the intent here, to impose such a technique to an extreme where all object types would have to be presented as abstract data types. It is felt in particular that viewing the relationships among object types is very important both because of the richness of data semantics which it exhibits through a very concise description and because it also provides a uniform identification mechanism for the objects. More detailed requirements to allow navigational requests among relationships are defined below.

i) The PCIS shall separate the descriptions of data (including operations on the data) and the instances of data from the tools that manipulate them.

This asserts that the knowledge and interpretation of relationships, properties of data and operations is controlled within the OMS and is not embedded in tools which are external to the OMS. It can always be the case that tools may ascribe some additional meaning to a particular property or relationship. However, it is desirable that relationships and properties are defined strictly within the OMS - so that those of general interest are generally available.

j) The data facilities shall be sufficient to support, at least (i) Ada program libraries, (ii) object oriented language class description libraries, (iii) CASE analysis and design data repositories, (iv) documentation systems, and (v) configuration management systems.

PCIS must support the modeling of those data structures required to support the development of tools written with the binding languages. Typically, data structures such as Ada program libraries should be easy to model within the OMS.

This requirement is intended to bring a bit of reality to abstract requirements that precede it. The intent is that the various inter-relationships and characteristics of (for instance) compiled Ada code (programs, modules, packages, etc.) be directly expressible using the facilities of the OMS. Thus the OMS facilities should be sufficiently rich to express Ada code at least to the module/package level, and possibly even to the statement level, allowing representation of something on the order of Diana trees in the OMS. Many current Ada compilers implement the program library as a single file in the host file system, with the internal structure of the library being peculiar to the compilation system and unknown to the host. However, although it is clearly not intended, this approach is not ruled out.

The characterization of Object Management Support in the remainder of the section is based on the "Stoneman" requirements [Buxton80] for a database, using a model based on entity-relationship concepts. Although a PCIS design meeting these requirements is expected to demonstrate the characteristics and capabilities reflected here, it is not necessary that such a design directly employ this model. This model, for which definitions and requirements follow, fulfills these requirements, and any alternative data model shall also fulfill the requirements that follow.

It is impossible to express concepts without language. The selection of a model based on entity-relationship concepts to present the general requirements of software development and maintenance in this area provides a vocabulary which allows the requirements to be elucidated clearly and concisely. It is recognized that use of a model in stating requirements could tend to bias the developers in undesirable ways toward implementations similar to the model. It could, for example, be based on a hierarchical, network, relational, functional, or object-oriented model. However, it was felt that a model-less statement of the requirements was beyond our abilities; the resulting statement would become so general as to lose all meaning. It is therefore important to recognosce that the OMS is a model, and any alternative which meets the requirements would be acceptable.

Go forward to Section 4.1: Objects, Relationships, and Attributes.