Keywords:
Astract: Aspect-orientation provides a new way of modularization by clearly separating crosscutting concerns from noncrosscutting ones. While aspect-orientation originally has emerged at the programming level, it now stretches also over other development phases. There are, for example, already several proposals for Aspect-Oriented Modeling (AOM), most of them pursuing distinguished goals, providing different concepts as well as notations, and showing various levels of maturity. Consequently, there is an urgent need to provide an in-depth survey, clearly identifying commonalities and differences between current AOM approaches. Existing surveys in this area focus more on comprehensibility with respect to development phases or evaluated approaches rather than on comparability on bases of a detailed evaluation framework. This article tries to fill this gap focusing on aspect-oriented design modeling. As a prerequisite for an in-depth evaluation, a conceptual reference model is presented as the article's first contribution, centrally capturing the basic design concepts of AOM and their interrelationships in terms of a UML class diagram. Based on this conceptual reference model, an evaluation framework has been designed, resembling the second contribution, by deriving a detailed and well-defined catalogue of evaluation criteria, thereby operationalizing the conceptual reference model. This criteria catalogue is employed together with a running example in order to evaluate a carefully selected set of eight design-level AOM approaches representing the third contribution of the article. This per approach evaluation is complemented with an extensive report on lessons learned, summarizing the approaches' strengths and shortcomings.

Keywords:
Astract: When software is developed in teams - the standard way software is developed today - versioning systems are the first choice for the management of collaboration. From a technical point of view, versioning systems have to face several challenges. Depending on the applied versioning paradigm, functionalities such as synchronous editing, branching, storing different versions, merging, etc. are required. Since much effort has been spent into realizing these tasks, measurable progress has been achieved over the last decades. Unfortunately, a lack of empirical studies exists to find out the actual requirements arising from practice. Therefore, we conducted an online survey and interviewed representative users of versioning systems from academia and industry. Special emphasis is on the versioning of software models, which are nowadays becoming more and more important as there is a trend to model-driven software engineering. The results of our empirical studies show that not all requirements of developers are satisfied by current versioning systems. Especially, more emphasis has to be put on the management of collaborative development, e.g., the division of work and the management of conflicts.

Keywords:

Keywords:
Astract: In the context of model-based tool integration, model transformation languages are the first choice for realizing model exchange between heterogenous tools. However, the lack of a conceptual view on the integration problem and appropriate reuse mechanisms for already existing integration knowledge forces the developer to define model transformation code again and again for certain recurring integration problems in an implementation-oriented manner resulting in low productivity and maintainability of integration solutions. In this chapter, we summarize our work on a framework for model-based tool integration which is based on well-established conceptual modeling techniques. It allows to design integration models on a conceptual level in terms of UML component diagrams. Not only the design-time is supported by conceptual models, but also the runtime, i.e., the execution of integration models, is represented by conceptual models in terms of Coloured Petri Nets. Furthermore, we show how reusable integration components for resolving structural metamodel heterogeneities, which are one of the most frequently recurring integration problems, can be implemented within our framework.

Keywords: