Besonders interessant ist das Thema Metamodellierung, bei der man Sprachen wie UML bzw. SysML auf einer Metaebene betrachtet .. oder sogar noch einen Schritt weiter geht und auch diese wieder auf einer weiteren Ebene, der Metametaebene analysiert. Auf der obersten Ebene sind die Sprachen gleich und koennen entsprechende Formalismen vorausgesetzt,  automatisch migriert werden in andere kompatible Modelle. Ein besonders einfaches Beispiel dafuer waere z.B. das Erzeugen von Java Klassen aus einem relationalem Datenbankmodell.

Hier meine Folien, welche in das Thema einfuehren .. Metamodellierung

map should (contain key ("one") and not contain value (10))
result should be => (0)
book should have (title ("Programming in Scala"))
tempFile should not be a ('directory)
quotient should be (1.0 plusOrMinus 0.2)

Als kleine Demonstration zeige ich hier nun wie man das ‘using’ Konstrukt aus C# in Scala nachahmen kann. Die Funktionsweise dieses Blocks ist simpel, aber immer wieder nützlich. Man übergibt einen Stream bzw. irgendeine Instanz, die IDisposable implementiert, verwendet diese und das Schließen bzw. Zerstören der Instanz geschieht ganz von alleine.

using (var file = File.CreateText("test.dat")
{
    file.WriteLine("C# is");
    file.WriteLine("great");
}

Was wirklich passiert ist, dass der Compiler ein try finally Block erzeugt, der in jedem Fall .Dispose() aufruft, womit dann im Falle eines Streams auch automatisch .Close() zum Zuge kommt. Fangen wir mit der Scala-Übersetzung an. Eine erste Methode könnte eine simple Funktion höherer Ordnung in der folgenden Art sein:

val file = new PrintWriter("test.dat")
using (file, () => {
  file.println("scala is")
  file.append("great")
})

def using(stream: Closeable, operation: () => Unit) {
  try {
    operation
  } finally {
    stream.close()
  }
}

Using erwartet den Stream sowie die auszuführende Funktion, die nichts erwartet und nichts zurückgibt (Unit entspricht praktisch void in C#). Wir können die Syntax noch weiter verbessern, indem wir den zweiten Parameter in einen By-Name-Parameter umschreiben:

def using(stream: Closeable, operation => Unit)

Nun fehlen die zwei Klammern in der Signatur, was dazu führt, dass wir sie auch beim Aufrufen weglassen können:

using (file, { ... })

Das kommt der Version aus C# schon recht nahe. Einen Unterschied können wir jedoch nicht verstecken – in Scala sind Variablendeklarationen keine Ausdrücke. Somit können wir sie z.B. nicht wie in C an eine Methode übergeben, sondern müssen die Variable im Voraus definieren und sie dann an using übergeben.
Doch trotzdem gibt es hier noch Verbesserungsmöglichkeiten. Wir können using in eine partiell auswertbare Methode umwandeln, sodass using einen Parameter erwartet und als Ergebnis wieder eine Funktion zurück liefert, die nur noch die Operation als Argument bekommt. Das sieht dann so aus:

def using(stream: Closeable)(operation: => Unit)  { ... }

Damit sind wir nunam Ziel angelangt. Wir können das using-Konstrukt fast wie in C# nutzen (in Scala können normale Klammern auch durch geschweifte ersetzt werden):

val file = new PrintWriter("test.dat")

using (file) {
  file.println("scala is")
  file.append("great")
}

Übrigens wird Scala nach Java Bytecode kompiliert und ist somit praktisch kompatibel und gemeinsam einsetzbar mit allen bestehenden Java-Systemen. Ein Compiler für die Common Language Runtime ist auch in der Entwicklung, der Support für Java ist aber wesentlich besser.

Beim Lesen des Buchs “Programming in Scala” (welches übrigens ausgezeichnet geschrieben ist) sind mir erstmals die Unterschiede zwischen den Programmierparadigmen wirklich klar geworden. Umso interessanter ist es dann nach und nach zu sehen wie Scala beides fusioniert und dabei etwas neues schafft. Das erstaunlichste an Scala ist aber wie man selber zu einem Sprach-Kreatonist werden kann! Die Programmiersprache ist in ihrem Kern recht einfach, aber dennoch so flexibel, dass jeder die Sprache erweitern kann, um sie an die entsprechenden Bedürfnisse anzupassen.

Das beste Beispiel ist die Actors-Bibliothek zur Abstraktion der parallelen Ausführung von Programmcode. Eine Idee – ursprünglich aus der Sprache Erlang – die es mittlerweile fast in jede Sprache geschafft hat als ein normales Framework. Scala geht weiter und integriert nicht nur Funktionalität, sondern auch Syntax aus Erlang und schafft somit eine ganz natürliche Integration – so als wäre das Programmieren mit Actors schon immer Bestandteil der Sprache.

Ein paar schöne Code-Beispiele zu Actors-Bibliothek befinden sich direkt hier.

Im nächsten Beitrag werde ich demonstrieren wie man das nützliche in C# bekannte using-Konstrukt nachbaut, um Streams etc. automatisch zu schließen.

Ähnlich wie in XUL oder XAML erzeuge ich außerdem etliche Teile meiner Oberflächen direkt aus dem XML-Baum, der sich aus allen XML-Knoten der geladenen Plugins ergibt. Dies ermöglichst es mir Menüs und Werkzeugleisten darzustellen ohne alle Plugin-Assemblies zu laden. Denn die Infos über Struktur, Titel und Icons der Oberfläche befinden sich bereits in den XML-Daten und müssen nicht erst vom .NET Code erzeugt werden. Mit solchen Prinzipien kann man auch große Anwendungen zu einem schnellem Start verhelfen, Visual Studio, #Develop und Co machen es genauso.

Anmerkung: Mono.Addins speichert die sogenannten XML-Addin-Manifests entweder in separaten Dateien (neben den Assemblies) oder in eingebetteten Resourcen innerhalb der .dll’s. In dem Fall wird beim ersten Start der Anwendung das Addin-Manifest extrahiert und binär auf der Festplatte abgelegt, um den nächsten Programmstart zu beschleunigen.

Schwieriger wird es, wenn man eine multilinguale Anwendung entwickelt und die Texte für die Oberfläche nicht mehr fix in die Metadaten eingetragen werden können. Im .NET-Umfeld ist es üblich alle zu lokalisierenden Resourcen in Satelliten-Assemblies (eine Assembly pro Kultur, z.B. de-DE) auszulagern. Aus dieser kann man dann die Strings und Bilder laden, doch verhindert man dadurch das verzögerte Laden des Plugins, denn die Sattelite-Assemblies und damit das gesamte Plugin werden bereits beim Laden der GUI benötigt. Folge ist, dass der Programmstart wieder ewig dauert.

Lösung: Wir müssen die für den Start so wichtigen Texte der Oberfläche separat speichern. Das muss immer dann gemacht werden, wenn ein Plugin hinzugefügt wird, d.h. genau dann wenn auch Mono.Addins einen Scan durchführt. Zu Hilfe kommt uns dabei eine recht neue Funktion von Mono.Addins: Localizer. Mit diesen kann man automatisch Strings aus Satellite-Assemblies oder anderen Quellen (z.B. l18n-Verfahren) laden. Perfekt für dieses Problem, da wir nur an die Oberflächentexte wollen, sonst aber nichts über die Plugins wissen.

XML-Manifest zur Erweiterung eines Menüs; Titel ist in Sprachresource mit Schlüssel "count-word-string" gespeichert

Das einfachste wäre sich an den Scanvorgang von Mono.Addins ranzuhängen und dann die Resource Strings zu laden und selber abzuspeichern. Ich werde wenn ich etwas Zeit finde mal versuchen das ganze in Mono.Addins zu integrieren und dann öffentlich verfügbar machen. Die nahtlose Integration hätte den Vorteil, dass die Texte einfach in den sowieso schon vorhandenen Binärdateien aufgenommen werden können. Das würde die Anzahl der zu lesenen Dateien erheblich verringern.

Mit etwas mehr Vorlauf ist es dann auch sogar noch mehr Teilnehmern möglich eigene Präsentationen zu zeigen, die ja doch etwas mehr Vorarbeit benötigen als ich dachte. Ich wollte eigentlich das Session Hijacking vorführen, aus Zeitgründen hat es dann aber doch nur für eine XSS-Lücke gereicht .

Für mich war die Vorführung des Java Content Repository sehr interessant, da dieses einige mächtige Konzepte vereint, die ich auch gerne in der .NET-Welt sehen würde. Zu einigen konkreten Ansätzen habe ich in mir in letzter Zeit schon Gedanken gemacht und habe angefangen dies umzusetzen. Beispielsweise die Mixin-Types, mit denen man Versionierung oder auch andere Anforderungen an die Datencontainer darstellen kann.

Die Diskussionen zum REST-Paradigma haben auch super zum Thema gepasst und haben auch mal wieder gezeigt, dass die korrekte Nutzung des HTTP-Protokolls sogar Sicherheitslöcher vermeiden (speziell bei XSRF) und die Performance vergrößern (Stichpunkt Caching im Browser) kann.

So, jetzt dürfen natürlich meine Präsentationen nicht fehlen:

• XML-Präsentation
• Sichere Webanwendungen

Hier gibts im Laufe der Zeit auch die Präsentationen der anderen.

Wir nutzen ein studentisches Begegnungszentrum – MOPS - als Veranstaltungsort.  Ein relativ kleines gemütliches Café. Da wir aktuell noch nicht die maximale Teilnehmeranzahl erreicht haben, könnt ihr euch gerne auf unserer Techtalk-Seite anmelden…

Auch interessant ist der Abschnitt über die (grundlegende) Funktionsweise von Garbage Collectoren. Außerdem ist das letzte Kapitel der Ayox Intermediate Language gewidmet, eine Eigenentwicklung einer Zwischensprache (ein Mix aus Java Bytecode und CIL) mit zugehöriger Laufzeit (Interpreter, etc.).

Download der Arbeit (pdf)

Viel Spaß beim Lesen

Aktuell finde ich jedoch die Idee zur Modellierung der Daten XML Schemata zu nutzen, wesentlich interessanter. Mit einem leistungsfähigem Designer könnte man seine Modelle und Beziehungen darstellen und diese dann als XSD-Datei speichern. In der Softwarebranche wird dieses Verfahren in ähnlicher Weise schon seit Jahren genutzt. Konkret nutzt man einige OMG-Standards, um den Ansatz der Model Driven Architecture zu vereinheitlichen und damit plattformunabhängiger zu machen.

Die Object Management Group (OMG) hat eigene XML-Formate (XMI) entworfen, die von vielen UML-Tools geschrieben werden können. Leider hat man damit auch direkt einige Möglichkeiten die reine XML-Schemata bringen würden, verworfen oder zumindest schwer umsetzbar gemacht. Beispielsweise könnten mit XSD-Dateien viele Validierungsregeln deklarativ ausgedrückt werden. Für Zeichenketten-Felder können eingeschränkte Datentypen definiert werden, die auf einer RegEx basieren, außerdem kann man die Multiplizät einzelner Beziehungen genauer definieren.

Modellierung einer N:M Relation mit MySQL Workbench

Dazu ein kleines Beispiel: In einer klassischen Datenbank gibt es keine Möglichkeit eine N:M Relations-Tabelle so anzulegen, dass immer mindestens genau ein Eintrag in der Relations-Tabelle enthalten ist. In XML-Schemata ist nicht nur das möglich, man kann sogar noch genauer festlegen, dass beispielsweise eine Relation mindestens ein und maximal drei Einträge beinhaltet. Bis dato musste diese Funktionalität in jeder Anwendung oberhalb der Datenbank neu programmiert werden. Auch XMI hält in diesem Punkt keine Lösung bereit, wenn ich mich nicht irre (andere Meinungen?).

Mein Wunsch für die zukünftige Datenmodellierung ist es möglichst viele Validierungsregeln bereits in das Model zu verlagern. Dies kann durch restriktive Datentypen oder genauere Multiplizitäten geschehen. Da die Datenmodelle praktischerweise als deklarative Daten vorliegen, kann basierend darauf sehr leicht automatisch Code erzeugt werden. Besonders vorteilhaft ist dies für verteilte Anwendungen, in einer Webanwendung beispielsweise könnte man automatisch Validierungscode für den Klient und den Server erzeugen.

Modellierung einer eingeschränkten (1-3) N:M-Relation mittels XSD

Zur produktiven Nutzung fehlen mir nur noch die entsprechenden Werkzeuge. Man braucht schon einen Designer, der auf einer höheren Abstraktionsebene als ein normaler XML Schema Designer arbeitet. Essentiell ist dann natürlich außerdem die Codegenerierung. Aber mit den DSL-Tools sollte man sowas ja alles schnell bauen können

Ursprünglich gab es in Visual Studio 2005 mal einen bereits recht brauchbaren XML Schema Designer, doch den hat Microsoft aus der 2008′er Version rausgekommen. Einen Ersatz wird es wohl allerfrühestens mit VS 2010 geben.

Jeder von uns hat schon mit einer DSL gearbeitet, wir haben es nur nicht mitbekommen . Denn genau genommen sind SQL als auch RegEx zwei DSLs, die besonders ausdrucksstark sind in ihrer Domäne. Mit einer RegEx kann ich String-Muster definieren, deren Programmierung in einer “normalen” Programmiersprache dutzende Zeilen benötigen würde. Für Abfragen aus relationalen Datenbanken eignen sich RegEx aber natürlich nicht, daher sagt man die Sprache ist auf eine Domäne – ihr Arbeitsgebiet – beschränkt.

In finde besonders die grafischen DSLs sehr spannend, da man mit ihnen komplizierte Zusammenhänge übersichtlich als Grafik präsentieren kann. Und wir wissen ja auch schon lange, dass eine Grafik mehr sagt als 1000 Codezeilen . In der Praxis kann man dann mittels eines Designers z.B. in Eclipse oder Visual Studio eine DSL nutzen, um beispielsweise Architekturen, Prozesse oder Automaten zu modellieren. Alles ist möglich!

Definition einer DSL für Funktionsdiagramme

Einige prominente Beispiele wären die UML mit entsprechend gekoppelter Codeerzeugung oder auch die Windows Workflow Foundation. Beide sind jedoch noch recht allgemein, es sind noch viel spezifischere DSLs denkbar. Man könnte z.B. grafisch die Übergänge zwischen Spielezuständen modellieren so wie es in dem Projekt sharpludus gemacht wird. Ebenfalls sehr speziell aber leistungsfähig sind die DSL Tools von Microsoft mit denen man eigene DSLs erzeugen kann. Diese sind im Visual Studio SDK enthalten und bringen einen grafischen Designer mit, mit dem man eigene grafische Designer bauen kann. Das ganze funktioniert wunderbar, sodass man innerhalb weniger Stunden – mit ein bischen Übung – leistungsfähige Tools bauen kann.

Das Diagramm kann dann per Knopfdruck (oder automatisch) in eine Textform gebracht werden. In Visual Studio steht dazu eine Text Template Engine zur Verfügung mit der man XML als auch Programmcode erzeugen kann. Die DSL Tools nutzen dieses Konzept selber um tausende Codezeilen für die Integration und Umsetzung des Designers in die Entwicklungsumgebung zu kreieren. Man könnte aber natürlich auch statt Code einfach HTML erzeugen zur Dokumentationszwecken so wie es das Projekt Feature Model DSL macht.

Ich werde auf jeden Fall mal selber eine DSL bauen, wenn ich dazu mehr Zeit habe und die richtige Idee. Denn lohnen tut sich soetwas meist erst wenn man die DSL in mehreren Produkten nutzen kann.