Modellbasierte Software-Entwicklung eingebetteter Systeme

Präsentation zum Thema: "Modellbasierte Software-Entwicklung eingebetteter Systeme"—  Präsentation transkript:

1 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

2 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

3 SysML Diagrammarten 14:44

4 Die vier Säulen der SysML

5 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: Wiley-ISTE, 320 pages(April 2013)

6

7 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

8 Pacemaker ibd

9 Zusicherungsdiagramme (par)
Parametric Diagrams Spezielle ibds zur Notation von Constraints Parameter Regeln (<<constraint>>) Integration von Ingenieur- Mathematik in Design-Modelle

10

11 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

12 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

13 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?

14 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

15 Integration von Modellsichten

16 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

17 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 …

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

19 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

20 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

21 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

22 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