Software Architecture Recovery based on Dynamic Analysis

Software Architecture Recovery based on Dynamic AnalysisAline Vasconcelos1,2, Cláudia Werner11COPPE/UFRJ – System Engineering and Computer Science ProgramP.O. Box 68511 – ZIP 21945-970 – Rio de Janeiro – RJ – Brazil2CEFET Campos (Centro Federal de Educação Tecnológia de Campos) Dr. Siqueira, 273 – Pq. Dom Bosco – ZIP 28030-130 - Campos dos Goytacazes- RJe-mail: [aline, werner]@cos.ufrj.brAbstractArchitecture recovery from legacy systems has been claimed to offer great contributions to software maintenance and reuse. Most of the approaches to architecture recovery is based on the static analysis of systems and lack a sound support to architectural elements identification. In this context, this paper presents an approach to architecture recovery based on dynamic analysis of systems. The system is executed for some specified use-cases and execution traces are collected. By analyzing the execution traces, interaction patterns are detected and architectural elements are defined based on these interaction patterns and their relation to use-case realizations. Moreover, in order to evaluate the proposed approach a case study is presented.1.IntroductionThis paper presents an approach to software architecture recovery from object-oriented legacy systems mainly based on the dynamic analysis of systems. Software architecture represents the description of a system global structure in terms of their elements and relationships among them, along with the principles that guide their design and evolution [1]. The proposed approach has been investigated in the context of the Odyssey project [11], which involves the development of a software development environment based on domain models named Odyssey. Our goals are to contribute to program comprehension and software maintenance and to generate artifacts that can later be used to specify a domain reference architecture.Architecture recovery involves a set of methods for the extraction of architectural information from lower level representations of a software system, such as source code [7]. The abstraction process to generate architectural elements frequently involves clustering source code entities (such as files, classes, functions etc.) into subsystems according to a set of criteria that can be application dependent or not. Architecture recovery from legacy systems is motivated by the fact that these systems do not often have an architectural documentation, and when they do, this documentation is many times out of synchronization with the implemented system. Most approaches to software architecture recovery has been exploring the static analysis of systems [2] [5] [6] [7]. When considering object-oriented software, which employs a lot of polymorphism and dynamic binding mechanisms, dynamic analysis becomes an essential technique to comprehend the system behavior, object interactions, and hence to reconstruct its architecture. In this work, the criteria used to determine how source code entities should be clustered in architectural elements are mainly based on the dynamic analysis of the system, taking into account the occurrences of interaction patterns and types (classes and interfaces) in use-case realizations.The proposed architecture recovery approach aims at the extraction of a functional decomposition of the system, clustering entities that implement similar and coherent functionality. However, it is important to state that an application can have many architecture descriptions, considering, for example, the different architectural views [3] or the diversity of implemented architectural patterns [2]. In this work, we adopt the 4+1 view model [3] to describe an architecture and, besides the functional decomposition that corresponds to the logical view of the architecture, the process and scenario views are also recovered by a dynamic reverse engineering sub-process. T o present the proposed approach, following this introduction, section 2 describes the proposed software architecture recovery process; section 3 presents a case study used to evaluate the process; and section 4 outlines some conclusions and lists our ongoing work.2.The Proposed ApproachThe proposed process to software architecture recovery is depicted in figure 1.Figure 1: The proposed software architecture recovery process.The process is iterative and incremental. The architecture is recovered in cycles, starting by the use-case modeling activity, and in each cycle a more complete description of the system architecture is obtained. The process is semi-automatic and guided by a developer who must have some knowledge about the application. This knowledge, if not existent, can be obtained from system experts, available system documentation and application execution. In the following we briefly describe the process activities.Static Reverse Engineering and Use-Case ModelingThe process starts by the static reverse engineering and use-case modeling activities. The static reverse engineering aims at the recovery of a static model of the system, which is represented through UML Class Diagrams. This activity is executed only once.The use-case modeling can start in parallel to the static reverse engineering. Its goal is to establish the focus of the architecture recovery in the current cycle of the process. To recover the whole architecture of an application in one step is a hard task [5]. In [9] the focus of the recovery process is also established by the use-case modeling. However use-cases are selected according to the change and evolution requirements of the application. In our work, the recovery must start by some key use-cases of the application, representing essential functionality, and incorporates more use-cases as the developer feels it is necessary.The use-case modeling activity involves a manual reconstruction of some system use-cases whenever an up-to-date use-case model of the application is not available. Besides use-cases definition, this activity also involves use-case scenarios description. A use-case scenario encompasses a set of steps that guide the developer during the application execution. In order to specify the use-cases and their scenarios, as stated in [4], which is also a reverse engineering method that performs the analysis of input and output events of the application, user manuals and application execution may be investigated. In application executions, menu options at the application user-interface are a good indicator of system use-cases. Moreover, test cases documentation, if available, can also be analyzed. Dynamic Reverse Engineering and Architectural Elements DefinitionDynamic reverse engineering aims at the reconstruction of a system behavioral model, represented through UML sequence diagrams, in this case. To this end, the system is executed for the specified use-case scenarios and these executions are monitored, allowing the collection of execution traces. Execution traces encompass the set of events and messages generated during system execution, with their sender and receiver instances and their types. They are the input source of information to the reconstruction of sequence diagrams and the definition of architectural elements.The criteria to architectural elements definition are based on the analysis of these execution traces. Most of the approaches to architecture recovery does not establish general criteria to architectural elements definition [5] [9]. When they do, architectural elements identification is based on the static analysis of the system [2] [6]. In this work, our assumption is that the dynamic model of the system, considering object-oriented software, reveals significant information about object interactions that is essential to support architectural elements reconstruction. We propose two criteria to architectural elements definition, namely:•Criterion 1: Clustering in subsystems source-code entities (classes and interfaces) that participate in interaction patterns that appear in a large1 set of use-cases. An interaction pattern that participates in the realization of a large set of use-cases indicates types that represent a central functionality in the architecture.•Criterion 2: Clustering of source-code entities that participate in the realization of a small set of use-cases together with these use-cases in subsystems.An interaction pattern represents an ordered sequence of messages and events that frequently occur during system execution. Moreover, the architectural elements defined must thereafter be mapped to the sequence diagrams reconstructed in order to allow a representation of a dynamic model of the system architecture, corresponding to the process and scenarios view [3]. The scenarios view relates use-cases to architectural elements.A challenge we face, however, to conduct this dynamic analysis is the volume of information obtained in the traces. One of the solutions proposed to this problem is to filter out from the traces the events and messages to/from Java API classes.EvaluationIn each cycle of the recovery process, the architecture reconstructed must be evaluated by system experts. The goal is to validate if the recovered elements really correspond to an expected architecture representation, being helpful to system comprehension.1 The number of use-cases that indicate a large set is application-dependent. As we perform several case studies applying the proposed process, a percentage value for this number can be defined.In order to reduce the frequently required manual effort to architecture recovery, a tool set to support the process has been developed in the context of the Odyssey project [11]. The following section presents a case study that was performed to evaluate the proposed process along with the description of our tool set.3.Case StudyA case study to evaluate the proposed process has been done with the support of the Odyssey environment, aiming at the reconstruction of its own architecture. Odyssey is a software development environment that covers the development for reuse, through domain engineering, and the development with reuse, through application engineering. It has two main views, namely Environment and Modeling Environment, in which the developer can create domains, applications, model domains and applications etc. Odyssey is written in Java programming language and contains around 650 classes.Along the years Odyssey became a huge environment, with drawbacks related to performance, usage complexity and evolution. Many tools, such as the pattern detection tool, are not necessary in some particular usage scenarios, and they can represent an overhead to the whole environment in these scenarios. Since Odyssey continues to evolve, in 2003 the team decided to reengineer the environment in order to reduce its complexity and to allow its customization to specific needs. However, only a few of the original developers were available and there was no up-to-date documentation of the whole environment design to be investigated. Thus the team realized the need to recover the Odyssey architecture in order to allow its comprehension and facilitate its reengineering. The following sections illustrate how the proposed process was applied to the recovery of the Odyssey architecture, taking into account a few architectural elements, i.e., the kernel of the application and some elements related to essential features of the environment.3.1.Static Reverse Engineering and Use-Case ModelingThe static reverse engineering was performed with the Ares tool, a reverse engineering tool integrated to the Odyssey environment, which is capable of extracting a UML static model from Java source-code. The use-case modeling activity started through the identification of some key use-cases, namely: Create a New Domain; Create a New Class; Create a New Use-Case; Create a New Class Diagram; and Define a New User. The identification of key use-cases is the developer responsibility, but may take into account some essential features of the application. In the case of Odyssey, since it represents a development environment, which encompasses reuse through domain engineering, the key use-cases were the ones related to domain creation and its modeling. Moreover, an important feature of the Odyssey environment is its control over authorized users. Some more use-cases were defined along the other recovery cycles.Create a New ClassMain Scenario: Create a new class through pop-up menu option. To start this scenario the user must be in theModeling Environment view of Odyssey.Steps:1.The user goes to the Structural View and presses the mouse right button.2.Odyssey shows a menu window with some options.3.The user chooses “Creates New Class”.4.Odyssey creates a new class element in its Structural View, with a graphical representation and a set ofdocumentation items to be fulfilled.Figure 2. Main scenario for Create New Class use-case.The main scenarios for each use-case were specified. Figure 2 exemplifies a scenario description to the main scenario for the use-case “Create a New Class”.3.2.Dynamic Reverse EngineeringDuring the dynamic reverse engineering, Odyssey was executed to the specified use-case scenarios and the execution traces were collected. To support the dynamic reverse engineering, we developed a trace collector tool, named Tracer, that uses aspects [10] to monitor Java program executions and collect the messages and events generated during execution. Tracer fits well the process needs, since it allows the collection of execution traces to be enabled and disabled at run-time, making it feasible to collect only the execution traces related to a specific use-case scenario or application functionality. Moreover, some filters can be applied while using Tracer, allowing the user to determine packages and/or classes to be traced. Tracer stores the trace in a XML file, facilitating the post-processing of the generated information. Based on these execution traces, sequence diagrams, associated to the use-case scenarios, were reconstructed using Odyssey.3.3.Architectural Elements DefinitionArchitectural elements definition started with the detection of interaction patterns in the reconstructed dynamic model. By comparing the sequence diagrams reconstructed to the Odyssey use-cases, it was possible to identify two interaction patterns that appear in almost all of the use-case scenarios. They are depicted in figures 3 and 4.Figure 3 illustrates the first pattern in the context of the “Create New Class” use-case. This pattern occurs anytime a new semantic element (like a class, a use-case or a user) needs to be created in Odyssey. Environment and ModelingEnvironment classes control a semantic element creation, asking SemanticFactory to fabricate the correspondent element. There are little differences in this pattern considering the different use-case scenarios, such as the ClassNode class, which is UseCaseNode in the “Create New Use-Case” use-case. It is important to state, however, that we assume that an interaction pattern can have some interleaved messages.The second interaction pattern detected is illustrated in figure 4. This pattern is in fact a continuation of the first one. By analyzing the patterns in figures 3 and 4, it was possible to realize that every model element, like classes, use-cases, diagrams etc., are modeling items (class ModelItem) and abstract models (class AbstractModel).Through the interaction patterns detected, it was possible to visualize the Odyssey kernel, the Semantic Core element, which encompasses the classes that are essential to the definition and instantiation of any semantic element and appear in the realization of almost all the use-cases, like Environment, ModelingEnvironment, AbstractModel etc. It is depicted in figure 6. Moreover, since Odyssey works with some factories, an architectural element to encapsulate them was defined. Architectural elements are depicted in figure 5. The Semantic Core depends on the Factories in order to create new semantic elements. The Class Modeling architectural element contains the classes (e.g. ClassModelRepresentation) that only appear in the realization of the use-cases related to class modeling. The same holds for the Use-Case Modeling architectural element. The classes in the Class Modeling and UseCase Modeling architectural elements are subclasses of classes in the Semantic Core.Figure 3. First interaction pattern detected in the Odyssey execution.Figure 4. Second interaction pattern detected in the Odyssey execution.In order to reconstruct the internal structure of each architectural element, a tool that queries the Odyssey internal class model was applied. The Class Manipulation tool provides some query capabilities to the Odyssey environment, allowing the user to select classes in the static model of an application based on some search criterion.The static reverse engineering of Odyssey was performed within Odyssey itself, making it possible to use the Class Manipulation tool to locate in the static model the classes that appeared in the interaction patterns detected. Since Odyssey has 650 classes, by using this tool, we could slice its static model and reduce the time to reconstruct its partial architecture. Moreover, by querying classes using their name string, allowed us to find classes with similar names. Grouping classes with a common string in their names,although not being one of our main crietria to architectural elements definition, is also helpful since designers use to follow this criterion in order to characterize architectural elements, like layers. The Class Manipulation tool also computed the high-level dependencies between the architectural elements (shown in figure 5) as their internal structures were reconstructed.Figure 5. Some Odyssey architectural elements.Figure 6. Semantic Core internal structure. 3.4. EvaluationBy evaluating the Odyssey architecture with experts we could confirm that the recovered architectural elements were reasonable. However, some static relationships between classes, as the aggregation between the classes Model and ModelItem (figure 6), were not recovered by the static reverse engineering tool and needed to be added manually to the diagram. Nevertheless, the recovered architecture was successfully used as the basis to the reengineering of the Odyssey, which lead to the generation of a new version of the environment, named OdysseyLight [12].4. Conclusions and Ongoing WorkThrough the presented case study it was possible to have an initial evaluation of the effectiveness of architecture recovery based on dynamic analysis of software. There are Odyssey Architectural Elementsalso a few approaches to architecture recovery that take into account the dynamic analysis. In [8], the authors apply the formal concept analysis technique to identify methods shared by use-cases implementation. Each concept in the generated conceptual lattice encompasses a set of use-cases and their shared methods. However, the lattice does not make clear where a source-code entity, such as a class, must be located in the architecture, since the same entity appears in more than one concept. In [9], dynamic analysis is also considered in the recovery process. However, this analysis is not automated and it is not used as the basis to architectural elements identification.In our proposal, criteria to architecture reconstruction are clearly defined based on use-case realizations. Moreover, we are currently specifying and developing tools to support the process activities to which an automated support still does not exist, such as the sequence diagram reconstruction and interaction patterns detection.References1. Garlan, D., Perry, D. Introduction to the Special Issue on Software Architecture. IEEETransactions on Software Engineering, April 1995, p. 269-274.2. Harris, D. R., Yeh, A., Reubestein, H.B., Yeh, A.S. Reverse Engineering to theArchitectural Level. In Proceedings of the 17th International Conference on Software Engineering, Scattle, Washington, April 1995, p. 186-195.3. Kruchten, P.B. The 4+1 View Model of Architecture. IEEE Software, November 1995, Vol. 12, Number 6, p. 42-50.4. Penteado, R.A.D., Germano, Masiero, F., P.C. An Overall Based on Fusion to ReverseEngineer Legacy Code. In Proceedings of the 3rd IEEE Working Conference on Reverse Engineering, Monterey, California, November, 1996, p. 179-188.5. Kazman, R., Carrière, S.J. Playing Detective: Reconstructing Software Architecturefrom Available Evidence. Technical Report CMU/SEI-97-TR-010, Carnegie Mellon University, October 1997.6. Mendonça, N. C., Kramer, J. Developing an Approach for the Recovery of DistributedSoftware Architectures. In Proceedings of the 6th IEEE International Workshop on Program Comprehension, Ischia, Italy, June 1998, p. 28-36.7. Sartipi, K., Kontogiannis, K., Mavaddat, F. Software Architecture Recovery. SoftwareEngineering Group, University of Waterloo, Waterloo, Ontario, Canada, Technical Report, 1999.8. Bojic, D., Velasevic, D. A Use-Case Driven Method of Architecture Recovery forProgram Understanding and Reuse Reengineering. In Proceedings of the 4th European Software Maintenance and Reengineering Conference, Zuriq, Swiss, February 2000, p.23-31.9. Ding, L., Medvidovic, N. Focus: a LightWeight, Incremental Approach to SoftwareArchitecture Recovery and Evolution. Working IEEE/IFIP Conference on Software Architecture, Amsterdam, Netherlands, August 2001, p. 191-200.10. AOSD Steering Committee. Aspect-Oriented Software Development. In:. Accessed in 09/02/2004.11. Odyssey Project. In: http://www.cos.ufrj.br/~odyssey. Accessed in 05/10/2004.12. Murta, L., Vasconcelos, A., et al. Run-Time Variability through Component DynamicLoading. To appear in the Proceedings of the Tools Session at the 18th Brazilian Symposium on Software Engineering, Brasilia, Brazil, October 2004.。