144 research outputs found

    Product line architecture recovery with outlier filtering in software families: the Apo-Games case study

    Get PDF
    Software product line (SPL) approach has been widely adopted to achieve systematic reuse in families of software products. Despite its benefits, developing an SPL from scratch requires high up-front investment. Because of that, organizations commonly create product variants with opportunistic reuse approaches (e.g., copy-and-paste or clone-and-own). However, maintenance and evolution of a large number of product variants is a challenging task. In this context, a family of products developed opportunistically is a good starting point to adopt SPLs, known as extractive approach for SPL adoption. One of the initial phases of the extractive approach is the recovery and definition of a product line architecture (PLA) based on existing software variants, to support variant derivation and also to allow the customization according to customers’ needs. The problem of defining a PLA from existing system variants is that some variants can become highly unrelated to their predecessors, known as outlier variants. The inclusion of outlier variants in the PLA recovery leads to additional effort and noise in the common structure and complicates architectural decisions. In this work, we present an automatic approach to identify and filter outlier variants during the recovery and definition of PLAs. Our approach identifies the minimum subset of cross-product architectural information for an effective PLA recovery. To evaluate our approach, we focus on real-world variants of the Apo-Games family. We recover a PLA taking as input 34 Apo-Game variants developed by using opportunistic reuse. The results provided evidence that our automatic approach is able to identify and filter outlier variants, allowing to eliminate exclusive packages and classes without removing the whole variant. We consider that the recovered PLA can help domain experts to take informed decisions to support SPL adoption.This research was partially funded by INES 2.0; CNPq grants 465614/2014-0 and 408356/2018-9; and FAPESB grants JCB0060/2016 and BOL2443/201

    Automatic code generation from UML diagrams: the state-of-the-art

    Get PDF
    The emergence of the Unified Modeling Language (UML) as the de-facto standard for modeling software systems has encouraged the development of automated software tools that facilitate automatic code generation. UML diagrams are used to diagrammatically model and specify the static structure as well as the dynamic behavior of object-oriented systems and the software tools then go ahead and automatically produce code from the given diagrams. In the last two decades substantial work has been done in this area of automatic code generation. This paper is aimed at identifying and classifying this work pertaining to automatic code generation from UML diagrams, restricting the search neither to a specific context nor to a particular programming language. A Systematic literature review (SLR) using the keywords “automatic code generation”, “MDE”, “code generation” and “UML” is used to identify 40 research papers published during the years 2000–2016 which are broadly classified into three groups: Approaches, Frameworks and Tools. For each paper, an analysis is made of the achievements and the gaps, the UML diagrams used the programming languages and the platform. This analysis helps to answer the main questions that the paper addresses including what techniques or implementation methods have been used for automatic code generation from UML Diagrams, what are the achievements and gaps in the field of automatic code generation from UML diagrams, which UML diagram is most used for automatic code generation from UML diagrams, which programming language source code is mostly automatically generated from the design models and which is the most used target platform? The answers provided in this paper will assist researchers, practitioners and developers to know the current state-of-the-art in automatic code generation from UML diagrams.Keywords: Automatic Code Generation (ACG); Unified Modeling Language (UML); Model Driven Engineering (MDE

    Software Reuse in Agile Development Organizations - A Conceptual Management Tool

    Get PDF
    The reuse of knowledge is considered a major factor for increasing productivity and quality. In the software industry knowledge is embodied in software assets such as code components, functional designs and test cases. This kind of knowledge reuse is also referred to as software reuse. Although the benefits can be substantial, software reuse has never reached its full potential. Organizations are not aware of the different levels of reuse or do not know how to address reuse issues. This paper proposes a conceptual management tool for supporting software reuse. Furthermore the paper presents the findings of the application of the management tool in an agile development organization

    Systematic evaluation of software product line architectures

    Get PDF
    The architecture of a software product line is one of its most important artifacts as it represents an abstraction of the products that can be generated. It is crucial to evaluate the quality attributes of a product line architecture in order to: increase the productivity of the product line process and the quality of the products; provide a means to understand the potential behavior of the products and, consequently, decrease their time to market; and, improve the handling of the product line variability. The evaluation of product line architecture can serve as a basis to analyze the managerial and economical values of a product line for software managers and architects. Most of the current research on the evaluation of product line architecture does not take into account metrics directly obtained from UML models and their variabilities; the metrics used instead are difficult to be applied in general and to be used for quantitative analysis. This paper presents a Systematic Evaluation Method for UML-based Software Product Line Architecture, the SystEM-PLA. SystEM-PLA differs from current research as it provides stakeholders with a means to: (i) estimate and analyze potential products; (ii) use predefined basic UML-based metrics to compose quality attribute metrics; (iii) perform feasibility and trade-off analysis of a product line architecture with respect to its quality attributes; and, (iv) make the evaluation of product line architecture more flexible. An example using the SEI’s Arcade Game Maker (AGM) product line is presented as a proof of concept, illustrating SystEM-PLA activities. Metrics for complexity and extensibility quality attributes are defined and used to perform a trade-off analysis

    Featured Scents:Towards Assessing Architectural Smells for Self-Adaptive Systems at Runtime

    Get PDF
    Self-adaptive systems (SAS) change their behavior and structure at runtime to answer the changes in their environment. Such systems combine different architectural fragments or solutions via feature binding/unbinding at runtime. Moreover, this combination may negatively impact the system's architectural qualities, exhibiting architectural bad smells (ABS). These issues are challenging to detect in the code due to the combinatorial explosion of interactions amongst features. Since SAS does not document these features in their source code, design time smell detection ignores them and risks reporting smells that are different than those observed at runtime. This paper assesses this risk to understand how ABS occurs at runtime for different feature combinations. We look for cyclic dependency and hub-like ABS in various runtime adaptations of two SAS, Adasim and mRubis. Our results indicate that architectural smells are feature-dependent and that their number is highly variable from one adaptation to the other. Some ABS appear in all runtime adaptations, some in only a few. We discuss the reasons behind these architectural smells for each system and motivate the need for targeted ABS analyses in SAS.Accepted for publication at 9TH IEEE INTERNATIONAL CONFERENCE ON SOFTWARE ARCHITECTURE (ICSA 2022)

    Establecimiento del estado del arte sobre el aligeramiento de procesos de software

    Full text link
    Existen varios modelos utilizados en la mejora de procesos de software tales como CMMI e ISO/IEC 15504, cuya implementación adecuada, implica no sólo la definición de los procesos, si no también introducir a las empresas de software en el desarrollo de una cultura de mejora continua. Un camino factible que tienen estas empresas para lograr la mejora continua es la optimización de sus procesos mediante su aligeramiento. Este artículo presenta un resumen de protocolo de la revisión sistemática llevado a cabo para esta investigación, así como los resultados del análisis de estrategias para el aligeramiento de procesos de software actualmente utilizados

    Benefits and Challenges of Model-based Software Engineering: Lessons Learned based on Qualitative and Quantitative Findings

    Get PDF
    Even though Model-based Software Engineering (MBSwE) techniques and Autogenerated Code (AGC) have been increasingly used to produce complex software systems, there is only anecdotal knowledge about the state-of-thepractice. Furthermore, there is a lack of empirical studies that explore the potential quality improvements due to the use of these techniques. This paper presents in-depth qualitative findings about development and Software Assurance (SWA) practices and detailed quantitative analysis of software bug reports of a NASA mission that used MBSwE and AGC. The missions flight software is a combination of handwritten code and AGC developed by two different approaches: one based on state chart models (AGC-M) and another on specification dictionaries (AGC-D). The empirical analysis of fault proneness is based on 380 closed bug reports created by software developers. Our main findings include: (1) MBSwE and AGC provide some benefits, but also impose challenges. (2) SWA done only at a model level is not sufficient. AGC code should also be tested and the models and AGC should always be kept in-sync. AGC must not be changed manually. (3) Fixes made to address an individual bug report were spread both across multiple modules and across multiple files. On average, for each bug report 1.4 modules, that is, 3.4 files were fixed. (4) Most bug reports led to changes in more than one type of file. The majority of changes to auto-generated source code files were made in conjunction to changes in either file with state chart models or XML files derived from dictionaries. (5) For newly developed files, AGC-M and handwritten code were of similar quality, while AGC-D files were the least fault prone

    STARS:software technology for adaptable and reusable systems

    Get PDF

    On the Empirical Evidence of Microservice Logical Coupling. A Registered Report

    Full text link
    [Context] Coupling is a widely discussed metric by software engineers while developing complex software systems, often referred to as a crucial factor and symptom of a poor or good design. Nevertheless, measuring the logical coupling among microservices and analyzing the interactions between services is non-trivial because it demands runtime information in the form of log files, which are not always accessible. [Objective and Method] In this work, we propose the design of a study aimed at empirically validating the Microservice Logical Coupling (MLC) metric presented in our previous study. In particular, we plan to empirically study Open Source Systems (OSS) built using a microservice architecture. [Results] The result of this work aims at corroborating the effectiveness and validity of the MLC metric. Thus, we will gather empirical evidence and develop a methodology to analyze and support the claims regarding the MLC metric. Furthermore, we establish its usefulness in evaluating and understanding the logical coupling among microservices
    • …
    corecore