Integrating Heterogeneous Components in Software Supply Chains

1. 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. Taken from “Formalizing Software Ecosystem Modeling” by V. Boucharas, S. Jansen, S. Brinkkemper 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

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

4. Simple Case: No overlapping functionality

5. Issue #1: Cross-Supplier Interoperability • Can Player of SupplierA work with Radio of SupplierB? • (The architecture prescribes some Player <-> Radio interaction)

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

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

8. Current Integration Approaches - 2/3 4 3 Adapt each component to a commonstandard • Up to 20 glue components: • A: 4+3 • B: 4+3 • C: 3+3 • Unnecessary glue complexityif standard and supplied interfaces significantly differ 3

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

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

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

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

13. 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. Issue #4: Customer Isolation • Level 1 (Basic) • Customer A should not get customer’s B components • (either binary or sources) • Level 2 • Customer A should not see customer’s B variation points/features

15. 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. 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. 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. 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. Thank You!