THE BIGLEVER NEWSLETTER: Special Series
The Software Product Line Lifecycle Framework: Standard Concepts and Constructs
Greetings from BigLever:
Welcome to the continuation of my special newsletter series on the Software Product Line (SPL) Lifecycle Framework. (To see the previous issues, visit BigLever's newsletter page.)
To overcome the problem of dissonant SPL concepts, technology, tools and techniques imposing disparate SPL silos in the development lifecycle, the SPL Lifecycle Framework provides a unified SPL solution. The framework introduces common constructs and concepts across the full system and software lifecycle. These common SPL concepts and constructs are provided by way of tool integration and asset integration into the SPL framework (click image to enlarge).
The purpose of tool integrations into the SPL framework is simply to make conventional development tools SPL-aware. This means making a tool aware and capable of working on reusable and configurable SPL core assets that contain internal SPL variations rather than merely working on conventional assets for one-of-a-kind applications.
The central concept in making any software development tool SPL-aware is the variation point. Variation points are the encapsulated locales within an asset that can be instantiated in different ways by the product configurator, based on feature selections in the feature profiles. For a development tool to be SPL-aware, it must be able to:
- identify and display variation points
- create and modify variation points (see next subsection on Asset Integration)
- enable the frameworks product configurator to instantiate variation points during product configuration
- display the instantiated representation of a variation point, as well as all the uninstantiated variability
- enable the frameworks production line development environment to perform semantic checks on variation points, impact analysis, statistics, queries and other SPL management operations
The SPL Lifecycle Framework provides a tool integration API for making existing software development tools SPL-aware.
Specific characteristics of a tool and its associated assets determine the type of integration that is required. When a tools assets have a text-based representation in the file system, the framework can often provide all the variation point capabilities, without the need for an explicit tool integration. When a tools assets are maintained in a proprietary internal representation, a deeper two-way integration is often required, where the tool is made SPL-aware and the framework is made tool-aware.
For example, the Telelogic DOORS® requirements management tool from IBM Rational uses a database for its proprietary internal representation of requirements. BigLever created a two-way bridge as a dual plugin between DOORS and the SPL Lifecycle Framework.
The integration bridges are independently installable options in the framework. When organizations transition to an SPL approach using the SPL framework, they identify preexisting bridges to match their existing toolset. IBM Rational has recognized the importance of the SPL Lifecycle Framework for supporting their customers' SPL demands and is working with BigLever to provide bridge integrations for their tools, across the full lifecycle.
The purpose of asset integration into the SPL framework is to enable conventional one-of-a-kind software assets to become reusable and configurable SPL core assets. The key to asset integration is adding the variation point concept and constructs into the asset structure:
- identify which asset constructs can become variation points
- define variation point encapsulations to contain the optional and alternative variants for the variation point, as well as the variation point logic to drive the variation point instantiation
- define the representation for variation point instantiations
To achieve the objective of common SPL concepts and constructs across all stages of the lifecycle, the variation point implementation in all assets must adhere to the variation point meta-model for the framework, as briefly outlined in the three bullets above.
Shared SPL Concepts and Constructs
The SPL Lifecycle Framework provides a single feature model and a single set of feature profiles that are shared across all the integrated tools and assets in a product line. The single product configurator in the framework provides a common instantiation semantics and mechanism, for all the integrated tools and assets. The frameworks software production line development environment provides a single, common administrative and development interface for managing SPL-specific engineering tasks for all the tools and assets across the full development lifecycle. These common concepts and constructs are provided by BigLever Software Gears.
Stay tuned for the upcoming installments of this newsletter series to learn more about how the SPL framework supports the full end-to-end SPL engineering lifecycle, plus how this Innovative new approach is providing a complete SPL solution at Lockheed Martin.
Charles W. Krueger
BigLever Software CEO
Don't miss your Newsletter!
Please help us make sure that you continue to receive the BigLever Newsletter by confirming your subscription with us. This ensures that future newsletters will be successfully delivered to your Inbox and not misplaced into your junk mail or spam folder.
To confirm, simply click the "confirm" link in the white bar below. After confirming, you can unsubscribe from our newsletter distribution at any time.