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:
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.
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.
Processes can be dynamically created as a direct consequence of the activation of programs by other processes.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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
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.
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.
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.
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.
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.