-Despite the promises of Model-Driven Engineering (MDE) to address complexity and improve productivity, no widespread adoption has been observed in industry. One reason this paper focuses on is reuse, which is essential in modern software engineering. In the context of MDE, poor availability of reusable models forces modellers to create models from scratch. At the same time, reusable code artifacts, such as frameworks/APIs are widespread. They are an essential part when creating software. This paper presents model-based reuse of APIs, which makes use of concern-driven development (CDD) to raise the level of abstraction of APIs to the modelling level. The interface (API) of a framework is modelled using a feature model and design models for each feature enabling their reuse in MDE. Additional information is embedded, such as impacts and protocols, to assist the developer in the reuse process. We discuss how this enables reuse at the modelling level, the required tool support and future work.
Model-Driven Engineering (MDE) has been around for
some time. Despite its promises to address challenges, such
as complexity, maintenance and productivity, no widespread
adoption has been observed in industry. The reasons are broad
and range from non-technical (cultural, social etc.) to technical
ones (e.g., lack of tool support) [
Methodical reuse of software artifacts is essential in modern
software engineering [
Reuse in the context of MDE is not very common. This
could be due to many factors, e.g., that with the current
available modelling technology it is difficult to make models
reusable, that model import and export between tools remains
non-trivial, and that there are not many model repositories with
available models for reuse [
Hence, we popose in this paper to elevate reusable code artifacts to the model level to enable their reuse in the MDE context. We do this by augmenting reusable code artifacts with models that describes their provided functionality, how to customize and how to use them within a specific reuse context using the appropriate modelling notations and level of abstraction.
The remainder of the paper is structured as follows.
Section II introduces Concern-Oriented Development (CDD) [
In contrast to the focus of classic Model-Driven Engineering
(MDE) on models, the main unit of abstraction,
construction, and reasoning in Concern-Driven Software Development
(CDD) is the concern [
Building a concern is a non-trivial, time-consuming task, typically done by or in consultation with a domain expert (subsequently called the concern designer). On the other hand, reusing an existing concern is extremely simple, and essentially involves three steps for the concern user: 1) Selecting the feature(s) of the concern with the best the Minueto framework by hand using the provided runnable impact on relevant goals and system qualities from the code examples. Each example covers at least one use case. variation interface of the concern. However, only a subset of the complete API is covered, which 2) Adapting the general models of features of the concern in addition required us to consider the API documentation in that were selected to the specific application context order to identify and place them appropriately. Figure 1 shows based on the customization interface by mapping them. the feature model of Minueto, which was obtained through 3) Using the functionality provided by the selected concern several iterations.
features as defined in the usage interface within the This confirms what we described in the previous section, application. that in order to create a concern, thorough knowledge is The feature model’s features are organized within a tree required. In the ideal case, this is done by a domain expert, structure, where a relationship between the parent and child for instance one or several framework developers, who have feature determines constraints for valid selection. A feature can deep knowledge of the reusable artifact. Considerable effort is be mandatory or optional, or all child features can be within required, but we deem this acceptable, if the API is reused a an XOR or OR relationship. Different models at different levels lot. Furthermore, the concern interface can evolve over time. of abstraction can provide a realization model for each feature. Adding one additional feature requires a lot less effort. This For instance, the design of a concern can be provided by also supports the use case of open source development, where design models that entail class, sequence and state diagrams. anyone can contribute.
Each feature provides the functionality for just that feature, B. Designing an API Subset contributing to the design of the parent feature’s realization model. In order to accomplish this, aspect-oriented techniques are used.
In general, MDE approaches rely heavily on tool support.
Tool support is even more important in the context of CDD, in particular for the concern user. The tool needs to guide the user for selecting variations (making valid selections) and evaluating impacts (allowing the user to perform trade-off analysis between different selections). In addition, the tool needs to hide the complexity of the composition of models and provide validation to ensure proper customization and usage.
This section provides an overview of our approach to raise
the level of abstraction for APIs to the modelling level and
is illustrated using an example framework called Minueto [
Concernification is the process of creating a concern
interface for an existing reusable artifact (API) in order to facilitate
its use within MDE [
In the previous section, when the features were determined, a mapping between the used API classes and its corresponding feature was established. Based on this, the API is split across the features, which means that a feature can contain more than one class. However, more fine-grained separation might be desired, for instance, when a specific operation of a class belongs to a different feature. Then, the operation can be moved out of that class and the class with just that operation is added to another design model of a different feature. When combining design models, classes with the same name will be merged.
Figure 2 shows the Minueto feature Windowed, which provides the ability to create a game in windowed mode. Windowed extends the design realization model of Surface by only contributing this functionality, i.e., the interface MinuetoWindow is already defined in Surface including all its operations.
Similarly, the feature Keyboard (sub-feature of Interactive) illustrated in Figure 3 provides a keyboard handler. In addition, it provides the required operations to register and unregister the handler from a window, which is not present in the MinuetoWindow interface of the visual feature group. These operations were separated from that interface and the interface class with just those operations added to the Keyboard feature.
When a user selects Windowed and Keyboard, both those features and their parents are part of the selection and their design realization models will be combined. Figure 4 shows the resulting composed model, which presents the subset of the API based on the user’s desired selection. It was obtained by combining the models of Windowed, Surface, Visual, Keyboard File
Legend mandatory or
optional xor (alternative) Visual Interactive
Utilities and Interactive. Classes with the same name are merged by combining their operations and attributes. For instance, the MinuetoWindow class now also contains the operations for keyboard handler registration. The user can then use these classes and operations within the application model.
Generated Interface of the Selected Features Windowed and <<impl>> MinuetoImage Minu<e<tiomKpely>b>oard + int KEY_A + int KEY_B ...
The previous section described how the variations of an API can be modelled and decomposed in order to provide only the interface of interest to the user. It also provides a compact and organized view of the user-perceivable features provided by an API. However, a concern interface can provide the following additional benefits: • Traceability can be provided, which allows the user to see which elements belong to which feature in the composed model of the API. • Impacts on high-level system qualities can be incorporated to give guidance to the user when selecting features on how they impact non-functional properties. • Usage protocols can be incorporated to formally specify the protocol of different classes on how they can be used. Correct use of the framework can then be ensured in the application models. • Partial structure and behaviour can be integrated, which forces the user to provide mappings to applicationspecific elements using the customization interface. For instance the fact that a certain interface needs to be implemented. • Other artifacts that usually are shipped with an API or are relevant for reuse could be integrated in the future (as a different kind of model).
These help decrease the risk of a user making mistakes when reusing an API, which can often lead to bugs or vulnerabilities in software systems.
As described in Section II, tool support is crucial for concern-orientation. It is important for both concern designer and user to be provided with proper tool support. Especially for the latter it is essential to hide the complexity of CDD and provide guidance throughout the reuse process following the three steps outlined in Section II. In addition, support to model existing API elements (classes, operations etc.) in order to differentiate them from application-specific elements is required.
We use TouchCORE [
In order to be able to import implementation classes that are defined by a programming language class library (such as those provided by Java) or a framework, it is possible to import them into a design model [16]. The modeller can choose, which implementation class to import. At first, the class is empty. We decided to only show the ones used by the user, since it might have a large amount of operations. The modeller can then import those operations that are needed. Whenever an operation uses another class from the same framework or programming language (e.g., as a return or parameter type), it is automatically imported. In addition, the hierarchy (both extends and interface implementations) of implementation classes is now supported, which wasn’t possible until recently. This means that on import, if the imported class is a super or sub class of an existing implementation class within the class diagram, the hierarchy is shown accordingly. An example, as seen in TouchCORE, is shown in the top part of Figure 5.
The structure illustrated in Figure 5 presents an example of the partial structure and behaviour mentioned as one of the benefits in the previous section. In this case, the modeller needs to provide a mapping for |Application and its constructor to corresponding elements of the model. This class will then have the associations to the implementation classes. Furthermore, using aspect-oriented techniques, we advice the constructor. An event queue is instantiated before the actual behaviour (represented by the box containing the asterisk) of an application’s constructor as shown in the bottom part of Figure 5, because it is required to provide interactivity.
This paper presented an overview of concern interfaces for APIs in order to facilitate the reuse of reusable code artifacts on the modelling level by raising their level of abstraction to it. The variations of an API are presented to the user in a concise way, showing the user-perceived features, from which the user can choose. When selecting, the user is able to do a trade-off analysis using impacts on high-level system qualities. Once a selection is made, the customized API (a subset of the API) is presented to the user showing only the relevant parts of the interface required for the desired features. Concernification of an API allows to incorporate additional information, which supports the user upon reuse using the concern interface. This also helps to reduce mistakes by the user during reuse, for instance, not calling a certain operation.
In the future, we plan to concernify a larger, more relevant framework, such as the Android SDK, in order to ensure the feasibility of the approach. Ideally, the concern interface is bundled along with the API’s code. Because of this, and the fact that it is more difficult to concernify a larger framework with thousands of classes by hand, we intend to perform this (semi-)automatically. This way, a feature model can be presented to the user, which, if necessary, can then be adjusted. To validate the automated concernification, we plan to empirically evaluate it to gather evidence on whether (i) the automated detection works well and (ii) this actually helps users. We believe that even more information/artifacts than those described in this paper can be incorporated more formally into a concern interface of APIs, which would improve API reuse and distribution as a whole. [13] M. Schöttle, N. Thimmegowda, O. Alam, J. Kienzle, and G. Mussbacher, “Feature Modelling and Traceability for Concern-Driven Software Development with TouchCORE,” in Companion Proceedings of MODULARITY 2015, pp. 11–14, ACM, 2015. [14] W. Al Abed, V. Bonnet, M. Schöttle, O. Alam, and J. Kienzle, “TouchRAM: A multitouch-enabled tool for aspect-oriented software design,” in SLE 2012, no. 7745 in LNCS, pp. 275 – 285, Springer, 2012. [15] M. Schöttle, “Aspect-Oriented Behavior Modeling In Practice,” M.Sc.
Thesis, Department of Computer Science, Karlsruhe University of Applied Sciences, September 2012. [16] M. Schöttle, O. Alam, F.-P. Garcia, G. Mussbacher, and J. Kienzle, “TouchRAM: A Multitouch-enabled Software Design Tool Supporting Concern-oriented Reuse,” in Companion of Modularity:2014, pp. 25–28, ACM, 2014.