1 / 19

Integrating Heterogeneous Components in Software Supply Chains

This paper addresses the challenges faced in software supply chains, which are characterized by their heterogeneous nature. It highlights issues such as cross-supplier interoperability, overlapping functionality, and technology mismatches. The authors present a solution framework using glue components to bridge differences among suppliers, with a focus on an Eclipse-based tool developed for NXP's software development challenges. By outlining different integration approaches and providing insights into customer isolation and delivery of partially configured components, this work aims to enhance collaboration and efficiency in software ecosystems.

aderes
Télécharger la présentation

Integrating Heterogeneous Components in Software Supply Chains

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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!

More Related