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