1 / 17

Behavioural Interoperability to Support Model-Driven Systems Integration

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

lok
Télécharger la présentation

Behavioural Interoperability to Support Model-Driven Systems Integration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Behavioural Interoperabilityto Support Model-Driven Systems Integration Alek Radjenovic, Richard Paige The University of York, UK

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. SMILE-S trees

  8. 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

  9. 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

  10. SMILE-S/X: conceptual approach

  11. SMILE-X architecture

  12. SMILE-X: mapping, configuration & instantiation configuration • Initialisation • Temporal config. • Connections instantiation

  13. 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

  14. 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

  15. 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

  16. 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

  17. Software SystemsEngineering Initiative www.ssei.org.uk

More Related