UML Target Animation

Das Projekt ?UML Target Animation“ befasst sich mit der Softwareentwicklung für technische Systeme mit begrenzten Ressourcen, so genanntes Embedded Software Engineering. Dieses unterscheidet sich grunds?tzlich von der Entwicklung für Anwendungs-Software im gew?hnlichen IT Bereich. Die wichtigsten Unterschiede sind eingeschr?nkte Ressourcen in Bezug auf Speicher und Rechenleistung, deterministische Reaktionszeiten (Echtzeitverhalten) sowie Anforderungen an geringen Energieverbrauch.

Auf Grund der obigen Anforderungen ist die derzeit übliche Notation zur Entwicklung der Embedded Software ANSI-C. Jedoch steigen auch im Bereich der Embedded Software die Anforderungen und die Komplexit?t der zu entwickelnden Software stetig an.

Daher geht man zunehmend dazu über, Software für technische Systeme mit der grafischen Modellierungssprache UML zu designen, um die Modelle übersichtlicher und damit auch verst?ndlicher für andere Entwickler und Au?enstehende zu machen. Aus dem Modell heraus wird dann automatisiert C-Code für das Embedded System generiert. Entsprechende Tools zur Entwicklung in UML für Embedded Systeme existieren z. B. mit IBM Rational Rhapsody + Willert Embedded UML Studio bereits. Genau wie im Bereich der High-Level-Programmierung muss aber auch hier beachtet werden, dass UML-Modelle und der daraus generierte Code trotz der vereinfachten Design-M?glichkeiten oftmals nicht sofort fehlerfrei in ihrem Verhalten sind. Die Ursache eines solchen Fehlverhaltens kann mit Hilfe so genannter Debugging-Werkzeuge analysiert werden.

Da die Entwicklung mit Hilfe der UML geschieht, ist es sinnvoll auch das Debugging und vor allem den Test von Applikationen auf der Design-Level-Ebene durchzuführen. Hier setzt das Projekt ?UML Target Animation“ an. Bisherige L?sungen erzeugen gro?e Mengen an instrumentiertem Code. Die oben angesprochenen Anforderungen bezüglich Echtzeitverhalten und beschr?nkten Ressourcen werden verletzt. Entwickelt werden soll also ein Verfahren, bei dem m?glichst wenig instrumentierter Code erzeugt wird und keine Beeinflussung des Laufzeitverhaltens erfolgt. Damit k?nnen auch Test- und Ausliefercode identisch sein, so dass gew?hrleistet ist, dass das getestete System auch dem ausgeliefertem entspricht. Dieses ist speziell in Hinblick auf sicherheitskritische Anwendungen ein wesentliches Kriterium für die Akzeptanz der Debug-L?sung beim Kunden.

Projektpartner