Software-Entwicklung
Informationszentrale UML
Fortsetzung des Artikels von Teil 4
Zustandsautomaten: Ereignis- oder Nachrichten-getrieben
Die Schnittstellen der UML werden in C mit Hilfe von Funktions-Pointer realisiert. Für jede Interface-Operation wird ein Eintrag in einer Struktur generiert (Bild 6). Die implementierende Klasse initialisiert diese Struktur mit Pointer auf die eigenen Operationen. Ruft ein Client eine Funktion der Schnittstelle auf, wird über die Instanz entschieden, welche implementierende Klasse tatsächlich aufgerufen wird. Die Interfaces dienen gleichzeitig als abstrakte Klassen. Wird eine Operation im Interface implementiert, wird diese ausgeführt, statt einen Funktions-Pointer zu generieren.
Jobangebote+ passend zum Thema
Wem dieses Konzept, aus welchen Gründen auch immer, nicht gefällt, braucht es nicht zu verwenden. Dies gilt im Übrigen auch für alle anderen Mechanismen. Wenn man aber eine vergleichbare Funktion benötigt und diese von Hand implementiert, wird sie garantiert nicht besser sein.
Einer der mächtigsten Mechanismen in Bezug auf Code-Generierung in der UML sind Zustandsdiagramme. Mit diesen kann Verhalten grafisch dargestellt und beschrieben werden. Der generierte Code ist immer gleich und fehlerfrei.
State Machines funktionieren Ereignis- oder Nachrichten-getrieben. Für den Empfang von Nachrichten wird eine Message Queue benötigt. Zu einem späteren Zeitpunkt werden die Nachrichten aus der Queue geholt und verarbeitet. Für diese und weitere Mechanismen, wie aktive Klassen (Tasks), Speicher-Management oder Timer-Management, stellen einige UML-Tools fertige Frameworks zur Verfügung. Diese Frameworks haben eine Abstraktionsschicht, um den Code an die Hardware anzupassen. So kann man entweder seine eigene Laufzeit-Umgebung bauen oder sich in ein bestehendes Betriebssystem einhängen. Für Anpassungen an die Hardware bzw. das Betriebssystem wird im einfachsten Fall ein Timer-Impuls benötigt, mit dessen Hilfe das Timer-Management bedient werden kann, um so die Timeout-Funktion in Zustandsdiagrammen anzustoßen. Kritische Aktionen, wie das Hinzufügen einer neuen Nachricht in die Message Queue, müssen beispielsweise über Semaphore vor anderen Prozessen geschützt werden. Manche Betriebssysteme bieten bereits Message Queues an. Auch für das Speicher-Management haben verschiedene Betriebssysteme bereits bestehende Mechanismen, die verwendet werden sollten. Wem diese Anpassungen zu viel Aufwand verursachen oder zu riskant sind, der kann sich an spezialisierte Anbieter wenden, die bereits Anpassungen für viele Betriebssysteme vorgenommen haben.
Synchrone State Machines sind riskant, weil man damit schnell einen Deadlock produzieren kann. Daher werden sie in der Regel nicht angeboten. Dennoch kann es manchmal sinnvoll sein, eine synchrone State Machine zu verwenden. Erstens spart man Speicher, zweitens kann die Code-Generierung von Zustandsdiagrammen verwendet werden, ohne ein Framework einzusetzen, und drittens werden damit Betriebssysteme wie OSEK unterstützt. So flexibel, wie einige UML-Tools sind, lässt sich das leicht realisieren, indem man anstelle des Framework selbst modellierte Klassen einsetzt. Ohne zu berücksichtigen, dass sich das Systemverhalten zwischen synchron und asynchron ändert, kann das gleiche Diagramm einfach umgeschaltet werden. Somit lassen sich innerhalb des gleichen UML-Projektes gleichzeitig synchrone und asynchrone State Machines verwenden.
Keine Angst vor generiertem Code
Die Möglichkeiten der Code-Generierung in der UML sind so mächtig und flexibel, dass man alle Anforderungen an den generierten Code erfüllen kann. Die alten Vorurteile über unleserlichen, ineffizienten, speicherfressenden Code entbehren jedweder Grundlage. U.a ergeben sich folgende Vorteile für die Verwendung der UML:
- gemeinsame Datenbasis für die gesamte Entwicklung,
- Unterstützung der Software-Kapselung,
- Verwendung objektorientierter Ansätze auch in C,
- Synchronisation von Modell, Code, Test und Dokumentation,
- Wiederverwendung von Modell, Code, Test und Dokumentation,
- Nachverfolgbarkeit von Anforderungen und Tests,
- Unterstützung testgetriebener Entwicklung,
- beliebige Verwendung der Möglichkeiten,
- Rapid Prototyping durch Simulation auf Modellebene,
- einheitliche Struktur für generierten Code (z.B. Statemachines) und vieles mehr.
Selbstverständlich gibt es auch einige Nachteile:
- Enormer Bedarf an Schulungen und Coaching nötig.
- Geänderte Arbeitsweise gegenüber dem Gewohnten (starkes Umdenken nötig).
- Bestehender Code kann oft nur schwer abgebildet werden (Varianten-Handling über Präprozessor-Anweisungen).
Literatur
- http://www-01.ibm.com/software/awdtools/rhapsody/
- http://www.ibm.com/developerworks/downloads/r/rhapsodydeveloper/
- http://www-142.ibm.com/software/products/de/de/ratirhap/
- http://www.willert.de/
- Balzert, H.: UML 2 in 5 Tagen: Der schnelle Einstieg in die Objektorientierung, 2. Auflage, Dortmund 2008.
- Rupp, C.; Queins, S.; Zengler, B.: UML 2 glasklar: Praxiswissen für die UML-Modellierung, 3. Auflage, München 2007.
- Oestereich, B.: Objektorientierte Softwareentwicklung. Analyse und Design mit UML 2.1, aktualisierte Auflage; München, 2006.
- Douglass, B. P.: Real Time UML: Advances in the UML for Real-Time Systems, 3. Auflage, Oxford, 2004.
- Douglass, B. P.: Real Design Patterns for Embedded Systems in C: An Embedded Software Engineering Toolkit, 1. Auflage, Oxford, 2010.
Der Autor
Alexander Schneider Nach dem Abitur hat Alexander Schneider zunächst eine Ausbildung zum Kommunikationselektroniker gemacht. Im Anschluss an seine Ausbildung studierte er Informatik, um dann sowohl Backend-Server-Software wie auch Applikations-Software zu entwickeln. Seit 2007 ist er in der Automotive-Branche als Experte für UML-Design tätig, arbeitet aktiv in Projekten mit und schult die Mitarbeiter in der Verwendung der UML.
- Informationszentrale UML
- Bild von außen: die Architektur
- Implementierung: bis ins Detail
- Code-Generierung: so gut wie handgeschrieben
- Zustandsautomaten: Ereignis- oder Nachrichten-getrieben
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Blick ins Zielsystem
UML-Modelle debuggen
Modellierung von E/E-Systemen
UML und AUTOSAR
Modellbasierte und textuelle Systemdokumentation
UML - mehr als nur Bilder
