Abstract not found

Introduction Software systems come and go through a series of passages that account for their inception, initial development, productive operation, upkeep, and retirement from one generation to another. This article categorizes and examines a number of methods for describing or modeling how software systems are developed. It begins with background and definitions of traditional software life cycle models that dominate most textbook discussions and current software development practices. This is followed by a more comprehensive review of the alternative models of software evolution that are of current use as the basis for organizing software engineering projects and technologies. Background Explicit models of software evolution date back to the earliest projects developing large software systems in the 1950's and 1960's (Hosier 1961, Royce 1970). Overall, the apparent purpose of these early software life cycle models was to provide a conceptual scheme for rati

L’algèbre relationnelle abstraite est utilisée pour donner une définition sémantique d’un langage de programmation impératif simple. A cet effet, divers domaines sont spécifiés par des axiomes relationnels. Certaines spécifications définissent des relations sur les types de base du langage (Booléens et entiers non négatifs); leur présentation insiste sur l’importance de la notion de point. Les autres spécifications construisent les domaines dont les relations sont utilisées pour dénoter les fragments de programmes. Les fragments ainsi traités sont les expressions, les déclarations de variables, les instructions (affectation, séquence, condition et itération) et les procédures. Les relations qui dénotent un frag-ment dépendent seulement de ce fragment et non de son environnement (à l’exception des procédures), ce qui constitue une approche originale. Enfin, on montre comment prouver la correction d’un fragment, relativement à une spécification, en utilisant sa définition sémantique. Les spécifications, la sémantique et la dérivation de programmes sont donc traitées uniformément dans le cadre de l’algèbre relationnelle abstraite. i Abstract relational algebra is used to define the semantics of a simple imperative language. In order to carry out this task, various domains are specified by relational axioms. Some specifications define relations on the basic types of the language (Booleans and natural numbers); their presentation stresses the importance of the concept of point. Other spec-ifications construct the relational domains whose relations are used to denote programs. The programming constructs that are defined include expressions, variable declarations, assignment statements, while-program statements and procedures. A particularity of the semantic definitions is that the relations denoting a program fragment depend only on the fragment, and not on its environment (procedure calls excepted). Finally, it is shown how the semantics of a program fragment can be used to prove its correctness relative to a specification. The result is a uniform abstract relational setting for specification, semantics and program derivation. ii

The safety aspects of computer-based systems as increasingly important as the use of software escalates because of its convenience and flexibility. However the complexity of even modestly sized programs is such that the elimination of errors with a high degree of confidence is extremely difficult. There are a number of approaches to enhancing safety in safety-critical control systems. These are surveyed and compared with particular emphasis on systems with software in the controlling system. A glossary of terms and an extensive bibliography for further reading are included.

Functional correctness is a technique for deriving a program and proving that this program meets its specifications. Both a program and its specifications are viewed as &nctions. Using techniques based upon symbolic execution and denotational semantics, a proof methodology has been developed. This current paper extends this theory of functional specifications which then permits us to model various life cycle methods in a consistent manner. Given several possible implementations for a given specification, we then develop techniques for evaluating one implementation over another.

Abstract not found

This document is out of date and may contain errors! Some of the approaches described have been abandoned, and others have been extended and improved. Read at your own risk.