Martin S. Feather

Reconciling system requirements and runtime behavior

This paper considers the problem of system deviations from requirements specifications. Such deviations may arise from lack of anticipation of possible behaviors of environment agents at specification time, or from evoking conditions in this environment. We discuss an architecture and a development process for monitoring system requirements at runtime to reconcile the requirements and the systems behavior. This process is deployed on three scenarios of requirements-execution reconciliation for the Meeting Scheduler system. The work builds on our previous work on goal-driven requirements engineering and on runtime requirements monitoring.

Language support for the specification and development of composite systems

When a complex system is to be realized as a combination of interacting components, development of those components should commence from a specification of the behavior required of the composite system. A separate specification should be used to describe the decomposition of that system into components. The first phase of implementation from a specification in this style is the derivation of the individual component behaviors implied by these specifications.nThe virtues of this approach to specification are expounded, and specification language features that are supportive of it are presented. It is shown how these are incorporated in the specification language Gist, which our group has developed. These issues are illustrated in a development of a controller for elevators serving passengers in a multistory building.

A System for Assisting Program Transformation

Program transformation has been advocated as a potentially appropriate methodology for program development. The ability to transform large programs is crucial to the practicality of such an approach. This paper describes research directed toward applying one particular transformation method to problems of increasing scale. The method adopted is tha t developed by Burstall and Darlington, and familiarity with their work is assumed. The problems which arise when attempting transformation of larger scale programs are discussed, and an approach to overcoming them is presented. Parts of the approach have been embodied in a machine-based system which assists a user in transforming his programs. The approach, and the use of this system, are illustrated by presenting portions of the transformation of a compiler for a toy language.

Utilizing Scenarios in the Software Development Process

Abstract Scenarios play an important role throughout the information system development process. Scenarios are partial descriptions of system and environment behavior arising in restricted situations . They are instrumental to the following activities: describing and clarifying the relevant properties of the application domain, uncovering system requirements, evaluating design alternatives, and validating designs. This paper will describe these roles in the context of an example and explain how computer-based tools can support the use of scenarios throughout the development process. The thesis of this paper is based on experience with three such computer-based tools.

Detecting interference when merging specification evolutions

We have been studying a model of software specification design which begins with a trivially simple specification, incrementally elaborates it in a number of parallel “lines” of design, and merges the specifications that result from each of those divergent lines to achieve the fully detailed specification. We employ “evolutionary” transformations that is, transformations whose very purpose is to change meaning to perform the elaborations in the design lines, and thereafter achieve merging by replaying the transformations in a serial order. Merging does not always proceed smoothly: on occasions the different lines of design interfere with one another in some manner, inhibiting the serial replay of their evolutionary transformations. We show that by comparing how the transformations change specification properties (herein we consider the properties of terminology and usage), certain kinds of interference can be detected, and in some cases means to deal with it suggested. L Specification evolution via transformation While traditionally the software design process has started with a specification and worked towards an implementation, we have come to believe that the construction of the starting specification is also an important and complex design process. We have studied a process in which specification construction is incremental the specification is gradualiy evolved from a trivially simple starting point by means of a series of evolutionary steps. We have built mechanisms for performing these via “evolutionary transformations”, akin to the transformations of conventional program transformation work, except they deliberately change the meaning of the specifications to which they are applied. In contrast, conventional transformations generally keep the meaning of the specification constant (so called “correctness-preserving”) while improving efficiency (sometimes they “shrink” the meaning, i.e., when the initial specification admits to alternative implementations, the transformations may be 01969 ACM 0-69791~305-1/69/0500/0169

The KBSA Requirements/specification Facet: ARIES

00.75 allowed to select from among those, but in any event they never introduce new possibilities). Similar research has been done in the area of modifications to type lattices and database schemes: in (21 a classification of possible changes to a type lattice is given, and used to suggest means for adapting existing data and operations on that data accordingly. Similar changes are considered in [lo], where the focus is on constructing methods to handle clashes between objects and programs created under different versions of the type lattice. Recently in (61 it is argued that several machine learning techniques can help in the task of making these same kinds of modifications to databases. 1.1 Parallel lines of design We found that different evolution steps are often independent, or nearly so. This prompted us to apply those steps in parallel, giving rise to several different lines of design. The specifications that result from each line of design must thereafter be merged. Since the different specifications have been obtained by applying series of evolutionary transformations, we obtain the merge of those specifications by applying the same transformations in series. A more complete description of the overall approach may be found in [4]. The aspect that is of interest here is the desire to pursue separate lines of design independently, and thereafter merge their results. The ability to do this would have several beneficial characteristics: l separation of concerns: the details introduced by one evolution can be ignored while conducting another evolution, l distributed development: several people may independently evolve the same initial specification in different ways, and thereafter have their versions merged, and l explicit combination: when the different lines of design are not completely independent, this will be recognized and dealt with explicitly at the time of merging. 12 Other work on meraine; L--_ Previous work toward merging has addressed the merging of programs expressed in simplified languages, and concentrated

A model for composite system design

This paper describes a transformation-based software environment which supports the acquisition and validation of software requirements specifications. These requirements may be stated informally at first, and then gradually formalized and elaborated. The environment assists in the validation of formalized requirements by translating them into natural language and graphical diagrams, and testing them against a running simulation of the system to be built. Requirements defined in terms of domain concepts are transformed into constraints on system components. The advantages of this approach are that specifications can be traced back to requirements and domain concepts, which in turn have been precisely defined.

Integrating Domain Knowledge, Requirements, and Specifications

Composite systems are systems that encompass multiple agents involved in ongoing, interactive activities. The authors study requirements acquisition, specification and design of such systems. The research objective is a model that encompasses this entire design activity, and thereafter, techniques and tools called for by the model, which will serve to provide automated assistance to a skilled designer of composite systems. The authors outline the proposed model that they have established so far, together with the experimental pieces of technology that they are assembling.<<ETX>>

Mappings for rapid prototyping

This paper describes efforts to develop a transformation-based software environment that supports the acquisition and validation of software requirements specifications. These requirements may be stated informally at first, and then gradually formalized and elaborated. Support is provided for groups of requirements analysts working together, focusing on different analysis tasks and areas of concern. The environment assists in the validation of formalized requirements by translating them into natural language and graphical diagrams and testing them against a running simulation of the system to be built. Requirements defined in terms of domain concepts are transformed into constraints on system components. The advantages of this approach are that specifications can be traced back to requirements and domain concepts, which in turn have been precisely defined.

Towards a derivational style of distributed system design — An example

The transformational methodology for software development is adapted to perform rapid conversion of specifications into prototypes. This makes feasible testing of specifications to observe their behaviours and assuring that specifications can indeed be implemented.The approach is centered on gathering techniques to map each type of specification language construct into a reasonably efficient implementation. Instances of these constructs in an actual specification may then serve as the focal points for the conversion process.