Development and Configuration of Service-Oriented Systems Families Bardia Mohabbati
Marek Hatala
Dragan Gaševi´c
SIAT, Simon Fraser University 13450 102 Avenue Surrey, BC V3T5X3, Canada
[email protected]
SIAT, Simon Fraser University 13450 102 Avenue Surrey, BC V3T 5X3, Canada
[email protected]
SCIS, Athabasca University 1 University Dr. Athabasca AB T9S 3A3, Canada
[email protected]
Mohsen Asadi
Marko Boškovi´c
SIAT, Simon Fraser University 13450 102 Avenue Surrey, BC V3T 5X3, Canada
[email protected]
SCIS, Athabasca University 1 University Dr. Athabasca AB T9S 3A3, Canada
[email protected]
ABSTRACT
Keywords
Software Product Lines (SPLs) are families of software systems which share a common sets of feature and are developed through common set of core assets in order to promotes software reusability, mass customization, reducing cost, timeto-market and improving the quality of the product. SPLs are sets (i.e., families) of software applications developed as a whole for a specific business domain. Particular applications are derived from software families by selecting the desired features through configuration process. Traditionally, SPLs are implemented with systematically developed components, shared by members of the SPLs and reused every time a new application is derived. In this paper, we propose an approach to the development and configuration of Service-Oriented SPLs in which services are used as reusable assets and building blocks of implementation. Our proposed approach also suggests prioritization of family features according to stakeholder’s non-functional requirements (NFRs) and preferences. Priorities of NFRs are used to filter the most important features of the family, which is performed by Stratified Analytic Hierarchical Process (S-AHP). The priorities also are used further for the selection of appropriate services implementation for business processes realizing features. We apply Mixed Integer Linear Programming to find the optimal service selection within the constraints boundaries specified by stakeholders.
Software Product Line, Service-Oriented Architecture, FeatureOriented Development, Service Selection, Optimization
Categories and Subject Descriptors D.2.13 [Software Engineering]: Reusable Software—Domain Engineering, Reuse models; G.1.6 [Optimization]: Integer programming
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’11 March 21-25, 2011, TaiChung, Taiwan. Copyright 2011 ACM 978-1-4503-0113-8/11/03 ...$10.00.
1.
INTRODUCTION
Success stories from industry (e.g., mobile phone industries) have recently propelled software product family to address efficiently software reuse, mass customization,reducing cost, time-to-market and improving the quality of the product. Software product families, commonly referred to as SPLs, are sets of software systems sharing most of their functionality [5]. SPLs are developed as a whole by using common assets such as models, components, architecture and other assets. Variability of such software system sets is typically described by feature models [2]. A particular application is an instance of the set of a software system family. The application is developed by selecting the desired features as required by the application stakeholders. In this context, the common assets of the SPL are reused when an instance (i.e., new member) of the SPL is selected. Recent research initiatives [12, 10] identified a promising synergy in a combined use of SPLs and SOAs. However, to be fully able to realize this synergy, some fundamental challenges need to be solved. Although both, SPLs and SOAs, are originally designed with intentions to increase reusability, they differ in underlying philosophies. In SPLs, reusable software assets are internally developed after a very systematic process of planning and analysis. On the other hand, in SOAs, reusability typically involves discovering and invoking services [14], often developed and provided by third parties. In this paper, we refer to this synergy as Service-Oriented Software Product Lines (SOSPLs). SOSPLs are SPLs in which services are used as building block implementations of application logic (see Sect. 2). SOSPL can be considered in the context of a typical SPL development process consisting of the domain and application engineering lifecycles (details in Sect. 2). In domain engineering, the use of services can reduce the time and cost of development SPLs, but it can also increase complexity of application derivation in application engineering. Each functionality of an SPL can be implemented with services from different providers offering different levels of non-functional
1606
(a) Problem Space : FM
E‐Travel
2
3
7
Payment
Reservation
Advertisement Delivery
1 Searching Travel Products
9
…
4 Booking Flight
5
6
Booking Accommodation
Booking Transportation
…
Detecting Fraud [ A D E J] [ A,D ,E,J]
…
8
Payment Method
…
11
10 Debit Card [ B,D,H,K ]
Credit Card [ A,D,I,K ]
13 Email [ B,H ,I,K]
14 SMS [ C,E,K ]
15 MMS [ C,D,J ]
12 Electronic Cheque
Payment Business Process Model Template
2 , 8
2 , 9 , 10
2
2 , 9 , 11
2
2 , 9 , 12
2
Tag Legend
Concern Security (qsec ) Availability (qav ) Cost (qpr ) Reliability (qel )
High A D G J
Med B E H K
Low C F I L
2
Notation
And Or Alternative Optional Mandatory Cardinality
n : (BP) Mapping
(b) Solution Space : (BP)
Figure 1: Initial functional feature model for simplified E-Travel. a) Feature model (FM) represents the variability in software family. b) Business process model template. properties such as reliability, response time, and cost. In such scenario, besides the selection of the desired features of an SPL, application engineers, who derive a concrete application from the SPL need to select an appropriate set of services that implement the business logic of the application under development. The selected services need to satisfy both functional and non-functional properties of the product line as much as possible. In this paper, we propose an approach for development and configuration of SOSPLs where stakeholders’ requirements and concerns are prioritized in different levels and then appropriate features of desired SPL member selected for final product deviation. Our approach is a twofold extension of the existing SPL development process. First, it extends the domain engineering lifecycle (Sect. 3) to support both specificities of SOSPLs reflecting their service-oriented nature and supporting non-functional requirements (NFRs) as needed for the process of feature and service selection. Second, our approach in application engineering of SOSPLs (Sect. 4) is based on Stratified Analytical Hierachical Process (S-AHP) [1] and Mixed Integer Linear Programming (MILP). S-AHP is a feature selection technique that prioritizes and selects features of a software family. The features selected by S-AHP are input of the next stage where MILP is applied to select appropriate services that realize these features according to stakeholder’s preferences correspond to (NFRs).
2.
SOFTWARE PRODUCT LINES
Software Product Lines are sets of software systems developed as a whole, which share common models, components, architecture and other assets. A development of applications according to SPL principles is generally divided in two lifecycles: domain engineering and application engineering. The domain engineering lifecycle aims to identify and develop reusable assets and members of the SPL. Typically, the domain engineering phase produces problem space models, solution space models, and mappings between the problem and solution space models. Problem space models are mostly specified as feature models. Feature models are used to distinguish the members of the product line; each feature
is an increment of the application functionality [2]. Solution space models specify the application logic of the members of SPL. As an illustration of these models, we use a part of the standard e-travel agency case study. E-travel is a B2C e-commerce family of software systems that enables users to browse, plan, and book a various kinds of traveling options. Such applications allow for arranging different kinds of accommodations, transportation, insurances and other features. Additionally, these applications offer different options for payment, ticket delivery, and advertisement. In Figure 1, we give parts of the problem (Figure 1a) and solution space (Figure 1b) models of this case study. Features in a feature model are visually represented with one or more feature diagrams[?]. Features in feature models can be in a mandatory or optional parent-child relationship, or grouped as Alternative, Or and And groups [2]. Mandatory child features are features which must be included in each configuration when their parent feature is included. In cases when the parent feature of an optional feature is selected, the optional feature might be included in the configuration. An example of optional and mandatory features are Payment Method and Fraud Detection, respectively. When a desired application needs a payment functionality, the parent feature Payment is selected in the configuration. Such an application must have some payment method reflected with Payment Method. However, the final application may optionally have a payment fraud detection functionality modeled with feature Detection Fraud. Cardinality can also be specified for alternative groups, in a format , meaning that minimum m and maximum n features must be selected for that group. Or feature groups are groups in which one or more features can be selected in final configurations. An example of such a feature group is Reservation in Figure 1a. In this group, any of the following features can be selected: Booking Flight, Booking Accommodation, and Booking Transportation. These features reflect that the target application can have any combination of these three functionalities. An example of the alternative feature group are child features of the Advertisement Delivery feature where the final configurations can provide advertisements by any Email, SMS, or MMS feature.
1607
Solution space models specify the application logic of the families of software systems. They are typically specified as model templates [6]. During product configurations, model templates are reduced to one of their sub-models according to the selected features of the feature model. The connection between feature model and model templates are specified using mapping model. Typically, mapping model consist of boolean expressions specifying presence or removal of a modeling element from a model template depending on the feature selection. For instance, in Figure 1 mappings are simple implication expressions between Debit Card, Credit Card and Electronic Cheque features and their corresponding business sub-processes. An example of a business process model template for the e-travel agency is given in Figure 1b. In this example, if Debit Card and Credit Card features are selected, and Electronic Cheque feature is not, created instance of the business model template will be a business process model with all elements of the model template except for the corresponding Cheque subprocess. Real industrial feature models tend to grow very large up to thousands of features. Configuration of such large feature models is very costly and overwhelming for application developers. This process tends to be even harder in the case of multiple stakeholders, when they have different priorities for high level non-functional properties. Furthermore, in SOSPLs there are usually multiple services available to implement the same functionality, but with different nonfunctional properties such as availability. This variability increases the cost and time of already complex application configuration process. To address this challenge, we propose domain and application engineering lifecycles for SOSPLs shown in Figure 2 and discuss details in the following sections.
3.
SOFTWARE SERVICE FAMILY DESIGN AND DEVELOPMENT
In this section, we describe details of the domain engineering lifecycle which includes main activities for the design and implementation of a family of service-oriented software system. These activities, labeled D1-D6 in Figure 2a, are performed iteratively during domain engineering. We also introduce required formalisms and formal definitions of the key concepts used in this life cycle. We first define the concept of SOSPLs, hereafter referred to as software service families. Definition 1. (Software Service Family). A software service family, denoted as SSF, is a set of software systems. SSF is defined by a feature set FS = FC ∪ FV where FC = {fc1 , fc2 , ..., fcn }, FV = {fv1 , fv2 , ..., fvm } are sets of core common and variable features, respectively, where |FC | = n, |FV | = m, and |FS |= n + m, (n, m) ∈ N. A set of combination of features in FS creates a configuration space JdKFS .
3.1
Variability Modeling (D2)
After performing requirements analysis for the whole family (Figure 2-D1), we next capture the super-imposition of all variations of the family by feature modeling (Figure 2-D2). Consequently, variable and common assets for the product line are respectively specified as optional features (FV ) and mandatory features (FC ) through feature models. The common assets among various members of the family are modeled as mandatory features. Optional features represent as-
sets that may or may not be included in a final configuration. By performing the variability analysis on the case study in Figure 1, we developed the feature model whose part is shown in Figure 1a. For example, we analyzed the possible methods of the payment in the E-travel domain and found that the possible supported ways of payment as Debit Card, Credit Card, and Electronic Cheque features. For instance, it is required all the products have at least two methods of payment which is indicated by the cardinality range .
3.2
Business Process Family Design (D3)
The design of business processes produces BP model templates, which are part of the solution space. A BP model template MT (BP ) contains the union of the business processes of all valid applications and can be modeled by process-oriented modeling languages such as Business Process Modeling Notation (BPMN). The domain requirements are analyzed and business processes are developed and refined incrementally, while the variability of the domain is reflected in them. Finally, the BP model template is created through the aggregation of business processes. In essence, a MT (BP ) consists of a set of interrelated activities A and their data dependencies. An activity can be an atomic activity or a sub-process (i.e., a compound activity); eventually implemented by services. Accordingly, a MT (BP ) contains all possible design situation (business processes) for the members of the family. Figure 1b depicts a part of the model template of business process for our case study.
3.3
Model Mapping (D4)
To connect the feature model and the BP model template, we define a mapping between their elements, i.e., mappings between features and activities. We apply a similar approach presented in [6]. In our approach, we consider a boolean variable ψ i corresponding to each feature fi . We also consider an annotation property for each activity in the BP model template MT (BP ) called presence conditions (PCs). An activity PC is formulated as a Boolean expression of ψ i variables corresponding to features mapped to the activity. Both feature and activity constructs in MT (BP ) uses reference elements to refer to model elements of feature models or model templates. Therefore, when domain engineers map features to activities, the activities’ PCs are defined. In application engineering, when features ψ i are removed from the configuration, their corresponding ψ i variables are set to false. Next, PCs are evaluated and activities with PC equal to false are removed from the BP model template. We should point out that when an activity is removed, elements of the BP model template dependent on the removed activity (i.e. input and output) are removed from the model as well. Moreover, verification mechanisms and simplification mechanisms are performed to check consistency of the model and to simplify the model, which is out of the scope of this paper. For example, in Figure 1, if the Credit Card feature is not selected for a final product configuration, variable ψ 11 is set to false. Next, the Credit Card activity PC (DB-PC = ψ 11 ∧ ψ 2 ∧ ψ 9 ) is evaluated to false. Hence, the activity can be removed from MT (BP ). As we mentioned before, the activity dependencies are removed from the model (links to other elements in BP) by mechanism provided in [6].
1608
Domain Engineering E
Domain Analysis Product Family Requirements Analysis
Business Process Family Design
Variability Modeling
D1
D2
Requirements Model
Domain Implementation
Domain Design
D3
D4
D6
D5
Mapping Schema
Business Process Model Templates
Feature Model
Business Process Model Template Implementation
Defining NFRs for SSF
Model Mapping
Service Discovery/ Implementation
Annotated Feature Model
Applic cation Engineering
(a) Application Analysis
Stakeholder’s Requirements Analysis Application Application Requirements Specification
Application Implementation
Application Design
A1
Feature Prioritization and Selection
Configured Feature Model
A2
Service Prioritization and Selection
Application Integration and Deployment
A3
Configured Product
Final Product
Legend Stage
A4
Process Flow Output
Artifact
Tractability
(b)
Figure 2: Activities of proposed methodology for Service-Oriented Product Line development. a) Domain Engineering. b) Application Engineering.
3.4
Defining Non-functional Requirements in SSF (D5)
Current methods for domain analysis [7] focus on modeling variability of functional facets in the family. NFRs are often neglected by the existing feature modeling techniques. However, it is critically important to incorporate them into both problem and solution space models. NFRs directly influence the selection of appropriate services as they provide feature implementations with varying non-functional properties. For instance, NFRs for the feature Credit Card can include cost, security, availability and reliability. Also, activity Check Credit, which is mapped to Credit Card (Figure 3), can entails some NFRs including security and cost. Hence, for activity Check Credit, only a service should be selected that satisfies both NFRs of the activity (i.e., activity level NFR) and the feature (i.e., feature level NFR). To incorporate NFRs, we extended the feature model by the concept of concern [1]. The concern is derived from an NFR which is related to the stakeholders’ objectives and preferences. Examples of concerns are implementation cost, security, risk, and time. Moreover, we define fuzzy-lexical values for each concern named as qualifier tag, which represent possible options of concerns. For example, the cost concern may have hight, medium, and low qualifier tags. We denote the set of defined concerns for a given family as Cf = {c1 , ..., cn } and qualifier tags of the ith concern as CiQT = {qt1 , ..., qtm }. In this stage, we first define all the concerns of the family and their corresponding qualifier tags based on the NFRs modeled in the family requirements analysis phase. Next, every feature of the feature model is analyzed with respect to the NFRs and is annotated with corresponding concerns. Then, for concerns of each feature appropriate qualifiers tag are determined and assigned. The mapping between feature models and BP model template MT (BP ) is used to propagate the concern values of the features to their corresponding solution space model elements (i.e., activities and sub-processes). For example, Figure 3 shows a sub-process model template, implementing different features. It is important, that we distinguish between: i) feature level NFR that are defined by assigning specific qualifier tags to the concerns of a given feature. These are then propagated onto their corresponding BP model template elements; and ii) activity level NFRs that are defined for individual activities in
the BP model template MT (BP ). Given that the MT (BP ) is implemented by discovering services (as described in the next stage - D6), NFRs for services need to be represented through QoS properties. QoS properties are expressed as concrete numbers or constraints over numbers (e.g., cost ≤ $1000). Having defined NFRs using concerns in the feature model, we need to determine how to represent NFRs in the activities as a bridge between these two different representations of NFRs, for instance, to map fuzzy-lexical values into numerical values. In order to provide mappings between fuzzy-lexical values of concerns and numerical values, we define a normalized concern function, which maps fuzzy-lexical qualifier tags CiQT (l = |CiQT |) of Ci concern into l disjoint normalized quality ranges QRi = {qr1 , ..., qrl } of real numbers from range [0, 1], where ∪lk=1 qrk = [0, 1]. For instance, in exemplified case study, we define the normalized concern function , as an schema, that maps the qualifier tags low, medium, and high of the cost concern into their normalized quality ranges: low = [0, 0.3), medium = [0.3, 0.7), high = [0.7, 1]. However, given that concrete costs of features might be in different rages of values (e.g., costs of features Credit Card and Debit Card are not equivalent), with each feature and concern we also need to maintain the information about the range of concrete values the each concern might take values from. With these concrete value ranges, we map normalized quality ranges QRi of concern Ci for a feature fj into quality f f ranges QRi j where l = |CiQT | = |QRi j |. In order to illustrate the use of described quality ranges, let us consider Figure 3, which defines a part of our case study. Based on the mapping between the feature model and BP model template, we can see that qualifier tag values of NFRs of feature Credit Card (i.e., feature level concerns) are propagated to the elements of the BP model template, that is, the BP sub-process providing the solution for feature Credit Card. By using the normalized concern function of the concerns shown and concrete quality ranges of each feature for their associated concerns, we transform qualifier tags into quality ranges. As it can be seen, since the cost concern of the feature Credit Card has a qualifier tag low assigned as its value, the cost concern corresponding quality range is [$5000, $6500). This quality range is then propagated to the Credit Card business sub-process. Similarly, quality ranges for other features are propagated onto
1609
S2(1) S2(2) .. 2 . S2(20)
Credit Card Sub-Business Process
FM
2
Payment
9
1
Payment Method
2
11 Mapping Link
S3(1) S3(2) .. 3 . S3(20)
3
4
11 Activity Annotation
Feature Annotation
Cost = [$5000‐$6500] Availability = [%80‐%100] Reliability = [%50‐%80) Security = [%80‐%100]
…
…
Cost (qpr) = [$200‐$500] Reliability = [%90‐%100]
Activity level
Credit Card
́
Q
Feature level
Q
Figure 3: Credit Card feature and sub-process realizing this feature the business sub-process. Next, domain engineers together with stakeholders specify the distribution of these quality ranges among activities of the business sub-process. In a nutshell, this distribution defines how much each element of the sub-process contributes to the satisfaction of the NFR defined as the quality range. For example, for the Check Credit activity, the defined quality range for the cost concern can be [$200-$500]. This specification process, which is performed by a domain expert, is outside of the scope of this paper. In addition to the NFRs propagated from the features, for each activity of the sub-process we also can define additional, activity level NFRs.
3.5
Business Process Model Template Implementation (D6)
The implementation process of the BP model template in the domain engineering lifecycle (Figure 2-D6) focuses mainly on generation of queries for discovering services, which offer operations implementing each activity Ai defined in MT (BP ). These queries are generated based on (non-)functionalities defined as feature and activity level quality ranges on the business processes. As already discussed, in the feature model mapping stage, feature level quality ranges are created from concerns’ qualifier tags via the provided normalized function for the concern and the concern ranges stored with the features. The activity level ranges are defined using feature level ranges. We define service template S T to capture both feature level quality ranges and activity level quality ranges. Hence, S T is a mean to aggregate the specification of required services and their QoS properties to satisfy the required functionality of a given activity. After developing S T with ranges for functional requirements and QoS properties, S T is employed to construct service search queries for the process of service discovery which is out of the scope of this work. Therefore, for each activity Ai ∈ MT (BP ), a set of m service candidates SAi = {si1 , ..., sim } are assumed to be discovered in the solution space (Figure 3). In other words, SAi includes binding links to different services providing multiple implementations for activity Ai with varying QoS properties. If there is no service discovered for activity Ai , we should provide a service implementation.
4.
SOFTWARE SERVICE APPLICATION ENGINEERING
In this section, we describe the application engineering lifecycle, which includes the process of (service-oriented) application derivation from SSF.
In the process of application derivation from SSF, we distinguish between stakeholder’s functional requirements and NFRs which are captured through stakeholder’s requirements analysis stage (Figure 2-A1). In order to effectively configure the family for the target application based on its stakeholder’s functional requirements and NFRs, the following issues should be addressed: 1) What features should be selected for the target application in order to satisfy both stakeholder’s functional requirements and NFRs; and 2) How should the selected features be realized by equivalent functional implementations that have different non-functional properties. In our case, those equivalent functional implementations refer to the discovered services, where for each activity Ai ∈ MT (BP ) there is SAi . To address these two challenges, in our method, a configuration process has two main stages.
4.1
Feature Prioritization and Selection
As already discussed, the feature model provides the configuration space JdKFS for the family. A member of the family is specified by selecting the desired features from the feature model. The process of configuration of the family is done through a series of successive stages of specialization of the reference feature model [7]. In each stage, a subset of preferred features is selected and unnecessary features are discarded. This yields a specialized feature model whose set of possible configurations is a subset of the reference feature model (Jdi KFS ∈ JdKFS ). A final configuration is obtained by fully specializing the feature model. To enhance the selection of features for a particular application, we should take into account the concerns related to high-level objectives and preferences (i.e., relative importance) of stakeholder. That is, we should know both stakeholder’s primary concerns and the stakeholder’s preferences with respect to these concerns (e.g., security is more important than the implementation cost). To this end, in our earlier work, we introduced a method for feature selection, called the Stratified Analytic Hierarchy Process (S-AHP ) [1]. S-AHP prioritizes and ranks features of a product family based on the high-level concerns of stakeholder’s and his/her preferences over these concerns, by utilizing the theory of the well-known Analytic Hierarchy Process (AHP). Having defined concerns and qualifier tags for the family as outlined in Sect. 3, the S-AHP prioritization steps are executed in application engineering (Figure 2-A2). First, based on NFRs, relative importance of the concerns are determined (e.g., security is strongly preferred over cost). Next, AHP is executed on the concerns to calculate the absolute ranks (priorities) of the concerns. Afterwards, according to the stakeholder’s inputs, less important concerns are filtered out. For remaining concerns, relative importance of their qualifier tags are determined by users and their ranks are computed by executing AHP on them. Then, the rank of each feature is specified based on their qualifier tags. Finally, the feature specialization step is done iteratively to select or remove features from the feature model based on their ranks and feature constraints by adopting steps introduced in [7]. The output of this stage is a specialized feature model in which variability related to functionalities is resolved. For example, the dashed gray circles in Figure 1 depict the features that are selected after applying the S-AHP specialization process. Consequently, other features are discarded, which results in the reduction of the configuration space JdKFS .
1610
This specialized model is input to the next specialization stage.
4.2
Service Prioritization and Selection
To derive the final configuration, there is still unresolved variability originating from implementations of the previously specialized feature model. This variability needs to be systematically managed and resolved. As already explained, each activity in the BP model template may have different implementations provided by a set of service candidates with the same functionality and varying QoS properties. The goal of service selection is the optimal selection of one service candidate for each activity (sj ∈ SAi ) in the BP model template MT (BP ) where all stakeholder’s NFRs of the target application are satisfied (Figure 2-A3). The optimization is performed at the level of each feature of the feature configuration obtained through S-AHP. For each feature their solution space counterpart is considered along with the candidate services discovered in domain engineering. We model the problem of finding the best candidate services as a Constraint Satisfaction Optimization Problem (CSOP). This constraint satisfaction problem is mapped to the Mixed Integer Linear Programming (MILP) model which is solved by a solver.
4.2.1
Formulating MILP
We use MILP to optimize the service selection. The modeled MILP problem has the following three inputs: a set of variables, a set of constraints, and an objective function. MILP attempts to maximize or minimize the value of the objective function by adjusting the values of variables while the constraints are enforced. Variables: We use binary decision variables in the model to represent the selection of service candidates for each activity of the BP model template realizing the feature under study1 . Therefore, we add all service candidates sij ∈ SAi for each activity Ai as variables to the MILP problem space. As for each activity we only want to select one service among available service candidates, a service candidate sij is selected if its corresponding decision variable xij is set to 1. Herewith, the service assignment should satisfy the following constraints in the MILP model: ∀SAi :
m X
xij = 1, m = |SAi |
(1)
quality for cost is defined as [$200-$500]. Furthermore, for service candidates sij ∈ SAi , we consider values of their QoS properties, but only those properties that correspond to the identified concerns in domain engineering. In our case, those concerns are security, availability, cost, and reliability as shown in Figure 1. We index these concerns with integer numbers as follows: 1-security, 2-availability, 3-cost, and 4-reliability. We create a quality matrix QSAi for each activity Ai , in which each row corresponds to a service candidate, while each column correspond to a QoS concern. For example, in our case study, the matrix will have four columns. Thus, the quality matrix is defined as QSAi = (Q(i, j); 1 ≤ i ≤ m, 1 ≤ j ≤ 4). Because QoS values are generally expressed in different scales, we need to normalize them all in a uniform representation. We used Max-Min normalization for this purpose [15]. As an example, assume that there are five services in SA2 for activity Pin Card Verification (e.g., A2 ) in Figure 3 and their values for QoS property cost are given by QSA2 (n, 3) = [100, 360, 280, 250, 400] where 1 ≤ n ≤ |SA2 |, and 3 is the index for cost. Since Qmax SA2 (n, 3) = 400 and Qmin (n, 3) = 100, thus the utility function for the cost SA2 QoS property defines the minimum utility value (0) when the cost is below $100, and a maximum utility value (1) when cost is above $400. Between these two ranges, the function grows linearly which results in Ucost (QSA2 (n, 3)) = [0, 0.13, 0.4, 0.5, 1], which represents a utility function for QoS property cost for the candidate services of activity A2 . As we discussed, S-AHP provides ranking result for stakeholder’s concerns that correspond to stakeholder’s preferences. Furthermore, feature concerns are converted into feature and activity level quality ranges on the BP model template. Therefore, we should apply the concern ranking result of S-AHP to the corresponding quality ranges propagated to the activity level NFRs. For instance, SAHP computes the ranks for the four concerns described in our case study, security, availability, cost, reliability as follows W = [0.58, 0.23, 0.06, 0.13]. This shows that the ordering between the four concerns is cost availability reliability security. Accordingly, by applying the ranking outcome of S-AHP, the general weighted composition of the utility functions for a service sti ∈ SAi , 1 ≤ t ≤ |SAi | for each Ai :
j=1
where m is the number of services in the service candidate set SAi assigned to Ai . For instance, assume that there are 20 service candidates that can implement activity Check Credit (A3 ) in Figure 3. As one service candidate from all available candidate sij ∈ SAi should be selected, we have P that 20 j=1 xij = 1. Constraints: As mentioned earlier, all concerns are mapped into quality ranges in domain engineering. Those quality ranges are imposed as constraints added to the MILP model for service selection at two levels: 1) feature level constraints QFC ; and 2) activity level constraints QAC . Objective function: As explained in domain engineering, NFRs of an activity are specified through quality ranges. For instance, Check Credit activity in Credit Card has a 1
We consider the MILP problem for each feature individually and the optimization is thus done at the level of individual features.
U (QSAi )(t, ∗) =
k X
Uj (QSAi )(t, j) · x ´ j · Wj
(2)
j=1
where k = |Cf | is the number of QoS properties that corresponds to the number of concerns defined in domain engineering; x ´j is a binary variable that states whether QoS property j should be considered or not for sti . Also, Wj ∈ R+ 0 is the weight of QoS property j which is computed as a rank of its corresponding concern in S-AHP. Accordingly, the problem of solving the MILP model can be formulated as a maximization problem of the following objective function subject to the feature and activity level constraints. X n X d maximize U (QSAi )(t, ∗) · xik · Wk (3) i=1 k=1
where n is the total number of activities in the business sub-process, while d = |SAi | is the number of candidate services at activity Ai , and xik is a binary variable that
1611
shows that service sk is selected or not for activity Ai after execution of the MILP process. The objective function (3) is linearized using the logarithmic function in order to be able to use it in the MILP models. By solving this model using any MILP solver, the objective function is maximized to find an optimal solution within the constraints boundaries specified by stakeholders at both feature and activity levels. Therefore, one service for each activity service candidate set (SAi ∈ MT (BP )) is selected based on the specified activity and feature level constraints.
5.
TOOL SUPPORT
We prototype and develop several components for the configuration framework to explore how proposed approach can help to manage variability and reduce the complexity of configuration process by abstraction and staged configuration process. The main components of framework are feature modeler, business process modeler, feature mapper, and service manager for selection and binding. We are currently integrating these independently functioning components to build a configuration platform for delivering configurable SSF. Our prototype extends Feature Modeling Plugin (FMP)2 , which is an Eclipse plug-in, for cardinalitybased feature modeling and configuration. It has been extended with required functionality for defining concerns related to NFRs of services. The Eclipse BPMN Modeler 3 is integrated for business process modeling and constructing model template. The current approach for implementing feature mapper component is based on Atlas Model Weaver (AMW) [8] which is an extension to an Eclipse plug-in. Each mapping model is composed of links that associate a feature in the feature model to one or multiple corresponding business process constructs in the business process model template designed for an entire family. We use the open source MILP implementation LpSolve v5.54 for solving the MILP model, which is entailed by service manager component for optimal selection of services w.r.t expectation and constraints specified by stakeholder.
6.
DISCUSSION
One of the biggest challenges in the configuration process is its scalability [3]. The scalability issues arise when the number of features increases in SPL. In consequence, the selection of corresponding appropriate implementation based on NFRs will be crucial. An SPL with m optional (variable) features FV has 2m −1 distinct products. For instance, a situation where a product line with 20 optional features has 1,048,575 products. Because of the possible large amount of variability, the complexity stems from features combination and permutation of NFRs. To the best of our knowledge, current classical approaches for the development of software services in service computing community focus on the construction of a single product through selection services relying on QoS-aware service management particularly at run-time. However, the majority of approaches do not support developing a range of products with common set of (non-)functionalities and some variable (non)functionalities. Moreover, the lack of reusability at the 2
http://gsd.uwaterloo.ca/projects/fmp-plugin/ http://www.eclipse.org/bpmn/ 4 http://lpsolve.sourceforge.net 3
level of design has been seen in software service development paradigm. We identified that the variability introduced in software product line engineering allows systematically managing service reuse to address the needs of stakeholder’s business objectives. Variability management deals with the resolution of variability for specific products through different levels of abstraction, which ameliorates configuration process. We observed that feature prioritization and staged configuration process enable elimination of variation points iteratively w.r.t to stakeholder’s requirements. The key to making a product line for a service-oriented system is eliminating unnecessary feature combinations. We perform this by determining and selecting features relevant to stakeholder’s requirements and exhibited constraints, which is followed by optimal selection of appropriate services in business process template. This promisingly helps to overcome the huge amount of configuration decisions in a systematic manner by means of variability model constructed at the design time. We found that carefully analyzing and managing variability also helps to develop an architecture and configuration model that could deal with future changes in stakeholder requirement models or changes in services implementation provided by different third parties. Furthermore, the proposed model-based approach for configuration allows that software service architecture is designed with points of variability that enables not only the construction of an infrastructure representing a complete range or family of products but also it can support the refinement and alteration of a product line. In this cases, SPLs proved to be a feasible way to align business goals and system architecture [9] [11]. Our proposed model-driven approach also attempts to lessen the complexity of configuration by reducing decision search space and resolving variability in different abstraction levels. On the one hand, all possible selection points at the level of feature, such as an incremental functionality, are resolved in order to obtain a valid instances of the software product line, as well as the feature dependencies which explicitly are represented in feature model. On the other hand, the NFRs related to the implementation level, which is provided by services, are incorporated into the feature model as configuration knowledge that heavily affects the configuration of a valid product. Nevertheless, it is substantially obvious that the analysis and development time of the product line is longer and have initial costs, e.g., constructing feature model comprising configuration and decision model, annotation of features with NFRs, and mapping process. However, the benefits that will be achieved in the long term can recompense these costs as take place in the broader software engineering practice as discussed through the context of SPL in [5].
7.
RELATED WORK
Recognition of the potential synergistic use of SPLs and SOAs has motivated development of several approaches for SOSPLs [11]. Lee et al. [12] present feature-oriented approach to analyzing and developing service-oriented systems and to specifying dynamic product configurations. The authors propose a service identification method based on a feature binding analysis technique. In their method, reusable services are organized into organizational services, mainly specifying workflows, and molecular services which implement computational tasks. Molecular services are composed
1612
of the available atomic services. The drawback of this approach is the increased complexity of the variability management of SOSPLs which are presented through orchestrating and service layers in the feature model. This can be inconvenient, as the size of the feature model can grow dramatically large, particularly in cases of variability of values of QoS properties. Furthermore, their approach does not consider business processes and it may identify candidate services that are not aligned with stakeholders’ goals which we have addressed in this paper through. Medeiros et al. [13] also introduce a method for development of SPLs of serviceoriented systems. Authors propose component-based development guidelines and steps for identifying components implementing services and subsequently service orchestration candidates which implement the SOSPL. A feature-based analysis technique is adopted to identify architectural component candidates. Similar to the approach of Lee at al. [12], all variability is captured in the feature model which is different from our approach as stated above. Boffoli et al. [4] propose a method for the development of SOSPLs using the principles of business process management. In their method, families of business processes are developed in domain engineering. In application engineering, a particular member of the family is chosen, and then services for the implementation are either identified or developed. In our approach, we identify and develop services earlier in domain engineering, hence, increasing their reusability for application engineering. Integer programming for the QoS-based service selection and composition problems has widely been proposed by several researchers. Zeng at. al [15] propose a quality-driven service selection for service composition. They use local and global planning to find the best service for the composition and apply MILP to find the optimal selection of services. Not only does the integer programming approach provide compositions that satisfy constraints, but it also maximizes user satisfaction based on specified utility functions. Our approach is built upon Zeng et al., and specifies utility functions based on S-AHP for prioritizing QoS concerns for service selection.
8.
CONCLUSIONS AND FUTURE WORK
In this paper, we proposed a feature-oriented method for the development and configuration of SOSPLs. We leverage feature modeling and model template-based approaches in order to model variability and configure SOSPL. Templatesbased approach enables representing the union of the business processes in all valid template instance. The proposed approach takes into account the functional and nonfunctional requirements at the level of design and implementation which is provided by services offering the same functionality and vary in QoS properties. Our method also uses of fuzzy-lexical qualifier tags as an easy-to-use mean for stakeholders to express NFRs and preferences. Defined fuzzy-lexical tags are transformed to range of numerical values in order to facilitate their use in the process of feature and QoS-driven service selection. The complexity of configuration process is reduced by following principles of modeldriven product line and staged configuration where variability points are resolved at the architectural and implementation levels. In this process, features are prioritized based on stakeholders’ NFRs. For future directions, we plan to conduct comprehensive evaluation of this method in the context
of realistic case studies. We intend to measure the performance of the service selection for various sizes of SOSPLs and numbers of services.
9.
REFERENCES
[1] E. Bagheri, M. Asadi, D. Gaˇsevi´c, and S. Soltani. Stratified analytic hierarchy process: Prioritization and selection of software features. volume 6287, pages 300–315. 2010. [2] D. Batory. Feature models, grammars, and propositional formulas. In Software Product Lines, pages 7–20. Springer, 2005. [3] D. Batory, D. Benavides, and A. Ruiz-Cortes. Automated analysis of feature models: challenges ahead. Commun. ACM, 49(12):45–47, 2006. [4] N. Boffoli, M. Cimitile, F. M. Maggi, and G. Visaggio. Managing soa system variation through business process lines and process oriented development. In Proc. 3rd Int’l Workshop on Service-Oriented Arch. and Software Product Lines, 2009. [5] P. Clements and L. Northrop. Software product lines. Addison-Wesley, 2001. [6] K. Czarnecki and M. Antkiewicz. Mapping features to models: A template approach based on superimposed variants. In GPCE, pages 422–437, 2005. [7] K. Czarnecki, S. Helsen, and U. W. Eisenecker. Staged configuration through specialization and multilevel configuration of feature models. Software Process: Improvement and Practice, 10(2):143–169, 2005. [8] M. Fabro, J. B´ezivin, and P. Valduriez. Weaving models with the eclipse amw plugin. In Eclipse Modeling Symposium, Eclipse Summit Europe, 2006. [9] J. V. Gurp, J. Bosch, and M. Svahnberg. On the notion of variability in software product lines. In Working IEEE/IFIP Conference on Software Architecture, 2001. Proceedings, pages 45–54, 2001. [10] A. Helferich, G. Herzwurm, S. Jesse, and M. Mikusz. Software product lines, service-oriented architecture and frameworks: worlds apart or ideal partners? In Proc. 2nd Int’l Conf. on Trends in Enterprise Application Architecture, pages 187–201, 2007. [11] J. Lee and G. Kotonya. Combining service-orientation with product line engineering. IEEE Software, 27:35–41, 2010. [12] J. Lee, D. Muthig, and M. Naab. A feature-oriented approach for developing reusable product line assets of service-based systems. Journal of Systems and Software, 83(7):1123–1136, July 2010. [13] F. M. Medeiros, E. S. de Almeida, and S. R. de Lemos Meira. Towards an approach for service-oriented product line architectures. In Proc. of the 3rd international workshop on Service-Oriented Architectures and Software Product Lines, 2009. [14] M. P. Papazoglou, P. Traverso, S. Dustdar, and F. Leymann. Service-oriented computing: State of the art and research challenges. Computer, 40(11):38–45, 2007. [15] L. Zeng, B. Benatallah, A. H. Ngu, M. Dumas, J. Kalagnanam, and H. Chang. QoS-aware middleware for web services composition. IEEE Transactions on software engineering, 30(5):311–327, 2004.
1613
