Informationstransfer von UML nach ASCET - ETAS

Von Marcel
Hachmeister,
Robert Bosch
GmbH
24
RT 1.2007
Informations-
transfer von UML
nach ASCET
Jede Entwicklungsphase wird
unterstützt: Von der Software-Architektur
bis zur Implementierung
Die Durchgängigkeit von der Software-Architektur bis zur Implementierung ist ein zentrales
Element im Software-Entwicklungsprozess der Getriebesteuerung. Der Artikel zeigt,
wie jede Entwicklungsphase durch aufeinander abgestimmte Tools unterstützt und die
Durchgängigkeit des Entwicklungsprozesses gewährleistet wird.
D ie
immer umfangreicher und
komplexer werdenden Software-
Umfänge verlangen nach abstrakteren
Beschreibungssprachen. Nach Assembler
und C-Programmierung werden
jetzt grafische Beschreibungssprachen
eingesetzt, sagt doch ein Bild mehr als
tausend Worte.
Zur Erreichung eines effizienten Software-Entwicklungsprozesses
setzt die
Robert Bosch GmbH bei der Software-
Entwicklung der Getriebesteuerung
daher eine aufeinander abgestimmte
Kombination aus grafischen Designund
Entwicklungstools ein.
Die Spezifikation der Software-Architektur
oder des Grobdesigns erfolgt in
UML (Ameos von Aonix), das Feindesign
und die Eingabe der Implementierungsinformation
erfolgen in ASCET
von ETAS. Dabei werden alle notwendigen
Informationen des UML-Modells
automatisch nach ASCET übertragen.
Diese Transformation erfolgt durch das
Tool aquintos.M2M der auf Modelltransformationen
spezialisierten Firma
aquintos (siehe Bild 1).
Die Ergebnisse der einzelnen Phasen
stehen in einem festen Bezug zueinander.
Dieser Bezug darf nicht verloren
gehen und wird durch geeignete Toolkopplung
sichergestellt. Dadurch wird
eine hohe Produktqualität erreicht
und die Anzahl der Rekursionen auf
ein Minimum beschränkt. Das in früheren
Entwicklungen entstandene Eigenleben
der einzelnen Entwicklungsphasen
und die damit einhergehende
Inkonsistenz wird wirkungsvoll ausgeschlossen
(z. B. Designdokumentation
passt nicht mehr zum Code etc.).
Dieser Artikel befasst sich mit der
Erstellung des Grobdesigns mittels
UML (Unified Modeling Language),
dem Transfer der statischen Softwarestruktur
nach ASCET mit dem anschließenden
Feindesign sowie der
Implementierung.
Software-Architektur/Grobdesign
eines Softwareteils
In der Getriebesteuerung der Robert
Bosch GmbH wird die Beschreibungssprache
UML eingesetzt. Durch diese
normierte und international anerkannte
Beschreibungssprache werden
Missverständnisse vermieden und die
Lesbarkeit sichergestellt. Die grafische
Notation erlaubt es, komplexe Sachverhalte
übersichtlich darzustellen. Die
UML ist besonders für objektorientierte
Software-Entwicklung ausgelegt.
Aufgrund der notwendigen hohen
Code-Effizienz bei Embedded Realtime-Systemen
wird die Software der
Getriebesteuerung in C programmiert.
Daher werden die Möglichkeiten der
Objektorientierung und der UML-
Beschreibungselemente nur eingeschränkt
benutzt.
Das OMOS-Konzept von der Robert
Bosch GmbH wurde entwickelt, um
wesentliche Elemente der Objektorientierung
zu nutzen und in C-Code
abzubilden (OMOS = Objektorientiertes
Modellierungskonzept für Steuergerätesoftware).
OMOS ist als Zusatz in Ameos verfügbar.
Hinter dem OMOS-Konzept verbergen
sich dabei zwei wesentliche Strategien:
• Variantenhandling und Konfiguration
• Anbindung vom Grobdesign an das
Feindesign/Implementierung (z. B.
Abbildung von objektorientierten
Methoden auf C durch C-Coderahmengenerierung)
Die Umsetzung dieser Strategien mit
UML wird im Folgenden kurz beschrieben.
Auf detaillierte Umfänge
von OMOS kann an dieser Stelle nicht
eingegangen werden.
Zur Beschreibung von Varianten wird
die Vererbung eingesetzt. Ziel ist, die
gemeinsamen Software-Anteile für
verschiedene Projekte in der „Elternklasse“
zu modellieren. Die projektspezifischen
Anteile werden in der
„Kindklasse“ modelliert. Dieses Stilmittel
wird auch dazu benutzt, um
komplette Funktionen auszublenden
(für unterschiedliche Projektanforderungen),
siehe Bild 2.
Bild 1:
Phasen in der
Software-
Entwicklung.
Bild 2:
UML-Klassendiagramm.
Architektur des SW-Systems
Architektur/Grobdesign
eines SW-Teils (Subsystems)
Feindesign
eines SW-Teils (Subsystems)
ASCET Editor
«1-Class»
CL_TSiCnr
«1-Class»
CL_TSiDhl
«1-Class»
CL_TSiFo
«1-Class»
CL_TSiHil
Ameos
Implementierung & Codegenerierung
eines SW-Teils (Subsystems)
«1-Class»
CL_TSi_Bas
«1-Class»
CL_TSiHot
Teilobjektdiagramm ---->
Strukturierung der Software
«1-Class»
CL_TSiWu
«1-Class»
CL_TSiWtr
«1-Class»
CL_TSiStgo
Die Objekte werden im UML-Klassendiagramm
festgelegt. Im vorliegenden
Beispiel handelt es sich um eine
Klasse, sodass die Objekte nicht explizit
ausgewiesen werden. Klassendiagramme
sind das zentrale UML-
Element des OMOS-Konzepts.
Die Konfiguration der Software erfolgt
im Konfigurationseditor. Er legt fest,
von welcher Klasse die Objekte instantiiert
werden und definiert die Zugehörigkeit
der Klassen zu einem (Kunden-)
Projekt.
Transformation
des Ergebnisses
des Grobdesigns/
Formulierung der
Transferregeln
«1-Class»
CL_TSiStgo
«1-Class»
CL_TSiStgo_Bas
-bActv : bool
-sDet: uint8
-bDwnShft21: bool
-ctDwnShft21: uint8
-swtPlrTab_C: bool
-tTraMax_C: uint8
-rAccPedCst_C: uint8
-drAccPedRngB_C:
sint16
-rAccPedRngA_C: uint8
-rAccPedRngB_C: uint8
-nTosRngA_C: uint16
-nTosRngB_C: uint16
-ctDwnShft21_C: uint8
+CalcSituation()
+Is_bActv() : bool
«1-Class»
CL_TloTra
«1-Class»
CL_TloTcp
«1-Class»
CL_TloPed
«1-Class»
CL_TloW
Vererbungsdiagramm ---->
Darstellung von Varianten.
Die Klasse CL_TSiStgo_Bas
kann wegkonfiguriert
werden.
In dieser ersten Phase werden die
Grundlagen für die spätere Erweiterbarkeit
und Varianz der Software gelegt.
Der Entwickler wird besonders
durch folgende Eigenschaften unterstützt:
• grafische Beschreibung
• Mechanismen für variantenreiche
Software (Reuse, Projektausprägungen)
Direkte Auswirkung auf Feindesign/
Implementierung hat ausschließlich
das Klassendiagramm. Alle übrigen
Diagrammtypen haben lediglich beschreibenden
und damit ergänzenden
Charakter (z. B. Sequenz-, State-,
Activity-Diagramme).
Transformation des Grobdesigns
zur Implementierung
Für Softwareteile, die sich nur bedingt
für eine grafische Programmierung
eignen (z. B. das Speichermanagement
eines Steuergeräts mit seinem
hohen Anteil an Tabellen und Verzeigerungen),
steht eine C-Coderahmengenerierung
zur Verfügung (siehe
OMOS). Die C-Coderahmen erhalten
automatisch alle wesentlichen
UML-Modellinformationen (z. B. Messund
Applikationsgrößen aus Attributen,
Include-Anweisungen aufgrund
von Kommunikationsbeziehungen, Programmrümpfe
für Methoden). Das
Implementieren der Funktionalität in
den Programmrümpfen erfolgt dann
in einem Standard C-Code-Editor (z. B.
CodeWright). Auf die Coderahmengenerierung
wird nicht weiter eingegangen.
Bei allen anderen Softwareteilen wird
ein grafisches Entwicklungstool mit
Autocodegenerierung eingesetzt. Die
Effizienz und Qualität der Software-
Entwicklung wird dadurch noch einmal
gesteigert. Die Getriebesteuerung
setzt ASCET ein.
Das Tool aquintos.M2M zur Modelltransformation
von UML nach ASCET
bietet die Möglichkeit, Regeln für die
Transformation zu spezifizieren.
Aktuell entwickelt die Getriebesteuerung
eine Abbildung der UML-/
OMOS-Modelle nach ASCET V5.1. Die
Abbildung benutzt derzeit nur Module
in ASCET, da zum Zeitpunkt der
Pilotphase eine durchgängige Verwendung
von Klassen in ASCET nicht möglich
war. Ursache war ein internes Tool
zur Verwaltung von Mess- und Applikationsgrößen,
auf das hier nicht
weiter eingegangen wird.
Die erste Version ist als Prototyp ausgelegt,
um Erfahrungen im Entwicklungsprozess
zu sammeln. Zukünftig
werden die Transformationsregeln
auch auf ASCET-Klassen ausgeweitet
werden.
Das Bild 3 zeigt eine Transformation
mit M2M. Die ASCET-Modellierung
erfolgt in Modulen.
Für die Klassen der UML-Modelle
wurden Abbildungsregeln unter Berücksichtigung
des OMOS-Konzepts
definiert. Die Aggregationen, die
Kommunikationsbeziehungen und die
Vererbungsbeziehungen werden abgebildet.
■➔
25
2007.1 RT

Bild 3:
Transformation
mit M2M
von aquintos.
Bild 4:
Auszug aus der
Architektur/
Grobdesign des
Softwareteils
Gangauswahl.
26
RT 1.2007
«1-Class»
CL_FZGG
«1-Class»
CL_FZGG_KOMP
«1-Class»
CL_TDpDyn
«1-Class»
CL_TDpDyn_Bas
-idRdoAct : uint8
+GetGearReq( xGear:uint8 ) : uint8
TDpDynDUsp
TDpDynUsp
TDpDynDsp
«N-Class»
CL_TDpDynTab
-idAct : uint8
-xCtlTab_C : uint8
«1-Class»
CL_SIWA
«1-Class»
CL_SIWA_CUST
Ameos
«RAM_Groesse» -FWA : uint8
«RAM_Groesse» -CMO : uint8
«Kennwert» -HDK : uint8
«Kennwert» -CMOMIN : uint8
«Kennlinie» -ECMO : uint16
+IstWarmlauf( uint8 )
+IstWaBew( uint8 )
+ErmittleWarmlauf()
+DetermineWarmUp()
+ExitCondition( uint8 )
ASCET
+IsActive( idSp:uint8 ) : bool
+Reset()
«1-Class»
CL_MOT_LL
«1-Class»
CL_FSIT
XMI-Interface
COM API
«1-Class»
CL_MOT
«1-Class»
CL_MOT_AHK
«1-Class»
CL_MOT_ERW
«1-Class»
CL_FSIT_DEV
«1-Class»
CL_TloTra
«1-Class»
CL_TRcAdm
Die Implementierung mit ASCET erfolgt
in mehreren sinnvollen Teilumfängen
des UML-Modells (Auswahl einzelner
Klassen). Die ausgewählten Klassen
werden als „Reference Classes“
bezeichnet und im UML-Modell entsprechend
markiert.
Da in ASCET keine Vererbung bekannt
ist, gilt bei Vererbungsbeziehungen
z. B. die Regel: „Gehe durch den Vererbungsbaum
der „Reference Class“
zur so genannten Elternklasse und
sammle alle Attribute ein, die geerbt
werden.”
Anschließend werden sie nach ASCET
in die „Reference Class“ transferiert.
Mehrfachinstanziierungen
mit ASCET
Wie erwähnt, wird die Verwendung
von ASCET-Klassen bei der Transformation
noch nicht unterstützt. Damit
die Mehrfachinstanziierung (N-Klassen)
in ASCET verwendet werden
kann, wird an der Erweiterung der
Transformationsvorschrift gearbeitet.
Die Erweiterung wird anhand des folgenden
Klassendiagramms erläutert
(Bild 4). Das Diagramm beschreibt Zusammenhänge
zwischen Klassen und
definiert die Instanznamen sowie die
Anzahl der Instanzen.
Man erkennt die drei Instanzen der
Klasse CL_TDpDynTab und die Kommunikationsbeziehungen
zu den
Nachbarklassen. Die Mehrfachinstanziierung
muss in ASCET eine Entsprechung
finden, um das Feindesign und
die Implementierung vornehmen zu
können, siehe Bild 5.
In ASCET wird dafür die Klasse
CL_TDpDynTab angelegt. Die Methoden
und Attribute werden von dem
Klassendiagramm übernommen. Die
drei Instanzen der Klasse CL_TDpDyn-
Tab werden als lokale Attribute in
der Klasse CL_TDpDyn_Bas angelegt,
siehe Bild 6.
Feindesign, Implementierung und
automatische Codegenerierung
Das Feindesign und die Implementierung
wird mit der grafischen Programmierung
durchgeführt, eines der Kernelemente
von ASCET. Die Blockdiagrammrahmen
für die grafische Programmierung
werden durch die
Transformation vorgegeben. Bild 5
zeigt ein Beispiel für grafische Programmierung
im Blockdiagramm.
Die Implementierungsinformationen
für Mess- und Applikationsgrößen (Attribute)
werden in ASCET ergänzt. Damit
kann die automatische Codegenerierung
gestartet werden.
Für die Codegenerierung wird der
Standard-Codegenerator von ASCET
mit kundenspezifischen Anpassungen
eingesetzt. Der Codegenerator erzeugt
wohl definierten C-Code. In
der Getriebesteuerung wird für jede
Klasse ein C-File generiert, Optimierungen
für 1-Klassen werden durch
ASCET automatisch berücksichtigt.
Das ausführbare Programm (HEX-File)
wird außerhalb von ASCET mit der
Standard-Entwicklungsumgebung generiert.
Die Mess- und Applikationsgrößen
(Attribute) müssen über ein Applikationstool
messbar sein. ASCET generiert
zu den Modulen und Klassen
zugehörige Files nach dem MSRSW-
Standard. In dem Standard sind auch
Implementierungsinformationen für
C-Code enthalten, die die Generierung
von c- und h-files erlauben.
So werden die Mess- und Applikationsgrößen
im Anwenderprogramm
zur Verfügung gestellt, siehe Bild 7.
ASCET wird mit Codegenerierung in
mehreren Bereichen der Robert Bosch
GmbH erfolgreich eingesetzt.
Zusammenfassung
Der vorgestellte Entwicklungsprozess
gibt dem Entwickler die Möglichkeit,
seine Software von der Architektur
bis zur Implementierung grafisch zu
beschreiben. Das in der Automobilbranche
notwendige Variantenhandling
ist in dem Prozess integriert. Jede
Prozessphase besitzt ein optimales
Tooling. Die Informationen der einzelnen
Phasen sind fest miteinander verknüpft,
ein Auseinanderlaufen bzw.
Eigenleben der einzelnen Entwicklungsphasen
ist ausgeschlossen.
Komplexe Sachverhalte werden im
Design durch die grafische Notation
der UML eindeutig beschrieben.
ASCET ermöglicht es, auch die Funktionsentwicklung
auf grafischer Ebene
durchzuführen. Die grafische
Modellierung der Algorithmen stellt
gleichzeitig eine gute Dokumentation
dar. Durch den Entwicklungsprozess
werden Rekursionen vermieden und
die Entwicklungseffizienz deutlich gesteigert.
3 Instanzen
der Klasse CL_TDpDynTab
CL_TDpDynTab PAR_idTyp
PAR_idRdo IsActive
Usp
CL_TDpDynTab
PAR_idTyp
PAR_idRdo IsActive
DUsp
CL_TDpDynTab
PAR_idTyp
PAR_idRdo IsActive
Dsp
Bild 5:
Klasse
CL_TDpDynTab
in ASCET mit
Feindesign/
Implementierung.
Bild 6:
Lokale Instanzen
in der Klasse
CL_TDpDynTab.
Bild 7:
Auszug der von
ASCET generierten
Files für
den Build-
Prozess.
C-File MSRSW-File
27
2007.1 RT