Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,597 views

Published on

Presentation at the CBSE 2011 conference

Published in: Technology, Business
  • Finally found a service provider which actually supplies an essay with an engaging introduction leading to the main body of the exposition Here is the site ⇒⇒⇒WRITE-MY-PAPER.net ⇐⇐⇐
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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

  1. 1. 1Software 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 Plan1. Context & Motivations2.2 Reference Framework3. Framework Implementations4.4 Evaluation5. 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. 5Versatile 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. 7Modular 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 instancesM 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 & JavaAspects 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. 103. Framework Implementations 10
  11. 11. 113. Framework Implementations 11
  12. 12. 124. Evaluation Complexity comparison between core features and their extensions Metrics from [Edwards, Medvidovic 2008] Hulotte FraSCAti 12
  13. 13. 135. ConclusionA reference framework defining domain-agnostic invariants used throughout the design lifecycle g yA 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 domainOne 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

×