Modellbasierte Software-Entwicklung eingebetteter Systeme

Modellbasierte Software-Entwicklung eingebetteter Systeme

Prof. Dr. Holger SchlingloffInstitut für Informatik der Humboldt Universität

undFraunhofer Institut für offene Kommunikationssysteme FOKUS

http://www.hu-berlin.de/index.html

Folie 2H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme

Wer wird Modelionär?

• Was sind keine Anforderungsartefakte: Ziele – Szenarien – Strategien – Algorithmen?

• Was sind keine Qualitätskriterien für Zielformulierungen: Prägnant und aktiv – Überprüfbar und verfeinerbar – Wertschöpfend und begründbar – Deklarativ und objektorientiert

• Welche Mittel sind nicht zur Strukturierung von Zielen geeignet:Schablonen – Und/Oder-Bäume – SysML-Diagramme – Poesiealben

• Wie viele SysML-Diagrammarten gibt es: 3 – 9 – 11 – 14

• Was sind keine SysML-Diagramme:Requirements- und Zusicherungsdiagramme – Blockdefinitions- und interne Blockdiagramme – Klassen- und Objektdiagramme – Zustands- und Aktivitätsdiagramme

• Wodurch werden Szenarien nicht beschrieben:Sequenzdiagramme – Aktivitätsdiagramme – Schablonen – Romane


SysML Diagrammarten

http://upload.wikimedia.org/wikipedia/commons/7/71/SysML_Diagram_Taxonomy.svg


Die vier Säulen der SysML

http://www.uml-sysml.org/documentation/sysml-tutorial-incose-2.2mo


Blockdefinitionsdiagramme (bdd)• ersetzt UML Klassen- und Objektdiagramme• Blöcke und Abhängigkeiten

Blöcke können Eigenschaften haben: Teile, Werte, Verweise Abhängigkeiten sind Assoziationen (Aggregation und Komposition)

und Generalisierungen/Spezialisierungen

(C) für alle Bilder: Fabrice Kordon, Jerome Hugues, Agusti Canals, Alain Dohet: Embedded Systems - Analysis and Modeling with SysML, UML and AADL. ISBN: 978-1-84821-500-9 Wiley-ISTE, 320 pages(April 2013)


Interne Blockdiagramme (ibd)• beschreiben die innere Struktur von Blöcken

Teile (Parts) eines Blocks werden wieder als Blöcke notiert Ports sind Interaktionspunkte (Ein/Ausgänge) von Blöcken

- Standard Ports (leere Quadrätchen): Operationen und Signale, Typ Interface,- Flow Ports (Quadrätchen mit Pfeilchen): Material- oder Informations-Flüsse,

ggf. mit Typ (Liter, Gramm, Integer, ...)- aggregierte Flow-Ports (Symbol <>): Fluss-Spezifikation in bdd gegeben

Konnektoren symbolisieren Verbindungen zwischen Blöcken• Interfaces eines Blocks werden mit Lollipop-Notation gezeichnet


Pacemaker ibd


Zusicherungsdiagramme (par)• Parametric Diagrams • Spezielle ibds zur Notation von Constraints

Parameter Regeln (<<constraint>>)

• Integration von Ingenieur-Mathematik in Design-Modelle


Weitere SysML-Diagramme• Anwendungsfall-Diagramme: Wer macht was?

“Use cases” Stakeholder und Funktionen des Systems Abhängigkeiten zwischen Funktionen, z.B. include, extend

• Paketdiagramme: Struktur des Systems verschachtelte Namensräume


Verhaltensdiagramme• Aktivitätsdiagramme

UML-Variante von Petrinetzen Kontrollfluss (paralleler) Aktivitäten

• Sequenzdiagramme sequentielles Verhalten und Interaktionen der Akteure Schwimmbahnen

• Zustandsdiagramme endliche Automaten Parallelität und Hierarchie


Strategien(Lösungsorientierte Anforderungen)• Def.: (Wikipedia) Eine Strategie ist ein längerfristig

ausgerichtetes planvolles Anstreben einer vorteilhaften Lage oder eines Ziels. Formal mathematisch ist eine Strategie eine Folge von Funktionen von einer Zustandsmenge (zum Beispiel die Menge der denkbaren Spielsituationen eines Spielers) in eine Menge von Aktionen (die entsprechend dem Spieler vorschreibt, was er tun soll).

• Strategien operationalisieren Ziele und Szenarien Ziel: Warum soll etwas passieren? Szenario: Was soll passieren? Strategie: Wie soll es passieren?


Drei Perspektiven von Strategien

• Struktur Art und Zusammensetzung von Teilen, Daten,

Attributen, Relationen typisch: Blockdiagramme, Objekt- und

Klassendiagramme• Funktion

Transformation durch das System typisch: Material- und Datenflussdiagramme

• Verhalten Zustände und Zustandsänderungen des Systems;

Reaktionen auf Stimuli typisch: Zustandsübergangsdiagramme


Integration von Modellsichten


From Requirements to Models

• Requirements are informal, models are semi-formal, code is formal

• I.e., software development can be seen as continuous formalization

• Usually: many design choices• Not one best practice established• State of the art:

Object-Oriented Modeling

http://spes2020.informatik.tu-muenchen.de/SPES_band.html


• V-Model

• Rational Unified Process (RUP)

Recap: Development Process Models

• Waterfall Model

•

• Evolutionary/Incremental Model

• Extreme Programming

Implementation

Design

Test,Integration

Maintenance

Productdefinition

Designspecification

Code

validatedCode

Changes

Analysis

Implementation

System test

Integration test

Unit test

Analysis

Architecture

Techn. Design

Acceptance test

Test cases

Test cases

Test cases

Analysis

Design Validation

Requirements

Prototypes

Implementation

Activity

Time

Analysis

Design

Implementation

Test

Configurationmanagement

Projectmanagement

Inception Elaboration Construction Transition


A Modeling FrameworkViewpoints

Requirements Functional Logical Technical

...

...

...

...

...

...

abstract

concrete


Requirements Viewpoint• documentation of the operational system environment

(nonfunctional req.)• documentation of the system goals and associated scenarios

(functional req.)• documentation of the necessary domain-specific properties (domain

req.)

modeling goals

context scenarios goal-oriented requirements

goals

System Level Ln

systemscenarios

systemgoals

solution-orientedsystem

requirements

R1

RN

environment model

System Level Ln

«flowPort»Crane1ActionSignal

«fl owPort»Crane2ActionSignal

«fl owPort»DeliveryBandSignal

«flowPort»SensorSignal

«flowPort»Suppl yBandSignal

«fl owPort»SystemOutput

«fl owPort»UserInput

Zyl inderkopffertigungsanlage


«fl owPort»Crane2ActionSignal

«fl owPort»DeliveryBandSignal

«flowPort»SensorSignal


«fl owPort»SystemOutput


User

Env ironment

Crane1 (extern)Crane2 (extern)

SupplyBand (extern)Deliv eryBand (extern)

SensorSignal

«flow»Deli veryBandSignal

«flow»Suppl yBandSignal

«flow»

Crane2ActionSignal

«fl ow»

Crane1ActionSignal

«flow»

SystemOutput

«fl ow»

UserInput

«flow»

<< hardgoal >>T ransport von Werkstücken

gewährleisten ()

<< softgoal >>Kol l ilsionenvermeiden ()

<< hardgoal >>Werkstück

transportieren ()

<< hardgoal >>Produktionsstofftransport

gewährleisten ()

<< hardgoal >>Werkstückeerkennen ()

<< hardgoal >>Verm essen von

Produktionsstoffen ()

<< hardgoal >>Zei tg leiche

bearbei tung ()

<< hardgoal >>Rohstoff

transportieren ()

+

«Contribution»

++

«Contribution»

--

«Contribution»

SupplyBand IOAdapter

(from 2.1.2. Zie le / Szenarien "IOAdapter")

UserInteraction

(from 2.3.2. Zie le / Szenarien "UserInteraction")

eingeschaltet

Ansteuerung berechnen

loop SupplyBand ansteuern

[OperationOn]

[!OperationOn]

ausgeschaltet

OperationOn()

Sensor()

SupplyBand()

!OperationOn()


(from 2.1.2. Ziele / Szenarien "IOAdapter ")

UserI nteracti on

(from 2.3.2. Ziel e / Szenari en "UserInteraction")

eingeschaltet



[OperationOn]

[!Operati onOn]

ausgeschaltet

Operati onOn()

Sensor()

SupplyBand()

!OperationOn()

Sensor

AutoMod e

Ope rationOn

Crane1Action

Crane2Action

SupplyBa nd

Delive ryBand

Funktionen des Transporta tionController

Sensor

AutoMod e

Ope rationOn

Crane1Action

Crane2Action

SupplyBa nd

Delive ryBand

Se nso r

Au toMode

Bewegung sau ftragCrane1

Be wegungsauftragCra ne2Op eration On

Se nsordaten v erarbei ten

Se nso r

Au toMode

Bewegung sau ftragCrane1

Be wegungsauftragCra ne2Op eration On

SupplyBa nd

Delive ryBandOpe rationOn

Förderbandbe wegungen berechnen

SupplyBa nd

Delive ryBandOpe rationOn

Crane1ActionBewegungsauftragCrane1

Wegpunkte für Crane1 berechne n

Crane1ActionBewegungsauftragCrane1

Cra ne2Acti onBewegungsauftragCrane2

Wegpunkte für Crane2 berechne n

Cra ne2Acti onBewegungsauftragCrane2


(from 2.1.2. Ziele / Szenarien "IOAdapter")

UserInteraction

(from 2.3.2. Ziele / Szenarien "UserInteract ion")

eingeschaltet



[Operati onOn]

[!OperationOn]

ausgeschaltet

Operati onOn()

Sensor()

SupplyBand()

!Operat ionOn()

«block»UserInput

«block»OperationOn

«block»AutoMode

«block»Sensor

«block»Crane1Sensor

«block»Crane2S ensor

«block»SupplyBandSensor

«block»DeliveryBandSensor

«block»SensorSignal

«block»Crane1S ensorSignal

«block»Crane2SensorSignal

«block»SupplyBandSensorSignal

«block»DeliveryBandSensorSignal

«block»SystemOuput

«block»Action

«block»Crane1Action

«block»Crane2Action

«block»SupplyBandAction

«block»DeliveryBandAction

«block»ActionSignal

«block»Crane1ActionSignal

«block»Crane2ActionSignal

«block»SupplyBandActionSignal

«block»DeliveryBandActionS ignal

+Raw Data translated by IOA dapter +Translated Signal

+determins

Determ ination

+determined

+Bus-conformant Data translated by IOAdapter +Raw Signal

+represented Inform ation

Representation

+Displayed data

Ini tia l

Anlage eingeschaltet

Anlage ausgeschaltet

Final

AutoMode ManualM ode

In i tial

[UserInput = AutoMode]

[UserInput = !AutoMode]

[UserInput: e inschal ten][UserInput:terminieren]

[UserInput:einschalten]

•systematic requirements elicitation•continuous documentation / specification•validation of requirements

supported activities

Models


Functional Viewpoint

System Functions

• integration of functional requirements into a comprehensive system specification

• precise modeling of the black box behaviour of a system• modeling of dependencies between functional requirements

modeling goals

• validation of requirements• generation of test cases and verification

conditions • functional prototypes

Black Box View(from VP RE)

«flowPort»Crane1Action Signal


«flowPort»DeliveryBandSignal

«flowPort»Se nsorSig nal


«flowPort»SystemOutput


Zylinderkopffertigungsanla ge

«flowPort»Crane1Action Signal


«flowPort»DeliveryBandSignal

«flowPort»Se nsorSig nal


«flowPort»SystemOutput


User

Environment

Crane1 (extern)Crane2 (extern)

SupplyBand (extern)Delive ryBand (extern)

Se nsorSig nal

«fl ow»DeliveryBandSignal

«flow»Sup plyBandSignal

«flow»

Crane2ActionSignal

«flow»

Cran e1ActionSignal

«flow»

SystemOutp ut

«flow»

UserIn put

«fl ow»

Projektion

functional hierarchyModels



Logical Viewpoint

subsystem architecture

• logical description of the solution via decomposition into subsystems

• platform independence of the described solution• reusability of logical subsystems

modeling goals

• verification of system behaviour• simulation

subsystembehaviour

subsysteminterface

models



Technical Viewpoint

ProcessingResource

:ConcurrencyResource


:SchedulerSlot :SchedulerSlot

:Scheduler


:Scheduler

:SchedulerSlot

:SchedulerSlot

target-hardware

Technical Perspective

CaptureTask

airTempCtrlTask

Scheduler

temp control

Var1tempVal

Var2tempSel

ECU

tempData

Logical Perspective

AirTempControlcontrol

Capturetemp

TempData

<<allocate>>

Modeling goals• Description of the target-hardware (ECUs, busses, memory,

…)• Definition of (software-)tasks and scheduling • Description of deployment-specific communication• Platform specific description of the specification

LogicalSubsystem

ComputingResource

app-task1:Taskcom:Task

app-task2:Task

bus-drv:Task

Signal1

Signal2

Message1 Frame1

payload Frame1header

Message1payloadheader

Signal1 Signal2

• Verification (timing analysis, schedulability, …)• (Platform specific) distribution of logical subsystems• Deployment

Mapping

Task and Scheduling

communi-cation


Modellbasierte Software-Entwicklung eingebetteter Systeme

Documents

Transcript of Modellbasierte Software-Entwicklung eingebetteter Systeme