Models of Software Development Environments.
A general model of software development environments that consists of structures, mechanisms, and policies is presented. The advantage of this model is that it distinguishes intuitively those aspects of an environment that are useful in comparing and contrasting software development environments. Four classes of environments-the individual, the family, the city. and the state-are characterized by means of a sociological metaphor based on scale. The utility of the taxonomy is that it delineates the important classes of interactions among software developers and exposes the ways in which current software development environments inadequately support the development of large systems. The generality of the model is demonstrated by its application to a previously published taxonomy that categorizes environments according to how they relate to language-centered, structure-oriented, toolkit, and method-based environments.
Introduction
A model is useful primarily for the insight it provides about particular instances and collections of
instances. By abstracting away non-essential details that often differ in trivial ways from instance to
instance and by generalizing the essential details into the components of the model, we derive a tool for
evaluating and classifying these instances - in ways that we had not thought of before we constructed our
model. It is with this purpose in mind - classification and evaluation - that we introduce a general model
of software development environments (SDEs). Our model consists of three components: policies,
mechanisms and structures.
Once we have defined this general model of software development environments, there are various points
of view from which we might classify environments. We might, for example, classify the SDEs according
to their coverage of the software life cycle; or classify them according to the kinds of tools that they
provide, contrasting those that provide a kernel set with those that provide an extended set; etc. Each of
these classifications yields useful comparisons and insights.
Another important point of view, which we have not seen in the literature, is a classification of SDEs
relative to the problems of scale - what is required of software development environments for projects of
different sizes taking into account the numbers of people and the length of the project as well as the size
and complexity of the system. Note that the distinction between programming-in-the-small and
programming-in-the-large [7] has some intimations of the problems of scale. However, this distinction is
basically one of single-unit versus multiple-unit systems and captures only a small part of this problem.
We build software systems that range from small to very large, and will be able to build even larger
systems as hardware gets cheaper and more powerful. What has not been sufficiently considered is the
effect of the scale of systems on the tools needed to build them*.
Thus, the main focus of this paper - and, indeed, of our research - is the problem of scale. We introduce
a classification of SDEs in terms of a sociological metaphor that emphasizes this problem of scale and
provides insight into the environmental requirements for projects of different sizes. This metaphor suggests
four classes of models: individual, family, city and state. The individual and family classes are the current
state of the art but are inadequate for building very large systems. We argue that the city model is adequate
but that very little attention has been given to this class. Further, we argue that future research and
development should address the city model and the proposed state model.
In section 2, we present our model of software development environments, discuss the individual
components and their interrelationships, and illustrate various distinctions that we make with environments
from the literature. In section 3, we classify SDEs into the four classes suggested by our metaphor,
characterize these classes, present a basic model for each class, and categorize a wide variety of existing
environments into the individual, family and city classes (we know of no examples of the state class).
Finally, in section 4 we summarize the contributions of our model and classification scheme.
We confine our discussion in the sections below primarily to those environments concerned with the
problems of implementing, testing, and maintaining software systems - that is, those environments that
are concerned about the technical phases of the software development process. We believe that
environments that concentrate on the full life-cycle and project management issues also could be described
with this model and categorized according to our classification scheme presented in section 3.
2. A General Model of Software Development Environments (SDEs)
Our general model of software development environments consists of three interrelated components:
policies, mechanisms and structures.
__________________
* For example, Howden [18] considers SDEs for medium and large systems only from the standpoint of capitalization and richness
of the toolset.
General { Policies }, { Mechanisms }, { Structures } )
. Policies are the rules, guidelines and strategies imposed on the programmer* by the environment;
. mechanisms are the visible and underlying tools and tool fragments;
. structures are the underlying objects and object aggregates on which mechanisms operate.
In general, these three components are strongly interrelated: choosing one component may have serious
implications for the other two components and place severe limitations on them.
We discuss each of these components of the model, illustrate them with examples from the SDE literature,
and discuss their interdependencies.
2.1 Policies
Policies are the requirements imposed on the user of the environment during the software development
process. These rules and strategies are often hard-coded into the environment by the mechanisms and
structures. For example, static linker/loaders generally require all externally referenced names to be defined
in the set of object modules that are to be linked together. This requirement, together with the requirement
that only linked/loaded objects may be executed, induces a policy of always compiling the modules before
linking them. A different strategy is possible for execution preparation tools that provide dynamic linking
and, hence, a different policy: for example, Multics' segmentation scheme [33] allows externally referenced
names to be resolved at run-time. In most cases, the design of the tools and the supporting structures define
or impose the policies.
But policies need not be hard-wired. A few architectures allow the explicit specification of policies. For
example, Osterweil's process programming [34,49] provides the ability to program the desired policies with
respect to the various mechanisms and structures available; Darwin's law-governed systems [30] consist of
declaratively defined rules restricting the interactions of programmers and tools. The important distinction
between hard-wired policies and process programs or rule systems is that the latter are architectures for
building environments and provide a way of explicitly imposing policies on the developers independently
of the mechanisms and structures.
Another distinction is between supporting and enforcing policies. If a policy is supported, then the
mechanisms and structures provide a means of satisfying that policy. For example, suppose that top-down
development is a supported policy. We would expect to find tools and structures that enable the developer
to build the system in a top-down fashion; by implication, we would also expect to find tools and structures
to build systems in other ways as well. If a policy is enforced, then not only is it supported, but it is not
possible to do it any other way within the environment. We call this direct enforcement when the
environment explicitly forces the developer to follow the policy. A slightly different kind of enforcement is
that of indirect enforcement: policy decisions are made outside the environment either by management or
by convention but once made they are supported but not enforced by the environment. For example,
management decides that all systems are to be generated only from modules resident within the Source
Code Control System (SCCS) [42]. The environment supports configuration management with SCCS;
however, it is the management decision that forces the developers to control their modules within SCCS.
There is a further distinction to be made between those policies that apply to mechanisms and structures
and those that apply to other policies. We refer to the second as higher-order policies. For example, 'all
projects will be done in Ada' is a higher-order policy.
2.2 Mechanisms
Mechanisms are the languages, tools and tool fragments that operate on the structures provided by the
environment and that implement, together with structures, the policies supported and enforced by the
environment. Some of these mechanisms are visible to the developers; others may be hidden from the user
__________________
* We use the term programmer in a generic sense to include any user of the environment.
and function as lower-level support mechanisms. For example, the UNIX TM System [25] tools for building
systems are available to the user. However, in Smile [21] these tools are hidden beneath a facade that
provides the developer with higher-level mechanisms that in turn invoke individual UNIX tools.
Policies are encoded in mechanisms in one of two ways: either explicitly by policy makers for a particular
project, or implicitly by the toolsmiths in the tools that comprise the environment. In the first case,
mechanisms such as shell scripts [19], Darwin's, CLF's [5] or Marvel's rules [20], or process programs
enable the policy maker to define explicitly the policies to be supported by the system. Whether these can
also be enforced depends on how well these mechanisms restrict the developer in what he or she uses in the
environment. In the second case, the examples from the preceding section (illustrating hard-wired policies)
exemplify implicit encoding. In most SDEs, policies are implicitly encoded in the mechanisms. There are
good historical reasons for this situation: we must work out particular instances before we can generalize.
Particular mechanisms and structures must first be built that implicitly encode policies in order to reach a
sufficient understanding of the important issues. Once we have reached this level of maturity, we can then
separate the specification of policies from mechanisms and structures.
2.3 Structures
Structures are those objects or object aggregates on which the mechanisms operate. In the simplest (and
chronologically, earliest) incarnation, the basic structures - the objects with which we build systems -
are files (as in UNIX, for example). The trend, however, is towards more complex and comprehensive
objects as the basic structures. One reason for complex basic structures is found in integrated
environments, particularly those centered around a syntax-directed editor [12, 50]. These SDEs share a
complex internal representation such as an abstract syntax tree [9] or an IDL graph [26] to gain efficiency in
each tool (because, for example, each tool does not need to reparse the textual form, but uses the
intermediate, shared representation). The disadvantage of this approach is that it is difficult to integrate
additional tools into the environment, particularly if the structure provided does not support well the
mechanisms and their intended policies. Garlan's tool views [14] provide a partial* solution: a structure and
a mechanism for generating the underlying common structure consistent with all the requirements of the
different tools in the SDE.
Another reason for this trend is to maintain more information about software objects to support more
comprehensive mechanisms and policies. For example, the use of project databases has been a topic of
considerable interest in the recent past [1, 31]. The basic structure currently generating a large amount of
interest is the objectbase [20, 49, 45] - it is hoped that this approach will solve the deficiencies of files and
databases.
These basic structures are the foundation for building more complex and more comprehensive higher-order
structures. For example, Inscape [37, 38] maintains a complex semantic interconnection structure among
the system objects to provide comprehensive semantic analysis and version control mechanisms and
policies about semantic consistency, completeness and compatibility among the system objects. Smile's
experimental database is a higher-order organization of basic structures that supports mechanisms and
policies for managing changes to existing systems. The Project Master Data Base (PMDB) [36] provides
an entity-relationship-attribute model [4] to represent, for example, problem reporting, evaluation and
tracking processes. CMS's Modification Request Tracking System [43] builds a structure that is
intertwined with SCCS's configuration management database (which in turn is built on top of the UNIX file
system); it coordinates change requests with the actual changes in the system. Finally, Apollo's Domain
Software Engineering Environment (DSEE) provides a comprehensive set of structures for coordinating the
building and evolving of software systems; these structures support, for example, configuration control,
planning and developer interactions.
__________________
* We say partial in the sense that Garlan's views do not help at all if the environment and its tools already exist independently of
Garlan's mechanisms and new tools need to be added. It is a full solution in the sense that if one develops the entire environment
with Garlan's views, then adding a new tool requires that one adds the view needed by that tool to the original set and generates the
newly integrated structure.
In general, structures tend to impose limitations on the kinds of policies that can be supported and enforced
by SDEs. Simple structures such as files provide a useful communication medium between tools but limit
the kinds of policies that can be supported. The more complex structures required by integrated
environments such as Gandalf [32] enable more sophisticated policies, but make it harder to integrate new
mechanisms and policies into the environment. Higher-order structures such as Infuse's hierarchy of
experimental databases [39] make it possible to enforce policies that govern the interactions of large groups
of developers, but do not allow the policy maker the ability to define his or her own policies.
One fact should be clear: we have not yet reached a level of maturity in our SDEs with respect to
structures. There is still a feeling of exploration about the kinds of structures that are needed. Indeed, there
is the same feeling of exploration about the policies that can or should be supported by an SDE, particularly
for those SDEs that are concerned with large-scale projects.
3. Four Classes of Models
We present a classification of SDEs from the viewpoint of scale: how the problems of size - primarily the
numbers of developers, but by implication the size of the system as well - affect the requirements of an
SDE that supports the development of those systems. Our classification is in terms of a sociological
metaphor that is suggestive of the distinctions with respect to the problems of scale. Along what is a
continuum of possible models, we distinguish the following four classes of SDE models:
Individual
Family
City
State
Our four classes follow the metaphor in that a family is a collection of individuals, a city is a collection of
families, and a state is a collection of cities; basically, each class incorporates those classes to its left. Our
metaphor also suggests that there may be further distinctions to be made to the right of the family model -
for example, neighborhoods, villages, etc. However, as relatively little is known about SDEs that support
city models, and nothing is known about SDEs that support the state model, we make as few distinctions as
possible. The purpose of this paper is to draw attention to these two representative classes - that is, the
city and the state.
We present two orthogonal characterizations for each class. The first emphasizes what we consider to be
the key aspect that distinguishes it in terms of scale from the others. These aspects are:
. construction for the individual class of models;
. coordination for the family class;
. cooperation for the city class; and
. commonality for the state class.
The second characterization emphasizes the relationships among the components. Historically,
. mechanisms dominate in the individual class;
. structures dominate in the family class;
. policies dominate in the city class; and
. higher-order policies dominate in the state class.
For each class of models we present a description of the class and support our characterizations with
example SDEs. For convenience in the discussion below, we use the term model instead of class of
models.
3.1 The Individual Model
The individual model of software development environments represents those environments that supply the
minimum set of implementation tools needed to build software. These environments are often referred to
as programming environments. The mechanisms provided are the tools of program construction: editors,
compilers, linker/loaders and debuggers. These environments typically provide a single structure that is
shared among mechanisms. For example, the structure may be simple, such as a file, or complex, such as a
decorated tree. The policies are typically laissez faire about methodological issues and hard-wired for
nano-management issues.
Individual
{ tool-induced policies* } ,
{ implementation tools } ,
{ single structure }
These environments are dominated by issues of software construction. This orientation has led to an
emphasis on the tools of construction - that is, the mechanisms - with policies and structures assuming
secondary importance. The policies are induced by the mechanisms - that is, hard-wired - while the
structures are dictated by the requirement of making the tools work together.
We discuss four groups of environments that are instantiations of the individual model: toolkit
environments, interpretive environments, language-oriented environments, and transformational
environments. The toolkit environments are exemplified by UNIX; the interpretive environments by
language-oriented environments by the Cornell Program Synthesizer [50]; and the
transformational environments by Refine [46].
The toolkit environments are, historically, the archetype of the individual model. The mechanisms
communicate with each other by a simple structure, the file system. Policies take the form of conventions
for organizing structures (as for example in UNIX, the bin, include, lib and src directories) and for ordering
the sequence of development and construction (as exemplified by Make [13]). These policies are very weak
and concerned with the minutiae of program construction. However, shell scripts provide the administrator
with a convenient, but not very extensive, mechanism for integrating tools and providing support for
policies beyond those encoded in the tools.
{ tools-induced policies, script-encoded policies, .* } ,
{ editors, compilers, linker/loaders, debuggers, . } ,
{ file system }
Interpretive environments are also an early incarnation of the individual model. They consist of an
integrated set of tools that center around an interpreter for a single language such as Lisp or Smalltalk [15].
The language and the environment are not really separable: the language is the interface to the user and the
interpreter the tool that the user interacts with. The structure shared by the various tools is an internal
representation of the program, possibly with some accompanying information as exemplified by property
lists. These environments are noted for their extreme flexibility and there are virtually no policies enforced
(or, for that matter, supported). Thus, in contrast to the toolkit approach where the tools induce certain
policies that force the programmer into certain modes of operation, programmers can essentially do as they
please in the construction of their software.
__________________
* We use italics for general descriptions of the components and normal typeface for specific components.
* The notation "." at the end of the list indicates that additional facilities may be available.
Interpretive
{ virtually no restrictive policies } ,
{ interpreter, underlying support tools } ,
{ intermediate representation }
Language-oriented environments are a blend of the toolkit and interpretive models. They provide program
construction tools integrated by a complex structure - a decorated syntax tree. Whereas the tools in the
toolkit environments are batch in nature and the tools in the interpretive are interactive, the tools in
language-oriented environments are incremental in nature - that is, the language-oriented tools try to
maintain consistency between the input and output at the grain of editing commands. A single policy
permeates the tools in this model: early error detection and notification. These environments might be
primarily hand-coded, as in Garden [40], or generated from a formal specification, such as by the
Synthesizer Generator [41].
Language-Oriented
{ error prevention, early error detection and notification, . },
{ editor, compiler, debugger, . } ,
{ decorated syntax tree }
Transformational environments typically support a wide-spectrum language (such as V [46]) that denotes a
range of object and control structures from abstract to concrete. Programs are initially written in a abstract
form and modified by a sequence of transformations into an efficient, concrete form. The mechanisms are
the transformations themselves and the machinery for applying them. The structure is typically a cross
between the intermediate representation of the interpretive model and the decorated syntax tree of the
language-oriented model. As in the language-oriented environments, a single policy defines the style of the
environment: the transformational approach to constructing programs (as, for example, in Ergo [44] and
PDS [3]). Programmer apprentices, such as KBEmacs [53], are a variation of this policy in that the
programmer can switch between the transformational approach and interpretive approach at any time.
Transformational
{ transformational construction, . },
{ interpreter, transformational engine, . },
{ intermediate representation/decorated syntax tree, . }
We have discussed four different groups of individual models and cited a few of the many environments
that are examples of these different models. Most research environments and many commercial
environments are instances of these individual models.
3.2 The Family Model
The family model of software development environments represents those environments that supply, in
addition to a set of program construction tools as found in an individual model, facilities that support the
interactions of a small group of programmers (under, say, 10). The analogy to the family for this model is
that the members of the family work autonomously, for the most part, but trust the others to act in a
reasonable way; there are only a few rules that need to be enforced to maintain smooth interactions among
the members of the family. It is these rules, or policies, that distinguish the individual from the family
model of environments: in the individual model, no rules are needed because there is no interaction; in the
family model, some rules are needed to regulate certain critical interactions among the programmers.
Family
{ .*, coordination policies } ,
{ ., coordination mechanisms } ,
{ ., special-purpose databases }
The characteristic that distinguishes the family model from the individual model is that of enforced
coordination. The environment provides a means of orchestrating the interactions of the developers, with
the goal that information and effort is neither lost nor duplicated as a result of the simultaneous activities of
the programmers. The structures of the individual model do not provide the necessary (but weak form of)
concurrency control. Because the individual model's structures are not rich enough to coordinate
simultaneous activities, more complex structures are required. It is these structures that dominate the
design of the environment, wherein the individual model the mechanisms dominated; the mechanisms and
policies in the family model are adapted to the structures.
We discuss four groups* of environments that are instantiations of the family model: extended toolkit
environments, integrated environments, distributed environments, and project management environments.
The extended toolkit environments are exemplified by UNIX together with either SCCS or RCS [52]; the
integrated environments by Smile; the distributed environments by Cedar [48]; and the project management
environments by CMS.
The extended toolkit model directly extends the individual toolkit model by adding a version control
structure and configuration control mechanisms (see, for example, UNIX PWB [8]). Programmer
coordination is supported with these structures and mechanisms; enforced coordination is supplied by a
management decision to generate systems only from, for example, SCCS or RCS databases. Thus, this
kind of family environment provides individual programmers a great deal of freedom with coordination
supported only at points of deposit into the version control database. The basic mechanisms for program
construction from the individual toolkit model are retained. However, these tools must be adapted to the
family model structure as, for example, Make must be modified to work with RCS or SCCS. Alternatively,
the tools may be constructed in conjunction with a database - e.g., the Ada program support environments
(APSEs) [2].
Extended Toolkit Model =
{ ., support version/configuration control } ,
{ ., version/configuration management } ,
{ ., compressed versions, version trees }
The integrated model extends by analogy the individual language-oriented model, where the consistency
policy permeates the tools. Here consistency is maintained among the component modules in addition to
within a module. As in the individual model, the mechanisms determine consistency incrementally,
although the grain size ranges from the syntax tree nodes of the Gandalf Prototype (GP) [16] to procedures
in Smile, to entire modules in Toolpack [35] and R n [6]. This model's structure is typically a special-purpose
database, although in CLF it is generated from a specification. The structures vary in their support
from simple backup versions to both parallel and sequential versions [17, 22].
__________________
* The notation "." at the beginning of the list indicates that we include the policies, mechanisms and structures from the previous
level.
* These groupings are not necessarily mutually exclusive. In particular, either distributed or project management aspects can be
mixed and matched with either extended toolkit or integrated environments.
Integrated
{ ., enforced version control, enforced consistency } ,
{ ., version description languages, consistency checking tools } ,
{ ., special-purpose database }
The distributed model expands the integrated model across a number of machines connected by a local area
network. Additional structures are required to support reliability and high availability as machines and
network links fail. For example, Mercury [23] is a multiple-user, language-oriented environment that
depends on a special distributed algorithm that simulates a small shared memory to guarantee consistency
among module interfaces; DSEE's database [27], on the other hand, is a simple extension of Apollo's
network file system.
Distributed Model =
{ . } ,
{ ., network mechanisms } ,
{ ., distributed objects }
The project management model is orthogonal to the progression from the extended toolkit model to the
distributed model. These environments provide additional support for coordinating changes by assigning
tasks to individual programmers. In DSEE, structures and mechanisms are provided for assigning and
completing tasks that may be composed of subtasks and activities [28]. CMS adds a modification request
(MR) tracking system on top of SCCS in which individual programmers are assigned particular change
requests and the changes are associated with particular sets of SCCS versions.
Project Management Model =
{ ., support activity coordination } ,
{ ., activity coordination mechanisms } .
{ ., activity coordination structures }
The family model represents the current state of the art in software development environments. In general,
it is an individual model extended with mechanisms and structures to provide a small degree of enforced
coordination among the programmers. The policies are generally laissez faire with respect to most
activities; enforcement of coordination is generally centered around version control and configuration
management. The most elaborate instance of the family model with respect to mechanisms is DSEE; the
most elaborate with respect to structures is CLF.
3.3 The City Model
As the size of a project grows to, say, more than 20 people, the interactions among these people increase
both in number and in complexity. Although families allow a great degree of freedom, much larger
populations, such as cities, require many more rules and regulations with their attendant restrictions on
individual freedom. The freedom appropriate in small groups produces anarchy when allowed to the same
degree in larger groups. It is precisely this problem of scale and the complexity of interactions that leads us
to introduce the city model.
{ ., cooperation policies } ,
{ ., cooperation mechanisms },
{ ., structures for cooperation }
The notion of enforced coordination of the family model is insufficient when applied to the scale
represented by the city model. Consider the following analogy. On a farm, very few rules are needed to
govern the use of the farm vehicles while within the confines of the farm. A minimal set of rules govern
who uses which vehicles and how they are to be used - basically, how the farm workers coordinate with
each other on use of the vehicles. Further, these rules can be determined in real time - that is, they can be
adjusted as various needs arise or change. However, that set of rules and mode of rule determination is
inadequate to govern the interactions of cars and trucks in an average city: chaos would result without a
more complex set of rules and mechanisms that enforce the cooperation of the people and vehicles; the
alteration of rules, of necessity, has serious consequences because they affect a much larger population
(consider the problem when Europe changed from driving on the left to driving on the right side of the
road). Thus, enforced cooperation is the primary characteristic of the city model.
It is our contention that the family model is currently being used where we need a city model, and that the
family model is not appropriate for the task. Because the family model does not support or enforce an
appropriate set of policies to handle the problems incurred by an increase in scale, we generally have a set
of methodologies and management techniques that attempt to stave off the anarchy that can easily occur.
These methodologies and management techniques work with varying degrees of success, depending on how
well they enforce the necessary cooperation among developers.
Little work has been done on environments that implement a city model - that is, that enforce cooperation
among developers. We discuss two such environments: Inscape/Infuse* [37, 39] and ISTAR [10]. Infuse
focuses on the technical management of the change process in large systems whereas ISTAR focuses on
project management issues. In both cases, the concern for policies of enforced cooperation dominate the
design and implementation: in Infuse, the policy of enforced cooperation while making a concerted set of
changes by many programmers has led to the exploration of various structures and mechanisms; in ISTAR,
the contractual model and the policies embodied in that model dominate the search for project management
structures and mechanisms.
The primary concern of Infuse is the technical management of evolution in large systems - that is, what
kinds of policies, mechanisms and structures are needed to automate support for making changes in large
systems by large numbers of programmers. Infuse generalizes Smile's experimental databases into a
hierarchy of experimental databases, which serves as the encompassing structure for enforcing Infuse's
policies about programmer interaction. These policies enforce cooperation among programmers in several
ways [24].
. Infuse automatically partitions the set of modules involved in a concerted set of changes into a
hierarchy of experimental databases on the basis of the strength of their interconnectivity (this measure
is used as an approximation to the oracle that tells which modules will be affected by which changes).
This partitioning forms the basis for enforcing cooperation: each experimental database proscribes the
limits of interaction (however, see the discussion of workspaces below).
. At the leaves of the hierarchy are singleton experimental databases where the actual changes take place.
When the changes to a module are self-consistent it may be deposited into its parent database. At each
non-leaf database, the effects of changes are determined with respect to the components in that
partition, that is, analysis determines the local consistency of the modules within the database. Only
when the modules within a partition are locally consistent may the database be deposited into its parent.
This iterative process continues until the entire system is consistent.
. When changes conflict, the experimental database provides the forum for negotiating and resolving
those conflicts. Currently, there are no formal facilities for this negotiation, but only the framework for
it. Once the conflicts have been resolved, the database is repartitioned and the change process repeats
__________________
* Infuse originated as, and still is, the change management component of the Inscape Environment (which explores the use of formal
interface specifications and of a semantic interconnection model in the construction and evolution of software systems). However,
the management issues of how to support a large number of developers are sufficiently orthogonal to the semantic concerns of
Inscape to be applicable in a much wider context (for example, to environments and tools supporting a syntactic interconnection
model) and to be treated independently.
for that (sub-) partitioning.
. Because the partitioning algorithm is only an approximation of the optimal oracle, Infuse provides an
escape mechanism, the workspace, in which programmers may voluntarily cooperate to forestall
expensive inconsistencies at the top of the hierarchy.
Thus the rules for interaction are encoded in the mechanisms, with the hierarchy providing the supporting
structure*.
Infuse
{ ., enforced and voluntary cooperation } ,
{ ., automatic partitioning,
local consistency analysis,
database deposit,
local integration testing,
. } ,
{ ., hierarchy of experimental databases }
Whereas Infuse is concerned with the technical problems of managing system evolution, ISTAR is
concerned with the managerial problems of managing system evolution. ISTAR is an integrated project
support environment (IPSE) [29] and seeks to provide an environment for managing the cooperation of
large groups of people producing a large system. To this end, it embodies and implements a contract model
of system development. ISTAR does not directly provide tools for system construction but instead supports
"plugging in" various kinds of workbenches. The contract model dictates the allowable interactions among
component developers [47].
. The client specifies the required deliverables - that is, the products to be produced by the contractor.
Further, the client specifies what the terms of satisfaction are for the deliverables - that is, the specific
validation tests for the products.
. The contractor provides periodic reporting about the status of the project and the state of the product
being developed. Clients are thus able to monitor the progress of their contracts.
. ISTAR provides support for amending the contracts as the project develops. Thus, the contract
structure can change in the same ways that the products themselves can change.
. A contract database provides the underlying structure for this environment.
Thus the interactions between the clients and the contractors are proscribed by the underlying model and
the mechanisms in the environment enforce those rules of interaction. The exact interaction of tools in the
construction of the components of the system is left unspecified, but the means of contracting for
components of a system are enforced by the environment.
{ ., contract model } ,
{ ., contract support tools } ,
{ ., contract data base }
__________________
* We are also investigating the utility of this structure for cooperation in integration testing. With a notion of local integration testing
analogous to our notion of local consistency checking, we expect to be able to assist the integration of changes further by providing
facilities for test harness construction and integration and regression testing within this framework.
3.4 The State Model
Pursuing our metaphor leads to the consideration of a state model. Certainly the notion of a state as a
collection of cities is suggestive of a company with a collection of projects. There are, we think,
intimations of this model in the following: the Department of Defense standardizing on one particular
language, Ada, for all its projects; a company trying to establish a uniform development environment such
as UNIX for all its projects; a company establishing a common methodology and set of standards to be
used on all its projects. It is easy to understand the rationale behind these decisions: reduction in cost and
improvement in productivity. If there is a uniform environment used by several projects, developers may
move freely between projects without incurring the cost of learning a new environment. Further, reuse of
various kinds is possible: tools may be distributed with little difficulty; code may be reused; design and
requirements may be reused; etc.
{ ., commonality policies } ,
{ ., supporting mechanisms } ,
{ ., supporting structures }
In this model, the concern for commonality, for standards, is dominant. This policy of commonality tends
to induce policies in the specific projects (or, in their city model environments). Thus, the policies of the
state model are higher-order policies because they have this quality of inducing policies, rather than
particular structures and mechanisms.
While one can imagine the existence of instances of this model (and there are certainly many cases where it
is needed), we do not know of one. Our intuition* suggests the following general description.
. Provide a generic model with its attendant tools and supporting structures for software development to
be used throughout a particular company.
. Instantiate the model for each project, tailoring each instance dynamically to the particular needs of the
individual project.
. Manage the differences between the various instances to support movement between projects.
Thus, while little is known about the state model, it appears to be a useful and fruitful area for investigation.
Scaling Up from One Class to the Next
Ideally, scaling up from one class to the next would be a matter of adding structures and mechanisms on top
of an existing environment. In at least one case this has been done without too much difficulty: scaling up
from the individual toolkit model to the family extended toolkit model. This example involves only a small
increment in policy.
It is extremely attractive to think of the higher-level models as using the lower-level models as components
upon which to establish new policies, mechanisms and structures. Unfortunately, there are several
difficulties. First, there is the problem of the tightness of coupling between structures and mechanisms.
Even in scaling up from the toolkit to the extended toolkit environments, retrofitting of old tools to new
structures is necessary. This raises the fundamental question of whether it is more profitable to retrofit
changes into the system or to reconstruct the entire environment from scratch. For example, environment
generators assume a common kernel that is optimized for a specific model, and often a particular group
within the model. Consequently, they are difficult to scale up. Mercury scales up the Synthesizer Generator
by extensive modifications to its common kernel rather than by adding something to coordinate generated
editors. Infuse provides another example: since it is a direct generalization of Smile, we initially attempted
__________________
* See various position papers and discussions in the 3rd International Software Process Workshop [11].
to extend Smile's implementation. This strategy failed and the current implementation is completely
independent of Smile.
Second, problems arise from the lack of structures and mechanisms in the base-level environment suitable
for the next level. For example, multiple-user interpretive environments are extremely rare. Further, this
lack of suitable structures and mechanisms is particularly important in moving from the family model to the
city model where enforcement is a much more serious issue. Building security measures on top of a
permissive environment (such as UNIX) is particularly difficult; it is too easy to subvert the enforcement
mechanisms.
Last, there is the problem of how well the granularity of the structures and the mechanisms of one level
lend themselves to supporting the next level. For example, the file system in the toolkit approach is easily
adapted to the extended toolkit. However, some of the higher-level structure of the extensions is embedded,
by convention, within the lower-level structure, as in SCCS where version information is embedded by an
SCCS directive within the source files.
Note that most of our examples illustrating scaling difficulties are, of necessity, from the individual to the
family model. Since this increment is much smaller than from family to city, we can expect greater
obstructions in scaling from the family to the city model.
The fundamental source of these various problems lies in the fact that the policies, mechanisms, and
structures required for the higher levels of environments are, in some sense, more basic and must be
designed in rather than just added on.
4. Contributions
A substantial part of our research focuses on the problems of large-scale systems. This led us to consider
why existing environments are inadequate for solving these problems. In order to characterize and compare
environments with respect to their suitability to large-scale systems, we developed our model of software
development environments and introduced our metaphorical classification scheme. We summarize our
contributions as follows:
. Our general model distinguishes precisely those aspects of an environment that are useful in evaluating
software development environments: policies, mechanisms and structures.
. Our taxonomy delineates four important classes of interaction among software developers with respect
to the problems of scale.
. The individual and family models represent the current state of the art in software development
environments. We explain why these two models are ill-suited for the development of large systems.
. We show that the city model introduces the qualitative differences in the policies, structures and
mechanisms required for very large software development projects.
. We propose a state model, which is in need of further clarification, understanding and implementation.
We conclude that there is a pressing need for research in both the technical and managerial aspects of city
model environments and in the delineation of the state model.

Acknowledgements

For their careful readings and critical comments: Dave Belanger, Craig Cleveland, Narain Gehani, Warren
Montgomery, Peggy Quinn, and Maria Thompson. For their helpful comments and discussions: Bob
Balzer, Lori Clarke, Larry Druffel, Bob Ellison, Peter Feiler, Nico Habermann, Jack Wileden, and Alex
Wolf.
Professor Kaiser is supported in part by grants from AT&T Foundation, IBM, Siemens Research and
Technology Laboratories, and New York State Center of Advanced Technology - Computer and
Information Systems, and in part by a Digital Equipment Corporation Faculty Award.



--R

"Database System Support for Software Engineering"
"Rationale for Stoneman"
"Program Refinement by Transformation"
"The Entity-Relationship Model - Toward a Unified View of Data"
"Automatic Compilation of Logical Specifications into Efficient Programs"
"The Impact of Interprocedure Analysis and Optimization in the R n Programming Environment"
"Programming-in-the-Large Versus Programming-in-the- Small"

"Programming Environments Based on Structured Editors: The Mentor Experience"
"Integrated Project Support with IStar"

"An Incremental Programming Environment"
"Make - A Program for Maintaining Computer Programs"
"Views for Tools in Integrated Environments"

"Gandalf: Software Development Environments"
"System Composition and Version Control for Ada"
"Contemporary Software Development Environments"
"An Introduction to the C shell"
"An Architecture for Intelligent Assistance in Software Development"
"Intelligent Assistance without Artificial Intelligence"
"An Environment for System Version Control"
"Multiuser, Distributed Language-Based Environments"
"Workspaces and Experimental Databases: Automated Support for Software Maintenance and Evolution"
"The UNIX Programming Environment"
"IDL: Sharing Intermediate Representations"
"Parallel Software Configuration Management in a Network Environment"
"Computer-Aided Software Engineering in a Distributed Workstation Environment"
"Essential Properties of IPSEs"
"Controlling the Evolution of Large Scale Software Systems"
"Toward a Persistent Object Base"
"The GANDALF Project"
The Multics System: An Examination of Its Structure
"Software Processes Are Software Too"
"Toolpack - An Experimental Software Development Environment Research Project"
"Prototyping a Project Master Database for Software Engineering Environments"
"Software Interconnection Models"
"Version Control in the Inscape Environment"
"Infuse: A Tool for Automatically Managing and Coordinating Source Changes in Large Systems"
"A Conceptual Programming Environment"
"The Synthesizer Generator"
"The Source Code Control System"
"The 3B20D Processor & DMERT Operating System: Software Devlopment System"
"Software Development and Inferential Programming"
"The Management of Changing Types in an Object-Oriented Database"
"Research on Knowledge-Based Software Environments at Kestrel Institute"
"An Introduction to ISTAR"
"A Structural View of the Cedar Programming Environment"
"Arcadia: A Software Development Environment Research Project"
"The Cornell Program Synthesizer: A Syntax-Directed Programming Environment"
"The Interlisp Programming Environment"
"RCS - A System for Version Control"

--TR
Generating language-based environments
SMALLTALK-80: the interactive programming environment
RCSMYAMPERSANDmdash;a system for version control
Automating the transformational development of software
Research on knowledge-based software environments at Kestrel Institute
A structural view of the Cedar programming environment
The impact of interprocedural analysis and optimization in the R<sup>n</sup> programming environment
Generating editing environments based on relations and attributes
Gandalf: software development environments
Systematic software development using VDM
A shared, segmented memory system for an object-oriented database
IDL: sharing intermediate representations
Prototyping a project master database for software engineering environments
Worlds: an organizing structure for object-bases
A graphical, extensible integrated environment for software development
Essential properties of IPSEs
Common LISP: the language
Software development environments
ANNA, a language for annotating Ada programs: reference manual
Software processes are software too
Software interconnection models
Database system support for software engineering
Incremental data-flow analysis algorithms
Automatic Programming
The Programmer''s Apprentice
The synthesizer generator: a system for constructing language-based editors
The evaluation of program-based software test data adequacy criteria
Foundations for the Arcadia environment architecture
The ergo support system: an integrated set of tools for prototyping integrated environments
A software development environment for law-governed systems
Pgraphite: an experiment in persistent typed object management
A unifying model for consistent distributed software development environments
Object management issues for software engineering environments workshop report
An overview of DOD-STD-1838A (proposed) the common APSE interface set: revision
An overview of PCTE and PCTE+
Integrating noninterfering versions of programs
The inscape environment
Object management in a CASE environment
Configuration management in BiiN SMS
The interface description language: definition and use
Software process models and programs: observations on their nature and context
Adequate testing and object-oriented programming
A comparative evaluation of object definition techniques for large prototype systems
A metaphor and conceptual architecture for software development environments
The entity-relationship modelMYAMPERSANDmdash;toward a unified view of data
Augmenting Parsers to Support Incrementality
Infuse
Contemporary software development environments
Characterizing the Software Process
Intelligent Assistance for Software Development and Maintenance
Views for Tools in Integrated Environments
Toward a Persistent Object Base
Program refinement by transformation
Graphical program development with PECAN program development systems
Computer-Aided Software Engineering in a distributed workstation environment
Implementing relational views of programs
Document structure and modularity in mentor

--CTR
Arun Sen, From DSS to DSP: a taxonomic retrospective, Communications of the ACM, v.41 n.5es, May 1998
Rakesh Agarwal , Patricia Lago, PATHOSa paradigmatic approach to high-level object-oriented software development, ACM SIGSOFT Software Engineering Notes, v.20 n.2, p.36-41, April 1995
Alfonso Fuggetta, A Classification of CASE Technology, Computer, v.26 n.12, p.25-38, December 1993
Christopher M. Lott, A Controlled Experiment to Evaluate On-Line Process Guidance, Empirical Software Engineering, v.2 n.3, p.269-289, 1997
Alan W. Brown , Maria H. Penedo, An annotated bibliography on integration in software engineering environments, ACM SIGSOFT Software Engineering Notes, v.17 n.3, p.47-55, July 1992
Nazim H. Madhavji , Kamel Toubache , Ed Lynch, The IBM-McGill project on software process, Proceedings of the 1991 conference of the Centre for Advanced Studies on Collaborative research, October 28-30, 1991, Toronto, Ontario, Canada
Dewayne E. Perry, Software evolution and light semantics (extended abstract), Proceedings of the 21st international conference on Software engineering, p.587-590, May 16-22, 1999, Los Angeles, California, United States
P. Ciancarini , C. Mascolo, Using formal methods for teaching software engineering: a tool-based approach, Annals of Software Engineering, v.6 n.1-4, p.433-453, April 1999
Christopher M. Lott, Process and measurement support in SEEs, ACM SIGSOFT Software Engineering Notes, v.18 n.4, p.83-93, Oct. 1993
Naser S. Barghouti , Gail E. Kaiser, Concurrency control in advanced database applications, ACM Computing Surveys (CSUR), v.23 n.3, p.269-317, Sept. 1991
language centered environments;toolkit environments;method-based environments;software development environments;structure-oriented environments;programming environments;sociological metaphor