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
4.4 Data Manipulation
Specific, named operations (and sets of operations) on objects,
attributes, relationships and their types are an important constituent
of an OMS. A major function of the OMS is to regulate the interaction
of objects and operations, such that a defined set of rules is not
Objects. The PCIS shall provide facilities to:
a) Create objects
b) Delete objects
c) Copy objects
d) Examine objects (by examining their attributes, relationships
e) Modify objects (by modifying their attributes and components)
f) Identify objects (as specified in
g) Identify the type of an object
h) Identify the components of an object
i) Identify the objects of which an object is a component
4.4B Relationships. The PCIS shall provide facilities to:
a) Create relationships
b) Delete relationships
c) Examine relationships (by examining their attributes)
d) Modify relationships (by modifying their attributes)
e) Identify relationships (as specified in
f) Identify the type of a relationship
g) Identify the objects of which a relationship is a component
4.4C Attributes. The PCIS shall provide facilities to:
a) Examine attributes
b) Modify attributes
c) Identify the type of an attribute
4.4D Components. The PCIS shall provide facilities to:
a) Associate a component with an object
b) Dissociate a component from an object
4.4E Binding language features for Input and Output.
a) PCIS shall provide basic Input/Output operations on bulk data
b) PCIS shall define the effect on the object base of standard
Input/Output facilities of a given binding language.
c) It is desirable that compilers support PCIS semantics in
implementations of the standard language Input/Output facilities.
Requirement 4.4E(a) requires that PCIS shall provide a set of
operations to read and write bulk data (for example, uninterpreted
sequences of data such as files or communication pipes). Furthermore,
the semantics of such operations shall not depend on any binding
language. PCTE provides such primitive I/O operations which can be used
instead of the language dependent I/O operations. This solution is
portable on any compiler.
Requirement 4.4E(b) requires that, for any binding language which has
I/O operations, the semantics of these binding defined operations be
specified when they apply to contents of PCIS objects. In particular,
such semantics will be, as far as possible, expressed in terms of the
basic language independent I/O operations provided by PCIS Requirement
4.4E(a). This will provide a guarantee that any PCIS tool using the I/O
features defined within the language binding will have the same common
effect on any implementation of PCIS and therefore will be portable.
This will also document the effect of these operations on many aspects
which are usually unclear in many specifications, for instance, the
security behavior and the locking policies.
Regarding Requirement 4.4E(c), it is unlikely that compiler suppliers
will have much interest in customizing language I/O operations to
interface with PCIS but on some platforms there may be hooks into the
implementation that allow those operations to be adapted to the
required semantics on PCIS objects. Also PCIS does not require compiler
vendors to supply such an implementation but Requirement 4.4E(b)
implies that if they do supply it, they all will have to comply with a
common well-defined semantics.
4.4F Concurrency Control. The PCIS shall provide mechanisms to
control concurrent access to data represented in the Object Management
A software project will have many users active simultaneously. To allow
them to work productively and without mutual interference, it must be
possible to isolate the collections of objects with which they are
working. This need is similar to that for configuration management.
A tool with the access rights to change some particular part of the OMS
data needs to be able to lock out changes by other tools with similar
rights, so that it can perform a series of operations without
interference. This is different from the changing of access rights to
the data in that it must be legal for a tool which has only the right
to change the data, not necessarily the right to change other tools'
access rights to the data.
4.4G Version and Configuration Support.
a) The PCIS shall provide a mechanism for specifying and
implementing policies of versioning, in which multiple versions of
objects are maintained and access by default to a preferred or current
version is allowed.
During the development of a product it is inevitable that intermediate
versions of elements of the product will be produced. These elements
will, during the development process, be integrated. Subsequent changes
to these elements must be strictly controlled since the work of many
users can depend on a particular version. There needs to be some way of
introducing new versions in a controlled manner such that users of a
previous version can adjust to the new version at a time of their
choosing. It is desirable that the existence of multiple versions be
transparent to the majority of tools. However, that is not mandated by
This relates to the topic of transaction support. "Long-term"
transactions may need to either keep intermediate versions or have a
way of recovering intermediate work-product objects by identification
of such intermediate versions.
The mechanisms by which versions are related, for example, by version
number or successor/predecessor relationships, is left to the PCIS
designer. The manner in which versions are recorded (for example,
whether difference techniques are used) is largely an implementation
b) The PCIS shall provide versioning of both elementary and
Objects for which versioning is required can be simple objects like
source files but more generally, they can be composite such as
structured documents or complex software configurations.
c) The PCIS shall support the building of different types of
configuration management systems.
There are many possible policy choices to be made so far as
configuration management is concerned. For instance, it must be
possible to allow the version naming policies to be made consistent
with company-wide policies. It must be possible to let change-control
and the methodology influence the organization of configurations, the
context within which they can be modified or the language governing the
selection of configuration components. No single policy is perceived as
adequate for all kinds of organizations and all sizes of projects. The
PCIS shall therefore not impose an exclusive choice but rather allow
for the building of several configuration management systems.
4.4H History Mechanism. The PCIS shall support a mechanism for
collecting and using history. The history mechanism shall provide
sufficient information to support comprehensive configuration control.
The reader is referred to the definition of
in the list of definitions.
The history mechanism discussed in this section is not necessarily
different from a particular use of the basic object, attribute, and
relationship facilities provided by the OMS. The history of objects
that are important to a development project may be recorded in special
relationships, attributes, and objects defined for that purpose. It is
not intended that the recording of history be either mandatory or
all-inclusive. The management of a particular project should be able to
decide which objects will have their history recorded and whether that
recording is to be mandatory. For example, the history of an a
compiler's output file might refer to the corresponding source code
file, the compiler used, compiler options, etc.
4.4I Uniformity of Mechanisms. The PCIS shall provide mechanisms
which apply to:
a) An object and transitively to all of its components
b) An object without its components
Equivalent mechanisms (including concurrency control mechanisms) shall
be provided for each of these two cases.
This requirement specifies the key feature of composite objects. It
requires that the PCIS provide facilities that, in one step, apply to
all components of an object. Some operations for which this would be
desirable include copy and delete. Such a capability naturally models
actions performed in software engineering, such as removing a complete
outdated version of a product. Item (b) of the requirement simply
points out that it must at the same time be possible to operate on
composite objects in their own right, without their components. It is
most natural for both mechanisms to be equivalent and, it is expected,
consistent with one another.
Go forward to
Section 4.5, Transactions.