Effort Estimation for Architectural Refactoring to Introduce Module Isolation Fatih ¨ Ozt¨ urk 1 , Erdem Sarılı 1 , Hasan S¨ ozer 2 , and Barı¸ s Aktemur 2 1 Vestel Electronics, Manisa, Turkey {fatih.ozturk, erdem.sarili}@vestel.com.tr 2 Department of Computer Science, Ozyegin University, Istanbul, Turkey {hasan.sozer, baris.aktemur}@ozyegin.edu.tr Abstract. The decomposition of software architecture into modular units is driven by both functional and quality concerns. Dependabil- ity and security are among quality concerns that require a software to be decomposed into separate units isolated from each other. However, it appears that this decomposition is usually not aligned with the decom- position based on functional concerns. As a result, introducing module isolation forced by quality attributes, while preserving the existing de- composition, is not trivial and requires a substantial refactoring effort. In this work, we introduce an approach and a toolset to predict this effort prior to refactoring activities. As such, a selection can be made among potential decomposition alternatives based on quantitative estimations. These estimations are obtained from scalable analysis of module depen- dencies based on a graph database and reusable query templates. We discuss our experiences and evaluate our approach on a code base used in a commercial Digital TV and Set-top Box software. Keywords: software architecture; reverse engineering; refactoring; module iso- lation; effort estimation; dependability; security. 1 Introduction Modularity is a key principle in software architecture design [12]. Decomposing the system into separate, modular units is driven by functional concerns and a set of relevant quality concerns such as dependability and security [2]. These quality concerns usually require that certain modules are decomposed and isolated from each other. For instance, distrusted modules must be isolated from the rest of the system to increase security. This is usually achieved by sandboxing [15] and placing each module into its own address space. Without such a fault isolation, errors can propagate among the modules of the system. Isolation is usually supported by the operating system (e.g., process isola- tion [9]) or a middleware (e.g., encapsulation of Enterprise Java Bean objects [4]). Regardless of the underlying infrastructure, the application software archi- tecture must be decomposed so that certain parts of the system can be quaran- tined. However, it appears that the required decomposition for module isolation