Introduction to MDD - Heinz Nixdorf Institut · 2014-10-12 · © Fachgebiet Softwaretechnik, Heinz...

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn

Modellbasierte Softwareentwicklung

Wilhelm Schäfer FG Softwaretechnik Raum ZM1.02-09 [email protected] Sprechstunde: Dienstags 14:00 – 15:00 Uhr Übungen: Christian Brenner [email protected] Tristan Wittgen

mailto:[email protected]


© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn

2 Modellbasierte Softwareentwicklung

Organisatorisches

Vorlesungsbeginn 11:15 Uhr

Klausurtermin: Voraussichtlich 9. Februar 2015 Hinweis: Es gibt nur einen Klausurtermin!

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Übungsgruppen

Erster Übungstermin: Mo 27.10.2014 (3. Vorlesungswoche) Gruppe 1: Mo., 13:00-13:45 Uhr, D 1 303, Christian Brenner Gruppe 2: Mi., 13:00-13:45 Uhr, D 1 303, Tristan Wittgen Gruppe 3: Do, 13:00-13:45 Uhr, D 1 303, Tristan Wittgen

Bonussystem Vorrechnen / Abgeben von Übungsaufgaben

• 1 Notenschritt (0,3 bzw. 0,4) durch zweimaliges Vorrechnen je einer Aufgabe in der Übung

• 1 Notenschritt (0,3 bzw. 0,4) für Erreichen von ≥ 80% aller möglichen Punkte der markierten Übungsaufgaben

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Übungszettel

Übungszettel werden nach der Vorlesung online gestellt Erster Übungszettel erscheint am 20.10.2014 (2. Vorlesungswoche) Abgabe: Mo, 8:00, s.t. eine Woche nach Ausgabe

• Erste Abgabe: Mo, 27.10.2014, 8:00 s.t. Elektronisch an [email protected] oder in

Papierform in den D3 Kasten Gruppen von 2-4 Personen Jeweils alle Matrikelnummern, IMT-Logins und

Übungsgruppe angeben Regeln auf Webseite beachten!




© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Motivation: What is Software Engineering?

“Processes, Methods, Techniques and Tools for the Software Lifecycle

The increasing use of software-intensive systems

in our everyday life, for example, in the automotive industry or the health care sector

shows that software engineering gains societal significance.

The Software Engineering Group addresses the

quality of software-intensive systems with model-based engineering including techniques based on

domain-specific languages.”

Prof. Dr. Wilhelm Schäfer

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Models

A model fulfills the following criteria [Sta73]:

[Sta73] Herbert Stachowiak. Allgemeine Modelltheorie. Springer, 1973. ISBN: 978-3-211-81106-1.

mapping

Original

Model waived

attributes abundant attributes

Mapping: corresponds to an original

Reduction: omits certain attributes of the original Pragmatic: replaces the original under certain circumstances

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Model Theory

O

O‘

M

M‘

Modeling

Model Operations

Interpretation

Original

Original (changed)

Model (changed)

Model

Martin Glinz. Einführung in die Modelltheorie. Universität Zürich, Institut für Informatik.

Operations • not feasible, or • too expensive

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Model-Based Software Development

O

O‘

M

M‘

Modeling

Programming • too error-prone • not maintainable • too expensive

Validation, Analysis,

Simulation, Verification, Refinement

Code Synthesis

Software (non-existent)

Software (existent)

Model

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Model-Based vs. Model-Driven

• Models used as “secondary” artefact • Documentation purpose • Communication purpose • Manual analyses and reasoning

Model-Based

• Model used as “primary” artefact • Inherent part of the developed system • Can not be omitted • Explicitly specified, developed, versioned, etc.

Model-Driven

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Overview

Accidents Therac-25 A320-211 – Accident in Warsaw Aeroplane crash at Lake Constance

The RailCab Project

Lessons learned

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Accident Examples

Between June 1985 and January 1987 the Therac-25

radiation machine killed (at least) four patients due to a software error

On 14 September 1993 in the Airbus A320-211 aircraft accident in Warsaw one crew member and one of the passengers lost their lives

In an aeroplane crash on 1st July 2002 near Überlingen / Lake Constance (Bodensee) 71 people are killed

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


The Therac-25 Accidents

Therac-25 is a machine for radiation therapy (to treat cancer) produced by AECL

Between June 1985 and January 1987 (at least) six patients received severe overdoses: three died shortly afterwards one might have died but died because of cancer the remaining two suffered of permanent disabilities

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


The Therac-25 (1/3)

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


The Therac-25 (2/3)

Functional principle Therac-25 is a “dual-mode” machine:

electron mode for surface tumours X-ray mode for deep tumours

rotating turntable moves equipment in beam path

Electron mode “scanning magnets” are used to spread the beam variable beam energy X-ray mode a tungsten target and a “beam flattener” are used the target generates the X-rays but absorbs most of the beam

energy the required energy has to be increased by a factor of 100,

compared to electron mode

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


The Therac-25 (3/3)

Upper turntable assembly

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Major event time line (1985) 1985 Jun 3rd: Marietta, Georgia, overdose. Later in the month, Tim Still calls AECL and asks if

overdose by Therac-25 is possible. Jul 26th: Hamilton, Ontario, Canada, overdose; AECL

notified and determines microswitch failure was the cause.

Sep AECL makes changes to microswitch and notifies users of increased safety. Independent consultant (for Hamilton Clinic) recommends potentiometer on turntable.

Oct Georgia patient files suit against AECL and hospital. Nov 8th: Letter from Canadian Radiation Protection Bureau

to AECL asking for additional hardware interlocks and software changes.

Dec Yakima, Washington, clinic overdose.

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Major event time line (1986)

1986 Jan 31st: Letter to AECL from Yakima reporting overdose

possibility. Feb 24th: Letter from AECL to Yakima saying overdose was

impossible and no other incidents had occurred. Mar 21st: Tyler, Texas, overdose. AECL notified; claims

overdose impossible and no other accidents had occurred previously. AECL suggests hospital might have an electrical problem.

Apr 7th: Tyler machine put back in service after no electrical problem could be found.

11th: Second Tyler overdose. AECL again notified. Software problem found.

15th: AECL files accident report with FDA.

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Major event time line (cont. 1986) 1986 May 2nd: FDA (US Food and Drug Administration) declares

Therac-25 defective. Asks for CAP (Corrective Action Plan) and proper renotification of Therac-25 users.

Jun 13th: First version of CAP sent to FDA. Jul 23rd: FDA responds and asks for more information. First user group meeting. Aug 26th: AECL sends FDA additional information. Sep 30th: FDA requests more information. Nov 12th: AECL submits revision of CAP. Dec Therac-20 users notified of a software bug. 11th: FDA requests further changes to CAP. 22nd: AECL submits second revision of CAP.

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn



1987 Jan 17th: Second overdose at Yakima. 26th: AECL sends FDA its revised test plan. Feb Hamilton clinic investigates first accident and concludes

there was an overdose. 3rd: AECL announces changes to Therac-25. 10th: FDA sends notice of adverse findings to AECL

declaring Therac-25 defective under US law and asking AECL to notify customers that it should not be used for routine therapy. Health Protection Branch of Canada does the same thing. This lasts until August 1987.

Mar Second user group meeting. 5th: AECL sends third revision of CAP to FDA. Apr 9th: FDA responds to CAP and asks for additional

information.

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn



1987 May 1st: AECL sends fourth revision of CAP to FDA. 26th: FDA approves CAP subject to final testing and

safety analysis. Jun 5th: AECL sends final test plan and draft safety

analysis to FDA. Jul Third user group meeting. 21st: Fifth (and final) revision of CAP sent to FDA. 1988 Jan 29th: Interim safety analysis report issued. Nov 3rd: Final safety analysis report issued.

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Reasons for the error

Developed based on Therac-20: Software replaces hardware safety measures

Bad Software-Design Concurrency not taken into account Variable changes during calibration of scanning magnets not

propagated Machine had an inconsistent state during treatment (Beam

with high energy without tungsten target)

Further reading: Nancy Leveson: Medical Devices: The Therac-25 http://sunnyday.mit.edu/papers/therac.pdf

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Lessons learned from Therac-25 accident:

Accidents are seldom simple

Accidents are often blamed to single source

Management inadequacies, lack of following incident reports

Involvement of management, technicians, users, and government

Unrealistic risk assessment

Overconfidence in software

Less-than-acceptable software-engineering practices

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


A320-211 Accident in Warsaw

A high-tech aeroplane with special safety features happens to be too intelligent for the crew.

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn



The aircraft is cleared for approach on runway 11 of Warsaw airport. The crew is informed about the existence of windshear. They perform the appropriate maneuver according to the manual.

The tower‘s weather data however is outdated. At the time of touchdown there is a strong tailwind…

Windshear

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn



Due to its high speed and tailwind the aircraft touches down 770m past the runway threshold.

Because of the tilted position only one landing gear touches the ground initially. The crew engages the wheel brakes.

Due to aquaplaning the brakes have no effect. Only 1525m past the runway threshold the second gear

finally touches ground.

http://en.wikipedia.org/wiki/Image:Flight_29041129.png

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Delayed breaking

Reverse thrust and Ground Spoiler only activate when: Both landing gears are under a pressure of 12t The wheels turn with a velocity of at least 72 kts.

Condition 1 was not satisfied due to the tilted position Condition 2 was not satisfied due to aquaplaning The braking system was activated much too late.

http://en.wikipedia.org/wiki/Image:Flight_29041129.png

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Probable Cause

[Ladkin1994]: "Cause of the accident were incorrect decisions and

actions of the flight crew taken in situation when the information about windshear at the approach to the runway was received.

Actions of the flight crew were also affected by design features of the aircraft which limited the feasibility of applying available braking systems as well as by insufficient information in the aircraft operations manual (AOM) relating to the increase of the landing distance."

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Lessons learned

Incorrect environment assumptions can result in a correct

working but not safe system behaviour!

Smart and complex systems together with not sufficient documentation (manuals) can result in serious crew errors (human factor)

⇒Correctness is not safety

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Aeroplane Crash Bodensee, July 2002

Even redundant and correct working safety equipment is not enough when safety policies and culture are not appropriate.

Reconstruction

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Aeroplane Crash Bodensee

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Chain of Events

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Collision and Wreckage Distribution

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Lessons learned

Traffic alert and Collision Avoidance System (TCAS) works

in both machines

Short Term Conflict Alert (STCA) was not available at ACC Zurich due to maintenance

The STCA of the Upper Area Control Center warns two minutes prior to collision, but no connection via the direct line could be established

⇒Even reliable working equipment does not guarantee safety when the safety policy at the organizational level is not sufficient (see Swiss air traffic control: ACC Zurich)

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Example: The RailCab Project

A system of autonomous vehicles that builds convoys to

optimize their energy consumption (RailCab Paderborn)

System of systems Hard real-time Safety-critical Self-Optimization ⇒ SFB 614

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Video

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


RailCab Coordination

Challenge: Safe Behavior

Background: Ensure safe operation is of paramount importance Operation must be safe also in the presence of hardware

faults

State of the Art: Testing Executing the system to detect safety violations

Model checking Complete formal verification of given safety properties

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Resulting & Future Challenges

Software is the Bottleneck

In the (recent) past, an embedded system would be either small or simple, or the composition of almost non-interacting imported and assembled components. The trend is that the number and complexity of functions will increase drastically. Increasing complexity is making the present design methodologies rapidly obsolete. Productivity of the order of six (or less!) lines of embedded code per day per person is common in HRT embedded systems. The cost of developing a new plane (of the order of several billions of Euros) is about ½ related to embedded software and electronics subsystems.

[B. Bouyssounouse, J. Sifakis (Eds.), Embedded Systems Design: The ARTIST Roadmap for Research and Development, Lecture Notes in Computer Science, vol. 3436, Springer, 2005, p.4]

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Complexity of Design Flows and Supply Chains The electronics industry is increasingly disaggregating: new opportunities are now opening up for subsystem and component suppliers. These dynamics are stressing the interfaces among the supply chain players. Several quality problems and time-to-market delays can be traced to specification and system integration difficulties. Among the most challenging supply chains to support are the automotive and avionics chain.

[B. Bouyssounouse, J. Sifakis (Eds.), Embedded Systems Design: The ARTIST Roadmap for Research and Development, Lecture Notes in Computer Science, vol. 3436, Springer, 2005, p.8]

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


A New Software Design Paradigm The highest ranked recommendation was to develop a new software design paradigm that recognizes that uncertainty and emergent, unanticipated behaviors are likely to be forever present in the software-intensive systems of the future due to their ultra-large, networked, distributed, and diffuse-control natures.

[NSF 2003, Executive Summary]

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Model-Based Development

A promising approach for solving these problems is model-based development: models can serve as a vehicle for communicating information between business process engineers, control engineers and computer scientists, and can also provide an additional basis for preimplementation validation of requirements and quality properties as well as for automatic generation of source code. […].

[Report on the EU/NSF Strategic Workshop on Engineering Software-Intensive Systems, Edinburgh, GB, 2004]

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Key Lesson learned

It is not enough to (just) test (and simulate) a program

Models for analysing the software and its environment are needed

Models should be understandable by different stakeholders

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Requirements for Software Development Correctness, Robustness, Reliability (summarized as Dependability (Zuverlässigkeit))

Efficient Production

Understandability, Reuse

Well defined Processes & Interfaces

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


V- Model - Focus of lecture

System (Model) construction

• Requirements • Design

Quality management • Reviews, test, …

Config. management • Manage artifacts

Project-Management • Plan, control and

monitor project

[Broehl1993]

system model, construction

system, quality management

integration test

accept- ance test

Implemen- tation

Analysis

detailed design

system test

use cases

test cases

test cases

modul test

test cases

coarse design

© F

achg

ebie

t Sof

twar

etec

hnik

, Hei

nz N

ixdo

rf In

stitu

t, U

nive

rsitä

t Pad

erbo

rn


Role of Design – Its Phases

Coarse Design (Software Architecture or PIM)

Decompose system into subsystems

Identify components Relations and cooperation

between components (connectors)

Result: architectural description Detailed Design (Component Design)

Determine interfaces/contracts Result: component specification

Implemen- tation

Analysis

detailed design

coarse design

design specification

architecture

requirement specification

test cases

test cases

Date post:	02-Aug-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Introduction to MDD - Heinz Nixdorf Institut · 2014-10-12 · © Fachgebiet Softwaretechnik, Heinz...

Documents