MDI 2010, Oslo, Norway

Behavioural Interoperabilityto Support

Model-Driven Systems Integration

Alek Radjenovic, Richard PaigeThe University of York, UK

Context

■ Project: “Model Driven Integration”■ Industry partners use a mixture of software components

from the supply chaino new code, third-party (COTS), legacy

■ Increased uncertainty during system integration■ Models described using different:

o platforms: UML, SysML, MODAF, Matlab Simulink, ...o tools: Rose RT, IBM RSA, Artisan Studio, ...o versions: UML 1.x vs. UML 2.x

■ Problem: lack of support for model driven integration

MDI 2010, Oslo, Norway

Importance

■ Detection of system integration problems very early ono during system design phase when models are createdo before any new code is writteno before a buy-in from a supply chain s/w manufacturer

■ Combining of system components that were not created:o at the same source o using the same (modelling or programming) platform

MDI 2010, Oslo, Norway

Technical requirements

■ Ability to bring together system components at the model level in order to be able to reason about:o structural compatibility (mainly evident at the syntax level)o behavioural compatibility (mainly evident at the semantic level)

■ Provide a tool framework (for the above) that is compatible for all relevant modelling technologieso as well as being extensible and scalable

MDI 2010, Oslo, Norway

Solution

■ A multi-paradigm modelling framework (SMILE) comprising:o a tool, a family of supporting languages, extension mechanism

■ SMILE capability:o compatibility checking of two or more input models

• checking for potential structural (SMILE-S) and behavioural (SMILE-X) problems during integration

o integration at model level (SMILE-I)o semi-automatic

• detection of incompatibilities• guidance • manual user intervention

MDI 2010, Oslo, Norway

SMILE-S: in a nutshell

■ An interchange formato describes the structure of heterogeneous models in a uniform fashion in

terms of trees• vertices = structural elements, edges = containment relationship• typically, a collection of properties to further describe characteristics of the

structural elements is attached to vertices

■ Transformation of input models into SMILE treeso external to the core toolo i.e. the knowledge of the underlying meta-models and parsing is

delegated to plug-in components

MDI 2010, Oslo, Norway

SMILE-S trees

MDI 2010, Oslo, Norway

SMILE-S patterns

MDI 2010, Oslo, Norway

■ By applying patterns to trees, we are able to extract (isolate) information of interest, and use transformations to define inputs to SMILE-X

SMILE-X: approach

■ Focuses solely on the behaviours in models■ Explores compatibility and interoperability issues via

simulation■ Uses templates to map artefacts from SMILE-S trees to

the specified behavioural modelo enables us to associate semantics with structural model elementso describes a particular behavioural paradigm (or, a related family of

behaviours) that we are interested in analysing• e.g. state machines

■ Facilitates a mechanism through which we can integrate behaviours of input modelso based on the chosen perspective, and o consequently perform simulations on the integrated system

MDI 2010, Oslo, Norway

SMILE-S/X: conceptual approach

MDI 2010, Oslo, Norway

SMILE-X architecture

MDI 2010, Oslo, Norway

SMILE-X: mapping, configuration & instantiation

MDI 2010, Oslo, Norway

configuration

instantiation- Initialisation- Temporal config.- Connections

SMILE-X: Scheduling, Triggers, Traces

■ Scheduling o options such as: simple activation, double buffer, or event based

■ Triggerso Compound Boolean expressionso Flags to halt execution

■ Simulation traceo Sequentialo Provides information on:

• Input and output messages• Failed conditions• Executed actions• Triggered conditions

MDI 2010, Oslo, Norway

Results

■ Through our initial exploration on small in-house case studies, we have been able to detect issues such as:o invalid state combinationso unused eventso unreachable stateso disconnected subsystemso out of sequence messageso deadlockso properties that do not hold

MDI 2010, Oslo, Norway

Value

■ Potential to predict system integration problems early on in the development lifecycle that may: o influence decisions on software acquisitiono save moneyo reduce development lifecycle timescaleso reduce risks

MDI 2010, Oslo, Norway

Future directions

■ Immediate futureo proof of scalability and extensibilityo a real world case study from the avionics domain

• in the order of 100s of UML packages• effort: 4 man-months

■ Beyond that...o potential for exploitation through tool vendors

MDI 2010, Oslo, Norway

MDI 2010, Oslo, Norway

Software SystemsEngineering Initiative

www.ssei.org.uk