Daniel Ratiu

Seamless Model-Based Development: From Isolated Tools to Integrated Model Engineering Environments

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.

Language evolution in practice: the history of GMF

In consequence of changing requirements and technological progress, software languages are subject to change. The changes affect the language’s specification, which in turn affects language processors as well as existing language utterances. Unfortunately, little is known about how software languages evolve in practice. This paper presents a case study on the evolution of four modeling languages provided by the Graphical Modeling Framework. It investigates the following research questions: (1) What is the impact of language changes on related software artifacts?, (2) What activities are performed to implement language changes? and (3) What kinds of adaptations capture the language changes? We found out that the language changes affect various kinds of related artifacts; the distribution of the activities performed to evolve the languages mirrors the classical software maintenance activities, and most language changes can be captured by a small suite of operators that can also be used to migrate the language utterances.

From Reality to Programs and (Not Quite) Back Again

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 todays 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.

The loss of architectural knowledge during system evolution: An industrial case study

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.

Extracting Domain Ontologies from Domain Specific APIs

Domain specific APIs offer their clients ready-to-use implementations of domain concepts. Beside being interfaces between the worlds of humans and computers, domain specific APIs contain a considerable amount of domain knowledge. Due to the big abstraction gap between the real world and todays programming languages, in addition to the knowledge about their domain, these APIs are cluttered with a considerable amount of noise in form of implementation detail. Furthermore, an API offers a particular view on its domain and different APIs regard their domains from different perspectives. In this paper we propose an approach for building domain ontologies by identifying commonalities between domain specific APIs that target the same domain. Besides our ontology extraction algorithm, we present a methodology for eliminating the noise and we sketch possible usage-scenarios of the ontologies for program analysis and understanding. We evaluate our approach through a set of case-studies on extracting domain ontologies from well-known domain specific APIs.

How Programs Represent Reality (and how they don't)

Programming is modeling the reality. Most of the times, the mapping between source code and the real world concepts are captured implicitly in the names of identifiers. Making these mappings explicit enables us to regard programs from a conceptual perspective and thereby to detect semantic defects such as (logical) redundancies in the implementation of concepts and improper naming of program entities. We present real world examples of these problems found in the Java standard library and establish a formal framework that allows their concise classification. Based on this framework, we present our method for recovering the mappings between the code and the real world concepts expressed as ontologies. These explicit mappings enable semi-automatic identification of the discussed defect classes

Limitations of automating model migration in response to metamodel adaptation

In consequence of changing requirements and technological progress, modeling languages are subject to change. When their metamodels are adapted to reflect those changes, existing models might become invalid. Manually migrating the models to the adapted metamodel is tedious. To substantially reduce effort, a number of approaches have been proposed to fully automate model migration. However, the evolution of modeling languages occasionally leads to metamodel changes for which the migration of models inherently cannot be fully automated. In these cases, the migration of models requires information which is not available in the model. If such changes are ignored or circumvented, they may lead to language erosion. In this paper, we formally characterize metamodel adaptations in terms of the effort needed for model migration. We focus on the problem of metamodel changes that prevent the automatic migration of models. We outline different possibilities to systematically cope with these kinds of metamodel changes.

Evaluating the Reference and Representation of Domain Concepts in 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 APIs 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.

Metamodel usage analysis for identifying metamodel improvements

Modeling languages raise the abstraction level at which software is built by providing a set of constructs tailored to the needs of their users. Metamodels define their constructs and thereby reflect the expectations of the language developers about the use of the language. In practice, language users often do not use the constructs provided by a metamodel as expected by language developers. In this paper, we advocate that insights about how constructs are used can offer language developers useful information for improving the metamodel. We define a set of usage and improvement patterns to characterize the use of the metamodel by the built models. We present our experience with the analysis of the usage of seven metamodels (EMF, GMF, UNICASE) and a large corpus of models. Our empirical investigation shows that we identify mismatches between the expected and actual use of a language that are useful for metamodel improvements.

The Logical Modularity of Programs

The principles and best practices of object oriented design require that modules in a program should match logical decomposition of the knowledge that the program implements. The violation of these modularization rules leads to several undesired consequences: (i) non-cohesive modules that mix different kinds of knowledge and (ii) logically coupled modules due to a dispersion of conceptually cohesive knowledge. In this paper, we use domain knowledge driven program analysis to detect and characterize discrepancies between the structural modularization of programs and the conceptual decomposition of the implemented knowledge. We characterize the mismatches at the levels of granularity of packages and classes and present their impact on different maintenance activities. The presented approach includes a technique for automating the recovery of mappings between the different categories of knowledge used in the program and the modules that implement them. We briefly present our experience with analyzing JHotDraw.