Your SlideShare is downloading. ×
Software Engineering of Component-Based Systems-of-Systems: A Reference Framework
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

1,122
views

Published on

Presentation at the CBSE 2011 conference

Presentation at the CBSE 2011 conference

Published in: Technology, Business

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,122
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
15
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 Plan1. Context & Motivations2.2 Reference Framework3. Framework Implementations4.4 Evaluation5. Conclusion 2
  • 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 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. 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 Extensible Middleware Platform• Container• Connector• Third-party components 6
  • 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 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 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. 103. Framework Implementations 10
  • 11. 113. Framework Implementations 11
  • 12. 124. Evaluation Complexity comparison between core features and their extensions Metrics from [Edwards, Medvidovic 2008] Hulotte FraSCAti 12
  • 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