Systemdesign Software-Engineering mit UML und C im Einsatz für Embedded-Systeme

Autor / Redakteur: Thomas Batt * / Franz Graser

Programmierung für Embedded-Systeme und UML – widerspricht sich das nicht? Vor allem, wenn man in C arbeitet? Nein, denn die UML ist bestens für Implementierungszwecke geeignet.

Anbieter zum Thema

Die Modellierung von Softwarearchitekturen dringt auch in die Embedded-Domäne ein. Sie funktioniert selbst, wenn man in C arbeitet.
Die Modellierung von Softwarearchitekturen dringt auch in die Embedded-Domäne ein. Sie funktioniert selbst, wenn man in C arbeitet.
(Bild: Fotolia)

Einer der ersten Schritte zur Definition der Software-Architektur ist die Identifikation der Software-Schichten. Je nach Komplexität der Embedded-Applikation sind es zumindest zwei. Eine typische Zwei-Schichten-Architektur besteht aus Applikation und Hardware-Treiber. Mit steigender Komplexität entsteht zum Beispiel eine 7-Schichten-Architektur aus Mensch-Maschine-Interface, Applikation, Middleware, Betriebssystem-Abstraktion, Betriebssystem, Hardware-Abstraktion und Hardware-Treiber.

Bild 1: UML-Darstellung von Software-Schichten im Paket- oder Klassendiagramm
Bild 1: UML-Darstellung von Software-Schichten im Paket- oder Klassendiagramm
(Grafik: MicroConsult)

Software-Schichten sind mit der UML-Notation als Pakete, mit einem aussagekräftigen Namen und dem Stereotype <<Software_Layer>> modellierbar. Die Abhängigkeit zwischen den Software-Schichten ist durch die Dependency Relation darstellbar. Diese Dependency Relation repräsentiert auf der späteren C-Modulebene mindestens ein include aus Schichtname_2 in Schichtname_1. Software-Schichten könnten sich als Präfix oder Postfix im C-Modulnamen abbilden. Klassischerweise repräsentiert sich eine Software-Schicht lediglich in der Programmcode-Organisation durch ein Verzeichnis, in dem die entsprechenden Inhalte der Software-Schicht gespeichert sind.

Lässt sich eine Software-Schicht noch weiter strukturieren, ohne die C-Modulebene zu erreichen, kann dies durch Software-Subsysteme erfolgen. Erst die Subsysteme enthalten die C-Module. In vielen einfachen Architekturen existiert diese Strukturebene nicht. In Architekturen, in denen Software-Subsysteme existieren, müssen diese zusammen mit ihren Abhängigkeiten identifiziert und den Software-Schichten zugeordnet werden.

Mischformen sind natürlich auch denkbar. Das heißt, es existieren Software-Schichten mit und ohne Software-Subsysteme. Software-Subsysteme sind mit der UML-Notation als Pakete mit einem aussagekräftigen Namen und dem Stereotyp <<Software_Subsystem>> modellierbar. Die Abhängigkeit zwischen den Software-Subsystemen ist durch die Dependency Relation darstellbar. Diese Dependency Relation repräsentiert auf der späteren C-Modulebene mindestens ein include aus Subsystem_2 in Subsystem_1.

Bild 2: UML-Darstellung von Software-Subsystemen
Bild 2: UML-Darstellung von Software-Subsystemen
(Grafik: MicroConsult)

Software-Subsysteme könnten sich als Präfix oder Postfix im C-Modulnamen abbilden. Klassisch repräsentiert sich ein Software-Subsystem lediglich in der Programmcode-Organisation durch ein Verzeichnis, in dem die entsprechenden Inhalte des Software-Subsystems gespeichert sind.

Was eine Software-Schicht oder ein Software-Subsystem einer anderen Software-Schicht oder einem anderen Software-Subsystem an Funktionalitäten anbietet, sind Software-Schnittstellen. Die UML definiert dafür die Interface-Klasse. Sie unterscheidet sich von der vollwertigen Klassennotation durch den zusätzlichen Stereotyp <<Interface>> und das fehlende Feld für die Attribute / Daten.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

(ID:42242548)