Die automische Code-Generierung klingt für mich erstmals sehr vielversprechend. Der Begriff suggeriert, dass ich als Entwickler viel weniger Arbeit habe! Im Folgenden berichte ich über meine Erfahrungen mit automatischer Code-Generierung im medizintechnischen Umfeld.

Worum geht es?

Mittels CASE-Tools (Computer Aided Software Engineering) wird aus einem Modell Code generiert. Weit verbreitet – gerade im Embedded-Umfeld – ist hierzu die grafische Notation UML (Unified Modeling Language). Ein Beispiel für ein CASE-Tool ist Rational Rhapsody von IBM. Mit diesem oder ähnlichen Tools, wird die Architektur bzw. das Design der Software grafisch dargestellt. Dabei können verschiedene Abstraktionsstufen dargestellt und verfeinert werden. Das CASE-Tool kann auch lediglich den Rumpf der Software erstellen. Dies erspart einem das oft fehleranfällige Erstellen von “boilerplate code”. Die Logik wird dann in einem herkömmlichen Editor (kann im CASE-Tool integriert sein) implementiert. Rhapsody beispielsweise lässt es auch zu, dass man die Logik grafisch entwirft. Hierzu werden weitere UML-Diagrammtypen, wie etwa Sequenzdiagramme, genutzt.

Die Vorteile eines ganzheitlichen Modells liegen auf der Hand:

• Der Production Code lässt sich direkt aus dem Modell erzeugen
• Das Modell liefert verschiedene Sichtweisen und Abstraktionsstufen
• Es kann jederzeit eine aktuelle Dokumentation erzeugt werden

Im regulatorischen Umfeld

Der Systementwurf wird mit einem Modell […] auf einer höheren Abstraktionsebene beschrieben als der herkömmlich ausführbare Code. […] Das Ziel ist, die Softwarequalität durch Beseitigung der fehleranfälligen manuellen Aufgaben beim Codieren zu verbessern.

Die nahtlose Nutzung von Modellen erleichtert eine sehr konsistente und effiziente Entwicklung.

Erfahrungen

Im aktuellen Projekt wurde mittels Rhapsody ausführbarer Code erzeugt. Dabei wurde die Architektur und das Design der Software in Rhapsody mittels UML grafisch erfasst und verfeinert. Die Logik der Klassen wurde dann auf herkömmliche Weise im Rhapsody-Editor in C++ codiert.

Vorteile

• Die Verfeinerung der Architektur und des Designs mittels UML erleichtert das Verstehen komplexer Sachverhalte.
• Die Dokumentation lässt sich direkt aus dem Modell erstellen. Es entfällt das fehleranfällige und zeitintensive Nachpflegen der Dokumentation.
• Mittels automatischer Code-Generierung fällt das fehleranfällige Erstellen des Software-Rumpfes weg.
• Der Fokus ist viel stärker auf das Wesentliche gerichtet. Wiederholende Programmieraufgaben übernimmt das Tool.
• Namen (bspw. Typen) werden nach einer Umbenennung an allen Verwendungsorten automatisch angepasst. Allerdings gilt dies nicht für den “manuell erstellten” Code. Ein Beispiel für solchen Code ist die Implementierung der Operationen.

Herausforderungen

• Der Einstieg in das Tool fällt schwer und erfordert intensive Schulung.
• Es fallen hohe Lizenzkosten an.
• Die Einrichtung eines Projektes und die Anbindung an ein CI-Tool ist schwieriger als bei herkömmlichen Editoren.
• Gerade unerfahrenen Entwickler*innen fällt der Einstieg schwer. Neben guten Programmierkenntnissen, sind auch detaillierte Kenntnisse der UML erforderlich.
• Die Logik wurde weiterhin herkömmlich in Rhapsody codiert. Dies bringt viele Nachteile mit sich. Code completion wird im Rhapsody-Editor nur sehr eingeschränkt unterstützt. Auch das Look & Feel wirkt sehr altmodisch und bietet bspw. nur sehr eingeschränktes Syntax Highlighting.
• Die Eigenarten des Tools zu verstehen erfordert viel Geduld. Bisweilen müssen sie umgangen oder auch einfach ertragen werden.
• Es besteht eine Abhängigkeit zum “Übersetzer”-Tool. Als Beispiel sei hier das Willert Framework genannt. Dieses definiert, wie die grafische Notation in den Code überführt wird.

Fazit

Die modellgetriebene Software-Entwicklung bietet viele Vorteile:

• Einfacheres Verstehen komplexer Sachverhalte dank grafischer Notation
• Erzeugen der Dokumentation aus dem Modell
• Fokussieren auf die Logik der Software

Doch die Einarbeitung in UML und das Tool zur automatischen Code-Generierung ist nicht zu unterschätzen. Die hohen Lizenzkosten können ebenfalls abschreckend wirken. Der Code-Editor von Rhapsody ist nicht mehr auf dem neusten Stand. Gängige kostenlose Editoren bieten hier viel mehr – bspw. der Qt Creator wie in diesem Projekt.

Zusammenfassend werden viele Vorteile der automatischen Code-Generierung durch das herkömmliche Codieren der Logik zunichte gemacht. Auf diese Weise erscheint mir der Aufwand grösser als der Ertrag. Es empfiehlt sich hier zumindest die Möglichkeit des Code Roundtrip zu nutzen. Dabei erstellt Rhapsody den Rumpf der Software und das manuelle Codieren erfolgt in einem Editor nach Wahl. Rhapsody importiert diesen Code dann zurück, um das Modell konsistent zu halten. Auf diese Weise kann zumindest von den Vorzügen eines modernen Editors profitiert werden.

Titelbild: Foto von Brett Jordan von Pexels

Beim Schreiben von Software werden Fehler gemacht. Diese Fehler werden – wenn überhaupt – auf unterschiedlichste Art und Weise entdeckt. Ein Verfahren ist die statische Code-Analyse. Diese unterzieht den Code bestimmten formalen Prüfungen. Die zu prüfenden Regeln sind in der Coding Guideline festgehalten. Coding Guidelines sind in der Softwareentwicklung weit verbreitet – wobei ihr Reifegrad von gut bis nicht anwendbar reicht. Damit steht und fällt auch die Akzeptanz bei den Entwickler*innen. Doch auch gute Coding Guidelines stossen nicht immer auf Gegenliebe.

Coding Guideline als Last

Coding Guidelines können eine Last sein, bspw. wenn für deren Überprüfung kein geeignetes Tool verwendet wird. Im Optimalfall sollte es wie ein Rechtschreibeprogramm schon während der Eingabe mögliche Fehler markieren und Verbesserungsvorschläge anbieten. Es wird schnell klar, die eigentliche Last ist meistens die Prüfung auf Konformität mit der Coding Guideline.

Wenn das Tool beispielsweise den Arbeitsfluss unterbricht, wird es schnell an Akzeptanz verlieren. Das gleiche geschieht, wenn schon zu Beginn der Analyse eine Flut von möglichen Defekten angezeigt wird und keine Filtermöglichkeiten bestehen. Im schlechtesten Fall enthält die Coding Guideline viele nicht automatisiert überprüfbare Regeln, die keinem Standard-Regelwerk entsprechen.

Coding Guideline als Nachbrenner

Eine einfache und kurzzyklische Prüfung auf Konformität mit der Coding Guideline wirkt sich sehr positiv auf die Qualität aus. Schliesslich lässt sie sich automatisiert und schnell durchführen – viel schneller als bspw. ein Review. Die Zeitinvestition in die Analyse formaler Implementierungsfehler rechnet sich in den allermeisten Fällen. Vor allem auch deshalb, weil Fehler frühzeitig (vor dem Ausführen) erkannt werden können. Nicht zuletzt erhält der Quellcode ein einheitliches Erscheinungsbild. Kolleg*innen, die in der Zukunft den Code anpassen müssen, werden es den ursprünglichen Autor*innen danken.

Bekannte Programmierrichtlinien

Eine der bekanntesten Programmierrichtlinien ist die MISRA Guideline (Motor Industry Software Reliability Association) aus der Automobilindustrie. Diese ist verfügbar für C und C++. Wobei die «aktuellste» Version für C++ aus dem Jahr 2008 stammt, für C immerhin aus dem Jahr 2012. Eine Aktualisierung ist angezeigt. Dennoch decken die Regeln von MISRA viele bekannte Probleme von C/C++ ab. Nennenswert ist auch das Regelwerk CERT C Coding Standard (vom Computer Emergency Response Team) oder CWE (Common Weakness Enumeration). Wobei letzteres vor allem auf Security-Themen (Gefahren von «ausserhalb der Software»), aber weniger auf Safety-Themen (Gefahren von «innerhalb der Software») eingeht.

Akzeptanz von Coding Guidelines erhöhen

Grundlage für das erfolgreiche Etablieren einer Coding Guideline ist das entsprechende Mindset: sowohl die Entwicklung wie auch das Management müssen anerkennen, das gute Software-Qualität kein Zufallsprodukt ist. Sie verursacht eben auch einen entsprechenden Aufwand. Unterstützt wird die Akzeptanz von Coding Guidelines des Weiteren durch folgende Punkte:

• Neue Coding Guidelines sollten, wenn immer möglich, bottom-up von den Entwickler*innen definiert werden. Sie dürfen sich auch von Team zu Team unterscheiden. Wichtig sind die gemeinsame Basis und die Akzeptanz.
• Zeitbudget für das Pflegen von Software-Qualität und den Wissensaustausch.
• Definieren eines gemeinsamen Style Guides. D.h. das Team definiert das einheitliche Aussehen des Codes. Diese Regeln sollten automatisiert prüfbar sein.
• Kurzzyklische automatisierte Prüfung ermöglichen. Siehe dazu mehr unter Wahl des Tools.

Wahl des Tools – der richtige Treibstoff für die Analyse

Das für das Team und Projekt geeignete Tool verleiht der Prüfung auf Konformität mit der Coding Guideline richtig Schub. Folgende Merkmale sollte das Tool aufweisen, um auf hohe Akzeptanz zu stossen:

• Möglichst für mehrere Programmiersprachen nutzbar
• Verschiedene Regelwerke unterstützen, die anerkannt und weit verbreitet sind (bspw. MISRA, CERT oder CWE).
• Die Möglichkeit bieten, eigene Regeln zu definieren. Dadurch können bspw. auch Regeln betreffend Code Style eingefügt werden.
• Integration möglich ins CI-Tool (Continuous Integration) und in die IDE (Entwicklungsumgebung).
• Unterstützt kollaboratives Arbeiten. Daher meistens browserbasiert, um Defekte gemeinsam im Team zu bearbeiten und zu lösen.
• Unterstützt die offline Prüfung. Wenn der Code zur Überprüfung zuerst eingecheckt werden muss, wird die Prüfrate mit grosser Wahrscheinlichkeit dramatisch sinken. Eine kontinuierliche Prüfung ist unabdingbar, um die technische Schuld gering zu halten.
• Fehler-Severity einstellbar. Wen die Liste möglicher Defekte zu gross ist, kann dies zu einer Geringschätzung und Vernachlässigung des Tools führen. Dies gilt es vor allem bei der Bereinigung von Legacy-Code zu beachten!
• Im regulatorischen Umfeld: zertifiziert nach einer verbreiteten Norm (bspw. IEC 61508 (allg. Industrie – bspw. Automation), ISO 26262 (Automobilindustrie) oder IEC 62304 (Medizintechnik).

Zusammenfassung

Mittels statischer Code-Analyse wird Software auf Konformität mit einer Programmierrichtlinie analysiert. Auf diese Weise werden formale Implementierungsfehler im Code entdeckt. Diese automatisierte Prüfung erfolgt mittels eines Tools. Das Tool sollte kollaboratives Lösen der Defekte unterstützen, möglichst kurzzyklisch nutzbar sein und standardisierte Regelwerke einbeziehen. Ziel ist vor allen Dingen den Arbeitsfluss während der Entwicklung nicht zu unterbrechen.

Coding Guidelines können in der Anwendung einen nicht vernachlässigbaren Aufwand zur Folge haben. Jedoch zahlt sich dieser durch die damit erreichte verbesserte Qualität mehr als aus. Ein weiterer Vorteil liegt in der Einheitlichkeit des Codes in einem grossen Team. Letztendlich vermindert sich auch der Testaufwand erheblich, da viele mögliche Fehler schon vor dem Ausführen behoben werden können.