Back To Top

info@comelio.com

  • Berlin, Germany
    Comelio GmbH
    Fon: +49.30.8145622.00
    Fax: +49.30.8145622.10

  • Frankfurt, Germany
    Comelio GmbH (Ecos Office)
    Fon: +49.69.1732068.30
    Fax: +49.69.1732068.39

  • Düsseldorf, Germany
    Comelio GmbH (Ecos Office)
    Fon: +49.211.6355642.00
    Fax: +49.211.6355642.09

  • Hamburg, Germany
    Comelio GmbH (Ecos Office)
    Fon: +49.40.209349960
    Fax: +49.40.209349969

  • Hannover, Germany
    Comelio GmbH (Ecos Office)
    Fon: +49.511.165975060
    Fax: +49.511.165975069

  • Stuttgart, Germany
    Comelio GmbH (Ecos Office)
    Fon: +49.711.460512750
    Fax: +49.711.460512759

  • München, Germany
    Comelio GmbH (Ecos Office)
    Fon: +49.711.460512750
    Fax: +49.711.460512759

  • Miami, USA
    Comelio, Inc. (Regus)
    Fon: +1.305.395.7962
    Fax: +1.305.395.7964

  • Kolkata, India
    Comelio Business Solutions Pvt. Ltd.
    Fon: +9133.4601.4451
    Fax:+9133.4601.4452

Dynamische .NET-GUIs

Comelio Forschung und Entwicklung Softwareentwicklung dynamische GUIInformationssysteme zeichnen sich dadurch aus, dass sie im Wesentlichen eine Benutzerschnittstelle für die Eingabe und Bearbeitung von relational zerlegten Datenstrukturen bieten. Tabellen, Sichten und teilweise auch Prozeduren werden in Form von Formularen angeboten, die für die typischen Aufgaben erstellen, löschen und aktualisieren.

Jahr

2007-2008

Partner

Fachhochschule Friedberg-Gießen

Finanzierung

Comelio GmbH

Ergebnis

  • Anforderungsanalyse und Datemodellierung
  • Prototypen für die Generierung von Formularen aus XML Schema und relationalen Datenbanken
  • Software GUI Generator zur Erstellung und Anzeige von dynamischen Oberflächen/Formularen auf Basis einer Datenquelle
Beteiligte Parteien

Fachliches Modell,
Softwareumsetzung, Finanzierung

Comelio GmbH, Essen

Wissenschaftliche Begleitung

Hochschule für Philosophie München

 

Comelio Forschung und Entwicklung Softwareentwicklung dynamische GUIDieses Forschungsprojekt beschäftigt sich mit den Möglichkeiten, der automatisierten Erzeugung von Oberflächen für Desktop-Anwendungen. Die erzeugten Oberflächen sollen als Prototypen dienen und nur die zu diesem Zweck benötigte Funktionalität enthalten. Als Ausgangsbasis für die Generierung dienen eine XML-Datei oder eine relationale Datenbank, welche das Datenmodell der zu erstellenden Anwendung enthält. Beide enthalten die nötigen Definitionen für Elementbenennung, Datentypen, Hierarchien und Häufigkeiten. Diese Strukturinformation kann entweder nach einem XML Schema manuell geschrieben werden, oder sie wird aus vorhandenen Informationen aus dem Datenmodell durch einen Algorithmus auf Basis unterschiedlicher Annahmen über die notwendige Oberfläche automatisch erzeugt. Sofern die Oberfläche mit XML beschrieben wird, besteht die beiden Möglichkeiten, direkt XML Schema oder ein speziell für Oberflächen entwickeltes und ausgerichtetes XML-Format zu verwenden. Das mögliche XML Schema zur Definition eines XML-Formats von Oberflächen wird ebenfalls im Rahmen dieser Arbeit erarbeitet.

Hier finden eine lauffähige Version des Comelio GUI-Generators, der .NET-Quelltext aus XML Schema und dem MS SQL Server erzeugt sowie Oberflächen direkt anzeigen kann.

comelio

Verwendung

Comelio Forschung und Entwicklung Softwareentwicklung dynamische GUI VerwendungAls Einsatzgebiet für ein fertiges Programm sind vor allem Geschäftsanwendungen zu nennen, die in der Regel eine große Anzahl von Eingabeformularen enthalten. Diese Formulare haben oft einen standardisierten Aufbau, der sich in allen Formularen widerspiegelt, auch wenn sie der Eingabe unterschiedlicher Daten dienen. Die Gestaltung solcher Formulare erfordert einigen Aufwand, wobei der Aufbau immer mit dem Kunden, der diese später benutzen soll, abgesprochen werden muss. Auch kann der Aufbau sich im Laufe des Entwicklungsprozesses der Software verändern. Nicht selten werden die Felder der Formulare direkt aus einer Datenbank übernommen. Anwendungen, die im Wesentlichen eine grafische Benutzerschnittstelle zu einer Datenbank abbilden, sollen im Fokus der Untersuchung stehen. Da alle zur Verarbeitung nötigen Zusatzinformationen wie Datentypen und ihre Begrenzungen, Schlüsselinformationen oder Beziehungen zwischen Tabellen bereits in der Datenbank vorhanden sind, bietet sich dieser Fall besonders für die automatisierte Erzeugung einer GUI an. Die Verwendung eines solches Algorithmus, der in einem eigenen .NET-Programm umgesetzt werden soll, ist insbesondere in der Phase der Anforderungsanalyse zu Beginn des Projekts, bei der Erstellung eines Prototyps im Rahmen eines Rapid Prototypings zu sehen. Die Verwendung einer solchen Technik zur Laufzeit kann ein möglicher Zukunftsschritt sein, hat allerdings den Nachteil, bei einer klassischen Desktop-Anwendung im Gegensatz zu einer Web-Anwendung schlechtes Laufzeitverhalten aufzuweisen.

comelioDie entstandene Software soll bei Kundengesprächen in der ersten Phase eines Projekts zum Einsatz kommen, um Datenstrukturen und benötigte Datenfelder festzulegen und eine möglichst programmorientierte Visualisierung im Kundengespräch zu verwenden. Die Erfahrung zeigt, dass gerade bei mittelständischen Kunden, die keine voll ausgebauten Prozesse der IT-Beschaffung und Softwareplanung für den eigenen Bedarf besitzen, zwar Anforderungen, die die Oberfläche anbetreffen, sehr genau und auch frühzeitig bei der Planung bekannt geben, bei der Planung der Datenstrukturen aber zu wenig kritisch sind. Hier ist es nicht zweckdienlich, ER-Diagramme oder Datenbankmodelle in Form von Tabellen oder sonst wie aufbereiteten Tabellen-Feld-Listen zu verwenden und diese bestätigen zu lassen. Die Gefahr, dass zu schnell Bestätigungen erfolgen, ist sehr hoch. Im Regelfall kann das dazu führen, dass später bei der Erstellung der Oberfläche, die genau auf Basis der Datenstrukturen erfolgt, Formularfelder erwartet oder angemahnt werden, die überhaupt nicht auf Grundlage der Datenstruktur möglich wären. Dies hat dann wiederum Revisionen der Datenstruktur zur Folge. Als Lösung kann man Beispielformulare entwickeln und zeichnen, was allerdings langwierig ist und zwangsläufig dazu führt, dass diese Entwürfe nach Umsetzung keinen Wert mehr darstellen.

Als Lösung für dieses häufig anzutreffende Problem schlägt dieses Buch nun den Weg vor, sich doch wieder auf die Datenstrukturen und das Datenbankmodell zu konzentrieren. Dieses wird in Gesprächen und Planungen permanent weiter entwickelt und wird auch nicht nach der Planungsphase umgesetzt und schließlich verworfen. Der GuiGenerator soll genau für diesen Einsatzbereich eine Lösung bieten: Man arbeitet konsequent am Datenmodell, das auch später noch Verwendung finden kann. Gleichzeitig hat man aber die Möglichkeit, aus der Datenschicht prototypische Formulare zu erzeugen, die im Rahmen von Kunden- und Beratungsgesprächen nutzbar sind und auf Änderungen der Datenstrukturen unmittelbar reagieren können. Durch die Verwendung von .NET-Oberflächenelementen hat man darüber hinaus sogar noch den Vorteil, dass der grafische Eindruck besser ist als bei MS Visio-Zeichnungen und der Zeitaufwand geringer als bei der Erstellung von tatsächlichen Formularen im Visual Studio.

Grundprinzip der dynamischen GUI-Erzeugung für Prototypen

Vorgehen

Comelio Forschung und Entwicklung Softwareentwicklung dynamische GUI VerwendungDie Anwendungen, die im Normalfall hier betrachtet werden sollen, benutzen als persistenten Datenspeicher weniger das Dateisystem und XML, sondern vielmehr relationale Datenbanken. Für die anvisierten .NET-Anwendungen ist dies dann in der Regel der MS SQL Server in Version 2005. Die grundsätzlichen Überlegungen gelten allerdings für viele andere Datenbanken auch. Hier geht man davon aus, dass auf Basis der Datenstruktur, wie sie sich innerhalb der Datenbank in Form von Tabellen und Sichten präsentiert, die Oberfläche in all den Bereichen sehr gut zu erstellen ist, wenn die Tabellen entsprechend Geschäftsobjekte abbilden. Aus dem oben kurz erwähnten Beispiel mit Vorgang, Angebot und Rechnung könnte man sich unmittelbar die entsprechenden Tabellen vorstellen, welche sich wiederum in Formularen für die Erfassung eines Datensatzes niederschlagen. Diese enthalten dann im einfachsten Fall alle Spalten als Formularelemente außer Primär- und Fremdschlüssel sowie berechnete Spalten (spezielle Variante im MS SQL Server), die eine Sonderbehandlung benötigen.

Für die Extraktion der relationalen Struktur aus der Datenbank gibt es unterschiedliche Möglichkeiten. Hier geht man davon aus, dass man in einer .NET-Programmiersprache mit ADO.NET, in Java mit JDBC und in PHP bspw. mit PDO (PHP Data Objects) oder in allen Programmiersprachen direkt auf den Systemkatalog zugreift, um die Datenstrukturen abzurufen. Wie schon im Rahmen der Vorstellung, XML Schema einzusetzen, erhält man die Datenstruktur, aus der dann mit geeigneten Algorithmen der benötigte Quelltext oder unmittelbar die Oberfläche generiert wird. Dabei lässt sich einfach vorstellen, wie die relationale Struktur aus den diversen Systemkatalog- oder Metadatenabfragen in eine Objektstruktur überführt wird, welche für die Formular-/Quelltexterstellung genutzt wird.

Verfahren zur GUI-Erzeugung

In der zweiten Abbildung ist eine Erweiterung der zuvor diskutierten Lösung zu sehen. Hier erstellt man aus der relationalen Datenstruktur über die erwähnten Fähigkeiten zunächst ein XML-Format. Dieses kann entweder ein eigenes XML-Format für (relationale) Datenstrukturen oder – was wahrscheinlicher ist - XML Schema sein. Es wäre allerdings auch möglich, direkt bei der Extraktion der Datenstrukturen ein XML-Format zu erzeugen, das in der Lage ist, eine GUI zu beschreiben. Die Erzeugung eines XML Schema-Formats ist insoweit interessant, weil es sich dabei um ein bestehendes, standardisiertes Datenbeschreibungsformat handelt, in dem alle Angaben, die in einer Datenbank getroffen werden können, auch angegeben werden können. Darüber hinaus entspricht es dem Gedanken, die Oberfläche auf Basis einer Datenstruktur zu erzeugen und lässt sich bspw. mit solchen einfachen Technologien wie XSLT in andere XML-Formate oder sogar unter Umständen auch zu C#-Quelltext umwandeln. Dies ist allerdings aufgrund der Komplexität des zu erzeugenden Formats und aufgrund der Notwendigkeit, die Umwandlung in einem .NET-Programm auszuführen, nur bedingt empfehlenswert.

Verfahren zur GUI-Erzeugung

Wesentlich ist beim Einsatz von XML Schema oder dem direkten Abruf der Datenstruktur aus einer Datenbank (mit und ohne Umwandlung in XML Schema), dass im Gegensatz zu der Vorgehensweise, ein proprietäres Format für die Beschreibung der Oberfläche zu verwenden, nur Heuristiken genutzt werden können, um eine Oberfläche zu erstellen. Es sind relativ viele Annahmen zu treffen, die insbesondere bei der Nutzung einer Datenbank aufgrund ihrer fehlenden Eigenschaft, Datenhierarchien innerhalb einer Felderliste abzubilden, zu Buche schlagen. Auf die Möglichkeit, objektrelationale Datenbanken zu berücksichtigen, wird nicht näher eingegangen, da sie bisher keine große Verbreitung gefunden haben. Sie würden allerdings ähnliche Fähigkeiten wie XML Schema bieten.

Software-Lösung

Comelio Forschung und Entwicklung Softwareentwicklung dynamische GUI SoftwareDie entstandene Software GuiGenerator bietet zahlreiche Einsatzmöglichkeiten und kann daher in der Planungsphase realer Projekte bereits erfolgreich eingesetzt werden. Der GuiGenerator stellt gewissermaßen eine Oberfläche zur Nutzung der entwickelten Klassenbibliothek dar. Die Oberfläche wurde vor allem zum Testen und zur Präsentation der verschiedenen Funktionen entwickelt. Für den Einsatz in realen Projekten sollte sie daher noch weiter verfeinert werden. Das Datenbankmodul der Anwendung, der mit den restlichen Funktionen kaum in Verbindung steht, ließe sich eventuell auch zu einer eigenen Anwendung ausgliedern.
nsbesondere die Erstellung einer funktionsfähigen Oberfläche aus einer Datenbank lässt sich bereits als Anschauungsobjekt für Kunden einsetzen. Einzige Voraussetzung ist das Vorhandensein einer ersten Version der Datenbank. Diese kann unter Zuhilfenahme eines entsprechenden Tools zur visuellen Datenbankmodellierung bequem erstellt und nach und nach verfeinert werden.

Es hat sich gezeigt, dass die in der Datenbank enthaltenen Informationen über das Datenmodell ausreichend sind, um eine einfache Oberfläche zur Darstellung der Daten zu generieren. Außerdem hat sich gezeigt, dass es durch die Fähigkeiten von ADO.NET 2.0 auch möglich ist, in der generierten Oberfläche tatsächlich (Test-)Daten einzugeben und zu editieren. Diese Fähigkeit könnte bei Bedarf noch weiter ausgebaut und verfeinert werden, um eine wirklich bequeme Bearbeitung von Daten zuzulassen. Andererseits können gerade die Probleme, die beim Verwenden der generierten Oberfläche zum Datenzugriff auftreten, wichtige Hinweise für die Entwickler liefern, welche Punkte bei der Entwicklung einer echten Oberfläche besonders berücksichtigt werden müssen. Man kann sich auf Basis der Software fragen, für welche Felder eine spezielle Validierung des eingegebenen Datenformats nötig ist oder für welche Felder eine Auswahl aus Werten einer anderen Tabelle vorgesehen werden muss (Fremdschlüssel).

Sollen einzelne Oberflächen modelliert werden, können diese entweder direkt als XML-Datei im entsprechenden Format oder in Form eines XML Schema-Dokuments modelliert werden. Da die Bearbeitung des XML-GUI-Formats sich jedoch als sehr aufwändig herausgestellt hat, ist es wesentlich einfacher, das Formular in einem Schema-Dokument zu definieren und dieses Dokument zu importieren. Das Formular als XML Schema ist in diesem Fall identisch mit der im Formular dargestellten Datenstruktur.

Beim Import bestehender Schema-Dokumente hat sich herausgestellt, dass die enthaltenen Informationen nicht immer für die Erzeugung einer optimalen Oberfläche ausreichend sind. Enthalten XML Schema-Dokumente mehrere Elemente auf der obersten Ebene, die gleichberechtigt als Wurzelelement verstanden werden könnten, ist es z.B. nicht möglich herauszufinden, welches von diesen Elementen tatsächlich als Ausgangspunkt für die Oberflächengenerierung dienen soll. Ein XML Schema-Prozessor würde hier in einer Programmiersprache wie .NET oder Java entweder ein XML-Instanzdokument zum Vergleich fordern oder die direkte Nennung des Wurzelelements erwarten. Dieses Problem wurde durch eine Möglichkeit zum Benennen des Ausgangselements gelöst, wie es auch in verschiedenen Programmiersprachen umgesetzt ist. Probleme bereiten aber auch größere Schema-Dokumente, deren Inhalt nicht mehr übersichtlich auf einem Formular angezeigt werden kann. Die Grenze, ab der ein Formular überladen wirkt, ist sehr schnell erreicht. Ein Formular, bei dem einige Steuerelemente nur durch Scrollen des Fensters verwendet werden können, gilt bei vielen Benutzern als unpraktisch und sollte vermieden werden.

Im Bezug auf den Schema-Import wären also weitere Regeln oder manuelle Einflussmöglichkeiten des Benutzers im Hinblick auf eine Aufteilung eines Schemas auf mehrere Formulare erstrebenswert. Gleiches gilt auch für die Zusammenfassung mehrerer Formulare aus unterschiedlichen Schema-Dateien zu einer Anwendung und das Zusammenwirken zwischen diesen Formularen.

Bildschirmfotos vom GuiGenerator