Refactoring Graph for Reference Architecture Design Process Francisca Losavio, Oscar Ordaz MoST, Escuela de Computación, Facultad de Ciencias, Universidad Central de Venezuela, Caracas
[email protected],
[email protected]
Nicole Levy CEDRIC, CNAM, Paris, France
[email protected] ABSTRACT Reference Architecture (RA) is the main artefact shared by all products of a Software Product Line (SPL); it covers commonality and variability of SPL products, and it is used as a template to produce new products in an industrial software production context. Responding to industrial practice, in previous works we have proposed a semi-automatic bottom-up refactoring process to build RA from existing products; their architectures are represented by a connected graph or valid architectural configuration (P, R), where P and R represent components and connectors. In this paper, on one hand we formalize the existence of the Refactoring Graph (RG) automatically constructed for each product, as a main artefact of the process. On the other hand, this process is extended with a new subprocess to manually complete the candidate architecture (CA) obtained automatically, combining the ISO/IEC 25010 standard quality model and goal-oriented techniques to model also non-functional variability, which is still an open research issue in SPL. Finally, RA is manually constructed from the completed CA by generalizing the variants obtained. The complete extended refactoring process is applied to obtain RA for the Integrated Healthcare Systems (IHS) domain. The process is partially tool supported.
Categories and Subject Descriptors D.2.2, D.2.10, D.2.11, D.2.13
General Terms Design
Keywords Software product line, reference architecture, refactoring graph, variability model, quality model, integrated healthcare systems, Integrated Healthcare System
1. INTRODUCTION A Software Product Line (SPL) is a set of software-intensive systems, sharing a common, managed set of features that satisfy the specific needs of a particular market segment or domain. These features are developed from a common set of core assets, which are reused in different products that form a family [1]. The SPL approach favours reusability and claims to decrease costs and time-to-market. The key issue in SPL development is the construction of a common architecture from which new products can be derived. A Reference Architecture (RA) is a generic architecture for high-level design of SPL products constructed in the SPL Domain Engineering phase [2]; it considers a core or set of components common to all products of the SPL family and a variability model to indicate and document how a variant component can be customized for each product [2]. Software Architecture is defined in [3] as “a collection of computational components - or simple components - together with a description of the interactions between these components, the connectors”. In this work the bottom-up approach is followed to construct RA, because in practice many industrial organizations dispose only of isolated products. In this case existing similar products must be examined, using reverse engineering techniques, to identify commonalty and variants. The RA design is a complex process that is in general poorly described in the literature and left to incomplete case studies, and details of methods and approaches are difficult to follow because there are no design standards. Moreover, existing traditional architectural methods and evaluation techniques for single-systems are reengineered and not specifically designed for SPL. In the reactive approach architectural knowledge is recovered from existing products [4] [5]. An important question that commonly appears in the literature is what needs to be done to ensure a suitable choice of architecture for the SPL family of products. To answer this question, this work provides a bottom-up refactoring process [6] modelled by a graph structure (RG) that generates automatically an initial architecture or Candidate Architecture (CA) from the RG of each considered product, taking into account commonalty and functional and nonfunctional variability. The goal of this work is two-folded: on one hand the mathematical foundations of our refactoring process are improved with the justification of the existence of RG, that allows to find all possible ways to assemble one by one the architectural valid configurations of a product; this fact can be seen as an intrinsic property of the product architectural connectivity. On the other hand, the process is extended with a new sub-process to complete the first CA obtained automatically from all RGs, considering a better documented and justified variability modelling of functional and non-functional requirements by combining the Softgoals Interdependency Graph (SIG) [7] [8] and the ISO/IEC 25010 quality model [9].
One of the problems with the SIG is the lack of standard notations and the handling of complexity of the graph configuration; however, even if automatic tools are available to support its graphical construction [10], not many guidelines are provided on how to make a “good” decomposition or refinement of non-functional requirements [11]. This work applies the extended refactoring process to a case study in the Integrated Healthcare Systems (IHS) domain, focusing on free-use software of the Open Source Foundation (OSI). This paper is structured as follows, besides this introduction: the second section formalizes the graph model supporting the refactoring process. The third section is dedicated to present the case study in the context of the IHS domain and the standards involved in our approach. The fourth section describes and applies the refactoring process to build the RA to the case study. The fifth section discusses the related works. Finally, conclusions and perspectives are presented. 2. FORMAL MODELING OF THE REFACTORING PROCESS The product architecture is represented by a connected graph or valid architectural configuration (P, R), where P and R represent components and connectors of the product. The cardinality of P is defined as the order of the configuration; to avoid trivial cases, order ≥ 2. Note that the assets, which are configurations of order 1, constitute a trivial case. A component provides/requires interface to/from another component; we will neither consider other relation types among components, nor ports. Only the logical view of the architecture expressing static aspects will be considered in this work and it will be specified using UML 2.0 [12]. The model supporting our process is a graph or Refactoring Graph, denoted by RG [6]. Given a certain product, the nodes of RG are all connected or valid intermediate architectural configurations of the product, i.e., connected induced sub-graph of (P, R), the nodes are distributed into levels, where Li is referred as level i containing all intermediate configurations of order i. There are as many levels in RG as many components in the product; if n is the number of components, the last level Ln has only one node corresponding to the product architecture. RG is constructed by a bottom-up process from the last level. Each node of Li, i≥2, originates as many nodes in Li-1, as valid configurations exist from Ci,i-1 combinations. There is an arc between two nodes in consecutive levels, if one of them is obtained from the other by adding a new component. That is to say, all precedent nodes of Li are placed in Li-1. Given two nodes ci-1 and ci, the arc represents the transformation to obtain ci from ci-1, by adding a new component to ci-1. Figure 1 shows an example of RG for a product of four components. In RG, paths from the first to the last level represent different ways to assemble the product as a sequence of intermediate valid configurations; components are added one by one, preserving connectivity, to obtain the product from its different assets. The connectivity of (P, R) ensure the existence of RG, from the following facts: If (P, R) is a valid configuration of order n, n ≥ 3, then (P, R) contains at least one intermediate valid configuration of order 2, of order 3,…, of order n, respectively. • Let (P, R) be a valid configuration of order n, n≥3 and (Q, R’) be a valid configuration of order i, 2≤i
