THE PROBLEM

The ultimate purpose of software engineering and computer science is to produce better, cheaper software. In this context software refers to a running system. The production of high-level source code is a possible but not necessary intermediate step. Better encompasses all qualitative aspects such as correctness, efficiency and so on. Cheaper refers to the overall cost of a software system including production, deployment, and maintenance.

Theoretical problems such as models for component composition, better theorem proving technology, formalized requirements analysis and the like, are important elements of a solution. The question is how best to make them practical.

Software engineers, desperate for automation, often create ad-hoc solutions without any formal basis. For example, the need to structure and organize complex software systems has lead to the creation and success of UML. The question is how best to put these tools on a rigorous formal basis.

There is an impressive list of projects that use formal methods [1]. Yet most of the examples cited required extensive hand-holding by researchers and do not represent successful theory in wide-spread use. Examples of formal methods in common use are more modest and include grammars, supported by parser generators, and finite state machines [7].

Why does computer science not have a larger impact on software engineering practices? Clearly, there are many theories that should be valuable and useful in practice and there are many practical tools that

There is a big communication gap between theoreticians and practitioners. For the theoretician programs are mathematical objects that never fail if we can just get their specification right and verify the code. For the practitioner formal methods use obscure notation, deal with toys examples, and will never scale. Software engineers are faced with daunting management, version control, and similar problems and must constantly make engineering tradeoffs to meet tight deadlines and market windows - computer scientists know little of that. Computer scientists create wonderful theories, concepts and abstractions - software engineers understand little of that.

Transitioning science to engineering is not just a technical problem but is mainly an educational, social, managerial problem.

Educational:

Software engineers could make use of many theoretical results if they knew how to do so. But we don't speak the same language. The presentation of research results is geared toward peer review not towards technology transition.

Social:

Software engineers are reluctant to take outside advice. After all they manage to build complex systems. Who likes to be told that some of his expertise can be replaced by a program?

Managerial:

Processes and procedures for software construction have evolved over many years and are firmly entrenched in organizations. Any change will be perceived as risky and is likely rejected.

This paper describes an example of successful technology transfer based on an intelligent translator for a domain-specific specification language and lessons learned. Translators for very high-level languages provide a vehicle for making complex, formally-based tools accessible to the engineering community. Indeed, special-purpose languages suggest a new paradigm of software development by empowering engineers in other disciplines to describe (aka program) solutions to their computational and control problems.