1

Software Engineering of Component-Based S stems of S stems ABased Systems-of-Systems: A

Reference Framework

Frédéric Loiret (*)Frédéric Loiret ( )Romain Rouvoy - Lionel Seinturier - Philippe Merle (**)

* KTH, Sweden** University of Lille & INRIA, France

CBSE 2011 – Boulder, ColoradoJune 21-23, 2011

1

2

Plan1. Context & Motivations

2 Reference Framework2. Reference Framework

3. Framework Implementations

4 Evaluation4. Evaluation

5. Conclusion

2

3

1. Context & Motivations

• Systems-of-Systems characterized by a wide diversity in terms of• Domain-specific requirements & analysisp q y

• Embedded, real-time, reconfigurable IT systems• Technologies

• Domain specific middleware communication protocols• Domain-specific middleware, communication protocols• Deployment environments (multi-scale)

• WSN, SOA IT

• New forms of complexity• High level design models centered on domain specific abstractions close to• High-level design models centered on domain-specific abstractions close to

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

2. Reference Framework

• Structured in three basic parts• Domain-agnostic invariants used

Domain-SpecificAnnotations

Domain-agnostic invariants usedthroughout the design lifecycle Versatile

Component Model

Domain-SpecificMiddleware

Domain-SpecificInterpreters(Plugins)

ExtensibleMiddleware

Platform

ModularToolset

• Separation of Concerns between domain-agnostic & domain-specific features• Two rolesTwo roles

• End-user developer• Domain-expert developer

• Versatile Component Model used homogeneously• Versatile Component Model used homogeneously• End-user application specifications• For implementing middleware platforms & toolset extension points

4

5

Versatile Component Model

• 6 generic & core architectural concepts6 generic & core architectural concepts• specialized via annotations

• Simple string-based attributes as well as arbitrary complex views ofwell 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

Extensible Middleware Platform

• Container• ConnectorConnector• Third-party components

6

7

Modular Toolset

• Component-based implementationComponent 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 pointsy p• Implementing the interface of the extension point• Bundled on demand

• Can be considered as a partially complete model interpreter

7

8

Front-End Model-Artefact-Factory

Metamodel ExtensionReferenceMetamodel

Annotations Binding Property InterfaceComponent Content ADL parser

An ADL LoaderAnother ADL LoaderAnother ADL LoaderADL L d

ADL Dispatcher

Description ADLFil

Metamodel Extension

Artefactshandledby the toolset1

ADL

files

Another ADL LoaderADL Loader

IDL Loader

D i ti Ch k C t t L d

Property Loader

Parser Files

PDLFiles

IDLFiles

Implar T

ools

et

PDL,

impl

. file

s

Description Checker Content Loader

Container-Generator

Personality FactoryConnector Factory

ImplFiles

Mod

ula

2

IDL,

P

ons

inst

ance

s

odel

inst

ance

Container GeneratorDispatcher

Third-party Integration

Content Generation

Container check

n-sp

ecifi

c an

nota

tion

nce

com

pone

nt m

o

Architecture Transformation Architecture Analysis

Back-EndBackend

3

4

5 Bootstrap Property men

tatio

n ar

tefa

cts

Dom

ain-

Ref

eren

Dispatcher5 p Property

Interface

Content Component BindingFinalize

Assembly

Impl

em

8

9

3. Framework Implementations• Distributed and Real-Time Environments

HulotteL S l SOA E i t Hulotte• Large Scale SOA Environments FraSCAti

Hulotte• Extension of Fractal-ADL (also support Think-

ADL, UML)• Back-End C & Java

Aspects shared between both approaches• Based on the reference framework• Java implementation, EMF metamodels

• Runtime Component reification & reconfiguration support can be finely configured

F SCA iJava implementation, EMF metamodels• Extensions expressed as partial architectures (set

of plugins)

FraSCAti• SCA assembly language• Invariants on the Back-End

• J b d• default XML-based ADL• Special XML tags for serializing syntax-free

annotations• U d h l f

• Java-based• Fractal API

• Reconfiguration Capabilities• Bindings• Used homogeneously for

• Application-level & Middleware-level architectures

• Toolsets and Plugins architectures

• Bindings• Dynamic component instantiation• Dynamic deployment of plugins

Toolsets and Plugins architectures

9

10

3. Framework Implementations

10

11

3. Framework Implementations

11

12

4. EvaluationComplexity comparison between core features and their extensionsMetrics from [Edwards, Medvidovic 2008]

Hulotte

FraSCAtiFraSCAti

12

13

5. Conclusion

A reference framework defining domain-agnostic invariants used throughout the design lifecycleg y

A strong SoC between domain-agnostic and domain-specific concepts and i t tinterpreters• Promotes reuse, avoids redundant implementation efforts• Developers focused on the problem domainDevelopers 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• Components can be used for tiny devices as well as for large-scale

environments

13