This case study is based on the feature model for B2C (Business-to-Consumer) eShop solutions with fixed-price purchasing that is provided in [1]. The purpose of this case study is to evaluate the support provided the HATS Variability Modeling Languages to the development of product lines of information systems.

According to Lau [1], the eShop domain is a relatively large and well-understood domain with a large degree of variability on which serious evaluations of new approaches can be performed.

We have extended the feature model proposed him with quality features concerning security and performance, so that we can also investigate how the configuration of product lines should be supported in order to take into consideration not only end-to-end functionality, but also performance and security requirements.

Top Level Features


Figure 1 shows the top level features of Lau’s feature model for B2C eShop solutions [1] and already includes the security and performance top level features. This model allows the specification of over one billion valid products. In the following paragraphs we provide the description of the three top features.

  • StoreFront: It defines the interface that the customer uses to access the eShop. Many features are directly visible to the customer and impact their experience at the eShop [1].
  • BusinessManagement: It deals with aspects pertaining to the eShop’s operation. Most of these aspects are back-office concerns, such as product management, order processing, and marketing, which are handled the eShop staff [1].
  • SoftwareQuality: It allows the specification of the degree in which security and performance should be supported in a certain eShop solution. This optional feature deals with quality characteristics, measures and metrics related to security and / or performance.

In the next two sections, we provide the sub-features of the features Registration and BuyPaths as in [1], where one can find the complete explanation of the feature model.

eShop Registration


An eShop may enable registration, which allows a customer’s information to be solicited, persisted and reused. Figure 2 shows the registration sub-features, which top features can be defined as follows.

  • RegistrationEnforcement: If registration is enabled, there must be a policy to determine which actions in the eShop are restricted to registered users only.
  • RegistrationInformation: Registration requires that the customer provide information about themselves, which is stored in a customer profile.
  • UserBehaviourTrackingInformation: It allows the eShop to associate data that it collects on user actions to a registration profile. The additional information can be used to interpret the data from a marketing perspective.

eShop BuyPaths


Buy paths is a grouping of features relating to the customer purchase workflow. Figure 3 shows the buy paths sub-features, which top features can be defined as follows.

  • ShoppingCart: It allows a customer to keep track of the items that they wish to purchase during their shopping session.
  • CheckOut: It encapsulates the features related to the checkout process. In the process, the customer reviews the items they have added to their shopping cart, enters their payment and shipping information, selects any shipping and gift options, and confirms the order.
  • OrderConfirmation: It provides an acknowledgment to the customer that the order was received the order processor and placed successfully.

In the next two sections, we provide the sub-features of the features Security and Performance.

Security


Figure 4 illustrates an applicable set of security-related sub-features, which top features can be defined as follows.

  • Authentication: It defines the mechanisms that should be available in the eShop system to authenticate whether a subject or resource is the one claimed.
  • Authorization: It consists of the mechanisms that should be available in the eShop system to control the access of its users to functions and data.
  • Confidentiality: It defines the mechanisms that should be available in the eShop system to protect data or information from unauthorized disclosure, whether accidental or deliberate.
  • Integrity: It consists of mechanisms to detect unauthorized modification of the eShop system or any of its data.
  • AttackDetection: It defines the mechanisms that should be available in the eShop system to monitor network and/or system activities for malicious activities or policy violations and to produce the respective reports.

Performance


Figure 5 provides a graphical representation of an applicable set of performance-related sub-features, which top features can be defined as follows.

  • ResponseTime: It defines the target response time of the eShop system after a transmission key is pressed a customer.
  • Throughput: It defines the number of concurrent tasks the eShop system should be able to handle over a set unit of time.
  • ResourceUtilization: It defines the maximum load of resource utilization the eShop system should have as target on the server side.

Further Reading


More information on the eShop case study can be found in [1], when referring to the original Lau’s feature model, and in [2, Section 4], when referring to the extension with quality features and to ABS models. ABS models can be found in [3].

[1] Sean Quan Lau. Domain analysis of e-commerce systems using feature-based model templates. Master’s thesis, University of Waterloo, 2006.

[2] Evaluation of Modeling, February 2012. Deliverable 5.3 of project FP7-231620 (HATS), available at http://www.hats-project.eu/sites/default/files/Deliverable5.3.pdf#page=55

[3] ABS model of the eShop Product Line, February 2012, available at http://www.hats-project.eu/sites/default/files/eshop2012.zip

Categories: HATS project