Areas of Interest
Motivation
In 1968 the NATO Science Committee held a conference in Garmisch (Germany), which is now generally referred to as the origin of the term (and the discipline) of "Software Engineering". This slogan has been put on the schedule as a provocation as, then, it was understood as a contradiction in terms.
Looking at the conference proceedings, one will find that the participants had ardent debates on whether or not to carry on using Assembler languages or replace them by high-level languages like Pascal. The main argument against Pascal and its kin was inefficient program execution. Inefficient program production, on the other hand, attracted much less attention. Today, such a discussion would be regarded quite futile- or would it?
Today, we are at a similar turning point in the history of Computer Science: we are facing the imminent replacement of conventional programming languges by diagrammatic design languages. Pascal and its descendants (like C++, Eiffel, Ada, Java) are being superseeded ba a novel class of languages like ROOM, SDL, and UML. This new generation of "programming languages" comes with the promise of a true quantum leap in productivity, maintainability and quality of complex software systems. And this time, in contrast to the transition from imperative-procedural to imperative-object oriented languages, this promise is realistic, as experiences from from Telecommunications and embedded Systems show (e.g. SDL/ObjectGeode, ROOM/ObjecTime Developer Toolset, StateCharts/Rhapsody, Petrinets/Artifex)
Of course, there will always be niches for programming languages like Java - just as today there are still applications for Assembler languages. The vast majority of application software systems however, will be created on a higher level of abstraction.
This leap forwards in software technology will substantially impact almost all areas of software production. In the following, some of these areas are discussed. It is these that my work focuses on. Some of them have already been addressed exhaustively in my Dissertation, some are as yet mostly uncharted territory.
Aspects
Software Architecture
A more abstract programming language also raises awareness of more abstract program structures: the architecture of software systems. This has been abused as a buzzword sfor some time, but what it really means, what effects it will have, and how we go about using and exploiting it is so far either completely unknown, or only discussed in academia. Generally accepted concepts and notations; powerfull, accessible and usable tools for software architecture are nowehere to be seen. Thus, software architecture is but a fancy buzzword so far.
Reuse, Components
One aspect closely realted to software architecture, is that of reuse of software components. In analogy to electrical engineering, the software engineer would like to have catalogs of components that could be ordered and used "off-the-shelv". For software components this has so far not been achieved, mainly for commercial reasons. If there are to be software componenets in the true sense of the word, two prerequisites are necessary: on the one hand, such a component has to guarantee certain properties under well-defined and liberal context conditions. On the other hand the component has to be described in an abstract way so that the benefit of reusing a component exceeds the effort.
Maintenance
Another aspect is that of maintenance, that is, correction of faults and functional evolution of software systems. This really is the dual of reuse: large parts of a system remain unchanged (are being reused), and changes are made only to one or a few components. While reusing a components requires that it be protected from the context, in making changes it is imperative to keep these changes and their impact local, in other words, to protect the rest of the system from them. Again, an abstract representation of the system is indispensable to actually achieve increased productivity and quality.
Software Process
Obviously, focusing on a system´s architecture fundamentally changes the way we go about designing and creatig a system. Today, UML und Catalysis claim quite self-importantly to be "architekture centric" und "component-based" - only in reality, there is little to justify these claims. There is a large body of research and practical experience on the process aspect of reuse, component procurement and architecture design, but so far, these exist only in isolation, and without much common ground.
Automated Software Engineering (ASE)
Just like it has been vital for the success of, say, Pascal, to have available powerful compilers, the success of UML in replacing conventional programming languages depends strongly on the availabiltiy of novel and catholic tools. The functionalities available today are far from adequate: beyond simple editors, and simulators, we need design debuggers and code generators. We need support for the exchangeof models, for animation of simulations, and for measuring designs.
Unified Modeling Language (UML)
Today, the UML is already "the lingua franca of the Software Engineering community". All other contenders have been supplanted by or integrated into the UML. For some time to come, there will be no other, independent alternative to the UML. There will probably be dialects and variants of UML ("a family of languages"), but they all will be descendants of UML. Admittedly, there are still a number of serious shortcomigs and inconsistencies of the UML, but compared to all its predecessors it offers a comprehensive and relatively tightly integrated conceptual system with broad industrial and academic support. Therefore, the UML is the natural starting point for reviving the vision of Computer Aided Software Engineering - and this time, to go all the way.
Vision
From these observations emanates the vision of integrated development environments for the production of software based on diagrammatic designs (Computer Aided Software Engineering - CASE) as follows:
Starting from an architectural design represented as an ensemble of UML diagrams, the feasibility of the design is assessed. This includes simplc consistency checks, but also extends to complex semantics analyses, e.g. behavioral properties like deadlocks and fairness. Also, load analyses may be carried out to evaluate usage profiles and potential bottlenecks. From this design, a first prototype is generated automatically. Manual additions are only necessary at certain critical spots. All changes made there are either mapped back into the design automatically, or are encapsulated in special components to be used as is.
This vision has been developed for the first time in the context of the structured methods of the seventies. Back then, several vital points have been neglected, however, leaving this powerful vision spread-eagled. For instance, there was an incomplete appreciation of the nature of software as a kind of living, developing organism. The software process had been understood only sketchily, expressive notations and concepts were missing. More on the technical side, there wer no graphical user interfaces, no semantic databases, no middleware for transparent distribution and many more, which today we regard as sound technology.
Finally and most importantly, there was a highly segmented market of of modelinglanguages and methods, so that the production of high-performance tools for any single segment was not commercially viable. Thus, it was not technically (and commercially) sensible for users to actually use these tools, so the overall market remained small and so on.
This is now all gone: in the last 20 years, there ahs been a great deal of progress. There is now only one relevant modeling language, the UML, it offers a multitude of expressive notations based on an integrated conceptual framework, and there is now the technological basis needed. Consequently, there has been an exponential growth in the UML tools market. In other words: the Vision of CASE is already becoming reality, step by step.
Some links for further reading.
Harald Störle