Transformational Variability Modeling Approach to Configurable Business System Application

The Software Product Line (SPL) is an emerging methodology for developing software products. Currently, there are two hot issues in the SPL: modelling and the analysis of the SPL. Variability modelling techniques have been developed to assist engineers in dealing with the complications of variability management. The principal goal of modelling variability techniques is to configure a successful software product by managing variability in domain-engineering. In other words, a good method for modelling variability is a prerequisite for a successful SPL. On the other hand, analysis of the SPL aids the extraction of useful information from the SPL and provides a control and planning strategy mechanism for engineers or experts. In addition, the analysis of the SPL provides a clear view for users. Moreover, it ensures the accuracy of the SPL. This book presents new techniques for modelling and new methods for SPL analysis.


Introduction
For more than ten years now, adaptation of software systems has become a major challenge for the software engineering community which has proposed different reference architectures and systematic approaches to address this challenging research topic. In the literature, the concept of adaptability is very broad and has many unclear and inconsistent definitions, with many closed-related types of non functional requirements such as flexibility, evolvability, transformability, reusability, robustness, configurability, etc. (see (Subramanian & Chung, 2001a) for a sample of representative definitions). This broad nature of adaptability makes it critical in practice since one of the problems in dealing with it is to give a clear and non ambiguous definition of adaptation and adaptability.
This contribution is based on the intuitive definition of N. Subramanian and L. Chung who consider that "adaptation means change in the system to accommodate change in its environment", and "adaptability is the extent to which a system adapts to change in its environment" (Subramanian & Chung, 2001a, 2001b. Since we also agree with them that, "software architecture should itself be adaptable for the final software system to be adaptable", this chapter, which is a continuation of our earlier work on business component semantics (BCS) extension and transformation of feature-oriented models (Fouda & Amougou, 2009, describes an engineering approach to support adaptation at architectural level of enterprise systems. The term enterprise system (ES) came into fashion somewhat recently, but the concept behind it has been subject to academic discussion for a long time now and has evolved from an historic development in Business, Computer Science, and Information Systems. Over the last years, ES have evolved to comprehensive IT-supported business solutions that presumptively support and enhance organizations in their operations. Often times, ES refer to the larger set of all large organization-wide packaged applications with a process o r i e n t a t i o n . T h e y h a v e t o b e c o n f i g u r e d t o s u i t t h e r e q u i r e m e n t s o f a n o r g a n i z a t i o n (alignment with organizational requirements). In order to facilitate the alignment process, most ES solutions provide reference models that describe the functionality and structure of the system. But, research shows that reference models still are only of limited use to the configuration process. According to M. Rosemanna and W.M.P. van der Aalst (Rosemanna A change in an IS, is any observable mutation and/or evolution of one or many of its building blocks: people, data, processes or interface (Whitten et al., 2001;Zachman, 1987). We qualify as "major" any change that results in a larger deviation of the information system definition. While robustness (i.e. the ability to tolerate some deviations in the environment) can be added to a software system at the design or even implementation stage, adaptability (i.e. the ability to adapt to larger deviations in the environment) cannot be added at such late stages. Adaptability can be enforced only if it is considered at the architecture development stage (Subramanian & Chung, 2001b). We go further in that direction by considering the IS architecture development stage, i.e. the enterprise process modeling, should be the initial stage where adaptability is taken in consideration.
Enterprise modeling (Bernus, 2003;Fox & Gruninger, 1998;Lankhorst, 2004;Vernadat, 2002) is a critical building block to establishing an agile, robust enterprise architecture that keeps pace with the fast moving business. It is the first building block in aligning the IT initiative with the business objectives. The aim of an enterprise model, named here "business system architecture" (BSA), is to bring together business operations and IT. The BSA serves as the foundation, framework and guidepost necessary to understand the enterprise and its environment.
The aim of this chapter is to propose and illustrate a reusable business component-based approach to develop BSAs with an innate potential to evolve and adapt to new requirements. To be more concise, the chapter's contribution is two-fold: First, it introduces an adaptable BSA modeling framework covering an architecture description language which formalizes the FORM engineering assets (Kang et al., 2002(Kang et al., , 2003Lee et al., 2000) as reusable business components (Ramadour & Cauvet, 2002) which provide domain knowledge reusable during IS engineering and a generic abstract model for adaptable business architectures. Second a transformational (Rotenstreich, 1992) engineering process for adaptable BSA design and use is given.
Our approach is an integrated system product line approach, like PLUSS+ (Eriksson et al., 2010), in the sense that it extends traditional systems engineering by incorporating ideas from software product line (SPL) engineering. It integrates a product line method managing variability with a software engineering methodology. It is based on the traditional domain engineering-application engineering view of software product line development (van der www.intechopen.com  , 2007;Weiss & Lai, 1999). SPL engineering is a paradigm to develop software applications (software-intensive systems and software products) using platforms and mass customization (Pohl et al., 2005). Developing applications using platforms means to plan proactively for reuse, to build reusable parts, and to reuse what has been built for reuse. Building applications for mass customization means employing the concept of managed variability, i.e. the commonalities and differences in the applications (in terms of requirements, architecture, components, and test artifacts) of the product line have to be modeled.
The chapter is organized as follows: section 2 presents the modeling framework, section 3 then outlines the associated transformational engineering process, and section 4 concludes the chapter.

Modeling approach
This section outlines a generic conceptual framework for adaptable BSA. This framework is generic in the sense that it is not dependent on a specific modeling technique or method. However, a requirement for the application of our engineering process is that the engineering method used throughout the process must manage variability (Kang et al., 2010) in order to facilitate the derivation of model variants from the initial model. The main idea is to give reusable business component (Ramadour & Cauvet, 2002) semantics (rBCS) to the assets of a domain-specific architecture design method M by providing for each structure the context in which it can be reused. The resulting method, named M/BCS (read "M with business component semantics"), produces M-adaptable domain-specific architectures.
The model for adaptable BSA specification given in this section is based on a well established method in the product line engineering research community: the featureoriented reuse method (FORM) (Kang et al., 1998).

Business component semantics
We use the model for conceptual business components specification of P. Ramadour and C. Cauvet (Ramadour & Cauvet, 2002) to define reusable domain-specific architecture assets. In this model, a business component integrates both reusable knowledge (object structures) and contextual knowledge guiding the reuse of the component. The context of a structure specifies specific requirements (set of constraints) accomplished by the structure and therefore indicates the suitable situation(s) in which a structure can be reused. The three levels of contextual constraints (business goals, business processes and business rules) considered by the model to specify conceptual business components clearly indicate that the conceptual business components of Ramadour and Cauvet are closely-related to enterprise process models assets (Bernus, 2003;Fox & Gruninger, 1998;Lankhorst, 2004;Vernadat, 2002). In this model, each business component has three constituents: a name, a descriptor and a realization:


Descriptors explain when and why use components. A descriptor has an intention and a context. The intention is the expression of the generic modeling problem. The term "generic" here means that this problem does not refer to the context in which it is www.intechopen.com Software Product Line -Advanced Topic 46 supposed to be solved. The context of a business component details its main business activity (domain) in terms of atomic and non atomic sub activities (process) and explains the choice of one alternative and not the other (common, optional, variabilities).  Realizations provide solutions to the modeling problems expressed in the descriptor sections. Solutions are the reusable part of the business component; they may have adaptation points that are parameters whose values are fixed at the reuse moment.
We use the formal language Z to formalize this business component model in order to allow a rigorous study of its properties. Due to space constraints, this model cannot be given here. Figure 1, gives the specification skeleton, where A denotes the set of finite subsets of A and Class is the set of classes of objects (as used in the object-oriented terminology). The detailed specification is given in (Fouda & Amougou, 2009  The types of solutions depend on the types of the business components. A solution can be a system decomposition, an activity organization or an object description, or anything else depending on the intention of the component. If this intention is to implement an activity of a product line engineering method (e.g. feature analysis), then the type of the solution is necessarily a kind of asset produced by the method (e.g. a feature model).
The BCS approach for adaptable business system architecture, which is advocated here, is a way to envelop assets of a product line engineering method with a domain knowledge layer. This layer, which indicates the purpose intended by the asset and the constraints it solve, provides the context in which it can be reused. It formally defines the extent to which the asset adapts to change in its environment. This additional layer is in fact an "adaptability information layer".

Business architecture description language
FORM/BCS architecture description language is specified through the description of its four main concepts: feature business components, subsystem architecture business components, process architecture business components, module business components and adaptable system architectures. www.intechopen.com

Feature business component
In FORM, a feature model of a domain gives the "intention" of that domain in terms of generic features which literally marks a distinct service, operation or function visible by users and application developers of the domain. FORM/BCS specifies a feature model of a domain as a business reusable component of that domain which captures the commonalities and differences of applications in that domain in terms of features ( Figure 2).
The type Feature specifies business activities. A business activity is caused by an event which is applied to a target set of objects. Features have a generalization (in the sense of objectoriented analysis) and decomposition. A feature's decomposition gives the set of its common (sub) features which indicate reuse opportunity, the set of its optional (sub) features and the set of its groups of alternate (sub) features.

Process architecture business component
A process architecture business component represents a concurrency structure in terms of concurrent business activities to which functional elements are allocated; the deployment architecture shows an allocation of business activities to resources (Figure 4).
The type ProcessArchitecture specifies process architectures. A process architecture is a set of business activities (tasks) and classes of objects (data). Each business activity operates on a class of objects (data accesses) and business activities exchange messages between them in the form of actions call or with the environment (null).

Module business component
Module business components are refinements of process business architecture components. A module business component may be associated with a set of relevant features. Also, alternative features may be implemented as a template module or a higher level module with an interface that could hide all the different alternatives ( Figure 5). The service view, which is a set of feature business components (the functional perspectives), provides the solution for the analysis of the service provided by a business organization.


The system view, which is a set of subsystem business components (the structural perspectives), gives the solution for the decomposition of a business organization.  The process view, which is a set of process business components (the procedural perspectives), provides the solution for the description of the processes of a business organization.  The logical view, which is a set of module business components (the logical perspectives), gives the solution for the specification of application modules associated to sub processes or tasks of a business organization.
The reusable business components defining adaptable system architectures can be stored in a database which can be requested using engineering by reuse operators developed by P.

Adaptable architectures engineering
In this section, we describe a system engineering methodology for the production and use of adaptable business architectures. Systems engineering focuses on stakeholder needs and the required functionality early in the development cycle to synthesize an overall system design that captures those requirements from a total life-cycle perspective. Our approach is an integrated system product line approach, like PLUSS+ (Eriksson et al., 2010), in the sense that it extends traditional systems engineering by incorporating ideas from software product line engineering. It integrates a product line method managing variability with a software engineering methodology. It is based on the traditional domain engineeringapplication engineering view of software product line development (van der Linden et al., 2007;Weiss & Lai, 1999).
The purpose of domain engineering is to develop a product line's reusable core assets to provide a production capability for products (Northrop, 2002) and the purpose of application engineering is to generate new systems utilizing the assets developed by domain engineering. We refer to the domain engineering activities of our methodology as horizontal engineering process and the application engineering activities as vertical engineering process to indicate that the purpose of application engineering is to refine business architectures at more low levels of abstraction ( Figure 7).  The horizontal process, which corresponds to the "engineering for reuse" approach, gives the possibility to analyze a product line domain and develop adaptable architectures of that domain. These abstract reusable models can be refined ("engineering by reuse" approach) by the vertical engineering process in order to derive the specific business components of an application domain, which is to configure a suitable application from domain engineering.

Horizontal engineering process
The horizontal engineering process has been done in (Fouda & Amougou, 2010). It is a transformational method (Partsch, 1992;Rotenstreich, 1992), based on a set of provably semantics-preserving derivation rules called constructors. The aim of a constructor is to transform, according to a formal rule called the construction schema, a kind of architectural artifact (the input type of the constructor) to another kind of architectural artifact (the output type of the constructor) by preserving all the system properties incorporated in any given input. The definition of a constructor therefore has three parts: the specification of the input type, the specification of the output type and, the specification of the construction rule which defines, through a construction schema and a set of semantics rules, how to build a semantics preserving output from a given input.
The horizontal engineering process has three constructors: the system view constructor which supports the system view design activity, the process view constructor which supports the process view design activity and the logical view constructor which support the logical view design activity. The service view of a system is the starting point of the process; this view is therefore obtained by applying any relevant requirement analysis technique.

System views design
The purpose of the system view design activity is to derive system views from service views. This activity is carried by the total function SVC, the system view constructor, whose purpose is to construct structural perspectives from functional perspectives of organizations. Figure 8, which intensively uses the adaptable business architecture model defined in section 2, specifies the system view constructor. In that figure, any text inside /* */ is a comment which explains the formal notation.

Process view design
The purpose of the process view design activity is to derive process views from system views of organizations. This activity is carried by the total function PVC, the process view constructor, whose purpose is to construct procedural perspectives from structural perspectives of organizations. Figure 9 defines the process view constructor.
Input: A structural perspective sp of an organization. Output: A set of procedural perspectives PVC(sp) of the organization. Construction schema: /* Adaptation points of the process architecture constructed from p in process(sp) are tasks of the process architecture for which we have more than one realization */ Fig. 9. The process view construction rule

Logical view design
The purpose of the logical view design activity is to derive logical views from process views. This activity is carried by the total function LVC, the logical view constructor, whose purpose is to derive logical perspectives from procedural perspectives of organizations. Figure 10 defines the logical view constructor.

Input:
/* Adaptation points of the module architecture of a context t are modules included in the module architecture of t for which we have more than one realization */ Fig. 10. The logical view construction rule

Vertical engineering process
The purpose of the vertical engineering process is to generate new systems utilizing the assets developed by horizontal engineering. Its ultimate goal is to configure a suitable business application from domain engineering. It refines architectural assets of a domain to low level assets of an application domain of that domain. This engineering process is also a transformational method based on a set of provably semantics-preserving refinement rules called refiners. The process has four refiners: the service view refiner which supports the service view refinement activity, the system view refiner which supports the system view refinement activity, the process view refiner which support the process view refinement activity and the logical view refiner which supports the logical view refinement activity (see Figure 7).

Service view refinement
The purpose of the service view refinement activity is to derive a service view of an application domain of a domain from the service view of that domain. This activity is carried by a total function FMR, the functional model refiner, defines in Figure 12, which refines feature business components, i.e. functional perspectives, of a domain to specific business components of an application domain by using decompositions of non atomic services of input feature business components. A service view refinement is triggered by a decomposition of an abstract service of the service view. Any decomposition defines an application domain since it specifies a specific manner to implement the service. Decompositions define how abstract (common and optional) services of domains are implemented in application domains. Figure 11 shows an example of a decomposition of an abstract service (career management of state personnel governed by the general status of the public service or the labor code: C 11 ) of the Cameroon civil servant management information system which has been used as a case study for the method (Atsa et al., 2010). In this decomposition, the abstract service C 11 is implemented only by four common actions; one of these actions (the recruitment process: C 111 ) is itself decomposed in four optional actions.  The refinement of a service view (see Figure 12 for the formal definition) replaces the decomposed service by its decomposition and integrates the new variability constraints in the new model.

System view refinement
The purpose of the system view refinement activity is to derive a system view of an application domain of a domain from the system view of that domain. This activity is carried by a total function SMR, the structural model refiner, defines in figure 16, which refines subsystem business components, i.e. structural perspectives, of a domain to specific business components of an application domain by using decompositions of non atomic services in subsystems of input subsystem business components. A system view refinement is triggered by a decomposition of an abstract service in a subsystem of the subsystem view. Any decomposition defines an application domain since it specifies a specific manner to implement the service. Decompositions define how abstract services of domains are implemented in application domains. Figure 15 shows an example of a decomposition of an abstract service (career management of state personnels: C 1 ) of the Cameroon civil servant management information system. In this decomposition, the abstract service C 1 is implemented by one common action and four optional actions.

Process view refinement
The purpose of the process view refinement activity is to derive a process view of an application domain of a domain from the process view of that domain. This activity is carried by a total function PMR, the procedural model refiner, defines in Figure 20, which refines process business components of a domain to specific business components of an application domain by using decompositions of non atomic tasks of input process business components. A process view refinement is triggered by a decomposition of a task of the process view. Any decomposition defines an application domain since it indicates a specific manner to implement the task. Decompositions define how abstract tasks of domains are implemented in application domains. Figure 19 shows an example of a decomposition of an abstract task (recruitment of state personnels governed by the general status of the public service or the labor code: C 111 , see Figure 11) of the Cameroon civil servant management information system. In this decomposition, the abstract task of C 111 is implemented by four optional tasks.
The refinement of a process view (see Figure 20 for the formal definition) replaces the decomposed task by its decomposition and integrates the new variability constraints in the new model.   ACTION (career,salaries,training,network,mail,system) TARGET Process : C 11 = (manage = [{recruit,advance,liquidate,transfer},{},{}]) ACTION (candidates, applications, competitive examinations, civil servants governed by the general status or the labor code, decisions) TARGET /* sub process of the process C 11 */ C 111 = (recruit) ACTION (candidates, applications, competitive examinations, civil servants governed by the general status or the labor code, decisions) TARGET (If the candidate has succeeded a competitive examination or has obtained a diploma giving the right to absorption or the Presidency of the Republic has given the authorization) DETAIL C 112 = (advance) ACTION

Logical view refinement
The purpose of the logical view refinement activity is to derive a logical view of an application domain of a domain from the logical view of that domain. This activity is carried by a total function LMR, the logical model refiner, defines in Figure 24, which refines module business components of a domain to specific business components of an application domain by using decompositions of non atomic business activities of input module business components.
A logical view refinement is triggered by a decomposition of a business activity of the logical view. Any decomposition defines an application domain since it specifies a specific manner to implement the business activity. Decompositions define how (common business activities, optional business activities, variability) abstract business activities of domains are implemented in application domains. Figure 23 shows example of a decomposition of an abstract business activity (absorption by qualification belonging to optional(action (C 111 ))) of the Cameroon civil servant management information system.  In this decomposition, the abstract business activity "absorption by qualification" is implemented by two optional business activities.
The refinement of a logical view (see Figure 24 for the formal definition) replaces the decomposed business activity by its decomposition and integrates the new variability constraints in the new model.

Conclusion
Until the last decade, variability could be defined either as an integral part of development artefacts or in a separate variability model. Concerning the first trend, many research contributions have suggested the integration of variability in traditional software development diagrams or models such as use case models (Oliviera et al., 2005), feature models (Kang et al., 2002;Bashroush et al., 2008), message sequence diagrams (Ziadi, 2004), class diagrams (Clauss, 2001;Ziadi, 2004), and activity diagrams (Razavian et al., 2008) to represent variability. Many others approaches have been proposed that suggest to define the variability information in a separate "orthogonal variability model" (OVM) which, according to Pohl et al. (2005), is a model that explicitly defines the variability of a software product line. In this chapter, we have presented an approach that tries to reconcile the two precedent orientations. The main idea is to envelop assets of a domain-specific design method managing variability with a domain knowledge layer which provides for each asset the context in which it can be reused. The domain knowledge layer is in fact an OVM that highlights the variability of the assets.
The resulting SPL engineering methodology has domain engineering activities, referred to as the horizontal engineering process, whose aim is to develop a product lines's reusable core assets to provide a production capability for products, and application engineering activities, referred to as the vertical engineering process, whose aim is to generate new systems utilizing the assets developed by horizontal engineering; The ultimate goal of the