Contact Information

Dr. Alexander Egyed
Johannes Kepler University
Altenbergerstr. 69
4040 Linz, Austria
http://www.sea.uni-linz.ac.at
email

Software Simulation and Execution

To date, software models are very specific in their support to software developers. As such they exhibit limitation ranging from inadequate constructional freedoms to insufficient analytic capabilities. Recent successes in domains like software architectures have shown that models can become more than just static pictures; models can also be made into dynamic entities (e.g., simulators) allowing more advanced reasoning. The task of creating “living models” to overcome static models is a solution to the second modeling deficiency identified previously. For instance, currently if software developers want to demonstrate some capabilities of a desired software product (e.g., the interoperability of two software components), they still need to create fast and dirty prototypes. Sometimes there are very good reasons for early prototyping but studies have shown that there is often reluctance in abandon prototypes which eventually may lead to poorly designed software systems based on un-scalable limitations of their initial prototypes. Shifting some of the emphasis of early development onto creating executable models may provide a working alternative. Executable models (e.g., state chart simulators) have the potential of allowing developers to analyze dynamic properties early on without the need for implementation. With the availability of techniques to overcome the model discontinuity, those executable models can then be synthesized to code directly, making them very cost effective design tools. As part of my more recent work, I am creating a state chart simulator. State chart modeling, as pioneered by Harel, depict evolutionary aspects of software components from their construction to their destruction. My simulator extends current ‘state of the art’ by supporting a wider range of design relevant properties such as dynamism (e.g., run-time creation and destruction of components). It is my intention to continue working on executable models as a counterpart towards traditional programming. This work may well shift the focal point of software development from programming to modeling where executable models could be seen as “model-based programming languages.” This development is analogous to programming languages that are structured around user interfaces (e.g. Powerbuilder); a development that has indeed shown benefits through that focal change. Nevertheless, structuring programs only around user interfaces (one type of concern) does not work well if multiple concerns need to be addressed at the same time. Model-based programming may allow to structure software development around multiple concerns concurrently, provided that mechanisms are in place that automatically ensure consistency between those multiple, non-orthogonal concerns while they evolve separately.

Relevant Publications

Related Research