=Paper=
{{Paper
|id=None
|storemode=property
|title=On Posteriori Integration of Software Tools
|pdfUrl=https://ceur-ws.org/Vol-961/paper15.pdf
|volume=Vol-961
|dblpUrl=https://dblp.org/rec/conf/caise/Schefstrom89
}}
==On Posteriori Integration of Software Tools==
https://ceur-ws.org/Vol-961/paper15.pdf
On Posteriori Integration of Software Tools
Dick Schefstrom
TeleLOGIC AB, Allrorum 1,951 75 Lulea, Sweden.
Abstract.
This paper tries to define and exampJify the concept of "integration" in the context of soflware develop-
ment support environments. TIle benefits of tight integration are discussed, together with different ap-
proaches 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 pro-
•
gramming support environment according to those principles.
(
1. The Role of Integration
Much hope is today focussed on the use of tools as a way increasing productivity in
software development, shown, for example, by the rapidly growing activity under the label
"CASE". While a substantial market of tools, supporting various parts of the software lifecycle,
indeed exist, few people would claim that a corresponding major productivity breakthrough has
occurred.
In this paper, we will focus on what might be the major obstacle before substantial gains
can be shown - the lack' Of integration. The basic argument is that the semantic loss and over-
head imposed by moving between tools that don't know about, and contribute to, each other, is
so big that it cannot be bypassed.
Another aspect of the problem is that the tasks perfonned during software development
never are so phased and isolated from each other, as the body of existing tools seem to imply.
Infact, software development is never is truly "automatic", and the role of tools is therefore
most often in providing the user with the infonnation he needs, and doing so WiUl short
response time and without requiring him to engage in errorprone or context breaking dialogues
with different other tools. The infonnation needed often spans over phases, obvious examples
being the need for accessing requirements documents, and design descriptions, in direct con-
nection to programming and maintenance.
In building support systems, the approach has often been to concentrate on selecting the
"right" functions, quite independently of each other. While this decomposition-oricnted
approach is easier to deal with, both from a teclmical and project administrative point of view,
it usually fails to recognize tile large potential of cross-service cooperation, and the obvious
fact that the value and usefulness of a service always is relative to its cost, tile latter which has
tluec components:
(I) The cost of activating a service in tcnns of finding it and providing tile light parameters.
(2) The cost, in waiting time, for tile user while the computer is working.
(3) 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.
(
1.1. A Definition of Integration
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.
1.1.1. Uniformity.
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.
2. Approaches to Building Development Environments
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.
2.1. Another Approach
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.
(2) 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).
(Schefstrom 1988). What is discussed here is Ulerefore probably best described as Ule second,
and maybe definitive. step in the development of Arcs, (Schefstrom 1988, Schefstrom 1987,
Schefstrom 1986a, Schefstrom 1986b, Schcfstrom 1986c, Narfelt & Schefstrom 1985, Narfelt
& Schefstrom 1984).
3. An Overview of Arcs
AlUlOugh integration takes away many of the traditional distinctions between tools, one
could divide Arcs into Ule following components:
* 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.
4. Integration 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, (Stromfors 1981, Stromfors 1986), as well as
certain semantic services like interactive cross referencing of (batch) compiled units. These ser-
vices utilized the internal form generated by the compiler, and tilereby already showed a degree
of integration with the compilers internal form and tile program library.
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).
6. Compiler and Linker
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.
(
7. Library Browser
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 did 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.
9. Teamwork Support and Configuration Control
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.
In Arcs, we approach Ulis area in tenns of three aspects:
(I) 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.
(2) 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.
(3) 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:
(
Typical sublibrary list:
•
3. Standard_Sublibrary
Showing Next Version sublibrary:
1. Programmers_Private
3. Standard_Sublibrary
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.
The following summarizes the basic cycle:
(I) Get a unit from Baseline sublibrary inlo a private sublibrary.
(2) Modify and test tile unit in private area without disturbing others.
(3) Return the unit 10 Next Version baseline sublibrary when finished.
(4) 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, (Sun Microsystems 1988) and Eclipse, (pierce 1987). What (
differs Arcs from those systems is the high level of integration in Arcs, between tile tools and
subsystems mentioned above, tile program library database, and tile characteristics of the Ada
language. In that sense it is similar to the Rational environment, (Morgan 1988).
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
just causes tile given 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.
(
10.2. Tile editor
•
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.
2:nd IEEE Conference on Ada Applications and Enviroruncnts, Miami Beach, Aplil 1986.
Schefstrom (l986b),
Integratillg Ada ill all Existillg Ellvirollmem - the Arcs Example, 1986 ACM Ada Confer-
ence, Edinburgh, May 1986.
Schefstrom (l986c),
Project Support Buildillg all the Ada Program Library, in Proceedings of Mll..COMP-86,
London, September 1986.
Schefstrom (1987),
The System-Oriemed Editor - A Tool for Mallagillg Large Software Systems, 1987 ACM
SIGAda Conference, Boston, Dec 1987.
Schefstrom (1988),
Programmillg-ill-the-Large with the System-Oriellted Editor, -1988 AdaEurope Confer-
ence, Munich, Germany, june 1988.
Stromfors (1981),
The Implemelltatioll alld Experiellces of a Strtlclllre-Oriemed Text Editor, in Proceedings
of ACM SIGPLAN/SIGOA Symposium on Text Manipulation, SIGPLAN Notices, vol
19, no 6, 1981.
Stromfors (1986),
Editillg Large Programs Usillg a Strtlctllre-Oriellted Text-Editor, Ola Stromfors, Linkop-
ing University. In (p.rogramming Envirorunent Workshop, 1986).
Sun Microsystems (1988), _
Illtroduction to NSE, March 1988.
(