Mobile-Menu

Modellierung

Objektorientierung und modellbasierte Werkzeuge

Seite: 5/5

Anbieter zum Thema

Linutronix GmbH
Parasoft® Deutschland GmbH

Voraussetzungen

Die Erfahrung zeigt, dass für ein effizientes Arbeiten mit Rhapsody frühzeitig die richtigen Voraussetzungen zu schaffen sind. Aus unserer Sicht sind folgende Punkte besonders wichtig:

  • Für die projektspezifischen Einstellungen sollte von Beginn an ein Profil angelegt und durchgängig referenziert werden (Bild 5). Da es am Anfang aufgrund fehlender Erfahrung meist noch unklar ist, welche Property-Einstellungen wie zu setzen ist, lassen sich auf diese Art und Weise ansonsten weitreichende nachträgliche Änderungen relativ einfach einbringen.
  • Bestimmte Property-Einstellungen sollten an Stereotypes gebunden werden. Sie sind dann deutlich im Modell erkennbar und können einheitlich gehandhabt werden. Beispiele: SimpleType (für enums, die im Allgemeinen per Value übergeben werden sollen), Volatile (setzt das Property C_CG::Attribute::PreDeclarationModifier zu “volatile” und sollte für volatile Attribute verwendet werden), PackedT (setzt des Property C_CG::Type::PreDeclarationModifier zu “__packed” und sollte für gepackte Strukturen verwendet werden)
  • Packages sollten großzügig verwendet werden um die Zusammenarbeit mehrerer Entwickler zu erleichtern. Diese Packages können dann in den jeweiligen Entwickler-Projekten referenziert werden. Packages werden standardmäßig als eigene Unit in einem separaten File gespeichert.
  • Es ist vorteilhaft ein „Helper“-Package mit allgemeingültigen Typen und Algorithmen (z.B. CRC) ganz unten im Layering zu definieren, das für alle darüber liegenden Layern wiederverwendbar ist. Das hatten wir – abgesehen von den üblichen Integer-Daten-Typen – nicht gemacht. Dies später nachzuholen, ist nur noch mit viel Aufwand realisierbar.

Unabhängig von der konkreten Entwicklungsmethodik ist ein gutes Grundverständnis der Domänen-spezifischen Probleme immer ein wesentlicher Erfolgsfaktor. In diesem Falle ist es z.B. das Verständnis der treibenden Aktivitäten und die Zuordnung in den zeitgetriebenen Interrupt-Kontext oder den ereignisgetriebenen Task-Kontext.

Durch den abstrakteren, modellhaften Ansatz muss von den beteiligten Entwicklern noch mehr entsprechendes Wissen abverlangt werden. Man darf sich bei der Methodik nicht gleich in die Bits und Bytes flüchten, und im Nachhinein schauen wie man alles zusammenfügt.

Der Vorteil von entsprechenden Modellierungs- und Codier-Richtlinien muss sicherlich nicht extra hervorgehoben werden.

Ergebnisse

Die bisherigen Ergebnisse müssen differenziert betrachtet werden. Aus Sicht des Architekten erlaubt die Modellbasierte Arbeit einen zügigen Übergang von der Architektur bis in die Implementierung. Insbesondere bleiben durch die expliziten Notationen die Grundentscheidungen der Architektur stets im Blick.

Für die Entwickler stellt der Wechsel auf OO und Rhapsody eine erhebliche Umstellung ihrer Arbeitsweise dar. Statt in C-Files und sehr ausgefeilten C-Editoren entsteht der Code im Editor von Rhapsody. Änderungen in den C-Files während des Tests müssen sorgfältig zurück gepflegt werden. Nicht unterschätzt werden darf auch der Paradigmenwechsel von einer Main-Loop auf eine Event-basierte Systemarchitektur.

Aus Sicht des Projektverantwortlichem bestand die größte Herausforderung in der Suche nach geeigneten Partnern. Der Umstieg auf einen OO-Entwurf gelingt nicht aus dem Stand. Rhapsody stellt ein sehr mächtiges Werkzeug dar, mit eher überschaubarer Dokumentation. Trotz eines vorgelagerten Evaluationsprojekts und begleitender Schulungen wäre das Projekt diesen Umfangs und Neuigkeitsgrades ohne die erfahrenen Partner nicht in der ohnehin knappen Vorgabezeit zu bewältigen gewesen.

Kritisch anzumerken bleibt, dass ein erheblicher Teil der Zeit – typisch für Embedded-Systeme – in die Entwicklung von Middleware-Schichten geflossen ist. Diese weisen dadurch zwar ebenso wie die Applikation eine klare Struktur auf, dienen aber nicht zur Produktdifferenzierung. Hilfreich wären hier künftig ggf. stärker standardisierte Middlewarepakete, die aber sicher Branchen- bzw. Anwendungstypisch ausgeführt sein müssten.

Literatur- und Quellenverzeichnis

[1] A. Wagener, Ch. Körner, P. Seger, H. Kabza, Anpassung eines Embedded Target für verteilte Steuer- und Regelungsaufgaben an den RTW von Matlab/Simulink, Embedded Intelligence 2001, Nürnberg

[2] U. Lefarth, T. Beck, Qualitäts- und Effizienzsteigerung bei der Entwicklung von Steuergeräte-Software, 3. Stuttgarter Symposium Kraftfahrwesen und Verbrennungsmotoren, 1999, Stuttgart.

[3] Dr. Gary Morgang, AUTOSAR – ein Projekt zur Entwicklung von Steuergeräte-Software, Elektronik automotive 1/2006

* Dr. Andreas Wagener leitet die Entwicklung von Motoransteuerungen bei der Dr. Fritz Faulhaber GmbH in Schönaich.

* Robert Stemplinger arbeitet als Software Entwickler bei der b1 Engineering Solutions GmbH in München.

* Markus Pauls ist als Software Architekt bei der b1 Engineering Solutions GmbH in München tätig.

(ID:44055654)

Weiterführende Inhalte