This paper tries to define and exampJify the concept of "integration" in the context of soflware development support environments. TIle benefits of tight integration are discussed, together with different approaches on how to achieve this properlY under the constraint of having to include existing software components and tools. The paper finally reports on the initial experience gained in building an Ada programming support environment according to those principles.
(3)
The cost of activating a service in tcnns of finding it and providing tile light parameters. The cost, in waiting time, for tile user while the computer is working.
The cost of finally"utilizing and assimilating the result of the service in tile context where the user needs it.
We call the sum of those costs the tl4rnaround time, and the purpose of our work is to minimize it.
Observe that we discuss not only the turnaround time of currenUy identified atomic ser vices, but Ule minimization of the cost for any typical pattern of work. For example, if the looking up of an imported interface is a common task, one could expect its turnaround time to be large in a traditional environment since it probably involves leaving an editor to go out in a file system, explicitly locating a file holding the interface, studying the interface and remember ing it, and then returning to the first point of editing without any oUler result than what could be memorized during the break.
Given the above view of the goal, it is clear Ulat imegratioll is a a key issue. The first and third components of the turnaround cost can obviously be very effectively attacked by util izing context information - making one tool explicitly utilize knowledge about the detailed state and context of the other tool. As will be described later, it also turns out that much less CPU cycles are consumed in a carefully built integrated system, making it effective in reducing even the second cost component.
Despite Um fact that integration is often mentioned as a highly desirable property of sup port environments, it still lacks a more precise cOlnmonly agreed on definition, and most publi cations never even try to be more explicit on the nature and meaning of the concept. However, as a concluding remark on the subject of integration, we propose the following:
In Ule context of software development environments, we discuss integration in terms of three characterizing properties of tools: IIIlijonllity, communicational ability, and openlless of representation. Each of UlOse are explained below together with examplcs.
Measures the degree to which different tools behave in a similar way in similar situations. This spans from reusing Ule same abstract concepts whcnever possible, to the unification of syntactical aspects of the user interface. The word external imegratioll has frequenUy been used to denote the latter part of this spectrum.
Examples: Use of Ule same command language and line editing conventions.
Use of the same conventions for managing windows and menues.
Use of the same user interaction style, such as pointing-at-object, iconization, parameter defaults, and command result reporting.
Use of the same editing, viewing, and searching tool for all texts.
Use of the same conceptual model for representation of data. In a Entity-Relationship Attribute based environment it would be natural to view most data in terms of typed, attributed, directed graphs. Other environments present other conceptual models, like strings, lists, and (mathematical) relations.
Use of similar operations on diffcrent data represented using the same model. Use of Ule same definitions of concepts; such as version, configuration, dependency, inheritance, relation, access privilege, transaction, icon, data key, Iype, etc. ( ( 1.1.2. Communicational ability.
Measures the degree to which a tool communicates its findings and actions to other tools, and the degree to which it provides means for other tools to initiate communication with it. This includes the temporal aspect of immediate notification, the selective aspect of communication with a particular '001, and the granularity aspect of communicating changed circumstances with high ptecision. .This may be achieved either by tools explicitly addressing each other, or by means of a "notify" mechanism provided by the object management system. It also includes the ability to (possibly dynamically) compose tools into larger aggregates.
Examples: The notification of a tool presenting a view of a database when the underlying data is changed.
The notification of the editor when the size of the window is changed.
Passing of context established in a browser, (pointing to a particular "current" object), to the editor or other more or less independent tools.
Immediate passing of result of an operation to a (set 01) tool.
Notification of the user, (or the tool he is currently using), when the mail program receives a message to that user.
Activation of, and passing of context to, the debugger when an exceptional condition occurs.
Communication from the editor to the compiler, or other processing tool, that the user changed a module, or with higher precision, a particular part of it.
Notification of involved users when the configuration management tool establishes a new version of an object for public use. 1.1.3. Openness of representation.
Measures the degree to which the data generated by one tool, or data otherwise in its domain, is made accessible for use by other tools.
The openness of representation provides for successive growth of the set of integrated tools. As new tools are 'built, or old tools are modified, the information utilization and availa bility will increase as a consequence of tool builders taking advantage of data defined by other tools this far.
Examples: The representation of data from the Pert chart tool in a form such that it can be used by the project tracking tool.
The representation of persOlmel, their abilities and availability, in a fonn such as it can be used by tile Pert chart project planning tool.
The representation of the language directed cditors internal working format in a way such tllat it can be used by the compiler, cross-referencer, data flow or complexity analyzer, etc.
The representation of tile Ada program library in a form such tlmt it can be used by tile configuration control tool, thc graphic browser, etc.
Representation of botll program code and documents in a form such that tlley can be related to each otller by means of a single mechanism. *
Representation of any tools data within Ule agreed upon datamodel, so that all tools and operations assuming that datamodel may be immediatelly applicable.
The total effort that seem to have been invested in attempting to build development environments over the last decade is impressing. Many of those projects have been highly cooperative, involving participants and tools from several countries and companies. This may have been especially true at the European scene, including projects within the ESPRIT pro gramme, such as PCTE/PACT, (pCfE 1986, PACT 1986, PACT 1988), and within the Eureka cooperation, such as ESF, (Fernstrom et ai, 1988), togeUler with national programmes in most countries. An example from Ule US is (Blumberg et a1 1988). A complete reference list over projects in tlJis area could in fact span'several pages, and several new ones are in an initial phase.
The creation of such an environment is however a major undertaking, comparable to the development of a new operating system, showing tlle same need for perfonnance and over all quality before the results could really be used. Consequently, there has been a hope that the environment could be built by putting togeUler existing tools, since developing Ulem again would not be feasible. This approach also builds on the strategy to benefit from a large market of existing software tools, and a desire to be equally open to every tool and teclmology.
On the otller hand, the whole idea of building an integrated system out of existing tools is an inherent paradox, at least if we are expected to accept tllOse tools as they are. If tlle benefits of integration are to be exploited, the illlegration must be quite tight, and utilize every chance of catching infonnation in one tool which might be of use in another place. Integration also seems to stand in conflict with tlle desire to be equally open to every tool, since very little can be achieved in tenn& of integration if not quite far reaching assumptions about involved tools are allowed.
To support the opinion one could obselve Ule international scene where few, if any, environment products of the first kind have evolved. Instead, tllere is an emerging set of what might be called integration frameworks, examples of which are PCTE, (Emeraude 1987), and Software Backplane, (Atherton 1987). Those products are usually not immediatelly useful as end user products, but represent semi-fabricates on top of which tool manufacturers are expected to build their products.
When it comes to ambitious environment products providing tightly integrated end user functionality, examples of which are Ule Interlisp, (Teitelman & Masinter 1984), Smalltalk, (Goldberg 1984), and the Rational Ada Environment, (Archer & Devlin, Rational 1986, Mor gan 1988), we see tlmt they are not built out of existing tools. Instead, tlley are carefully crafted togeUler from pieces built wiUI a single purpose: to fit into tlte environment and contri bute to its high levcl of integration.
To conclude, we observe Ulat it is hard to sec any successful attempts on building a com petitive environment out of existing tools.
We have noted two ,existing approachcs: (I)
Build the environment out of existing tools purchased on the market.
We consider Ulis approach unsound in that it can be shown to ruin the major beneficial characteristic of the next generation envirolUuents: the high level of integration.
Build the environment frolll scratch to ensure a high level of integration.
Although this approach has been shown feasible in some cases. it has the drawback of soaking up resources into development of basic capabilities and "tool kernels" which have no real relationship to the original reason for starting from scratch: improving the integra tion.
As an obvious alternative, we propose an approach which takes the best aspects out of the previous proposals:
Take existing tools, over which we have full technical alld cOllunercial comrol, and modify them into a high level of integration. Both Witll respect to each other, and wiU, respect to a possible "integration framework" on top of which the environment is built.
The idea sounds simple and obvious: instead of writing all those tools from Ule begin ning. we modify our existing ones whenever necessary. In this way we can achieve the high level of integration and productivity associated with the second approach. for a price that is closer to the first approach. Furthermore. since the software to use for the environment con struction is assumed to be known by in house engineers, there can be a fast start and high speed of progress.
However, few organizations have Ule necessary control over a sufficienUy interesting and complete set of software tools. For a successful project, Ule following criteria must therefore be met by the involved organizations: * They must have full technical and commercial control over significant software tools. *
They must have the willingness to modify UlOse tools to meet the requirements of the integrated environment. *
They must be ready to commit to certain tools, and therefore to a particular technology and philosophy of integration.
The rest of this paper reports on the applying of this philosophy in one particular context - the Ada product development efforts as carried out within the companies TeleLOGIC and TeleSoft.
The necessary prerequisites seemed to be Ulere in that it included full control over a pro
duction quality Ada compilation system and a debugger. (TeleSoft 1988), and a set of pro
grammer support tools as collected wiUtin the Arcs system. (Ada editor, browser, recompilation
tools. teamwork support, configuration control, program library manipulation. query tools, etc).
* * * * * *
Ada oriented editor.
Compiler & Binder.
Library database browser.
Debugger. "Integration framework", which includes program library database. query and command languagc. common internal datastructures, (such as Graphs (Schefstrom 1988», and win dowing system and associated VI toolkit.
Teamwork support and configuration management, which includes multiple user coordina tion, project control, and version management in the program library database. .
The primary and most ambitious versions of the software are being built to take advan tage of hardware configurations of Ule category "network of powerful workstations". The pur pose is simple: create a significant reduction in programming turnaround time. While not all of the components have reached the stage of a stable released product. prototypes exist and are in use internally.
Some of the components above, togeUler WiUl the philosophy of the integration frame work, have been described in earlier publications, (see references at end of chapter I). How ever, to make the presentation reasonably complete, we include a short summary of the integra tion framework.
The Arcs environment is in many rcspects centered around Ule Ada program library. [n our case this program library is much more general than is sllicUy required by the Ada LRM, (Narfelt & Schefstrom 1984, Narfelt & Schefstrom 1985). Rather than being tailored to only solving the Ada library problem. as initiaUy perceived, it supports a network, or graph-. oriented datamodel. Arbitrary nodes may be introduced, which are connected by arbitrary rela tionships. Both nodes and relationships may have attribllles. and also have a type. or a category. This is used by the compiler to represent Ada compilation units and their interrela tionships, as well by other tools to include non-Ada code or other information. Another usage is to impose a mcta structure, subsystems, on top of the oUlerwise flat namespace of Ule Ada library.
Included in this ffalnework is also a query and manipulation language based upon an extended relational algebra. Results of such queries are called graphs and nodelists, and all tools arc made to accept such objects as their input, and produce their output in the same way. This acts as one important integrating factor in Arcs.
The library database is distributed in the scnse that a single database is construCted out of arbitrary physically separate parts. This acts both as a means for distribution, sharing. view creation, and version managcmcnt.
All this is described in more dctail in Ule references above. The similarity in conccpts with efforts like PCTE/PACT, (PCTE 1986, PACT 1988), and CA[S, (CA[S 1988), should be noled. Similar ideas, and similar problems, seem to evolve out of the work around Hypertext systems, (CACM 1988). ( ( ( ( 5. Ada oriented editor
The language oriented editor is probably the most established and well-known component in modem programming environments, (programming environment workshop 1986, ACM 1984). It is a key component for reasons that will be explained. Nevertheless, different editors that all are called language-oriented differ dramatically in capabilities, and are often talked about interchangeably in a way that is not reasonable. Therefore, let us distinguish between two elasses of such editors: .. ..
Syntax-directed editors, which know about the syntax of the programming language, but not about the semantics. All of them can check the edited text for syntactic correctness; most of them allow the user to initially produce the text in terms of "syntactic categories"; some of them allow changes to take place in terms of "syntactic categories". Semantics-directed editors have, usually, all the syntax directed capabilities as a subset. In addition, they check and utilize typing information. This allows them to provide the prob ably more important extra benefits of type checking, interactive cross-reference, semantic completion, and browsing between modules in a system.
The Arcs editor belongs to tile second, semantics-oriented, category.
Since the services we want to provide are based on that syntactic or semantic information is available immediatelly during editing, it usually implies that this information must be main tained incrementally. In the semantics case, in combination with a language like Ada which inlposes a Sb'ong type checking among separately compiled units, one must also integrate the editor with the program library, since littie can be said semantically about a compilation unit in isolation. The intermediate representation used by the editor must tilen, for tilings to actually work, be tile same as for the batch compiler and code generators.
AltilOugh the above renections are at least partially known from a number of language editor projects, (Reps 84, Kaiser, Kaplan, & Micallef 1987), one could from a general software engineering standpoint observe that not many have a fair chance of actually building a seman tic Ada oriented editor, since it requires very close coordination WiUl a complete compilation system and its program library database.
When starting the work described here, we had already inlplemented an editor supporting
syntactic support and hierarchical structuring,
This was very useful for static inspection and understanding of a large system, and as a nice interface to the debugger. However, when changing tile unit in the editor most of tile semantic capabilities had to be turned off and the editor fell back to supporting mainly syntax. This because the semantic aspects of the internal form were not incrementally maintained, and must be updated in batch.
However, closer investigation of tile problem revcaled that more could be achieved without prohibitive costs, a large part of which can be attributed to a tight integration with the existing compiler.
The compiler used, (TeleSoft 1988), is structured into three phascs, a Front-End, a Middle-Pass, and Code Gcncrators. The Front-End includes all tilC routines for checking thc type correctness of a program, and its purposc in tilC translation process is to producc an intcr nal represcntation of th~ ,compiled unit, which can then be used as input to tilC Middlc-Pass. The Front-End is well separatcd from othcr parts, and is nm complctely before starting later • phases of the translation process.
Because of this property, it was possible to import the Front-End software into Ule editor, and using it for very quick type-checking and internal-fonn generation. When the user needs to execute his program, the environment checks for which units only Ule Front-End has been run, and when necessary runs the Middle-Pass and Code Generator. As is discussed in the next sec tion, Ule importing of all those compiler modules into Ule editor gives furUler substantial contri butions to decreasing turnaround time.
Further improvements of Ule editor are underway, including finer incrementality as a way of optimizing Ule generation of Ule internal fonn. Quite naturally, those opportunities are most obvious when a change is limited in scope or is in statements, (as opposed to in declarations).
The compiler is the most obvious and basic of tools in Ule environment, and a rich source of productivity enhancing integration opportunities. To achieve Ule high goals, Ule viewpoint must however be much more towards Ule compiler as one of many cooperating components. The structure of a compiler, to be possible to use in a high-integration environment, must be such that the parts can be used and called quite independenUy of each other. Different parts must be possible to recombine in new ways, and be possible to call independenUy and in different orders. Finally, it must be possible to activate routines in many states, such as in a partially completed syntactic or semantic analysis.
The compiler used in this project had those properties to a quite high degree, and made it possible to for a relatively low cost collect what we believe are Ule major benefits of tight integration. Although incremental update of Ule internal fonn, during editing, proved to be economic in many cases, the major benefit of Ule integration seems to come simply by avoid ing to throwaway computation results by repeatedly recompute datastructures from more basic forms. Given the current operating system and language teclmology, this seems to be closely related to whether one can keep datastructures in main memory and let tools eoooperate through those, as opposed to repeatedly converting between this fonn and Ule (usually different) fonnat Utat has to be used when communication Uuough fIles. This seemingly una voidable loss in both structural and semantic contents has been noted before, and is also developed in an excellent"paper by R. Balzer, (Balzer 87).
So, a conclusion is Ulat major gains can be achieved just by allowing tools to communi cate in the more precise way that is possible by sharing all datastructures in a single virtual memory space. This opens up new possiblilities, and creates new ways of Ulinking about tool cooperation Ulan are available when being contstrained to combine tools by pipes or reading each others output liles.
It also seems like Ada compilers are unusually rewarding to build this way, due to Ule dependency on a context of previously compiled units as provided in the program library. Any non-integrated Ada compiler must at every invocation open and read the program library, often doing certain conversions of an externally stored fonn to a more suitable internal fonn, fol lowed by a tennination where all those internal datastructures are lost. At the next invocation, Ule same datastmclures are created again, just to be thrown away yet another time.
Initial performance results are very encouraging, showing a 75 percent gain in compila tion speed at medium sized modules, (400 lines). The results are even beller wilh smaller modules, as well as in cases when errors are detected. The laller is due to that in case of errors, no phase beyond semantics is nm, making the (alternative) batch startup overhead ( ( ( relatively higher. Detailed results do of course depend on the characteristics of the actual com piler technology used, but we see no factors that would dramatically change the tendency.
The tight integration also makes it easy and obvious to provide more end user services. Examples of such are fast semantic error feedback to the editor, and quick response and sug gested recompilation orderings in case modules have been compiled in wrong order. Another nice example is the direCt' communication with the browser, which makes it possible to directly update graphical presentations whenever a compilation, (or editing session), causes a structural change.
Finally, any Ada linker must check that the modules linked togetller have been compiled in the correct order. In the integrated compiler, all the necessary datastructures are immedi atelly available making this operation much less costly.
In modem programming environments, which are often based on a complex and highly structured "database", the tools for searching and presenting data are of great importance. The most important such tool is usually called the "browser".
In our most basic case, the database contains an Ada program whose development the environment is intended to support. The role of the browser is then to visualize that program to the user, and allow him to move around among the packages, changing view and level of abstraction. The browser also establishes a default context, and provides a means for changing from typing characters into pointing at desired objects. All this immediatelly extends into han dling any types of objects, and is therefore the most visible manifestation of the "seamless sys tem".
The browser in Arcs provides a number of different views and modes, and utilizes type information to present library database structures in the most appropriate way. When presenting nodes and relationships that can be identified as Ada modules and their interrelationships, Ada specific knowledge is used to group nodes and select icons as to emphasize that what is viewed is indeed an Ada program. Examples includes hiding bodies and subunits under specification nodes, and grouping together such units that arc in the same subsystem.
The browser is tightly integrated WiUl Ule rest of Arcs, some examples of which are tlle following: • • • •
When a unit is recompiled, replaced, deleted, or a new unit included into Ule scope of the current library, this immediatelly affects the view presented by the browser.
The result of operations using tlle query and manipulation language are reported in terms of objects, called "graph variables". Those are in fact tlle variables of the query language, and the browser, as any tool in Arcs, takes such variables as input.
The unit clicked on using the browser is automatically made the default unit for any other command in Arcs.
The browser reads its information from exactly tlle same source, tlle program library data base, as is used by evcry otller tool. This means that graphical pictures presented by the browser are always correct and up to datc in the sense tllat what is seen is always exactly tlle software that would execute if the linker was called and tllC resulting program was started.
The browser was however created specifically for Arcs, and di.d not exist on beforehand . 8. Debugger
Debugging is closely coupled to Ule inspection and browsing of programs. Therefore, tools like the browser and Ule editor, with its interactive cross reference ability, fit extremely well in Uus context. If such tools are immediatelly available in close connection to the debug ging session, they not only provide their original seIVice of ovelView and aiding understanding of the program, but provides Ule context and presentation mechanisms for the pure debugger activities. In fact, browser and "semantic" editor togeUler makes up a main part of the debuggers user interface. Reusing those components in this new context furUler strengthens the users feeling of system unifonnity.
The tight integration here also shows the usual benefits of sharing internal datastructures. The internal fonns used by Ule compiler in doing typechecking and managing separate compi lation, and by the semantic Ada editor to provide interactive cross referencing and semantic completion, is of course also used by the debugger. The immediate availablility of those datas tructures, togeUler WiUI the resulting very short debugger initialization time and freedom of context change, furUler contributes to minimizing turnaround time.
The debugger existed on beforehand as a separate tool WiUI its own user interface and own management of internal datastruetures.
In practice we seldom work alone, but are members of a team of programmers which concurrenUy modifies and updates different parts of the same program system. Any sel;ous enviromnent must allow for Ulis dynamic process of continuous change to proceed, without resorting to extensive manual work, recompilations, or purely administrative solutions. This is, however, one of Ule major challenges in building an Ada development system. Not very surprisingly, Ule design of Ule program library database is a very central issue here. (I) (2) (3)
In Arcs, we approach Ulis area in tenns of three aspects: First, different users must be able to have differellt views of UlC same system under development. While Ule largest part of Ule program library is common to Ule program mers of a project, Uley must be able to specify arbitrary individual variations. One pro grammer might be updating one unit, in his view, while another one need to see Ule older stable version while testing still anoUler unit. This independence must be provided while not forcing duplication of parts that don't need to be so.
Second, partly as a consequence of the first requirement, it must be possible to have IlI/iI tiple versiolls of the same unit in the program library. The first requirement could infact be approached as a question of allowing multiple versions, and allowing different people denote different versions as the default. The related concept of a configuration must then be introduced.
Finally, but very important and sometimes forgotten, Ulere must be good support for the work process. The configuration control scheme must be built for an interactive, dynamic, changing, and sometimes inconsistent, environment. We have found this last aspect, of hardening Ule configuration control system Witil respect to frequent change, as most fruit ful and rewarding to work wiUl.
Arcs, together with the TeleGen2 program library on top of which it is built, meets those requirements to a very high degree. (
In our case, an Ada program library is defined by composing a list of sublibraries, each containing an arbitrary set of compilation units. Sublibraries are independent entities, and may be combined completely freely to construct full libraries; it is just that certain combinations of sublibraries will make Arcs generate more complaints about recompilation needs and missing units than others. This property, independence of sublibraries, infact showed to be mOl:e important and useful than we fully foresaw when designing it.
The scheme is very general, and can be used in many ways. However, Ule method dis cussed here might be called "incremental baseline update", and builds on Ulat a given set of sublibraries are said to represent the most recent stable state of the project, in other words, a "baseline". Worl< then proceeds by programmers reserving units in a baseline sublibrary, tran sefering them to a private sublibrary for modification and test. When finished, Ule unit can be moved back to Ule origin sublibrary, but maybe more typically to an intended Next Version of the Baseline sublibrary, ~\)1ce other people may not want to see the change immediatelly.
The following shows a typical such sublibrary list:
At some suitable point in time the configuration manager then decides to establish a new Baseline, and the point here is that Ulis can be done witil a single command, in a slruclurcd and highly automatic way given the information in the Baseline and Next Version sublibraries. (I) (2) (3) (4)
The following summarizes the basic cycle: Get a unit from Baseline sublibrary inlo a private sublibrary.
Modify and test tile unit in private area without disturbing others.
Return the unit 10 Next Version baseline sublibrary when finished.
Generate new baseline from old Baseline and Next Version sublibraries.
Going into Ule details of this kind of multiple version, multiple people environment, reveals a large number of questions and special cases. However, most of them can be handled using this basic structure. Let liS consider some examples: •
Assume now that other people have updated and returned units, and you want to make those visible in your view for testing against, and you don't want to wait until a complete new baseline makes it visible. To solve this problem, tile RESYNC command can be used, which synchronizes the local view WiOl what has been released as Next Versions. This is done by giving the user local versions of tile Next Version units he doesn't already have.
As anotller example, consider what happens if you you have reserved and changed a cen tral spec, and therefore need to recompile many depending units, many of which currently are in the baseline, (and therefore are shared between many people).
This problem is directly solved by the COMPILE command, which computes tile neces sary recompilations, and makes sure that tltis takes place only in tile local view.
Finally, consider tile case that one want to reserve a mtit for update, but there is a newer one than the Baseline version.
The answer is that the GET command will automatically select the newest version, (if it is not reserved, in which case reselvation is denied).
Similar schemes for doing configuration control and coordination of project groups have
been presented within NSE,
The most important component, the Ada program library, existed on beforehand. How ever, Arcs teamwork support and configuration management could never have been built, as is true for all of the services presented, without the unrestricted access to internal interfaces. 10. Experience
AIl parts of what IS' described above have been developed at least to the stage of proto types stable enough for internal use. A subset of tile functionality is currently offered, and has been delivered, as a product to external customers, and over the next year tile externally avail able functionality will be successively increased. However, tltis means tilat tile major experi ence tllis far comes from the internal use, and tile following comments are based on this fact. 10.1. User Illterface
Arcs was originally built in a bottom-up philosophy, emphasizing basic primitives and combinational ability. The quite large body of functionality was provided by memlS of basic building blocks, which could tllen be combined into different more elaborate services.
As an example of tllis approach, consider the often wanted service of iterating through all places in a system where a particular procedure is called. In a large system, this obviously involves searching through many modules. According to the building block approach, the basic service of stepping through units was made extremely simple: The command
Arcs> ixref init <list of units> just causes tile given <list_oCunits> to be searched. However, the problem of creating that list of compilation units, containing all tllOse units where it could be meaningrul to search for calls of tile given procedure, is not part or the "ixref' command. Instead, the generally available pro gram library database query language should be used ror this task, utilizing the fact that Ihc ( only units that could pOssibly contain a call to a given procedure are those that 1) directly "withs", or 2) are secondary units, to the unit in which the procedure is declared. The Arcs command language allows such queries to be expressed direcUy at the same command line.
This kind of generality provided a lot of power, and created numerous unexpected new usages and combination opportunities. However, only for U,e expert user. Experienced people having the necessary curiosity, and time to invest, find it very powerful, while oU,er people. have found Ute generality overwhelming and even disturbing.
As a result of U,is experience, we are now working on providing more prepacked serviccs corresponding to often wanted patterns of combinations of basic functions. The trick here is to do Utis while keeping U,e combinational abilities and avoiding to create an ever more complex system.
While the Ada oriented editor provide a substantial body of well appreciated functionality not available oUterwise, Ute mere introduction of another editor is an obstacle in many cases. Despite the fact Utat most people learn the editor in less than a day, U,e intrusion into what is in some cases considered to be the programmers innermost privacy - U,e editor - is creating much discussion. The opinion has been that one should fmd a way of providing all the serviccs while letting the user still use standard "vi", for example.
However, the previous discussion in this paper, together with several investigations dedi cated to the editor problem, seem to show U,at accepting U,e limitations of not having "admin istrative and teclmical control" over the editor would be too hard. So, instead of trying to util ize an arbitrary editor, we invest more, and extend, the one Utat is built into Arcs. The development goes along two lines: I) we create a number of special versions of the built in editor to make it appear like different popular editors. 2) We introduce even more functionality dedicated to software development, to further motivate the change to a new editor. 10.3. Configuration cOll/rol
The configuration control in Arcs, or as it also is called, "Teamwork support", is an example of functionality that successively grew out of the need and experience of the work in the developmcnt group. Different specifications were written and evaluated, but it was not until we had used Ada for a large system, with multiple people, for a longer time, that we could develop a functionality that was really felt helpful. The reason it took time before reaching a matured standpoint in Utis subject is probably just that it is a complex area where fcw well known principal results are available. It is furU,ermore an area where the semantics of modem separate compilation languages like Ada interact WiOl thc environment in a very elaborate way.
This inherent complexity, together with U,e fact that many people, just as in U,e case with the editor, already have some own way of working, makes lilis part of Arcs into one of thc most difficult to explain. However, oncc the problem is understood, and UlC Arcs configuration control functionality has becn in use for a while, the service turns out to be among thc most valuable and appreciated. 11. Acknowledgements
The ideas and results reportcd hcre are part of what has been discussed, argucd about, and worked on ovcr U,C ycars at onc of U,e most creativc places I know: The Ada Devclop ment Environments conidor at TelcLOGIC/Lulea. Mikael Backinan, Nils Livingstonc, Hans Ohman. Ola Stromfors. and Johnny Widen, are all responsible for any good ideas presented in ~tis paper. 12. References ACM (1984).
Proceedillgs of tile ACM SIGSOFT/SIGPLAN Software Ellgilleerillg Symposium 011 Prac tical Software Developmellt Ellvirollmellts, Peler Henderson, cd., Pittsburgh Pennsyl vartia, April 1984.
Archer & Devlin
Ratiollal's Experiellce usillg Ada for Very Large Systems, "White Paper". Rational, 1501 Salado Drive. Mountain View. CA 94043.
Atherton (1987),
Tile Software Backplalle. Product description material, Atherton Technology, 1333 Bor deaux Drive, Sunnyvale, CA.
Balzer (1987),
Livillg ill tile Next-Gelleratioll Operatillg System, in (IEEE Software 1987).
Barstow, et ai, (1984),
Imeractive Programmillg Ellvirollmellts, Barstow, Shrobe, & Sandewall. McGraw-Hill 1984.
Blumberg et aI (1988).
NASA Software Support ellvironmellt: COllfigurillg all Ellvironment for Ada Desigll, Blumberg, Cantor, McNickle, and Reedy. in "Ada in Industry", Proceedings of the 1988 Ada-Europe Conference, Munich. Cambridge University Press.
CACM (1988),
Communicatiolls of tile ACM - SpeciallsSlle 011 Hypertext, July 1988.
CAIS (1988),
Military Stalldard Commoll APSE lllterface Set (CAlS). Proposed Military Standard, US Dep of Defellse.
Carr et aI (1987),
Implemelltatioll of a Prototype CAIS Ellvironmellt, in ACM Ada Letters, Volume VII, number 2, March,April 1987.
Emeraude (1987),
Emeraude PCTE Gelleral Preselltatioll, Product Description Material, G.I.E. Emeraudc, 38, bd H.-SeUier. 92154 Suresnes Cedex, France.
Fersnstrom et al (1988).
Eureka Software Factory Desigll Guidelines and Arcilitecture, Fernstrom, Narfell, Rccn skaug, Schaefer, and Weber. ESF consortia 1988.
Gallo, Minot, & Thomas (1986),
Tile Object Managemellt System of PCTE as a Software Ellgilleerillg Database Manage mellt System, in Proceedings of tile ACM SIGSOFT/SIGPLAN Software Enginccring Symposium on Practical Software Development Environments, Palo Allo, Cal, Dce 1986. Goldberg (1984),
Tile Illfluellce of all Object-Oriented Lallguage 011 tile Programming Environment, in ( (
(Ballitow 1984).
IEEE Computer (1987),
IEEE Computer, Nov 1987, Special issue on programming environments.
IEEE Software (1987),
lEEE Software, Nov 1987, Special issue on programming environments.
Kaiser, Kaplan, & Micallef,
Multil/ser, DistribllJed Lallgl/age-Based Ellvirollmems, lEEE Software, November 1987. Morgan (1988),
COllfigllratioll Managemellt alld Versioll Comrol ill tire Ratiollal Programmillg Ellviroll mem, in "Ada in Industry", proceedings of the 1988 Ada-Europe Conference, Munich, Cambridge Univelliity Press.
Narfelt & Schefstrom (1984),
Towards a KAPSE Database, in Proceedings of the 1984 lEEE Conference on Ada Applications and Environments, StPaul, Mirmesota 1984.
Narfelt & Schefslrom (1985),
Extelldillg tire Scope of tire Program Library, in 1985 International ACM Ada Confer ence, Paris 1985.
Programming Environment Workshop, (1986),
Proceedillgs from [mernatiollal Workslrop 011 Advallced Programmillg EllvironmenlS, Trondheim, Norway, June 1986.
PCTE (1986),
A Basis for a Portable Commoll Tool Ellvirollmem, Functional Specification. European Strategic Programme for Research and Development in Information Technology. PACT (1986),
PACT Gelleral Descriptioll, Bull SA Louvecielmes, France, 1986.
PACT (1988),
PACT Commioll Services - C Lallgl/age, Bull S.A. Louveciennes, France, 1988. Pierce (1987)
ECLIPSE - All APSE Based 011 PCTE, in Proceedings of the Ada-Europe International Conference, Stockholm, May 1987.
Reps (1984),
Gelleratillg Lallgl/age-Based ellvirollmems, MIT Press, Cambridge, Mass.
Software Sciences (1987),
Eclipse Overview, Software Scienccs Ltd, UK, OClober 1987.
Rational (1986),
Applicatioll of tire ratiollal EllvirOlUllem to Lifecycle Software Development, "Whilc Paper", Rational, 1501 Salado Drive, Mountain View, CA 94043.
Tei LeIman & Masinter (1984),
Tire [Ilterlisp Programmillg Ellvironmem, in (Ballitow 1984).
TeleSoft (1988),
TeleGell2 - Tire TeleSoft Second Gelleratioll Ada Developmellt System, User's GI/ide.
TeleSoft, 5959 Cornellitone Court West, San Diego, 92024 California Schefslrom (l986a) [megralillg an Ada.. Library Syslem inlo lire Unix Configuratioll Management Toolset. •