LibraJune 2005 Community Technology Preview

Peter Bachmann

Kirill OsenkovSteffen Büchner

.NET Projektstudium, BTU Cottbus

Libra als Framework...

• ...für Code Repräsentierung

• operiert mit Abstrakten Syntax-Bäumen• interne Darstellung: Hierarchien von Blöcken

while

< ++

a

AnweisungenBedingung

a 10

while (a < 10)

{

a++;

}

Libra als Forschung

• Suche nach bereits existierenden Ansätzen

• Idee existiert bereits seit 1970: syntax-gesteuerter Code Editor

• Bisher existierende Lösungen unpraktisch• Idee aber dennoch richtig: Intentional Programming

Libra als Experiment

• Spielwiese zum Ausprobieren

• Suche nach einer bequemeren Code Darstellung

• Analyse von Benutzbarkeit existierender Entwicklungsumgebungen

Projektverlauf

Teilprojekte:

1. Canvas.dll (grafische Bibliothek)

2. LibraCore.dll (Definition von Blöcken)

3. LibraClient.exe (Test-Umgebung für C# Code)

4. XmlEditor.exe (Test-Umgebung für XML)

Heute:

• Vier Projekte in C#.NET (Visual Studio 2005 Beta 2)

• 11 400 C# Code Zeilen

• 180 Klassen und Schnittstellen

Canvas.dll• Status: fast fertig implementiert

• stellt ein .NET UserControl “DrawWindow” zur Verfügung, womit man schnell und unabhängig von einer konkreten Grafikbibliothek zeichnen kann

DrawWindow Eigenschaften

• gepuffert (double-buffering)

• verwendet intern wahlweise GDI oder GDI+ (Benutzung von OpenGL und DirectX später auch möglich: flexible Schnittstelle IRenderer)

• erweiterbare Scrollbar auf Basis von Shapes

Es fehlen noch die Funktionen zum Arbeiten mit Bitmaps.

Canvas Shapes

Canvas.dll stellt auch “Shape” Funktionalität zur Verfügung:

• Basisklassen für visuelle Objekte, die auf DrawWindow gezeichnet werden können

LibraCore.dll

• stellt Klassen zur Verfügung, mit welchen man Blockhierachien modellieren kann• zu jeder Blockhierarchie existiert ein RootBlock, der als Repräsentant für die gesamte Hierarchie dient• beinhaltet CodeWindow, welches beliebige modellierte Blockhierarchien, mittels DrawWindow, visualisieren kann

CodeWindow

Klassenhierarchie

• IBlock unterstützt elementare Operationen auf Blöcken

• Beispiele:

AcceptVisitor(IVisitor v)

Parent, Root und Draw()

• AbstractBlock ist die Standardimplementierung, von der alle weiteren Blöcke in Libra erben

•AbstractContainerBlock ist die Standardbasisklasse für alle Blöcke die Kinder enthalten können (z.B. NamespaceBlock)

Basisschnittstelle IBlock

Entwurfsmuster: Visitor

• um die Funktionalitäten kapseln zu können und schnell und übersichtlich neue hinzuzufügen, haben wir uns für dieses Entwurfsmuster entschieden

• durch Visitoren kann man neue Funktionalitäten, wie z.B. das Kompilieren oder die statische Analyse, hinzufügen ohne an der Klassenhierarchie etwas ändern zu müssen

•streng typisierte Softwarearchitektur, so ist kein Casting nötig, alles zur Kompilierungszeit bekannt

•Beispiele: DrawVisitor, LayoutVisitor und XMLGeneratingVisitor

Editieren von Blockhierarchien

ActionManager

• IAction stellt eine Transaktion auf Blöcken dar

• der ActionManager verwaltet Objekte vom Typ IAction, er speichert diese chronologisch und stellt so eine sehr flexible und einfach zu nutzende Basis für Undo/Redo zur Verfügung

• alle Transaktionen auf Blöcken werden durch Actions, wie z.B. AddBlocksAction und RemoveBlockAction gekapselt (ausgelagert), und somit können wir neue Transaktionen hinzufügen ohne an den Basisklassen von LibraCore etwas ändern zu müssen

Entwurfsmuster: Composite

• durch dieses Entwurfsmuster lassen sich sich sehr komplexe Transaktionen als einfaches IAction auffassen somit bleibt die komplexität vor dem späteren Verwender von LibraCore verborgen

• dieses Entwurfsmuster wird auch bei den Block-Klassen verwendet (AbstractContainerBlock)

Anwendungbeispiele

•Libra ist als Framework für Quelltexteditoren aller Art gedacht

•(fast) jede Programmiersprache lässt sich als eine (Libra-) Blockhierarchie modellieren

•Zum Experimentieren und als Präsentationsbeispiel implementieren wir parallel die Unterstützung für zwei Sprachen: C# und XML

Wie geht’s weiter?

Mit C# und XML Testprojekten muss noch experimentiert werden, um die notwendige Funktionalität zu gewährleisten (z.B. Benutzbarkeit, Arbeit mit Tastatur und Maus, Navigation, Selektierung, Drag & Drop, etc.).

Erst nachdem die Testbeispiele zufriedenstellend laufen, werden die jeweiligen Hierarchien um fehlende Blöcke ergänzt.

So wird sichergestellt, dass die meiste Arbeit vor dem “Losprogrammieren” passiert – so erleichtert man sich die Aufgabe, Hierarchien am Ende zu ergänzen.

Idealerweise kann der C# Quellcode für die fehlenden Blöcke eventuell automatisch nach der vorgegebenen Grammatik erzeugt werden.

Als Super-Aufgabe (für viele Jahre) könnte man sich die automatisierte Generierung von Libra-basierten Editoren für beliebige Programmiersprachen vorstellen, wenn die Grammatik vorgegeben ist.

Aber das ist noch nicht alles...

Blöckenhierarchie alleine reicht nicht, um einen guten Editor zu bauen.

Man braucht noch:

• Name resolution system, Typ-Informationen

• Integration mit modernen Entwicklungsumgebungen

• Compiler, Debugger, statische Analyse

• und vieles mehr

Das ganze ist natürlich extrem aufwendig, aber... machbar!

Das Wesentliche ist der neue Ansatz, neue Art und Weise mit Code zu arbeiten. Gerade dies soll Libra-Framework demonstrieren.

expect Libra Beta 1...

...coming soon...