International audience

Since their introduction, mobile application development has become complex and now rivals web app development. The primary factor contributing to this complexity is their monolithic architecture: a mobile application is still deployed as a single unit. In contrast, web applications have adopted modular architectures such as Microservice or Micro FrontEnd (MFE). This last approach divides development into teams, each responsible for an MFE corresponding to a specific software feature. Our study examines the adoption of the MFE architecture on native mobile platforms. This paper discusses: i) how MFE can be adapted to current native mobile platforms; ii) the limitations of adapting MFE architecture on mobile; and iii) the challenges MFE introduces to mobile application development. Despite challenges in composing mobile MFEs post-deployment, our research highlighted maintaining a static development-side composite is feasible, albeit with a loss of flexibility. This allows team separation and independent feature development, though technological agnosticism isn't achieved.

The microservice-oriented architecture (MSA) is an architectural style which involves organizing an application as of small independent services, each oriented towards one business functionality while being data autonomous. In pursuit of modernizing their software to take advantage of the Cloud, companies have been eager to migrate their monolithic legacy software towards an MSA. This migration necessitates an identification phase to reorganize classes around the monolith’s functionalities as a set of microservice candidates. However, most identification approaches fail to utilize the monolith’s internal multilayered architecture to identify those functionalities, and thus the microservices. As a consequence, ignoring the internal multilayered architecture increases the risk of identifying microservice by their technical layer which is recognized as a conceptual anti-pattern. In this paper, we explore the impact of the multi-layer architecture in monolithic applications during the identification to develop a semi-automatic approach that relies on it to identify an MSA. Particularly, we analyze the presentation layer to determine the endpoints of each business functionality of the monolith. From these endpoints, we apply a vertical decomposition to identify the necessary classes to implement each feature as a microservice. In the process, we also define the bounded context of each microservice during the vertical decomposition of the data-access layer. For the evaluation, we implemented a model-driven process and applied it on a set of varying open-source applications commonly used in the literature. We compared the results of approach with and without the reverse-engineering of the internal architecture to measure the impact of our approach on the identification of quality microservices. Using decomposition metrics (e.g., MoJoFM, c2ccvg), we were able to measure a significant positive impact.

Formal Concept Analysis (FCA) has been introduced for almost a decade as a suitable method for Feature Location (FL) on a collection of product variants. Even though FCA-based FL techniques allow to locate the core of a feature implementation, they do not propose a solution to trace feature interactions to their implementation. Thus, the extracted traceability links (traces) are too inaccurate, and, in the context of SPL extraction, cannot be used to generate complete products.

International audience

Due to its tremendous advantages, microservice architectural style has become an essential element for the development of applications deployed on the cloud and for those adopting the DevOps practices. Nevertheless, while microservices can be used to develop new applications, there are monolithic ones, that are not well adapted neither to the cloud nor to DevOps. Migrating these applications towards microservices appears as a solution to adapt them to both. In this context, we propose an approach aiming to achieve this objective by focusing on the step of microservices identification. The proposed identification, in this paper, is based on an analysis of the relationships between source code elements, their relationships with the persistent data manipulated in this code and finally the knowledge, often partial, of the architect concerning the system to migrate. A function that measures the quality of a microservice based on its ability to provide consistent service and its interdependence with others microservice in the resulting architecture was defined. Moreover, the architect recommendations are used, when available, to guide the identification process. The conducted experiment shows the relevance of the obtained microservices by our approach.

International audience

The reuse at the component level is generally more effective than the one at the object-oriented class level. This is due to the granularity level where components expose their functionalities at an abstract level compared to the fine-grained object-oriented classes. Moreover, components clearly define their dependencies through their provided and required interfaces in an explicit way that facilitates the understanding of how to reuse these components. Therefore, several component identification approaches have been proposed to identify components based on the analysis object-oriented software applications. Nevertheless, most of the existing component identification approaches did not consider co-usage dependencies between API classes to identify classes/methods that can be reused to implement a specific scenario. In this paper, we propose an approach to identify reusable software components in object-oriented APIs, based on the interactions between client applications and the targeted API. As we are dealing with actual clients using the API, dynamic analysis allows to better capture the instances of API usage. Approaches using static analysis are usually limited by the difficulty of handling dynamic features such as polymorphism and class loading. We evaluate our approach by applying it to three Java APIs with eight client applications from the DaCapo benchmark. DaCapo provides a set of pre-defined usage scenarios. The results show that our component identification approach has a very high precision.

International audience

Modularity in Object-Oriented (OO) applications has been a major concern since the early years of OO programming languages.Migrating existing OO applications to Component-Based (CB) ones can contribute to improve modularity, and therefore maintainability and reuse.In this paper, we propose a method for source code transformation (refactoring) in order to perform this migration.This method enhances decoupling by considering that some dependencies between classes should be set through abstract types (interfaces) like in CB applications.In addition, some anticipated instantiations of these classes "buried" in the source code are extracted and replaced by declarative statements (like connectors in CB applications) which are processed by a dependency injection mechanism.For doing so, a set of "Bad Smells", i.e., modularity-violating symptoms, has been defined.These are first detected in the source code.Then, some refactoring operations are applied for their elimination.An implementation of the method was successfully experimented on a set of open source Java projects.The results of this experimentation are reported in this paper.

Usually, companies meet different customer needs in a particular domain by developing variants of a software product.This is often performed by ad-hoc copying and modifying of various existing variants to fit purposes of new one.As the number of product variants grows, such an adhoc development causes severe problems to maintain these variants.Software Product Line Engineering (SPLE) can be helpful here by supporting a large-scale reuse systematically.SPL architecture (SPLA) is a key asset as it is used to derive architecture for each product in SPL.Unfortunately, developing SPLA from scratch is a costly task.In this paper, we propose an approach to contribute for recovering SPLA from existing product variants.This contribution is two-fold.Firstly, identifying common features and variation points of features of a given collection of product variants.Secondly, exploiting commonality and variability in terms of features to identify mandatory components and variation points of components as an important step in this recovering process.To evaluate the proposed approach, we applied it to two case studies.The experimental results bring evidence the effectiveness of our approach.

Large object-oriented applications have complex and numerous dependencies, and usually do not have explicit software architectures. Therefore they are hard to maintain, and parts of them are difficult to reuse. Component-based development paradigm emerged for improving these aspects and for supporting effective maintainability and reuse. It provides better understandability through a high-level architecture view of the application. Thereby migrating object-oriented applications to component-based ones will contribute to improve these characteristics (maintainability and reuse). In this paper, we propose an approach to automatically transform object-oriented applications to component-based ones. More particularly, the input of the approach is the result provided by software architecture recovery: a component-based architecture description. Then, our approach transforms the object-oriented source code in order to produce deployable components. We focus in this paper on the transformation of source code related to instantiation and inheritance dependencies between classes that are in different components. We experimented the proposed solution in the transformation of a collection of Java applications into the OSGi framework. The experimental results are discussed in this paper.

Reconciling Software Product Lines (SPL) and Service Oriented Architecture (SOA) allows modeling and implementing systems that systematically adapt their behavior in respond to surrounding context changes.Both approaches are complementary with regard to the variability and the dynamicity properties.Architecture Description Language (ADL), on the other hand, is recognized as an important element in the description and analysis of software properties.Different ADLs have been proposed in SOA or in SPL domains.Nevertheless, none of these ADLs allows describing variability and dynamicity features together in the context of service-oriented dynamic product lines.In this sense, our work attempts to describe the changing architecture of Dynamic Service-Oriented Product Lines (DSOPL).We propose an ADL that allows describing three types of information: architecture's structural elements, variability elements and system's configuration.Furthermore, we introduce context elements on which service reconfiguration is based.

Software Product Line Engineering (SPLE) is a systematic reuse approach to develop a short time-to-market and quality products, called Software Product Line (SPL). Usually, a SPL is not developed from scratch but it is developed by reusing features (resp. their implementing source code elements) of existing similar systems previously developed by ad-hoc reuse techniques. The features implementations that are reused may be changed for developing new products (SPL) using SPLE. Any code element can be a part of (shared by) different features implementations; modifying one feature's implementation can thus impact others. Therefore, feature-level Change Impact Analysis (CIA) is important to predict affected features for change management purpose. In this paper, we propose a feature-level CIA approach using Formal Concept Analysis (FCA) applied to SPL evolution. In our experimental evaluation using three case studies of different domains and sizes, we show the effectiveness of our technique in terms of the most commonly used metrics on the subject.

Companies often develop a set of software variants that share some features and differ in others to meet specific requirements. To exploit the existing software variants as a Software Product Line (SPL), a Feature Model of this SPL must be built as a first step. To do so, it is necessary to define and document the optional and mandatory features that compose the variants. In our previous work, we mined a set of feature implementations as identified sets of source code elements. In this paper, we propose a complementary approach, which aims to document the mined feature implementations by giving them names and descriptions, based on the source code elements that form feature implementations and the use-case diagrams that specify software variants. The novelty of our approach is its use of commonality and variability across software variants, at feature implementation and use-case levels, to run Information Retrieval methods in an efficient way. Experiments on several real case studies (Mobile media and ArgoUML-SPL) validate our approach and show promising results.

International audience

Despite that reuse libraries are now well adopted during software development step, software evolution step is not yet covered by this kind of beneficial approach. In this paper we present the "evolution shelf", a generic infrastructure to achieve for-reuse and by-reuse techniques within the field of software evolution. The basic idea behind that is to propose and encourage the reuse of recurring and reliable evolution expertises to achieve the structural evolution of a software system at the architectural level. For that purpose, the shelf assists architects in classifying, storing and selecting reusable architectural evolution operations. The underlying concept that we propose to capitalize the expertises is called "evolution style" and it mixes a syntactic and a semantic description format. These ideas form a core for a long-term vision in which it is possible to build a business model of evolution-of-the-shelf (EOTS) with the special objective to decrease the efforts and the risks related to the evolution activities.

Software architecture modeling and representation became a main phase of the development process of complex systems. In fact, software architecture representation provides many advantages during all phases of software life cycle. Nevertheless, for many systems, like legacy or eroded ones, there is no available representation of their architectures. In order to benefit from this representation, we propose, in this paper, an approach called ROMANTIC which focuses on extracting a component-based architecture of an existing object-oriented system. The main idea of this approach is to propose a quasi-automatic process of architecture recovery based on semantic and structural characteristics of software architecture concepts.

Adapting software components to be used in a particular application is a crucial issue in software component-based technology. In fact, software components can be used in contexts with characteristics different from those envisaged when designing the component. To deal with this issue, we propose in this paper an approach aiming at adapting a software component structure in order to preserve service continuity. This adaptation, achieved by component fragmentation, allows its structure reconfiguration and its redeployment while preserving its behavior and its services. The structural adaptation process is based on two phases. The first one consists of the component re-engineering in order to introduce runtime adaptation facilities. The second phase, achieved since runtime, aims at reconfiguring the component structure according to the user needs.

We propose in this article an object-oriented approach to rewriting queries using views. Our approach aims to mitigate certain limitations of existing query rewriting approaches. Among these limitations, the inconsideration of certain types of object-oriented complex queries or the lack of uniformity of this approaches compared to the object-oriented model.

Query formulation remains obstinately difficult for large classes of users. Indeed, with the exception of approaches facilitating syntax problems, there is a noticeable absence of models taking charge of the user through from specification of their needs to formulation of their queries. In this article, we take a novel look to object-oriented queries — reifying the ones which users formulate as components then reusing them, by means of strategies for selecting, assembling and adapting them to help in the formulation of new complex queries.

Query formulation remains obstinately difficult for large classes of users. Indeed, in face of the growth in query complexity due to development of new kind of application manipulating great size of data, we notice the absence of models taking charge of the user through from specification of needs to formulation of queries. We think that users can be given effective help in query formulation by means of re-using former queries. Indeed, the objective of this work is to propose a method of assisting users to formulate queries by accessing and re-using existing ones. It consists of making available to users query components plus a strategy for re-using them. The approach developed here lies within the scope of re-use development environments. The model developed incorporates knowledge defining query components and ways to select, adapt or combine them to meet particular requirements.

In database or knowledge-base systems, query formulation languages are the means offered to users for accessing data or knowledge. Queries allow selection of data under particular, either simple or complex constraints, resulting from one or several structures. However, query formulation remains obstinately difficult for large classes of users. Indeed, with the exception of approaches facilitating syntax problems, there is a noticeable absence of models taking charge of the user through specification of their needs to formulation of their queries. In the case of object-oriented database systems, whose data models and concepts are more complex than those of relational databases, database users need assistance with several kinds of formulation problems. In this respect, we consider that the storage and reuse of former queries constitutes a promising avenue of investigation. We take a novel look at object-oriented queries, reifying the ones which users formulate as components then reusing them, by means of strategies for selecting, assembling and adapting them to help in the formulation of new complex queries.

We propose an approach facilitating query formulation for users sharing a common database. Our approach is based on two considerations. On the one hand, query formulation can be considered as a skill which can be shared entirely or partly between users. Accordingly we propose a model for storing and making available this skill to help users formulate their new queries. On the other hand we base our design on custom construction of a database adapted to each business group of users in question. In using it, the users of a given business cooperate transparently through their queries to design databases specific to their business. Thus, they take part co-operatively if indirectly in reducing the difficulty of query formulation.