180 likes | 366 Views
Behavioural Interoperability to Support Model-Driven Systems Integration. Alek Radjenovic, Richard Paige The University of York, UK. Context. Project: “Model Driven Integration” Industry partners use a mixture of software components from the supply chain
E N D
Behavioural Interoperabilityto Support Model-Driven Systems Integration Alek Radjenovic, Richard Paige The University of York, UK
Context • Project: “Model Driven Integration” • Industry partners use a mixture of software components from the supply chain • new code, third-party (COTS), legacy • Increased uncertainty during system integration • Models described using different: • platforms: UML, SysML, MODAF, MatlabSimulink, ... • tools: Rose RT, IBM RSA, Artisan Studio, ... • versions: UML 1.x vs. UML 2.x • Problem: lack of support for model driven integration
Importance • Detection of system integration problems very early on • during system design phase when models are created • before any new code is written • before a buy-in from a supply chain s/w manufacturer • Combining of system components that were not created: • at the same source • using the same (modelling or programming) platform
Technical requirements • Ability to bring together system components at the model level in order to be able to reason about: • structural compatibility (mainly evident at the syntax level) • behavioural compatibility (mainly evident at the semantic level) • Provide a tool framework (for the above) that is compatible for all relevant modelling technologies • as well as being extensible and scalable
Solution • A multi-paradigm modelling framework (SMILE) comprising: • a tool, a family of supporting languages, extension mechanism • SMILE capability: • compatibility checking of two or more input models • checking for potential structural (SMILE-S) and behavioural (SMILE-X) problems during integration • integration at model level (SMILE-I) • semi-automatic • detection of incompatibilities • guidance • manual user intervention
SMILE-S: in a nutshell • An interchange format • 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 trees • external to the core tool • i.e. the knowledge of the underlying meta-models and parsing is delegated to plug-in components
SMILE-S patterns • 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 model • enables us to associate semantics with structural model elements • 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 models • based on the chosen perspective, and • consequently perform simulations on the integrated system
SMILE-X: mapping, configuration & instantiation configuration • Initialisation • Temporal config. • Connections instantiation
SMILE-X: Scheduling, Triggers, Traces • Scheduling • options such as: simple activation, double buffer, or event based • Triggers • Compound Boolean expressions • Flags to halt execution • Simulation trace • Sequential • Provides information on: • Input and output messages • Failed conditions • Executed actions • Triggered conditions
Results • Through our initial exploration on small in-house case studies, we have been able to detect issues such as: • invalid state combinations • unused events • unreachable states • disconnected subsystems • out of sequence messages • deadlocks • properties that do not hold
Value • Potential to predict system integration problems early on in the development lifecycle that may: • influence decisions on software acquisition • save money • reduce development lifecycle timescales • reduce risks
Future directions • Immediate future • proof of scalability and extensibility • a real world case study from the avionics domain • in the order of 100s of UML packages • effort: 4 man-months • Beyond that... • potential for exploitation through tool vendors
Software SystemsEngineering Initiative www.ssei.org.uk