Document-oriented bases allow high flexibility in data representation which facilitates a rapid development of applications and enables many possibilities for data structuring. Unfortunately, in many cases, due to this flexibility and the absence of data modelling, the choice of a data representation is neglected by developers leading to many issues on several aspects of the document base and application quality; e.g., memory print, data redundancy, readability and maintainability. We aim at facilitating the study of data structuring alternatives and providing objective metrics to better reveal the advantages and disadvantages of a structure with respect to user needs. The main contributions of our approach are twofold. First of all, the semi-automatic generation of many suitable alternatives for data structuring given an initial UML model. Second, the automatic computation of structural metrics, allowing a comparison of the alternatives for JSON-compatible schema abstraction. These metrics reflect the complexity of the structure and are intended to be used in decision criteria for schema analysis and design process. This work capitalises on experiences with MongoDB, XML and software complexity metrics. The paper presents the schema generation and the metrics together with a validation scenario where we discuss how to use the results in a schema recommendation perspective.

Abstract New code in projects can introduce violations that deviate the code implementation from the intended architecture. This process is known as architecture erosion. In this article, we propose an approach for recovering the implemented architecture, and detecting violations when comparing it with the intended architecture. Given a code repository, the continuous integration pipeline calls the solution to detect the incidences of architecture violations as well as some quality and social metrics. This data is presented in metric‐centered views that help development teams to manage architecture erosion. Our approach is based on model‐driven engineering techniques since models serve to represent the code, and a model‐based pattern language helps us to automate the search for violation occurrences and execute corresponding actions (e.g., creation/assignment of issues). We confirm the approach benefits in a real project implemented by a software developing company, in a sample project available on the internet, and in a software development course, including 20 projects, where every single project decreases its architecture violations density through time.

Abstract The migration of software is an economically important niche since the daily operations of many business still rely on systems based on legacy technologies. Migration to more recent technologies comes with major technical and management challenges mainly related to knowledge‐loss issues on the specific technology but also on the architecture and design of the legacy. This article presents a method that addresses the reverse/forward engineering tasks as well as some management challenges such as the planning of the migration based on a better understanding of the system. The process relies on the use of models and transformations to create high‐level abstraction views of the legacy. A big challenge with the migration of certain legacy applications is that much of the business logic is inside triggers which are written in the PL/SQL language and scattered across the application layers. Therefore, developers need to know what they need to migrate and where it is. The main contribution of our work is that the abstractions allow developers to understand and plan the migration without the need of having a vast knowledge on the initial technology. Furthermore, our views help developers to decide about the structure and business logic they want to have in the target system. In this article, we describe the application of the method to the Oracle Forms case study. Nevertheless, the approach can be generalized to other technologies through new bridges that transform from said technologies to the abstract views. The article ends by reporting lessons learned from our experience.

Large Internet companies like Amazon, Netflix, and LinkedIn are using the microservice architecture pattern to deploy large applications in the cloud as a set of small services that can be developed, tested, deployed, scaled, operated and upgraded independently. However, aside from gaining agility, independent development, and scalability, infrastructure costs are a major concern for companies adopting this pattern. This paper presents a cost comparison of a web application developed and deployed using the same scalable scenarios with three different approaches: 1) a monolithic architecture, 2) a microservice architecture operated by the cloud customer, and 3) a microservice architecture operated by the cloud provider. Test results show that microservices can help reduce infrastructure costs in comparison to standard monolithic architectures. Moreover, the use of services specifically designed to deploy and scale microservices reduces infrastructure costs by 70% or more. Lastly, we also describe the challenges we faced while implementing and deploying microservice applications.

Nowadays, software development teams face the challenge of maintenance and evolution of large applications. This is known as modernization and comprises a process of understanding the existing application, and a process of transforming from the as-is state to the to-be state. In this article, we present an approach to modernize legacy applications into microservices. We propose a model-centered process to analyze and visualize the current structure and dependencies between the business layer and the data layer. Furthermore, we propose a modularization into clusters and microservices using four different diagrams. To validate our approach we have analyzed a JEE application with over 74566 LoC. The results show that the understanding is greatly improved through the diagrams proposed, and the modularization proposed constitutes the first step towards the automated modernization of the application.

A Schema-less NoSQL system refers to solutions where users do not declare a database schema and, in fact, its management is moved to the application code. This paper presents a study that allows us to evaluate, to some extent, the data structuring impact. The decision of how to structure data in semi-structured databases has an enormous impact on data size, query performance and readability of the code, which influences software debugging and maintainability. This paper presents an experiment performed using MongoDB along with several alternatives of data structuring and a set of queries having increasing complexity. This paper introduces an analysis regarding the findings of such an experiment.

Electrical Transformers are complex devices that exhibit an enormous variability depending on the intended power transformation, environmental conditions, standards imposed and customer particularities. Incomplete information or inconsistencies in the specifications can lead to re-processes and higher bid times. This paper presents our experience on using multiple feature models to specify custom Electrical Transformer as a Configuration Process. This process facilitates the elicitation of knowledge from multidisciplinary experts using several feature models, one per domain and per standard and defining relationships among them. This separation of domains eases the analysis and validation of the models. To support the process, we have developed some tools to separate, merge and analyze these models. The final feature models are tested configuring and comparing products from existing company catalogs. We consider that the same strategy can be used in other contexts where experts on multiple disciplines participate.

Model-based solutions are becoming more sophisticated because of the advent of new types of models, languages, and editors. To deal with this complexity, some of the current Integrated Development Environments (IDEs) offer Model Management Systems (MMSs) that provide functionalities to visualize, navigate, and search the modeling artifacts existing in a workspace. Each MMS defines the types of modeling artifacts that it supports and, commonly, furnishes extensibility mechanisms for including new ones. However, the use of those mechanisms usually requires a big implementation effort. As a result, when an MMS does not support all the types of modeling artifacts that a model-driven engineer uses, he/she discards it and ends up manipulating his/her solution through file system views which is not appropriate when projects become larger. In this paper we present some of our preliminary results towards the construction of MoMS-DL, a domain-specific language to define (and automatically generate) customized Eclipse-based MMSs improving the daily work of model-driven engineers.

The participation of women in undergraduate program of Systems and Computing Engineering at the University of los Andes, Colombia, has been declining over the past years, and today it is only about 11%. This phenomenon has been evidenced in many universities around the world and there are several collaborative projects and networks trying to understand the causes to find mitigation actions in the future. In this paper, we present progress of the project being done in our context. We present figures for the last two decades that show the problem, the instruments we have defined to understand the causes and some preliminary results.

The use of reconfigurable platforms for embedded system design leverages product line engineering (PLE), in which the development of products starts from a set of core assets (the platform) rather than the development of individual products from zero. Two major activities of PLE are domain engineering (i.e., platform development) and product engineering (i.e., product customization) reusing the core assets. Virtual prototyping in PLE allows rapid validation of both the platform and individual products with greater benefits in development costs, time to market and quality. However, since virtual prototypes (VP) are implemented in low-level languages, if platform development and product engineering are done at this level, productivity is negatively affected. A commonly-accepted solution for closing this productivity gap is to raise the level of abstraction in the whole design process and to automate the implementation of VPs from the high-level descriptions. In this paper, we present the HiLeS2 Framework, which is based on Model Driven Software Product Lines (MD-SPL) concepts. HiLeS2 framework provides an environment for domain and product engineering, automated construction of VPs and creation of product line integrated development environments.

Workflow monitoring and analysis concerns aim at identifying potential improvements of workflow applications. This paper presents an approach to specify and implement monitoring and analysis concerns on workflow applications raising the level of abstraction for workflow analysts. First, the specification of monitoring and analysis concerns is declared in a technology-independent way with a domain-specific language named MonitA. MonitA makes extensive use of the data available in the workflow application and its constituents to enhance the monitoring and analysis specifications. Second, we defined and implemented a strategy to assist developers to enhance a given workflow technology to support the generation of the monitoring and analysis code and its composition with the workflow application. This instrumentation-based approach enables the monitoring and analysis of workflow applications during their operational execution. We illustrate the flexibility of our approach by targeting different workflow platforms and different workflow applications.

In workflow management systems, analysis concerns related to monitoring, measurement, and control aim at identifying potential improvements of workflow applications. However, the specification of analysis concerns is done using a specific workflow language and engine, producing entangled code which is detrimental to their maintainability. The purpose of this paper is twofold. First, it presents briefly a domain-specific language to specify analysis concerns, independently of any workflow technology and in a modularized way. Second, it shows a strategy to assist developers to enhance a given workflow technology to support the automated implementation of analysis concerns into its workflow applications. Thus, given a workflow application and its analysis concerns, they are automatically integrated producing an enhanced executable workflow application.