7.2. Codegenerierung

Das Ergebnis der Codegenerierung ist das vollständige Programm. Je nach Inhalt des Designs, können wir auch Unit-Testfälle generieren.

Um dies tun zu können, benötigen wir das Designmodell, welches die statischen und dynamischen Aspekte des Programmes beinhaltet.

7.2.1. Code aus der statischen Struktur generieren

Es ist ziemlich unkompliziert, diese Generierung durchzuführen. Zumindestens so lange wir es für eine objektorientierte Sprache tun. Dies sind einige der grundlegenden Regeln:

  • Eine Klasse wird eine Klasse.

    In einigen Zielsprachen (wie Java, C++) werden sie auch Dateien und Übersetzungseinheiten.

  • Eine Generalisierung wird zu einer Vererbung.

    Wenn die Zielsprache keine Vererbung unterstützt und wir dies während des Design's nicht adressieren, sind einige spezielle Konvertierungen erforderlich, um dieses Problem zu lösen.

  • Ein Attribut wird zu einer Membervariablen.

  • Eine navigierbare Assoziation wird eine Membervariable.

    Abhängig von der Zielsprache, der Zielplattform und der Kardinalitäten der Assoziation wird dies ein Zeiger, eine Referenz, eine Collection-Klasse, ein Eintrag in einigen Tabellen oder Bitabbildungen (map) sein.

  • Eine nicht abstrakte Operation in einer Klasse wird zu einer Methode.

  • Eine abstrakte Operation in einer Klasse wird zu einer abstrakten Methode.

  • Ein Parameter in einer Operation wird zu einem Parameter in der Methode.

    Bei einfachen Typen (int, boolean) ist dies der Normalfall. In C++ werden diese wahrscheinlich Const-Klassen. In Java kann dies für Klassen nicht eingefordert werden.

  • Ein out- oder in/out-Parameter in einer Operation wird zu einem referenzierenden Parameter in der Methode.

    In C++ werden dies referenzierende nicht-konstante Parameter. Bei Javaklassen ist dies der Standard. Einfache Typen (int, boolean) müssen in Java in ein Objekt einer korrespondierenden Klasse (Integer, Boolean) konvertiert werden.

  • Die Sichtbarkeit von Attributen, Assoziationen und Operationen werden zu Sichtbarkeit von Membervariablen oder Methoden.

  • Pakete werden Verzeichnisse, Namensräume oder beides.

7.2.2. Code aus Interaktionen und Zustandsautomaten generieren

Diese Konvertierung ist nicht so unkompliziert, wie die Konvertierung der statischen Struktur. Sie hängt sehr viel mehr von der Zielsprache und der Zielplattform ab.

Generell ist es nur möglich, das Folgende zu Interaktionen zu sagen:

  • Eine Nachricht wird in einen Funktionsaufruf konvertiert.

    Die Empfängerklasse wird eine Funktion mit dem richtigen Namen und der richtigen Signatur haben.

    Die sendende Funktion in der Klasse eines Senders wird einen Funktionsaufruf auf eine Funktion des Empfängers aufweisen.

  • Eine asynchrone Nachricht wird entweder eine Nachricht senden, die durch einige andere Thread- oder Funktionsaufrufe verarbeitet werden, die einen neuen Thread starten.

Das Folgende beschreibt einen möglichen Weg, Zustandsautomaten zu generieren:

  • Ein Zustandsautomat wird in einen Satz von Membervariablen generiert, bei dem sich jede Methode in dieser Klasse auf das entscheidende Verhalten bezieht.

  • Ein Zustand wird zu einem zusammengehörenden Satz von Werten dieser Membervariablen generiert.

  • Ein Ereignis wird zu einem Aufruf auf eine Membermethode generiert, der den Zustand ändern kann.

    Diese Methoden würden dann typischerweise eine grosse switch-Anweisung haben, aufgesplittet je nach aktuellem Zustand.

  • Ein Wächter wird, in dem Zweig des richtigen Zustandes, zu einer if-Anweisung in der Ereignis- Membermethode generiert.

  • Eine Transition wird als Zuordnung auf einige Zustandsvariablen generiert.

  • Eine Aktion wird als Funktionsaufruf generiert.