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
Plan
1. Context & Motivations
2.
2 Reference Framework
3. Framework Implementations
4.
4 Evaluation
5. 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.
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
Extensible Middleware Platform
• Container
• Connector
• Third-party components
6

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
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
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
3. Framework Implementations
10

11.
11
3. Framework Implementations
11

12.
12
4. Evaluation
Complexity comparison between core features and their extensions
Metrics from [Edwards, Medvidovic 2008]
Hulotte
FraSCAti
12

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