32,536 research outputs found
Analysis of Software Binaries for Reengineering-Driven Product Line Architecture\^aAn Industrial Case Study
This paper describes a method for the recovering of software architectures
from a set of similar (but unrelated) software products in binary form. One
intention is to drive refactoring into software product lines and combine
architecture recovery with run time binary analysis and existing clustering
methods. Using our runtime binary analysis, we create graphs that capture the
dependencies between different software parts. These are clustered into smaller
component graphs, that group software parts with high interactions into larger
entities. The component graphs serve as a basis for further software product
line work. In this paper, we concentrate on the analysis part of the method and
the graph clustering. We apply the graph clustering method to a real
application in the context of automation / robot configuration software tools.Comment: In Proceedings FMSPLE 2015, arXiv:1504.0301
Product line architecture recovery with outlier filtering in software families: the Apo-Games case study
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
Recovering Architectural Variability of a Family of Product Variants
A Software Product Line (SPL) aims at applying a pre-planned systematic reuse
of large-grained software artifacts to increase the software productivity and
reduce the development cost. The idea of SPL is to analyze the business domain
of a family of products to identify the common and the variable parts between
the products. However, it is common for companies to develop, in an ad-hoc
manner (e.g. clone and own), a set of products that share common
functionalities and differ in terms of others. Thus, many recent research
contributions are proposed to re-engineer existing product variants to a SPL.
Nevertheless, these contributions are mostly focused on managing the
variability at the requirement level. Very few contributions address the
variability at the architectural level despite its major importance. Starting
from this observation, we propose, in this paper, an approach to reverse
engineer the architecture of a set of product variants. Our goal is to identify
the variability and dependencies among architectural-element variants at the
architectural level. Our work relies on Formal Concept Analysis (FCA) to
analyze the variability. To validate the proposed approach, we experimented on
two families of open-source product variants; Mobile Media and Health Watcher.
The results show that our approach is able to identify the architectural
variability and the dependencies
Mapping General System Characteristics to Non- Functional Requirements
The Function point analysis (FPA) method is the preferred scheme of
estimation for project managers to determine the size, effort, schedule,
resource loading and other such parameters. The FPA method by International
Function Point Users Group (IFPUG) has captured the critical implementation
features of an application through fourteen general system characteristics.
However, Non- functional requirements (NFRs) such as functionality,
reliability, efficiency, usability, maintainability, portability, etc. have not
been included in the FPA estimation method. This paper discusses some of the
NFRs and tries to determine a degree of influence for each of them. An attempt
to factor the NFRs into estimation has been made. This approach needs to be
validated with data collection and analysis.Comment: 5 page
A Systematic Review of Tracing Solutions in Software Product Lines
Software Product Lines are large-scale, multi-unit systems that enable
massive, customized production. They consist of a base of reusable artifacts
and points of variation that provide the system with flexibility, allowing
generating customized products. However, maintaining a system with such
complexity and flexibility could be error prone and time consuming. Indeed, any
modification (addition, deletion or update) at the level of a product or an
artifact would impact other elements. It would therefore be interesting to
adopt an efficient and organized traceability solution to maintain the Software
Product Line. Still, traceability is not systematically implemented. It is
usually set up for specific constraints (e.g. certification requirements), but
abandoned in other situations. In order to draw a picture of the actual
conditions of traceability solutions in Software Product Lines context, we
decided to address a literature review. This review as well as its findings is
detailed in the present article.Comment: 22 pages, 9 figures, 7 table
Enforcing Architectural Styles in Presence of Unexpected Distributed Reconfigurations
Architectural Design Rewriting (ADR, for short) is a rule-based formal
framework for modelling the evolution of architectures of distributed systems.
Rules allow ADR graphs to be refined. After equipping ADR with a simple logic,
we equip rules with pre- and post-conditions; the former constraints the
applicability of the rules while the later specifies properties of the
resulting graphs. We give an algorithm to compute the weakest pre-condition out
of a rule and its post-condition. On top of this algorithm, we design a simple
methodology that allows us to select which rules can be applied at the
architectural level to reconfigure a system so to regain its architectural
style when it becomes compromised by unexpected run-time reconfigurations.Comment: In Proceedings ICE 2012, arXiv:1212.345
Architectural mismatch tolerance
The integrity of complex software systems built from existing components is becoming more dependent on the integrity of the mechanisms used to interconnect these components and, in particular, on the ability of these mechanisms to cope with architectural mismatches that might exist between components. There is a need to detect and handle (i.e. to tolerate) architectural mismatches during runtime because in the majority of practical situations it is impossible to localize and correct all such mismatches during development time. When developing complex software systems, the problem is not only to identify the appropriate components, but also to make sure that these components are interconnected in a way that allows mismatches to be tolerated. The resulting architectural solution should be a system based on the existing components, which are independent in their nature, but are able to interact in well-understood ways. To find such a solution we apply general principles of fault tolerance to dealing with arch itectural mismatche
Using Quantitative Methods as Support for Audit of the Distributed Informatics Systems
This paper highlights some issues regarding how an indicators system must be developed and used in an audit process. Distributed systems are presented from de points of view of their main properties, architectures, applications, software quality characteristics and the scope of audit process in such systems. The audit process is defined in accordance to standard ISO 19011 and the main characteristics of this process are highlighted. Before using quantitative methods in audit processes, the framework in which the indicators are built must be defined. There are presented types of indicators used in audit process and classes of measurement scale. An audit process is carried out on different levels and support indicators must be in accordance to audit object. The paper presents some requirements of the indicators depending on the level of audit.Quantitative Methods, Audit Process, Distributed Informatics System
- …