Successfully reported this slideshow.

Software Engineering of Component-Based Systems-of-Systems: A Reference Framework

2

Share

1 of 13
1 of 13

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Software Engineering of Component-Based Systems-of-Systems: A Reference Framework

  1. 1. 1 Software Engineering of Component- Based S stems of S stems A Systems-of-Systems: Reference Framework Frédéric Loiret (*) () Romain Rouvoy - Lionel Seinturier - Philippe Merle (**) * KTH, Sweden ** University of Lille & INRIA, France CBSE 2011 – Boulder, Colorado June 21-23, 2011 1
  2. 2. 2 Plan 1. Context & Motivations 2. 2 Reference Framework 3. Framework Implementations 4. 4 Evaluation 5. Conclusion 2
  3. 3. 3 1. Context & Motivations • Systems-of-Systems characterized by a wide diversity in terms of • Domain-specific requirements & analysis p q y • Embedded, real-time, reconfigurable IT systems • Technologies • Domain specific middleware, communication protocols Domain-specific middleware • Deployment environments (multi-scale) • WSN, SOA IT • New forms of complexity • High level design models centered on domain specific abstractions close to High-level domain-specific the problem domain • Applications should be adapted in the best way with a minimum effort • Adaptations may impact several steps of the design lifecycle • Implementation, analysis, compilation, execution 3
  4. 4. 4 2. Reference Framework Domain-Specific • Structured in three basic parts Annotations • Domain-agnostic invariants used throughout the design lifecycle Versatile Component Model Extensible Domain-Specific Modular Domain-Specific Middleware Interpreters Toolset Middleware Platform (Plugins) • Separation of Concerns between domain-agnostic & domain-specific features • Two roles • End-user developer • Domain-expert developer • Versatile Component Model used homogeneously • End-user application specifications • For implementing middleware platforms & toolset extension points 4
  5. 5. 5 Versatile Component Model • 6 generic & core architectural concepts • specialized via annotations • Simple string-based attributes as well as arbitrary complex views of the system • Used at design time, analysis time, compile time, runtime • Simple mechanisms but allowing to capture a wide range of software diversity • We do not impose a specific concrete syntax (considered as a variation point) 5
  6. 6. 6 Extensible Middleware Platform • Container • Connector • Third-party components 6
  7. 7. 7 Modular Toolset • Component based Component-based implementation • Core components implementing the domain-agnostic logic of CBSoS • Architecture visitors, consistency checks, optimizations, synthesis of implementation artifacts, implementation of the toolset’s workflow • Plugin components implementing the domain-specific logic • Via cleary-defined extension points y p • Implementing the interface of the extension point • Bundled on demand • Can be considered as a partially complete model interpreter 7
  8. 8. 8 Front-End Model-Artefact-Factory Reference Metamodel Metamodel Extension Artefacts handled AD files ADL ADL Annotations Binding Component Property Interface Content Dispatcher parser by the An ADL Loader L 1 toolset Another ADL Loader Description Another ADL Loader ADL ADL L d Loader Files Fil Parser ar oolset ID PD im files IDL Loader IDL Property Loader PDL L, P L, pl. Files Files odula T Description Ch k D i ti Checker Content L d C t t Loader Impl Files odel instance om n-specific annotation instances M Container-Generator Personality Factory 2 Connector Factory ons ponent mo Container Generator Third-party Integration Dispatcher Content Generation eferen com Container check nce D ain- entation artefacts 3 Architecture Transformation Architecture Analysis R 4 Back-End 5 Backend Bootstrap p Property Im m plem Dispatcher Interface Assembly Finalize Content Component Binding 8
  9. 9. 9 3. Framework Implementations • Distributed and Real-Time Environments  Hulotte Hulotte • Large Scale SOA Environments L S l E i t • Extension of Fractal-ADL (also support Think-  FraSCAti ADL, UML) • Back-End C & Java Aspects shared between both approaches • Runtime Component reification & reconfiguration support can be finely configured • Based on the reference framework • Java implementation, EMF metamodels FraSCAti F SCA i • Extensions expressed as partial architectures (set • SCA assembly language of plugins) • Invariants on the Back-End • default XML-based ADL • Java-based J b d • Special XML tags for serializing syntax-free • Fractal API annotations • Reconfiguration Capabilities • Used homogeneously f U dh l for • Bindings • Application-level & Middleware-level • Dynamic component instantiation architectures • Dynamic deployment of plugins • Toolsets and Plugins architectures 9
  10. 10. 10 3. Framework Implementations 10
  11. 11. 11 3. Framework Implementations 11
  12. 12. 12 4. Evaluation Complexity comparison between core features and their extensions Metrics from [Edwards, Medvidovic 2008] Hulotte FraSCAti 12
  13. 13. 13 5. Conclusion A reference framework defining domain-agnostic invariants used throughout the design lifecycle g y A strong SoC between domain-agnostic and domain-specific concepts and interpreters i t t • Promotes reuse, avoids redundant implementation efforts • Developers focused on the problem domain One Size Fits All solution is not realistic, but Hulotte & FraSCAti already cover a set of various domain-specific aspects • ADL abstractions are intuitively “specialization-aware” • Components can be used for tiny devices as well as for large scale large-scale environments 13

×