DIT945/TDA593 Model-Driven Software

Development
Introduction
Patrizio Pelliccione
Associate Professor (Docent), Chalmers|GU
www.patriziopelliccione.com
About myself
Associate Professor, Software Engineering division, Computer Science and
Engineering department Chalmers | University of Gothenburg

Autonomous and smart systems

Adaptation
Evolution
http://wasp-sweden.org/
https://www.chalmers.se/sv/styrkeomraden/ikt/forskning/automatiserat-samhalle/wasp/Sidor/default.aspx

Achieving complex Collaborative Missions

via Decentralized Control and Coordination
of Interacting Robots
http://www.co4robots.eu/
http://www.co4robots.eu/

Next Generation Electrical Architecture

Volvo Cars and many suppliers
http://ngea.se/
https://www.researchgate.net/project/Next-Generation-Electrical-Architecture-NGEA
About Myself

More than 10 years of experience working on modeling and

Model-driven Engineering (MDE)
Model-driven Engineering for architecture modeling and verification
Model-driven Engineering for managing upgrade of complex systems
Model-driven Engineering for robotic systems
Model driven Engineering in industry
TEAM
Examiner and course responsible:
Patrizio Pelliccione - patrizio@chalmers.se Lecturers:
Patrizio Pelliccione
Supervisors: Grischa Liebel -
grischa@chalmers.se
Magnus gren magnus.agren@chalmers.se
Magnus gren
Piergiuseppe Mallozzi mallozzi@chalmers.se
Piergiuseppe Mallozzi
Claudio Menghi menghi@chalmers.se
Claudio Menghi
Michal Palka michal.palka@chalmers.se
Michal Palka
Sergio Garcia gsergio@chalmers.se
Sergio Garcia
Representatives

Chalmers
JOSEFIN KVILLERT - kvillert@student.chalmers.se
SIMON SUNDSTRM - simsund@student.chalmers.se
SAMUEL UTBULT - usamuel@student.chalmers.se

GU
Looking for three volunteers!
Course objectives

Learn how to design and develop a

software system using software
modeling techniques
Learn different types of models
Critical understanding on how to use
models and when using models brings
benefits
Changes from previous year

Changed the project from booking system for a hotel to

robotic domain

Reduced the focus on code generation and anticipated

the assignment of generating code

More focus on architecture

Each supervisor is specialized in a topic and he will

follow all the groups on that topic
Webpage

We will use pingpong!

GU students please register
to PingPong
https://pingpong.chalmers.se/public/
courseId/8815/lang-en/publicPage.do
Literature list
Model-driven Software Engineering (MDSE) in Practice. The book on MDD, MDE,
MDA, MD* by Marco Brambilla, Jordi Cabot, and Manuel Wimmer. 2nd edition. Morgan &
Claypool, 2017. ISBN (paperback) 9781627057080. (ebook) 9781627059886

UML @ Classroom - An Introduction to Object-Oriented Modeling. Authors: Martina

Seidl, Marion Scholz, Christian Huemer, Gerti Kappel. ISBN: 978-3-319-12741-5 (Print)
978-3-319-12742-2 (Online)

Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented

Analysis and Design and Iterative Development, 3rd edition, Prentice Hall PTR,
2005. ISBN-13: 978-0131489066, ISBN-10: 0131489062

Slides and papers suggested during the lectures

 Detailed schedule
(Seven weeks)

https://pingpong.chalmers.se/public/courseId/8815/lang-en/publicPage.do?item=4067534
Course structure
8 Lectures
5 Assignments
will create the project
No grading for assignments
5 Compulsory supervisions

Sub-courses
Project (Projekt), 6 higher education credits
Template of the report on pingpong
Written assignment (Skriftlig inlmningsuppgift), 1.5
higher education credits

Final presentation
One or two days
2017-01-11/12
Lindholmen, Jupiter building, 4th floor, room 473
Groups definition -
Supervision
Groups will be randomly generated
Groups will be created according to the data you
will provide in the Google form:

https://goo.gl/forms/pZZNEhtYkXSw3gBB3
 Examination

https://pingpong.chalmers.se/public/courseId/8815/lang-en/publicPage.do?item=4067532
Self-evaluation

Peer-evaluation Group work for each

assignment mandatory!
For each assignment you should submit the group
assignment and the individual peer-evaluation
group work (PeerEval-GroupWork.docx in
Pingpong - templates)

Final self- and group-evaluation at the end of the

course (Final_self-and_group-evaluation.docx in
Pingpong - templates) mandatory!
The Project Topic
Design + prototype of a robotic system

Project description as input

Models, simulation, running code as an output

The project description is available on PingPong under the Project

Description page
Project Assignments
Assign. 1 (W1): Setup, Use Cases, Dom. Model
Assign. 2 (W2): Architecture
Assign. 3 (W3-W4): Class Diagrams & Code Gen.
Assign. 4 (W5): State diagrams
Assign. 5 (W5): Sequence Diagrams

All assignments together: Final report

Additionally: Individual report
Supervision Slots
Tuesdays 08:00 - 09:45
Tuesdays 10:00 - 11:45
Tuesdays 15:15 - 17:00
Wednesdays 08:00 - 09:45
Mandatory supervisions in W2, 3, 5, 6, 7
Wednesdays 10:00-11:45 Groups: Random based on survey
Thursdays 8:00-9:45 Groups will be created ASAP
Thursdays 10:00-11:45
Thursdays 15:15-17:00
Fridays 8:00-9:45
Fridays 10:00-11:45
Submissions & Grading
All submissions via PingPong
Hard deadlines no excuses

Every assignment:
group submission + individual contribution
Group grade
Individual grade

Take a close look at the Course PM!

Individual Contribution
You should try to identify tasks and assign a responsible and a
controller to each task
The responsible makes sure that the task is realized, asking also help to
other members of the group
The controller makes sure that the task meets the expected quality level

You will
reflect on this responsibility
explain the steps you have taken

You will have to judge each others contribution!

Technical Support
Useful videos:
https://www.youtube.com/channel/UCefaOkE8GpvBQjPGUndL7zQ

Contact persons:
Papyrus: Grischa Liebel - grischa@chalmers.se
Robotic part + simulator for robots: Claudio Menghi -
menghi@chalmers.se
Yakindu: Michal Palka - michal.palka@chalmers.se
DIT945/TDA593 Model-Driven Software
Development
Basic concepts*
Patrizio Pelliccione
Associate Professor (Docent), Chalmers|GU
www.patriziopelliccione.com

* Inspired by slides of Alfonso Pierantonio, and Bran Selic

Learning objectives

After this lecture, you should be able to

Basic concepts about modeling
Argument about the importance of modeling in the robotic
domain
What is a Model?
 Models

A simplification of a system built with an

intended goal in mind. The model should
be able to answer questions in place of the
actual system [Bzivin et al. 2001]

A model has an intent, a purpose related to a

specific consumer
It is always an abstraction of the reality
It describes a subject that exists or that is
intended to exist in the future

et al. 2001] Jean Bzivin, Olivier Gerb. Towards a Precise Definition

[Bzivin30/10/17 Chalmers of the OMG/MDA Framework. In ASE'01, Automated Software
24
Engineering. 2001.
Models of human body: intent & consumer

Crash tests Medicin

Dressmakers
Model is always an abstraction of the reality

When a model is
correct or valid?
 Models
Model created with the intent
The thing that that satisfies a particular
the model is purpose
about

Subject Model Intent

Consumer

Uses the model to satisfy/

achieve her/his goals
Descriptive vs Prescriptive Models

is described by Descriptive
Subject
Model

prescribes Prescriptive
Subject
Model
 Flowcharting DSL in the 60's
Model-driven software
development
Metamodel
Models as central artifacts for
software development
A metamodel is an explicit
specification of a shared
conceptualization
Abstract syntax of models and the
interrelationships between concepts
Model
within a domain
 Model-driven software
development

Model transformation allows the

automatic generation of one
model (target model) from
another model (source model)
 Model-driven software development: DSLs
Domain Specific Languages
(DSLs) are languages
specifically tailored to a
particular application
domain
Definition of a DLS requires
expertise of
Language engineering
Domain of interest
Concepts typically encoded
in a metamodel
Metamodel of MML DSL of FlyAQ
 Robotic domain?

http://pal-robotics.com/
 Robots increasingly used in the near future

Facilitating tasks of everyday life

Social or an industrial facility of the
future (e.g., a hotel, an office, a
hospital, or a warehouse)
Teams of robots provide services
and accomplish everyday tasks
such as object handling/
transportation, or pickup and
delivery operations
https://www.amazonrobotics.com
Robots increasingly used in the near future

Automating potentially dangerous tasks

Substituting/assisting humans with robots is

safe, fast, and cost efficient
Often the operator will not have the line-of-sight
to the robot
Impractical and/or impossible to manually
control robots
Other forms of navigational aids are required

Peter Burman, Project Manager Mine Automation, Boliden Mines:

http://www.svemin.se/wp-content/uploads/2016/08/burman.pdf
Need of Turn-key solutions

A robot pre-equipped and/or configured with the

right sensors for the specific mission
Specification of the mission in an easy and user-
friendly way
Robots should be smart, i.e. able to take decisions
on their own so to manage unpredictable situations
Completely autonomous robots
When the operator is unable to issue commands (due
to insufficient radio conditions etc.)
Robots should be able to collaborate with humans
State of the art / state of practice

Usually there are no system development processes (highlighted

by a lack of overall architectural models and methods). This
results in the need for craftsmanship in building robotic systems
instead of following established engineering processes.

H2020 Robotics Multi-Annual Roadmap ICT-2016.

http://sparc-robotics.eu/wp-content/uploads/2014/05/H2020-Robotics-Multi-Annual-Roadmap-ICT-2016.pdf
Main barriers: integration and interoperability
Integration
Formalisms and algorithms over different modules
(perception, planning, learning, envisioning etc.) are
typically incompatible
The top performing state-of-the-art modules are often
the hardest to integrate, because they use
sophisticated and incompatible representations and
algorithms that must first be adapted to the needs of
robot control

Interoperability of robotic components

Lack of interoperability standards
Lack of well-defined interfaces with clear semantics

H2020 Robotics Multi-Annual Roadmap ICT-2016.

http://sparc-robotics.eu/wp-content/uploads/2014/05/H2020-Robotics-Multi-Annual-Roadmap-ICT-2016.pdf
Need of system engineering approaches
Systematic processes, methods, models, and tools are
needed to create robotic systems for real-world applications
make or break factor in the development of complex robot
systems

Specification of the overall system architecture

Re-usable robot building blocks for system integration in the
form of well defined modules with clear semantics and clearly
explained and well-defined properties

Such a system of modular integration will stimulate component

supply chains and significantly alter the robotics market
place
Turn-key solutions: challenges

Easy to use robots - Enable stakeholder without expertise

in ICT or robotic to program or teach robots and to
interact/use them

Easy to (re-)configure robots (re-)configure according

to the specific domain and mission needs, operating
environment and external factors

Dealing with uncertainty ability to adapt to unknown,

unpredictable, and dynamic operating environment and
self-learn
Easy to use robots

Intuitive Human Robot Interfaces for use

and configuration, teach or specify task
using domain specific terminology

Interactions and collaborations with

operators and other robots should be
safe, intuitive and appropriate
Easy to (re-)configure robots
Software configuration may take place at design-time or at run-
time as a result of the end user selection of operating parameters

Run-time Self-Configuration
The system can alter its own configuration within a pre-determined
set of alternative configurations designed into the system

Autonomous Configuration
The system can alter its own configuration in response to external
factors, for example altering its morphology in response to the
failure of a sensor or actuator
Dealing with uncertainty
The robot should be able to respond to changes in potentially
unstructured and dynamic operating environments

Adjustment as a result of perception and the decisional

mechanisms

Adaptation as a result of self-learning from its experience

Cooperative missions - teams of both heterogeneous and

homogeneous robots (and potentially in collaboration with
humans) that collaborate and cooperate to accomplish complex
missions
Key techniques/methods

Model-driven software development (MDSD) and DSL (domain

specific languages) are core technologies required in order to
achieve a separation of roles in the robotics domain while also
improving compose-ability, system integration and also
addressing non-functional properties.

H2020 Robotics Multi-Annual Roadmap ICT-2016.

http://sparc-robotics.eu/wp-content/uploads/2014/05/H2020-Robotics-Multi-Annual-Roadmap-ICT-2016.pdf
The promise of MDE

Improve the time and effort required to program

and design a robotic system to tackle a new task
in a new domain
efficient reuse of components
most engineering tasks like robot program
generation will be performed automatically

The robot designer can concentrate on the

creative tasks
Use of models in the robotic domain

H2020 Robotics Multi-Annual Roadmap ICT-2016.

http://sparc-robotics.eu/wp-content/uploads/2014/05/H2020-Robotics-Multi-Annual-Roadmap-ICT-2016.pdf
Step 1: models are used by persons

Advantages
Hide complexity
Engineers can focus on
Code more creative activities
generation Reusability
Modularity
Automating repetitive tasks
Improve quality
Step 2: Robots use models at run-time

Update
Incoming message
Controller( Check !m3
?m1 Advantages
a5 ?m2
Exploit models to
Sending message,
action Yes No a4
a3 understand the reality
(to be checked)
a2
a1 Monitor that the execution
Error of the mission is correct
recovery
Local Failure Understand the
Normal exceptions exception
behaviour
Abnormal
behaviour
environment
Understand how to self-
Sending message
(checked)
adapt
 Step 3: Robots adapt models and improve them
Incoming message Update
?m1
Controller( Check !m3

Sending message, a5 ?m2

action Yes No a4
a3
(to be checked)
a1
a2
Error
recovery
Local Failure
Normal exceptions Abnormal exception
behaviour behaviour

Sending message
(checked)
Todo!

GU students: register to PingPong

All: fill the Google form for enabling the groups definition
(Deadline this evening!!)
Read and study:
The paper called Models2016.pdf that you can find on
PingPong
Chapter 1 (Introduction) and Chapter 2 (MDSE Principles) of
the book Model Driven Software Engineering in practice