A method is presented for the stepwise refinement of an abstract architecture into a relatively correct lower-level architecture that is intended to implement it. A refinement step involves the application of a predefined refinement pattern that provides a routine solution to a standard architectural design problem. A pattern contains an abstract architecture schema and a more detailed schema intended to implement it. The two schemas usually contain very different architectural concepts (from different architectural styles). Once a refinement pattern is proven correct, instances of it can be used without proof in developing specific architectures. Individual refinements are compositional, permitting incremental development and local reasoning. A special correctness criterion is defined for the domain of software architecture, as well as an accompanying proof technique. A useful syntactic form of correct composition is defined. The main points are illustrated by means of familiar archit...

Current research in specifications is emphasizing the practical use of formal specifications in program design. One way to encourage their use in practice is to provide specification languages that are accessible to both designers and programmers. With this goal in mind, the Larch family of formal specification languages has evolved to support a two-tiered approach to writing specifications. This approach separates the specification of state transformations and programming language dependen-cies from the specification of underlying abstractions. Thus, each member of the Larch family has a subset derived from a programming language and another subset independent of any programming languages. We call the former interface languages, and the latter the Larch Shared Language. This paper focuses on Larch interface language specifications. Through examples, we illustrate some salient features of Larch/CLU, a Larch interface language for the programming language CLU. We give an example of writing an interface specification following the two-tiered approach and discuss in detail issues involved in writing interface specifications and their interaction with their Shared Language components.

Abstract. Abstraction identification is named as a key problem in requirements analysis. Typically, the abstractions must be found among the large mass of natural language text collected from the clients and users. This paper motivates and describes a new approach, based on traditional signal processing methods, for finding abstractions in natural language text and offers a new tool, AbstFinder as an implementation of this approach. The advantages and disadvantages of the approach and the design of the tool are discussed in detail. Various scenarios for use of the tool are offered. Some of these scenarios were used in case study of the effectiveness of the tool on an industrial-strength example of finding abstractions in a request for proposals.

The design of a large system typically involves the development of a hierarchy of different but related architectures. A criterion for the relative correctness of an architecture is presented, and conditions for architecture composition are defined which ensure that the correctness of a composite architecture follows from the correctness of its parts. Both the criterion and the composition requirements reflect special considerations from the domain of software architecture. The main points are illustrated by means of familiar architectures for a compiler. A proof of the relative correctness of two different compiler architectures shows how to decompose a proof into generic properties, which are proved once for every pair of architectural styles, and instance-level properties, which must be proved for every architecture. 1 Introduction The development of an architecture for a large system is a complicated task that can be made simpler by means of a stepwise development methodology. Ide...

People benefit from tightly integrated systems that can be designed, realized and evolved affordably. Unfortunately, common software design methods do not easily accommodate requirements for tightly integrated systems. Indeed, when used to meet such requirements, common methods tend to yield unnecessarily complex structures that complicate design and realization and that inhibit subsequent evolution. After substantiating this claim, I present the mediator method as a solution. This method combines behavioral entity-relationship (ER) modeling for design with a mediator approach to implementation. The mediator method is better than common methods for designing, realizing, and evolving many integrated systems. I support this claim both by rational argument from simplifying models and by careful...

Software engineering focuses on producing quality software products through quality processes. The attention to processes dates back to the early 70's, when software engineers realized that the desired qualities (such as reliability, efficiency, evolvability, ease of use, etc.) could only be injected in the products by following a disciplined flow of activities. Such a discipline would also make the production process more predictable and economical.

The construction of interactive server-side Web applications differs substantially from the construction of traditional interactive programs. In contrast, existing Web programming paradigms force programmers to save and restore control state between user interactions. We present an automated transformation that converts traditional interactive programs into standard CGI programs. This enables reuse of existing software development methodologies. Furthermore, an adaptation of existing programming environments supports the development of Web programs. 1 Designing Web Programs The need for generating Web information on demand is obvious. One page may need the current time and date; another page may include results from a database query; a third page may display the current status of the server. Since such programs compute small amounts of information and produce not much more than a single Web page, people call them scripts. Following a long-standing tradition in computing, Web scripti...

Programmers confront a minefield when they design interactive Web programs. Web interactions take place via Web browsers. With browsers, consumers can whimsically navigate among the various stages of a dialog and can thus confuse the most sophisticated corporate Web sites. In turn, Web services can fault in frustrating and inexplicable ways. The quickening transition from Web scripts to Web services lends these problems immediacy.

“No scene from prehistory is quite so vivid as that of the mortal struggles of great beasts in the tar pits... Large system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it... “Everyone seems to have been surprised by the stickiness of the problem, and it is

This paper presents two fundamental arguments. Firstly, it is proposed that most of the currently-available systems development methodologies are founded on concepts which emerged in the period from about 1967 to 1977. This argument is presented through the use of literature references. The second argument is that the profile of the development environment now faced in organisations is very different from that which prevailed in the period 1967 to 1977. This is illustrated through original empirical research carried out by the author which supports this argument, and by contrasting these findings with those of previous studies in the literature. It is therefore argued that there is a need to update ‘tenses ’ by deriving new methodological canons more appropriate to the needs of the current development environment. Some suggestions for new methodological canons appropriate to the current development environment are provided.