PalladioCM.CodeGen

Aus SDQ-Wiki
Outdated Content
The information on this site is not exactly outdated, but misses many current details.

This pages documents the implementation contained in the code area PalladioCM.CodeGen, which is the generation of SimuCom code and the SimuComFramework, as well as the other code generations (Prototype, ?) from PCM instances.

  • Author: Mainly Steffen, also Roman.
  • Responsible now: Anne

Jira Component


SimuCom

Beschreibung aus Review SimuCom Plattform.docx, einer Reviewvorlage von Steffen.

Overview

SimuCom ist das Simulationsframework des PCM. Es bemüht sich die Konzepte das Meta-Modells möglichst genau so abzubilden, wie sie definiert sind. Es unterteilt sich in zwei Teile: eine Modell-2-Text Transformation, die konkrete Instanzen des PCM in Code umwandelt, der den zweiten Teil konfiguriert: die SimuCom Plattform. Diese Plattform bietet alle Dienste, die generisch sind, und die nicht vom Generator erstellt werden müssen. Damit folgt das Design dem von M.Völter vorgeschlagenen MDD Vorgehen mit Plattform und Generat. Außerdem wurden einige der Patterns eingesetzt, die Generat und Plattform koppeln sollen. So gibt es z.B. Template-Methods, die vom Generator gefüllt werden und abstrakte Oberklassen, die das Generat beerbt und mit dem restlichen Methoden auffüllt. Die Plattform teilt sich auf in zwei Eclipse-Plugins:

  1. simucom.variables: Enthält alle Teile der Plattform, die sich mit der Simulation der Parametercharaktersierungen von Heiko befassen. Das Plugin wird auch vom Prototype Mapping genutzt, das eine „Simulation“ auf echter Hardware durchführt.
  2. Simucom: Der eigentliche Kern der PCM Simulation. Enthält Klassen für simulierte Ressourcen, für Scheduler, für Workload Treiber, usw.

Stackframes

Simucom.variables benutzt als Kernalgorithmus sogenannten StackFrames. Die Idee stammt aus dem Compilerbau und wird zur Realisierung von Scopes aus Programmiersprachen benutzt. Scopes sind dabei die Sichtbarkeitsbereiche von Variablen, in Java und C also z.B. alles zwischen zwei geschweiften Klammern. Der Compiler (aus dem Compilerbau) generiert nun für jeden Scope ein Stackframe, dass ein Speicherblock auf dem Stack ist, der die lokalen Variablen des aktuellen Scopes enthält. Weiterhin enthält er auch einen Pointer auf seinen Vaterstackframe, denn die Variablen des umliegenden Frames sind zusätzlich zu den Variablen des aktuellen Frames zugänglich. Diese Frames werden nun, genau wie im Compilerbau benutzt, um Heikos Parameter / Variablen und Ressourcen-Charakterisierungen umzusetzen. Alle Werte von Charakterisierungen eines Scopes liegen im aktuellen Stackframe.

StoEx

Wichtig im variables Paket ist der PCMStoExEvaluationVisitor, der von der Simulation benutzt wird, um den AST eines beliebigen StoEx Ausdrucks zu durchlaufen und anhand des aktuellen Stackframes auszuwerten. Steht also z.B. im Stackframe unter a.BYTESIZE der Wert 10, so ergibt die Auswertung von 100*a.BYTESIZE dann 1000. Dabei prüft der Visitor die Typen der Ausdrücke auf Konformität. Der von Heiko eingeführte ANY Typ entspricht dabei dem Java Object Typ, bei dem erst zur Laufzeit ermittelt wird, welcher Typ tatsächlich vorliegt. Ansonsten entspricht der EvaluationVisitor dem üblichen Expression Evaluieren aus dem Compilerbau.

Überblick Pakete

Simucom bietet im Paket resources Klassen für die Simulation von Resourcen mit drei Scheduling Strategien: ProcessorSharing (ein RoundRobin ohne Zeiten für Kontextswitch und mit unendlich kleinen Zeitscheiben), FIFO und DELAY. Im Paket usage sind die Basisklassen der Workload-Treiber mit ihren jeweiligen Template-Methoden zu finden. Im Basis-Paket findet sich die abstrakte Oberklasse einer jeden Simulation. SimuCom.model enthält das Simulationsmodell, wie es für Desmo-J nötig ist, um den aktuellen Zustand der Simulation zu halten. SimuCom.sensor enthält das ursprüngliche (=von der initialen Simulationsimplementierung) Simulations-Sensorframework. Dieses wurde bisher nicht ausgetauscht, sondern vielmehr über seine Observer zugänglich gemacht. Als Observer hängt dann im Moment die aktuelle Fassung des Sensorframeworks daran. Damit konnte eine Migration des Codes bisher verschoben werden, um später im Sinne einer sanften Migration diesen Teil auszutauschen.

Code generation

The simulation code generation is written in Xtend. Make sure to have Xtend installed when changing the code generation.

Troubleshooting

  • "Â" symbols are shown in the Xtend templates and you get many errors: Change the encoding of the folder containing the templates: Right-click on the folder -> properties, set another text file encoding there (UTF-8 worked for Anne).

Diagrams

Outdated documentation

Roman describes the interaction of SimuCom and the SensorFramework in this study thesis, available on our BSCW-Server. However, you might have to be careful what is still up to date.

Rerun Simulation

Es ist möglich, ein durch SimuCom generiertes Projekt erneut auszuführen, ohne dass dabei Code neu generiert werden muss. Informationen dazu sind hier verfügbar: Rerun Simulation Plugin