Informationstransfer von UML nach ASCET

Bild 1:
Phasen in der
SoftwareEntwicklung.
Ameos
Architektur des SW-Systems
Architektur/Grobdesign
eines SW-Teils (Subsystems)
Von Marcel
Hachmeister,
Robert Bosch
GmbH
Informationstransfer von UML
nach ASCET
Transformation
des Ergebnisses
des Grobdesigns /
Formulierung der
Transferregeln
Feindesign
eines SW-Teils (Subsystems)
ASCET
Editor
Jede Entwicklungsphase wird
unterstützt: Von der Software-Architektur
Implementierung & Codegenerierung
eines SW-Teils (Subsystems)
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.
Bild 2:
UML-Klassendiagramm.
«1-Class»
CL_TSiStgo
«1-Class»
CL_TSi_Bas
«1-Class»
CL_TSiStgo_Bas
D
ie immer umfangreicher und
komplexer werdenden SoftwareUmfä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 SoftwareEntwicklung 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 UMLBeschreibungselemente 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.
«1-Class»
CL_TSiCnr
«1-Class»
CL_TSiWu
«1-Class»
CL_TSiDhl
«1-Class»
CL_TSiWtr
«1-Class»
CL_TSiFo
«1-Class»
CL_TSiHil
«1-Class»
CL_TSiHot
«1-Class»
CL_TSiStgo
Teilobjektdiagramm --->
Strukturierung der Software
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 UMLElement 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.
-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
«1-Class»
CL_TloTra
«1-Class»
CL_TloTcp
«1-Class»
CL_TloPed
«1-Class»
CL_TloW
+CalcSituation()
+Is_bActv() : bool
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 SoftwareEntwicklung 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.
➔
■
24
RT 1. 2007
25
2 0 0 7 .1 RT
Bild 3:
Ameos
Transformation
mit M2M
«1-Class»
CL_SIWA
von aquintos.
«1-Class»
CL_FZGG
«1-Class»
CL_FZGG_KOMP
«1-Class»
CL_FSIT
«1-Class»
CL_SIWA_CUST
«RAM_Groesse»
«RAM_Groesse»
«Kennwert»
«Kennwert»
«Kennlinie»
-FWA : uint8
-CMO : uint8
-HDK : uint8
-CMOMIN : uint8
-ECMO : uint16
«1-Class»
CL_FSIT_DEV
«1-Class»
CL_MOT
+IstWarmlauf( uint8 )
+IstWaBew( uint8 )
+ErmittleWarmlauf()
+DetermineWarmUp()
+ExitCondition( uint8 )
«1-Class»
CL_MOT_AHK
«1-Class»
CL_MOT_LL
«1-Class»
CL_MOT_ERW
XMI-Interface
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.
COM API
ASCET
Bild 4:
Auszug aus der
Architektur/
Grobdesign des
Softwareteils
Gangauswahl.
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.
«1-Class»
CL_TDpDyn
«1-Class»
CL_TDpDyn_Bas
«1-Class»
CL_TloTra
-idRdoAct : uint8
+GetGearReq( xGear:uint8 ) : uint8
TDpDynDUsp
TDpDynUsp
TDpDynDsp
«N-Class»
CL_TDpDynTab
-idAct : uint8
-xCtlTab_C : uint8
+IsActive( idSp:uint8 ) : bool
+Reset()
26
RT 1. 2007
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.
«1-Class»
CL_TRcAdm
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_TDpDynTab 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.
Bild 5:
Klasse
CL_TDpDynTab
in ASCET mit
Feindesign/
Implementierung.
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.
3 Instanzen
der Klasse
CL_TDpDynTab
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 MSRSWStandard. 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.
CL_TDpDynTab
PAR_idTyp
PAR_idRdo IsActive
Usp
CL_TDpDynTab
PAR_idTyp
PAR_idRdo IsActive
Bild 6:
Lokale Instanzen
in der Klasse
CL_TDpDynTab.
DUsp
CL_TDpDynTab
PAR_idTyp
PAR_idRdo IsActive
Dsp
Bild 7:
Auszug der von
ASCET generierten Files für
den BuildProzess.
C-File
MSRSW-File
27
2 0 0 7 .1 RT