What to Fix? Distinguishing between design and non-design rules in automated tools

Technical debt---design shortcuts taken to optimize for delivery speed---is a critical part of long-term software costs. Consequently, automatically detecting technical debt is a high priority for software practitioners. Software quality tool vendors have responded to this need by positioning their tools to detect and manage technical debt. While these tools bundle a number of rules, it is hard for users to understand which rules identify design issues, as opposed to syntactic quality. This is important, since previous studies have revealed the most significant technical debt is related to design issues. Other research has focused on comparing these tools on open source projects, but these comparisons have not looked at whether the rules were relevant to design. We conducted an empirical study using a structured categorization approach, and manually classify 466 software quality rules from three industry tools---CAST, SonarQube, and NDepend. We found that most of these rules were easily labeled as either not design (55%) or design (19%). The remainder (26%) resulted in disagreements among the labelers. Our results are a first step in formalizing a definition of a design rule, in order to support automatic detection.Comment: Long version of accepted short paper at International Conference on Software Architecture 2017 (Gothenburg, SE

Property-Part Diagrams: A Dependence Notation for Software Systems

Some limitations of traditional dependence diagrams are explained, and a new notation that overcomes them is proposed. The key idea is to include in the diagram not only the parts of a system but also the properties that are assigned to them; dependences are shown as a relation not from parts to parts, but between properties and the parts (or other properties) that support them. The diagram can be used to evaluate modularization in a design, to assess how successfully critical properties are confined to a limited subset of parts, and to structure a dependability argument.

Concern-oriented analysis and refactoring of software architectures using dependency structure matrices

Current scenario-based architecture analysis methods analyze the architecture with respect to scenarios that relate to stakeholder concerns. Albeit the primary motivation is to analyze the impact of stakeholders' concerns, it appears that concerns are not explicitly represented as first class abstractions. The lack of an explicit notion of concern in scenario-based analysis approaches can result in an incomplete analysis because scenarios are too specific and can only partially represent the concerns. We propose the concern-oriented architecture analysis method (COSAAM) that builds on scenario-based approaches but includes an explicit notion of concern in the analysis. COSAAM applies Dependency Structure Matrices (DSMs) to represent and analyze the dependencies among scenarios, concerns and architectural elements. Further, COSAAM extends DSMs by introducing explicit DSM patterns and heuristic rules for analyzing the impact of concerns on the architecture and for supporting the refactoring of the architecture. Copyright 2009 ACM

Using hypergraph clustering for software architecture reconstruction of data-tier software

Software architecture reconstruction techniques aim at recovering software architecture documentation regarding a software system. These techniques mainly analyze coupling/dependencies among the software modules to group them and reason about the high-level structure of the system. Hereby, inter-dependencies among the software modules are mainly represented with design structure matrices or regular directed/undirected graphs. In this paper, we introduce a software architecture reconstruction approach that utilizes hypergraphs for representing inter-module dependencies. We show that these models are more appropriate for capturing dependencies other than direct call relations. We illustrate the application of the approach with an industrial PL/SQL program from the telecommunications domain. PL/SQL programs are mainly composed of procedures that are coupled due to commonly accessed database elements. We analyze and represent these dependencies in the form of a hypergraph. Then, we perform modularity clustering on this model and propose a packaging structure to the designer accordingly. We observed promising results in comparison with previous work. The accuracy of the results were also approved by domain experts. Turkey http://www.turkcell.com.tr Kaya [email protected] Turkey Sabanci University ://people.sabanciuniv.edu/kaya/ [email protected] Turkey Turkcell http://www.turkcell.com.tr Hasan Sozer [email protected] Turkey Ozyegin University http://faculty.ozyegin.edu.tr/hsozer

Exadat: Análisis de Variabilidad en Persistencia de Productos de Software

Existe una tendencia mundial hacia el desarrollo y evolución de familias de productos en lugar de la creación de un producto de software para un cliente específico. Sin embargo, es común la construcción de tal familia a partir de varios sistemas a medida. Además, estas implementaciones usualmente carecen de la documentación de la arquitectura implementada. A partir de esta problemática se plantea en este trabajo la identificación de familia de productos de software desde una perspectiva de persistencia. El enfoque propuesto utiliza mecanismos de ingeniería reversa para reconstruir la arquitectura del producto implementado. A partir de la arquitectura se identifican posibles puntos de variación y variantes implicadas en la persistencia de datos.Sociedad Argentina de Informática e Investigación Operativ