1 / 22

Modellbasierte Software-Entwicklung eingebetteter Systeme

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:

mahdis
Télécharger la présentation

Modellbasierte Software-Entwicklung eingebetteter Systeme

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 http://upload.wikimedia.org/wikipedia/commons/7/71/SysML_Diagram_Taxonomy.svg

  4. Die vier Säulen der SysML http://www.uml-sysml.org/documentation/sysml-tutorial-incose-2.2mo

  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: 978-1-84821-500-9 Wiley-ISTE, 320 pages(April 2013)

  6. 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

  7. Pacemaker ibd

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

  9. 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

  10. 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

  11. 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?

  12. 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

  13. Integration von Modellsichten

  14. 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

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

  16. A Modeling Framework Viewpoints abstract Abstraction Layers concrete

  17. Requirements Viewpoint modeling goals environment model • documentationoftheoperational systemenvironment (nonfunctionalreq.) • documentationofthesystemgoalsandassociatedscenarios (functionalreq.) • documentationofthenecessarydomain-specificproperties (domainreq.) goal-orientedrequirements context goals scenarios System Level Ln Models R1 RN system scenarios system goals solution-oriented systemrequirements System Level Ln • systematic requirements elicitation • continuous documentation / specification • validation of requirements supported activities

  18. Functional Viewpoint modeling goals • integrationoffunctionalrequirementsinto a comprehensivesystemspecification • precisemodelingoftheblack box behaviourof a system • modelingofdependenciesbetweenfunctionalrequirements Models Black Box View (from VP RE) System Functions functionalhierarchy Projektion • validationofrequirements • generationoftestcasesandverificationconditions • functionalprototypes supported activities

  19. Logical Viewpoint modeling goals • logicaldescriptionofthesolutionvia decompositionintosubsystems • platformindependenceofthedescribedsolution • reusabilityoflogicalsubsystems models subsystem interface subsystemarchitecture subsystem behaviour • verificationofsystembehaviour • simulation supported activities

  20. Technical Viewpoint Modeling goals • Description ofthetarget-hardware(ECUs, busses, memory, …) • Definition of (software-)tasksandscheduling • Description ofdeployment-specificcommunication • Platformspecificdescriptionofthespecification target-hardware Task and Scheduling communi-cation Logical Subsystem Mapping supported activities • Verification (timinganalysis, schedulability, …) • (Platformspecific) distributionoflogicalsubsystems • Deployment

More Related