Konzeption eines Frameworks zur Erstellung von grafischen Benutzerschnittstellen mit der IDE Powerbuilder

Inhaltsverzeichnis

1 Einführung
1.1 Inhalt
1.2 Motivation
1.3 Begrifflichkeiten
1.3.1 Muster
1.3.2 Framework
1.4 Rahmenbedingungen
1.4.1 IDE PowerBuilder®
1.4.2 Softwaresystem LEASMAN®

2 Model View Controller
2.1 Document View Modell
2.2 MVC2 Modell

3 Beobachter Muster

4 Fabrikmethode

5 Framework Konzeption

6 Implementierung unter PowerBuilder®
6.1 AbstractModel::addModelListener()
6.2 AbstractModel::removeModelListener() .
6.3 AbstractModel::modelChanged()

7 Prototyp

8 Fazit und Ausblick

Abbildungsverzeichnis

Literaturverzeichnis

1 Einführung

1.1 Inhalt

Der Schwerpunkt dieser Arbeit liegt in der Konzeption eines Frameworks für grafische Benutzerschnittstellen unter Verwendung etablierter Entwurfsmuster. Ausgangspunkt dafür bildet die Behandlung des Model View Controller (MVC) Entwurfsmusters, dessen Grundgedanken bereits 1979 von Trygve Reenskaug für die Beschreibung von Benutzerschnittstellen in Smalltalk entwickelt wurde. Von diesem Zeitpunkt an bis heute etablierte sich das MVC Muster als quasi de facto Standard für den Entwurf komplexer Softwaresysteme und ist damit Anlass, sich mit dessen Entwicklung und praxisorientierten Einsatz auseinan- der zu setzen. Die eingeführten Begriffe Model, View und Controller werden definiert und deren Interaktionssituationen schematisiert. Damit einhergehen- de Softwaretechnisch zu lösende, Problemsituationen bedingen den zusätzli- chen Einsatz weiterer Entwurfsmuster, wie dem Beobachtermuster und der Fabrikmethode, welche ebenfalls studiert und in das Framework Konzept ein- fließen werden. Darauf aufbauend wird, unter Berücksichtigung der aktuellen Entwicklungen und vorliegenden Rahmenbedingungen, dieses Konzept weiter spezialisiert, mit der Zielsetzung letztlich, die generelle Machbarkeit in Form eines GUI Frameworks durch den abstrakten Klassenentwurf einer Model- und Viewkomponente innerhalb der IDE PowerBuilder® zu zeigen.

1.2 Motivation

Meist historisch bedingt, sorgt der ständige Fortschritt und die Etablierung neuer Technologien für ein immer größer werdendes Einsatzgebiet mit komple- xeren Anforderungen an moderne Softwaresysteme. Diese stellen heute nicht mehr nur eine softwaretechnische Abbildung eines konkreten Anwendungsfalles oder eines Geschäftsprozesses dar, sondern sie haben viel mehr den Charakter einer Infrastruktur, indem mehrere Systeme miteinander kooperieren.

Um den damit verbundenen Erweiterungsaufwand weiterhin gerecht zu werden, betreibt die DELTA proveris AG mit Sitz in Limbach-Oberfrohna, ein aufwendiges Refactoring des Softwaresystems LEASMAN® und fördert damit diese Studienarbeit. Im Rahmen dieses Refactoring Prozesses und der damit verbundenen technologischen Weiterentwicklung sollen die Abhängigkeiten zwischen zugrunde liegender Funktionalität auf der einen und Benutzerschnittstelle auf der anderen Seite minimiert werden.

1.3 Begrifflichkeiten

1.3.1 Muster

Muster (engl. Pattern) bedeutet im wörtlichen Sinne eine gleich bleibende Struktur und stellt im übertragenen Sinne ein praktisch bewährtes Lösungs- schema, in Form einer Dokumentation, für bekannte Probleme der Software- entwicklung dar.

Geprägt wurde der Begriff 1977 vom Architekturprofessor Christopher Alex- ander an der University of California in Berkley durch seine Theorien über Muster in der Architektur und dessen Ergebnisse in Form einer guage“ [AM99]. Die ”PatternLan- ”Viererbande“(engl.GangofFour)veröffentlichte1995 das Werk [GoF95], welches als Initiator des öffentlichen Interesses an Mustern in der Softwareentwicklung angesehen werden kann.

Das Hauptaugenmerk von Mustern liegt dabei in der Wiederverwendbarkeit des Problemwissens und es werden die Architekturmuster, Entwurfsmuster und Idiome unterschieden. Der formelle Aufbau eines Musters sollte mindestens der Gliederung nach Kontext, Problembeschreibung und Lösungsschema genügen, was auch als Alexandrian Form bezeichnet wird. Die ”Viererbande“struktu- riert wesentlich feiner und enthält neben den bereits genannten Gliederungs- punkten weitere wie Synonyme, Motivation, Anwendbarkeit, Implementierung, Beispielcode und Praxiseinsatz. Meist wird sich jedoch, je nach Autor und Problemsituation, nur an deren Gliederungen angelehnt und für die speziellen Bedürfnisse adaptiert [PSA98]. Der grundlegende Aufbau spiegelt sich auch in der kurzen Definition ”LösungfüreinProblemimKontext“[AM99]wieder.

Nicht minder wichtig ist eine konkrete Benennung der Muster, im Sinne ei- ner praktikablen Katalogisierung sowie einer vereinfachten Kommunikation im Fachvokabular der Softwareingenieure.

Die Anwendung von Mustern unterliegt letztlich aber immer einem gewissen Freiheitsgrad und sollte als Vorschlag, nicht als Vorschrift angesehen werden. Der Vergleich mit einem Kochrezept bringt es auf den Punkt. Wahllose Zu- sammenstellung verschiedener Rezepte zu einem Menü macht dieses ebenso wenig schmackhaft, wie die Anwendung zahlreicher Muster einen guten Soft- wareentwurf ausmacht. Die Anpassung an individuelle Rahmenbedingungen sollte daher bei der Anwendung von Mustern berücksichtigt werden.

1.3.2 Framework

Die Wiederverwendbarkeit und Wartbarkeit spielen bei der Entwicklung kom- plexer Softwaresysteme eine wesentliche Rolle und werden grundlegend durch die Objektorientierte Programmierung unterstützt. Kapselung von Daten und Methoden, Instanziierung und Vererbung sind zentrale Begriffe dieses Para- digmas und ermöglichen die Wiederverwendung des zugrunde liegenden Quell- codes.

Ein Framework baut darauf auf und stellt einen wiederverwendbaren System- entwurf dar. Damit enthält dieses, neben dem eigentlichen Quellcode, auch die Steuerung des Kontrollflusses zwischen den in ihm enthaltenen Komponenten und spiegelt damit die Architektur des darauf aufbauenden Systems wieder. Eine Definition des Frameworkbegriffes soll an dieser Stelle aus [GoF95] über- nommen werden.

”A set of cooperating classes that makes up a reusable design for a specific class of software. A framework provides architectural guidance by partitioning the design into abstract classes and defining their responsibilities and collaborations. A developer customizes the framework to a particular application by subclassing and composing instances of framework classes.“

Ein Framework besteht in der Summe also aus konkreten und abstrakten Klas- sen. Der wesentliche Unterschied, gegenüber einer funktionalen Gliederung in Bibliotheken, wird aus Sicht des Entwicklers wesentlich deutlicher und stellt sich wie folgt dar. Komponenten werden durch den Entwickler in einer Haupt- funktionmain()aufgerufen, wobei der Kontrollfluss durch die Hauptfunktion vom Entwickler definiert ist. Ein Framework stellt im Gegensatz dazu selbst die Hauptfunktion dar und der Entwickler kann diese erweitern und an seine individuellen Bedürfnisse anpassen, wobei das Gerüst der Hauptfunktion wie- derverwendet wird.

Die Vorteile liegen auf der Hand. Entwicklung neuer Komponenten auf Basis eines Frameworks erfolgt zum einen erheblich schneller, da diese im wesentli- chen durch Komposition und Konkretisierung existierender Klassen des Fra- meworks erfolgt. Zum anderen beinhalten die vom Framework zur Verfügung gestellten Klassen bereits eine gewisse Robustheit, da immer wieder genutzte Funktionalität wie Fehlerbehandlung, Datenaustausch und interner Kontroll- fluss wiederverwendet und nicht erneut entwickelt werden muss. Die Produkti- vität der Entwicklung von konkreten Anwendungssystemen wird durch Frame- works erheblich gesteigert. Die Entwicklung des Frameworks selbst ist jedoch ein aufwendiger, von umfangreichen und wiederkehrenden Reorganisationen geprägter Prozess.

Verschiedene Typen von Frameworks, wie bspw. Application Frameworks oder Graphical User Interface (GUI) Frameworks unterscheidet man im wesentli- chen nach dessen Einsatzgebiet. Application Frameworks sind für allgemeine Anwendungen von Bedeutung. Als klassische Vertreter hiervon sind die Micro- soft Foundation Classes (MFC) und die PowerBuilder® Foundation Classes (PFC) zu nennen. Das in dieser Arbeit auf Basis des MVC Musters entwickelte Framework, zählt zu der Klasse der GUI Frameworks und verfolgt damit vor- rangig das Ziel, eine Architektur für wieder verwendbare GUI Elemente bereit zu stellen.

1.4 Rahmenbedingungen

1.4.1 IDE PowerBuilder®

Für das Produkt LEASMAN® wird neben zahlreichen weiteren Entwicklungs- begleitenden Tools im wesentlichen die Entwicklungsumgebung PowerBuilder® der Firma Sybase, aktuell in der Version 10, eingesetzt. Die Geschichte von PowerBuilder® ist auf die im Jahre 1974 gegründete Firma Computer Solu- tions Inc. (CSI), welche bis in die frühen 90er Jahre hauptsächlich ein Manu- facturing Resource Planning (MRP) System vertrieb, zurück zu führen. Mit Etablierung der grafischen Benutzerschnittstellen durch Microsoft Windows gerieten die bis dahin üblichen textuellen Benutzerschnittstellen der legendären 80x24 Auflösung in den Hintergrund.

Auf der Suche nach Tools und Techniken zur Entwicklung grafischer Benutzer- schnittstellen existierte zum damaligen Zeitpunkt ausschließlich die Program- miersprache C. Dave Litwack und Mitchell Kertzman waren schließlich die Initiatoren der Entwicklung eines einfach zu bedienenden Client/Server Tools für die Kommunikation mit den bekanntesten Relationalen Datenbank Mana- gement Systemen Oracle und Sybase. Im August 1990 wurde die Beta Version 1.0 von PowerBuilder® unter dem Codenamen ”Headstart“durchPowersoft veröffentlicht und die zahlreiche Beteiligung von namhaften Unternehmen, wie American Airlines, Microsoft, 3M, Fidelity Investments, Coca-Cola und vielen mehr, war viel versprechend. Das offizielle PowerBuilder® 1.0 Release wurde im Juli 1991 freigegeben und die Erfolgsgeschichte zeichnete sich bereits in den ersten 6 Monaten am Umsatz von 5,2 Millionen Dollar ab. Ein Jahr später wurde Version 2.0 veröffentlicht und der Umsatz stieg im Jahr 1992 auf 22,1 Millionen Dollar. Die weitere rasante Umsatzentwicklung (57 Millionen Dol- lar im Jahre 1993 und 133 Millionen Dollar 1994) lies Investoren aufmerksam werden und letztlich wurde Powersoft am 13. Februar 1995 von Sybase für 904 Millionen Dollar gekauft. Bis 1996 genoss PowerBuilder® eine führende Stellung im Client/Server Bereich. Die Etablierung integrierter Entwicklungs- umgebungen, wie bspw. Visual Basic oder Borland Delphi, deren wachsende Anzahl von Entwickler schnell die von PowerBuilder® überstieg, drängten diesen in den folgenden Jahren jedoch mehr und mehr in den Hintergrund. Auch die rasante Entwicklung des Internets und das Heranwachsen der Dot- com Blase sorgte für mehr Interesse an Web-Projekten. Nichtsdestotrotz wurde PowerBuilder® stetig weiter entwickelt und auch aktuelle Technologien, wie XML oder Webservices, können in der verwendeten Version 10 genutzt werden. [LANI]

Resümierend kann man sagen, dass es sich im Wesentlichen um eine Integra- ted Development Environment (IDE) der Fourth generation language (4GL) handelt, dessen Hauptvorteil in der patentierten Datawindow-Technologie zu sehen ist.

1.4.2 Softwaresystem LEASMAN®

”DasKomplettsystemLEASMAN R○ist eine auf die Bedürfnisse von Leasing- gesellschaften zugeschnittene Verwaltungssoftware, die alle betriebswirtschaft- lichen Ansprüche berücksichtigt.“ [DEPAG]

Seit Gründung der DELTA project GmbH im Jahre 1994 und dem Beginn der Entwicklungsarbeiten an LEASMAN® im Jahre 1997 kann die mittlerwei- le umfirmierte DELTA proveris AG auf ein gesundes und stetiges Wachstum zurückblicken. Die kontinuierliche Weiterentwicklung, auf Basis des Firmenleit- bildes DEPAG (Dialog, Effektivität, Potenzial, Anspruch und Glaubwürdig- keit), machte LEASMAN® zu dem was es heute ist, zur ”zukunftsfähigen Standardlösung der gesamten Kfz-Leasingbranche“. [DEPAG]

Ausgangspunkt war die Entwicklung einer klassischen Client/Server Anwen- dung mit einem Informix Dynamic Server (IDS) als Datenbank und den Clien- ten in Form einer Multiple Document Interface (MDI) Applikation. Die rasante Entwicklung im Bereich der Informationstechnologie und dem damit verbun- denen Bedarf, bewährte Lösungen durch neue Technologien stets auf dem ak- tuellen Stand der Technik zu halten, sind Gründe für den Architekturwandel hin zu einer Mehrschichtenarchitektur. Eine vereinfachte Darstellung dieser Architektur veranschaulicht das in Abbildung 1 dargestellte Schalenmodell.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Schalenmodell der LEASMAN® Architektur

Das Hauptaugenmerk der im folgenden behandelten Entwurfsmuster dient der Umsetzung eines auf dem Model View Controller Muster basierenden Frameworks, welches zwischen Benutzerschnittstelle und Serviceschicht ansetzen, da die Konzeption des Frameworks auf wiederverwendbare GUI Elemente für die IDE PowerBuilder® abzielt. Zuerst müssen allerdings das Muster selbst und deren unterschiedliche Ausprägungen studiert werden.

2 Model View Controller

Um die verwendeten Begrifflichkeiten präzise zu definieren, bietet es sich an, aus dem Original von Trygve Reenskaug zu zitieren und anschließend das Zusammenspiel der einzelnen Komponenten zu schematisieren.

”Modelsrepresentknowledge.Amodelcouldbeasingleobject(ratheruninte- resting), or it could be some structure of objects. There should be a one-to-one correspondence between the model and its parts on the one hand, and the re- presented world as perceived by the owner of the model on the other hand. The nodes of a model should therefore represent an identifiable part of the problem. The nodes of a model should all be on the same problem level, it is confusing and considered bad form to mix problem-oriented nodes (e.g. calen- dar appointments) with implementation details (e.g. paragraphs).

A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a pre- sentation filter. A view is attached to its model (or model part) and gets the data necessary for the presentation from the model by asking questions. It may also update the model by sending appropriate messages. All these questions and messages have to be in the terminology of the model, the view will there- fore have to know the semantics of the attributes of the model it represents. (It may, for example, ask for the model’s identifier and expect an instance of Text, it may not assume that the model is of class Text.)

A controller is the link between a user and the system. It provides the user with input by arranging for relevant views to present themselves in appro- priate places on the screen. It provides means for user output by presenting the user with menus or other means of giving commands and data. The con- troller receives such user output, translates it into the appropriate messages and pass these messages on .to one or more of the views. A controller should never supplement the views, it should for example never connect the views of nodes by drawing arrows between them. Conversely, a view should never know about user input, such as mouse operations and keystrokes. It should always be possible to write a method in a controller that sends messages to views which exactly reproduce any sequence of user commands.

[...]