A model-driven software product line framework for supply chain companies to facilitate software reuse and integration
Supply chains
- It is uneconomic for either the semiconductor manufacturer or their customers to develop all the necessary software
- As software is commoditized, companies can use commoditized components as part of their software solutions
- An ecosystem of suppliers is developing for feature-specific services
- However, companies today do not develop individual products, rather, they develop product lines - families of manufactured products, that need to be customized for a variety of physical devices, protocols, environments, and languages
- To cover the whole product line, companies need to use components from multiple suppliers, who offer some of the same functionality. This leads to a product line with alternative components
Figure 1: Supply chain scenario
The challenges
MoDSoC supports the following challenges
- Support for software reuse through product line modeling
- Support for component selection from various suppliers
- Integration of third party components with different technologies, different interfaces, different implementation styles
- Automatic generation of integration glue code from a model
- Support for partial configuration of the product to allow further different configurations by the customer
Our solution
We present a novel model-driven framework for software product lines. Software and systems product lines engineering is rapidly emerging as an important paradigm, allowing order-of-magnitude improvements in time to market, maintenance cost, quality, and mass customization support.
Our tools and methodologies facilitate software reuse, support integration, configuration and delivery of suppliers’ components in the supply-chain domain, enabling transformations into various product artifacts, including build scripts and glue code for the integration of third party suppliers’ components. Our solution is based on the Rational tools.
Solution Description
In addition to the known product lines variability constructs such as optional and alternative variation points, we introduce a novel product line variability pattern that supports selection among components with incompatible interfaces or different technology, which is a common situation in a supply chain scenario. This pattern allows engineers to replace an architecture component, which represents a variation point and has no actual implementation, by one of several alternative supplier components. Moreover, the interfaces of the alternative supplier components do not have to match the interfaces of their architecture component. This allows us to partially define the interfaces of the architecture component according to high-level specifications or standards, and fully define the interfaces of the actual supplier components including method names and signatures.
Using this pattern, we first define the supplier independent component model (SICM) containing architecture components, which represent variation points, and their composition. As a second step, we model the concrete components, some of which are supplier components and others are in-house components, with their variability points. We then specify which concrete components implement which architecture component with variability conditions, to get a supplier variation point model (SVP).
Figure 2: From SICM to SSCM
When we come to define a partially configured model for a downstream customer, we resolve the variation points of the architecture components by selecting suppliers or in-house components for each one, and possibly other component’s variation points. We run a model to model transformation that takes the SICM and create a supplier specific component model (SSCM). The transformation replaces each architecture component with a selected component, and tries to connect the selected components according to the connections of their respective architecture components. Whenever the interfaces do not match, or the components are of different component technology, integration is needed. A new glue component is then inserted as part of the transformation, allowing the two components to connect with newly created matching interfaces to the glue (see Figure 2).
Having an SSCM model allows us to model the required glue components and specify the needed integration in a model level, using UI assistance (see Figure 4). Furthermore, it allows us to separate the architecture variability choices that must be done in-house to allow component integration and postpone other variability decisions that will be done later by the downstream customer. After the glue is modeled, we perform model to code transformation and automatically generate source code for the glue components, components wrappers, and build scripts. These artifacts, which may still include code level variability, are delivered to a downstream customer, allowing them to make various variability decisions, even if they do not use modeling tools, and deliver various versions to their own customers. This way our SICM is a product line model of several SSCMs, where each represents a product line of a downstream customer.
Figure 3: Glue configuration process
The issues addressed in this project can be applied to various industries such as electronics, automotive, A&D, and more.
