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
SECTION 8
REQUIREMENTS FOR TOOL MANAGEMENT AND SERVICES FOR TOOLS
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:
- Registration
- Installation
- Removal
- Update
- Administration of multiple versions
- Administration of multiple copies
- Integration with other aspects of the environment
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:
- Determining the context in which a tool was invoked
- The other tools that are dependent on the tool (tools that
must be updated together)
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:
- Microsoft Windows' help engine
- UNIX's man-page X-aware utility
- Hypertext systems such as Owl
It is possible that the standard support for object distribution and
object identification will satisfy this requirement.
Go forward to
Section 9, Ancillary Requirements.