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: 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 14:44 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 Sequenzdiagramme 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

Recap: Development Process Models Waterfall Model Evolutionary/Incremental Model Extreme Programming V-Model Rational Unified Process (RUP) Implementation System test Integration test Unit test Analysis Architecture Techn. Design Acceptance test Test cases Implementation Design Test, Integration Maintenance Product definition specification Code validated Changes Analysis Analysis Design Validation Requirements Prototypes Implementation Activity Time Analysis Design Implementation Test Configuration management Project Inception Elaboration Construction Transition There are many different development process models …

A Modeling Framework Viewpoints abstract Abstraction Layers concrete 14:17 concrete

Requirements Viewpoint modeling goals 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.) Models context scenarios goal-oriented requirements goals System Level Ln system solution-oriented system requirements R1 RN environment model 14:19 systematic requirements elicitation continuous documentation / specification validation of requirements supported activities

Functional Viewpoint modeling goals 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 Models Black Box View (from VP RE) System Functions functional hierarchy Projektion 14:21 validation of requirements generation of test cases and verification conditions functional prototypes supported activities

subsystem architecture Logical Viewpoint modeling goals logical description of the solution via decomposition into subsystems platform independence of the described solution reusability of logical subsystems models subsystem interface subsystem behaviour subsystem architecture 14:23 verification of system behaviour simulation supported activities

Technical Viewpoint supported activities 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 Logical Subsystem target-hardware Task and Scheduling communi-cation 14:25 Mapping supported activities Verification (timing analysis, schedulability, …) (Platform specific) distribution of logical subsystems Deployment