baikem2011 uml_in_der_praxis

UML konkret einsetzen ein Praxisleitfaden für C/C++ Entwickler
Andreas Foltinek, IMACS GmbH
andreas.foltinek@imacs-gmbh.de
1. Kurzfassung
Die modellbasierte SW-Entwicklung mit UML hat sich mittlerweile fest etabliert. Immer mehr Entwickler haben sich entschieden, diese zu verwenden, zögern jedoch mit der Einführung. Größtes Hemmnis ist dabei
nicht (mehr) der Zweifel an Effektivität oder dem Nutzen, sondern der vermeintliche "Sprung ins Ungewisse"
und eine vermutete "lange Einarbeitungszeit".
Liegt die Lösung einer Problemstellung mit C/C++ meist intuitiv auf der Hand, so stellen sich beim Einsatz
von UML oft viele Fragen:
 Wie und in welchen Fällen muss ich welches Diagramm verwenden?
 Wie können Details wie Metadaten und funktionale Implementierungen mit eher abstrakten Diagrammen
konkret modelliert und beschrieben werden?
 Wie werden Kommunikationen, verteilte Systeme oder HMI's modelliert?
 Wie wird mit zeitkritischen Funktionen umgegangen? Welche Designelemente müssen gewählt werden?
 Wie wird ein Design/Projekt getestet – auf dem Zielsystem aber auch virtuell?
 etc.
Anhand einer konkreten Modellierung werden diese und andere Fragen anschaulich beantwortet und gezeigt, wie einfach UML funktioniert - genau so intuitiv und offensichtlich wie C/C++.
Der Vortrag zeigt dabei die Einfachheit und Gradlinigkeit einer Entwicklung mit UML. Unter Vermeidung theoretischer Darstellungen wird anhand eines konkreten praktischen Beispiels die Realisierung eines Projektes
dargestellt. Er gibt ferner einen Eindruck über die Effektivität bei der Verwendung von UML und UMLErweiterungen – vom der modellbasierten Analyse, über das Design und der Implementierung bis zur automatischen Code-Generierung.
UML in der Praxis
IMACS GmbH – Embedded Software Tools 2011
1 von 9
2. Einleitung
2.1 Fokus
Der Vortrag möchte nicht die Frage diskutieren, ob UML/SysML basierte Methoden verwendet werden sollten oder nicht. Die prinzipielle Sinnhaftigkeit hängt von vielfältigen Randbedingungen ab und wurde bereits
eingehend diskutiert [1].
Natürlich bewirkt die UML keine Wunder und ein schlechter Programmierer wird sich dadurch nicht signifikant verbessern - fähige Entwickler werden hingegen Ihre Effektivität enorm steigern.
Im Fokus demonstriert der Vortrag den Weg von der Produktidee, über das Modell, dem generierten Code,
einer realitätsgetreuen Simulation bis zur Integration auf einem lauffähigen Target. Nicht betrachtet werden
hier Themen wie Requirements Engineering oder Traceability (die ebenfalls wichtig sind). Auch wird nicht
separat auf die SysML eingegangen, da es viele Parallelen zur UML gibt und teilweise lediglich Notationen
und Bezeichnungen verwendet werden. Das im Folgenden beschriebene Beispiel ist daher auch im Zusammenhang mit der SysML-Nutzung anwendbar.
2.2 Inhalt und Struktrierung
Das grundlegende Problem der UML ist: Es handelt sich lediglich um eine "Sprache". Genau wie bei einer
menschliche Sprache mit Vokabular und Grammatik ist es möglich daraus verschiedenste Dinge wie Lyrik,
Novellen, Schachbücher, Gesetzestexte etc. zu erstellen. Dabei gibt es zunächst kein globales "richtig" oder
"falsch", bzw. kein "gut" oder "schlecht". Die Qualität eines Dokumentes ist erst im Kontext mit dessen Verwendung bestimmbar.
Entsprechend ist es möglich, die UML auf ganz verschiedenen Arten anzuwenden – dies mehr oder weniger
sinnhaft im Bezug auf den jeweiligen Anwendungsfall. Hier ist es besonders das Erarbeiten und konsequentes Einsetzen eines richtigen Vorgehensmodells. Dieses beschreibt wie die UML für die jeweiligen Problemstellungen richtig eingesetzt wird.
Das nächste Kapitel zweigt die vollständige Realisierung eines sehr einfachen embedded Steuerungsprojektes unter dem Einsatz der UML. Das hier verwendete Vorgehensmodell wurde in vielen embedded Projekten
erfolgreich verifiziert und zeigt sehr klar die Parallelen zu einer Entwicklung mit C/C++.
Der Weg der Entwicklung wird in folgenden Schritten dargestellt:
1) Modellierung …
der Applikation mit den zwei Phasen "Design" und "Konkrete Implementierung"
2) Generierung …
des plattformunabhängigen Serien-Codes (d.h. es ist keine manuelle Nacharbeit mehr
erforderlich) durch Verwendung eines HAL
3) Simulation …
und Test auf einer virtuellen Hardware. Diese wird durch einen PC emuliert und stellt
hierbei das Verhalten der Steuergeräteumgebung realitätsgetreu dar.
4) Integration …
und Test auf einem realen Zielsystem mit Einsatz des Design-Level-Debuggings.
1. Modelierung
(Model Editor)
3. Simulation
2. Generierung
(PC-Software)
(Source Code)
4. Integration
(Target)
Abbildung 1: Typische Schritte einer modellbasierten Projekt-Generierung
UML in der Praxis
IMACS GmbH – Embedded Software Tools 2011
2 von 9
2.3 Modellverarbeitung
Modellierung
Aus Sicht der einzelnen Teilwerkzeuge wird die Modell-Information mit der folgenden Werkzeugkette verarbeitet:
Model Editor
Generierung
Code
Import
C, C++, ST
HMI
Visual
HMI
Target
Code
Version Control
System
XML-Repository
Projects, Applications,
Libraries etc.
Interfaces
Code-Generator
Simulation
Editor: C/C++, UML, PLC, HMI
IDE, Launcher, Relocator
Document.
rC-Lib
MSVC .NET
MSVC .NET
Debugger
Compiler
Offline Simulation
Visualization
(PC-Software), Software in
the Loop, UML-Debugger
(PC-Software), DataLogger, UML-Debugger
API, Driver,
RT-Scheduler
other Tools
Libraries
RTOS
Protocol
Stack's
Target Debugger
Target Compiler /Linker
any 8,16,32 Bit
any 8,16,32 Bit
online connection
Target(s)
single / distributed
Integration
Abbildung 2: Die vier Entwicklungsschritte im Bezug auf den Tool Chain Flow
2.4 Beispielapplikation
Um diesen Ansatz zu demonstrieren, wird ein sehr einfaches Steuerungssystem mit drei Flüssigkeitstanks
realisiert. Jeder Tank beinhaltet einen analogen Füllstandsensor AI_Level, einen elektrisches Ventil
DO_Valve zur Befüllung sowie ein manuelles Auslassventil. Der gewünschte Flüssigkeitsstand kann über
den Parameter SetLevel bestimmt werden. Die Niveauregelung soll über eine Hysterese von 4cm verfügen
und eine verzögerte Reaktion von 5s aufweisen um ein Flattern des Einlassventils zu verhindern.
Abweichend von den ersten zwei Tanks soll der dritte Tank einen zusätzlichen Alarmausgang DO_Alarm
enthalten der aktiviert wird, falls der Flüssigkeitsstand unter die Marke AlarmLevel sinkt.
Zur Darstellung der flexiblen Lösungsmöglichkeiten soll die Reglerfunktionalität zum einen klassisch textuell
aber auch mit einer grafischen Notation erstellt werden.
Abbildung 3: Beispielprojekt, Übersicht der 3 Tanks und Detailansicht von Tank 1
UML in der Praxis
IMACS GmbH – Embedded Software Tools 2011
3 von 9
3. Leitfaden für die Umsetzung
3.1 Modellierung
3.1.1 Vorgaben und Richtlinien zur Applikationsmodellierung
Der effektivste Weg der modellbasierten Entwicklung ist die Generierung von Serien-Code. Dies bedeutet,
das keine nachträgliche manuelle Bearbeitung des Codes mehr erforderlich sein darf/muss. Dadurch ist ein
Divergieren von Code und Modell ausgeschlossen und kein problematische "Round-Trip-Engineering" erforderlich (= Nachführen des Modells aufgrund manueller Änderungen im generierten Code). Daher wird für die
Modellierung von embedded Steuerungssystemen die Beachtung folgender Grundsätze empfohlen:
 Alle Applikations-Information sollten innerhalb des Modells gehalten werden – auch die vollständige
funktionale Implementierung, Metadaten, HMI etc. (natürlich auf eine virtuelle, hardwareunabhängige Art).
Dies vermeidet die manuelle Nachbearbeitung des generierten Codes sowie aller anderer Generierungsprodukte.
 Realisierung eines hohen Levels an Objektorientierung, was bedeutet, dass alle Informationen, die zu
einer logischen/technischen Einheit gehören, im selben Modul (Klasse) abgebildet sind. Die garantiert ein
Maximum an Wiederverwendbarkeit und reduziert die Verbindungen innerhalb des Models auf ein Minimum.
 Redundanz vermeiden. Jede Information/Entität (z.B. Struktur, Daten, Funktionalität, HMI, weiterführende Informationen etc.) sollten nur einmal definiert sein und dann von anderer Seite nur noch entsprechend
referenziert werden. Zweitdefinitionen an einer anderen Stelle sind unbedingt zu vermeiden.
Um diese Empfehlungen einzuhalten, sind verschiedene zielgerichtete Erweiterungen der UML erforderlich,
was dem Geist der UML jedoch nicht wiederspricht (sondern sogar nahegelegt wird).
3.1.2 Konkreter Ablauf der Modellierung
Die konkrete Modellierung wird in der Reihe nach entsprechend den unten aufgelisteten Schritten durchgeführt. Neben diesen werden oft auch vorgelagerte Schritte (z.B. Anforderungsbeschreibung mit Anwendungsfällen) und nachfolgende Schritte (funktionale Verifikation) durchgeführt, die jedoch nicht Fokus dieses
Vortrags sind.
Um den Entwicklungs-Übergang von C/C++ nach UML zu erläutern, sind die korrespondierenden C/C++ Tätigkeiten parallel zur UML dargestellt. Zur Verdeutlichung werden folgenden Symbole verwendet:
 C = Aktivitäten zur Entwicklung mit C
 C++ = Aktivitäten zur Entwicklung mit C++
 UML = Aktivitäten zur Entwicklung mit UML
 UML = verwendete UML-Sprachelemente
 UML = beschreibt die Vorteile durch UML-Einsatz, auch durch automatisch generierte Zusatztools
Step 1: Separierung der logischen "Einheiten" und Strukturierung des Designs
Bestimmung und Separation der einzelnen technischen/logischen "Einheiten" des Systems. Die "Einheiten"
des Beispielprojektes sind: System (root unit), 2 x TankControlA (für Tank 1,2), 1 x TankControlB (für Tank
3).
Ferner werden die ersten bekannten Attribute, Daten und Funktionen entwurfsmäßig angelegt.
C
Erstellung von main() und zwei struct's zur Datenhaltung. Erstellung der (noch) leeren Regelungsfunktionen.
 C++ ::
Erstellung einer Klasse für jede "Einheit". Entwurf der Elemente und Prozeduren.
 UML ::
Erstellung einer Klasse für jede "Einheit". Entwurf der Elemente und Prozeduren (ggf. grafisch).
 UML ::
Klassen Diagramm: Klassen, Komposition, Aggregation, Generalisierung.
 UML
Grafische Dokumentation und Liste der Klassen und deren Attribute.
Step 2: Verteilung der "Einheiten" auf mehrere Design-Files
Um später die TankControlX Einheit (Klasse) in anderen Projekten wiederverwenden zu können, ist es erforderlich, diese in einer separaten Datei abzulegen. Diese Bibliotheksdatei wird dann in unser Hauptprojekt
eingebunden.
C
Erstellung neuer .c und .h files. Manuelles Verschieben der Code-Teile von der alten in die neue Datei.
 C++ ::
Erstellung neuer .c and .h files. Manuelles Verschieben der Code-Teile von der alten in die neue Datei.
 UML ::
Erstellung neuer Project-Files und Verschieben der Klasse TankControlX per Maus ins die neue Datei.
 UML ::
Paket Diagramm: Relationen
 UML
Grafische Dokumentation der einbezogenen Files, deren Hierarchie und der Klassen in den Files.
UML in der Praxis
IMACS GmbH – Embedded Software Tools 2011
4 von 9
Step3: Erstellung von Instanzen (Objekte) und Vervollständigung der Relationen
Gemäß der benötigten Tankanzahl müssen die Klassen nun instanziiert werden. In UML werden diese Instanzen als Objekte bezeichnet. Weiterführend müssen die Beziehungen nun vervollständigt werden. In unserem Beispiel beinhaltet TankControlB die gleichen Teile von TankControlA mit einigen Erweiterungen/Zusätzen. Daher kann TankControlB von TankControlA erben und übernimmt damit alle Attribute.
C
Erstellen von zwei globalen Variablen des Typs TankControlA und einer des Typs TankControlB. Erstellen einer zyklisch aufgerufenen Funktion, die die Regelungsfunktionen jedes Tasks separat aufruft und den entsprechenden TankHandle übergibt.
 C++ ::
Erstellen von zwei Instanzen von TankControlA und einer von TankControlB. Eine Vererbungsrelation textuell hinzufügen.
 UML ::
Erstellen von zwei Instanzen von TankControlA und einer von TankControlB. Eine Vererbungsrelation grafisch hinzufügen.
 UML ::
Klassen Diagramm: Komposition, Aggregation, Generalisierung; Objekt Diagramm.
 UML
Grafische Dokumentation und Listung der Klassen und deren Beziehungen.
Step 4: Festlegung der Schnittstellen zwischen "Einheiten" und deren Kommunikation
Neben der Struktur und Hierarchie der Klassen ist die Art der Interkommunikation essentiell. Im Falle unseres Beispiels wird ein entsprechender Bereich in den Tankmodulen angelegt:
C
Manuelle Codierung.
 C++ ::
Manuelle Codierung.
 UML ::
Erstelle einen Interface-Bereich (Port) in der Klasse und verschiebe die entsprechenden Elemente und Funktionen dort
hinein.
 UML ::
Komponenten Diagramm.
 UML
Grafische Dokumentation und Listung des Klassen Interfaces.
Step 5: Vervollständigen der Daten-"Elemente" (aus den Modell-Attributen)
Ein "Element" ist in diesem Zusammenhang ein Objekt, womit jegliche Daten beschrieben werden und überdies eine leistungsfähige Virtualisierung für alle Datenarten (RAM Variables, EEPROM Variable, IOs, Timer,
Counter, Konstanten, Simulationsvariablen, etc.). Daneben beinhaltet ein Element alle Meta- und Zusatzdaten (multilinguale Beschreibungen, Wertebereich, physikalische Einheit, Visualisierung, graphische Darstellung, Kommunikation etc.), die in den Generierungsprodukten redundanzfrei verwendet werden können.
C
Vervollständigen der globalen Variablen (TankControlA , TankControlB). Erstellen von separaten Aufrufen der Regelungsfunktion für alle drei Instanzen. Einfügen der Metadaten in ein sep. File.
 C++ ::
Vervollständigen der Elemente und Verschieben dieser in die entsprechende Klasse. Einfügen der Metadaten in ein
sep. File.
 UML ::
Vervollständigen der Elemente und Verschieben zur korrekten Stelle.
 UML ::
Klassen Diagramm: Elemente.
 UML
Globale Liste aller angelegten Elemente mit deren Metadaten. Realitätsgetreue Simulation und Test der kompletten Applikation. Sehr offensichtliches Design Level Debugging
Step 6: Einfügen der Prozess-Visualisierung (PC-HMI / SCADA)
Eine Prozessvisualisierung ist ein hervorragendes Zusatz-Tool zum Testen und Debuggen. Leistungsfähige
UML-Tools ermöglichen deren modellinterne Definition sowie die automatische Generierung in Form einer
eigenständigen PC-Software.
C
nicht möglich (bzw. nur mit einem separaten System)
 C++ ::
nicht möglich (bzw. nur mit einem separaten System)
 UML ::
Einfügen der Oberflächen und Visualisierer ins Modell
 UML ::
HMI Vorschau
 UML
Realitätsgetreue Simulation und Test der kompletten Applikation. Sehr offensichtliches Design Level Debugging
Step 7: Vervollständigen der Funktionalität
Vervollständigung und Fertigstellung der Funktionalität mit textuellen oder grafischen Notationen.
C
nur textuell mit C-Funktionen möglich
 C++ ::
nur textuell mit C-Funktionen oder C++ -Methoden möglich.
 UML ::
textuell und grafisch durch die Verwendung von Activity-, Signal- und State-Charts or Procedures (C-code).
 UML ::
Klassen Diagramm, Objekt Diagramm.
 UML
Realitätsgetreue Simulation und Test der kompletten Applikation. Sehr offensichtliches Design Level Debugging
Bereits ab Schritt 5 ist eine vollständige Code-Generierung des Projektes möglich und damit auch eine lauffähige PC-Simulation dessen verfügbar. Nach den erforderlichen Modifikations-/Korrekturschleifen ist die
Modellierungsphase nach erfolgreichem Test abgeschlossen.
Ergebnis ist eine plattformunabhängige und getestete Applikation in Form eines UML-Modells.
UML in der Praxis
IMACS GmbH – Embedded Software Tools 2011
5 von 9
Abbildung 4: Modellteile in Form des Projektbaums, eines Klassendiagramms und eines State-Charts
3.1.3 Umsetzung weiterführende Anforderungen
Neben diesem sehr einfachen Beispiel, haben reale Projekte, insbesondere embedded Systeme, natürlich
sehr viel komplexere Anforderungen. Die folgende Aufzählung enthält eine Sammlung von Themen (und einen Ansatz zur Umsetzung), die typischerweise von Kunden nachgefragt werden.
Laufzeitdynam. Teile
Echtzeit, Multitask.
Interrupts
HW spez. Teile
Bestehender Code
Target-HMI
Verteilte Systeme
UML in der Praxis
Hierzu können sogenannte "Interface-Klassen" verwendet werden, die als Platzhalter für die dynamischen Instanzen dienen. Zur Laufzeit werden diese auf Anforderung verbunden oder getauscht.
Die Funktionalitäten verschiedener Reaktions- und Zeitanforderungen können
durch die Wahl von Abarbeitungstypen einer entsprechend Gruppe zugeordnet
werden. Diese Gruppen können über das API entsprechend der PrioAnforderungen individuell "schedult" werden.
Den Modellteilen, die per Interrupt abgearbeitet werden sollen, wird ein besonderer
Abarbeitungstyp zugewiesen, der dann mit der Interrupt-Service-Routine verbunden wird.
Für alle hardware-spezifischen Komponenten/Teile kann im HAL/API eine entsprechende, möglichst einfache Schnittstellenfunktion erstellt werden, die dann vom
Modell aufgerufen wird. In der Simulation kann diese oft durch wenige Zeilen
Code ebenfalls nachgebildet werden.
Existente C/C++-Code-Teile können in eine Klasse als gewöhnliche Prozedur(en)
integriert werden (das UML-Tool muss dies unterstützen).
Leistungsfähige UML-Tools unterstützen die Integration des vollständigen HMIs
(textuell und/oder grafisch) bereits im Modell als ein spezieller Bestandteil eine
normalen Klasse. Sie unterstützen statische, dynamische und interaktive HMI Inhalte und haben direkten Zugriff auf die Elemente und deren Metadaten (sehr hilfreich). Die Ausführung auf dem Zielsystem wird durch eine HMI-Engine realisiert,
die unabhängig von der Applikationsfunktionalität ausgeführt wird und reicht von
monochromen Dot-Character-Displays bis zu "full color" SVGA.
Leistungsfähige UML-Tools unterstützen die Modellierung (und Code-Generierung)
von verteilten Systemen. Die einzelnen Knoten werden hierbei als speziell gekennzeichnete hierarchische Unterklassen instanziiert, und können entweder in der Simulation als Ganzes oder für die jeweiligen Targets separat generiert werden. Für
die eigentliche Kommunikation werden entsprechende Funktionsaufrufe generiert,
die vom API zur Verfügung gestellt werden. Der Entwickler kann dabei ohne weitere Beachtung direkt auf Daten anderen Knoten zugreifen.
IMACS GmbH – Embedded Software Tools 2011
6 von 9
3.2 Code-Generierung
3.2.1 Vorgaben und Richtlinien
Für die Code-Generierung (Abbildung 2) wird die Einhaltung der folgenden Grundsätze empfohlen.
 Prinzipiell können zwei unterschiedliche Methoden der Code-Generierung unterschieden werden:
a) Transformierende Code Generation (TCG), ist eine eher simple lineare Methodik, die Templates
durch Ersetzen/Einfügen entsprechend dem erstellten Modell anpasst. In der Regel sind die Ergebnisse
Code-Frames die manuell vervollständigt werden müssen.
b) Compilierende Code Generation (CCG), arbeitet mit einem speziellen Design-Compiler, der komplexe Generierungsprozesse unterstützt (z.B. C-Code aus einem OO-Modell) und verschiedene Generierungsergebnisse erzeugt. In der Regel wird "fertiger" C-Code erzeugt, der ohne Nachbearbeitung für das
Zielsystem übersetzt werden kann.
 Der effizienteste Weg ist die direkte Erzeugung von Serien-Code, der keine manuelle Nachbearbeitung
benötigt (technisch nur mit der CCG-Methode möglich).
 Unterstützung der direkten Generierung von ANSI-C-Code (für 8/16Bit Prozessoren bzw. zur Reduktion
der Code-Größe) trotz eines objektorientierten Modells ohne die Beschränkung der OO-Features (technisch nur mit der CCG-Methode möglich).
 Generierung von gut verständlichem (lesbaren) Code für den Fall eines Source-Level-Debuggens, Zertifizierung oder anderer Prüfungen)
 Kompakter und performanter Code, passend zum Zielsystem bzw. der Applikation.
 Neben der Quell-Code-Generierung, sind ebenfalls andere weiterführende Generierungsprodukte
nützlich oder sogar zwingend notwendig.
 Der Code-Generator muss spezielle Eigenheiten des Zielsystems wie z.B. (Alignment, Byte-Anordnung,
Segmentierung, etc. unterstützen.
3.2.2 Generierungsergebnisse
Im Detail erzeugt der Code-Generator folgende Ergebnisse (Quellcode und Dokumentation):
 Definition der Datenstrukturen verschiedener Typen von Elementen für alle Instanzen
 Instanziierte Daten aller Elemente/Module einschließlich deren Metadaten (falls erforderlich)
 Extensive Pointer-Konstruktionen zur Unterstützung der OO-Eigenschaften auch mit regulärem C-Code
 Funktionaler Code von State-Charts, Activitiy Charts, Signal-Charts, Prozeduren, …
 Code-Teile zur Unterstützung der verteilten Kommunikation
 Ausführliche Dokumentation für alle Bereiche des Modells und dessen implementierende Teile
Ferner (falls erforderlich):
 Vollständige HMI Daten (z.B. für eine Runtime-HMI-Engine) mit Referenzen zu den Daten-Strukturen
Weiterführendes für Werkzeuge/Tool-Chain:
 Cross-Referenz-Listen zur Herstellung der Verbindung zwischen Modell und generiertem Code
Da das Beispielprojekt kein Zielsystem-HMI besitzt, hat der hier erzeugte Code nur eine geringe Größe und
umfasst lediglich die Definitionen der Datenstrukturen, die instanziierten Daten sowie die multi-entrance fähigen C-Funktionen der modellierten Funktionalität.
UML in der Praxis
IMACS GmbH – Embedded Software Tools 2011
7 von 9
3.3 Simulation
Leistungsfähige UML-Werkzeug-Systeme bieten eine realitätsgetreue Simulation (Abbildung 3) des Modells.
Um dies zu ermöglichen, wird der (hardwareunabhängige) generierte Code mit einem allgemeingültigen, virtuellen API übersetzt und kann als eigenständige PC-Software ausgeführt werden. Die Zustände der Simulation des Projektes erfolgt über die generierte PC-basierte Prozessvisualisierung (also ohne separaten Aufwand).
Dies ermöglicht dem Entwickler, sein Projekt bereits vorab zu testen und zu präsentieren (Abbildung 1), ohne hierzu ein reales Zielsystem zu benötigen (MBS = modellbasierte Simulation),
3.3.1 Vorgaben und Richtlinien
Analog zu den anderen Phasen hat eine effektiv verwendbare Simulation folgende grundsätzliche Anforderungen zu erfüllen:
 Die Simulation muss automatisch generiert werden - ohne separate Tätigkeiten durch den Entwickler sowie für alle denkbaren Projektarten.
 Alle Variablen des Projektes müssen in einer gut strukturieren Weise mit Metadaten angezeigt werden
und müssen manipulierbar sein. Dies ermöglicht ein effektives DLD (= Design Level Debugging)
 Das Verhalten der Simulation sollte das reale Laufzeitverhalten des Targets, als auch die Reaktionen der
Umweltsimulation im Modell so gut als möglich nachbilden. Für eine RMBS (= Realistic Model Based Simulation) werden > 95% empfohlen.
3.3.2 Ablauf der Offline-PC-Simulation
Nach der Generierung und Compilierung kann die PC-Simulation als Standalone-PC-Software gestartet
werden. Dies bietet die Möglichkeit, die Simulation einem Kunden oder Kollegen zu geben. Es bietet dem
Anwender die volle Funktionalität einschließlich des Embedded Target HMI.
3.4 Integration auf dem Zielsystem
Die Kopplung des generierten Codes mit der Tool-Chain des Zielsystems (Abbildung 2) erfolgt über einen
HAL/API. Es enthält ca. 15…35 festgelegte C-Funktionen und eine Runtime-Library (hängt davon ab ob das
Zielsystem über ein HMI verfügt). Die API-Funktionen abstrahieren den Zugriff auf EA's, Timer, Zähler,
Schnittstellen, Display, Touch etc.)
Da vom CASE-Tool lediglich die funktionalen Prozeduren bzw. Prozedurpakete generiert werden, müssen
diese vom API aus mit der erforderlichen Häufigkeit und Priorität aufgerufen werden. Dadurch behält das
API (der Systemintegrator) die Gesamtkontrolle und kann diese individuell und flexibel anpassen.
3.4.1 Ablauf der Online-PC-Visualisierung
Höherwertige Tools bieten darüber hinaus die Möglichkeit, die erzeugte PC-Software über eine DatenSchnittstelle (seriell, USB, Ethernet CAN) mit der Hardware zu verbinden und ermöglichen damit DLB (Design-Level-Debugging) auch auf der laufenden Hardware. Durch die Verwendung der "Recorder-Funktion"
des Tools ist es möglich, alle internen Zyklen aufzuzeichnen und sie zum Debuggen Schritt für Schritt zu
überprüfen.
UML in der Praxis
IMACS GmbH – Embedded Software Tools 2011
8 von 9
4. Ergebnisse und Diskussion
Der größte Nutzen beim Einsatz der modellbasierten Entwicklung ergibt sich bei einer hochgradigen Integration/Abdeckung aller relevanten Projektinformationen durch das Modell. Die Integration der Implementierung
(Funktionalitäten und Daten) sowie aller anderen Projektinformationen in das Modell ist sicher ein ungewöhnlicher Ansatz, erfüllt jedoch die Entwickleranforderungen in einer äußerst effektiven und pragmatischen
Weise (best practice).
Neben dem generierten Zielsystem-Code ist ein weiterer Aspekt die große Anzahl von zusätzlichen Generierungsprodukten aus dem Modell wie Offline-Simulation, Online-Visualisierung, Dokumentation, Kommunikation etc.
Die zentrale Frage ist die Absicht des Entwicklers bei der Verwendung von UML. Ist es für ihn ausreichend,
mit UML lediglich ein Design zu entwickeln und dann manuell zu implementieren, oder soll das Modell als
zentrale Designbasis eine vollständige Generierung des Seriencodes (und Zusatz-Software) ohne manuelle
Nacharbeit ermöglichen.
Seit nun über 10 Jahren Marktpräsenz nutzen viele Software-Entwickler die "Overall-Object-Orientation"Methode mit Seriencode-Generierung und wollen diese effiziente Weise der Softwareentwicklung mit UML
nicht mehr missen. Natürlich bedingt dies die Erweiterung der UML in vielen Gebieten und die UML bekommt dadurch Aspekte einer DSL (Domänen Spezifischen Sprache) für embedded Steuerungssysteme.
Dies ist jedoch normal und symptomatisch und jeder effiziente Einsatz der UML mit der Beabsichtigung einer
Code-Generierung bedingt Erweiterungen der Sprache.
Begriffe:
MBS
RMBS
O³
CCG
TCG
DLD
DSL
HAL
HMI
Model Based Simulation
Realistic Model Based Simulation
Overall Object Oriented: alle relevanten Informationen (nicht nur Daten und Funktionalitäten)
sind Bestandteil einer Klasse/ eines Moduls
Compiling Code Generation
Transforming Code Generation
Design Level Debugging
Domänen-spezifische Sprache
Hardware Abstraction Layer
Human-Machine-Interface: Bedienerschnittstelle
Quellen:
[1] C. Kechler: "UML 2.0", Galileo Press, Bonn 2006
[2] T. Weilkiens: "Systems engineering mit SysML/UML", dpunkt.verlag, Heidelberg 2006
[3] P. Hruschka, C. Rupp: "Agile Softwareentwicklung …", Hanser, 2002
Autor:
Andreas Foltinek studierte Elektrotechnik an der Universität Stuttgart.
Bereits vor seinem Studium sammelte er als "Jugend forscht" Teilnehmer und durch zahlreiche Projektentwicklungen für Firmen im MSR-Bereich umfangreiche Erfahrung und kann auf mittlerweile 25 Jahre Embedded Hard- und Softwarepraxis zurückblicken.
1994 gründete er die Firma IMACS GmbH und ist seither dort als Geschäftsführer für Forschung und Entwicklung verantwortlich. Als geistiger Vater eines UML basierten CASE-Tool-Systems gilt seine Leidenschaft
den Methoden zur Softwareentwicklung sowie der Erhöhung der Einsetzbarkeit und des Abdeckungsgrades
von Softwaremodellen und Codegeneratoren.
Schwerpunktmäßig beschäftigt er sich aktuell mit neuen Tool-Konzepten sowie der Beratung von Kunden
beim Einsatz von OOP UML, MDD, deren praktischen Umsetzung und der hardwareseitigen Integration.
UML in der Praxis
IMACS GmbH – Embedded Software Tools 2011
9 von 9