Domain specific languages (DSLs) bring substantial increase in productivity and quality and thus look very appealing to software engineering practitioners. Because language workbenches can drastically reduce the cost of building and maintaining DSLs and associated tooling, they catch the attention of technical leads and project managers in the industry. Effective use of language engineering technologies for software development requires specific knowledge about building DSLs in general and about language workbenches in particular. Practicing software engineers need to enrich their skills with a new software development approach and the supporting tools. In this paper we present our experiences with training and coaching software practitioners in developing domain specific languages and the associated tooling with Jetbrains' Meta-Programming System. We distill the experience that we have gained over the last three years while running 16 trainings organized by three different organizations. The trainings were attended by over 50 developers, who work in different business domains and posses a wide variety of technical backgrounds, previous experiences and concrete needs. We present a set of challenges faced while teaching language engineering technologies in the industry. To address these challenges we developed a curriculum containing increasingly complex topics and an approach, which combines classical trainings with continuous coaching either remotely or on site. Based on our experience we distill a set of lessons learnt about the dissemination of language engineering technologies to practitioners. We identify several concrete needs which are key to broader adoption of language engineering in practice.

Due to its capabilities to integrate well with C code, Spin has been used for C code verification based on environment models that describe the context, in which the software under verification is expected to run. In practice this approach requires an in-depth knowledge of Promela and the underlying technology. Moreover environment models tend to be verbose and exhibit heavily intertwined statements of Promela and C code. Thereby, writing and understanding such hybrid models is difficult and error-prone. Alleviating this problem we develop a specialized language for expressing environment models used in verification harnesses. Our language harmonizes the use of Promela and C in a homogeneous way that is suitable for practitioners. We show how a small number of language concepts is sufficient to define environments for a wide variety of commonly encountered software components written in C. The approach is integrated in the development platform mbeddr, a technology stack for embedded programming and formal verification developed on top of JetBrains’ MPS language workbench.

When verifying C code, two major problems must be addressed. One is the specification of the verified systems properties, the other one is the construction of the verification environment. Neither C itself, nor existing C verification tools, offer the means to efficiently specify application domain-level properties and environments for verification. These two shortcomings hamper the usability of C verification, and limit its adoption in practice. In this paper we introduce an approach that addresses both problems and results in user-friendly and practically usable C verification. The novelty of the approach is the combination of domain-specific language engineering and C verification. We apply the approach in the domain of state-based software, using mbeddr and CBMC. We validate the implementation with an example from the Pacemaker Challenge, developing a functionally verified, lightweight, and deployable cardiac pulse generator. The approach itself is domain-independent.

The growth of software complexity and high degree of dependencies between functionalities motivates the use of models during requirements engineering. Hence, readability and comprehensibility of currently requirements specification techniques should be increased. Additionally, multi-view modeling and tabular expression are widely accepted techniques in requirements documentation. We present a tool that allows structured multi-view modeling of the behavior of the system by means of tabular notation. Our tool provides various table patterns to support different behavior views, which leverage the advantages of tabular specification, e.g., unambiguous, precise, and easier to read, analyses and communicate. Our aim is to reduce the complexity in the development of software systems.

Model-based requirements engineering supports eliciting, specifying and analyzing the work products elaborated during the requirements engineering process by providing adequate models. However, especially the inclusion of formal models needs to be investigated further. These models represent requirements and have to be integrated with reference models that define and structure the work results and their relations. We have developed the research tool MIRA to provide an infrastructure for the tool-based evaluation of the usage of models in the field of requirements engineering. In this paper we present the research questions addressed by MIRA concerning the reference model and the formal models. We explain how MIRA supports answering these research questions.

Programming involves representing domain concepts by using programming abstractions. In object-oriented programs, concepts and relations of the business domain are represented as classes, attributes and methods. However, the concepts and relations that logically belong together are scattered across different modules, interleaved with technical concepts, and distorted due to implementation details. In this paper, we present an automatic method to identify logically related concepts and the relations among them. To achieve this, we systematically transform program identifiers into fragments of natural language sentences and check whether these sentence fragments are meaningful for humans. In order to automatically perform such checks, we use the World Wide Web as a knowledge base that contains a huge number of meaningful texts, and use the Google web search engine to validate the meaningfulness of these sentences. If the search engine returns a sufficient number of hits, we discovered a piece of knowledge in the code. By systematically applying this method, we obtain a condensed form of the knowledge embodied in the program which is an enabler for automatic analyses. We present our experience with several use-cases: (1) assessing the meaningfulness of identifiers, (2) extracting complex concepts from compound identifiers, (3) extracting a meaningful taxonomy from the class hierarchy, and (4) extracting complex conceptual relations from the code. We report on our observations during the analysis of real world Java code, discuss the limitations of our approach and sketch extension possibilities.

More than 20 years of research has created a large body of ideas, concepts, and theories for model-based development of embedded software-intensive systems. These approaches have been implemented by several tools and successfully applied to various development projects. However, the everyday use of model-based approaches in the automotive and avionic industries is still limited. Most of the time, the engineers work with a predefined set of isolated tools, and therefore adapt their engineering methods and process to the available tools. Today, the industry achieves tool integration by demand-driven, pragmatic, and ad-hoc composed chains of a priori existent commercial tools. Nevertheless, these tool chains are not (and cannot be) seamless, since the integration that can be achieved is not deep enough. This hampers the reuse and refinement of models, which subsequently leads to problems like redundancy, inconsistency, and lack of automation. In the end, these deficiencies decrease both the productivity and quality that could be provided by model-based approaches. To overcome these problems, a deep, coherent, and comprehensive integration of models and tools is required. Such an integration can be achieved by the following three ingredients: 1) a comprehensive modeling theory that serves as a semantic domain for the models, 2) an integrated architectural model that holistically describes the product and process, and 3) a manner to build tools that conform to the modeling theory and allow the authoring of the product model. We show that from a scientific point of view, all ingredients are at our hands to do a substantial step into an integrated process and tool world. Further, we illustrate why such a solution has not been achieved so far, and discuss what is to be done to get a step closer to seamless model-based engineering.

Architecture defines the components of a system and their dependencies. The knowledge about how the architecture is intended to be implemented is essential to keep the system structure coherent and thereby comprehensible. In practice, this architectural knowledge is explicitly formulated only in the documentation (if at all), which usually gets outdated very soon. This leads to a growing amount of implicit knowledge during evolution that is especially volatile in projects with high developer fluctuation. In this paper we present a case study about the loss of architectural knowledge in three industrial projects to answer the following research questions: 1) to what degree is the architectural documentation kept in conformance with the code? 2) how well does the documentation reflect the intended architecture?, 3) how big is the architectural decay?, and 4) what are the causes for nonconformances? We answer these questions by investigating the architecture documentation, the source code, and by performing interviews with developers. The most important outcomes of our study are: the informal documentation and the source code are not kept in conformance with each other, none of them completely reflects the intended architecture, and even developers taken individually are not completely aware of the intended architecture. Quantitatively, between 70% and 90% of these nonconformances are caused by flaws in the documentation and between 10% and 30% represent architectural violations in the code.

Libraries are the most widespreaded form of software reuse. In order to properly use a library API, its clients should fulfill a series of (many times implicit) assumptions made by the API programmers. Failing to fulfill these assumptions leads to a misuse of the library and thereby to defects in the client's code. In this paper we present a method for checking a well-behaved usage of an API through a set of context-sensitive syntactic constraints over the API clients. These constraints restrict the set of programs that can be written with an API only to programs that fulfill the API assumptions and thereby represent a well-behaved and valid usage of the API. In this paper we present a set of typical assumption classes made by API providers about their clients. We define a framework for formalizing the context- sensitive constraints over the API client code and propose a typical constraint for each class of assumptions. Thereby we provide a mechanism that allows the provider of an API to describe the knowledge of how an API is intended to be used in an automatically checkable form. We present our experience with parts of the Java Standard APIs.

As libraries are the most widespread form of software reuse, the usability of their APIs substantially influences the productivity of programmers in all software development phases. In this paper we develop a framework to characterize domain-specific APIs along two directions: 1) how can the API users reference the domain concepts implemented by the API; 2) how are the domain concepts internally represented in the API. We define metrics that allow the API developer for example to assess the conceptual complexity of his API and the non-uniformity and ambiguities introduced by the API's internal representations of domain concepts, which makes developing and maintaining software that uses the library difficult and error-prone. The aim is to be able to predict these difficulties already during the development of the API, and based on this feedback be able to develop better APIs up front, which will reduce the risks of these difficulties later.

Making explicit the mappings between real-world concepts and program elements that implement them is an essential step in understanding, using or evaluating the public interface of programs, libraries and other collections of classes that model core domain concepts. Unfortunately, due to the big abstraction gap between the modeled domain and today's programming languages, the mapping is most of the times ambiguous as concepts and relations from the real world are distorted and diffused in the code. In this paper we present a comprehensive formal framework for describing the many-to-many mappings between domain concepts and the program elements, real-world relations and program relations and the real-world concept names and program identifiers. This framework allows us to describe and discuss typical classes of diffusion of the domain knowledge in code. Based on our formal framework we describe an algorithm to recover the mappings between entities from an ontology and program elements. We illustrate the framework by using examples from the Java standard library.

Gaining an overview of the concepts represented in large programs is very demanding as multiple dimensions of knowledge appear at different abstraction levels throughout the source code. To reduce the overall comprehension effort it is therefore desirable to make the knowledge once gained explicit and shareable. We tackle this problem by establishing a mapping between source code and conceptualizations shared as ontologies. To achieve this we regard programs themselves as knowledge bases built on the programs' identifiers and their relations implied by the programming language. Making these mappings explicit allows sharing knowledge about the concepts represented in programs. We exemplify our approach on Java programming language and the WordNet ontology and we report on our experience with analyzing an open source system