System Overview

Software product line engineering is a systematic approach to achieving software reuse. It aims to minimise the overheads incurred when building a family of software products that have significant shared features yet various differences. SPLE and its reuse-oriented methodology has many advantages, both financial and technical, and industrial case studies document the successes it can bring.
The idea of software product families was first documented by Parnas. SPLE has been researched in increasing depth over the past two decades. Its use in industry has also increased, beginning with larger businesses such as Boeing, Hewlett-Packard, and LG, and latterly making inroads into smaller enterprises such as Salion. However, due to its relative newness and its perceived overheads it is not yet in widespread use in small- to medium-sized enterprises (SMEs). Efforts exist to bring the benefits of SPLE to companies less able to accept its large up-front analysis times.
SPLE is traditionally split into two main processes: domain engineering and application engineering. In domain engineering the scope of the domain of the product family is defined, and common and variable parts across all product instantiations are identified. The commonalities and variabili- ties are represented in a variability model. Application engi- neering is where concrete product instantiations are produced from the assets and models that have been produced in the domain engineering process. This requires the production of a configuration specification of the variability model, which defines the features to be included (and excluded) from the product in question. A transformation process must then take place, mapping the assets and the configuration specification into a concrete product.
There are three ways in which an organisation can undertake product line engineering: proactive, extractive, and reactive. The proactive approach in- volves complete domain analysis and variability management being performed in advance of any application engineering. In many small- to medium-sized enterprises the large upfront costs of this approach mean it is not viable. In contrast, the reactive approach involves creating and updating the product line as and when new members of the family appear. Extensive domain analysis is avoided, and time can be saved. The extractive approach involves bootstrapping a product line by taking existing products as the base for the core assets. The extractive and reactive approaches can be used in conjunction.
In a variability or feature model, constraints are introduced on how a combination of features can be selected for a product derivation.
Mandatory features. Mandatory features are denoted by a filled circle on the feature tree. Mandatory features must be included in a product derivation. As such, they are core components in the product line, shared across all derivations. Authentication is a mandatory feature in the PEP.
Optional features. Optional features are denoted by an unfilled circle on the feature tree. They can be included in product derivations if chosen, but do not have to be. Mentors is an optional feature in the PEP.
Alternative features. Alternative features provide a set of features from which one can be chosen. They are mutually ex- clusive. PassThrough and FormsBased are alternative features of Authentication in the PEP.
Or features. Or features provide a set of features from which one or more can be chosen.
Requires constraint. A requires constraint provides a link between between features on two separate branches of the feature tree. The selection of one feature requires that another feature must also be chosen. Linked Mentors =⇒ Mentors is a contraint in the PEP.
Excludes constraint. An excludes constraint stipulates that a certain feature can only be selected if a particular other feature is excluded from the selection.
The software development technique of continuous integration provides an automated process that builds, tests, analyzes, and deploys an application to help ensure that it functions correctly, follows best practices, and is deployable. This process runs with each source-code change and provides immediate feedback to the development team. The process in ApleT spreads the benefits of this across all the products in a product line.
Continuous integration can be performed with continuous integration software running on a CI server1. The CI software allows for the set up of multiple build jobs, each of which is the configuration of steps required to build, test, analyze and deploy a particular application. ApleT extends this to allow all the product instances in a product line to be built, tested, analyzed and deployed automatically.
A job configuration build process may farm out some of the build pipeline to dedicated build scripts. Build scripts are called by the CI server and do a lot of the work. Build script languages include Ant, NAnt, rake, psake, FAKE.
An important part of CI is to make the builds self-testing. Tests can include unit tests, integration tests and end-to-end tests. The ApleT approach focuses on end-to-end tests through the use of BDD executable acceptance tests. BDD was chosen for the high-level description of specifications it provides. It does not preclude the use of unit or integration tests.
Behaviour-driven development is an agile software develop- ment process with processes and tool support for discovering, documenting, and implementing software specifications. BDD can be broadly split into two main parts - facilitating discussion between software developers and product owners, and providing continuous, automated feedback on the implementation of software specifications.
Gherkin is a domain-specific language used in BDD for describing system behaviours. The primary units of Gherkin are features, scenarios, and scenario steps.
-
Features. Features are the main unit within the exe- cutable specification portion of BDD. Features have a user story that describes the relevant user for whom the feature is for; what benefit it brings to them - what is the reason for its inclusion in the system; and what it actually does. Features are composed of a number of different scenarios.
-
Scenarios. Scenarios are constituent parts of features, and describe different possible paths through a feature. A scenario describes what should happen when a given system behaviour is exercised in a given set of circum- stances. There may be “happy paths”, where the feature works as desired, and there will be paths where certain validation checks or business processes do not comply and have to be dealt with. The execution of scenarios can be automated. Scenarios are correspond to acceptance tests; if all scenarios in a feature pass, then we can say that that feature “passes” and the desired behaviour is being achieved. Scenarios are composed of a number of steps that describe the state that exists and the actions and expectations that occur during a scenario.
-
Scenario Steps. Scenarios are composed of steps labelled as Given, When, and Then. These names correspond to the Arrange-Act-Assert pattern from TDD. Given steps set up the context for the scenario. The When steps exercise some functionality of the system, and the Then steps make a number of assertions about how the system state should be following those actions.
In behaviour-driven frameworks such as Cucumber and SpecFlow, scenario steps are linked to step definitions, which is a layer of fixture code that exercises production code.
ApleT extends the executable specifications of BDD with variability concepts. This allows for the creation of BDD feature specification tests. Based on the parameterisation provided by the job configuration, the correct specifications are run against the correct version of the product.