View
60
Download
5
Category
Preview:
DESCRIPTION
Modellbasierte Software-Entwicklung eingebetteter Systeme. Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für offene Kommunikationssysteme FOKUS. Wer wird Modelionär?. Was sind keine Anforderungsartefakte: - PowerPoint PPT Presentation
Citation preview
Modellbasierte Software-Entwicklung eingebetteter Systeme
Prof. Dr. Holger SchlingloffInstitut für Informatik der Humboldt Universität
undFraunhofer Institut für offene Kommunikationssysteme FOKUS
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
Folie 3H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
SysML Diagrammarten
http://upload.wikimedia.org/wikipedia/commons/7/71/SysML_Diagram_Taxonomy.svg
Folie 4H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
Die vier Säulen der SysML
http://www.uml-sysml.org/documentation/sysml-tutorial-incose-2.2mo
Folie 5H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
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)
Folie 6H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
Folie 7H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
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
Folie 8H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
Pacemaker ibd
Folie 9H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
Zusicherungsdiagramme (par)• Parametric Diagrams • Spezielle ibds zur Notation von Constraints
Parameter Regeln (<<constraint>>)
• Integration von Ingenieur-Mathematik in Design-Modelle
Folie 10H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
Folie 11H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
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
Folie 12H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
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
Folie 13H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
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?
Folie 14H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
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
Folie 15H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
Integration von Modellsichten
Folie 16H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
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
Folie 17H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
• 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
Folie 18H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
A Modeling FrameworkViewpoints
Requirements Functional Logical Technical
...
...
...
...
...
...
abstract
concrete
Folie 19H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
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
«flowPort»Crane1ActionSignal
«fl owPort»Crane2ActionSignal
«fl owPort»DeliveryBandSignal
«flowPort»SensorSignal
«flowPort»Suppl yBandSignal
«fl owPort»SystemOutput
«fl owPort»UserInput
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()
SupplyBand IOAdapter
(from 2.1.2. Ziele / Szenarien "IOAdapter ")
UserI nteracti on
(from 2.3.2. Ziel e / Szenari en "UserInteraction")
eingeschaltet
Ansteuerung berechnen
loop SupplyBand ansteuern
[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
SupplyBand IOAdapter
(from 2.1.2. Ziele / Szenarien "IOAdapter")
UserInteraction
(from 2.3.2. Ziele / Szenarien "UserInteract ion")
eingeschaltet
Ansteuerung berechnen
loop SupplyBand ansteuern
[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
Folie 20H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
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»Crane2ActionSignal
«flowPort»DeliveryBandSignal
«flowPort»Se nsorSig nal
«flowPort»Suppl yBandSignal
«flowPort»SystemOutput
«fl owPort»UserInput
Zylinderkopffertigungsanla ge
«flowPort»Crane1Action Signal
«flowPort»Crane2ActionSignal
«flowPort»DeliveryBandSignal
«flowPort»Se nsorSig nal
«flowPort»Suppl yBandSignal
«flowPort»SystemOutput
«fl owPort»UserInput
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
supported activities
Folie 21H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
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
supported activities
Folie 22H. Schlingloff, SS2014 – modellbasierte Software-Entwicklung eingebetteter Systeme
Technical Viewpoint
ProcessingResource
:ConcurrencyResource
:ConcurrencyResource
:SchedulerSlot :SchedulerSlot
:Scheduler
:ConcurrencyResource
: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
supported activities
Recommended