© 2010 IBM Corporation IBM Research – Haifa Virage Logic Integrating Heterogeneous Components in Software Supply Chains Herman Hartmann, Aart Matsinger, Tim Trew Virage Logic, The Netherlands Mila Keren, Julia Rubin, Tali Yatzkar-Haham IBM Research - Haifa, Israel

2/19 Software Supply Chains Software vendors do not function as independent units not all customers are end-users not all software is built in-house there are multiple suppliers Taken from Formalizing Software Ecosystem Modeling by V. Boucharas, S. Jansen, S. Brinkkemper

3/19 Scope Present issues that arise in product line supply chains Based on real problems/needs of NXP Developed Eclipse-based tool to address NXPs s/w development challenges Component-oriented Agreed standard but not an agreed API

4/19 Simple Case: No overlapping functionality

5/19 Issue #1: Cross-Supplier Interoperability Can Player of SupplierA work with Radio of SupplierB? –(The architecture prescribes some Player Radio interaction)

6/19 Glue code needed! Bridge over differences in names, styles, etc –E.g.: passing 3 ints vs. passing a struct of 3 ints

7/19 Current Integration Approaches - 1/3 Create all possible glue components during domain engineering Navigation: 4 alternatives Connectivity: 3 alternatives Audio processing: 3 alternatives Up to 33 different glue components –A: 4x3 –B: 4x3 –C: 3x

8/19 Current Integration Approaches - 2/3 Adapt each component to a common standard Up to 20 glue components: –A: 4+3 –B: 4+3 –C: 3+3 Unnecessary glue complexity if standard and supplied interfaces significantly differ 4 3 3

9/19 Current Integration Approaches - 3/3 Create the required glue component during application engineering glue is defined late in the development process 4 3 3

10/19 Issue #2: Overlapping Functionality – Feature Selection Logic is Complicated

11/19 Example 1: Unmatched Features No 45W output in SupplierA

12/19 E.g. 2: Contradictions MP3 in SupplierB requires a CD

13/19 Issue #3: Technology Mismatch Components of different technologies –(Assuming interface mismatch is solved) Differences in: –Calling conventions –Name mangling –Object layouts –Sizes of primitive types –BigEndian vs. littleEndian

14/19 Issue #4: Customer Isolation Level 1 (Basic) –Customer A should not get customers B components –(either binary or sources) Level 2 –Customer A should not see customers B variation points/features

15/19 Issue #5: Delivery of Partially Configured Components Binary deliverables –Better customer isolation –Alas, preprocessor-based variations are already resolved Source deliverables –Need to compile on different build environments –Materializer needs to take the environment into account

16/19 The Zigbee Architecture –There is a standard but not an API –(However, the API is likely to be similar across suppliers) –Customer want to mix layer from different suppliers

17/19 Solution Overview: Glue Various kind of glue generators Implemented as a Model-to-Text transformation Invoked as part of the materialization process Predefined rules for choosing a glue generator –Based on the chosen components/suppliers –Engineer can override

18/19 Solution Overview: Implementation Constraints Concrete components are annotated with supplier name –(as well as additional implementation data) Selection of a concrete component will force selection of other concrete components Based on: –Architectural links –Ability to generate glue

19/19 Thank You!