Systems always get bigger and fatter over time i.e. systems will never get to be simpler than today. System evolution is hard to manage unless done systematically using an appropriate methodology i.e. processes, methods and tool support. For a Product Line, PL, this is of utmost importance since an increase in the number of features / products leads to an exponential rise in system complexity, see Figure 1.
Figure 1: Complexity vs. Number of Features/Products
In the past, we have seen at least two anti-patterns related to the way product lines are developed:
- Clone-and-Own: copies existing products and individually evolves products in isolation
- One-Size-fits-All: builds all PL features in a single product to deliver various features as a preconfigured product
Both approaches exponentially increase system complexity with the growing number of products.
Our solution, Evolving Systems Paradigm (ESP) delivers a methodology to solve this problem, increasing longevity of a business domain to match its market needs.
Evolving Systems Paradigm in a nutshell
ESP is the PL methodology to directly contain the risk of the “exponential rise in complexity” for rapidly evolving PLs.
ESP organises PL development activities around Product, Domain and Application Engineering teams, see Figure 2.
- Product Engineering approaches the problem by analysing the PL needs. It identifies features and organises them into Feature Trees to enhance communication with clients. Furthermore, Feature Models are elaborated with a separation into common and variable features within the scope of the PL. PL requirements are elicited, formally defined and related to identified features.
- Domain Engineering defines logical concepts and domain elements such as various kinds of Parts needed to fulfil the requirements. Parts are mapped to features. Reference architectures and frameworks are identified to match domain needs and used to accommodate Parts and their interactions.
- Application Engineering provides physical components used to build each PL product. It identifies various technologies e.g. embedded real-time tooling including implementation languages, compilers, hardware and deployment environments.
Figure 2: ESP views PL development as a set of Product, Domain and Application Engineering activities
Parts as a building unit for Product Lines
ESP is based on three major types of entities used to build all products of a PL. Let’s take a closer look into the content of the products and see what they are made of. We discover entities that may be identical, similar or unique in functionality:
- Initially, we notice identical entities scattered throughout each of the products. We identify and factor out all these entities away from the products and store a single instance of such entities into a PL Model Repository, PLMR. We name common entities: Core Parts, CPs.
- Next, we notice variants of entities repeating themselves in products. We identify all variants of a single entity. We collect and remove all variants away from the products and store a single entity instance in the PLMR. We name variable entities: Interchangeable Parts, IPs.
- Finally, what remains are product specific entities directly contributing to the uniqueness of the product.
We store an instance of each entity into the PLMR. We name unique entities: Product specific Parts, PsPs.
Variability and Binding Specifications
ESP enables Domain and Application engineers to separate out Part variability into domain and application variability specifications. Each variability dimension is expressed as a set of instructions including any required static and dynamic models needed to transform an IP into its Physical Parts i.e. original part variants.
Binding specifications define how to wire Physical Parts into architectures.
Each Part type is annotated with its variability and binding specifications.
 Physical Parts are Part Variants and shall not be confused with physical components used for deployment e.g. jars, exes, libs etc.
Using Parts, Variability and Binding Specifications
ESP process defines the two following steps:
- During analysis, we factor out variant parts into IPs and store IPs and related specifications including CPs and PSPs into the PLMR to enable their reuse
- Populating the PL with products built using entities from the Model Repository:
- Product creation starts at Variability Resolution Time when variability specifications are executed on IPs to transform Logical IPs into corresponding Physical Parts
- Product composition continues at Binding Time to execute binding specifications on Physical Parts to bind them into larger structures.
How it works
ESP is an invasive software composition technology. Parts are executable UML models: static & dynamic, formal & complete. Model transformations inject parts into the PL architecture to obtain products
The process of populating the target PL is given in Figure 3. Each product is a unique composition of Physical Parts composed into a specific Product Architecture. Product-Part Matrix specifies each product as a composition of CPs, IPs, PsPs and respective Binding and Variability Specifications. System Builder uses parts from the PLMR and the Product-Part Matrix to build complete product lines.
Figure 3: Populating the Target PL
Variability and Binding specifications are expressed using stereotypes defined in the ESP UML profile. Initially, the UML profile is applied and stereotypes allocated to corresponding entities. Next, stereotypes are materialised resulting in fully-blown Physical Parts, variants. Finally, Physical Parts are interconnected using interfaces and supplementary model elements into a fully functional product. Each intermediate model is persisted for debugging purposes. The UML profile is retracted, thus enabling processing of the next part.
Build and deploy
The output of the composition process is a PL baseline comprising executable product models. Several types of product models are created during the population of the Target PL:
- Product Domain Executable UML Models
- Product Implementation Models
- Product Build System Models
Product Domain Executable models are compiled by the model compiler into Implementation Models. Product Implementation Models are compiled by the Product Build System to obtain the product executables. Out-of-the-box implementation models are available for C, C++ and Java programming languages. Additional programming languages are available on request.
Product implementation models are promptly compiled, debugged and tested. The System Builder builds a single product as a composition of 7 +/- 2 IPs within 60 seconds, thus making the modify-compile-test cycles a programmer’s reality.
Benefits of the Evolving Systems Paradigm
ESP methodology is non-disruptive i.e. it is iterative, incremental and embraces legacy implementations. Existing systems are refactored, organised into parts with which the PLMR is populated. Legacy implementations are easily reused by creation of legacy interface models. Parts are bound to legacy interface models with corresponding Binding Specifications.
Each part in the PLMR is additionally equipped with following information:
- Test Drivers and Unit Tests modules per Physical Part
- Traceability to Key Features, Use Cases, User, Domain and Application Requirements, Technical System Requirements including Integration, Verification and Validation test cases, Deployment Plans and Scripts
- Complete implementation model and respective documentation set is generated for the product
- Automated collection and presentation of Test Results
When the PLMR is populated with Parts, ESP may be used to show that the concrete PL products may be regenerated from the models. Once proof has been obtained, we use the PLMR, instead of the concrete products, to evolve the PL completely covering the needs of the business domain.
Green field PL projects are expected to reap all benefits from the very first product deployment, enabling unprecedented product line longevity and supporting the business domain to deliver its full response to its market needs.