emeraude portable common tool environment

Emeraude portable common tool environment

IAN CAMPBELL

Abstract: This paper present the Emeraude portable common tool environment. It begins by explaining the approach followed in the design and construction of software development environments, and the Emeraude product itself. It continues with a general overview of the numerous related developments, with respect to standardization efforts, products and associated research and development. There follows a technical presentation of the architecture, addressing in particular issues on process control, object management and use of the object management system, distribution over a network of workstations, and the user interface. The paper assumes a general knowledge of PCTE given in an overview paper in Information and Software Technology, Vol 29 No 8.

I t is now widely recognized that the availability of integrated project support environments (1PSEs) is crucial for improving the productivity of the

software industry. It is also recognized that the environments should not be tied to particular hardware. Indeed, one important aspect is to enlarge the choice for software developers of which tool sets (methods, languages, etc). to use, whether in a given organization or for a given development. Another aspect is the need to enlarge the tool market for the tool suppliers, so as to increase potential sales, which in turn should lead to lower costs for environment builders and end users.

One approach to the efficient integration of software engineering tool sets is to factor out those common features required by most tools for information management and interaction with the tool users. It is therefore an efficient way forward to define a domain in which these common needs are satisfied, while leaving the tools themselves to carry on their specific tasks and offer their specific facilities. Out of this realization has arisen the concept of the portable common tool environment (PCTE) whose framework corresponds to the operating system kernel of the IPSE.

PCTE has been defined through a collaborative effort under the ESPRIT programme and is seen as providing the basis for advanced software engineering environments by defining a public tool interface to be

GIE Emeraude, 38 Boulevard H-Sellier, 92154 Suresnes Cedex, France

used as the standard for tool integration, and the necessary portable framework for the IPSE integrated on the PCTE basis.

From this approach it is clear that PCTE itself is not an IPSE, but provides a basis on which an IPSE architect can construct environments by the integration of the appropriate tools supporting all aspects of the software development process.

The definition of PCTE has been jointly funded, over the period 1983 to 1986, by the European Community's ESPRIT programme and by six major European computer manufacturers: Bull, GEC, ICL, Nixdorf, Olivetti and Siemens. This definition work was carried out in the context of the PCTE project to define a basis for a portable common tool environment. The PCTE interface definition is now managed as a standard by the PCTE interface management board (PIMB) which has set up the necessary technical and administrative support to do configuration control of the PCTE interface set definition. The board elects itself a chairman for a period of two years and has a board secretary provided by the Comission for the European Communities (CEC). As well as computer manufacturers represented on the board, there are other European organizations such as the European Space Agency, GIE Emeraude, representatives of European software houses and universities, and the independent European programme group (IEPG) of European NATO defence ministries.

E m e r a u d e

Three French companies (Bull, Eurosoft, Syseca) constituted in 1983 a joint venture called GIE Emeraude to implement and market a product offering the standard tool interface defined by the PCTE specifications. Such a product has as its goal to provide a suitable basis for various software engineering projects, and be available on different categories of machines, so as to cover the needs of various teams of software developers.

This product, called Emeraude, is now available on Bull SPS7 workstations, and will be available on Sun, Vax, Hewlett-Packard, and PC/AT workstations during 1988. The Sun implementation is already under- going field tests.

The Emeraude product consists of an implementa-

210 0950-5849/88/020210-08503.00 O 1988 Butterworth & Co (Publishers) L t d . information and software technology

tion of PCTE together with the basic tools required for setting up and using it. The Emeraude PCTE underlying framework for IPSE construction is made up of three basic components:

• object management system (OMS) and process control mechanisms, which manipulate the various entities in the PCTE based software development environment IPSE,

• distribution facilities, which allow the environment to be implemented transparently over a network of workstations,

• user inferface, which provides the basic interaction mechanisms between user and machine, on which the tools build their dialogue with the end users.

The product also includes a standard virtual terminal implemented using the mechanisms defined in PCTE for the tool user interface. Its aim is to provide the facilities for dialogue between a normal end user and a tool, including aphanumeric terminal emulation allowing for Unix compatibility and computer graphics metafile interpretation for the display of diagrams. The user interface mechanisms themselves do not define how the dialogue looks on the screen, but provide the means whereby the IPSE architect can implement the chosen policy for how things look on the screen.

Also supplied as part of the Emeraude product, there are system administration tools, dialogue management tools and the initial tool set from the Esprit PACT project (PCTE added common tools).

The Emeraude product is destined for use by IPSE builders as a basis for integrating software development environments. It includes a manual describing the Emeraude environment, and the user station guide to help new users to get used to using it. Also there is a user manual containing the description of how to use the tools supplied as part of the product. This documentation has been produced for Emeraude by Syntagma Systems Literature of Truro, UK.

Several one-day presentations of Emeraude and PCTE have already been given as seminars. A two-day initiation course is currently provided for new users of the Emeraude product. A full training course for the Emeraude environment will be available from the first quarter of 1988.

Under a special agreement with the CEC, ESPRIT and other European community projects can have free use of the Emeraude product for their needs within their particular project and for its duration.

Emeraude related developments

There are numerous Emeraude related developments in progress. They can be classified in three general categories as work on the PCTE standard tool interface definition, environments being integrated on the basis of Emeraude, and research and development around PCTE.

The necessary control of evolution of the PCTE standard tool interface definition is being managed under the auspices of the PIMB. PCTE has already

created immense interest and there are numerous comments and suggestions which have to be carefully studied for the standard interface to evolve in a healthy way. Certain evolutions are already being studied; coordination is ensured through the technical control arm of the PIMB called the PCTE interface control group.

To complement the current c language interface specification, ADA, PROLOG and Common LISP interface set definitions are in progress, together with a formal definition of PCTE.

The original PCTE project is looking at some aspects of the interface definition such as an implementation of the ADA binding so that tools written in ADA can access the PCTE facilities offered by Emeraude. It is also looking at the definition and manipulation of complex or composite objects, and other specific issues. The ESPRIT PAVE project is investigating the implementation of the PCTE standard interfaces on a non-Unix operating system, Vax/VMS, and is contributing to the Unix independence of the tool interface as well as to how to integrate the access to foreign tools which run outside the IPSE itself but which can be started and controlled by tools integrated in the PCTE based IPSE. In a somewhat similar way, the ESPRIT Aphrodite project is examining the implementation of PCTE on a distributed realtime executive called Chorus, and is contributing to the host-target aspects on how to control a foreign application running on a target environment but able to be debugged from the Emeraude based IPSE.

The Independent European Programme Group (IEPG TA-13) regrouping the defence ministries of European NATO members, has a programme called PCTE+ involving evolution from PCTE to define and assess a language independent IPSE interface set for use by the civil and defence communities. This PCTE evolution programme is defining both the requirements and the PCTE+ interface specification to meet them. The rationale and final PCTE+ specification document will be ready to be submitted to the PIMB by the end of 1989, after some demonstration and assessment. One area of particular importance being taken into account is security (confidentiality and integrity of information).

Other PCTE and Emeraude related activities were already evoked in the previously mentioned article in the October 1987 issue of this publication. PCTE based environments being built around Emeraude (as well as on other PCTE implementations) include the PACT environment being integrated under the ESPRIT programme project of that name, and the EAST envionments being constructed on the basis of Emer- aude and the PACT common services under the Eureka Advanced Software Technology project.

Emeraude technical description

As mentioned above, the Emeraude product consists of a kernel and a set of basic tools to be used in the building of IPSE. This technical description looks

vo130 no 4 may 1988 211

particularly at the Emeraude kernel, which is in effect a sort of specific operating system for project support environments for software development.

Process control

Process control is in Unix style with message queues for interprocess communication.

Process control covers program execution and the communication between a program and its environment, which may include other running programs.

Current practice in these areas is considered to be at a satisfactory level for software engineering environments. As a consequence the goal is to offer the same functionalities as those of a widely-known operating system, namely Unix System V as standardized by the X-Open Group; this choice is governed by the underlying goal of hardware independence. However some extensions are required to meet completely the needs of process control:

• a uniform way to be able to start a process from its static context (executable or interpretable program),

• extra features for suspension, resumption and termination of processes,

• extra features in the management of message queues for cooperation and communication between processes, particularly to explore the contents of a message queue,

• application of the distributed object base facilities to Unix entities such as named pipes, files, character devices, etc.

The execution primitives deal with the notion of a program in execution. They define how an execution can be started or teminated, how it can be controlled, how parameters can be passed to the program, and more generally define the relations between a running program and the environment within which it executes. Facilities are provided for running a program (process), for defining and controlling its access rights and the objects it will be able to manipulate, and for the interactions between a process and its surrounding context.

The communication primitives deal with the way a process can access the file type uninterpreted data (contents of objects) which are kept in the object base. They correspond to conventional input-output facilities and are closely modelled on those of Unix.

Special mechanisms are provided to allow different processes to communicate with a high degree of cooperation and synchronization, and in order to exchange information. In addition to traditional Unix pipes and signals, PCTE provides a message passing facility. These mechanisms are upward compatible with ones found in Unix System V, although they offer some additional, more powerful functionalities.

Object management system

The OMS data model is derived from the entity- relationship data model (E-R) of Chenl; the user can

associate a number of attributes with objects and represent the various relationships which exist between the objects. An object is any entity manipulated by the user: for example document, program fragment, tool, project plan, etc.

A software development environment may be seen as an information utility, and in this sense the purpose of an environment is to ensure that software engineers can get the information they need when they need it. In a similar way, the purpose of tools may be seen as the capturing of information processing it and disseminat- ing results.

This means that a crucial component in an environment is the existence of a central repository of information. In the PCTE approach, the heart of the environment is an object base, modelling the software activity it supports.

The OMS is an information management system, which accesses this object base in response to requests made by any of the environment's components.

An object, in the area of software engineering environments (e.g. in the Stoneman report), can be any such entity as a file, in the traditional sense, a program, a report . . . . or something more abstract like a project or a team.

The goal of the PCTE OMS is to manage all these objects in a uniform way, i.e. to provide storing mechanisms, convenient access means, and to manage the various dependencies that must be maintained in order to support the different versions of a software product, to control the modifications applied to a given object and to know the consequences of all changes.

The OMS must allow the user to associate a number of properties with the contents of an object. These properties may be simple values referred to as attributes, or they may represent associations between objects. The power of an OMS comes from its ability to designate an obiect by a predicate involving its relationships with other objects, rather than by a simple name, and also by the possibility to constrain certain structures through the introduction of schemas. A schema corresponds to a description of certain constraints on the properties of a collection of objects.

Software engineering information bases present particular characteristics. First, their goal is not to make complex computations with the values of the attributes which are associated with an object; these attributes are used to record significant status data or to get access to the object. Second, depending on the organization and general rules or procedures in a given PCTE based environment, the user may have to have the possibility to use the system for his or her own needs, and to define new attributes, without having to go to a higher authority; such attributes will typically have meaning only for the user who introduced them.

Special mechanisms must be provided to assist the tool designers in ensuring the integrity and consistency of the objects manipulated.

A key aspect of an environment, and one that has a major impact on the complexity of the toolwriting

212 information and software technology

process, is the set of functions that are provided to manipulate the various objects in the system. The various agents in the environment (users and programs) can be said to operate on a number of entities that are known to the system and can be designated in it, and which are globally referred to as objects. These may be files in the traditional sense, peripherals, communication channels, or the description of the static contexts of a program, but also objects representing information items such as project milestones, tasks, project management and progression records.

In a medium sized project, a huge number of objects are created which may have complex relationships. Among the numerous examples, one could mention:

• the documentation and the source code of a program (the latter may itself contain several modules),

• the history and the derivation trails for a given version of a given object (representing, a program, a program fragment, a document or other items to which configuration management can be applied,)

• the test set for exercising a particular version of a module with the set of sample results that are supposed to be produced by these tests.

A uniform treatment of the various classes of objects, and powerful mechanisms to store and designate these objects, are two important requirements on a software engineering environment. The natural solution is a system that alows the user to associate a number of attributes, whose values represent specific properties, with objects and to represent the various relationships which can exist between objects.

As already indicated above, the basic OMS model is derived from the E-R data model and defines objects and binary relationships as being the basic items of the environment information base. Objects are entities (in the E-R sense), which can be designated, and can optionally be characterized by:

• what is called a contents, i.e. a repository of uninterpreted data implementing the traditional file concept,

• a set of attributes that are primitive values which can be named individually,

• a set of relationships in which the object participates.

Relationships allow the representation of logical associations/dependencies between objects as well as structured information. In particular, one might need to represent composite objects composed of several objects (a notion that supercedes the traditional directory), or to establish explicitly a reference from one object to another. Relationships also may have attributes, which can be used to describe specific properties associated with the relationship, and which allow the designation of a specific relationship (among the possibly many in which a given object may participate) by the values of its (key) attributes.

An OMS relationship is binary and can be seen as a pair of two unidirectional links where the origin of one is the destination of the other and vice-versa. The

principal means of accessing objects in most OMS operations is to navigate the OMS object space by traversing a sequence of links designated by a string value type pathname.

This selection in navigation mode is efficient, which is very important as it is the unique access mechanism used by every tool. Another important characteristic is that this navigation mode allows upwards compatibility from Unix, and thus a smooth transition path from Unix to PCTE, which is another of the design goals.

Objects, relationships and attributes have types which define their properties. Object types may be linked together by subtyping relationships. The object base structure and its integrity constraints are represented by a set of type definitions for objects, attributes and links. This set of definitions is the object base schema, and the OMS model includes the definition of schema definition subsets (SDS), for instance by the grouping of all the definitions related to a given project.

At any time, a process operates with a set of definitions that constitute its working schema, which is an application of the external model of the ANSI/ SPARC report e. The working schema is established for a process as the well-formed composition of a set of SDS and can be dynamically reestablished so as to change the working context of a process. A working schema corresponds to a description of certain constraints on the properties of a collection of objects and of relationships which are operated by a given process. A working schema can thus reflect the specificities of a given tool when applied to the objects and relationships specific to a given user. Various users, user groups, and tools can access the same objects, but can only see the information which is relevant to them. Furthermore, the object base structure used by a tool or a set of tools may be described in a serparate schema definition. To integrate such a tool into a PCTE based environment, it is necessary to add this description to the global schema of the environment.

The OMS data model, although derived from the E-R model, differs however by the inclusion of a number of functionalities which are required by software engineering information bases.

First, traditional database management systems are well suited to structured data manipulation, which is also an objective for the OMS, but they are generally very limited in their ability to handle large quantities of data, of whose structure they are unaware. Text files, graphical respresentations, and executable binary code are important examples of nongenerally structured data. The ability to handle data not to be interpreted is provided by the OMS through its concept of object contents.

Second, the project administrator must be able to organize his or her own project environment without necessarily any reference to a unique object base administrator. This feature is necessary to enable the definition of extensions to the schema describing such environments. The resulting dynamic evolution of the

vol 30 no 4 may 1988 213

information base schema during its use is a particular feature of the PCTE OMS.

Third, in a software engineering information base, integrity contraints, such as reference integrity (control of the existence of the referenced objects) or stability constraints may be specified on the relationship types in the OMS model.

Fourth, the ability to support the storage of multiple versions of objects is also an important feature and the mechanisms provided must be general enough to support various organization models. The OMS itself does not provide version management mechanisms, but offers basic facilities that can be used by tool developers to implement specialized configuration management systems.

Use of OMS

As it is possible to define data types by use of primitives, data definition tools can be implemented based on forms and on some data definition language (DDL).

In a similar manner, any program can access the object base directly by using the data handling primitives. This makes possible the implementation of various query tools, which may be called by any user or program.

A software engineering environment must provide mechanisms for concurrent access control and for recovery which are well adapted to object base management.

Data access synchronization and recovery mechanisms are provided in PCTE by adapting the well known notion of transaction to the context of software engineering environments. In a general sense, a transaction can be regarded as a workframe in which individual operations take place. A transaction can be defined to have certain properties, namely:

• atomicity: it is guaranteed that, at the end of a transaction, either the object base is in a state corresponding to all the required modifications, or it remains as if the transaction had never started,

• serializibility: it is guaranteed that several concurrent transactions produce the same result as the sequential execution of the same transactions.

Some tools have their own error recovery. For this reason, the concept of a transaction has been generalized to the concept of an activity which permits a choice of different levels of integrity, which in their turn allow the tool writer to tune the mechanisms to the desired level of data consistency and concurrency control, ranging from unprotected behaviour to proper, fully protected atomic and serializable transactions.

An important aspect of PCTE functionalities is the modularity of tools, which allows for tool composition: the ability to construct new tools by reusing tool modules which exercise well defined actions, preferably in an atomic way. A new tool may be constructed in this way from elementary tools; this new tool may be itself

incorporated in a more powerful tool, at a higher level of tool composition.

In an ideal situation, any tool should be seen as a primitive. For a tool, a failure can be interpreted, or note, as a failure of the tool which has invoked it. A natural solution is to provide for nested activities, in a similar way to block structure nesting in programming languages.

In such a model, modifying the object base inside a transaction is effective only when all the encapsulating transactions are successful.

Distribution

It is important to realize that the development of a large or complex piece of software results above all from teamwork. This has to be reflected in the environment, which needs to be an environment for a project, and not only for individuals. The various user stations must therefore be connected physically so that a user working on one station can access information located on, or communicate with, other stations. They must also be connected logically so as to treat a user as an actor in a larger context, rather than as an individual who interacts with other individuals.

The architectural support can thus be seen as consisting of a set of user stations connected through a high-bandwidth network and sharing common physical and logical resources such as printers, discs, communication channels or specialized processors. The software architecture should however preserve the visibility of a unique set of resources accessible to everyone. In other terms, we should have a single system, whose resources are distributed in a transparent manner among the various physical components, and not a number of individual systems that have to communicate explicitly. This insistency on the transparency of the distribution is seen as fundamental.

As already indicated above, the PCTE preferred architecture is a network of powerful workstations and associated resources. In this environment, project teams and users have to share software, data, and peripherals. This whole architecture must be seen by the users as a single machine, and yet each machine can act as an autonomous unit.

The hardware architecture of a PCTE based environment is thus a set of user stations connected through a LAN. A workstation is equipped with one or several disc units which support fixed or removable volumes, and each object is allocated to a given volume. A volume is in fact a physical collection of objects, which may be implemented as part or the whole of a physical disc. In this way, the object base is distributed on the various workstations, all of which are potential object servers.

An individual user station may be one of these powerful workstations with its own backing store, or a discless station needing to access all its used volumes over the network, or indeed in a degraded way it may be a more traditional terminal connected to one of the workstations.


Accessing any object is achieved by following a logical path, which depends on the volumes supporting the various objects and not on the workstations where these volumes are said to be mounted. The object base is thus distributed in a transparent way for the user. Access to the remote volumes is one of the tasks of the distribution management of PCTE.

All stations in the environment must have equal rights. Successful operation of the distribution mechanism has not to depend upon any hierarchy, fixed or configurable, of the stations of the underlying LAN. Nor is the ability of a process to make a request of a remote station altered or diminished by changes in the LAN topology.

The distribution mechanism has to provide:

• transparent distribution of the functions of the OMS, process execution, process structure and interprocess communication,

• network administration, i.e. control management of the communication over the LAN, with supervision of the connected stations,

• distribution management, i.e. control and configuration of the distribution mechanism itself, including station connection and disconnection protocols.

The required uniformity and mutual independence of the network topology is achieved by the assignment to the stations of unique host identifiers which are fixed and independent of the station's (possibly changing) network address.

To facilitate the management of such an environment, all entities which may reside anywhere in a PCTE based environment are given a unique identifier. A process is characterized by its data and a collection of information constituting its execution context. A process is not an OMS object. Processes may not migrate from the station on which they are created. However, processes may create children on other stations, either deliberately (by explicitly quoting the desired host identifer) or as a result of features of the child itself, such as its specific hardware requirements.

The transparency provided by distribution means that processes need not be aware of the location of the objects they refer to. The same system call is used for both local and remote object reference. Thus, the distribution mechanism shields the process from being dependent upon topological considerations.

Any OMS volume may be mounted, hardware permitting, anywhere in the PCTE system to which it belongs. Immediately it is mounted, the objects on the volume become visible throughout the PCTE based environment in question. Distribution uses in-kernel replicated tables of mounted volumes to enable transparent navigation along links which cross volumes (and therefore possibly workstations).

As a process structure becomes distributed so may its means of interprocess communication. Message queues and pipe files which figure in the object base can be used remotely in a transparent way from the process viewpoint. The same is true of the Unix anonymous

pipes, which are however always created locally with respect to the process asking for their creation. Similarly, the processes having system-wide identities inside a given PCTE based environment, the sending of signals to processes is also fully distributed in the same transparent manner. A process using one of these entities is never aware of the location (local or remote) of the resource itself, nor of any of the other processes using it. (In practice, the only way to create distributed anonymous pipes is implicitly, as a side-effect of the distribution of a family of processes).

Each station is represented by an object in the object base, and is identified by its host identity. This identifier is assigned when the station is initially created. All PCTE system calls that circumvent the transparency of the distributed system make explicit use of the host identity.

The distribution mechanism has to manage the static topology of stations and during a session it manages the connection and disconnection of stations from the PCTE based environment.

User interface

Since the arrival of advanced user stations offering a high-resolution bitmap display and a pointing device such as a mouse, user interface design and the whole concept of man-machine interaction have undergone a radical change. It has been recognized that traditional systems were too inflexible and put great demands on the user's ability to adapt to the interaction method. Nowadays there is far more emphasis on systems which can be adapted to user requirements. Modern systems exploit multiprocessing environments by allowing the user to interact with several tools concurrently. This is generally achieved by using windows.

In recent years, a number of windowing systems have been developed and marketed. They have quite varied philosophies about user interaction and tend to offer tools which have been written for specific machines, leading to ever increasing problems of tool portability.

One of the major objectives of PCTE therefore is to provide a user interface (UI) which takes the recent technical developments into consideration, but placing emphasis on the portability of tools. In a software engineering environment the UI has to provide a basic set of functionalities for the development of new tools; it is all the more useful to be able to achieve this while ensuring that many existing tools are still supported.

Another problem of user interaction has always been the inconsistency in meaning of various instructions in different contexts or modes, particularly when editing. In an attempt to provide a more uniform interaction method, the entities within the UI are, as far as possible, handled in the same way: i.e. there is a standard set of operations. This technique is known as the object-oriented method, whereby object is a general term for any element (or group of elements) which can be made visible on the screen, whether it be a window, character, string of characters, graphical

vo130 no 4 may 1988 215

element, etc. (Of course, this is not the same meaning of the word object as that used to describe above the software engineering objects managed in the object base). The method consists of two steps. First, selecting the object and second, performing an operation (command) on the object. Such operations are called generic commands, since the same command can be applied to different types of objects, e.g. move or delete. The system determines how the command is to be interpreted, depending on the context in which it is used. In this way a mechanism for basic editing operations is part of the UI itself.

In PCTE, the overlapping method has been chosen, rather than the tiling method for windowing, in the belief that the real power of such systems lies in the ability to bury and retrieve windows, i.e. by popping partly obscured windows to the front of the screen (so that they are completely visible). This allows all running tools to make optimum use of screen space.

Although windows are each conceived as emulating a conventional terminal, they are not an output medium as such. As their name perhaps suggests, windows are simply structures through which a section of information may be viewed. This information is stored in a data structure called a frame. A window is linked to a frame via an intermediate structure called a viewport which defines that part of a frame which is to be displayed in the window. In this way it is possible, for example, to maintain a record of interactive dialogues with the system during a working session - information need not be lost once it has been scrolled out of the top of a window.

A method is provided to display complex images, containing a mixture of textual and graphical information, in a single window. A number of viewports are grouped together in a tree hierarchy and, although each viewport defines a section of a different frame, all the frame sections appear to the user as belonging to the same window.

Windows are used as the medium through which tools are provided with user input. Since several tools may be running at any given time, it is essential that input is received by the appropriate tool. The user ensures this by designating a particular window to be the current (otherwise known as the listening) window. In this way, all tools may output concurrently, yet only one tool receives user input.

Many systems often required the user to remember quite large sets of command instructions. At best the system could be prompted for a list of available commands, but afterwards the command still had to be entered explicitly. To facilitate command entry for users, some systems developed the concept of using a menu based approach. The PCTE UI provides two types of menu: static and pop-up, which can be incorporated in new tools. Static menus are displayed continually and are generally used to display tool options which are always available to the user. Pop-up menus, on the other hand, are displyed on the screen

when a specified button or key is pressed and disappear once the choice (maybe none) has been made. Pop-up menus are useful for those tools offering different sets of available options to the user according to the working context. The user does not then have to remember which options are available in which contexts.

Basic editing is concerned with the manipulation of objects on the screen. So as to provide a powerful set of facilities, the UI allows editing operations not only within a window, but also between windows, including between different tools. Such an operation could, for example, be the copying or moving of text from one window to another. In this way, the output from one tool may be selected in one window and used as the input for another tool in a different window. Naturally, only meaningful operations of this type are supported.

The PCTE UI itself is about providing a portability level which is readily implementable on different workstations. The Emeraude PCTE implementation will, in 1988, be providing its portability level interface on an implementation using X-Windows. Above this level, most tools need to be able to use higher level common features in order to achieve a harmonious, tool-user dialogue and at the same time profit from a greater degree of commonality and factorisation of features. The Emeraude PCTE provides a standard virtual teminal as it ensures Unix tty compatibility for existing tools; this dialogue manager is of course implemented using the underlying PCTE UI, but provides additional facilities enabling the construction of homogeneous house styles for tool-user dialogue, including the ability to encapsulate existing Unix tools so that they can provide the end user with menus and form-based command and parameter entry, and display mechanisms which include text and graphics.

In the context of the PACT common services, the Emeraude product will also be offering a complete dialogue management common service. Therefore, in terms of dialogue, the Emeraude PCTE product provides complete support to exploit in a systematic way the facilities offered by modern, advanced workstations. It contains in particular a tool independent screen management system providing multiple, independently active windows, virtual terminal handling, generalized interwindow editing facilities, and menu management. The general purpose functions can be augmented by application specific guidance.

From the user's point of view, a large uniformity between the various tools is highly desirable. The various tools should use the same form of interfaces, command languages and online assistance facilities. The tool developers have the means to fit their tools easily into the mould so defined. From the IPSE architect's point of view, it is possible to canalize the dialogue between tools and end users, by preparing standard menus and forms to be used usually, and by controlling that those menus and forms which are stored in the object base respect any house-style rules.


Conclusion Bibliography

There is now widespread acceptance of PCTE in Europe: a number of software houses are basing their product policy on PCTE and a number of national or international projects are relying on the PCTE interfaces.

The Emeraude product implements PCTE and provides a commercially available basis on which to construct PCTE based IPSE. Such IPSE are indeed soon becoming available, in particular PACT implemented on Emeraude will be available in 1988.

References

1 Chen, P 'The entity relationship model: towards a unified view of data' A CM Trans. Database Syst. Vol 1 No 1 (March 1976)

2 ANSI SPARC Study Group on database management systems Interim Report FDT Bulletin of ACM SIGMOD Vol 7 No 2 (1975)

Clement, J L and Leygues, F 'Interface Utilisateur Multifenetre Emeraude' Acres de la Convention Unix '87 Paris

'Emeraude Standard Virtual Terminals' Functional specifications release 1.4 GIE Emeraude (June 1987)

PACT General description, Bull, Eurosoft, GEC Software, ICL, Olivetti, Syseca, Systems & Manage- ment (1986)

PCTE Functional Specifications, Bull, GEC, ICL, Olivetti, Nixdorf, Siemens (June 1986)

PCTE presentation at Palo Alto Conference of December 1986, SIGplan (January 1987)

Zimmermann, H, Guillemont, M, Morisset, G and Banino, J S 'Chorus: a communication and processing architecture for distributed systems' INRIA Research Report 328 (1984) [ ]

vo130 no 4 may 1988 217

emeraude portable common tool environment

Documents