Explore the vast range of titles available.

Software engineering research now considers that no system is an island, but it is part of an ecosystem involving other systems, developers, and users. When a framework or a library evolves, its clients often must adapt. For example, client developers might need to adapt to functionalities, client systems might need to be adapted to a new API, and client users might need to adapt to a new user interface. The consequences of these changes are yet unclear: what proportion of the ecosystem might be expected to react, how long might it take for a change to diffuse in the ecosystem, do all clients react in the same way? This paper reports an exploratory study aimed at observing API evolution and its impact on a large software ecosystem, Pharo, which has about 3600 distinct systems, and 6 years of evolution. We analyze 118 API changes in the context of method replacement and suggestion, and answer research questions regarding the magnitude, duration, extension, and consistency of such changes in the ecosystem. The results of this study help to characterize the impact of API evolution in large software ecosystems and provide the basis to better understand how such impact can be alleviated.

With the generalization of mobile devices and Web applications, GUI frameworks evolve at a fast pace: JavaFX replaced Swing, Angular 8 replaced Angular 1.4 which had replaced Google Web Toolkit (GWT). This situation forces organizations to migrate their applications to modern frameworks regularly so they do not become obsolete. There has been research in the past on automatic GUI migration. However, and concurrently, large organisations’ applications use many different technologies. For example, the IT company with which we are working, Berger-Levrault, wishes to migrate applications written in generic programming language (Java/GWT), proprietary “4th generation” languages (VisualBasic 6, PowerBuilder), or markup languages (Silverlight). Furthermore, one must expect that in a few years time, new frameworks will appear and new migrations will be required. Thus, there is a need for a language-agnostic migration approach allowing one to migrate various legacy GUI to the latest technologies. None of the existing solutions allow to deal with such a variety of GUI framework. They also typically focus on a subpart of the migration (i.e. how to extract a specific GUI framework) ignoring the re-engineering/forward-engineering part of the migration (which is straightforward for a single technology). This makes it difficult to adapt these solutions to other GUI frameworks. We propose an approach to migrate the GUI part of applications. It is based on meta-models to represent the visual element structure and layout. We detail how to create both the GUI extractors and generators, with guidelines to support new markup and programming languages. We evaluate our approach by implementing three extractors and generators for web-based or desktop-based user interfaces defined with generic programming languages (Java, Pharo, TypeScript) or markup languages (XML, HTML). We comment case studies on five applications, opened and closed source, of different sizes. The implementations of our generic approach detect 99% of the widgets and identify (i.e. determine the type of the widget) 97% of them. We give examples of the migrated GUIs, both successful and not.

Rotten Green Tests are tests that pass, but not because the assertions they contain are true: a rotten test passes because some or all of its assertions are not actually executed. The presence of a rotten green test is a test smell, and a bad one, because the existence of a test gives us false confidence that the code under test is valid, when in fact that code may not have been tested at all. This article reports on an empirical evaluation of the tests in a corpus of projects found in the wild. We selected approximately one hundred mature projects written in each of Java, Pharo, and Python. We looked for rotten green tests in each project, taking into account test helper methods, inherited helpers, and trait composition. Previous work has shown the presence of rotten green tests in Pharo projects; the results reported here show that they are also present in Java and Python projects, and that they fall into similar categories. Furthermore, we found code bugs that were hidden by rotten tests in Pharo and Python. We also discuss two test smells —missed fail and missed skip —that arise from the misuse of testing frameworks, and which we observed in tests written in all three languages.

Automatic testing constitutes an important part of everyday development practice. Worldline, a major IT company, is creating more and more tests to ensure the good behavior of its applications and gains in efficiency and quality. But running all these tests may take hours. This is especially true for large systems involving, for example, the deployment of a web server or communication with a database. For this reason, tests are not launched as often as they should be and are mostly run at night. The company wishes to improve its development and testing process by giving to developers rapid feedback after a change. An interesting solution is to reduce the number of tests to run by identifying only those exercising the piece of code changed. Two main approaches are proposed in the literature: static and dynamic. The static approach creates a model of the source code and explores it to find links between changed methods and tests. The dynamic approach records invocations of methods during the execution of test scenarios. Before deploying a test case selection solution, Worldline created a partnership with us to investigate the situation in its projects and to evaluate these approaches on three industrial, closed source, cases to understand the strengths and weaknesses of each solution. We propose a classification of problems that may arise when trying to identify the tests that cover a method. We give concrete examples of these problems and list some possible solutions. We also evaluate other issues such as the impact on the results of the frequency of modification of methods or considering groups of methods instead of single ones. We found that solutions must be combined to obtain better results, and problems have different impacts on projects. Considering commits instead of individual methods tends to worsen the results, perhaps due to their large size.

Model-driven engineering (MDE) exploits well-defined, tool-supported modelling languages and operations applied to models created using these languages. Model transformation is a critical part of the use of MDE. It has been argued that transformations must be engineered systematically, particularly when the languages to which they are applied are large and complicated—e.g., UML 2.x and profiles such as MARTE—and when the transformation logic itself is complex. We present an approach to designing large model transformations for large languages, based on the principle of separation of concerns . Specifically, we define a notion of localized transformations that are restricted to apply to a subset of a modelling language; a composition of localized transformations is then used to satisfy particular MDE objectives, such as the design of very large transformations. We illustrate the use of localized transformations in a concrete example applied to large transformations for system-on-chip co-design.

Models are the core assets in model-driven engineering, and are therefore subject to all kind of manipulations, such as refactorings, animations, transformations into other languages, comparisons and merging. This set of model-related activities is known as model management . Even though many languages and approaches have been proposed for model management, most of them are type-centric, specific to concrete meta-models, and hence leading to specifications with a low level of abstraction and difficult to be reused in practice. In this paper, we introduce ideas from generic programming into model management to raise the level of abstraction of the specifications of model manipulations and facilitate their reuse. In particular we adopt generic meta-model concepts as an intermediate, abstract meta-model over which model management specifications are defined. Such meta-model concepts are mapped to concrete meta-models, so that specifications can be applied to families of meta-models satisfying the concept requirements. As a proof of concept, we show the implementation of these ideas using the Eclipse Modeling Framework and the Epsilon family of languages for model management.

It is widely acknowledged that the system functionality captured in a system model has to match organisational requirements available in the business model. However, such a matching is rarely used to support design strategies. We believe that appropriate measures of what we refer to as the fitness relationship can facilitate design decisions. The paper proposes criteria and associated generic metrics to quantify to which extent there is a fit between the business and the system which supports it. In order to formulate metrics independent of specific formalisms to express the system and the business models, we base our proposal on the use of ontologies. This also contributes to provide a theoretical foundation to our proposal. In order to illustrate the use of the proposed generic metrics we show in the paper, how to derive a set of specific metrics from the generic ones and we illustrate the use of the specific metrics in a case study.

Relational databases play a central role in many information systems. Their schema contains structural (e.g. tables and columns) and behavioral (e.g. stored procedures or views) entity descriptions. Then, just like for ``normal'' software, changes in legislation, offered functionalities, or functional contexts, impose to evolve databases and their schemas. But in some scenarios, it is not so easy to deconstruct a wished evolution of the schema into a precise sequence of operations. Changing a database schema may impose manually dropping and recreating dependent entities, or manually searching for dependencies in stored procedures. This is important because getting even the order of application of the operators can be difficult and have profound consequences. This meta-model allows us to compute the impact of planned changes and recommend additional changes that will ensure that the RDBMS constraints are always verified. The recommendations can then be compiled into a valid SQL patch actually updating the database schema in an orderly way. We replicated a past evolution showing that, without detailed knowledge of the database, we could perform the same change in 75\\% less time than the expert database architect. We also exemplify the use of our approach on other planned changes.

Purpose - Most of the process models concentrate on who does what, when, i.e. on the description of the operational performance of tasks. The goal driven approaches try to establish a close relationship between the \"whys\" and the \"whats\". The former captures the strategic goals of the organisation whereas the latter tells us how they are achieved through tasks carried out by actors. In addition, managers do not naturally make the distinction between what to achieve (the goal) and the manner to achieve it (the strategy). This confusion often leads to the expression of manners as goals. In order to make clear the fundamental distinction between these two concerns and to master the complexity of process modelling, this paper seeks to propose a goal-perspective, the map-driven process modelling approach.Design methodology approach - The map representation system conforms to goal models in the fact that it recognises the concept of a goal but departs from those by introducing the concept of strategy to attain a goal.Findings - A business and its supporting system change in a concurrent way. In order to help the propagation of the intentional changes onto operational ones, we adopted the two levels hierarchical spiral process model. The intentional spiral deals with the production of the business process models using the map formalism and the operational one deals with the specifications of the supporting systems.Originality value - A business process is defined in terms of goals and strategies of reaching these goals. The approach allows choosing an appropriate level of details when analysing and redesigning business processes.

We consider requirements change due to system evolution which results from contextual forces such as the decision to standardise practices across subsidiaries of a company. Our experience with the financial branch of the French Renault group is that eliciting change requirements poses its own specific problems. We propose to model change as a set of gaps between the requirements specification of the current and the future system. Our approach is to define a generic typology of gaps to facilitate a precise definition of change requirements. It adopts a goal oriented requirements specification and shows how to customise the generic gap typology to this specific requirements representation formalism. The paper presents the approach to elicit gaps and illustrates it with the Renault case study.