A Systematic Method for Architecture Recovery Fritz Solms Department of Computer Science, University of Pretoria, Pretoria, South Africa Keywords: Architecture Recovery, Architectural Tactics, Architectural Patterns, Architecture Description. Abstract: Software architecture recovery aims to reverse engineer a software architecture description from the system ar- tifacts (e.g. source code) in order to facilitate software architecture analysis, improvement and control. Whilst there are a number of software architecture recovery methods, none of the current methods focus purely on those aspects of a system which address non-functional requirements. This paper introduces the Systematic Method for Software Architecture Recovery (SyMAR). SyMAR is an inspection method used to recover a software architecture description consistent with the view of a software architecture providing a specification of a software infrastructure addressing non-functional requirements within which application functionality addressing functional requirements can be deployed and executed. The method has been applied to a num- ber of industrial architecture recovery projects. This paper discusses the experiences from these projects and illustrates the method using one of these projects as a case study. 1 INTRODUCTION Ongoing system maintenance often leads to architec- tural drift and erosion (de Silva and Balasubrama- niam, 2012) resulting in an increase in system com- plexity, maintenance costs and architectural failures (Roy and Graham, 2008; de Silva and Balasubrama- niam, 2012). Furthermore, a lack of an authoritative understanding of the software architecture makes it difficult to analyze the causes of architectural con- cerns and to effectively re-architect aspects of the system to address such concerns. At this point it is often advisable to recover the software architecture of the system. Software Architecture Recovery in- volves extraction of relevant information, abstraction and description (Tilley et al., 1994) resulting in a com- plete or partial description of the software architecture (Duenas et al., 1998). Common challenges around software architecture recovery include the size and heterogeneity of the code bulk and that architectural abstractions are not explicit at source level (Ducasse and Pollet, 2009). Abstractions required for an architectural descrip- tion include the identification of architectural pat- terns or styles, architectural tactics and the concepts and constraints a software architecture introduces for the specification of application components (Solms, 2012). Here an architectural style or pattern is de- fined as the structural organization of components and connectors, with constraints on how they can be combined (Shaw and Garlan, 1996). An architec- tural tactic refers to a reusable technique used to con- cretely address quality requirements (Rozanski and Woods, 2011). In addition, a software architecture may specify concepts and constraints within which application functionality is to be developed (Solms, 2012). For example, using either stateful components as in CORBA, Java-EE, stateless services Services Oriented Architectures or pure functions as in Map- Reduce based architectures affects the ease of reuse (Erl, 2005), parallelization (Hinsen, 2009) and other qualities. Efforts to automate the recovery of aspects of the architecture from source (Sartipi, 2003; Eisenbarth et al., 2003; Hamdouni et al., 2010) are able to extract component-connector views, generate message traces across components and perform clustering into higher level components or features. They are, however, not in a position to perform abstractions into architectural patterns and tactics. Nor are these methods able to abstract application code into the concepts and con- straints within which they are developed or even to distinguish between aspects of the code which address non-functional requirements (i.e. architecturally sig- nificant code (Solms, 2012)) and those implementing application functionality. Here application function- ality refers to primary functional requirements around what the processes the system needs to execute to provide the user the functionality they require. Non- functional requirements, on the other hand, refer to system or service qualities like performance, scalabil- ity, reliability, auditability, security, integrability and 215 Solms F.. A Systematic Method for Architecture Recovery. DOI: 10.5220/0005383302150222 In Proceedings of the 10th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE-2015), pages 215-222 ISBN: 978-989-758-100-7 Copyright c  2015 SCITEPRESS (Science and Technology Publications, Lda.)