Inhaltsverzeichnis

1  Einf uhrung  1

1.1  Inhalt  1

1.2  Motivation  1

1.3  Begrifflichkeiten  2

1.3.1  Muster  2

1.3.2  Framework  3

1.4  Rahmenbedingungen  5

   5

1.4.1  IDE PowerBuilder R  

   6

1.4.2  Softwaresystem LEASMAN R  

2  Model View Controller  7

2.1  Document View Modell  13

2.2  MVC2 Modell  14

3  Beobachter Muster  15

4  Fabrikmethode  17

5  Framework Konzeption  19

6  Implementierung unter PowerBuilder R  

   21

6.1  AbstractModel::addModelListener()  23

6.2  AbstractModel::removeModelListener()  25

6.3  AbstractModel::modelChanged()  25

7  Prototyp  26

8  Fazit und Ausblick  29

Abbildungsverzeichnis   31

Literaturverzeichnis   33

1 Einf¨ uhrung

1.1 Inhalt

Der Schwerpunkt dieser Arbeit liegt in der Konzeption eines Frameworks f¨ ur grafische Benutzerschnittstellen unter Verwendung etablierter Entwurfsmuster. Ausgangspunkt daf¨ ur bildet die Behandlung des Model View Controller (MVC) Entwurfsmusters, dessen Grundgedanken bereits 1979 von Trygve Reenskaug f¨ ur 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¨ ur den Entwurf komplexer Softwaresysteme und ist damit Anlass, sich mit dessen Entwicklung und praxisorientierten Einsatz auseinander zu setzen. Die eingef¨ uhrten Begriffe Model, View und Controller werden definiert und deren Interaktionssituationen schematisiert. Damit einhergehende Softwaretechnisch zu l¨ osende, Problemsituationen bedingen den zus¨ atzlichen Einsatz weiterer Entwurfsmuster, wie dem Beobachtermuster und der Fabrikmethode, welche ebenfalls studiert und in das Framework Konzept einfließen werden. Darauf aufbauend wird, unter Ber¨ ucksichtigung 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

zu zeigen. Viewkomponente innerhalb der IDE PowerBuilder R

1.2 Motivation

Meist historisch bedingt, sorgt der st¨ andige Fortschritt und die Etablierung neuer Technologien f¨ ur ein immer gr¨ oßer werdendes Einsatzgebiet mit komplexeren Anforderungen an moderne Softwaresysteme. Diese stellen heute nicht mehr nur eine softwaretechnische Abbildung eines konkreten Anwendungsfalles oder eines Gesch¨ aftsprozesses dar, sondern sie haben viel mehr den Charakter einer Infrastruktur, indem mehrere Systeme miteinander kooperieren.

1

Um den damit verbundenen Erweiterungsaufwand weiterhin gerecht zu werden, betreibt die DELTA proveris AG mit Sitz in Limbach-Oberfrohna, ein

und f¨ ordert daaufwendiges Refactoring des Softwaresystems LEASMAN R

mit diese Studienarbeit. Im Rahmen dieses Refactoring Prozesses und der damit verbundenen technologischen Weiterentwicklung sollen die Abh¨ angigkeiten zwischen zugrunde liegender Funktionalit¨ at auf der einen und Benutzerschnittstelle auf der anderen Seite minimiert werden.

1.3 Begrifflichkeiten

1.3.1 Muster

Muster (engl. Pattern) bedeutet im w¨ ortlichen Sinne eine gleich bleibende Struktur und stellt im ¨ ubertragenen Sinne ein praktisch bew¨ ahrtes L¨ osungsschema, in Form einer Dokumentation, f¨ ur bekannte Probleme der Softwareentwicklung dar.

Gepr¨ agt wurde der Begriff 1977 vom Architekturprofessor Christopher Alex-ander an der University of California in Berkley durch seine Theorien ¨ uber

Muster in der Architektur und dessen Ergebnisse in Form einer ” Pattern Language“ [AM99]. Die ” Viererbande“ (engl. Gang of Four) ver¨ offentlichte 1995 das Werk [GoF95], welches als Initiator des ¨ offentlichen 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¨ osungsschema gen¨ ugen, was auch als Alexandrian Form bezeichnet wird. Die ” Viererbande“ struktu-

riert wesentlich feiner und enth¨ alt neben den bereits genannten Gliederungspunkten 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¨ ur die speziellen Bed¨ urfnisse adaptiert [PSA98]. Der grundlegende Aufbau spiegelt sich auch in

2

der kurzen Definition ” L¨ osung f¨ ur ein Problem im Kontext“ [AM99] wieder. Nicht minder wichtig ist eine konkrete Benennung der Muster, im Sinne einer 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 Zusammenstellung verschiedener Rezepte zu einem Men¨ u macht dieses ebenso wenig schmackhaft, wie die Anwendung zahlreicher Muster einen guten Softwareentwurf ausmacht. Die Anpassung an individuelle Rahmenbedingungen sollte daher bei der Anwendung von Mustern ber¨ ucksichtigt werden.

1.3.2 Framework

Die Wiederverwendbarkeit und Wartbarkeit spielen bei der Entwicklung komplexer Softwaresysteme eine wesentliche Rolle und werden grundlegend durch die Objektorientierte Programmierung unterst¨ utzt. Kapselung von Daten und Methoden, Instanziierung und Vererbung sind zentrale Begriffe dieses Paradigmas und erm¨ oglichen die Wiederverwendung des zugrunde liegenden Quellcodes.

Ein Framework baut darauf auf und stellt einen wiederverwendbaren Systementwurf dar. Damit enth¨ alt 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] ¨ ubernommen 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.“

3

Ein Framework besteht in der Summe also aus konkreten und abstrakten Klassen. Der wesentliche Unterschied, gegen¨ uber 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 Hauptfunktion main() 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¨ urfnisse anpassen, wobei das Ger¨ ust der Hauptfunktion wiederverwendet wird.

Die Vorteile liegen auf der Hand. Entwicklung neuer Komponenten auf Basis eines Frameworks erfolgt zum einen erheblich schneller, da diese im wesentlichen durch Komposition und Konkretisierung existierender Klassen des Fra-meworks erfolgt. Zum anderen beinhalten die vom Framework zur Verf¨ ugung gestellten Klassen bereits eine gewisse Robustheit, da immer wieder genutzte Funktionalit¨ at wie Fehlerbehandlung, Datenaustausch und interner Kontrollfluss wiederverwendet und nicht erneut entwickelt werden muss. Die Produktivit¨ at 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¨ agter Prozess.

Verschiedene Typen von Frameworks, wie bspw. Application Frameworks oder Graphical User Interface (GUI) Frameworks unterscheidet man im wesentlichen nach dessen Einsatzgebiet. Application Frameworks sind f¨ ur allgemeine Anwendungen von Bedeutung. Als klassische Vertreter hiervon sind die Micro-Foundation Classes soft Foundation Classes (MFC) und die PowerBuilder R

(PFC) zu nennen. Das in dieser Arbeit auf Basis des MVC Musters entwickelte Framework, z¨ ahlt zu der Klasse der GUI Frameworks und verfolgt damit vorrangig das Ziel, eine Architektur f¨ ur wieder verwendbare GUI Elemente bereit zu stellen.

4

1.4 Rahmenbedingungen 1.4.1 IDE PowerBuilder R

wird neben zahlreichen weiteren Entwicklungs-F¨ ur das Produkt LEASMAN R

begleitenden Tools im wesentlichen die Entwicklungsumgebung PowerBuilder R

der Firma Sybase, aktuell in der Version 10, eingesetzt. Die Geschichte von

ist auf die im Jahre 1974 gegr¨ undete Firma Computer Solu-PowerBuilder R

tions Inc. (CSI), welche bis in die fr¨ uhen 90er Jahre haupts¨ achlich ein Manufacturing Resource Planning (MRP) System vertrieb, zur¨ uck zu f¨ uhren. Mit Etablierung der grafischen Benutzerschnittstellen durch Microsoft Windows gerieten die bis dahin ¨ ublichen textuellen Benutzerschnittstellen der legend¨ aren 80x24 Aufl¨ osung in den Hintergrund.

Auf der Suche nach Tools und Techniken zur Entwicklung grafischer Benutzerschnittstellen existierte zum damaligen Zeitpunkt ausschließlich die Programmiersprache C. Dave Litwack und Mitchell Kertzman waren schließlich die Initiatoren der Entwicklung eines einfach zu bedienenden Client/Server Tools f¨ ur die Kommunikation mit den bekanntesten Relationalen Datenbank Management Systemen Oracle und Sybase. Im August 1990 wurde die Beta Version

unter dem Codenamen ” 1.0 von PowerBuilder ^R Headstart“ durch Powersoft

ver¨ offentlicht und die zahlreiche Beteiligung von namhaften Unternehmen, wie American Airlines, Microsoft, 3M, Fidelity Investments, Coca-Cola und vielen

1.0 Release wurde mehr, war viel versprechend. Das offizielle PowerBuilder R

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¨ ater wurde Version 2.0 ver¨ offentlicht und der Umsatz stieg im Jahr 1992 auf 22,1 Millionen Dollar. Die weitere rasante Umsatzentwicklung (57 Millionen Dollar im Jahre 1993 und 133 Millionen Dollar 1994) lies Investoren aufmerksam werden und letztlich wurde Powersoft am 13. Februar 1995 von Sybase f¨ ur

eine f¨ uhrende 904 Millionen Dollar gekauft. Bis 1996 genoss PowerBuilder R

Stellung im Client/Server Bereich. Die Etablierung integrierter Entwicklungsumgebungen, wie bspw. Visual Basic oder Borland Delphi, deren wachsende

5