MARTE für UML Programmiersprachen und Modellierungswerkzeuge - Entwurf von Software für
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Entwurf von Software für
eingebettete Systeme
Programmiersprachen und
Modellierungswerkzeuge
MARTE für UML
Wintersemester 2010/11
TU Chemnitz
Fakultät für Informatik
Professur Betriebssysteme
Dr. Dirk Müller
Übersicht
● Einführung
● UML: Metamodellierung und Diagrammarten
● Profil, Stereotyp, Eigenschaftswert
● Vorgänger und Verwandte
● Paketdiagramm
● Zeit
● Beispiele von Uhren
● Operationen auf Uhren
● Zusammenfassung
● Literatur
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 2/27Einführung
● UML-2-Profil für MARTE (Modeling and Analysis of
Real-Time and Embedded systems)
● UML-2-Profil: konkrete Erweiterung des UML-2-
Metamodells basierend auf dem leichtgewichtigen
Erweiterungsmechanismus (belässt UML-Metamodell)
● Stereotype mit Eigenschaftswerten (tagged values)
● Constraints (Einschränkungen, Nebenbedingungen)
● Analogie zu Sprachbeschränkungen auf Quellcode-
ebene (z.B. MISRA-C/C++): Modellbeschränkungen
auf Modellebene (auch: MISRA-AC-TL für TargetLink)
● unterstützt Modellierung, Simulation und Analyse
● für Codegenerierung nur teilweise geeignet [1]
● Version 1.0 im November 2009 erschienen
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 3/27MOF-Metamodellierung
● „meta“ als
relativer Begriff
● M3-Ebene hat
sich selbst als
Metamodell (vgl.
Bootstrapping)
● erst durch solche
formal definierten
Regeln auto-
matische Code-
generierung er-
möglicht
Quelle: http://upload.wikimedia.org/wikipedia/commons/9/93/M0-m3.png
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 4/27UML-2.3-Diagrammarten
neu in Version 2.2
Quelle: [3], S. 704
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 5/27UML-Profil
“A profile defines limited extensions to a reference metamodel with the
purpose of adapting the metamodel to a specific platform or domain.” [3]
● ist ein spezielle Form eines Pakets
● Bezugs-Metamodell ist notwendig (hier: UML-MM)
● neue Diagrammart Profildiagramm zur Beschreibung
der Anwendung von Profilen
● gekennzeichnet durch
● Menge von zugeordneten
Stereotypen
● Menge von zugeordneten
Constraints (Einschränkungen)
– als Kommentar (natürliche Sprache,
optional auch in OCL, Object Constraint Quelle: [3], S. 689
Language, formal angegeben)
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 6/27Beispiel: EJB-Profil
Enterprise Java Beans als Komponenten in Java EE
Quelle: [3], S. 686
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 7/27Stereotyp
● konkrete Syntax: Name in
Guillemets, «name»
● abstrakte Syntax: Er-
weiterung anderer Meta-
klassen
● bei Anwendung eines
Stereotyps auf ein
Modellierungselement
spricht man von Eigen-
schaftswerten (tagged
values), typisiert (neu in
UML 2)
● Eigenschaftswerte werden
im Kommentar angegeben
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 8/27Vorgänger und Verwandte
● „UML Profile for Schedulability, Performance and Time
(SPT)“, aktuelle Version 1.1 ist 2005 erschienen
● für UML 1, daher keine Weiterentwicklung
● „OMG Systems Modeling Language (OMG SysML)“,
aktuelle Version 1.2 ist im Juni 2010 erschienen
● Modellierung von HW, SW, Informationen, Prozessen,
Personen, Einrichtungen mgl. => nicht mehr SW-zentriert
● zusätzliche Diagrammarten
– Anforderungsdiagramm (requirement diagram)
– Parameterdiagramm (parametric diagram) für Analysen
● kompaktere Sprache, unterstützt Viewpoints
● „UML Profile for System on a Chip (SoC)“, aktuelle
Version 1.0.1 ist 2006 erschienen
● „AUTOSAR UML Profile“, aktuelle Version 1.0.1, 2006
● Mapping des AUTOSAR-Metamodells auf UML/SysML
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 9/27Paketdiagramm von MARTE
● NFP: non-functional prop.
● GRM: Generic Resource
Modeling
● Alloc: Allokation von
Funktionalität zu Modulen
(Zeit, Raum, WCET)
● GCM: Generic Component
Model
● HLAM: High-Level Application
Modeling
● SRM: SW Resource Model
● HRM: HW Resource Model
● GQAM: Generic Quantitative
Analysis Modeling
● SAM: Schedulability Ana. M.
● PAM: Performance Ana. Mod.
● VSL: Value Specification Lan-
guage
● RSM: Repetitive Structure
Modeling
Quelle: [2]
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 10/27Arbeitszyklus mit MARTE
Quelle: [2]
● viele Schritte automatisierbar
● manchmal kann sogar auf Experten aus der Analysis-
Domäne verzichtet werden
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 11/27Zeit in MARTE
● chronometrisch
verschiedene
● klassischer Zeitbegriff, gekoppelt an eine Uhr Berechnungs
● logisch modelle
unterstützt
● gebunden an Ereignisse, asynchron
● synchron
● gebunden an Ereignisse, sogar getaktete Ausführung
● vgl. synchrones Berechnungsmodell mit Lustre, Esterel
● benötigt für EZS mit höchsten Anforderungen
● Profil-
diagramm
Quelle: [4], S. 73
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 12/27Zeitmodellierung: Clock
Quelle: [4], S. 74
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 13/27Beispiel: 100-Mhz-Uhr in MARTE
alternative
● nature Darstellungsform
für Eigenschafts
● discrete werte
● dense
● isLogical
● false => chrono- Objekt
metrisch
● true => logisch oder
synchron
● unitType
● Aufzählung möglicher
Zeiteinheiten
Quelle: [1]
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 14/27Beispiel: Chronometrische Uhren
Quelle: [4], S. 85
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 15/27Clocks: NFPs und Operationen
● Nichtfunktionale
Eigenschaften
chronometrischer
Uhren
● Stabilität
(Varianzmaß)
● Offset (Differenz)
● Taktversatz (Skew,
1. Ableitung)
● Drift (2. Ableitung)
● Operationen
● Diskretisierung
● Filterung
● Verzögerung Quelle: [4], S. 475
● Verkettung
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 16/27Codegenerierung mit MARTE
● Codegenerierung als Schwachstelle von MARTE
● Lösungsansätze durch Kombination mit anderen
Sprachen, z.B. SysML und SystemC [1]
Modell in Software:
Promela SPIN Ordnung: ausführbarer
ja/nein Code
Verifikation
MARTE
Hardware:
Generator SystemC FPGAs bzw.
ASICs
synthesefähiges
SysML VHDL Implementierung
(Produkt)
Spezifikation und Beispiel für
zugleich modellgetriebene
Implementierung Softwareentwicklung Verilog
(vom Menschen) in mehreren Stufen
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 17/27SPARK-Profil für UML
● Integration mit Code-
generierung von der
anderen Seite her (im Vgl.
zum MARTE-Profil)
● UML ist ziemlich C++-
orientiert => Probleme bei
der Spezifikation des
Informationsflusses
● Automatisierung möglich
mit Rhapsody in Ada (UML
CASE tool)
Quelle: [7]
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 18/27AADL
● Architecture analysis and design language
● Ursprung in der Luftfahrt, heute stark im Automobilbau
verwendet
● standardisiert durch Society of Automotive Engineers
(SAE), Version 1.0 vom November 2004
● unterstützt Hard- und Software => gut für eingebettete
Systeme (Kombination aus Anwendung und Aus-
führungsplattform)
● unterstützt Scheduling-Analyse => gut für EZ-Systeme
● komplizierte Konstrukte, nicht alles orthogonal
● besser: Abbildung auf UML MARTE, meist möglich
Quelle: [9]
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 19/27EAST-ADL2
● Electronics Architecture and Software Technology -
Architecture Description Language, Version 2 [10]
● Modellierungssprache als DSL für Automobilindustrie
● im Rahmen von EU-Forschungsprojekten 2004 ent-
wickelt, verbindet Software- und Systementwicklung
● Kombination aus UML und natürlicher Sprache
● passt gut zum AUTOSAR-Standard
● funktionale Dekomposition durch hierarchische
Modellierung ermöglicht
● kann ebenso gut auf UML MARTE abgebildet werden
● auch Kombination mit MARTE vorgeschlagen, um
bessere Schedulinganalyse zu ermöglichen [11]
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 20/27Zusammenfassung
● MARTE ist ein Profil für UML, eine leichtgewichtige
Erweiterung, 2009 von der OMG standardisiert
● ermöglicht Modellierung, Simulation und Analyse von
eingebetteten und Echtzeitsystemen
● sehr ausführliche Modellierung von Zeit als Grundlage
für Echtzeitsysteme, auch synchrones Be-
rechnungsmodell unterstützt
● Codegenerierung nur teilweise möglich
● Kombination mit z.B. SysML und SystemC scheint
eine gute und praktikable Lösung zu sein
● auch Kombination von UML mit SPARK möglich:
SPARK-Profil
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 21/27Simulink vs. UML MARTE
Simulink UML MARTE
● Unterstützung zeit- ● OO-Konzepte sorgen für
diskreter und zeit- bessere Modularität und
kontinuierlicher Ber.- Wiederverwendbarkeit,
Modelle (MoC) also Änderbarkeit
● Datenfluss kann besser ● besser für System-
beschrieben werden Spezifikation (NFPs)
● Vorsprung bei auto- ● Codeblöcke müssen oft
matischer Code- noch eingefügt werden,
generierung (z.B. mittels aber z.T. auch schon
RTW) Codegeneratoren
● Änderbarkeit ein-
Quelle: [8]
geschränkt durch
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11
fehlende OO-Konzepte 22/27Resümee Sprachen und Modellierung
● Unterscheidung nach dem Produkt
● Software (ausführbares Programm): klass. Compiler
● Hardware (FPGAs/ASICs): HW-Beschreibungssprachen
● HW-/SW-Codesign (beides): z.B. SystemC
● Unterscheidung nach der Abstraktionsebene
● Höhere Progr.-sprache (C, C++, PEARL, Ada, Lustre, Esterel)
● MDSD (Matlab/Simulink, MARTE/SysML)
● Ziele modellgetriebener Softwareentwicklung (MDSD)
● kürzere Entwicklungszeit (Produkteinführungszeit)
● frühes Testen möglich => Zuverlässigkeit steigt
● schneller Prototypenbau (Rapid Prototyping) für Kunden
● Entkopplung von Domänen- und Plattformwissen
● Portabilität (einfacherer Wechsel zu neuen Plattformen)
● Integration des Entwicklungszyklus bei Simulink und ASCET
bereits gelungen; bei UML MARTE immer besser
● SPARK mit statischer Analyse als weitgehender Ersatz für
Tests,
DirkIntegration in SW
Müller: Entwurf von Entwicklungsumgebungen
für eingeb. Systeme, WS 2010/11 (GNAT)
18.01.11 23/27Ansätze für Korrektheit von SW
● Auswahl geeigneter Formalismen (Sprachen, Modelle)
● Beschränkung der Sprachmittel, Setzen von Regeln und
Richtlinien („Weniger ist mehr.“)
● auf Codeebene
– MISRA-C:2004, MISRA-C++:2008
– SPARK basierend auf Ada
● auf Modellebene
– MISRA-AC-TL für TargetLink
● Design/Program by Contract („Vertrauen ist gut, Kontrolle ist besser!“)
Vor- und Nachbedingungen, dynamisch z.B. bei Eiffel
–
– Annotationen im Quelltext (Redundanz), z.B. SPARK
● Model Checking, Theorembeweisen („Der Teufel liegt im Detail.“)
– Übertragung in Promela, Prüfung mit SPIN; UPPAAL
– statische Prüfung (Theorembeweisen) z.B. mit SPARK
● Nutzung spezifischer Analysewerkzeuge
– Nutzung von Werkzeugen für Lustre/Esterel [5]
– Nutzung von Analysewerkzeugen für MARTE
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 24/27Vergleich zwischen Programmier-
sprachen/Modellierungsmethoden HR Highly recom-
mended – if this
technique or mea-
sure is not used, the
reasons for not us-
ing it should be de-
tailed during safety
planning.
R Recommended
as a lower measure
to an HR recom-
mendation.
--- The technique
has no recommen-
dation for or
against its use.
NR The technique or
measure is posit-
ively not recom-
mended
for this safety integ-
rity level – if it is
used, the reasons
for using it should
be detailed during
safety planning.
Quelle: “IEC 61508-7: Functional safety of electrical/electronic/programmable
electronic safety-related
Dirk Müller: Entwurf vonsystems
SW fürPart 7: Overview
eingeb. Systeme,ofWStechniques
2010/11 and measures“
18.01.11 25/27Programmiersprachen und
Sicherheit
Programmier Sicherheitsmerkmale (Stärken) Schwachstellen
sprache
Ada 83 ● Laufzeitüberprüfungen obligatorisch ● Zugriff auf nicht gesetzte
● Zeiger werden initialisiert Variablen (Skalare)
● typsicher, auch über Paketgrenzen hinweg mit 'Valid bzw.
● Recovery nach Fehlern pragma Initialize_Scalars;
in Ada 95 behoben
Modula-2 ● typsicher, auch über Paketgrenzen hinweg ● nicht gesetzte Variablen
● begrenzte Recovery-Möglichkeiten nach (Skalare) und Zeiger
Fehlern
Pascal ● strenges Typsystem ● Laufzeitüberprüfungen nur
optional
● nicht gesetzte Variablen
(Skalare) und Zeiger
C ● (zusätzliche Werkzeuge: make und lint) ● 150 nicht definierte „Features“
● Laufzeitüberprüfungen finden
häufig nicht statt
Fortran 77 ● Typprüfung ● Default-Zuweisungen
● keine Zeiger ● keine Prüfungen über
Quelle: [6], S. 412 Paketgrenzen hinweg
Dirk Müller: Entwurf von SW für eingeb. Systeme, WS 2010/11
18.01.11 26/27[1]
Literatur
M. Mura, A. Panda, M. Prevostini: “Executable Models and Verification from MARTE and
SysML: a Comparative Study of Code Generation Capabilities”. In: Proceedings of
MARTE Workshop (DATE08), Munich, Germany, March 2008,
http://www2.lifl.fr/MARTEworkshop/papers/PrevostiniMuraPanda_Date08_Friday_W8.pdf
[2] S. Gérard, F. Terrier, B. Selic, P. Boulet: “MARTE, The UML standard extension for real-
time and embedded systems“, 2008,
http://www-users.cs.york.ac.uk/~burns/papers/MARTE.pdf
[3] OMG Unified Modeling Language (OMG UML), Superstructure, Version 2.3, May 2010,
http://www.omg.org/spec/UML/2.3/Superstructure/PDF/
[4] UML Profile for MARTE, 1.0, Nov 2009, http://www.omg.org/spec/MARTE/1.0/PDF/
[5] The synchronous group: “Tools”, 2010,
http://www-verimag.imag.fr/Tools,36.html?lang=en
[6] John Barnes (Hrsg.): „Ada 95 Rationale“, LNCS 1247, Springer, Berlin/Heidelberg, 1995
[7] Xavier Sautejeau: „Modeling SPARK systems with UML“, ACM SIGAda Ada Letters, Vol.
XXV, Issue 4, pp. 11-16, 2005,
http://doi.acm.org/10.1145/1104011.1103848
[8] L. Brisolara et al.: “Using UML as a front-end for an efficient Simulink-based multithread
code generation targeting MPSoCs”, UML-SoC’07. San Diego, June 2007,
http://www.inf.ufrgs.br/~lisane/Brisolara_UmlSoC07.pdf
[9] F. Mallet, R. de Simone, L. Rioux: „Event-triggered vs. Time-Triggered communications
with UML MARTE“, Forum on Specification and Design Languages, pp. 154-159, 2008
[10] EAST ADL 2.0 Specification, 2008,
http://www.atesst.org/home/liblocal/docs/EAST-ADL-2.0-Specification_2008-02-29.pdf
[11] Anssi et al.: “Completing EAST-ADL2 with MARTE for enabling scheduling analysis for
Dirk Müller:
automotive Entwurf vonERTSS
applications“, SW für2010,
eingeb. Systeme, WS 2010/11
18.01.11http://www.erts2010.org/Site/0ANDGY78/Fichier/PAPIERS%20ERTS%202010%202/ERTS2010_0123_final.pdf
27/27Sie können auch lesen
