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 following definitions in the list of definitions in Section 10: PROCESS, PROGRAM, RESOURCE, ACTIVATE, DEACTIVATE, TERMINATE, SUSPEND, and RESUME. These definitions pertain specifically to this section. The processes managed here are not to be confused with software life-cycle processes. The IRAC requirements as a whole are intended to apply to an interface that supports the software process. ``The general purposes of the process management services in an SEE are the unambiguous definition and the computer-assisted performance of software development activities across total software lifecycle activities'' [NIST91].

A fundamental requirement of a framework is to provide program execution facilities through which software development tools can be executed. These facilities support tool composition, execution, and testing. Reusing executable programs economically increases tool functionality. Furthermore, there is a desire to increase the longevity of PSEs through the provision of facilities hosted on distributed and heterogeneous systems.

The notion of building tools from smaller programs is consistent with contemporary software engineering practice that advocates precise functional decomposition of complex components into separate simpler components. In addition, when the programs are independently compiled and linked, the separate program name space affords the opportunity for distributing the execution of the programs that comprise the tool. For example, the distribution of a PSE in an environment consisting of an interconnection of mainframes and workstations may be used to separate tool functionality to provide a more responsive user interface. In this instance, the composition of a tool would exploit the facilities that support the cooperation among code that executes on different computers.

A further example of building tools from smaller programs arises with the facility for user-defined operations. PCIS designers may choose either to treat each operation as a separate program, or to treat the collection of operations on an object as a single program. The requirements of this section have been written on the latter assumption. The PCIS designers are left with this and associated design decisions. One issue is the relationship between program activation and creating object instances. Another associated issue is the impact on access control mechanisms.

The requirements do not present a view as to whether a program should be multi-tasking or not. Likewise the requirements do not present a view as to whether a user-defined operation can be multi-tasking or not. Such decisions are left to the PCIS designers. Allowing multi-tasking within programs and operations gives considerable power to the tool writer, but complicates scheduling.

At a minimum, program execution facilities must enable one program to call (invoke) the execution of another program, that is, to create a process in a well-defined way that enhances the construction and transportability of PSE tool sets. This is consistent with the Stoneman [Buxton80] statement that "the KAPSE shall provide a mechanism whereby it shall be possible for one APSE tool to invoke another APSE tool and supply the invoked tool with parameters". Thus, the potential transportability of a Command Language Processor tool among PCIS conforming PSEs is increased, allowing, for example, a compiler tool set to be constructed through a command procedure that invokes the various phases (programs) that comprise the compiler. The ability to concurrently execute another program provides greater utility to the tool builder than many existing interfaces that are used to accomplish tool composition through the concatenation of program executions.

A process is analogous to an Ada task in that it executes logically in parallel with other processes, has mechanisms for interprocess synchronization, and can exchange data with other processes. However, a process differs from an Ada task in two critical ways:

  1. Data, procedures, or tasks within one process cannot be directly referenced from another process, whereas within an Ada program there can be direct references from one Ada task to other Ada tasks.
  2. Processes are only bound together by cooperative use of the PCIS facilities, while Ada tasks in a program are bound together prior to execution.
The overall objective of this section is to provide a minimal set of facilities that support synchronous and asynchronous modes of program execution. Furthermore, attaining this objective should not compromise the effective use of all processing resources in order to achieve parallel/distributed execution or efficient serialized interleaved execution.

Three significant events are identified in the process life-cycle: activation, termination, and deactivation. Activation is defined as the event that creates a process. Termination is defined as the event that precludes a process from further processing; the process ceases execution but can still be referenced through the PCIS. Deactivation is defined as the event that erases all PCIS-maintained information about a process including the process identity. Consequently, the identity of the process may be reused following deactivation providing that it does not compromise the integrity of the PCIS implementation.

Finally, the ability to exploit tool synergism in order to compose complex tools from simpler tools has motivated specific requirements for creating processes, controlling processes, and communicating among processes in order to promote a comprehensive process execution model within the PSE. These requirements are the basis for facilities that can be provided within the PCIS to promote the straightforward construction of tools and toolsets beyond that provided by conventional command procedures. The requirements are specified to allow for maximum innovation in the PCIS design and to minimize the prejudicial influence of existing tool interface designs and implementations.

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

The access controls and security rights required are those specified in Section 7.2. In that context a subject is always a process, although a process may also be an object for some operations.

The requirements of Section 2.6 (Modularity) and Section 2.8 (Technology Compatibility) shall apply to the Program Execution Facilities required by this section.

This statement reminds the PCIS definer of two of the General Design Objectives to be considered in fulfilling the requirements of this section.

The Modularity requirements permit a layered specification of the PCIS. The resulting PCIS specification may permit partial implementations. An interface set having optional partitions may present problems of consistency. For example, behavior must be well-defined when optional facilities are bypassed.

One conceivable partitioning of the PCIS is that the OMS is the smallest required portion and no new interfaces are present to fulfill the Program Execution Facilities.

Therefore, depending on its partitioning, the PCIS may require selecting a standard operating system platform and fulfilling the requirements of this section in terms of that platform. In this way, the PCIS may define higher-level Program Execution Facilities while having well-defined behavior when those facilities are bypassed and the underlying platform services are accessed directly.

5.1 Parallel Execution

The PCIS shall provide for the parallel execution of processes.

This requirement specifically stipulates that processes may execute in parallel except when serialized execution is required by the semantics of the facility. A PCIS design that forces serialized process execution is unacceptable unless serialization is necessitated by insufficient processing resources, thus requiring two or more processes to share one, single instruction stream processor. In this event, the PCIS must provide interleaved (logically parallel) process execution that allocates processing resources among processes "fairly".

Processes can be dynamically created as a direct consequence of the activation of programs by other processes.

5.2 Activation of Programs

In the context of the PCIS, and of program support environments generally, a program is a relatively static entity that may exist in various forms, from source to executable image, in the normal progression from inception to execution. The term "process" is used to denote an abstraction that represents the execution of a program. It is implicit that program execution denotes any of the states that comprise a program's execution chronology (ready, blocked, waiting, etc.).

Activation of a program may be viewed as an instantiation of an executable image of a program together with the establishment of the control information and resources that are necessary for its execution. Specific properties of a process are not elaborated, for example, loci of control and address space, since this level of detail is superfluous to understanding the requirement. It is recognized, however, that for a distributed execution environment, an important capability is to normalize differences within the execution environment for the PSE and between the PSE and any target environment to which it is connected. Consequently, for most tools, the actual processing location of program execution is expected to be transparent in the denotation for process and is consequently not explicitly required by the program execution facilities. This transparency enhances further PSE tool transportability over a variety of different computer architectures. However, it should be noted that Requirement 2.10B requires that it be possible to explicitly influence the actual processing location.

A straightforward dependency relationship for these requirements is one that implies a hierarchical process structure that originates from the process creating the processes executed by the tool or toolset. This permits the resources to be inherited and reclaimed in a well-established and accepted fashion. However such a strict hierarchical relationship among processes is not mandated by the requirements.

5.2A Activation. The PCIS shall provide a facility to create a process out of a program which is in a format suitable for execution. This process creation is called activation of a program. The PCIS shall support multiple activations of the same program.

Following activation the process is ready for execution. The assumption is made that an executable image for the program has been prepared using appropriate language processor tools either prior to, or as a part of, activation. Following activation, a process includes the notion of all resources explicitly and implicitly required to support the execution of the specified program, including ancillary procedures or resources such as those necessary to support program debugging and monitoring.

It is important to separate the requirement for program activation from requirements that may exist to support the fragmentation or distribution of a program's execution. The latter requirements are typically satisfied by the overlay and run-time functionality necessary to manage a program's use of the addressing and processing capacity of the execution environment. This should be transparent when writing source code for a transportable tool and is more properly considered to be a requirement for the language processor tools, viz., compiler and linker. Consequently, this is intentionally absent from the scope of the requirements for the PCIS.

It is anticipated that tools will wish to share other tools and they must not be inhibited from so doing by previous activations of the shared programs.

5.2B Process Identification. The PCIS shall provide that each process be identifiable. In particular it shall be possible for a process to identify:

a) Itself.

b) The (parent) process from which it was activated.

c) Each of the (child) processes which it has activated. The means by which a (child) process is identified shall be available to the (parent) process as an indivisible part of the activation.

After process creation, subsequent communication and synchronization with the process depend upon the ability to identify it. The PCIS must, therefore, provide identification in some form.

This requirement does not say how processes shall be identified, merely that there must be some mechanism allowing the process to be identified in some way and is analogous to Requirement 4.3A. Processes may be identified relative to some root process by some user or system assigned name (for example "myjob/editor" or "."), by the order of activation (for example, 1.2.3 represents the third child of the second child of the first child of the root process), by what they are doing (for example, "the process that has this resource locked"), by a global identifier (like the UNIX process number) or by the identification method for objects (see Requirement 4.3C) if processes are represented as objects.

In the particular case of child processes there is the additional requirement to identify each child individually. To facilitate this in the situation where a process is using multi-tasking, the means of identification needs to be established as an indivisible part of the activation, for example, as a unique process identity or as a child number relative to the parent process.

A process ceases to exist after deactivation and will therefore no longer be identifiable.

5.2C Process References. The PCIS shall provide a mechanism for referencing processes, in particular:

a) A reference shall identify a single process until the reference is dissolved or the process is deactivated. If the process is deactivated, all subsequent uses of the reference shall not identify any other process.

A specific facility must be provided for referencing a process. This requirement augments the requirement for being able to identify a process by requiring support for referencing the process once identified.

The model assumed for referencing one process by another process is analogous to that used for referencing files in a contemporary file system. In this model, a process reference can be created as an association between an identifier and a process. Dissolving the reference removes the association. It is recommended that a compliant PCIS design provide a unified reference model. Implicit in this recommendation is the expectation that the process reference provides efficient and secure reference to a process and that it eliminates the need to revalidate access rights and privileges each time the process is referenced.

A PCIS design that guarantees uniqueness of names after deactivation, while not required, is compliant with the requirement.

It is envisaged that the PCIS will provide specific facilities for a parent to reference a child process and a child process to reference its parent. The PCIS definer may also provide facilities for a process to pass a reference to another process, for example so that sibling processes can refer to one another conveniently.

b) It shall be possible to use a reference to a process several times with access controls checked only once, where this is compatible with the security requirements of Sections 7.2 and 7.3.

This is essentially a performance issue.

c) The PCIS shall support the ability to associate and dissociate stability requirements with a reference. The stability requirement applies to a referenced process and at least includes that the process is not deactivated while the stability requirement persists.

This is analogous to the facility to specify stability requirements for referenced objects.

5.2D Activation Data. The PCIS shall provide a facility to make data available to a process when it is created.

The facility to make data available following activation of a program is similar to the presence of in-mode parameters included in the specification of the main program. The requirement is intended to provide a straightforward capability for the activator of a program to optionally pass data to the process that results from the activation.

While it is expected that the rules for parameter conformance and passing will remain consistent with the appropriate language rules, restrictions on activation data are not prohibited in order to support a dynamic environment that is efficient and implementable. For example, a PCIS design may legitimately restrict activation data to a single data type. It is likely that such restrictions would be compatible with any Ada - Appendix F [Ada83] parameter requirements for a compiler implementation; however, no additional functionality should be assumed from the Ada Run-Time System to support activation data. The rationale for the requirement is to ensure that a practical facility for parameterized activation of a program exists that is analogous to the call of an Ada procedure.

5.2E Dependent Activation. The PCIS shall provide a facility for the activation of a program that depends upon the activating process for its existence. This implies that the PCIS shall specify clear, consistent rules defining the termination behavior of processes dependent on a terminating process.

This point clarifies the behavior of processes whose existence depends on that of the parent process.

A typical requirement of many tools is for a process to have a well-defined relationship with the process that invoked its activation, that is, the creating or parent process. There are two distinct motivations for requiring this relationship:

  1. There should be some notion of accountability within the PCIS. Since processes consume resources, there should not be uncontrolled access to them. Therefore, a capability is needed to authenticate the rights through which a process derives its processing resource. A dependency relation on the parent process provides a measure of accountability for such authentication, that is, inherited rights.
  2. In order to simplify the termination of related processes. When a process is terminated explicitly by itself or another process, it should optionally result in all processes created by the terminated process becoming terminated. Thus, the process that requested the termination is not required to individually terminate all processes created by the process to be terminated.
A straightforward dependency relationship for these requirements is one that implies a hierarchical process structure that originates from the process creating the processes executed by the tool or toolset. This permits the resources to be inherited and reclaimed in a well-established and accepted fashion. While a strict hierarchical relationship among processes is not mandated by the requirement, it should be possible for a parent process to optionally request, when activating a program, dependent process termination when it terminates. Consequently, a process should be provided with a facility to create a dependent subordinate process, viz, a subprocess.

The rationale for requiring clear and consistent rules that define the termination behavior of processes that are dependent on the terminating process is based upon the need to safeguard against nonproductive process execution. In particular, when a parent process terminates abnormally, any dependent processes that are servicing the parent should be prevented from further execution.

5.2F Independent Activation. The PCIS shall provide a facility for the activation of a program that does not depend upon the activating process for its existence. This implies that none of the independently activated processes created by the activating process will be automatically terminated on termination of its parent process.

Certain categories of IPSE tools are expected to execute independently of the tool that requested program activation. Consequently, there is a specific requirement for a process to continue execution after its parent has terminated. For example, tools that execute in a background execution environment, such as spooler-type tools, are usually independent of the invoking process. Independent activation does not preclude the need for accountability of a process. However, the means through which this accounting is achieved is not required to be specified by the PCIS since there is no apparent benefit that accrues to tool transportability.

5.3 Termination of Processes

The rationale for the termination requirements is based upon the need to provide complementary capabilities to those specified for program activation. The PCIS must permit prevention of further execution of a process while still allowing access to its termination data.

5.3A Termination. The PCIS shall provide a facility to terminate a process. There shall be two forms of termination: the normal termination of a process and the abnormal termination of a process. Normal termination of a process is always self-determined, whereas abnormal termination may be initiated by other processes, subject to the access restrictions on the terminated process.

A process may terminate any process that it can reference, subject to any access restrictions on the operation. In particular, a process may terminate itself, either normally or abnormally.

An important aspect of normal termination is that it is both orderly and voluntary and is therefore called process completion. Conversely, termination of a process by another process (or by a task within the process itself) is not necessarily synchronized with the process to be terminated and is not necessarily orderly.

An abnormal termination capability is required when aberrant process execution is detected or in the event that unhandled exceptions are visible outside the process in which they were raised. A useful distinction is recognized between completion and abnormal termination regarding the availability of information to other processes. When a process completes, it is expected that the precise reason for termination will be provided by the terminated process. However, when a process is abnormally terminated this information may not be available. This distinction is used to guide the requirement stipulated below for termination data.

5.3B Termination Data. The PCIS shall provide a facility for termination data to be made available. These data shall provide at least an indication of success or failure for processes that terminate normally. For processes that terminate abnormally the termination data shall at least indicate abnormal termination. The termination data shall remain available until the terminated process is deactivated.

This requirement is motivated by the need to maintain logically consistent process execution among cooperating processes. For example, when a process is created to perform a service for another process (not necessarily the parent process), data indicating the success or failure of the service should be made available to accommodate asynchronous normal or abnormal termination.

The precise information that comprises termination data are not specified, other than it must, at a minimum, permit the recording of successful or failed execution. It is expected that a PCIS design will provide for additional information, such as performance data and resource consumption data. PCIS designers need to consider the relationship of persistence of termination data of a process with the OMS transaction design.

When a process terminates abnormally it cannot guarantee the accuracy of the termination data. Under these circumstances, the PCIS is required to ensure that the termination data include an indication of abnormal termination.

5.4 Deactivation of Processes

The PCIS shall provide a facility to deactivate a terminated process. On deactivation the process shall be removed so that it can no longer be identified.

The rationale for the deactivation requirements is based upon the need to provide complementary capabilities to those specified for program activation. That is, the PCIS must permit the deletion of processes and the recovery of any residual resources, for example, the resources dedicated to the termination data.

5.5 Cooperation of Processes

Tools can be constructed to exploit the capability to distribute functionality as separate processes. A corollary of this is a requirement for a means to communicate dynamically between processes. This is necessary to support the use of cooperating processes within and between tools. The mechanism for such cooperation may implement control integration [NIST91].

5.5A Data Transmission. The PCIS shall provide a facility for the transmission of data between processes. The facility shall support layered communication protocols.

Specific facilities must be provided for exchanging data among processes. The generality of the requirement is deliberate in order to avoid suggesting a particular design and to encourage an effective approach for interprocess communication.

In particular, it is expected that no single message passing paradigm will be appropriate for all applications. Event notification, file transfers and partial database exchanges are examples of applications requiring different abstractions from the data transmission services on which they rely. The PCIS may provide a flexible set of protocols, facilitate the construction of new protocols, or both.

Common models for these facilities are found in SoftBench's Broadcast Message Server and Microsoft Windows' Dynamic Data Exchange messaging service.

For another example, the following model is one potential approach that satisfies the requirement. In this approach, the exchange of data are specified using an abstract type resource that provides a means for passing data among processes having access to the resource. The resource is accessible through a symmetric interface that facilitates both the synchronous and asynchronous exchange of data. The identification and attributes of the resource are consistent with other PCIS objects and are independent of message synchronism and the multiplicity of data exchanges.

The semantics of the interprocess communication facilities are expected to be functionally compatible with those specified for contemporary message passing models. While it is not required that the Ada language rendezvous semantics be specified for exchanging data, it is expected that the facilities are sufficiently comprehensive that the tool builder may construct a rendezvous style interprocess communication capability. The principal reasons for not requiring that interprocess communication be functionally equivalent to the Ada rendezvous style of communication are: a desire for consistency and orthogonality in the facilities that are available to the tool builder, and the fundamentally different execution contexts of a process and an Ada task.

A requirement that interprocess communication provide identical features to the Ada rendezvous model may impose the restriction that interprocess communication follow rules that may be unwarranted for communication among processes which are outside the semantics of the language. For example, a selective terminate for processes analogous to that for Ada tasks would require that process termination adhere to the rules for Ada dependent tasks. This clearly compromises process termination orthogonality, for the sake of consistency of inter and intra-process communication, since process termination should be independent of communication requirements. Conversely, relaxing the requirement for equivalent functionality compromises consistency by specifying similar communication facilities that are governed by different rules, thereby potentially causing confusion for the tool builder. In addition, programs, rather than Ada tasks, are likely to be choices for software distribution among separate computers. Consequentl

5.5B Data Transmission Among PCIS Implementations. The PCIS shall provide a facility for the transmission of data between processes utilizing independent PCIS implementations. The facility shall support layered communication protocols.

This requires mechanisms for inter-process communication (IPC) between independent environments. This merely recognizes that the need for remote access between environments is frequent, that technology is in wide use today to fulfill that need, and so any new system specification (such as the PCIS) would be deficient if it did not fulfill the need.

5.5C Synchronization. The PCIS shall provide a facility for the synchronization of cooperating processes.

A facility to synchronize process execution is required. Synchronization is specified separately from the requirement for interprocess communication to emphasize the functional difference between communication and synchronization.

A conforming PCIS design may include process synchronization as a result of interprocess communication; however, specific facilities are expected to be available for process synchronization. While it is mandatory that Ada task execution semantics are not compromised by the process execution model, it is recognized that the strict separation of process and Ada task management may incur unacceptable process execution behavior. Therefore, a coordinated execution model for process and Ada task synchronization may be appropriate, but it should not require extensive increased support from the Ada Run-Time System.

The generality of the requirement is deliberate in order to avoid suggesting a particular design and to encourage an innovative approach to process synchronization.

Typically, the facility should provide for establishing synchronized execution points among cooperating processes. For example, a process may wish to coordinate its continued execution with some events; this event may occur as a result of some explicit action, provided through the PCIS, by another process.

5.5D Suspension. The PCIS shall provide a facility for suspending a process. Operations currently being performed on behalf of the process may continue.

It is essential to realize that the operations being performed on behalf of a process refer to PCIS operations which execute autonomously. It does not refer to tools executing as dependent sub-processes, such sub-processes could be suspended along with the parent. An example of a PCIS operation executing autonomously may be an access to an object which is held on another node of the network. The data transfer may well be performed by an actor executing on the remote node. Such an actor would complete its execution and return the result.

In the context of an executing process, this requires the suspension of all Ada tasks that are executing, a facility not directly available in the Ada language. During the execution of an Ada program, individual Ada tasks may become suspended as a result of language features, for example when awaiting a rendezvous. However, suspension of a process must not change the behavior of the Ada task execution within the process unless the change is a direct consequence of the task not being in an executable state, for example, failure to honour an interrupt. It is recognized that a corollary of suspension of a process is that it may result in failure of Ada tasks that depend upon real-time interactions and delays. It specifically does not imply the release of any resource which a process has assigned to it, or which it has acquired, to support its execution.

5.5E Resumption. The PCIS shall provide a facility to resume a process that has been suspended.

The result of applying this facility to a suspended process is that all of the tasks suspended in the process are made available for execution simultaneously. The resumption of a process need not necessarily result in rescheduling of task execution within that process; that is, the same set of Ada tasks may continue execution following resumption of the process unless rescheduling is necessitated by the occurrence of a time-dependent event, for example, completion of an external task blocking operation. Consequently, the semantics of the Ada task model are safeguarded by ensuring that rescheduling only occurs for events that would occur if the process had not been suspended and then resumed. Some aspects of the task scheduling are intentionally undefined and could allow rescheduling on process resumption. This is likely to be an implementation decision.

5.5F Notify Mechanism. The PCIS shall provide a mechanism for programs to be invoked and processes to be notified when specified operations are performed on a specified object.

Operations can be performed on objects, relationships, attributes, processes and resources. One example of the use of this facility is where several windows associated with different processes and possibly on different workstations are displaying the same object. Modification to the object via one window should be notified to the processes associated with the other windows.

Another application is in automating the software development process. Products of one life-cycle phase are inputs to another. Programs supporting subsequent phases can be automatically invoked when their inputs become ready.

Process notification is required to fulfill the needs of processes which are affected during their execution by the actions of otherwise asynchronous processes. Program invocation is required to assist tools whose preconditions for execution may not be met for an indeterminate time. Additionally, automatic program invocation can permit applications of the notification mechanism to survive system crashes, yielding a more robust and useful mechanism.

PCIS designers shall specify the relationship between this notification mechanism, and any object oriented class/type defined or inherited operation execution facilities provided in the OMS. Designers shall also specify the consequences of notifications occurring within the purview of transactions within the OMS.

5.5G Connected-target Execution. The PCIS shall support the loading and initiation of the execution of a program on a connected target.

This reflects the emphasis on support for development of real-time systems. Such systems are normally developed in a host/target approach, where the target may have no PSE facilities.

While developing programs for a real-time embedded system, it is common to use a host/target development mode of working. This is, in general, a matter of necessity, since the target frequently has insufficient resources to support the development toolset. It is increasingly the case that this method of working is the most appropriate and cost effective for other types of software. During host/target development, initial testing is usually performed on the host machine, since that machine is available (the target may not be) and has extensive testing and debugging tools.

5.5H Inspection and Modification. The PCIS shall support mechanisms to inspect and modify the execution environment of a process executing either on the host or on a connected target.

The facility is intended to promote support for target independent (universal) debuggers and tools. Such universal debuggers are seen to be highly desirable for those developing systems for a variety of target machines. The construction of universal debuggers on a PCIS implementation is expected to require cooperation with each target RTS.

5.6 A Uniform Model that includes Processes

The PCIS shall provide processes as objects.

The PCIS is required to apply its data modelling facilities to process objects. This provides the PCIS with a uniform underlying model for the expression of its concepts. It provides tools with a small, uniform set of primitive concepts for the accessing of environment objects. It furthermore permits tools to record the interrelations and properties of those diverse objects in a single object base.

This requirement must be contrasted with the option to cite a standard operating system specification as a component of the PCIS. If PCIS were to choose an existing standard operating system as its form of program execution facilities, then processes would not be unified with the OMS.

Go forward to Section 6, Input and Output.