Recover Software Architecture Research Articles

Software Architecture Recovery Techniques

There are many software architecture recovery techniques which has been discovered which automatically recover software architecture from the software implementation. In this project we will propose a research approach for comparing different software architecture recovery techniques. A dependency (code dependency) is a file that something you are trying to install requires. It can be a library of a third-party organization. These dependencies effect the application but it is very hard to makeany software without using these external dependencies. But these code dependencies have some disadvantages too. Firstly, we will specify about the code dependencies and their impact on software design. Then we will describe some software architecture recovery techniques. We will take a project (Bash) as our research base and we will apply these recovery techniques to the project. We will use some software testing tools to compare these algorithms (software recovery techniques) with each project.

Software Architecture Module-View Recovery Using Cluster Ensembles

Software architecture documents are valuable assets supporting the maintenance process for software systems. Unfortunately, in many projects, software architecture documentation is not conducted properly or the documents become obsolete due to a discrepancy with the current architecture. To address this, various automated methods to recover software architecture have been proposed in the literature. We argue that most previous studies have not considered cluster ensembles but relied on a single clustering algorithm. In this paper, we propose to take advantage of cluster ensembles for software architecture recovery. Our experiments on five open-source projects are reported and the results are analyzed.

Runtime recovery and manipulation of software architecture of component-based systems

Recently, more attention is paid to the researches and practices on how to use software architecture in software maintenance and evolution to reduce their complexity and cost. The key in such architecture-based maintenance and evolution is to recover software architecture from existing systems. Almost all studies on architecture recovery focus on analyzing the source code and other documents. Such recovered software architecture can hardly capture runtime states and behaviors of the system. At the same time, current work pays little attention on how to change the system directly via manipulating the recovered software architecture. This paper presents a novel approach to recovering software architecture from component based systems at runtime and changing the runtime systems via manipulating the recovered software architecture. Containing much more details than the designed software architecture, the recovered software architecture can accurately and thoroughly describe the actual states and behaviors of the runtime system. It can be described formally with the extension of traditional architecture description language, which enables the recovered software architecture to absorb the semantics embedded in the designed software architecture. The recovered software architecture can be represented as multiple views so as to help different users to control the complexity from different concerns. Based on the reflective ability of the component framework, the recovered software architecture is up-to-date at any time and changes made on it will immediately lead to the corresponding changes in the runtime system. The approach presented in this paper is demonstrated on PKUAS, a reflective J2EE (Java 2 Platform Enterprise Edition) application server, and the performance is also evaluated.

Recovering software architecture from the names of source files

We discuss how to extract a useful set of subsystems from a set of existing source-code file names. This problem is challenging because many legacy systems use thousands of files names, including some that are very short and cryptic. At the same time the problem is important because software maintainers often find it difficult to understand such systems. We propose a general algorithm to cluster files based on their names, and a set of alternative methods for implementing the algorithm. One of the key tasks is picking candidate words to try to identify in file names. We do this by (a) iteratively decomposing file names, (b) finding common substrings, and (c) choosing words in routine names, in an English dictionary or in source-code comments. In addition, we investigate generating abbreviations from the candidate words in order to find matches in file names, as well as how to split file names into components given no word markers. To compare and evaluate our five approaches, we present two experiments. The first compares the ‘concepts’ found in each file name by each method with the results of manually decomposing file names. The second experiment compares automatically generated subsystems with subsystem examples proposed by experts. We conclude that two methods are most effective: extracting concepts using common substrings and extracting those concepts that relate to the names of routines in the files. Copyright © 1999 John Wiley & Sons, Ltd.

Recovering software architecture from multiple source code analyses

We describe the experiences we have had in using ManSART - a software architecture recovery tool that we developed and are employing in the analysis of large scale legacy software systems. ManSART uses a battery of standard data flow, control flow, and program slicing capabilities to automatically recover architectural features from source code. This source code analysis is enabled by representations called analysis. Analysis modules describe the interfaces of each component in a multiple component system. ManSART uses these modules to focus source code analysis and to store the results.