- Email: [email protected]
PCTE — The kernel of software engineering environments
North-Holland Microprocessing and Microprogramming 24 (1988) 161-166
161
PCTE - THE KERNEL OF SOFTWARE ENGINEERING ENVIRONMENTS
Malcolm VERRALL Software Technology Group, CAP Industry Ltd, 143-149 Farringdon Road, London ECIR 3AD, UK
The tools within a Software Engineering Environment should be built around a kernel, the power of which exceeds a conventional operating system. PCTE is a major development of such a kernel. The history and current status of PCTE is described first. There then follows a discussion of the scope of PCTE's coverage. After this is a description of the facilities provided by PCTE to the tools running on it. Finally there is an explanation of one of the major models used in providing these facilities.
1. INTRODUCTION A software product has a value and a cost of production. The purpose of advances in software production are to increase the ratio of value~cost. According to good engineering principles this is achieved by the use of method in the production of software: thereby raising the quality of the final product and lowering the amount of resources consumed by production. The effectiveness and efficiency of the methods are increased by automation, thus further increasing the ratio. These automated tools should not be considered in isolation but as part of a system (known as an environment) for the production of software, thus we require automated systems to support the production of software - Software Engineering Environments, SEEs. As well as benefiting from the presence of other tools in the SEE, tool writers should benefit from the very essence of the SEE itself. This essence is made explicit in the notion of a kernel; such a kernel has power exceeding that of a conventional operating system in both type and magnitude, and forms the underlying philosophy of many SEEs. PCTE, a basis for a Portable Common Tool Environment, is a potential standard for the kernel of SEEs, defining both the function and interface of the kernel. The specification of PCTE is publicly available, several prototypes have been written and a number of industrial quality implementations exist and more are being created; thus, PCTE is now ready for promulgation to and use by the global software engineering community. 1.1. Chronological Perspective The ideas contributing to the development of PCTE came from a number of sources: ALPAGE [1], a study for an environment conducted by Bull for the French government; M_Chapse, a study for a Minimal Chill and Ada Programming Support Environment, undertaken by a government and industry consortium in the UK; PAPS [2], a design and prototype implementation for a Portable Ada Programming System developed by a European consortium; CAIS 13], a specification of an Ada programming support environment interface standard - the Common APSE Interface Set, produced by a working party from the Department of Defense, industry and academia in the USA; and the UNIX operating system [4].
PCTE was developed by a project in the European Strategic Programme for Research and Development in Information Technology, ESPRIT, which is a long-term programme supported by the European Economic Community. The need for a standard tool environment was realised by the directorate of ESPRIT and thus a project to design and implement a tool interface was launched at the beginning of ESPRIT [5]. This project has produced the specification of the function of PCTE and the C binding of its interface as well as a number of prototypes running on various computers including Bull SPST, Olivetti 3B2, ICL Perq and Sun Workstation. A separate project has produced a specification of the Ada binding of the PCTE interface [6]. The latest version (1.4) of the PCTE specification [7] has been released from the project and charge of it passed to a body independent of the project, the PCTE Interface Management Board, PIMB, supported by the Commission of the European Communities. A French consortium, supported by the French government, has produced an industrial quality implementation of PCTE, known as Emeraude [8], initially running on Bull SPS7s. An ESPRIT project, Sapphire [9,10], in which the author's organisation participates, has ported Emeraude to the IBM PCJAT, Sun-2 and Sun-3 and is porting it to the HP9000 series 300 and VAX/Ultrix. Another ESPRIT project, PAVE, is producing a separate PCTE implementation on VAX/VMS. A further ESPRIT project, VIP, is producing a formal speeifieatiou of PCTE in VDM. A number of advances are also taking place in the evaluation and use of PCI'E. "llle Sapphire project is converting three major existing software tools (a Minimal IPSE, a software engineers' documentation support system and an Ada compiler) to PCTE and comparing PCTE with CAIS. An ESPRIT project, PACT, is implementing a number of new and existing tools on PCTE to make a basic SEE. Another ESPRIT project, SFINX [11], in which the author's organisation participates, has amongst its various concerns experimentation with SEEs made from the integration of ESPRIT tools on PCTE and promotion of PCTE [12,131.
162
M. Verrafl / PCTE - The Kernel o f Software Engineering Environments
2. SCOPE The organisational and technical worlds in which PCTE exists, and the needs which these worlds have, delimit PCTE; these worlds and their needs are discussed here. PCTE serves both tool writers and users on a wide variety of projects, in the first place the diversity of projects in the whole decade of the ESPRIT programme and in the second industrial projects. It provides support for tools that will cover the entire software development life-cycle and for many languages - not only of programming, but also of other elements of software development, for instance, project planning, specification and design - and their use on a single project. It permits the movement of projects between hardware and operating systems, thus allowing the evolution of a product to continue even though its development host has become obsolete; and it allows the movement of tools between organisations, projects and personnel thus fostering the dissemination and exchange of software concepts and technology. PCTE is an important step along the road towards standardisation of SEE kernels and is becoming widely accepted. There are a number of requirements for the kernel of an SEE, the most fundamental of the strategic requirements is that it should supply more support for tools than is currently available. That is, more work should be done by the kernel in supplying more powerful mechanisms for use by the tool; this reduces the cost of development of the tool and raises its quality. This support should not only be for the type of tools cun'ently available but should also look forward to more advanced tools. A second strategic requirement is that there is an evolutionary path from the existing state of development of SEEs, most readily obvious as upward compatibility from existing operating systems Io PCTE; but, it is important that this compatibility is achieved without PC-WE being in any way tied to any one operating system. Thus existing tools will be able to mn within a PCTE based SEE but without necessarily receiving all the benefits of doing so, though they will be to some degree enhanced, for instance by transparent access to remote data. Requirements of a more tactical nature are openness, user interface improvement, execution mechanisms and support for transient and persistent data. Openness requires that the SEE allows the addition of tools other than those out of which it was built. The user interface will be improved by use of modern techniques, such as the Window Icon Menu Pointer, WIMP, model, and by homogenisation of the user interface of different tools. Execution mechanisms and support for transient data allow the interoperation of tools, which contributes to their integration by function, a value-adding aim of an SEE. There are three aspects to support for persistent data: data sharing, which allows different tools to use the same data; data structuring, which allows the structures of persistent data to be made explicit and independent of tools thus decreasing individual tools' data dependence; and data integrity, which maintains the completeness and consistency of persistent data. Conformance and compatibility are PCTE goals, conformance is with applicable ISO standards, compatibility has been chosen to be in an upward sense with the UNIX operating system, but without making PCTE irrevocably linked to UNIX. Compatibility with tools operating under the host's operating system,
though not a goal, is desirable. The purpose of upward compatibility is to preserve the value of effort expended so far in developing tools and is ensured by the legality of UNIX system calls and pathnames in PCTE, thus making these tools compatible with PCTE at the binary code level. Implementations may choose to allow the operation of tools under the native operating system at the same time as PCTE tools and the integration of the two sets of tools by the exchange of data between them and the availability to PCTE tools of data stored by the native filing system. Ease of use is a laudable and oft-quoted aim for software; it is made manifest in PCTE in three ways. Firstly, there is a small number of powerful, separable conceptual models for the user to understand; these are principally the entity-relationship data model, schemas, process and transactions, and windowing virtual terminals. Secondly, the specification is partitioned such that each part may be understood largely in isolation. Thirdly, the primitives interfacing to the kernel are treated uniformly. The nature of development systems becoming available is driven by the increased demand for development power and is that of host-target systems where the host is a heterogeneous network of workstations sharing physical resources and information resources. The network is a Local Area Network, LAN; each individual workstation is a "3M" machine: a mip or more of cpu power, megabytes of slorage and a high-resolution screen with about a million pixels. The kernel interface primitives should seek a good compromise between accomplishing only one function apiece and being powerful and useful. Where a UNIX system call performs the desired function the PCTE primitive is based on it. All primilives can be called from programming languages, currently C and Ada, and are thus able to be built on by use of the language. Compatibility and ease of use through uniformity is achieved by using the UNIX style for signals and the primifives' parameters and returned value; the returned value is implementation independent. Any specification should be as complete and unambiguous as the specification language permits; work going on to specify PCTE formally, using VDM, will remedy any lack of precision resulting from the current informal language. The kernel should be specified in terms which are independent of both machine and implementation and furthermore should be structured to aid comprehension. For PCTE this structuring is done hy partitioning into sections dealing with the major concepts which are mostly independent of one another, though the fact that PCTE is a distributed system and that it has a central data model is a recurring theme. It must be possible to implement the kernel on a variety of hardware and operating systems, to permit the operation of unchanged UNIX tools and to have an acceptable performance; satisfying these objectives collectively requires balanced, engineered implementations. To allow a more rapid implementation and acceptance of PCTE its first implementations are based on UNIX and VMS. PCTE is well founded in that its design, specification and implementation can be shown to satisfy the above needs.
M. Verrall / PCTE - The Kernel o f Software Engineering Environments
3. FACILITIES This section describes the functionality supplied by PCTE to tools running on it. This explanation of PC'rE is partitioned into four parts: distribution, user interface, data store, processes. The US working party which produced CAIS also produced a requirements document for a CAIS called DoD Requirements and Design Criteria for the Common Ada Programming Support Environment Interface Set and known as the RAC. The report [14] on the conformance of PCTE to the RAC includes sections on entity management and program execution which have provided the framework for the sections in this paper on P C r E ' s data store and processes functionality. 3.1. Distribution The most important point about distribution is that it is invisible to the tool, a PCTE installation is seen as a whole. The persistent data store is seen as a single, complete whole without knowing which secondary memory any part of it lies on; transient data can be passed between processes without them having to be aware of their locations within the network. Nevertheless, PCTE also allows a tool to specifically locate persistent data and processes at particular places within the network. The kernel allows administration of the network of workstations, for instance, the connection of individual workstations to the network. The distribution functionality of the kernel is not affected by the topology of the network at any time; there is no dependence on a ranking of workstations on the LAN.
163
visible on the screen can be smaller than the apparent terminal as seen by the tool, and the visible area can be moved over the whole apparent terminal. An individual apparent terminal can display a mixture of pixel, graphic or text entities simultaneously; the font for display of text can be chosen. Input can be captured from alphanumeric keys, function keys, mouse position or mouse buttons and can be directed by the end user to any apparent terminal which the tool permits. The input can be reported to the tool at one of two levels: physical or logical. At the physical level it is reported to the tool in terms of the mouse or the keyboard. At the logical level it is reported to the tool in terms of requests for tool to perform actions upon the apparent terminal, having been translated by the kernel from physical actions specific to the implementation of the kernel. Combined output and input facilities are offered in two ways: options and delegation. There is a specialised apparent terminal component for displaying a list of options and capturing the end user's selection from that list. The process can delegate the work of responding to a logical level input, typically manipulation of an apparent terminal's appearance, to the kernel, thus saving on the effort of having to do the work itself. There are two storage facilities provided, one for components of apparent terminals and one for the individual units of display within them. An apparent terminal can be saved in the data store and restored later. References to units of display can be written to and read from a buffer belonging to the workstation; one use for this facility is to exchange them between different apparent terminals of the same and different tools.
3.2. User Interface
3.3. Data Store
The user interface part of PCTE lies between the body of the tool and the physical terminal. On the outside is the physical appearance of output from the tool on the window and the physical actions which generate input to the tool, at the moment PCTE regards the specification of these as an implementation decision and quite deliberately says nothing about them. On the inside are the facilities and information provided to the body of the tool, which are described below.
Software engineering tools are concerned with the capture, manipulation and display of the information used in the process of software development. This information must be retained and thus the existence and accessibility of a central data store is vital to an SEE.
A tool communicates with the physical terminal by means of apparent terminals of a complex, arboreal structure. An apparent terminal appears to the tool as an actual physical terminal, whereas it is not; it is mapped onto the physical terminal by PCTE. The tool can manipulate the structure and content of the apparent terminal. It can have a number of these apparent terminals all independent of one another and of the apparent terminals belonging to other tools. The behaviour of the apparent terminals on the screen is that of sheets of paper on the top of a desk which overlap one another and can be taken out from underneath and put on top, and vice versa, both as individual sheets and collections of sheets; they can also be wriuen on. Output facilities are provided for the apparent terminals as a whole and for their content. The appearance, such as size and position, of the apparent terminals can be manipulated both individually and in groups. The area of the apparent terminal
The entity management part of the RAC is based on the Entity-Relationship concept [15] which separates information into entities, representing the existence of things, relationships joining entities together and properties Of entities or relationships. The Entity-Relationship concept also divides entities and relationships into classes of like entities and relationships. The data store part of PCTE is likewise developed from the EntityRelationship concept, so the facilities described below can be seen to map straightforwardly onto the PCTE model later in this paper. In the world of Software Engineering entities may be many things; a representative list would include workstations, volumes, devices, personnel, jobs of work, documents and programs; a great strength of PCTE is that it manages these uniformly. PCTE retains, manipulates, polices and describes data. In retaining data, its properties and relationships, PCTE provides facilities for representing data using the entities, properties and binary relationships of an Entity-Relationship model.
164
IV/. Verra/I / PCTE - The Kernel o f Software Engineering Environments
When manipulating data PCTE can identify, create, delete, examine and modify entities and relationships and examine and modify their properties. Properties can contain either data known as interpreted data whose value is manipulated by data store facilities or data known as uninterpreted data whose value is not manipulated by data store facilities. Some types of uninterpreted data are in fact accessed by input/output functions and thus correlate with the UNIX byte stream model. Identification of an entity or relationship is achieved by using the structure of the data store. A previously known entity and a list of relationship types are given, following a path starting from the known entity and proceeding through relationships of the given types leads to the identified entity or relationship. This differs from the original Entity-Relationship model which identifies entities and relationships by class and key attributes. A particular and necessary ability is to be able to track down an entity wherever it may be moved to in a distributed system. To police data, PCTE can define and enforce the legality of operations on data and ensure the integrity of the data store. It provides synchronisation of access to individual entities, relationships and attributes and access control to entities by extending the UNIX model of ownership and access type. It provides a transaction mechanism with the facilities to start, end and abort transactions. Data description is based on typing of all entities and relationships. PCTE has predefined entity types and can define new entity types in a tree from them, inheriting relationships and attributes; it can also define relationship types. Both entity and relationship type definitions can be changed. The definitions correlate entity types with relationship types and both with attribute types. They allow multiple, distinct relationships between the same entities. 3.4. Processes The basic concept here is that a process is a program which is executing. The facilities supplied are thus concerned with the execution of programs, the passing of transient data between processes, input/output and local workstation administration. The current state of the technology, the UNIX model, was taken to be acceptable and so the facilities are only briefly enumerated. In PCTE one process activates a program stored as a data entity to make it a process. The activating process is called the parent, the activated process is called the child. The child process is not a data entity but has an identity. Processes can suspend., resume, complete, abort or be aborted. A parent and child can execute in series or in parallel; co-operating processes can synchronise by signals, messages, waits and locks. A parent can inspect and modify a child; upon completion the child can report to the parenL Transient data can be exchanged as in UNIX by signals, pipes and messages. Input/Output is by the UNIX byte stream model and is of the uninterpreted data of those data store entities equivalent to a UNIX pipe, file, character device or block device.
4. M O D E L One of the major models in PCTE is described in this section: that of the Object Mangement System used for the data store. 4.1. Object M a n a g e m e n t System The PCTE model for persistent data is a directed graph. The vertices of this graph are called objects and correspond directly to entities in the Entity-Relationship model. The directed arcs of this graph are called links and can compose the binary relationships in the Entity-Relationship model; however, they differ in that they can be traversed in only one direction whereas relationships can be traversed in either direction. Both objects and links have attributes, corresponding to properties in the EntityRelationship model; in the case of some objects there is a special attribute called content, containing uninterpreted data, whose value is not part of the data model. The division of entities and relationships into classes is implemented by PCTE's typing of objects and links. The part of the kernel which handles persistent data according to this model is known as the Object Mangement System, OMS [16]. 4.1.1. Definition of Data Object types form a single hierarchy, starting from one predefined root type, in which an object inherits the links and attributes of its parent. An object type is given in full by its name, the type of its parent, the attribute types which apply to this object type, and two sets of link types - those leading from it and those leading to it. There are a number of predefined types subsidiary to the root type including file, character device, pipe and message queue, which exist to unify a number of facilities with the data model. Link types are defined independently of one another. A link type is given in full by its name, the attributes which apply to this link type, two sets of object types - those from which it can lead and those to which it can lead (a link instance will select one of each) and three particular properties: cardinality, category and stability. Cardinality determines whether one or many links of this type may lead from a single object; if cardinality is many then some of the attributes are designated keys in order to distinguish the different links of this type leading from a single object, these attributes are known as key attributes. Category can be reference, implicit or composition. If the category is reference the link simply points from one object to another. If the category is implicit the link can only exist as part of a relationship, not on its own; it may have a key but no other attributes, and the value of the key is set automatically by PCTE. If the category is composition then the creation and deletion of the object at the end of the link is tied to the creation and deletion of the link leading to it. Stability determines whether the object the link leads to may be deleted or updated while the link exists, according to the level of stability on the link. Relationships can be defined by pairing together two link types which are mutually inverse; that is, for each of the link types, the set of object types from which the link type leads is the same as the set of object types to which the other link type leads. The creation and deletion of each link in a relationship is
M. Verrall / PCTE
-
The Kernel of Software Engineering Environments
tied to the creation and deletion of the inverse link in the relationship, thus the relationship is automatically maintained. The type definitions are collected together by tool developers into useful groupings called Schema Definition Sets, SDSs, which are themselves held as objects. An SDS contains type definitions imported from other SDSs and new type definitions; there is a system SDS from which the definitions of the predcfined types are imported. Each process has its own view of the persistent data given by the list of SDSs available to it, these compose its Working Schema. Unlike conventional database management systems, PCTE does not have an overall schema and thus the addition of a new tool to the SEE can be easily accomplished as its new view can be added in the form of new SDSs.
Thus, as the investment in PCTE reaches a critical mass, it is in the interest of all members of the global software engineering community - whether they be suppliers or users of hardware, kernels, tools or environments to support, adopt and promote the Portable Common Tool Environment.
REFERENCF~ [1]
[21 [3]
4.1.2.
O p e r a t i o n s on data
An object or link is located using a start object, links and attributes combined into a pathname. The start object is either the root object or an object previously located and noted; from there a sequence of links lead to the desired object. Each link is identified by its typename and if of cardinality many by the values in the pathname equating with the values in its key attributes. PCTE provides a transaction model, in which either all or none of a sequence of changes are applied, to manage concurrent access and maintain consistency of the database. It allows the designation of a sequence of operations on objects and links as being associated in a single activity. Each activity has a class describing the degree of protection the activity requires, this class may be unprotected, protected or transaction. If the class is unprotected concurrent data accesses are permitted indiscriminately; if the class is protected concurrent data accesses are prohibited during each individual operation in this activity but are permitted between operations; if the class is transaction the accesses are treated as whole and only applied upon successful completion of the activity.
[4]
[51
[6]
[71
[8] [9] [10]
[11] 5. CONCLUSION [121 PCTE captures a long history of European experience in the area of Software Engineering Environments and consequently satisfies the needs for an SEE kernel and is suitable for the technology available to support one. Already, tools are being implemented on PCTE and SEEs are being constructed around it; in particular, a large number of projects from the AIvey (UK national), ESPRIT and EUREKA (Western European) programmes are developing their software engineering tools and environments on PCTE and their experiences are contributing to the spread and acceptance of PCTE. PCTE has a clear evolutionary future. The PCTE Interface Management Board will ensure the continued maintenance of PC'I'E, and the NATO Independent European Programme Group TA-13 is enhancing [17] the PCTE definition to incorporate further requirements in preparation for consideration as a NATO standard.
165
[13] [141 [15]
[16]
[17]
Roubine, O., Gart, M.B. and Minot, R., ALPAGE: A Software Engineering Environment for Large Scale Applications, in: proceedings of Compcon 83, San Francisco, February-March 1983. Olivetti, Portable Ada Programming System, Global Design Report (Olivetti, Pisa, 1982). Department of Defense, Common Ada Programming Support Environment (APSE) Interface Set (CAIS), Dt)D-STD-1838 (IJ.S. Department of Defense, 1986). Ritchie, D.M. and Thompson K., The UNIX TimeSharing System, Communications of the ACM (1974) vol. 7, July. Logica, ESPRIT Preparatory Study, Portable Common Tool Environment, Final Report (Commission of the European Communities, Brussels, 1983). Systems Designers and Mark V Business Systems, PCTE, A Basis for a Portable Common Tool Environment, Ada Functional Specifications (Commission of the European Communities, Bmssels, 1987). Bull, GEC, ICL, Nixdoff, Olivetti and Siemens, PCTE, A Basis for a Portable Common Tool Environment, Functional Specifications (Commission of the European Communities, Brussels, 1986). GIE Emeraude, Emeraude General Presentation (GIE Emeraude, Suresnes, 1986). Sapphire, Project Sapphire: PCTE Portability, project brochure (Sapphire, 1987). Tedd, M., The Sapphire Project: Building Confidence in PCTE, in: proceedings of ESPRIT '87, 4th Annual ESPRIT Conference, Brussels, September 1987 (Northttolland, Amsterdam, 1987). SFINX, Software Factory Integration and Experimentation, project brochure (SFINX, 1987). SFINX, A Comprehensive Introduction to the Portable Common Tool Environment (SFINX, 1988). SFINX, Introductory Course on PCTE Concepts (SFINX, 1987) V i d e o . Environment Working Group, PCTE Conformance to the RAC (Aria-Europe, 1986). Chen, P.P., The entity relationship model: towards a unified view of data. ACM Transactions on Database Systems, (1976) vol. 1, no. 1. Gallo, F., Minot, R. and Thomas, I., The Object Management System of PCTE as a Software Engineering Database Management System, in: proceedings of 2nd ACM SIGSOVI'/SIGPLAN Software Engineering Symposium on Practical Software Development Environments, Palo Alto, December 1986 (Association for Computing Machinery, New York, 1987) pp. 12-15. IEPG-TAI3, PCTE Evolution Programme, PCTE+ Definition Phase Work Programme (NATO, 1986).
161
PCTE - THE KERNEL OF SOFTWARE ENGINEERING ENVIRONMENTS
Malcolm VERRALL Software Technology Group, CAP Industry Ltd, 143-149 Farringdon Road, London ECIR 3AD, UK
The tools within a Software Engineering Environment should be built around a kernel, the power of which exceeds a conventional operating system. PCTE is a major development of such a kernel. The history and current status of PCTE is described first. There then follows a discussion of the scope of PCTE's coverage. After this is a description of the facilities provided by PCTE to the tools running on it. Finally there is an explanation of one of the major models used in providing these facilities.
1. INTRODUCTION A software product has a value and a cost of production. The purpose of advances in software production are to increase the ratio of value~cost. According to good engineering principles this is achieved by the use of method in the production of software: thereby raising the quality of the final product and lowering the amount of resources consumed by production. The effectiveness and efficiency of the methods are increased by automation, thus further increasing the ratio. These automated tools should not be considered in isolation but as part of a system (known as an environment) for the production of software, thus we require automated systems to support the production of software - Software Engineering Environments, SEEs. As well as benefiting from the presence of other tools in the SEE, tool writers should benefit from the very essence of the SEE itself. This essence is made explicit in the notion of a kernel; such a kernel has power exceeding that of a conventional operating system in both type and magnitude, and forms the underlying philosophy of many SEEs. PCTE, a basis for a Portable Common Tool Environment, is a potential standard for the kernel of SEEs, defining both the function and interface of the kernel. The specification of PCTE is publicly available, several prototypes have been written and a number of industrial quality implementations exist and more are being created; thus, PCTE is now ready for promulgation to and use by the global software engineering community. 1.1. Chronological Perspective The ideas contributing to the development of PCTE came from a number of sources: ALPAGE [1], a study for an environment conducted by Bull for the French government; M_Chapse, a study for a Minimal Chill and Ada Programming Support Environment, undertaken by a government and industry consortium in the UK; PAPS [2], a design and prototype implementation for a Portable Ada Programming System developed by a European consortium; CAIS 13], a specification of an Ada programming support environment interface standard - the Common APSE Interface Set, produced by a working party from the Department of Defense, industry and academia in the USA; and the UNIX operating system [4].
PCTE was developed by a project in the European Strategic Programme for Research and Development in Information Technology, ESPRIT, which is a long-term programme supported by the European Economic Community. The need for a standard tool environment was realised by the directorate of ESPRIT and thus a project to design and implement a tool interface was launched at the beginning of ESPRIT [5]. This project has produced the specification of the function of PCTE and the C binding of its interface as well as a number of prototypes running on various computers including Bull SPST, Olivetti 3B2, ICL Perq and Sun Workstation. A separate project has produced a specification of the Ada binding of the PCTE interface [6]. The latest version (1.4) of the PCTE specification [7] has been released from the project and charge of it passed to a body independent of the project, the PCTE Interface Management Board, PIMB, supported by the Commission of the European Communities. A French consortium, supported by the French government, has produced an industrial quality implementation of PCTE, known as Emeraude [8], initially running on Bull SPS7s. An ESPRIT project, Sapphire [9,10], in which the author's organisation participates, has ported Emeraude to the IBM PCJAT, Sun-2 and Sun-3 and is porting it to the HP9000 series 300 and VAX/Ultrix. Another ESPRIT project, PAVE, is producing a separate PCTE implementation on VAX/VMS. A further ESPRIT project, VIP, is producing a formal speeifieatiou of PCTE in VDM. A number of advances are also taking place in the evaluation and use of PCI'E. "llle Sapphire project is converting three major existing software tools (a Minimal IPSE, a software engineers' documentation support system and an Ada compiler) to PCTE and comparing PCTE with CAIS. An ESPRIT project, PACT, is implementing a number of new and existing tools on PCTE to make a basic SEE. Another ESPRIT project, SFINX [11], in which the author's organisation participates, has amongst its various concerns experimentation with SEEs made from the integration of ESPRIT tools on PCTE and promotion of PCTE [12,131.
162
M. Verrafl / PCTE - The Kernel o f Software Engineering Environments
2. SCOPE The organisational and technical worlds in which PCTE exists, and the needs which these worlds have, delimit PCTE; these worlds and their needs are discussed here. PCTE serves both tool writers and users on a wide variety of projects, in the first place the diversity of projects in the whole decade of the ESPRIT programme and in the second industrial projects. It provides support for tools that will cover the entire software development life-cycle and for many languages - not only of programming, but also of other elements of software development, for instance, project planning, specification and design - and their use on a single project. It permits the movement of projects between hardware and operating systems, thus allowing the evolution of a product to continue even though its development host has become obsolete; and it allows the movement of tools between organisations, projects and personnel thus fostering the dissemination and exchange of software concepts and technology. PCTE is an important step along the road towards standardisation of SEE kernels and is becoming widely accepted. There are a number of requirements for the kernel of an SEE, the most fundamental of the strategic requirements is that it should supply more support for tools than is currently available. That is, more work should be done by the kernel in supplying more powerful mechanisms for use by the tool; this reduces the cost of development of the tool and raises its quality. This support should not only be for the type of tools cun'ently available but should also look forward to more advanced tools. A second strategic requirement is that there is an evolutionary path from the existing state of development of SEEs, most readily obvious as upward compatibility from existing operating systems Io PCTE; but, it is important that this compatibility is achieved without PC-WE being in any way tied to any one operating system. Thus existing tools will be able to mn within a PCTE based SEE but without necessarily receiving all the benefits of doing so, though they will be to some degree enhanced, for instance by transparent access to remote data. Requirements of a more tactical nature are openness, user interface improvement, execution mechanisms and support for transient and persistent data. Openness requires that the SEE allows the addition of tools other than those out of which it was built. The user interface will be improved by use of modern techniques, such as the Window Icon Menu Pointer, WIMP, model, and by homogenisation of the user interface of different tools. Execution mechanisms and support for transient data allow the interoperation of tools, which contributes to their integration by function, a value-adding aim of an SEE. There are three aspects to support for persistent data: data sharing, which allows different tools to use the same data; data structuring, which allows the structures of persistent data to be made explicit and independent of tools thus decreasing individual tools' data dependence; and data integrity, which maintains the completeness and consistency of persistent data. Conformance and compatibility are PCTE goals, conformance is with applicable ISO standards, compatibility has been chosen to be in an upward sense with the UNIX operating system, but without making PCTE irrevocably linked to UNIX. Compatibility with tools operating under the host's operating system,
though not a goal, is desirable. The purpose of upward compatibility is to preserve the value of effort expended so far in developing tools and is ensured by the legality of UNIX system calls and pathnames in PCTE, thus making these tools compatible with PCTE at the binary code level. Implementations may choose to allow the operation of tools under the native operating system at the same time as PCTE tools and the integration of the two sets of tools by the exchange of data between them and the availability to PCTE tools of data stored by the native filing system. Ease of use is a laudable and oft-quoted aim for software; it is made manifest in PCTE in three ways. Firstly, there is a small number of powerful, separable conceptual models for the user to understand; these are principally the entity-relationship data model, schemas, process and transactions, and windowing virtual terminals. Secondly, the specification is partitioned such that each part may be understood largely in isolation. Thirdly, the primitives interfacing to the kernel are treated uniformly. The nature of development systems becoming available is driven by the increased demand for development power and is that of host-target systems where the host is a heterogeneous network of workstations sharing physical resources and information resources. The network is a Local Area Network, LAN; each individual workstation is a "3M" machine: a mip or more of cpu power, megabytes of slorage and a high-resolution screen with about a million pixels. The kernel interface primitives should seek a good compromise between accomplishing only one function apiece and being powerful and useful. Where a UNIX system call performs the desired function the PCTE primitive is based on it. All primilives can be called from programming languages, currently C and Ada, and are thus able to be built on by use of the language. Compatibility and ease of use through uniformity is achieved by using the UNIX style for signals and the primifives' parameters and returned value; the returned value is implementation independent. Any specification should be as complete and unambiguous as the specification language permits; work going on to specify PCTE formally, using VDM, will remedy any lack of precision resulting from the current informal language. The kernel should be specified in terms which are independent of both machine and implementation and furthermore should be structured to aid comprehension. For PCTE this structuring is done hy partitioning into sections dealing with the major concepts which are mostly independent of one another, though the fact that PCTE is a distributed system and that it has a central data model is a recurring theme. It must be possible to implement the kernel on a variety of hardware and operating systems, to permit the operation of unchanged UNIX tools and to have an acceptable performance; satisfying these objectives collectively requires balanced, engineered implementations. To allow a more rapid implementation and acceptance of PCTE its first implementations are based on UNIX and VMS. PCTE is well founded in that its design, specification and implementation can be shown to satisfy the above needs.
M. Verrall / PCTE - The Kernel o f Software Engineering Environments
3. FACILITIES This section describes the functionality supplied by PCTE to tools running on it. This explanation of PC'rE is partitioned into four parts: distribution, user interface, data store, processes. The US working party which produced CAIS also produced a requirements document for a CAIS called DoD Requirements and Design Criteria for the Common Ada Programming Support Environment Interface Set and known as the RAC. The report [14] on the conformance of PCTE to the RAC includes sections on entity management and program execution which have provided the framework for the sections in this paper on P C r E ' s data store and processes functionality. 3.1. Distribution The most important point about distribution is that it is invisible to the tool, a PCTE installation is seen as a whole. The persistent data store is seen as a single, complete whole without knowing which secondary memory any part of it lies on; transient data can be passed between processes without them having to be aware of their locations within the network. Nevertheless, PCTE also allows a tool to specifically locate persistent data and processes at particular places within the network. The kernel allows administration of the network of workstations, for instance, the connection of individual workstations to the network. The distribution functionality of the kernel is not affected by the topology of the network at any time; there is no dependence on a ranking of workstations on the LAN.
163
visible on the screen can be smaller than the apparent terminal as seen by the tool, and the visible area can be moved over the whole apparent terminal. An individual apparent terminal can display a mixture of pixel, graphic or text entities simultaneously; the font for display of text can be chosen. Input can be captured from alphanumeric keys, function keys, mouse position or mouse buttons and can be directed by the end user to any apparent terminal which the tool permits. The input can be reported to the tool at one of two levels: physical or logical. At the physical level it is reported to the tool in terms of the mouse or the keyboard. At the logical level it is reported to the tool in terms of requests for tool to perform actions upon the apparent terminal, having been translated by the kernel from physical actions specific to the implementation of the kernel. Combined output and input facilities are offered in two ways: options and delegation. There is a specialised apparent terminal component for displaying a list of options and capturing the end user's selection from that list. The process can delegate the work of responding to a logical level input, typically manipulation of an apparent terminal's appearance, to the kernel, thus saving on the effort of having to do the work itself. There are two storage facilities provided, one for components of apparent terminals and one for the individual units of display within them. An apparent terminal can be saved in the data store and restored later. References to units of display can be written to and read from a buffer belonging to the workstation; one use for this facility is to exchange them between different apparent terminals of the same and different tools.
3.2. User Interface
3.3. Data Store
The user interface part of PCTE lies between the body of the tool and the physical terminal. On the outside is the physical appearance of output from the tool on the window and the physical actions which generate input to the tool, at the moment PCTE regards the specification of these as an implementation decision and quite deliberately says nothing about them. On the inside are the facilities and information provided to the body of the tool, which are described below.
Software engineering tools are concerned with the capture, manipulation and display of the information used in the process of software development. This information must be retained and thus the existence and accessibility of a central data store is vital to an SEE.
A tool communicates with the physical terminal by means of apparent terminals of a complex, arboreal structure. An apparent terminal appears to the tool as an actual physical terminal, whereas it is not; it is mapped onto the physical terminal by PCTE. The tool can manipulate the structure and content of the apparent terminal. It can have a number of these apparent terminals all independent of one another and of the apparent terminals belonging to other tools. The behaviour of the apparent terminals on the screen is that of sheets of paper on the top of a desk which overlap one another and can be taken out from underneath and put on top, and vice versa, both as individual sheets and collections of sheets; they can also be wriuen on. Output facilities are provided for the apparent terminals as a whole and for their content. The appearance, such as size and position, of the apparent terminals can be manipulated both individually and in groups. The area of the apparent terminal
The entity management part of the RAC is based on the Entity-Relationship concept [15] which separates information into entities, representing the existence of things, relationships joining entities together and properties Of entities or relationships. The Entity-Relationship concept also divides entities and relationships into classes of like entities and relationships. The data store part of PCTE is likewise developed from the EntityRelationship concept, so the facilities described below can be seen to map straightforwardly onto the PCTE model later in this paper. In the world of Software Engineering entities may be many things; a representative list would include workstations, volumes, devices, personnel, jobs of work, documents and programs; a great strength of PCTE is that it manages these uniformly. PCTE retains, manipulates, polices and describes data. In retaining data, its properties and relationships, PCTE provides facilities for representing data using the entities, properties and binary relationships of an Entity-Relationship model.
164
IV/. Verra/I / PCTE - The Kernel o f Software Engineering Environments
When manipulating data PCTE can identify, create, delete, examine and modify entities and relationships and examine and modify their properties. Properties can contain either data known as interpreted data whose value is manipulated by data store facilities or data known as uninterpreted data whose value is not manipulated by data store facilities. Some types of uninterpreted data are in fact accessed by input/output functions and thus correlate with the UNIX byte stream model. Identification of an entity or relationship is achieved by using the structure of the data store. A previously known entity and a list of relationship types are given, following a path starting from the known entity and proceeding through relationships of the given types leads to the identified entity or relationship. This differs from the original Entity-Relationship model which identifies entities and relationships by class and key attributes. A particular and necessary ability is to be able to track down an entity wherever it may be moved to in a distributed system. To police data, PCTE can define and enforce the legality of operations on data and ensure the integrity of the data store. It provides synchronisation of access to individual entities, relationships and attributes and access control to entities by extending the UNIX model of ownership and access type. It provides a transaction mechanism with the facilities to start, end and abort transactions. Data description is based on typing of all entities and relationships. PCTE has predefined entity types and can define new entity types in a tree from them, inheriting relationships and attributes; it can also define relationship types. Both entity and relationship type definitions can be changed. The definitions correlate entity types with relationship types and both with attribute types. They allow multiple, distinct relationships between the same entities. 3.4. Processes The basic concept here is that a process is a program which is executing. The facilities supplied are thus concerned with the execution of programs, the passing of transient data between processes, input/output and local workstation administration. The current state of the technology, the UNIX model, was taken to be acceptable and so the facilities are only briefly enumerated. In PCTE one process activates a program stored as a data entity to make it a process. The activating process is called the parent, the activated process is called the child. The child process is not a data entity but has an identity. Processes can suspend., resume, complete, abort or be aborted. A parent and child can execute in series or in parallel; co-operating processes can synchronise by signals, messages, waits and locks. A parent can inspect and modify a child; upon completion the child can report to the parenL Transient data can be exchanged as in UNIX by signals, pipes and messages. Input/Output is by the UNIX byte stream model and is of the uninterpreted data of those data store entities equivalent to a UNIX pipe, file, character device or block device.
4. M O D E L One of the major models in PCTE is described in this section: that of the Object Mangement System used for the data store. 4.1. Object M a n a g e m e n t System The PCTE model for persistent data is a directed graph. The vertices of this graph are called objects and correspond directly to entities in the Entity-Relationship model. The directed arcs of this graph are called links and can compose the binary relationships in the Entity-Relationship model; however, they differ in that they can be traversed in only one direction whereas relationships can be traversed in either direction. Both objects and links have attributes, corresponding to properties in the EntityRelationship model; in the case of some objects there is a special attribute called content, containing uninterpreted data, whose value is not part of the data model. The division of entities and relationships into classes is implemented by PCTE's typing of objects and links. The part of the kernel which handles persistent data according to this model is known as the Object Mangement System, OMS [16]. 4.1.1. Definition of Data Object types form a single hierarchy, starting from one predefined root type, in which an object inherits the links and attributes of its parent. An object type is given in full by its name, the type of its parent, the attribute types which apply to this object type, and two sets of link types - those leading from it and those leading to it. There are a number of predefined types subsidiary to the root type including file, character device, pipe and message queue, which exist to unify a number of facilities with the data model. Link types are defined independently of one another. A link type is given in full by its name, the attributes which apply to this link type, two sets of object types - those from which it can lead and those to which it can lead (a link instance will select one of each) and three particular properties: cardinality, category and stability. Cardinality determines whether one or many links of this type may lead from a single object; if cardinality is many then some of the attributes are designated keys in order to distinguish the different links of this type leading from a single object, these attributes are known as key attributes. Category can be reference, implicit or composition. If the category is reference the link simply points from one object to another. If the category is implicit the link can only exist as part of a relationship, not on its own; it may have a key but no other attributes, and the value of the key is set automatically by PCTE. If the category is composition then the creation and deletion of the object at the end of the link is tied to the creation and deletion of the link leading to it. Stability determines whether the object the link leads to may be deleted or updated while the link exists, according to the level of stability on the link. Relationships can be defined by pairing together two link types which are mutually inverse; that is, for each of the link types, the set of object types from which the link type leads is the same as the set of object types to which the other link type leads. The creation and deletion of each link in a relationship is
M. Verrall / PCTE
-
The Kernel of Software Engineering Environments
tied to the creation and deletion of the inverse link in the relationship, thus the relationship is automatically maintained. The type definitions are collected together by tool developers into useful groupings called Schema Definition Sets, SDSs, which are themselves held as objects. An SDS contains type definitions imported from other SDSs and new type definitions; there is a system SDS from which the definitions of the predcfined types are imported. Each process has its own view of the persistent data given by the list of SDSs available to it, these compose its Working Schema. Unlike conventional database management systems, PCTE does not have an overall schema and thus the addition of a new tool to the SEE can be easily accomplished as its new view can be added in the form of new SDSs.
Thus, as the investment in PCTE reaches a critical mass, it is in the interest of all members of the global software engineering community - whether they be suppliers or users of hardware, kernels, tools or environments to support, adopt and promote the Portable Common Tool Environment.
REFERENCF~ [1]
[21 [3]
4.1.2.
O p e r a t i o n s on data
An object or link is located using a start object, links and attributes combined into a pathname. The start object is either the root object or an object previously located and noted; from there a sequence of links lead to the desired object. Each link is identified by its typename and if of cardinality many by the values in the pathname equating with the values in its key attributes. PCTE provides a transaction model, in which either all or none of a sequence of changes are applied, to manage concurrent access and maintain consistency of the database. It allows the designation of a sequence of operations on objects and links as being associated in a single activity. Each activity has a class describing the degree of protection the activity requires, this class may be unprotected, protected or transaction. If the class is unprotected concurrent data accesses are permitted indiscriminately; if the class is protected concurrent data accesses are prohibited during each individual operation in this activity but are permitted between operations; if the class is transaction the accesses are treated as whole and only applied upon successful completion of the activity.
[4]
[51
[6]
[71
[8] [9] [10]
[11] 5. CONCLUSION [121 PCTE captures a long history of European experience in the area of Software Engineering Environments and consequently satisfies the needs for an SEE kernel and is suitable for the technology available to support one. Already, tools are being implemented on PCTE and SEEs are being constructed around it; in particular, a large number of projects from the AIvey (UK national), ESPRIT and EUREKA (Western European) programmes are developing their software engineering tools and environments on PCTE and their experiences are contributing to the spread and acceptance of PCTE. PCTE has a clear evolutionary future. The PCTE Interface Management Board will ensure the continued maintenance of PC'I'E, and the NATO Independent European Programme Group TA-13 is enhancing [17] the PCTE definition to incorporate further requirements in preparation for consideration as a NATO standard.
165
[13] [141 [15]
[16]
[17]
Roubine, O., Gart, M.B. and Minot, R., ALPAGE: A Software Engineering Environment for Large Scale Applications, in: proceedings of Compcon 83, San Francisco, February-March 1983. Olivetti, Portable Ada Programming System, Global Design Report (Olivetti, Pisa, 1982). Department of Defense, Common Ada Programming Support Environment (APSE) Interface Set (CAIS), Dt)D-STD-1838 (IJ.S. Department of Defense, 1986). Ritchie, D.M. and Thompson K., The UNIX TimeSharing System, Communications of the ACM (1974) vol. 7, July. Logica, ESPRIT Preparatory Study, Portable Common Tool Environment, Final Report (Commission of the European Communities, Brussels, 1983). Systems Designers and Mark V Business Systems, PCTE, A Basis for a Portable Common Tool Environment, Ada Functional Specifications (Commission of the European Communities, Bmssels, 1987). Bull, GEC, ICL, Nixdoff, Olivetti and Siemens, PCTE, A Basis for a Portable Common Tool Environment, Functional Specifications (Commission of the European Communities, Brussels, 1986). GIE Emeraude, Emeraude General Presentation (GIE Emeraude, Suresnes, 1986). Sapphire, Project Sapphire: PCTE Portability, project brochure (Sapphire, 1987). Tedd, M., The Sapphire Project: Building Confidence in PCTE, in: proceedings of ESPRIT '87, 4th Annual ESPRIT Conference, Brussels, September 1987 (Northttolland, Amsterdam, 1987). SFINX, Software Factory Integration and Experimentation, project brochure (SFINX, 1987). SFINX, A Comprehensive Introduction to the Portable Common Tool Environment (SFINX, 1988). SFINX, Introductory Course on PCTE Concepts (SFINX, 1987) V i d e o . Environment Working Group, PCTE Conformance to the RAC (Aria-Europe, 1986). Chen, P.P., The entity relationship model: towards a unified view of data. ACM Transactions on Database Systems, (1976) vol. 1, no. 1. Gallo, F., Minot, R. and Thomas, I., The Object Management System of PCTE as a Software Engineering Database Management System, in: proceedings of 2nd ACM SIGSOVI'/SIGPLAN Software Engineering Symposium on Practical Software Development Environments, Palo Alto, December 1986 (Association for Computing Machinery, New York, 1987) pp. 12-15. IEPG-TAI3, PCTE Evolution Programme, PCTE+ Definition Phase Work Programme (NATO, 1986).