models modelling mbse
Download
Skip this Video
Download Presentation
Models, Modelling , MBSE

Loading in 2 Seconds...

play fullscreen
1 / 36

Models, Modelling , MBSE - PowerPoint PPT Presentation


  • 134 Views
  • Uploaded on

Models, Modelling , MBSE. Professor John Hosking, Dean of Engineering and Computer Science. Part 1 General Concepts. Models and modelling. Formalisation language syntax/semantics Scope of applicability Insight Execution Prediction. v = u + at v 2 = u 2 + 2as s = ut + ½at 2.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Models, Modelling , MBSE' - laken


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
models modelling mbse

Models, Modelling, MBSE

Professor John Hosking,

Dean of Engineering and Computer Science

models and modelling
Models and modelling

Formalisation

language syntax/semantics

Scope of applicability

Insight

Execution

Prediction

v = u + at

v2 = u2 + 2as

s = ut + ½at2

models and modelling1
Models and modelling

Formalisation

language syntax/semantics

Scope of applicability

Insight

Execution

Prediction

CH4 + 2 O2 -> CO2 + 2 H2O

models and modelling2
Models and modelling

Formalisation

language syntax/semantics

Scope of applicability

Insight

Execution

Prediction

models and modelling3
Models and modelling

Formalisation

language syntax/semantics

Scope of applicability

Insight

Execution

Prediction

models and engineering
Models and Engineering
  • Engineering is about modelling
    • Including Software Engineering
    • Much of the engineering process is about taking a specification and turning it into design model(s)
      • Using theory, methodology, evidence based best practice
    • Models are tested
      • scope of applicability
      • compliance to specification
    • Models are used to specify detailed construction
    • Construction overseen by engineers
      • true for SE?
modelling and software engineering
Modelling and Software Engineering

“The growing complexity of software is the motivation behind work on industrializing software development. In particular, current research in the area of model driven engineering (MDE) is primarily concerned with reducing the gap between problem and software implementation domains through the use of technologies that support systematic transformation of problem-level abstractions to software implementations.”

France and Rumpe,2007, Model-driven Development of Complex Software: A Research Roadmap, FOSE’07

mde is about communication
MDE is about Communication

Model

Problem Domain

Implementation Domain

Req Model

Analysis Model

Design Models

Design Model

Problem Domain

Implementation Domain

Test Models

Test Models

What modelling language(s)?

How are they designed to be effective?

How are they implemented?

mde is about viewpoints
MDE is about Viewpoints

Req Model

Analysis Model

Design Models

Design Model

Problem Domain

Implementation Domain

Test Models

Test Models

Separation of concerns

Consistency management

Hidden dependencies

mde is about automation
MDE is about Automation

Auto/semi-auto

transform

Performance?

Deadlocks?

Transform Model

Anti Patterns?

Req Model

Analysis Model

Design Models

Design Model

Problem Domain

Implementation Domain

Test Models

Self Consistent?

Code Smells?

Test Models

Transform specn?

Traceability links?

Consistency?

Versioning?

Analysis tool scope?

Limitations?

Usability?

Specification/implmn

Coverage?

mde challenges
MDE Challenges

“… we consider the problem of developing MDE technologies that automate significant portions of the software lifecycle to be a wicked problem. A wicked problem has multiple dimensions that are related in complex ways and thus cannot be solved by cobbling solutions to the different problem dimensions.”

France and Rumpe,2007, Model-driven Development of Complex Software: A Research Roadmap, FOSE’07

mde and formal methods
MDE and Formal Methods
  • Why not just use formal specification techniques?
    • FSTs typically limited in scope
      • Eg only work for some viewpoints
    • Tradeoff in expressability and ability to mechanically analyse
    • Hence use FSTs to analyse subset of models
      • Eg Z models for data and operation viewpoints
      • “Model checking” for state transition viewpoints
      • Petri nets for control flow viewpoint
development versus runtime models
Development versus Runtime Models
  • Most MDE initiatives have focused on development models
    • Abstractions above code
  • Runtime models present abstractions of executing systems
    • How to use to manage and modify executing software
      • Adaptive systems – monitor behaviour (eg performance) and adapt (eg add extra servers)
some major mde initiatives
Some major MDE initiatives
  • Model Driven Architecture (MDA) - OMG
    • Three viewpoints: computation independent, platform independent and platform dependent
    • MOF, UML, QVT
    • Very rich set of modelling languages lost of complexity
    • Example of “extensible general purpose modelling language” approach
  • Software factories – Microsoft
    • Many small domain specific viewpoints linked by transforms
    • Small lightweight modelling languages
    • Heavy emphasis on reuse of knowledge
    • Example of “domain specific modelling language” approach
pros and cons
Pros and cons

Extensible GPML

+ “Standard” models

+ Model interchange

+ Analysis tool interchange

+ Build it once

  • Complex languages
  • Not client friendly
  • Extension mechanisms complicate things

Domain Specific MLs

+ Client friendly

+ Simple languages

+ Simpler tooling

  • Build it often
  • Smaller user base => higher maintenance cost
  • DSL Babel challenge
model driven systems engineering
Model Driven Systems Engineering
  • Extends from Software Engineering to Systems Engineering
  • Typically Extensible GPML based
    • Heavy emphasis on standardisation
    • Not surprising
  • Egs
    • SysML
    • Function Blocks (more for embedded systems)
    • BIM/IFC (for integrated design of buildings)
sysml
SysML
  • OMG driven (UML standards developers)
  • Extends/restricts UML (ie GPML approach)
    • New viewpoints
      • Requirements, Parametric views
      • Supports V&V, gap analysis
    • Eliminates some software centric viewpoints
      • Only uses 7 of UML 2’s 13 diagrams
      • Replaces “classes” with “blocks”
iec 61499 function blocks
IEC 61499 Function Blocks
  • From Control community
  • Pushes Block concept in SysML further
    • Gaining popularity in embedded systems community
    • Arguably more implmnoriented than SysML
    • See Vyatkin review paper
    • Argues for combining
bim ifc
BIM IFC
  • Building information modelling
    • Integrates viewpoints of multiple professionals working on constructing/maintaining buildings
      • Engineers, PMs, architects, builders, plumbers, …
    • Aims to revolutionise building construction
    • Current state of the art – much manual rentry of data
      • Significant opportunity for error
      • BIM aims for standardised interoperability
  • Industry Foundation Classes
    • Base set of classes defining the multiple viewpoints
    • EXPRESS modelling language extensible GPML approach
  • Much work done – much to do
some areas of contribution
Some areas of contribution
  • Meta-tools for simply implementing graphical modelling languages (domain specific visual languages – DSVLs)
  • Performance estimation tools
  • Model transformation tools
  • EXPRESS modelling environment
  • Requirements extraction tools

A few examples follow

how to build a domain specific visual modelling language dsvl
How to build a Domain Specific Visual Modelling Language (DSVL)?
  • Design the DSVL formalism
    • Domain modelling, Physics of Notations, Cognitive Dimensions of Notations, …
  • Design and implement an editing environment & possibly a code generator
    • Icons and connectors, domain model, views on domain model, behaviour under user interaction, code generator, simulator, …
    • Lots of programming OR use a meta-tool
meta tool
Meta-tool
  • Tool to help build other software tools
  • In this case a tool to specify a DSVL and its modelling environment and which generates the environment
  • It typically uses several DSVLs to make specification easy

Tool designer Tool end user

uses specifies/generates uses specifies/generates

Meta tool DSVL Modelling tool Other possibly executable models

my group s meta tool research work

Pounamu

2003

JViews

1997

Ispel

1991

JComposer

1998

Marama

2007 …

Kea

1989

MViews

1993

My group’s meta-tool research work
  • Have developed a series of frameworks and meta tools for DSVL specification

Design Tools

Engineering,

Software

Frameworks for

constructing multi-view

multi-notation environments

Meta tools for specifying &

constructing multi-view

multi-notation environments

Java +

Web Services

Eclipse +

Java

Prolog

Java

Plus lots of applications developed using the frameworks & meta tools

tool specification using marama
Tool Specification using Marama

GeneratedModelling Tool

  • Domain model
    • EER
    • OCL
  • Icons &Connectors
  • Views
    • Icons/connectors
    • Model elements
    • Mappings
  • Behaviour
    • Constraints
    • Layout

About a day to specify and implement a basic modelling tool

marama notes
Marama notes
  • Marama is an example of a model driven toolset itself
    • New DSVL expressed using a variety of graphical models expressing different viewpoints then DSVL environment auto generated from those models
  • Supports DSML approaches
    • Easy to design and implement small modelling languages
  • A research tool
    • Lacks lots of features you’d want in a production toolset
    • But has been hardened and used in industrial projects (for large European banks) by Sofismo, a Swiss MDE consultancy company
p erformance estimation maramamte
Performance estimation – MaramaMTE
  • Example of a model analysis tool
  • Implemented using Marama
  • Given a software architecture how well will the implemented system work?
  • MaramaMTE supports
    • Modelling software architectures for service oriented systems
    • Modelling of workload models
    • Generation of testbed able to be exercised using workload model; generates workload testbench
      • Assumes inter-component comms cost less than computation cost
    • Deployment of testbed and workload testbench onto real hardware
    • Runs system – generates performance stats
maramamte
MaramaMTE

End user interaction spec

Architecture spec

requirements extraction maramaai
Requirements extraction – MaramaAI
  • Takes textual requirements in the form of scenario descriptions
  • Auto-extracts Essential Use Cases
    • Abstracted interaction models
  • Supports English and Malay!
  • Matches the derived EUCs against known EUC patterns
    • Looking for errors/missing features/etc
  • Generates mock user interfaces for RE to confirm requirements with client
    • Round trip engineering
  • Maintains consistency between the various viewpoints
extraction and mapping
Extraction and mapping

Map to the EUC diagram categorising “select option” interaction as a “user intention”

2

3

1

“select voter registration option (1)” is mapped to a particular abstract interaction – “select option (2)”

summary
Summary
  • Models and their importance in Science and Engineering
  • MDE basics
  • Issues with MDE and examples of initiatives
  • MD Systems Engineering
  • Meta tools for quickly specifying and implementing DSVLs and their environments
  • A couple of model analysis and transformation tool examples
ad