Automated Recovery of Software System Designs

Architectural Recovery Using Concerns

approach

The effort and cost of software maintenance tends to dominate other activities in a software system’s lifecycle. A critical aspect of maintenance is understanding and updating a software system’s architecture. However, the maintenance of a system’s architecture is exacerbated by the related phenomena of architectural drift and erosion, which are caused by careless,  unintended addition, removal, and/or modification of architectural design decisions. These phenomena make the architecture more difficult to understand and maintain and, in more severe cases, can lead to errors that result in wasted effort or loss of time, money, even lives.  To determine the current architecture of a software system, we have developed a recovery technique called ARC (Architectural Recovery using Concerns). ARC uses a representation of a software system’s concerns, information retrieval, and machine learning to recover the software architecture of a system from source code.

Read the paper here:
Joshua Garcia, Daniel Popescu, Chris Mattmann, Nenad Medvidovic, and Yuanfang Cai. Enhancing architectural recovery using concerns. In Proceedings of the 26th International Conference on Automated Software Engineering (ASE), September 2011.

Comparing Software Architecture Recovery Techniques

Many software architecture recovery techniques have been produced for many than three decades to help deal with the problem of architectural drift and erosion.  Previous comparative studies while informative and providing preliminary hints as to the respective quality of different recovery techniques—have been limited in a number of ways. First, these analyses disagree as to which techniques are most accurate. Second, they do not elaborate the conditions under which each technique excels or falters. Third, the quality of the “ground truths” on which these studies base their conclusions is questionable. Fourth, previous comparative analyses have been limited in terms of scale (i.e., the numbers and sizes of systems selected, or the number of techniques evaluated).

To address these shortcomings, we performed the first comprehensive comparative analysis of software architecture recovery techniques along eight ground-truth architectures of six open source systems. For the comparative analysis, we selected a set of six state-of-the-art software architecture recovery techniques and a number of metrics to assess each technique for its  ability to identify a system’s architectural components and overall architectural structure. Our results suggest that two of the techniques routinely outperform the rest, but even the best of the lot has surprisingly low accuracy. Based on the empirical data, we identify several avenues of future research in software architecture recovery.

Read the paper here:
Joshua Garcia, Igor Ivkovic, and Nenad Medvidovic. A Comparative Analysis of Software Architecture Recovery Techniques. In Proceedings of the 28th International Conference Automated Software Engineering (ASE), November 2013.

Ground-Truth Architectures

Undocumented evolution of a software system and its underlying architecture drives the need for the architecture’s recovery from the system’s implementation-level artifacts. While a number of recovery techniques have been proposed, they suffer from known inaccuracies. Furthermore, these techniques are difficult to evaluate due to a lack of “ground-truth” architectures that are known to be accurate. To address this problem, we argue for establishing a suite of ground-truth architectures, using a recovery framework proposed in our recent work. This framework considers domain-, application-, and context-specific information about a system, and addresses an inherent obstacle in establishing a ground-truth architecture — the limited availability of engineers who are closely familiar with the system in question. In this work, we present our experience in recovering the ground-truth architectures of four open-source systems. We discuss the primary insights gained in the process, analyze the characteristics of the obtained ground-truth architectures, and reflect on the involvement of the systems’ engineers in a limited but critical fashion. Our findings suggest the practical feasibility of obtaining ground-truth architectures for large systems and encourage future efforts directed at establishing a large scale repository of such architectures.

Read the paper here:
Joshua Garcia, Ivo Krka, Chris Mattmann, and Nenad Medvidovic. Obtaining Ground-Truth Software Architectures. In Proceedings of the 35th International Conference on Software Engineering (ICSE), Software Engineering in Practice Track, May 2013.

Message Flow in Distributed Event-Based Systems

eos_diagrams_web_crop

Distributed event-based (DEB) systems contain highly-decoupled components that interact by exchanging messages. This enables the development of scalable, adaptable, concurrent, and heterogeneous distributed applications, but also makes DEB systems difficult to maintain. Most existing program analysis techniques to support maintenance are not well suited to DEB systems, while those that are tend to suffer from inaccuracy or make assumptions that limit their applicability. To aid in maintenance of DEB systems, we created Eos, a static analysis technique that identifies message information useful for maintaining a DEB system, namely, message types and message flow within a system. Eos has been evaluated on six off-the-shelf DEB systems spanning five different middleware platforms, and has exhibited excellent accuracy and efficiency. Furthermore, a case study involving a range of maintenance activities undertaken on three existing DEB systems shows that, on average, Eos enables an engineer to identify the scope and impact of required changes more accurately than existing alternatives.

Read the paper here:
Joshua Garcia, Daniel Popescu, Gholamreza Safi, William G.J. Halfond, and Nenad Medvidovic. Identifying Message Flow in Distributed Event-Based Systems. In Proceedings of 9th joint meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE 2013), August 2013.

300-320  
220-902  
NS0-157  
70-532  
101-400  
70-413  
70-461  
400-101  
300-208  
CCA-500  
EX300  
1Z0-804  
200-125  ,
102-400  
AWS-SYSOPS  
EX300  
200-101  
300-115  
220-801  
100-105  ,
CCA-500  
70-410  
9L0-066  
70-178  
2V0-621D  
100-101  
JK0-022  
ITILFND  
70-417  
NS0-157  
220-802  
AWS-SYSOPS  
70-462  
350-030  
300-135  
ITILFND  
HP0-S42  
101  
210-060  
350-001  
70-246  
300-320  
220-802  
200-310  
2V0-621D  
1Z0-060  
350-029  
101-400  
MB2-704  
70-417  
70-534  
MB6-703  
200-125   ,
220-902   ,
100-105   ,
220-902   ,
300-101   ,
220-902   ,
810-403   ,
200-105   ,
642-996   ,
300-075   ,
300-070   ,
642-996   ,
300-115   ,
642-996   ,
MB2-712   ,
642-997   ,
300-115   ,
300-208   ,
300-365   ,
300-365   ,
SY0-401   ,
SY0-401   ,