Situational Method Engineering for the Enactment of Method-Centric Domain-Specific Languages

Model-driven technologies influence today's software engineering more and more. During the last decade, a multitude of so-called meta models (or modeling languages) were developed to lift the level of abstraction from textual programming languages to the more conceptual level of models, which can be processed (e.g., by using model transformation, model validation, or simulation), and from which code can be generated automatically. Beside many benefits, which arose using this new technology, other drawbacks came up. Especially, the multitude of domain-specific and complex meta models, the relationship between different meta models, and unfamiliar design principles, still hamper effective application of model-driven technologies. This situation, for example, becomes obvious in automotive industry, where meta models, such as AUTOSAR, EAST-ADL, or TADL, were developed to enable the effective design of different concerns in automotive software development. Although, a lot of documentation in textual form is available, there is a gap between informal documentation and formal meta-model specification. Especially, matching complex meta models with the overwhelming number of documentation to apply meta models correctly proves sometimes difficult and causes a gap between research and the application of new technologies in real industrial development projects. Therefore, the basic idea behind this thesis is to provide an integrated process model, which enables the execution and enactment of model-driven development processes in form of an effective guidance system. On the one hand, this requires the extension of conventional control-flow semantics of today's software development processes, which are modeled for management and simple documentation purposes only. On the other hand, our approach integrates more detailed information about guidelines, roles, or work products, which is normally distributed across different informal documents. We put all these information into a comprehensive and computer-interpretable model, which is afterwards interpreted to guide developers' work automatically. Based on this, the process model not only allows us to determine a sequence of actions, which have to be executed to produce particular output, but it also enables us to generate new artifacts, such as activity-specific editors to support respective development activities. This works as follows: While generated editors can exactly provide developers with needed capabilities, using an all-purpose standard editor allows for the application of all capabilities at any time of the development process. Because of the increasing number of large meta models or domain-specific languages, this could be a confusing task for most of the time. Therefore, our approach proposes the generation editors, that restrict the capabilities and the available set of design elements, i.e., language elements of a meta model, to the situational needs of a respective development activity only. In addition, the process model links each development activity with an individual set of computer-interpretable guidelines, which are relevant for the activity only, in contrast to the global set of "constraints" or guidelines as used in standard editors. These guidelines are evaluated in the context of a specific development activity and provide developers with situational guidance information. As the process model is interpreted and monitored all the time, we are enabled to log all modeling actions. These logs are either used to improve the process afterwards in doing conventional reviews, or to analyze these logs to derive traceability information at process execution time, and to identify potential inconsistencies between work products. This information is used to decide on the repetition of individual development activities to correct the inconsistencies. Finally, as it proves difficult to design complex process models for each project situation from scratch, we combined the general approach with process line engineering techniques to enable reuse of already available information and to combine these information with additional computer-interpretable design artifacts. Therefore, a so-called method repository is used to store all interpretable development activities as variants for variation points designed in a reference process, which can be compared with the reference product (aka. platform) as used in product line engineering. The final process is generated by matching project-specific requirements with available variants and combining these variants with relevant variation points of the reference process