Graphischer Editor für die technologieunabhängige User Interface

 Universität Augsburg Lehrstuhl für Softwaretechnik und Programmiersprachen Prof. Dr. Bernhard Bauer Praktikum Modellgetriebene Softwareentwicklung SS 2008 Graphischer Editor für die technologieunabhängige User Interface Modellierung Manfred Schönheits Ulrich Harner Christian Rinner
Inhalt Inhalt........................................................................................................................................... 1
1 Einführung .......................................................................................................................... 2
1.1 Motivation ................................................................................................................... 2
2
Modellgetriebene Entwicklung von Benutzerschnittstellen.............................................. 3
2.1 Anforderungen ............................................................................................................ 3
2.2
Bisherige Ansätze......................................................................................................... 3
2.2.1
GUI ‐ Beschreibungssprachen............................................................................. 3
2.2.2
Kommerzielle Lösungen...................................................................................... 4
2.3 Konzeption des Metamodells...................................................................................... 4
2.3.1
Design ................................................................................................................. 4
2.3.2
Definition in EMF ................................................................................................ 5
2.4 Entwicklung eines graphischen Editors ....................................................................... 5
2.4.1
Verwendung des GMF........................................................................................ 6
2.5 Codegenerierung ......................................................................................................... 6
3
2.5.1
Transformation vom PIM zu PSC mit openArchitectureWare ........................... 7
Zusammenfassung und Ausblick ........................................................................................ 8
1 1 Einführung Heutige Software‐Entwicklungsprozesse verwenden Modelle in aller Regel lediglich zur Dokumentation von Softwaresystemen. Es besteht also nicht mehr als eine gedankliche Verbindung zwischen Modell und Softwareimplementierung. Bei der modellgetriebenen Softwareentwicklung (engl. Model Driven Software Development, MDSD) verfolgt man einen anderen Ansatz: Modelle dienen nicht nur zu Dokumentationszwecken, sondern sind gleichzusetzen mit Code. Die Umwandlung von Modell zu Code erfolgt dabei automatisiert. Im Bereich der Modellierung von grafischen Benutzerschnittstellen (engl. Graphical User Interface, GUI), existieren seit langem WYSIWYG‐Editoren die eine solche Umwandlung durchführen können. Die erzeugten Artefakte basieren dabei jedoch stets auf bestimmten Technologien wie beispielsweise HTML oder Java SWING, sind also Plattformabhängig. Aufgrund der Vielzahl heute existierender Endgeräte (PCs, PDAs, Smartphones etc.), wäre es von Vorteil einen Editor zu besitzen der in der Lage ist Modelle in Code für beliebige Zielplattformen zu transformieren. Ziel dieser Arbeit ist es im Prinzip einen solchen Editor zu realisieren. Dabei liegt der Schwerpunkt auf der Erstellung einer Beschreibungssprache, d.h. eines sog. Metamodells für eine Technologieunabhängige GUI‐Modellierungssprache. 1.1 Motivation In vielen Fällen kann durch den Einsatz von MDSD die Entwicklungsgeschwindigkeit bei der Softwarefertigung beschleunigt, und damit eine Produktivitätssteigerung erzielt werden. Höhere Qualität und verbesserte Wartbarkeit der Software, sowie Expertenwissen das in die Automation einfließt, sind weitere positive Effekte die zum Produktivitätsgewinn beitragen. Besonders deutlich wird dies eher mittelfristig, wenn das System gewachsen ist und einige Veränderungen daran vorgenommen wurden. In diesem Zustand helfen die einheitliche Architektur und die automatisch aktuelle Designdokumentation den Entwicklern dabei, weitere Änderungen vorzunehmen und Fehler zu vermeiden. Die Benutzeroberfläche von Applikationen wird heutzutage immer wichtiger, und spielt oft eine entscheidende Rolle bei der Beurteilung der Qualität. Noch dazu fließt nicht selten ein erheblicher Anteil der Entwicklungsarbeit in deren Programmierung. Deshalb ist es wegen der oben genannten Vorteile erstrebenswert, MDSD auch bei der Entwicklung von Benutzeroberflächen einzusetzen. 2 2 Modellgetriebene Entwicklung von Benutzerschnittstellen 2.1 Anforderungen Um den graphischen Editor zu implementieren, der im Rahmen dieser Arbeit realisiert werden soll, müssen mehrere Schritte unternommen werden. Ein wesentlicher Aspekt besteht darin, die für die Modellierung benötigten Elemente zu identifizieren und festzulegen. Dazu werden auch die Elemente von Benutzeroberflächen aktueller bzw. gängiger Programme in Betracht gezogen. In Frage kommen unter Anderem Elemente wie ‐ Eingabe‐Elemente wie z.B. einzeilige Textfelder (z.B. zur Eingabe von Suchbegriffen) und mehrzeilige Textfelder (z.B. zum Schreiben einer Email) ‐ Ausgabe‐Elemente wie z.B. Beschriftungen, ToolTips oder Fortschrittsbalken ‐ Auswahl‐Elemente wie z.B. Ankreuzfelder, Radio‐Buttons ‐ Elemente, die eine Aktion signalisieren wie z.B. Buttons ‐ Elemente, die als Behälter für andere Elemente dienen, wie z.B. Tabellen 2.2 Bisherige Ansätze Um die Inhalte einer Domäne formal zu beschreiben, sind sog. Domänenspezifische Sprachen (Domain Specific Languages, DSLs) erforderlich. Eine DSL besteht aus deren konkreter Syntax sowie aus einem Metamodell und dessen abstrakter Syntax und statischer Semantik. In einem Metamodell wird die genaue Struktur einer Domäne beschrieben. Die Metamodellelemente und deren Beziehungen zueinander werden als abstrakte Syntax bezeichnet, unter statischer Semantik versteht man das Festlegen von Bedingungen (Constraints), die ein Metamodell erfüllen muss, um als wohlgeformt bezeichnet werden zu können. Als konkrete Syntax wird die textuelle oder grafische Notation der DSL bezeichnet. Für die Entwicklung einer passenden DSL ist eine Recherche nach bestehenden GUI ‐
Beschreibungssprachen hilfreich, weshalb hier einige kurz erwähnt sein sollen. Diese bilden zwar eine gute Grundlage zur Beschreibung von Benutzerschnittstellen, allerdings fehlt ihnen die Möglichkeit, die Anforderungen an die zu entwickelnde Oberfläche formal zu spezifizieren. 2.2.1 GUI ­ Beschreibungssprachen XUL 3 XUL ist eine auf XML basierende Beschreibungssprache für Benutzeroberflächen. Ursprünglich für das Mozilla‐Projekt entwickelt, wird XUL inzwischen auch von anderer Software genutzt. Für die Darstellung der aus XUL‐Dateien erzeugten Benutzeroberflächen kommt die „Gecko Rendering Engine“ zum Einsatz. Die Vorteile von XUL im Bezug auf die Entwicklung einer DSL liegen in der Trennung von Layout und Design, dem grossen Umfang an Elementen, der nahezu alle für die Beschreibung einer GUI benötigten Elemente enthält und in der Plattformunabhängigkeit der (statischen) Benutzeroberfläche. Die Nachteile liegen darin, dass einige Elemente eher Browserspezifisch sind (z.B. IFrame ) und der dynamische Teil nicht rein deklarativen Charakter hat , sondern auf die Verwendung von Javascript abzielt. Noch dazu besteht zwischen manchen Elementen eine gewisse Redundanz (z.B. „Description“ und „Label“). XAML XAML basiert ebenfalls auf XML, wurde von Microsoft entwickelt und ist Bestandteil der .NET 3.0 – API. Sie dient zur Beschreibung und Erstellung von Oberflächen der Windows Presentation Foundation (WPF) und Workflows in Windows Workflow Foundation. Zu den Vorteilen zählen der hohe Bekanntheitsgrad und die überschaubarere und intuitiverer Aufteilung der Elemente. Allerdings ist XAML nicht für Applikationen im Allgemeinen entwickelt, sondern zielt speziell auf Rich Clients ab. 2.2.2 Kommerzielle Lösungen JAXFRONT JAXFRONT ist eine von xcentric technology & consulting GmbH entwickelte Software, die XML‐Schemas (XSDs) für die Modellierung von Benutzeroberflächen verwendet, und daraus XHTML Web Forms oder Java‐Oberflächen generieren kann. 2.3 Konzeption des Metamodells Sind alle Elemente eingegrenzt, die im Editor zur Modellierung einer GUI verwendbar sein sollen, kann man beginnen ein Metamodell zu entwerfen. Das Metamodell bestimmt in abstrakter Weise die Konstrukte der technologie‐neutralen GUI‐Modellierungssprache, ihre Beziehungen untereinander sowie Gültigkeits‐bzw. Modellierungsregeln. 2.3.1 Design Das Design des Metamodells lässt sich gut anhand eines UML‐Diagramms darstellen: 4 Abb. 1: Definition des Metamodells 2.3.2 Definition in EMF Das fertig designte Metamodell muss nun mit EMF in ein Ecore Metamodell umgesetzt werden. Hierzu gibt es die Möglichkeit den EMF‐internen Editor zu verwenden, der die Metaklassen in einer Baum‐Struktur‐Ansicht darstellt. Da diese Ansicht nicht skalierbar ist, kann die Erstellung größerer Metamodelle sehr unübersichtlich und mühsam werden. Aus diesem Grund gibt es auch die Möglichkeit einen externen UML Editor zu verwenden sofern dieser das gezeichnete Modell in das Eclipse UML2 2.0 Format exportieren kann. Mit dem uml2ecore Plugin für Eclipse, welches im openArchitectureWare Framework, kurz oAW enthalten ist kann die Eclipse UML2 Datei am Ende in eine Ecore Datei umgewandelt werden. 2.4 Entwicklung eines graphischen Editors Nachdem ein EMF basiertes Metamodell erstellt wurde soll nun im nächsten Schritt ein dazu passender graphischer Editor erzeugt werden. Mit Hilfe des Eclipse Graphical Editing Frameworks, kurz GEF ist es möglich einen solchen domänenspezifischen Editor automatisch zu generieren. 5 2.4.1 Verwendung des GMF Um den Generationsprozess in Gang setzen zu können, müssen zunächst die drei GMF‐
Konfigurationsmodelle erstellt werden: Graphical Notation Model, Tool Definition Model und Mapping Model. Das Graphical Notation Model beschreibt die Figuren, d.h. die graphische Repräsentation der Modellobjekte. Die Palette und einige weitere Einstellungen des Editors sind im Tool Definition Model beschrieben. Aufgabe des Mapping Models ist es das Metamodell mit den beiden eben genannten Modellen zu verbinden. Sind all diese Modelle erstellt, so reichert GMF das Mapping Model noch mit weiteren Informationen an um daraus schließlich den graphischen Editor als Eclipse Plugin zu erzeugen. Abbildung 2 veranschaulicht diese Zusammenhänge. Abb. 2: Funktionsweise des GMF 2.5 Codegenerierung 6 Ist der graphische Editor fertiggestellt, so hat man ein praktisches Werkzeug zur Hand um ein beliebiges plattformunabhängiges Modell (engl. Platform Independent Model, PIM) für eine GUI erstellen. Dieses PIM kann durch einen Codegenerator in Plattformspezifischen Code, kurz PSC überführt werden. 2.5.1 Transformation vom PIM zu PSC mit openArchitectureWare Das Codegeneratorframework oAW soll die Entwicklung von Codegeneratoren möglichst flexibel und einfach gestalten. Hierfür stellt das Framework verschiedene Sprachen zur Verfügung: Xtend, Xpand und Check. Xtend ist eine funktionale Sprache, die dazu verwendet werden kann bestehende Metamodelltypen mit zusätzlicher Logik zu erweitern. Das Konzept heißt Extensions und wurde nebenbei bemerkt auch von Microsoft in C# 3.0 eingeführt . Das Besondere daran ist die Möglichkeit für beliebige Typen zusätzliche Operationen zu definieren, ohne dass die ursprüngliche Typdefinition bekannt sein oder verändert werden muss. Diese Extensions sind sowohl innerhalb von Xtend als auch in den anderen Sprachen Check und Xpand aufrufbar. Auf diese Weise können zusätzlich plattformspezifische Informationen in das Modell eingebracht, also das PIM zu einem plattformspezifischen Modell, kurz PSM transformiert werden. Xpand ist eine statisch getypte Templatesprache welche spezielle, für die Codegenerierung wichtige Features bereitstellt. So wird beispielsweise die Modularisierung von Templates, deren polymorpher Aufruf und das Schreiben in Dateien innerhalb von Templates unterstützt. Check stellt das dritte und letzte Mitglied der oAW Sprachfamilie dar. Sie ist an die Object Constraint Language (OCL) angelehnt, welche Bestandteil der Unified Modeling Language (UML) ist. Mit Check lassen sich Modellvalidierungsregeln, sogenannte Constraints formulieren und in den Generator integrieren. Diese Constraints können sogar in einem mit GEF erzeugten graphischen Editor ausgeführt werden, um entsprechende Meldungen und Marker zu erzeugen. Im letzen Schritt dieser Arbeit werden die eben vorgestellten Sprachen dazu verwendet einen Generator zu schaffen, der ein GUI‐Modell in HTML‐Code umwandeln kann. Abbildung 3 bietet einen Überblick über den gesamten Transformationsvorgang. 7 Abb. 3: Der Transformationsprozess 3 Zusammenfassung und Ausblick Diese Arbeit hat sich mit modellgetriebener Entwicklung von Benutzeroberflächen beschäftigt. Es wurde ein graphischer Editor konzeptioniert, mit dem GUIs plattformunabhängig modelliert werden können und sich anschließend auf verschiedene Plattformen transferieren lassen. Dazu wurde ein Metamodell definiert, mit dem sich statische GUIs formal beschreiben lassen. Auf dessen Basis wird im nächsten Schritt unter Verwendung des GMF der graphische Editor entstehen, bevor dann im letzten Schritt mit oAW die Transformatoren implementiert werden. Weiterentwicklungsmöglichkeiten bestehen unter Anderem darin, Benutzerinteraktion (z.B. mit UML‐Aktivitätsdiagrammen), Navigation und Layouts in die Modellierung einzubeziehen. Diese Arbeit zeigt, dass modellgetriebene Entwicklung von grafischen Benutzerschnittstellen prinzipiell machbar und auch erstrebenswert ist, da der hohe Aufwand für die Entwicklung des Metamodells und der Transformatoren mit einem hohen Automatisierungsgrad und einer hohen Wiederverwendbarkeit einhergeht. Allerdings besitzt auch dieses Werkzeug Einschränkungen, so wird es zum Einen wahrscheinlich nur schwer möglich sein, sehr komplexe Anwendungen komplett ohne zusätzliche Programmierung zu realisieren, zum Anderen kann damit nur eine Teilmenge aller bekannten GUI‐Elemente modelliert werden, um die Plattformunabhängigkeit zu gewährleisten. 8