Table 2 - uploaded by Tijs van der Storm
Content may be subject to copyright.
Summary of causes of architecture violations by MOD4J

Summary of causes of architecture violations by MOD4J

Source publication
Conference Paper
Full-text available
Model-driven software development (MDSD) has been on the rise over the past few years and is becoming more and more mature. However, evaluation in real-life industrial context is still scarce. In this paper, we present a case-study evaluating the applicability of a state-of-the-art MDSD tool, modJ, a suite of domain specific languages (DSLs) for d...

Contexts in source publication

Context 1
... √ symbol indicates that requirements of the modality in a certain row are taken into account if it is fulfilled according to the predicate in each column. We summarized the determined causes of requirement violations in Table 2. We have seen that MOD4J follows the major parts of the reference architecture, but lacks modeling support for certain variable features [10]. ...
Context 2
... have seen that MOD4J follows the major parts of the reference architecture, but lacks modeling support for certain variable features [10]. The rows 2, 3, 5, 6, 7 from Table 2 describe the cause of this. These variable features can be implemented by hand using the aforementioned extension points, at a certain cost (see below where we evaluate hand-written code). ...

Similar publications

Article
Full-text available
Nowadays agile software development is used in greater extend but for small organizations only, whereas MDA is suitable for large organizations but yet not standardized. In this paper the pros and cons of Model Driven Architecture (MDA) and Extreme programming have been discussed. As both of them have some limitations and cannot be used in both lar...

Citations

... Users can skip down to the next lower abstraction level if an abstraction is not suitable or if it introduced too much performance overhead (a very important concern in embedded software). Based on a case study in enterprise systems, [56] suggests that "the use of hand-written code [..] was instrumental in implementing the fine details of some functional requirements. We propose that designers of model driven development environments introduce such a feature [..]" mbeddr supports this not by generating skeletons that users can then fill in with "manually written code" in an external IDE. ...
... Instead, users can write lower-level code directly in mbeddr, avoiding integration issues with the external IDE. [56] continues to conclude with "[..] and at the same time try to prevent [the user of manually written code] by (incrementally) perfecting their modeling languages." This is exactly what has been done in mbeddr by successively adding language extensions. ...
Article
Full-text available
Language workbenches are touted as a promising technology to engineer languages for use in a wide range of domains, from programming to science to business. However, not many real-world case studies exist that evaluate the suitability of language workbench technology for this task. This paper contains such a case study. In particular, we evaluate the development of mbeddr, a collection of integrated languages and language extensions built with the Jetbrains MPS language workbench. mbeddr consists of 81 languages, with their IDE support, 34 of them C extensions. The mbeddr languages use a wide variety of notations—textual, tabular, symbolic and graphical—and the C extensions are modular; new extensions can be added without changing the existing implementation of C. mbeddr’s development has spanned 10 person-years so far, and the tool is used in practice and continues to be developed. This makes mbeddr a meaningful case study of non-trivial size and complexity. The evaluation is centered around five research questions: language modularity, notational freedom and projectional editing, mechanisms for managing complexity, performance and scalability issues and the consequences for the development process. We draw generally positive conclusions; language engineering with MPS is ready for real-world use. However, we also identify a number of areas for improvement in the state of the art in language engineering in general, and in MPS in particular.
... In their paper, Lussenburg et al. [22] describe a case study in which an administrative enterprise application was migrated to an MDD development paradigm. The focus of their paper was to evaluate the suitability of a particular MDD framework (MOD4J). ...
... These parameters configure the code generation; for example, defines the set of fields a class shall contain (a more detailed example is provided below). This approach is similar to the one described in [22]. ...
Article
Domain-specific modelling (DSM) is a modern software development technology that aims at enhancing productivity. One of the claimed advantages of DSM is increased maintainability of software. However, current empirical evidence supporting this claim is lacking. In this paper, we contribute evidence from a case study conducted at a software development company. We study how the introduction of DSM affected the maintenance of a legacy system. We collected data about the maintenance phase of a system that was initially developed using manual programming, but which was gradually replaced by DSM development. We performed statistical analyses of the relation between the use of DSM and the time needed to resolve defects, the defect density, and the phase in which defects were detected. The results show that after introducing DSM the defect density is lower, that defects are found earlier, but resolving defects takes longer. Other observed benefits are that the number of developers and the number of person-hours needed for maintaining the system decreased, and the portability to new platforms increased. Our findings are useful for organizations that consider introducing DSM and would like to know which benefits can be realized in software maintenance.
... Lussenburg et al. [11] present a comparison of a non-MDE implementation with an implementation generated by a MDE tool, which is called Mod4J. Three criteria were studied: conformance to the reference architecture, functional requirement satisfaction and reduction of handwritten code. ...
... The first observation we make is that all three projects managed to reach high reuse levels, around 80-90% ( Figure 2). These values coincide, in a rough comparison, with some related work [10], [11], [12]. ...
Conference Paper
Software reuse and model-driven engineering (MDE) are two distinct approaches that attempt to improve quality and productivity in software projects. Much is said about how MDE can increase software reuse by reducing the amount of hand-written code, but few studies consider the fact that in MDE other artifacts -- models, tools, transformations and code generators -- come into play and need to be considered. How much more reuse can we achieve with MDE? How reusable are these MDE-specific assets? Motivated by these questions, this paper presents the observations made in three exploratory studies. In each study, the same software was developed with and without MDE, and a comparison based on reuse metrics was made. The results indicate that MDE can increase and/or improve software reuse in different ways, but with some associated costs, such as increased software complexity and decreased maintainability. In the context of our observations, complex technical domains have more to gain from the automation achieved with MDE, while business domains seem to be more suitable for simpler feature-based configuration. We conclude the paper pointing out more studies that could be performed to gain additional knowledge regarding MDE and reuse.
Conference Paper
Model-driven development (MDD) and aspect-oriented programming (AOP) are two very different paradigms, having in common that they both aim at increasing development efficiency. In order to investigate their benefits and liabilities, we compared both in context of a case study on an industrial-grade software system, the Open SOA platform. Already having a model-driven XML/XSL-T implementation in place, we re-implemented the corresponding logic of the Open SOA platform with a corresponding AOP implementation in AspectJ. Considering several comparison criteria, the results of our case study indicate that the AspectJ implementation is less redundant, better testable, and improves on understandability and readability. The model-driven approach, in turn, is the more flexible one, as it allows for generating arbitrary artifacts and structures, without the need for compromising on design. Additionally, we expect that MDD can furthermore catch up on readability and understandability, when more advanced MDD tooling can be leveraged. As our case study mainly centers around implementing wrappers and boilerplate-code, which are rather common issues, our results may be transferred to similar problem settings. Furthermore, our evaluation criteria can guide others in making technology choices. To this end, we give an outlook on how combinations of MDD and AOP may leverage the best of both worlds.
Conference Paper
Domain-specific languages (dsls) can significantly increase productivity and quality in software construction. However, even dsl programs need to evolve to accomodate changing requirements and circumstances. How can we know if the design of a dsl supports the relevant evolution scenarios on its programs? We present an experimental approach to evaluate the evolutionary capabilities of a dsl and apply it on a dsl for digital forensics, called DERRIC. Our results indicate that the majority of required changes to DERRIC programs are easily expressed. However, some scenarios suggest that the dsl design can be improved to prevent future maintenance problems. Our experimental approach can be considered first steps towards evidence-based dsl evolution.