4.2.1 Software architecture reconstruction

Software architecture reconstruction is a reverse engineering process which aims to obtain the architecture information of any system using existing other source artifacts [7]. Fig. 4.1 shows a conceptual model for architecture reconstruction.

An architecture reconstruction process uses different source artifacts which are input for the SAR process such as code, detailed design, logs, documentation, and stakeholder concerns. Two basic motivations for SAR can be identified, that is, missing or incomplete architecture documentation, or an architecture drift due to evolution of the requirements. Since manual handling of architecture reconstruction is usually time consuming and costly, fully or semiautomatized methods and tools are implemented. The result of the SAR process is an architecture documentation that includes a description of a set of architecture views for addressing stakeholder concerns [27]. An architecture view conforms to an architecture viewpoint. Architecture views can be visual or textual [5].

4.2.2 Domain analysis

A well-known process for analyzing and modeling the current state of the art of a particular domain is domain analysis. Domain analysis is the process of identifying, capturing domain knowledge about the problem domain with the purpose of making it reusable when creating new systems [4,18,31,21]. Domain here refers to “an area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area.” Several domain analysis processes have been defined in the literature, but in general these include the steps for (1) domain scoping and (2) domain modeling. Fig. 4.2 shows the overall domain analysis process that we will adopt.

In domain scoping it is explicitly described what will be considered in the domain and likewise the scope will be determined. This will include also the selection of the primary studies that will be used to analyze the domain. In the domain modeling process, usually a commonality and variability analysis process is carried out to derive a domain model. With the commonality and variability analysis process the identified primary studies are simultaneously analyzed to identify common and variant features of a domain [32]. A feature model is a model that defines features and their dependencies. A feature is a system property that is relevant to some stakeholder and is used to capture commonalities or discriminate between them. Feature models are usually represented in feature diagrams (or tables). A feature diagram is a tree with the root representing a concept (e.g., a software system), and its descendent nodes are features. Various relationships between a parent feature and its child features (or subfeatures) are defined, including mandatory, optional, or, and alternative. A feature configuration is a selected set of features which describes an instance of the feature diagram. Cross-tree constraints further restrict the possible selections of features to define configurations. The most common cross-tree constraints are requires and excludes.

4.3.1 Domain scoping

As discussed before, the domain scoping defines what will be considered in the domain and likewise the scope will be determined. Our key concern in this study is architecture reconstruction and in particular we focus on the process and the corresponding tools. In the scoping process we have used different reputable and most cited libraries, including IEEE Explore, ACM, Science Direct, Springer, WebOfKnowledge, and Wiley. In these platforms we have searched for papers related to software architecture reconstruction. We have created search strings including the terms “software architecture reconstruction” and “software architecture recovery” in abstract of papers. After a careful analysis of the selected papers according to exclusion criteria we have derived the list of papers as shown in Appendix 4.A – Primary studies. We have thoroughly read these papers and applied the commonality and analysis for deriving the common and variant concepts related to SAR. The result of the data extraction process is described using a domain which is explained in the next subsection. Table 4.1 provides our exclusion criteria for the study selection process. We further filtered out the query results according to these defined criteria. Table 4.2 presents the number of study selections after applying search queries and exclusion criteria. Seventeen studies were singled out of 652 studies after applying the exclusion criteria.

4.3.2 Feature model

Fig. 4.3 shows the feature model of SAR methods that we have derived from the domain analysis process.

A SAR method consists of the mandatory features of goal, source artifacts, adopted method, process steps, and architecture model and one optional feature of architecture model.

The goal feature defines the aim of the SAR and why the SAR is actually applied. The goal of the SAR method can be architecture redesign, system modernization, refactoring, and architecture nonconformity identification. Architecture redesign is a process for enhancing, adapting, or revising the current architecture. Architecture redesign can be applied when underlying system architecture does not perform as desired against the current or future requirements. Refactoring is a software development process where the low-level components are rearranged without changing the functionality of the program code. Refactoring is heavily used in industry, which makes the code more readable and adaptable to further changes in the requirements. System modernization is a software process in which the current systems architecture and used technology stack are adapted to the current requirements and the current state of the system is maintained. At last, architecture nonconformity identification is a process that aims to find differences between intended and implemented architecture. These differences can be crucial and can lead to bugs, defects, or errors. One or more of the defined goals can be valid for a SAR method.

Source artifacts are artifacts that are used to (re)construct an architecture. Code, logs, documentations, and stakeholder concerns are source artifacts for SAR methods. SAR methods can use one or more of these artifacts to extract architectural elements which can be represented by architectural models. Code is an executable that is written according to a programming language. Code of systems are implemented with respect to their specifications in architecture designs. Logs are output data from systems which might give insight about system architecture. Documentation shows textual information about systems which can be architecture designs and functional and nonfunctional requirements. Stakeholders are individuals, groups, people, or organizations that have an interest in the developed system. Stakeholder concerns shape how the architecture is designed and implemented. The SAR method can have one or more of these source artifacts to reconstruct the system's architecture.

Adopted methods represent techniques applied for reconstructing the system architecture. Various methods have been implemented and proposed in the literature for SAR. These include clustering, partitioning, data mining, querying, or scripting. These methods can be used together or separately. Clustering methods consist of grouping some related data together. Partitioning is dividing data into parts that may or may not be related to each other. In SAR data mining techniques are adopted in which patterns are detected in large sets of source codes, logs, and documentation. Some of the SAR methods also utilize querying on graphs in which the architecture is represented as graph-based models. Scripting software architectures in their own domain-specific languages is another method adopted by SAR methods.

Process steps define phases used in a SAR method. SAR methods usually consist of a series of different processes including preprocessing, architecture extraction, architecture analysis, architecture visualization, and suggestions. Preprocessing is an optional step in which the source artifact might be prepared for the architecture extraction step. This can include reformatting, removing unnecessary libraries, and removing comments. Architecture extraction is performed on source artifacts; the valuable data are extracted from these artifacts and hence it is a mandatory step in all SAR methods. In the architecture analysis step architecture components are formed using the output of the extraction step. The architecture visualization step presents the reconstructed architecture in a user-friendly manner, which can be graphical or textual. Visualization of the reconstructed architecture is not always present; thus this feature is optional. Another optional feature in process steps is suggestions. Suggestions such as design pattern application, architecture pattern application, or code refactoring can be advised after the architecture is constructed.

Architecture model representation defines the representation used for describing the architecture. The adopted SAR methods in the primary studies use different representations, including Unified Modeling Language (UML), XML Metadata Interchange (XMI), MetaObject Facility (MOF), or graph representations. UML is the standardized model to represent the software architecture which contains diagrams for developers to develop, construct, and document the architectures. XMI is designed for exchanging information using extensible markup languages. Software architectures can be represented and visualized using XMI-based models. MOF is standard for model-driven engineering proposed by the Object Management Group. Graph-based models can also represent the software architecture in different forms, such as Bayesian networks, Markov chains, and state diagrams.

The architecture view feature represents which view is to be reconstructed using the SAR method. Architecture view is a mandatory feature in SAR methods for representing what part of the architecture will be constructed. The module view, allocation view, and component & connector view can be reconstructed in the architecture analyzing step. The module view represents how the system is structured as set of code units. The allocation view represents how the system relates the structures that are not software in the system's running environment. The component & connector view shows how the system is structured in terms of components and its relations among each other.

Using the feature diagram, we can generate many different architecture reconstruction methods by selecting the desired features. However, not all configurations might be possible in practice. Hence, cross-tree constraints are used to eliminate the invalid configurations. We have seen that if the architecture model selection feature is not chosen, then the architecture is not visualized. As architecture is not represented in any manner, it is impossible to visualize. In addition, if a model selection feature is present it is not mandatory to see the architecture visualization feature. Code source artifact must be selected if the goal of the SAR method is refactoring or architecture nonconformity identification. Hence, both of these goals are operated at code level, and code is needed. Refactoring or architecture nonconformity identification may or may not be selected if the code is selected as source artifact. Stakeholders source artifact must be chosen if system modernization goal is selected as a feature. The system modernization goal feature may or may not be selected if stakeholder source artifact is selected. The querying feature must be selected as adopted method if the architecture model is graph-based and vice versa if this constraint does not apply. The preprocessing step must be selected from process steps if log or documentation source artifacts are selected and vice versa if this constraint does not apply. The code source artifact feature must be selected if the code refactoring or design pattern application feature of process suggestions is selected and vice versa if this does not apply. Table 4.3 shows a summary of identified feature composition constraints.

4.3.3 Generic business process model

Architecture reconstruction is in essence a process activity that includes several steps linked in different ways. Based on the identified studies as discussed in the previous subsection, Fig. 4.4 provides the generic business process model for architecture reconstruction methods.

The first step in architecture reconstruction begins with a definition of a problem statement explaining what the proposed method aims to solve. According to the problem statement the required architectural information which consists of architecture views is selected. The next step is to select a method to solve the stated problem according to the needs defined in the previous step. These methods can utilize techniques from clustering, partitioning, data mining, or querying methods. Reconstruction methods might utilize a model for solving the problem or might need preprocessing of the source artifacts before the extraction of architectural elements. Models are used for representing both the abstractions in the code and reconstructed architectures. These models can be graph-, MOF-, UML-, or XMI-based. These four steps define the SAR process design describing the planning of the proposed SAR method.

Preprocessing can be done in several ways, such as reformatting and refactoring code, removing undesired libraries and dependencies, and providing intermediate models to a workflow. The successful completion of architectural element extraction is followed by the analysis of the extracted elements for forming the architectural information intended in the information selection phase. The process follows by two optional steps, i.e., visualizing the reconstructed architecture and suggesting improvements on the reconstructed architecture. In the visualization step the architecture is shown using the selected architecture representation. In the suggestion step the process provides guidelines for architecture reconstruction.

4.4.1 Recovering software architecture from the names of source files

Table 4.4 shows the features for the architecture reconstruction method of Anquetil et al. [2]. As shown in the table the goal of this method is to identify the nonconformance between the intended architecture and implemented architecture. Only the code source artifact is used in the architecture extraction step. This method adapts a clustering and partitioning method and does not generate any models. In the architecture analysis step the component & connector view of the architecture is created using the extracted information from the architecture extraction step.

Fig. 4.6 shows the concrete business process model for this SAR method that is derived from the generic business process model of Fig. 4.4. The first step is to state the problem and then select which information will be extracted from the architecture. Subsequently, the reconstruction technique to be applied is selected and the steps so far actually designed the SAR method. Then the architectural elements are extracted and analyzed for reconstructing the architecture.

4.4.2 ART: an architectural reverse engineering environment

Table 4.5 shows the features for the architecture reconstruction method of Fiutem et al. [11]. The goal of this SAR method is to identify nonconformity between the architecture and code. Code of the system is used as source artifact and data mining techniques are adopted in this method. Process steps consists of preprocessing, architecture analysis, architecture extraction, and architecture visualization. The graph-based model is used for representing the architecture throughout the process. The module and component & connectors views of the architecture are reconstructed. The method proposes a nonsuggestive architectural recovery tool based on system, module, task, and data architecture views for software architecture. Lexical parsers were used to model the architecture from the code into abstract syntax trees (ASTs). The user constructs a file before the architecture extraction phase. After the architecture elements are analyzed they form a graph which is visualized through a user interface.

Fig. 4.7 shows the business process model for this study. In this method, first the problem is defined. Information, technique, and model are selected according to the defined problem. Preprocessing is applied on the code and architectural elements are extracted and analyzed, different from the previous method architecture visualized in this method.