Checking consistency between design documentation and source code; Gurcan Gulesir (UT)
The development and maintenance of today’s software systems is an increasingly effort-consuming and error-prone task. A major cause of this problem is the lack of formal and human-readable documentation of software design. In practice, software design is often informally documented (e.g. texts in a natural language, ‘boxes-and arrows’ diagrams without formal syntax and semantics, etc.), or not documented at all. Therefore, the design cannot be properly communicated between software engineers, it cannot be formally analyzed, and the conformance of an implementation to the design cannot be formally verified. A solution that consists of a graphical language and tooling to check the consistency between design and source code will be presented.

The Gap Between Specification and Design; Stephen J. Mellor
Whenever we build an abstract specification language, we lose some control over that which we have abstracted away. This poses difficulties when we desire such control, but are unwilling to lose the undoubted benefits of an abstract specification language.
This problem is greater when the gap between the specification and the eventual implementation is large, which is especially the case when defining the functional behaviour of an embedded system. At this stage, the differentiation between hardware and software has not (or should not have!) been made, and the specification of software or hardware optimizations is premature.
Instead, we can treat transformations as being of equal importance as the specification model. In this way, optimations can be embedded within the transformations and so close the gap between specification and design in a general manner.

Discovering faults in exception handling as an example of recurring code; Magiel Bruntink (CWI)
Exception handling is a key component of any reliable software system. This allows the system to detect errors, and react to them correspondingly. Despite its importance exception handling is often the least well understood, documented and tested part of the system. An approach and analysis tool will be presented to reduce the number of implementation faults related to exception handling.

Experiences with Addressing Crosscutting Concerns at ASML; Pascal Durr (UT)
In the early phases of the Ideals project, several crosscutting concerns were identified within the ASML software, such as tracing, contract enforcement and error handling. A case study and a prototype implementation were executed, which demonstrated the benefits of using Aspect-Oriented Programming to address these crosscutting concerns. As a result, ASML initiated a transfer project to mature the prototype into an industrial-strength implementation. In this presentation, we discuss this process, the resulting weaver implementation, and its current usage at ASML. We present the results of an experiment with 17 ASML software engineers to quantify the effectiveness of the solution. However, there were still remaining challenges with the application of Aspect-Oriented Programming: in particular, aspects may interfere with each other. We present an approach for the detection of behavioral conflicts that is based on a novel abstraction model for representing the behavior of advice. One of the benefits of the approach is that it neither requires the application programmers to deal with the conflict models, nor does it require a formal background for the aspect programmers.

Embedded Systems Modeling, Analysis and Synthesis; Jeroen Voeten (ESI), Luc van Engelen (TU/e), Marc Hamilton (ASML)
Model driven engineering (MDE) refers to the systematic use of models as primary engineering artifacts throughout the engineering lifecycle. In this chapter we will show how executable models can be used to aid the design process of a light control subsystem of a wafer scanner. An explicit distinction is made between the model of the application logic and the platform on which it is deployed. It will be shown how the performance of this subsystem can be predicted in an early phase of the design process, before the system is implemented in terms of hardware and software components. The executable model in addition allows a prototype software implementation to be derived from it automatically in a predictable way. The executable model is expressed in POOSL, a special-purpose modeling language targeting real-time embedded systems. To allow an embedding in a future MDE environment, an experiment is performed to express a similar model in the general-purpose modeling language UML from which the executable models can be derived through model transformations. These transformations further allow one to combine an application model created in UML with a platform model created in POOSL and analyze this combined model.

Rregistration is closed and the maximum number of participants has been reached.