Suchen

Systemdesign

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

Seite: 2/2

Firmen zum Thema

Schnittstellen zwischen den Schichten und Subsystemen

Eine Schnittstelle wird in C durch eine C-Header-Datei repräsentiert. Da diese neben den Deklarationen der Operationen / Funktionen auch Deklarationen von Daten enthalten kann, ist die C-Header-Datei besser durch eine vollwertige Klassennotation mit Attributen und Operationen modellierbar. Die Klasse sollte durch den Stereotyp <<Interface>> und den Stereotyp <<C-Header>> gekennzeichnet werden.

Bild 3: UML-Darstellung von Software-Schnittstellen
Bild 3: UML-Darstellung von Software-Schnittstellen
(Grafik: MicroConsult)

Zusätzlich zum Namen enthalten die Datendeklarationen optional den Datentyp. Ergänzend zum aussagekräftigen Operationsnamen enthalten die Operationsdeklarationen optional den Return-Datentyp und die Parameter bestehend aus Namen und Datentyp. Die Dependency Relation, ausgehend von der Kante eines Paketes (Software-Schicht oder Software-Subsystem), endet nun an der Kante der Schnittstellenklasse und nicht mehr an der Kante des anderen Paketes.

Ausgehend von der bis hierher erstellten Software-Architektur müssen nun konkrete C-Module identifiziert werden. Dabei ist zu beachten, dass jede Software-Schnittstelle eine Implementierung in einem entsprechenden C-Modul enthält und jede Software-Schnittstelle von anderen Softwareelementen mindestens einmal genutzt wird. Das C-Modul ist mit der UML über eine vollwertige Klasse notierbar. Diese Klasse bekommt den Stereotyp <<C-Module>> zugeordnet.

C-Module und ihre Abhängigkeiten

Der Implementierungspfad einer Software-Schnittstelle in einem C-Modul wird durch die Interface- bzw. Realisierungsrelation dargestellt. Der Nutzungspfad einer Software-Schnittstelle oder einer beliebigen anderen C-Header-Datei wird mit der Dependency Relation und dem zusätzlichen Stereotyp <<use>> dargestellt. Beide Relationen repräsentieren im C-Code das #include.

Bild 4: Zusammenhänge werden transparent. UML-Darstellung von modularen Abhängigkeiten
Bild 4: Zusammenhänge werden transparent. UML-Darstellung von modularen Abhängigkeiten
(Grafik: MicroConsult)

Die vorangegangene Modellierung der Software-Struktur muss nun noch um die Software-Abläufe ergänzt werden. Diese Abläufe sind klassischerweise in C-Funktionen gekapselt. Zur Modellierung generischer Software-Abläufe bietet die UML das Aktivitätsdiagramm und das Zustandsfolgediagramm an. Für Abläufe, die wenig ereignisgesteuert und mehr datenflussorientiert sind, ist das Aktivitätsdiagramm die Notation der Wahl. Für Abläufe, die mehr ereignisgetriebenen sind, ist das Zustandsfolgediagramm zu bevorzugen,das hier aber nicht besprochen wird. Beide Diagrammarten enthalten viele Detailnotationen, um auch komplexere Sachverhalte modellieren zu können.

Um Abläufe zu programmieren, bieten sich C-Kontrollkonstrukte wie switch-case und/oder if-else an. Optional lassen sich auch Funktionszeiger nutzen.

Bild 5: Ein Ablaufdiagramm. Die UML-Darstellung von Software-Abläufen ähnelt einem Flussdiagramm.
Bild 5: Ein Ablaufdiagramm. Die UML-Darstellung von Software-Abläufen ähnelt einem Flussdiagramm.
(Grafik: MicroConsult)

Die zentrale C-Funktion main() kann wie eine spezielle Funktion in einem speziellen C-Modul betrachtet werden. Mit der UML modelliert ist main() eine Funktion in der Klasse, die das C-Modul der Hauptapplikation repräsentiert. In Ergänzung zum Stereotyp <<C-Module>> kennzeichnet sich diese Klasse durch <<Main-Application>>. Alle inkludierten Elemente werden mit der Dependency Relation zusammen mit dem Stereotype <<use>> abgebildet. Enthält die main() -Funktion einen Ablauf, ist dieser durch ein Aktivitätsdiagramm oder einen Zustandsfolgediagramm modellierbar.

Zusammenfassung und weitere Tipps

Nun haben Sie eine Vorstellung zum Einsatz der UML-Diagramme für eine kleine Embedded- und Echtzeitapplikation in Verbindung mit der Sprache C bekommen. Dafür gibt es mit der UML viele Umsetzungsvarianten. Egal welchen Weg Sie wählen – es ist wichtig, dass dieser Weg gemeinsam für ein Projekt oder noch besser gemeinsam im Unternehmen gegangen wird. Sie arbeiten heute nach C-Codierrichtlinien, so sollte es zukünftig auch UML-Modellierungsrichtlinien geben. Da die Modellierung mit Papier und Stift sehr mühsam ist, sollten Sie sich dafür ein Tool anschaffen.

Bild 6: UML-Darstellung der main()-Funktion
Bild 6: UML-Darstellung der main()-Funktion
(Grafik: MicroConsult)

Für den hier dargestellten Sachverhalt steht online ein Download bereit, der eine kleine Applikation für den ASURO-Roboter enthält. Sie ist als UML-Modell und als ANSI-C Programm enthalten. Da die Applikation sehr klein ist, enthält sie keine Software-Subsysteme. Sonst sind alle besprochenen Elemente enthalten. //FG

* Thomas Batt verantwortet bei MicroConsult als Trainer die Themen Software Engineering für Embedded-Systeme sowie Entwicklungsprozess-Beratung..

(ID:42242548)