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



8.1 Tool Management

8.1A Tool Composition. The PCIS shall provide mechanisms that allow tools construction via composition of other tools.

The PCIS must provide ways to construct powerful tools from smaller less powerful ones. A good example of the requirement for this is the ability to compose a tool from a compiler and linker, allowing the compile and link to be done in what appears to the user to be a single step.

8.1B Tool Life-Cycle Management. The PCIS shall support the life-cycle management of the tools installed on a PCIS implementation. This support includes, at least:

PCIS implementations are intended to be platforms for integrated sets of tools to be used through out the entire life-cycle of a project. Since the life-cycle for significant projects is expected to be quite long, it is likely that during that life-cycle, tools will be installed, removed, copied, and updated. The PCIS must provide services to manage the use and maintenance of tools during the project life-cycle in order to be a reasonably useful platform.

Support for registration, installation, modification, and removal of tools includes at least facilities for placing the tool in the PCIS Object Management System. Once in the Object Management System, the tool must be useable by those intended, subject to the access control policies of the particular site. The addition, creation, and modification of OMS typing information (object types and methods) must be conveniently supported. Facilities for associating a tool with auxiliary information such as help files and natural language message files must be provided. Facilities for encapsulating a foreign tool (a non-PCIS tool) must also be provided.

During a long project development, it is very likely that multiple versions of the same tools will be in use at the same time. The PCIS must support the use of multiple versions of a tool at the same time and provide the necessary facilities to distinguish the tools and determine which version of a tool was used to produce or modify an object.

Since it is expected that sets of tools will be used together and some tools will be composed from others, the PCIS shall support the management of sets of tools. This includes, at least:

8.1C Tool and Operation Binding. The way to bind a tool and an OMS class/type defined operation to a PCIS implementation should be independent of the PCIS implementation.

Tools may be bound according to their implementation mechanism, be it shell level composites of sub-tool program execution, program binary module execution, control message integration programs, or the like.

PCIS designers need to specify how tools and class/type defined operations become "attached" to the framework or to class/type definitions, how they make themselves known, how they cooperate with data, control, OMS transaction, and User Interface integration.

8.2 Services for Tools

8.2A Licensing Services. The PCIS shall support Tool Licensing.

The PCIS is expected to support environments populated with tools from a variety of vendors. It is expected that the tools will be licensed. Thus the PCIS needs to provide tool vendors with services that support tool licenses and the enforcement of tool licenses.

8.2B Accounting Services. The PCIS shall provide accounting services.

Some accounting services are utilized by tools as part of their user interaction and as part of their licensing policy. In order for tools to have a portable interface to these accounting services the PCIS needs to provide them.

8.2C Network-Based Help Services. The PCIS shall support network based help services for tools.

PCIS implementations are expected to be distributed over a network (both wide area networks and local area networks). It is the goal of PCIS implementations to provide this distribution in the most transparent way possible. To this end, the PCIS shall support the provision of network-based help services for tools.

PCIS designers should specify whether PCIS programs use consistent help between different platforms (so PCIS help is consistent among PCIS workstations regardless of platform choice), or whether PCIS programs use help facilities consistent with platform vendor facilities.

Consistent help between PCIS and the native platform tools appeases the platform vendor community, but requires tool suppliers and application builders to implement different help programs for each platform and user interface.

Consistent help between different PCIS hosts simplifies tool supplier convergence activities, but requires different help programs for each platform.

Examples of drastically different help engines are:

It is possible that the standard support for object distribution and object identification will satisfy this requirement.

Go forward to Section 9, Ancillary Requirements.