1. Professor John Hosking, Dean of Engineering and Computer Science Models, Modelling, MBSE

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

3. Models and modelling Formalisation language syntax/semantics Scope of applicability Insight Execution Prediction CH 4 + 2 O 2 -> CO 2 + 2 H 2 O

4. Models and modelling Formalisation language syntax/semantics Scope of applicability Insight Execution Prediction

5. Models and modelling Formalisation language syntax/semantics Scope of applicability Insight Execution Prediction

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

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

8. MDE is about Communication Problem Domain Implementation Domain Model Test Models Design Model Problem Domain Implementation Domain Req Model Design Models Analysis Model Test Models What modelling language(s)? How are they designed to be effective? How are they implemented?

9. MDE is about Viewpoints Test Models Design Model Problem Domain Implementation Domain Req Model Design Models Analysis Model Test Models Separation of concerns Consistency management Hidden dependencies

10. MDE is about Automation Test Models Design Model Proble m Domain Implementation Domain Req Model Design Models Analysis Model Test Models Anti Patterns? Coverage? Self Consistent? Code Smells? Deadlocks? Performance? Auto/semi-auto transform Transform Model Transform specn? Traceability links? Consistency? Versioning? Analysis tool scope? Limitations? Usability? Specification/implmn

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

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

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

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

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

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

17. 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”

18. IEC 61499 Function Blocks From Control community Pushes Block concept in SysML further –Gaining popularity in embedded systems community –Arguably more implmn oriented than SysML –See Vyatkin review paper –Argues for combining

19. 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 re-entry 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

20. Summary Models and their importance in Science and Engineering MDE basics Issues with MDE and examples of initiatives MD Systems Engineering approaches