You have roughly 40 contact hours in a typical course. If all you do in them is lecture, you might as well just hand out your notes and let the students find something more productive to do with all that time. The only way a skill is developed—skiing, cooking, writing, critical thinking, or solving thermodynamics problems—is practice: trying something, seeing how well or poorly it works, reflecting on how to do it differently, then trying it again and seeing if it works better. Why not help students develop some skills during those contact hours by giving them some practice in the tasks they’ll later be asked to perform on assignments and tests?

Learning by doing

The term model-driven engineering (MDE) is typically used to describe software development approaches in which abstract models of software systems are created and systematically transformed to concrete implementations. In this paper we give an overview of current research in MDE and discuss some of the major challenges that must be tackled in order to realize the MDE vision of software development. We argue that full realizations of the MDE vision may not be possible in the near to medium-term primarily because of the wicked problems involved. On the other hand, attempting to realize the vision will provide insights that can be used to significantly reduce the gap between evolving software complexity and the technologies used to manage complexity.

/pdf/model-driven-development-of-complex-software-a-research-1l2kfenshb.pdf

Model-driven Development of Complex Software: A Research Roadmap

data type in the sense of Hoare describes the class of admissible representations (or implementations), that a specification should define such a class rather than a single algebra, and that the abstract data type should be identified with the final algebra in this class. This idea, though not intended, gave rise to some confusion and separated those who believed in initial semantics from those who believed in final semantics. The fundamental criticism in the initial algebra approach was the following: the "abstraction-function" should map the representations to the abstract data type (which makes it final), and not the other way around. But it seems that this controversy was purely a misunderstanding (not by Wand himself), since the initial homomorphism from the initial algebra to the algebras of the specification is not intended to be the "abstraction function", nor its counter part, the "representation function". Instead it models the highly desirable property of initial algebras as realizing the specification in a certain "minimal" way, usually expressed by the principles "no confusion" and "no junk". The final algebra semantics of specifications better fits the intentions of algebraic implementations, and of "behavioral abstraction". The latter was introduced already in 1976 by Giarratana, Gimona, and Montanari (see /GGM 76/) and was motivated by the behavior notion of finite automata theory. Final algebra semantics of algebraic specification has been intensively studied by many authors (see /Kl 83/ for an overview) but is not equally unified and developed as initial algebra semantics. Beside the final algebra approach there are data type specification techniques which originate from the theory of recursive equations (see /Lo 81/, /Kl 83/, /BMSi 84/), and which are studied in view of the assertion calculus for program verification, or in respect to evaluation strategies and complexity. It was early discovered that simple algebraic specifications, which consist of listings of sort symbols, operation symbols, and equations, are in their pure f.orm not appropriate for writing down specifications of larger software systems. Roughly speaking, in this regard they correspond to assembly code and not to structured programs of high level languages. This observation gave rise to the development of the specification language CLEAR by Burstall and Goguen (see /BG 77/ and /BG 80/), which is the first specification language conceptually based on algebraic specifications and their semantics. Among others, a concept of parameterized specifications is incorporated for an appropriate structuring of larger specifications and a modular design of software systems. This first algebraic specification language has considerably influenced the development of the theory of algebraic specifications and the design of other specification languages (see the bibliographic notes in the appendix of this volume).

Fundamentals of Algebraic Specification 1

Interest is increasing in the transformational approach to programming and in mechanical aids for supporting the program development process. Available aids range from simple editorlike devices to rather powerful interactive transformation systems and even to automatic synthesis tools. This paper reviews and classifies transformation systems and is intended to acquaint the reader with the current state of the art and provide a basis for comparing the different approaches. It is also designed to provide easy access to specific details of the various methodologies.

Program Transformation Systems

Finite differencing is a program optimization method that generalizes strength reduction, and provides an efficient implementation for a host of program transformations including "iterator inversion." Finite differencing is formally specified in terms of more basic transformations shown to preserve program semantics. Estimates of the speedup that the technique yields are given. A full illustrative example of algorithm derivation is presented.

/pdf/finite-differencing-of-computable-expressions-4m5i78lx15.pdf

Finite Differencing of Computable Expressions

Formal program construction by transformations is a method of software development in which a program is derived from a formal problem specification by manageable, controlled transformation steps which guarantee that the final product meets the initial specification. This methodology has been investigated in the Munich project CIP (computer-aided intuition-guided programming). The research includes the design of a wide-spectrum language specifically tailored to the needs of transformational programming, the construction of a transformation system to support the methodology, and the study of transformation rules and other methodological issues. Particular emphasis has been laid on developing a sound theoretical basis for the overall approach. >

Formal program construction by transformations-computer-aided, intuition-guided programming

The algebraic specification of the semantics of programming languages is outlined. Particular emphasis is given to the problem of specifying least-fixed points by first-order conditional equations. To cover this issue, the theory of specifying partial heterogeneous algebras by abstract data types is slightly extended by a more general notion of homomorphism. In this framework the semantics of programming languages can be uniquely specified in a purely algebraic way, using particular models of a hierarchy of abstract types. This approach is demonstrated for a simple procedural programming language. Several increasingly complex versions of iterations are treated and analyzed with respect to their theoretical consequences. Finally, as a complementary algebraic technique, transformational semantics is explained and applied to our examples.

On the algebraic definition of programming languages

Unlike for conventional compilers for imperative programming languages such as C or ADA, no establishedmethods for safeguarding artifacts generated by model-based code generators exist despite progress in the field of formalverification. Several test approaches dominate the engineering practice. This paper describes a general and toolindependenttest architecture for code generators used in model-based development. We evaluate the effectiveness of ourtest approach by means of testing optimizations performed by the TargetLink code generator, a widely accepted andcomplex development tool used in automotive model-based development.

Systematic Testing of Model-Based Code Generators

The algebraic programming language OPAL has been designed as a testbed for experiments with the specification and development of functional programs. The language shall in particular foster the (formal) development, of productionquality software that is written in a purely flmctional style. As a consequence, OPAL molds concepts from Algebraic Specification and Functional Programming into a unified framework. The amalgamation of these two concepts which are both based on a sound theoretical foundation constitutes an ideal setting for the construction of formally verified "safe" software. Moreover, the high level of abstraction and the conceptual clarity of the functional style can increase the productivity of software development significantly. Unfortunately, the acceptance of the functional style suffers from the widespread prejudice that its advantages are paid for by a high penalty in runtime and storage consumption. Yet, this is not, true. Due to their semantic elegance and clarity, functional programs are amenable to a wide variety of powerful optimizations, such that the programmer need not be concerned with low-level considerations about machine pecularities. This way, she can concentrate on finding good algorithmic solutions instead. The potential for automatic optimizations is highly increased, when functional programs are combined with algebraic specifications. Then, algebraic properties of the flmctional programs can be used to guide optimizations which go far beyond traditional optimization techniques. In this paper we illustrate some principles of algebraic programming. Moreover, we introduce the language OPAL, sketch its compilation strategies, and point out some challenges for further research in the area of algebraic programming languages.

Peter Pepper

Papers

Formal program construction by transformations-computer-aided, intuition-guided programming

On the algebraic definition of programming languages

Systematic Testing of Model-Based Code Generators

OPAL: design and implementation of an algebraic programming language

Algebraic implementations preserve program correctness