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
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
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
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:
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.
- The ability to prevent change operations (for
configuration control purposes)
- Security and confidentiality facilities
- Data typing (this aspect is considered further below).
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
- There is a need selectively to allow or prohibit certain
operations on certain data requested by certain users or
f) The PCIS shall support mechanisms for developing new data
descriptions by inheriting (some of) the properties of existing data
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.
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
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)
program libraries, (ii) object oriented language class
description libraries, (iii) CASE analysis and design data
repositories, (iv) documentation systems, and (v) configuration
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
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
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.