Behavioral requirements engineering of large-scale software systems, using current Formal Description Techniques (FDT), is complex and difficult. In Statecharts, this complexity is evident in the form of a blow-up in the number of states and difficulty of managing the name space. We have introduced a notation, called Viewcharts, which reduces the complexity of expressing behavioral requirements of large systems. Viewcharts extends Statecharts to include behavioral views and their composition. In this paper we present an overview of the Viewcharts notation and establish its semantics via translation to Statecharts.

This paper is concerned with the problem of communicating abstract data type (ADT) values in heterogeneous distributed programs. It focuses on addressing two fundamental issues of the problem: the selection of suitable exchange representations and the generation of data converters. Exchange representations are the ways to represent data during transmissions across networks. Data converters are programs transforming data from one representation to another; they are the major facility to deal with heterogeneity in a communication. This paper reports the following results: a term-based exchange representation, which is an abstract notation and so is particularly suitable for communicating ADT values in heterogeneous programs; and methods to generate data converters.>

How should iterators be abstracted and encapsulated in modern imperative languages? We consider the combined impact of several factors on this question: the need for a common interface model for user defined iterator abstractions, the importance of formal methods in specifying such a model, and problems involved in modular correctness proofs of iterator implementations and clients. A series of iterator designs illustrates the advantages of the swapping paradigm over the traditional copying paradigm. Specifically, swapping based designs admit more efficient implementations while offering relatively straightforward formal specifications and the potential for modular reasoning about program behavior. The final proposed design schema is a common interface model for an iterator for any generic collection.>

Trace assertion specification methods constrain behaviour at the interface of a module by identifying legal sequences is its equivalent normal/canonical form.

Iterators are defined, and previously published methods for defining their meanings are outlined. It is shown how to use trace specifications to define a common form of iterator module (Alphard-style iterators). A form of specification for an iterator is shown which can capture the key differences between a set and a sequence at a few particular places in the specification. The trace specification of a sequence iterator is compared to an algebraic specification. It is concluded that the algebraic specification is possible but somewhat clumsier. Traces are used to give partial specifications of iterator construct that make sequences of calls on procedural parameters.>

IDL (Interface Description Language) is a practical and useful tool for controlling the exchange of structured data between different components of a large system. IDL is a notation for describing collections of programs and the data structures through which they communicate. Using IDL, a designer gives abstract descriptions of data structures, together with representation specifications that specialize the abstract structures for particular programs. A tool, the IDL translator, generates readers and writers that map between concrete internal representations and abstract exchange representations.

We give a technique for partially simulating procedure variables using Ada tasks. The simulation involves using interface tasks, a technique which may be useful for other problems.

Abstract The design and construction of a peephole optimizer is described. The optimizer consists of a database of patterns, a translator that translates the patterns into an implementation language, and a pattern‐matcher skeleton into which the generated pattern code is inserted. it is argued that this three‐part split is a good way to approach the construction of certain kinds of programs.