IRAC 4.4: Data Manipulation

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 violated.

4.4A Objects. The PCIS shall provide facilities to:

a) Create objects

b) Delete objects

c) Copy objects

d) Examine objects (by examining their attributes, relationships and components)

e) Modify objects (by modifying their attributes and components)

f) Identify objects (as specified in Section 4.3)

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 Section 4.3)

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 attributes.

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 System.

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 the IRAC.

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 issue.

b) The PCIS shall provide versioning of both elementary and composite objects.

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 HISTORY 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.