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

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

RTI Real-Time Innovations

MicroConsult Microelectronics Consulting & Training GmbH

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.

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.

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.

(ID:42242548)