Entwurfsunterstützung Web-basierter Schnittstellen auf Basis der UML
Werbung
Institut für Informatik Arbeitsgruppe Softwaretechnik Warburgerstr. 100 33098 Paderborn Entwurfsunterstützung Web-basierter Schnittstellen auf Basis der UML Diplomarbeit für den integrierten Studiengang Informatik im Rahmen des Hauptstudiums II von Martin Luther Modjo Kamneng Stemberg 9, 33106 Paderborn E-mail: [email protected] Matr. Nr.: 3275448 vorgelegt bei Prof. Dr. Wilhelm Schäfer und Prof. Dr. Gregor Engels Paderborn, im April 2003 i Danksagung Als erstes möchte ich mich bei meinen Eltern bedanken, die mir die notwendigen Grundlagen des Lebens beigebracht und die nötige Erziehung gegeben haben. Besonders bedanke ich mich bei Frau Rachel Dzukou und Frau Maria Notz, deren Unterstützung mir dieses Studium ermöglicht hat. Weiterer Dank gebührt auch meiner Frau Muriel Peggy, die mir die Abende und Nächte verziehen hat, die ich mit dem Rechner verbracht habe. Ich danke auch meinem Betreuer Jörg Wadsack für seine wertvollen Ratschläge sowie Herrn Prof. Dr. Wilhelm Schäfer für die Erstkorrektur und Herrn Prof. Dr. Engels für die Zweitkorrektur der Arbeit. Außerdem danke ich allen Mitarbeitern der AG-Schäfer für die gute Zusammenarbeit und die angenehme Atmosphäre. Eidesstattliche Erklärung Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe, und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen worden ist. Alle Ausführungen, die wörtlich oder sinngemäß übernommen worden sind, sind als solche gekennzeichnet. Paderborn, 15. April 2003 ________________________ (Martin L. Modjo Kamneng) ii Inhaltsverzeichnis 1. EINLEITUNG ......................................................................................................1 1.1 Motivation..................................................................................................................1 1.2 Ziel der Arbeit ...........................................................................................................2 1.3 Gliederung der Arbeit ..............................................................................................3 2. GRUNDLAGEN ..................................................................................................5 2.1 Web-Applikation.......................................................................................................5 2.1.1 Definition einer Web-Applikation.......................................................................5 2.1.2 Architektur einer Web-Applikation.....................................................................7 2.2 Textauszeichnungssprachen...................................................................................10 2.2.1 HTML................................................................................................................10 2.2.2 XML ..................................................................................................................13 2.2.3 XHTML.............................................................................................................15 2.2.3 XML-Schema ....................................................................................................16 2.3 Serverskripte ...........................................................................................................17 2.3.1 CGI Programme ................................................................................................18 2.3.2 Java-Servlets......................................................................................................18 2.3.3 Java Server Pages ..............................................................................................22 2.3.4 PHP....................................................................................................................24 2.3.5 ASP....................................................................................................................25 2.4 HTML Template .....................................................................................................26 2.5 Unified Modeling Language (UML) ......................................................................27 2.6 Das Werkzeug Fujaba ............................................................................................29 2.6.1 Fujaba UML-Klassendiagramme ......................................................................29 2.6.2 Fujaba Interaktions-Diagramme........................................................................30 3. VERWANDTE ANSÄTZE .................................................................................34 3.1 Das Cocoon Projekt ................................................................................................34 iii 3.2 UML Erweiterung für den Entwurf von Web-Applikationen............................35 3.2.1 Modellierung von Web-Applikationen mit UML .............................................36 3.2.2 Eine UML Erweiterung für den Entwurf von Web-Sites..................................36 3.2.3 Modulare Modellierung von dynamischen Web-Seiten mit UML ..............37 4. MODELLIERUNG VON DYNAMISCHEN WEB-SEITEN MIT UML .................40 4.1 Konzept ....................................................................................................................40 4.1.1 Template Mechanismus.....................................................................................40 4.1.2 Layout-Elemente ...............................................................................................42 4.1.3 DB-Zugriffsschicht............................................................................................44 4.1.4 Die Web-Schnittstelle........................................................................................45 4.2 Technische Umsetzung ...........................................................................................47 4.2.1 UML-Modell für HTML-Elemente...................................................................47 4.2.2 Java-Servlets in Fujaba......................................................................................55 4.2.3 Realisierung der Web-Schnittstelle in Fujaba ...................................................57 4.2.4 Codegenerierung ...............................................................................................63 5. PROTOTYP ......................................................................................................66 5.1 Erstellung der Wissensbank...................................................................................66 5.2 Template Bibliothek................................................................................................67 5.3 Architektur des Diagnosesystems ..........................................................................68 6. ZUSAMMENFASSUNG UND AUSBLICK........................................................77 LITERATURVERZEICHNIS..................................................................................79 ANHANG ..............................................................................................................83 iv Abbildungsverzeichnis Abbildung 1: Beispiel einer Web-Applikation – Das Autogeschäft AutoScout24 ...............1 Abbildung 2: Beispielgraph für ein medizinisches Diagnosesystem [46, S. 16]...................3 Abbildung 3: Basic Web Applikation Architektur ................................................................6 Abbildung 4: Dynamische Web-Seite Architektur................................................................6 Abbildung 5: Architektur einer Web-Applikation.................................................................7 Abbildung 6: Grundgerüst eines HTML- Dokumentes .......................................................12 Abbildung 7: Beziehung zwischen XML-Dokumente, XML-Schema und ihre Validierung .....................................................................................................................................17 Abbildung 8: Grundsätzliche Arbeitsweise von Servlets ....................................................19 Abbildung 9: Request-Response-Muster für Servlet-Engine ..............................................20 Abbildung 10: Kommunikation zwischen Servlet Engine und Servlet ...............................21 Abbildung 11: Übersicht der Servlet-API ...........................................................................22 Abbildung 12: Beispiel eines HTML Templates – test.templ .............................................26 Abbildung 13: Beispielprogramm für die Validierung von test.tmpl..................................27 Abbildung 14: Der Software-Entwicklungsprozess als Wasserfall-Modell ........................28 Abbildung 15: Beispiel für einen UML Klassendiagramm aus dem Diagnosesystem........30 Abbildung 16: Beispiel eines Aktivitätsdiagramms ............................................................31 Abbildung 17: Beispielaktivität ...........................................................................................33 Abbildung 18: Funktionsprinzip von Cocoon .....................................................................35 Abbildung 19: Abstraktes Model der Web Applikation......................................................38 Abbildung 20: Metamodel für den Aufbau des Klassendiagramms....................................39 Abbildung 21: Ablauf der Modellierung und Generierung von dynamischen Web-Seiten 41 Abbildung 22: UML-Zuordnung der zu realisierenden Komponente. ................................42 Abbildung 23: Überführung des XML Schemas in einem UML-Modell ...........................43 Abbildung 24: Ablauf des Transformationsprozesses .........................................................44 Abbildung 25: Überführung der Datenbank in Fujaba ........................................................45 Abbildung 26: Konzept der Web-Schnittstelle....................................................................46 Abbildung 27: UML-Klassendiagramm - Struktur der HTML-Tabelle..............................49 Abbildung 28: Einlesen des Templates und Aufbau des ASG ............................................50 v Abbildung 29: Methoden einer HTML-Tabelle ..................................................................50 Abbildung 30: Struktur von HTML-Elementen nach dem Kompositum-Muster ...............51 Abbildung 31: typische Struktur des ASGs einer HTML-Tabelle (vgl. Abbildung 27) .....51 Abbildung 32: addToChildren - Methode für HTML-Tabelle ............................................52 Abbildung 33: generateHtmlCode – Methode für HTML-Tabelle .....................................53 Abbildung 34: Darstellung des ASGs eines Templates.......................................................54 Abbildung 35: Dialog zur Erzeugung einer UML Klasse in Fujaba ...................................55 Abbildung 36: Erzeugung der Servlet doPost Methode in Fujaba ......................................56 Abbildung 37: Implementierung der doGet-Methoden der AnmeldeServlet – Klasse .......56 Abbildung 38: Kommunikation zwischen der Web-Schnittstelle und HTML-Elementen..57 Abbildung 39: Beispielstruktur einer Web-Applikation......................................................58 Abbildung 40: Anmeldeformular des medizinischen Diagnosesystems .............................59 Abbildung 41: Klassendiagramm – Ausschnitt aus dem Diagnosesystem..........................60 Abbildung 42: Modellierung der doGet Methode ...............................................................60 Abbildung 43: Modellierung der buildServerPage Methode ................................61 Abbildung 44: Modellierung der patientSelection Methode...................................62 Abbildung 45: Antwortseite auf die Anmeldeanfrage aus Abbildung 40 ...........................62 Abbildung 46: Aufbau und Codegenerierung eines ASGs..................................................64 Abbildung 47: Codegenerierung in Fujaba..........................................................................64 Abbildung 48: Quelltext einer Servlet-Klasse .....................................................................65 Abbildung 49: Ausschnitt aus dem SQL-Diagramm des DB-Schemas ..............................67 Abbildung 50: Template-Bibliothek des Diagnosesystems.................................................67 Abbildung 51: Beschreibung der Servlet-Klassen des Diagnosesystems............................68 Abbildung 52: Design des Diagnosesystem - Servlet-Klassen und HTML-Elemente........69 Abbildung 53: Design der Kommunikation zwischen Servlet- und Datenbankklassen......70 Abbildung 54: Indexseite des Diagnosesystems – diagnosesystem.html ............................71 Abbildung 55: doGet Methode von der Klasse MDSServlet ........................................71 Abbildung 56: init Methode der Klasse MDSServlet..................................................72 Abbildung 57: Patientenformular zur Erstellung einer neuen Behandlung .........................73 Abbildung 58: buildServerPage-Methode der Patient-Servlet-Klasse.......................74 Abbildung 59: Ausschnitt des Templates – diagnose.html..................................................74 vi Abbildung 60: fillKrankheiten-Methode der Diagnosis-Klasse ..........................................75 Abbildung 61: Diagnoseformular eines Patienten ...............................................................76 Abbildung 62: Klassendiagramm - HTML Elemente..........................................................83 Abbildung 63: SQLDiagramm aus der eingelesenen Datenbank des Diagnosesystems .....84 Abbildung 64: Architektur des Diagnosesystems................................................................85 1 1. Einleitung 1.1 Motivation Die rasanten Entwicklungen und Anforderungen des Internets in den letzten Jahren haben zur Standardisierung von Browsern als Benutzeroberfläche geführt. Mit der zunehmenden Beliebtheit des Internets gewinnen Anwendungen wie Web-Applikationen, die auf der Infrastruktur des WWW (Word Wide Web) basieren, an großer Bedeutung. Grundlegende Komponenten einer solchen Web-Applikation erweisen sich als das zugehörige graphische Design und die Geschäftslogik der Anwendung. Es geht bei ihrer Entwicklung nicht mehr nur darum, statische HTML-Seiten zu erstellen und diese in dem Word Wide Web verfügbar zu machen, sondern auch um die Realisierung von komplexen Geschäften mit Datenbankzugriffen wie z.B. AutoScout24 [2] (vgl. Abbildung 1). Abbildung 1: Beispiel einer Web-Applikation – Das Autogeschäft AutoScout24 2 Die Entwicklung von Web-Applikationen geschieht in der Regel mit Hilfe von Technologien bzw. Skripten wie CGI (Common Gateway Interface [6] [7]), PHP (Hypertext Preprozessor [25] [26]), ASP (Microsoft’s Active Server Pages [1]), JSP (Java Server Page [19]) oder Java Servlets [29] [30] [31]. Ihre Benutzung weist allgemein auf folgende Einschränkungen hin: • • • Fehlende CASE-Tools für ihren Ansatz Manuelle Implementierung der Interaktionen. Mischung von Logik und Layout-Elemente. Einer der Hauptgründe dieser Einschränkungen liegt bei den fehlenden Entwicklungsprozessen für ihre Realisierung. Der fehlende Entwicklungsprozess führt in der Regel zu einer schlechten Portierbarkeit und geringeren Wiederverwendbarkeit der meist entwickelten Web-Applikationen. Außerdem weisen die so entwickelte WebApplikationen auf eine schlechte Anpassungs-, Verbesserungsund Erweiterungsmöglichkeiten an neuen Anforderungen hin. 1.2 Ziel der Arbeit In dieser Arbeit wird das Case-Tool Fujaba (From UML to Java and back again [10]) um die Fähigkeit erweitert, dynamische Web-Seiten modellieren zu können. Diese Erweiterung soll zuerst eine objektorientierte Zugriffsschicht auf die Layout-Elemente realisieren. Mit Hilfe einer vorliegenden Zugriffsschicht auf die Datenbank soll dann eine Kommunikationsschicht zwischen Layout-Elementen und Datenbanktabellen ermöglicht werden, mit deren Unterstützung die manuelle Implementierung der Interaktionen von der Web-Applikation erhoben werden soll. Dabei wird ein Mechanismus für die Modellierung von dynamischen Web-Seiten mit UML realisiert, das Layout-Elemente und Geschäftslogik interagieren lässt. Das CASE-Tool Fujaba dient als Basis der Implementierung. Sie verwendet bei der Codegenerierung dessen UML Meta-Schema. Ohne diese Arbeit verfügt Fujaba über keine Modellierungsmöglichkeit von Web-Applikationen. Als Beispielanwendung zur Erläuterung des Zieles dieser Diplomarbeit verwende ich ein einfaches Expertensystem zur Unterstützung der Diagnosefindung in einer Arztpraxis. In dem System sollen einerseits Behandlungen von Patienten durch Ärzte einer Praxis protokolliert werden können; andererseits soll das System eine Wissensbank zur Verfügung stellen, in der die Zusammenhänge von Krankheiten, Symptomen und Ursachen sowie geeigneten Untersuchungsmethoden, Diagnose- und Behandlungsmöglichkeiten für Krankheiten enthalten sind. Das System soll dem Arzt bei der Diagnose und Behandlung unterstützen, indem es, ausgehend von bereits festgestellten Symptomen, wahrscheinliche 3 Krankheiten ermittelt und weitere Untersuchungen zur genaueren Eingrenzung der Krankheit vorschlägt. Konnte eine Krankheit diagnostiziert werden, soll das System Behandlungsmöglichkeiten vorschlagen, beziehungsweise auf bekannte Kontraindikationen für Behandlungen, wie etwa eine Allergie gegen bestimmte Medikamente, hinweisen (vgl. Abbildung 2). Abbildung 2: Beispielgraph für ein medizinisches Diagnosesystem [46, S. 16] 1.3 Gliederung der Arbeit Die vorliegende Arbeit gliedert sich in 6 Kapitel. Das Kapitel 2 gibt einen Überblick über die in dieser Arbeit verwendeten Grundlagen. Der Abschnitt 2.1 definiert WebApplikationen, stellt die Architektur und die zugehörigen Komponenten vor. Der Abschnitt 2.2 thematisiert die Auszeichnungssprachen wie HTML (HyperText Markup Language [15] [16] [17]), XHTML (Extensible HyperText Markup Language [47]), XML (Extensible Markup Language [43]) und XML-Schema [44], während in Abschnitt 2.3 eine Einführung in die Technologien für die Entwicklung von Web-Applikationen gegeben 4 wird. Der Abschnitt 2.4 präsentiert das Konzept von HTML Templates, und die Abschnitte 2.5 und 2.6 schließen Kapitel 2 mit einer Übersicht über die UML (Unified modeling language [38] [39]), sowie das Projekt Fujaba ab. Weiterhin werden im Kapitel 3 die mit dieser Arbeit verwandten Ansätze vorgestellt. Im Abschnitt 3.1 wird das Cocoon Projekt erläutert. Es ist ein Java geschriebenes Framework, das XML/XSL Dokumente für Client in beliebigen Formaten darstellen kann. Die folgenden Absätze im Abschnitt 3.2 thematisieren das Konzept einer UML-Erweiterung für den Entwurf von Web-Applikationen. Das 4. Kapitel befasst sich im Abschnitt 4.1 mit einem allgemeinen Konzept zur Modellierung von dynamischen Web-Seiten mit UML und der Abschnitt 4.2 mit der technischen Umsetzung. Anschließend wird im Kapitel 5 ein Prototyp als Beispielsitzung für die in dieser Arbeit erarbeiteten Lösungsansätze vorgestellt. Es ist ein Expertensystem zur Unterstützung der Diagnosefindung in einer Arztpraxis. Das Kapitel 6 beschäftigt sich abschließend mit den Ergebnissen dieser Diplomarbeit in Form einer Zusammenfassung und mit möglichen Vorschlägen, die zu späteren Arbeiten beitragen können. 5 2. Grundlagen 2.1 Web-Applikation 2.1.1 Definition einer Web-Applikation In dieser Arbeit betrachten wir eine Web-Applikation als die Aktualisierung der Geschäftslogik durch Benutzereingabe. Das Wesentliche ist die Interaktion zwischen Benutzer und Geschäftslogik, die hinter der Applikation steckt. Ohne Geschäftslogik hinter der Applikation, gibt es keine Web-Applikation. Deswegen werden Systeme, die Interaktionen zwischen Benutzer (durch den Browser) und Geschäftslogik auf dem Server ermöglichen, als Web-Applikationen bezeichnet. Viele Web-Applikationsbenutzer navigieren nicht nur durch Links, sondern interagieren mit dem Server durch Dateneingabe. Diese Daten können einfache Texte, Checkbox Listen, binäre oder File Informationen sein. Interaktionen der Web-Applikation werden dem Benutzer in einem Browser dargestellt. Der Browser bezeichnet eine Applikation, die auf der Clientmaschine abläuft. Er ist mit dem Server im Netzwerk verbunden und kann Informationen über eine Web-Seite anfordern. Nachdem die Seite mit Informationen aktualisiert wird, wird die Verbindung mit dem Server getrennt. Der Browser weiß, wie er mit dem Web-Server kommuniziert und wie er Informationen aus der Anfrage darstellt. Mehrere Web-Seiten-Informationen bestehen aus Links zu anderen Web-Seiten, die durch die Benutzeranfrage leicht erreichbar sind. Benutzer navigieren innerhalb der Applikation über Links und Anfragen, die neue Web-Seiten vom Server generieren. Eine Web-Applikation beinhaltet drei Hauptkomponenten: • • • Web Server Netzwerk Verbindung Browser Abbildung 3 stellt die Basic-Architektur einer Web-Applikation dar. Eine Anfrage vom Browser wird über die Netzwerkverbindung, die durch einen HTTP (Hyper Transfer Text Protokoll [14]) definiert ist, an den Web-Server weitergegeben. Der Web-Server bearbeitet die Anfrage und generiert eine Web-Seite als Antwort, die dem Browser zurückgegeben wird. 6 Abbildung 3: Basic Web Applikation Architektur Setzen sich Inhalte der Antwortseite bei der Laufzeit aus Informationen in einer Datenbank zusammen, spricht man von einer dynamischen Web-Seite. Abbildung 4 präsentiert die Architektur von dynamischen Web-Seiten. Die Generierung der Antwortseite wird in diesem Fall durch einen Filter mit Zugriff auf die Datenbank realisiert. Abbildung 4: Dynamische Web-Seite Architektur Dynamische Web-Seiten bieten einige Vorteile für Web-Designer. Sie ermöglichen die automatische Aktualisierung der Web-Inhalte und ihre Synchronisation mit Daten aus der Datenbank. Eine dynamische Web-Seite beinhaltet Code, der auf dem Web-Server bei einer Anfrage ausgeführt wird. Sie kann also als ein Textfile mit Skripten, die auf dem Web-Server interpretiert werden oder eine kompilierte binäre File, die auf dem WebServer ausgeführt wird, gespeichert werden. In beiden Fällen benutzt der Code der WebSeite Server-Ressourcen wie Datenbankzugriff, Mail Service, File Service, etc. 7 2.1.2 Architektur einer Web-Applikation Die Abbildung 5 stellt eine Zusammenfassung der Architektur von Web-Applikationen dar. Alle Aktionen von Web-Applikationen basieren auf Web-Seiten. Web-Seiten können vom Server durch Browser Anfrage entstehen oder vom Web-Server zum Browser durch einen Filter verteilt werden. Es wird zwischen Client-Seiten und Server-Seiten unterschieden. Server-Seiten können die Client-Seiten wiederum generieren. Clientanfragen werden von Client-Seiten durch Formulare, die aus Elementen wie Inputfelder, mehrzellige Textfelder, Listen- und Buttonelemente bestehen, an den ServerSeiten für ihre Bearbeitung weitergegeben. Client-Seiten können auch aus Frames bestehen, die durch Links (Target) andere Client-Seiten erreichen. Für statische Seiten sind Client-Seiten einfache Kopien von Server-Seiten. Im Fall von dynamischen Web-Seiten werden Client-Seiten von dem auf dem Web-Server ausgeführten Skript generiert. Diese Skripte werden meistens mit Sprachen wie PHP, ASP, JSP oder Java-Servlets geschrieben. Da statische Seiten als spezielle Fälle von dynamischen Seiten betrachtet werden können, lässt sich die Realisierung von Web-Applikationen allgemein nur noch über die Verwirklichung dynamischer Web-Seiten zusammenfassen. Abbildung 5: Architektur einer Web-Applikation 8 Client Ein Client ist ein Rechner, der die Dienste eines anderen als Server oder Host bezeichneten Rechners nutzt. Wenn jemand mit seinem PC Daten aus dem WWW (World Wide Web) abruft, ist der PC ein Client des Web-Servers, mit dem er verbunden ist. Web-Seiten können mit spezifizierten Komponenten ausgestattet sein, die auf der Clientmaschine ausgeführt werden. Die Häufigsten sind Java Applets, ActiveX Controlls und einige, die kompilierte Komponenten beinhalten. Sie werden bei Anfragen im Browser ausgeführt. Abhängig vom Browser und der Konfiguration dieser Komponenten werden auf Ressourcen des Browsers und der Clientmaschine zugegriffen. Server Ein Server bezeichnet einen Rechner, der anderen Rechnern im Netz einen Dienst zur Verfügung stellt. In großen Netzwerken können auch mehrere Server mit teilweise verschiedenen Funktionen vorkommen. Client/Server Die Client/Server Bezeichnung bezieht sich auf eine Struktur, die für die Verbindung von Computersystemen in einem Netzwerk zuständig ist. Hierbei ist der Client in der Regel der Desktop-PC oder eine Workstation. Der Server ist in der Regel ein größerer Rechner, auf dem große Mengen von Daten gespeichert und wichtige Anwendungen (Computerprogramme) ausgeführt werden. Web-Applikationen basieren auf das Client/Server-Prinzip. Bei Clientanfrage wird die Geschäftslogik vom Skript innerhalb der Web-Seite auf dem Server interpretiert. Web-Seiten Die grundlegenden Komponenten der Web-Applikation sind Web-Seiten. Browser können Web-Seiten vom Web-Server anfragen. Web-Server verteilen Web-Seiten zum Browser. Die Realisierung und die Organisation von Web-Seiten ist die Aufgabe der Benutzerschnittstelle der Applikation. Bei Web-Applikationen agiert der Browser als Container für die Benutzerschnittstelle mit spezifischen Schnittstellen, die den Inhalt der Web-Seite bestimmt. Eine Web-Seite setzt sich innerhalb von Serverskripten, die für ihre Generierung eingesetzt werden, als eine Kombination aus statischer und dynamischer Seite zusammen. Als dynamische Seite beinhaltet sie einen Code, der auf dem Web-Server ausgeführt wird. Daraus wird mit Hilfe von Server-Ressourcen eine neue Seite generiert und dem Browser zurückgeschickt. 9 Serverskripte Bei einer Clientanfrage existiert die Verbindung zwischen Benutzer und Server solange, bis die Antwortseite generiert ist. Alle Aktivitäten auf dem Server finden während dieser Verbindung statt. Die Geschäftslogik, die auf dem Server liegt, wird bei der Ausführung des Skripts der angefragten Web-Seite aktiviert. Abhängig von der Skript-Engine (Abstraktion eines Berechnungsprozesses mit zeitlicher Beschränkung), die den Berechnungsprozess des Skripts bestimmt, kann die dynamische Seite benutzerdefinierte Variablen oder Funktionen enthalten. Einige Skript-Engines ermöglichen es sogar Objekte zu definieren, die durch Interaktionen der Applikation angesprochen werden. Als Ergebnis bei der Ausführung des Skripts wird die Geschäftslogik aktualisiert und als Antwort auf die Clientanfrage eine Web-Seite generiert. Clientskripte Der Server ist nicht die einzige Komponente der Web-Applikation, in der Skripte ausgeführt werden. Der Browser kann selber einen Skriptcode auf der Web-Seite ausführen. Diese Ausführung hat allgemein keine Zugriffe auf Server-Ressourcen. Unter Clientskripte sind nicht Clientkomponenten wie Java Applets oder ActiveXcontrols gemeint, die eine andere Struktur innerhalb der Web-Applikation haben, sondern solche wie Java-Skripte oder VB-Skripte, die im Code der Web-Seiten eingebettet sind. Dieser Code wird im Browser beim Laden eines Dokuments oder bei einem Knopfdruck ausgeführt. Die dynamische HTML-Spezifikation (DHTML, Dynamic HyperText Markup Language) ermöglicht sogar bei Clientskripten einen besseren Zugriff und eine bessere Kontrolle über jeden Aspekt des Web-Seiten-Inhalts. Wenn eine Web-Seite im Browser dargestellt wird, wird sie zuerst eingeparst und in verschiedenen Elementen verteilt. Jedes dieser Elemente kann durch einen Namen oder ID-Attribute identifiziert werden. Diese Namen oder ID-Attribute können auch auf einem Clientskript referenziert werden. Genauso wie bei Serverskripten können benutzerdefinierte Variablen und Funktionen bei Clientskripten definiert werden. Formulare Jede Web-Applikation wird mehr als navigierbare Inputfelderdaten akzeptiert. Auch Texte, selektierbare und boolesche Informationen werden verarbeitet. Das HTML-Formular ist der am meisten verbreitete Mechanismus, um Benutzerinformationen zu sammeln. Seine grundlegenden Elemente sind Inputfelder, mehrzellige Eingabefelder, Checkboxen, Radiobutton und Selektionslisten. Diese Elemente werden durch einen Namen oder IDAttribute identifiziert. Das Formular wird mit einer dynamischen Seite assoziiert, die durch den beinhalteten Skriptcode Clientanfragen bearbeitet. Wenn ein Formular ausgefüllt ist, wird es durch einen Knopfdruck an den Server geschickt. Der Web-Server findet die mit dem Formular assoziierte Seite und führt den beinhalteten Skriptcode aus. Der Skriptcode ermöglicht die Zugänglichkeit der durch das Formular zugeschickten Informationen. 10 Frames HTML-Frames unterstützen die gleichzeitige Offenhaltung mehrerer Web-Seiten. Der Browser teilt sein Fenster in verschiedene Unterfenster auf, auf dem verschiedene Seiten dargestellt werden können. 2.2 Textauszeichnungssprachen Im Abschnitt 2.1 wurde die Architektur der Web-Applikation vorgestellt. Durch die Interaktionen zwischen Client und Server werden Informationen ausgetauscht. Daten werden somit von dem Client in bestimmten Datenbanken abgespeichert oder dem Client von der Datenbank zur Verfügung gestellt. Je nach Fähigkeit des Browsers müssen diese Daten aufgrund ihrer Darstellung bei dem Client in passenden Formaten geschrieben werden. In den folgenden Abschnitten werden nun die Auszeichnungssprachen (Markup Languages) HTML, XML und XHTML erläutert. Diese Sprachen werden benutzt, um Web-Inhalte darzustellen. 2.2.1 HTML HTML bezeichnet die Sprache, mit der Web-Seiten definiert werden können. HTML steht für HyperText Markup Language, was im Deutschen mit Hypertext Auszeichnungssprache übersetzt werden kann. Es ist eine Sprache, die die Struktur, den Inhalt und das Verhalten eines Web-Dokuments beschreibt. HTML basiert auf SGML (Standard Generalized Markup Language [33]), eine ISO-Norm, mit der die Syntax von Auszeichnungssprachen definiert wird. Eine solche Auszeichnungssprache ist nötig, um Dokumente auf verschiedenen Rechnersystemen einheitlich darstellen zu können. Im Gegensatz zu Dokumenten, die mit einem bestimmten Anwendungsprogramm erzeugt und dann in einem speziellen Dateiformat mit integrierten Sonder- und Schlüsselzeichen gespeichert werden (z.B. MS- Word-Dokumente) und somit nur mit dem Programm mit dem sie erzeugt wurden, dargestellt und weiterbearbeitet werden können, werden HTMLDokumente im ASCII- Format gespeichert. Dies bedeutet, dass HTML-Dokumente nur aus fortlaufenden Texten ohne Sonder- und Steuerzeichen bestehen, und somit mit jedem beliebigen Editor erzeugt werden können. Da außerdem jedes Rechnersystem das ASCII-Format versteht, lassen sich HTMLDokumente problemlos von einem Computer auf einen anderen übertragen. Ein HTMLDokument besteht aus zwei verschiedenen Textarten. Erstens dem eigentlichen Inhalt, also die Informationen (Text, Graphik etc.), die auf dem Bildschirm angezeigt werden sollen und zweitens der Markierung (Markup), den so genannten Tags (also dem Text, der die Art 11 und Weise festlegt, wie die Informationen dargestellt werden sollen). Diese Markierungen werden vom Browser (das ist der Client, der das HTML-Dokument auf den Bildschirm bringt) verstanden und interpretiert. Um nun saubere Dokumente schreiben zu können, darf die Deklaration der Version bzw. der Art des Dokuments/Dokumenttyps nicht fehlen. Sie sagt über das betreffende Dokument aus: "Dieses Dokument ist konform mit den Regeln in der HTML DTD [xxx] ", wobei xxx für die Version der HTML steht. Alle HTML-Tags werden von den spitzen Klammern "<" und ">" (auch bekannt als "kleiner als" bzw. "größer als" Zeichen) eingeschlossen. Innerhalb dieser spitzen Klammern steht der Name des verwendeten Tags. Dabei ist es prinzipiell gleichgültig, ob ein Tag groß oder klein geschrieben wird. Wegen der besseren Übersichtlichkeit empfiehlt es sich diesen groß zu schreiben. Nach der öffnenden spitzen Klammer sollte kein Leerzeichen folgen, ebenso wie nach dem TagNamen. Hält man sich nicht daran, kann es passieren, dass der Browser den Tag nicht richtig interpretiert. Eine Auszeichnung, die mit einem Tag eingeschaltet wird, bleibt für den gesamten folgenden Text gültig, bis sie wieder ausgeschaltet wird. Sie wird einfach ausgeschaltet, indem derselbe Tag, mit dem man die Auszeichnung eingeschaltet hat, am Ende wieder verwendet wird: diesmal allerdings mit einem Schrägstrich vor dem Namen des Tags. Bei vielen Tags kann bzw. muss man weitere Informationen, so genannte Attribute, angeben, die die Ausführung des Tags steuern. Diese Attribute werden hinter den Tag-Namen innerhalb der spitzen Klammern eingegeben. Zwischen dem Tag-Namen und den einzelnen Attributen muss ein Leerzeichen vorhanden sein, und die meisten Attribute bekommen außerdem mit einem "="-Zeichen einen Wert zugewiesen. Bei diesen Werten, die üblicherweise in Anführungszeichen eingeschlossen sind, kann es sich um eine Zahl, einen Dateinamen, eine URL oder ein festgelegtes Token (d.h. den symbolischen Wert eines Attributs) handeln. Bei Sonderzeichen ist Vorsicht geboten. Da z.B. die spitzen Klammern für die Einbettung der HTML-Tags reserviert sind, sollten sie nicht innerhalb des normalen Textes verwendet werden. Genauso verhält es sich mit Anführungszeichen bei Attributen, denn sie kennzeichnen Anfang und Ende der Werteangabe. Dennoch ist es möglich, diese Zeichen als Text auszugeben. Bei HTML gibt es nämlich einen Mechanismus zur Angabe solcher Sonderzeichen. Diese Symbolkürzel heißen Entities. Ein Entity hat folgende Syntax: &Zeichen; wobei solche Zeichen einem bestimmten Zeichenkürzel wie beispielsweise &copy; für das Copyzeichen © entsprechen. Bei den Kürzeln ist die Groß- und Kleinschreibung relevant, und das Semikolon am Ende des Entities darf auch nicht vergessen werden. Jede HTML Seite verfügt über dieselbe Struktur. Abbildung 6 stellt die allgemeine Struktur eines HTML-Dokumentes dar. Die erste Zeile definiert dem nachfolgenden Text gemäß der SGML Spezifikation als HTML-Dokument nach dem in der Version 4.0 definierten Standard. Der Tag <! DOCTYPE> bezeichnet also den Standard, mit dem das folgende Dokument beschrieben wird. Dieser Tag wird 12 noch nicht von allen Browsern unterstützt, sollte aber dennoch immer verwendet werden. Das Attribut HTML besagt, dass es sich um ein HTML-Dokument handelt. Hinter dem Attribut PUBLIC steht im Anführungszeichen, um welche DTD (Document Type Definition [48]) es sich handelt. Der Tag <HTML> beschreibt die Zusammensetzung eines HTML-Dokuments mit der üblichen Aufteilung: erst Kopfteil <HEAD>, dann Körperteil <BODY>. 1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> 2 <HTML> 3 <HEAD> 4 <TITLE>Hier Steht der Titel der Seite… </TITLE> 5 </HEAD> 6 <BODY > 7 Hier steht der eigentliche Inhalt der Seite 8 </BODY> 9 </HTML> Abbildung 6: Grundgerüst eines HTML- Dokumentes In dem Kopfteil, dessen Definition mit dem <HEAD>- Tag beginnt und mit dem </HEAD>- Tag aufhört, stehen die Informationen über das Dokument. Dazu gehört der Dokumententitel, der innerhalb der Tags <TITLE> und </TITLE> stehen muss. Im Kopfteil des Dokuments wird aber nicht nur der Titel festgelegt, sondern auch noch weitere Informationen oder Scripte, die z.B. durch die Tags <META>, <LINK>, <BASE> und <SCRIPT> untergebracht werden. Der eigentliche Inhalt eines HTML-Dokuments wird zwischen den Tags <BODY> und </BODY> eingebaut. Mit der Version 3.0 von HTML wurden die von Netscape eingeführten Attribute zur Einbettung einer Hintergrundgrafik sowie zur Steuerung der Hintergrundfarbe und vieles mehr übernommen. Mit dem </BODY>- Tag wird die Definition des Seiteninhalts abgeschlossen, das Dokument ist hier zu Ende. Den krönenden Abschluss des Dokuments bildet dann nur noch der Ende-Tag-</HTML>. Mit HTML können aber nicht nur Texte dargestellt und beschrieben werden. Man kann mit einfachen Befehlen auch andere Ressourcen wie Musik, Graphik, oder sonstige Multimediadaten in einem Dokument verbinden. Dazu muss der Browser in der Lage sein, gegebenenfalls andere Programm-Module einzubinden (so genannte Plug-Ins) oder andere Anwendungen aufzurufen, wenn er diese Fähigkeiten nicht von Hause aus hat. Kodierte Daten muss er an entsprechende Anwendungsprogramme weitergeben können, damit beispielsweise Audiodateien auch von einem Audioplayer weitergegeben werden können. Der Browser ist für die eigentliche Darstellung eines HTML-Dokuments auf dem Bildschirm zuständig. Darin befindet sich die Antwort auf die Frage, warum ein und dasselbe HTML-Dokument von verschiedenen Browsern bzw. auf verschiedenen Rechnersystemen nicht hundertprozentig gleich dargestellt wird. Der Grund liegt in den unterschiedlichen Rechnerausstattungen. Zwar verfügen einerseits manche Computer nicht über dieselben Schriftarten zur Textdarstellung. Andererseits können sie nicht beliebige 13 Farben präsentieren. Außerdem gibt es viele Browser, die nicht alle HTML-Kommandos (korrekt) umsetzen können. Andere Computer und Browser sind nicht einmal grafikfähig. Solche Gesichtspunkte müssen bei der Seitenerstellung beachtet werden. HTML bietet durch die in der HTML-DTD definierten Elemente die Möglichkeit zur Beschreibung der Struktur, des Layouts und des Verhaltens eines Web-Dokuments. Die Flexibilität und die einfache Erlernbarkeit und Handhabung der Sprache führen dazu, dass sich HTML als Auszeichnungssprache für das WWW durchgesetzt hat und sich somit als grundlegender Mechanismus zur Darstellung von Information auf dem WWW erweist. Im Übrigen liefert HTML auch den Mechanismus für die Einbindung anderer Internet Protokolle und Dienste, die über das WWW verfügbar sind (FTP, Gopher, Usenet, E-Mail etc.). HTML wird in mehreren Versionen und in mehreren Arten definiert angefangen bei der ersten Version von HTML bis hin zur aktuellen Version HTML 4.01. Die neuste Version 4.0 hat einige Verbesserungen und Neuigkeiten mit sich gebracht. Neue HTML-Tags bzw. neue HTML-Attribute werden von den alten Browsern nicht unterstützt. Dies führt aber nicht zu einer Fehlermeldung im Browser, da der Standard vorsieht, dass ein Browser ein HTML-Tag, welches er nicht kennt, einfach ignoriert. Jede Version und Art wird dabei in einer DTD (Document Type Definition) definiert. Diese DTD sagt aus, welche Elemente es gibt, welche Attribute welches Element enthalten darf, welche Werte diese Attribute erhalten dürfen und welches Element welche (weiteren) Elemente enthalten kann bzw. wie diese angeordnet sein müssen. Im Grunde wird somit der gesamte Aufbau eines HTMLDokumentes beschrieben und festgelegt. Diese DTD legt also fest, was in HTML erlaubt ist und was nicht. Der Nachfolger von HTML 4.0 (XHTML, vgl. 2.2.3) ist seit kurzem von W3C (W3 Konsortium [41]) verabschiedet worden. 2.2.2 XML XML (eXtensible Markup Language) bezeichnet eine neue Markup Sprache, die vom W3Konsortium entwickelt wurde, um strukturierte Dokumente bzw. Daten im Web zu benutzen. XML ist eine Metasprache, d.h. mit XML lassen sich neue Markup Sprachen definieren, mit denen dann Dokumente erzeugt werden. Das große Plus von XML besteht darin, dass es keinen festgelegten Satz von Markup Befehlen gibt. Man kann die Befehle beliebig selbst definieren. Aussagekräftige Namen können für die Markups verwendet werden, anhand derer man die Bedeutung des Inhaltes schon erkennt. XML stellt eine Beschreibungssprache dar, in welcher dann eine Spezifizierung vorgenommen werden muss. Der Nutzer hat die Möglichkeit und Aufgabe eine eigene DTD mitzuliefern, um eine Typendefinition für sein Dokument vorzunehmen. Damit das Dokument entsprechend den Vorstellungen des Nutzers präsentiert wird, ist das so genannte XSLT (Extensible Stylesheet Language [49]) notwendig. XML bietet die 14 Möglichkeit, Daten so zu strukturieren, dass sie Regeln entsprechen, die man selbst festlegen darf. Auf diese Weise bezeichnen wir strukturierte Daten als Dokumente. Diese Regelhaftigkeit führt bei XML jedoch nicht zwangsweise zu starren immer gleich aufgebauten Dokumenten. Ein Dokumenttyp kann mit Varianzen definiert werden. Ein XML Dokument baut sich aus so genannten Elementen auf. Diese Elemente tragen Namen, die bei der Dokumententwicklung vergeben werden können. Ein Beispiel ist das Element <beruf> Schneiderin </beruf>. Wird bei der Vergabe der Namen darauf geachtet, dass diese aussagekräftig sind, kann behauptet werden, dass ein solches Dokument selbstbeschreibend ist. Die Elementnamen können als Beschreibungsdaten sowohl direkt von Menschen gelesen und verstanden werden, als auch von Suchmaschinen indiziert werden. Damit wird eine potentielle bessere Qualität bei der Suche nach Inhalten im Internet möglich gemacht. Es wird nicht mehr nach Zeichenketten gesucht, die sich irgendwo in irgendeinem Dokument befinden, sondern beispielsweise nach einer Zeichenfolge, die in einem Element mit dem Namen "beruf" vorkommt. Dennoch bewirkt das XML Format von Dokumenten allein noch nicht viel. Es sind eher die in XML notierten Formate, die einen wirklichen Gewinn aus diesem Format ziehen können. Ein anschauliches Beispiel hierfür ist das SVG (Grafikformat Scalable Vector Graphics [32]). Ein Textelement, das als grafisch anspruchsvolles Objekt als Banner einer Web-Seite dienen soll, bietet die Vorteile beider Welten. Es umfasst gleichzeitig Grafik und Text. Der Textteil ist nicht binär abgelegt, sondern bleibt als Text inhaltlich recherchierbar. Der grundlegende Mechanismus bei allen XML basierten Formaten kennzeichnet sich dadurch, dass eine Quellinformation umgewandelt in eine anwendungsorientierte Form wie beispielsweise Grafik, HTML, PDF wird. Ein möglicher Produktivitätsgewinn durch Nutzung von XML Formaten liegt nun in der oben beschriebenen Regelhaltigkeit von XML Dokumenten. Dient ein Regelwerk, ein Dokument Typ Definition als Schablone für künftige eintreffende Inhalte, können bereits vor der wirklichen Verfügbarkeit dieser Inhalte alle weiteren Verarbeitungsschritte realisiert werden; Wie z.B. die Umwandlung in Grafik oder HTML oder eine Kombination von HTML mit eingebetteter Grafik. Wichtig dabei ist die Verwendung von Standardwerkzeugen bei der Realisierung weiterer Verarbeitungsschritte, die das Auslesen, das Durchsuchen und das Sortieren von XML Dokumenten übernehmen. Es besteht dadurch für Anwendungsprogrammierer keine Notwendigkeit mehr, die Position von Elementen in der Datenquelle exakt zu kennen. Es genügt in vielen Fällen, zu wissen, welche Elemente namentlich angefordert werden sollen, und dies den Standardwerkzeugen anschließend aufzutragen. Man kann also sagen, dass der Effekt von XML eigentlich auf einer generellen Übereinkunft über den Aufbau und die Benutzung von Schnittstellen beruht. In diesem Sinn steht XML lediglich für eine bedeutende Basistechnologie. 15 2.2.3 XHTML XHTML (Extensible HyperText Markup Language) ist eine Familie gegenwärtiger und in der Zukunft noch zu entwickelnder Dokumenttypen und Module, die HTML 4 abbilden und erweitern. XHTML 1.0, die erste Version von XHTML, definiert die bisherigen drei auf SGML basierenden DTDs für HTML 4 als XML Anwendung. XHTML wurde somit entwickelt, um HTML 4.0 mit den Vorzügen von XML als Modellierungssprache für Dokumente und Datenstrukturen zu kombinieren. Ziel ist es, den gesamten Sprachumfang von HTML 4.0 durch XML-DTDs so abzubilden, dass bestehende HTML-Dokumente weiterhin verwendet werden und gleichzeitig die hinter XML stehenden Konzepte adaptiert werden können. XHTML-Dokumente sind somit XML-konform und können mit normalen XML Werkzeugen verarbeitet, betrachtet, bearbeitet und validiert werden. XHTML-Dokumente können so geschrieben werden, dass sie genauso gut oder besser in existierenden HTML 4.0 konformen wie in neuen XHTML 1.0 konformen Anwendungen funktionieren. XHTML ist erweiterbar. Bei HTML war es nötig, die ganze Sprachdefinition zu ändern, um neue Elemente hinzuzufügen. Bei XML basierenden Dokumenttypen ist das nicht nötig. XHTML erweist sich als klarer und strenger als HTML. Geräte die nicht die Kapazitäten eines PCs haben, können XHTML daher wesentlich leichter und besser darstellen als HTML-Dokumente. Dies bringt konkret folgende Vorteile: • • • • Erweiterbarkeit von XHTML Aufteilung von XHTML in verschiedene Module Erleichtertes „Parsing“ aufgrund der XML Syntax-Vorschriften Transformation in andere Formate mit XLST Die XHTML-Familie ist der nächste Schritt in der Evolution des Internet. Wenn die Entwickler von Inhalten heute auf XHTML umsteigen, können sie in die XML-Welt mit allen dort gebotenen Vorteilen vordringen und dennoch darauf vertrauen, dass ihr Inhalt vorwärts- und rückwärtskompatibel gewährleistet wird. Mit XHTML sollen auch vorhandene Kompatibilitätsprobleme bei der Interpretation von HTML 4.0 Code von den diversen User-Agents der unterschiedlichen Hersteller vermieden werden. Insbesondere die Entwicklung eigener, bisher meist proprietärer Sprachelemente soll durch XHTML organisiert werden. Neueste Überlegungen zu XHTML beschäftigen sich mit der Modularisierung der Sprache und führten vor kurzem zu einem neuen „Working Draft“ durch das W3C [41], welches XHTML 1.1 spezifiziert. 16 2.2.3 XML-Schema Eine der Entwicklungen im Bereich XML beruhte darauf, dass es nicht nur als Auszeichnungssprache für textorientierte Dokumente wie Web-Seiten, sondern auch als Format für große Mengen extrem strukturierter Daten (z.B. tabellenartige Datensätze) und ihren Austausch begeistert angenommen wurde. Um solche Daten vollständig modellieren zu können, fehlte es in den Anfangszeiten von XML an einer geeigneten Beschreibungssprache. Diese Lücke hat das W3C mit der Spezifikation XML Schema im Mai 2001 geschlossen. XML-Schema gibt einen neuen Ansatz zur Definition von Dokument Typen und damit zur Spezifikation von XML Sprachen. Mit der Erhebung der eXtensible Markup Language zum Industriestandard 1998 hatte sich zunächst die von der Standardized Generalized Markup Language übernommene Document Type Definition als Format zur Beschreibung konkreter XML Sprachen etabliert. Doch durch die starke Verbreitung von XML in der Praxis machten sich zunehmend die Grenzen und Nachteile der DTDs bemerkbar. Insbesondere die Dokumentenzentrierte Sichtweise der DTDs unter Vernachlässigung von Datentypen erweist sich in Zeiten der Annäherung der Programmiersprachen an die Datenmodellierung als problematisch. So lassen sich zwar mittels dem XMI-Format (XML Metadata Interchange [42]) auch jetzt schon aus objektorientierten Datenmodellen, beschrieben etwa durch die Unified Modeling Language, oder auch direkt aus z.B. einer Javaklasse, passende XML Sprachen automatisch generieren, doch lassen DTDs weder die Beschreibung bestimmter semantischer Bedingungen noch die Festlegung von Wertebereichen zu. Gerade die zunehmende Verbreitung verteilter Anwendungen erfordert eine Möglichkeit, Daten in einem einheitlichen und vor allem in einem flexiblen und leicht modifizierbaren Format, welches sich zudem leicht auswerten (parsen) lässt, zu transportieren. Der bisher unvermeidbare Bruch zwischen applikationsinterner Datenhaltung und abgeleiteter XML-Sprache soll nun durch das XML-Schema als Nachfolger der DTDs überwunden werden. Die XML-Schema-Sprache stellt dabei eine Obermenge der DTDSprache dar. Genau wie eine DTD stellt ein XML-Schema Regeln zur Verfügung, nach denen ein XML-Dokument auf seine Gültigkeit überprüft bzw. validiert wird. Da jedes XML-Schema auch ein XML-Dokument ist, lässt es sich selbst auch durch ein Schema oder eine DTD beschreiben. Wie in der Abbildung 7 dargestellt, werden XML-Dokumente mit Hilfe von DTD oder XML-Schema validiert. 17 Abbildung 7: Beziehung zwischen XML-Dokumente, XML-Schema und ihre Validierung 2.3 Serverskripte Server Side Scripting (vgl. Serverskripte - 2.1.2) kennzeichnet einen Sammelbegriff für viele Arten von serverseitigen Web-Anwendungen, d.h. unabhängig von der verwendeten Skriptsprache werden die Programme, die auf dem Server ausgeführt werden, entsprechend bezeichnet. Dies umfasst neben unterschiedlichen Sprachen auch unterschiedliche Konzepte, mit allerdings ähnlichen Zielen. Die Skripte liegen meist im Quelltext auf dem Server vor, und werden zur Laufzeit von einem Interpreter analysiert und ausgeführt. Der Server generiert nun ggf. eine Antwort, die an den Client geschickt wird. Aufgrund der Eigenschaft, dass sie nicht auf dem Client gestartet werden, benötigen sie im Gegensatz zu Client Side Scripting (vgl. Clientskript 2.1.2) keine lokalen Ressourcen. Dies hat zur Folge, dass die Performance ausschließlich serverabhängig ist, was bei einer großen Anzahl von Clients zu dem Nachteil einer hohen Last auf dem Server führt. Diese Skripte stellen sich - da sie größtenteils nicht kompiliert werden - meist als plattformübergreifend heraus, und haben deshalb einen hohen Verbreitungsgrad, was zu dem großen Vorteil der Portierbarkeit führt. Obwohl diese Skripte sehr verbreitet sind, werden sie oft nicht weiter beachtet, da sie im Gegensatz zu z.B. JavaScript nur im Hintergrund arbeiten, ohne direkt zum Vorschein zu kommen. Der größte Nutzen besteht in den Interaktionsmöglichkeiten mit dem User, d.h., die Web-Seite kann sich auf jeden Nutzer individuell einstellen und anpassen. Dies eröffnet ein weites Spektrum an Einsatzmöglichkeiten. 18 2.3.1 CGI Programme Das Common Gateway Interface (CGI) kann als eine Art Schnittstelle zwischen dem WebServer und den dort abgelegten Programmen angesehen werden. So ist es beispielsweise notwendig, dass die Datenübertragung eines Formulars in einer Datenbank mit einem serverseitigen Programm vollzogen werden muss, und genau hier kommt CGI zum Einsatz. CGI regelt den Aufruf und die Parameterversorgung von externen Programmen, den so genannten CGI-Skripten. Die Parameterübergabe erfolgt in Abhängigkeit von der HTTPMethode, welche beim Aufruf des CGI-Programms gewählt wurde. Daraufhin kommunizieren das CGI-Programm und der HTTP-Server über eine Reihe festgelegter Umgebungsvariablen. Bei diesem Datenaustausch werden Informationen über den Server und der vom Client erzeugten Anfrage ausgetauscht. Der Vorteil gegenüber Java und JavaScript liegt darin, dass das CGI-Programm nicht voraussetzt, auf dem Rechner des Besuchers geladen zu werden, sondern arbeitet an Ort und Stelle. Meist werden CGI-Anwendungen mit der Programmiersprache Perl (Practical Extraction and Report Language [7]) erstellt. Perl ist eine Symbiose aus der Programmiersprache “C” und einigen UNIX-Befehlen. Die in Perl programmierten Scripte werden als reine ASCII-Files abgelegt, also als reine Textdateien, die erst bei der Ausführung kompiliert werden. So gilt zum einen ein rasches und unkompliziertes Verändern der Programme, zum anderen werden diese sehr schnell ausgeführt, was bei rechenintensiveren Anwendungen wie Suchmechanismen oder Datenbankanbindungen sehr von Vorteil ist. 2.3.2 Java-Servlets Servlets [30] [31] bezeichnen Protokolle und plattformunabhängige Java-Programme, die die Funktionalität eines Web-Servers erweitern. Servlets bedeuten für den Server JavaProgramme, die dynamisch geladen werden und die Funktionalität des Host erweitern. Die grundsätzliche Arbeitsweise von Servlets wird in Abbildung 8 dargestellt, sie kann so beschrieben werden, dass ein Client-Programm, welches ein Web-Browser sein kann, auf einen Web-Server zugreift und eine Anfrage (Request) stellt. Diese Anfrage wird von der Servlet-Engine bearbeitet und an das entsprechende Servlet weitergereicht. Das Servlet seinerseits sendet eine Antwort, aus der die Servlet-Engine die eigentliche Antwort (Response) an den Client sendet. 19 Abbildung 8: Grundsätzliche Arbeitsweise von Servlets Servlets interagieren mit einem auf dem Web Server laufenden Servlet-Engine über Requests und Responses. In ihrer Funktionalität liegen Servlets zwischen CGIProgrammen und kommerziellen Server Erweiterungen. Im Gegensatz zu CGIProgrammen müssen Servlets weder für eine spezifische Plattform noch für einen bestimmten Server modifiziert werden. Vorteile von Java-Servlets Java-Servlets sind leistungsfähiger, einflussreicher, übertragbarer und einfacher zu verwenden als ein traditionelles CGI und viele alternative vergleichbare Techniken. Als Vorteile von Servlets zählt man: • • • • Effizienz: sie sind effizienter und schneller als CGI Skripte, weil sie ein anderes Prozess-Model benutzen. Praxis und Leistungsfähigkeit: Servlets bieten die Vorteile der leichten Entwicklung, der Plattformunabhängigkeit und der Annehmlichkeit, eine Sprache zu benutzen, die eine umfassende Infrastruktur bereithält, z.B. für das automatische Parsen und Decoding von HTML-Formular-Daten, lesen und schreiben von HTTPHeadern, die Handhabung von Cookies, Session Tracking und vielen weiteren. Darüber hinaus haben sie Zugriff auf den großen Satz der verfügbaren Java APIs und natürlich auf die gesamte verfügbare Leistungsfähigkeit der Standard Java APIs. Übertragbarkeit: Servlets werden in Java geschrieben und befolgen die Semantik und Syntax der Standard API. Daher können Servlets auf verschiedenen Servern betrieben werden. Servlets werden direkt oder über ein Plugin von nahezu jedem wichtigen Web-Server, insbesondere Apache [50], unterstützt. Freie Verfügbarkeit: Für fast alle Web-Server ist eine Aufrüstung zur Servlet Unterstützung im Allgemeinen frei oder kostengünstig. Nachteile von Java-Servlets Neben den vielen Vorteilen, die Java-Servlets bieten, haben sie natürlich auch Nachteile: 20 • • Verfügbarkeit: Viele Provider bieten zurzeit noch keine kostengünstige ServletUmgebung. Anforderungen: Eine laufende JVM (Java Virtual Maschine) benötigt zum Betrieb ca. 10-mal so viele Ressourcen auf dem gleichen PC wie z.B. eine GNU bash. Anwendungsbeispiele Typische Anwendungen für Java-Servlets sind: • • • • • • Datenverarbeitung und/oder Speicherung von Daten, die von HTML-Formularen übermittelt wurden. Bereitstellung von dynamischen Inhalten, zum Beispiel die Ergebnisse einer Datenbankabfrage. Session Tracking Vernetzung von Servern Zusammenarbeit zwischen Benutzern Etc. … Servlet-Engine Eine Servlet-Engine ist eine Server-Applikation, die Servlets ausführt, Clientanfragen an ein angefragtes Servlet weiterleitet und die Servlet-Antwort an den Client zurücksendet. In Netzwerken und insbesondere im Internet kommunizieren User-Agents und Web-Server durch Anfragen (Requests) und Antworten (Responses). Diese Requests und Responses basieren i.d.R. auf dem Hypertext Transfer Protocol (HTTP). Die laufende Servlet-Engine interagiert ebenfalls mit einem oder mehreren Web-Servern durch Anfragen (Requests) und Antworten (Responses) miteinander, allerdings nicht mit dem HTTP-Protokoll, sondern mit einem vom System abhängigen Protokoll. So verwendet z.B. eine TomcatEngine [36] oder JServ-Engine zur Kommunikation mit einem Apache Web-Server das Apache Jserv-Protocol (AJP), welches ebenfalls bei dem Request-Response-Muster aufsetzt (vgl. Abbildung 9). Bei einem Apache Web-Server handelt es sich um das Modul „mod_jserv“. Seine Hauptaufgabe besteht darin, einen HTTP Request an eine ServletEngine im AJP Protokoll weiterzureichen, und die Antworten im HTTP Protokoll an den Client zu senden. Abbildung 9: Request-Response-Muster für Servlet-Engine 21 Die Servlet-Engine übersetzt den AJP-Request in ein ServletRequest-Objekt und kreiert ein ServletResponse-Objekt, um auf die Anfrage zu antworten. Abbildung 10 verdeutlicht diese Zusammenhänge. Abbildung 10: Kommunikation zwischen Servlet Engine und Servlet Während und bis zum Ende der Ausführung werden alle an das ServletResponseObjekt übergebenen Daten in einen AJP-Response konvertiert und zurück an den WebServer gesendet. Dieser übersetzt die AJP-Response in einen HTTP-Response und sendet ihn schließlich an den Client. Die grundlegende Servlet Architektur Das Servlet-API setzt sich aus zwei Paketen zusammen, aus javax.servlet und javax.servlet.http. Das erste Paket ist allgemeiner: es setzt nur einen grundlegenden Client-Server-Rahmen mit einem zustandlosen Request-ResponseProtokoll voraus. Das zweite Paket ist auf HTTP spezialisiert. Es kennt Sachverhalte wie HTTP-Methoden und HTTP-Header. Eine Übersicht über die wichtigsten Klassen und Interfaces wird in Abbildung 11 dargestellt. Das Paket javax.servlet enthält eine GenericServlet-Klasse, die eine service()Methode implementiert, um einen Request-Response-Zyklus zu verarbeiten. Das Paket javax-servlet.http beinhaltet eine HttpServlet-Klasse, die eine Reihe von doXXX()-Methoden implementiert, um einen Request-Response-Zyklus zu verarbeiten; wobei XXX verschiedene HTTP-Methoden (Post, Get, etc.) entspricht. Zu den wichtigsten Elementen in javax.servlet werden die folgenden vier Interfaces gezählt: Servlet, ServletConfig, ServletRequest und ServletResponse. Servlet ist das grundlegende Interface, das die Methoden für den Lebenszyklus vereinbart. ServletConfig vereinbart die Methoden, die zur Initialisierung benötigt werden. ServletRequest und ServletResponse vereinbaren all die Methoden, die gebraucht werden, um einen Request und eine Response verarbeiten zu können. Das Paket 22 javax.servlet enthält die GenericServlet-Klasse, die Implementierung der Servlet- und ServletConfig-Interfaces bereitstellt. die Default- Die HttpServlet-Klasse gehört, zusammen mit den Interfaces HttpServletRequest und HttpServletResponse, zu den wichtigsten Elementen von javax.servlet.http. Diese erweitern systematisch die entsprechenden Elemente aus javax.servlet. Eine Servlet-Klasse weitet i.d.R die HttpServlet-Klasse aus, die wiederum GernericServlet erweitert. Abbildung 11 gibt eine Übersicht über diese Zusammenhänge. Abbildung 11: Übersicht der Servlet-API 2.3.3 Java Server Pages JSP steht für JavaServer Pages ([12] [37]). JSP sind von Sun-Microsystems entwickelt worden und bezeichnen eine neue erweiterte Servlet-Technologie für vereinfachte serverseitige Anwendungen, welche die Trennung von Business Logik und Präsentation möglich macht. Die JSPs haben Zugriff auf das Java-API (Application Programming Interface) und können objektorientiert programmiert werden. Bestandteile der JSP bestehen aus einem statischen HTML-Code für die Oberflächengestaltung (Layout der Web-Seite) und einem dynamischen Java-Code für den 23 Programmteil (Anwendungslogik). Kurz beschrieben erweist sich JSP als eine dynamisch generierte Web-Seite, die auf fast allen Web-Servern ausgeführt werden kann. Speziell für JSP entwickelte die Apache-Gruppe den JSP-Server Tomcat, ein OpenSource-Projekt. Tomcat kennzeichnet einen vollständigen HTTP-Server, der HTML, Servlets und JSP unterstützt. Um die Wirkung und Arbeitsweise einer JSP zu verdeutlichen, wird einem reinen Servlet eine sehr verbreitete Web basierende Technologie gegenüber gestellt. Im Grunde besteht kein großer Unterschied zwischen einer JSP und einem Servlet. Jedoch gibt es bei Servlets einen Nachteil in der Ausgabe von HTML-Code. Dies wird nur über Java-println-Anweisungen ermöglicht, die zahlreich vorkommen können. Einfacher ist es mit JSP, die das Design von der Logik so trennt, dass diese umfangreichen Ausgaben über den statischen HTML-Teil der JSP geregelt werden. SunMicrosystems beschreibt die Vorteile von JSPs mit folgenden Eigenschaften: Plattformunabhängigkeit, einfache Administration, Trennung von Logik und Design, stärkere Performance, Erweiterbarkeit. JSP eignet sich besonders, wenn serverseitige Entscheidungen oder Aktionen notwendig sind und deshalb bei Datenbankabfragen der Clients oder bei der Prüfung der Zugangsberechtigung sehr verbreitet sind. Auf eCommerce Seiten stellt es sich in Warenkorbsystemen als sehr nützlich heraus. Ziel dieser Technologie ist es, auf die speziellen Anforderungen und Wünsche des Benutzers einzugehen, und dynamisch eine passende bzw. richtige Antwort mit Hilfe statischen HTML als Design zu geben. Somit werden die Bedürfnisse der Benutzer durch JSP befriedigt. JSP -Dateien (.jsp Endungen) werden auf Webservern gespeichert. Obwohl sie formal wie HTML-Dateien aussehen, werden sie intern anders behandelt. Der JSP-Code wird dabei von den Tags <% eingeleitet und durch %> beendet. Eine JSP -Datei wird vom Server in ein Servlet konvertiert, indem der Quell-Code aus der JSP –Datei (Skripte) in ein Servlet übertragen wird. Dabei wird das statische HTML einfach als Ausgabe (Output-Stream) behandelt. Anschließend wird das Servlet übersetzt. Dies geschieht entweder beim Installieren der Datei oder bei der ersten Anforderung der Seite. Bei jedem Aufruf der JSP leitet sie die Anfrage an das entsprechende Servlet, das daraufhin die Ausgabe an den Client sendet. Falls die JSP geändert worden ist, wird ein neues Servlet erstellt, übersetzt und ausgeführt. Aus diesem Grund überprüft das Servlet immer, ob die JSP erneuert worden ist. Darüber hinaus wird ein spezieller Web-Server mit einem JSP-Engine (standalone container) bzw. einem Web-Server wie Apache, Netscape Enterprise Server, Microsoft Personal Web Server oder Internet Information Server mit aufgesetzter Engine (add-on) benötigt, um JavaServer Pages verwenden zu können. Zu den populärsten JSPEngine zählen: Resin von Caucho [3], Tomcat von Apache [36] und JRun von Macromedia/Allaire [20]. JSPs weisen auch gewisse Nachteile auf. Zum einen sind die JSPs von der Sicherheit her von Außen leicht angreifbar. Um dieses Problem zu lösen, bietet Sun die Erweiterung JSSE (Java Secure Socket Extension) an. Falls Basisklassen geändert werden, 24 die auch von JSPs genutzt werden, müssen die bisher generierten auf dem Server befindlichen JSPs gelöscht werden. Das hat zur Folge, dass die JSPs bei jeder Anfrage neu übersetzt werden müssen. Wenn mehrere JSPs in einer HTML-Seite angefordert werden, kann dies zu „langen Wartezeiten und hoher Serverbelastung“ führen. 2.3.4 PHP PHP bedeutet Hypertext Preprocessor([25] [26]) und bezieht sich auf sich selbst. Es ist eine eigenständige Skriptsprache, d.h., sie besitzt eine eigene Syntax und eine sehr große Funktionsvielfalt. Wie fast alle dieser Skriptsprachen ist auch PHP in HTML eingebettet und verwendet normalerweise keine eigenständigen Dateien. Allein der Dateiname ändert sich von ".htm" / ".html" zu ".php". Dies hat den großen Vorteil, dass die Ausgabe der PHP-Skripte an der entsprechenden Stelle direkt in die HTML-Seite eingebunden und ausgegeben werden kann. PHP wird oft in Verbindung mit HTML-Formularen eingesetzt, weil die Daten, die sie verschicken, auf besonders einfache Weise mit Hilfe von PHP ausgewertet und weiterverarbeitet werden können. Seine eigentlichen Stärken spielt PHP dann dabei aus, wenn es im Zusammenspiel mit einer Datenbank genutzt wird. PHP unterstützt eine große Anzahl von Datenbanken; u.a. Adabas D, dBase, FilePro, Interbase, mSQL, MySQL, Informix, ODBC, Oracle, Sybase, Solid, Velocis, Unix dbm, PostgreSQL. Insgesamt 19 verschiedene Typen können über PHP angesprochen und verwendet werden. Dabei stehen alle benötigten Funktionen für die Datenbankoperationen direkt zur Verfügung und müssen nicht erst implementiert werden. Eine weitere wichtige Eigenschaft von PHP liegt in der Kommunikationsmöglichkeit über eine Vielzahl von Protokollen, u.a. IMAP, SNMP, NNTP, POP3 oder auch HTTP. Somit ist es z.B. möglich, direkt in PHP eine Mail zu erstellen und zu versenden. Falls ein benötigtes Protokoll nicht unterstützt werden sollte, so bleibt noch die Möglichkeit, direkt über Netzwerk-Sockets zu kommunizieren. Letzendlich fehlt noch die Integration in einen Webserver wie z.B. den weit verbreiteten Apache-Server, ohne den, PHP-HTML-Seiten, die von Clients wie Browsern angefragt werden, nicht vor der Auslieferung modifizieren kann. Insgesamt ergibt sich nun aus der Summe dieser Teile die Möglichkeit, dynamisch generierte Web-Seiten zu erzeugen. Die Skriptsprache PHP unterstützt eine objektorientierte Programmierung, zwingt aber nicht zu ihrer Verwendung. Es sind also Klassen und Objekte in PHP realisierbar, aber im Gegensatz zu z.B. Java kann man auf deren Verwendung auch komplett verzichten. 25 2.3.5 ASP ASP steht für Active Server Pages [1] und sollte nicht mit "Application Service Provider" verwechselt werden, welches auch mit ASP abgekürzt wird. ASP ist keine eigenständige Skriptsprache. Vielmehr bildet es eine Hülle für schon vorhandene Sprachen wie VBScript, JScript oder Perl und besitzt aus diesem Grund auch keine eigene Syntax. Da es auf anderen Skriptsprachen basiert, kann man sich je nach Fähigkeiten und Neigungen die geeignete aussuchen und in ASP verwenden. Vom IIS (Internet Information Server), der vermutlich der meistgenutzte Server im Zusammenhang mit ASP ist, werden direkt nur VBScript und JScript unterstützt. Um weitere Sprachen einzubinden, müssen entsprechende Interpreten installiert werden. Auch ASP wird in HTML eingebunden, wobei in diesem Fall die Datei mit ".asp" endet. Da ASP über keine eigenen Funktionen für Datenbank- oder Dateisystemzugriffe verfügt, müssen diese über Kommunikationsobjekte ergänzt werden. Die Möglichkeiten von ASP hängen immer von den zur Verfügung stehenden Komponenten ab. Für Standardprogrammierelemente wie Schleifen und Bedingungen wird die Syntax der verwendeten Skriptsprache übernommen. Obwohl verschiedene Projekte mit dem Ziel, ASP auf unterschiedlichen Betriebssystemen zu ermöglichen, existieren, bleibt ein Grossteil der ASP-Seiten auf dem Server mit den Betriebssystemen der Windows-Familie und dem Internet Information Server beschränkt, so dass nicht von der gleichen Plattformunabhängigkeit wie bei PHP gesprochen werden kann. PHP versus ASP Während PHP eine große Sprachenpalette aufweist, so dass eine Erweiterung nur selten nötig ist, setzt man bei ASP auf einen sehr geringen Rahmen, der sich leicht erweitern lässt und auch ohne Ergänzungen nur für sehr einfache Aufgaben ausreicht. PHP ist eher ein komplettes Rundumpaket, während ASP allein nur einen kleinen Teil einer WebAnwendung darstellen kann. Da der Quellcode des PHP-Interpreters frei verfügbar ist, kann man PHP auch auf unterschiedliche Server-Betriebssysteme verwenden, während sich ASP meistens auf die Windows-Systeme begrenzt und der Quellcode des Interpreters nicht veröffentlicht wird. Eine abschließende Entscheidung für PHP oder ASP fällt schwer. Es hängt stark von der Umgebung und Situation ab. In einer Firma mit ausschließlich Windows-Servern spricht vieles für ASP, während im privaten Bereich wohl eher PHP aufgrund der Kostenfrage bevorzugt wird. Eine pauschale Empfehlung ist jedoch nicht möglich, zumal viele Faktoren eine Rolle bei der Entscheidung spielen. 26 2.4 HTML Template Templates sind Layout/Design-Vorlagen, die meistens aus HTML-Code bestehen. Der Hauptvorteil von Templates besteht in der strikten Trennung von Code und HTML. Somit wird eine Web-Seite nicht nur übersichtlicher, auch die Arbeit an der Web-Seite kann besser zwischen Entwickler/Programmierer und Designer aufgeteilt werden. Der Designer kann in Ruhe ein HTML-Dokument erstellen. An den Stellen, wo später der dynamische Inhalt eingesetzt werden soll, fügt er Variable/Platzhalter ein. Der Programmierer setzt für diese Variablen Werte ein, und muss sich somit nicht um das Design kümmern. Wenn sich in der HTML-Datei etwas ändert, muss das Script nicht geändert werden und umgekehrt. Das HTML-Template ermöglicht somit den Einsatz von vorgefertigten HTML-Seiten innerhalb der Web-Applikation-Umgebung. Statisch erstellte Seiten, die mit Hilfe eines HTML-Editors entwickelt wurden, werden somit mit dynamischen Komponenten, wie z.B. einer Datenbank Abfrage, erweitert. Als Beispiel zur Erläuterung stellen wir ein Modul für die HTML-Templates (HTML.Template.java [18]) vor, die mit Javacode validiert werden. Das Modul beinhaltet folgende Tags bzw. Variablen: <tmpl_var>, <tmpl_if>, <tmpl_unless>, <tmpl_loop> und <tmpl_include>. Die if, unless und loop sind Blocktags und müssen mit entsprechenden </tmpl_if>-, </tmpl_unless>- und </tmpl_loop>-Tags abgeschlossen werden. Zusätzlich können die <tmpl_if>- und <tmpl_unless>-Tags optional ein <templ_else> beinhalten. Der <tmpl_include>-Tag wird validiert, wenn das HTML-Template erzeugt wird. Alle anderen Tags werden erst bei der Ausgabe des Templates ausgeführt. Der <tmpl_var>-Tag ist das Einfachste und kann an jeder Stelle innerhalb des Templates eingesetzt werden. Der <tmpl_loop> Tag ist ein wenig komplizierter als die anderen. Er ermöglicht es Listelemente in einer HTML-Blockstruktur zu generieren. Jedes Element der Liste wird mit Hilfe des <tmpl_var>-Tags erzeugt. Das Modul stellt außerdem Methoden durch Bibliothekklassen zur Verfügung, mit deren Hilfe Werte zu diesen Variablen zugewiesen werden. Abbildung 12 stellt eine HTM- Template (test.templ) dar. In ein Java-Programm wird das Template mit Hilfe von Bibliothek-Methoden eingelesen. Die Variablen „home“ (Abbildung 12 Zeile 4) und „cwd“ (Abbildung 12 Zeile 6) sind Platzbehälter, die mit dynamischen Inhalten von dem Java-Programm initialisiert werden. 1 2 3 4 5 6 7 8 <html> <head><title>Test Template</title></head> <body> My Home Directory is <tmpl_var home> <p> My current working directory is set to <tmpl_var cwd> </body> </html> Abbildung 12: Beispiel eines HTML Templates – test.templ 27 Das Java-Programm aus Abbildung 13 bearbeitet das Template test.tmpl. Durch die Zugriffsmethode setParam (variable, wert) wird die in das Template definierte Variable mit dem entsprechenden Wert initialisiert (vgl. Abbildung 13, Zeilen 9 und 10). Das Template wird dann schließlich durch ein Output-Stream ausgegeben (vgl. Abbildung 13, Zeile 12). 1 import HTML.Template; 2 public class Test { 3 public static void main(String [] args) { 4 try { 5 // Create the Template object 6 Template t = new Template("test.tmpl"); 7 8 // Set some parameters 9 t.setParam("home", System.getProperty("user.home")); 10 t.setParam("cwd", System.getProperty("user.dir")); 11 12 System.out.print(t.output()); 13 } catch(Exception e) { 14 } 15 } 16 } Abbildung 13: Beispielprogramm für die Validierung von test.tmpl 2.5 Unified Modeling Language (UML) Um Software von hoher Qualität zu angemessenen Kosten zu erstellen, ist ein ingenieurmäßiges Vorgehen bei der Software-Entwicklung Voraussetzung. Dazu gehören ein Vorgehensmodell, die Auswahl standardisierter Sprachen und das Management aller Ressourcen. Generell wird das Vorgehensmodell bei der Entwicklung einer Applikation, also einer Software, als Software-Entwicklungsprozess bezeichnet. Der SoftwareEntwicklungsprozess besteht aus einer Folge von kleinen Entwicklungsschritten, die durch Lebenszyklusmodelle beschrieben werden. Abbildung 14 stellt als Beispiel das WasserfallModell dar, das aus Folgen von Phasen besteht. Das Resultat einer Phase ist die Eingabe für die nächste Phase. Der Prozess umfasst alle notwendigen Arbeitsschritte, von der Analyse bis zur Wartung. 28 Abbildung 14: Der Software-Entwicklungsprozess als Wasserfall-Modell Die UML kennzeichnet eine standardisierte graphische Notation für objektorientierte Modelle. Sie besteht aus einer Anzahl unterschiedlicher Diagramme, die spezielle Aufgaben bei der Entwicklung eines Software-Systems übernehmen. Die einzelnen UMLDiagramme lassen sich in drei Modellgruppen aufteilen: • • • Analyse-Modell: Die Modellkategorie unterstützt die Analysephase des SoftwareEntwicklungsprozesses. Der Entwickler verschafft sich einen Überblick über die Anforderungen des Systems. Danach kann er die Funktionalität und den Aufwand des Systems ermitteln bzw. abschätzen. Zu dieser Kategorie zählt das Use-CaseDiagramm. Statisches Modell: Hier wird die Struktur des Systems entworfen. Auf dem Klassen-Diagramm wird das Konzept des Systems erstellt. Das Package-Diagramm sorgt für die logische Struktur. Dynamisches Modell: Diese Modellart geht auf die Objekt-Zustände und die Interaktion zwischen den Objekten ein. Die einzelnen Diagramme bieten graphische Notationen an, um die Lebensdauer und die Aktivität von Objekten anzuzeigen. Die Diagramme bieten auch die Möglichkeit, den Nachrichtenaustausch, das Zusammenspiel und die parallelen Abläufe zwischen den Objekten darzustellen. Zu dieser Modellart zählen das Sequenz -, das Kollaborations-, das Zustands- sowie das Aktivitäts-Diagramm. Eine Einordnung der reinen UML in den Software-Entwicklungsprozess beschränkt sich auf die Punkte 1 und 2. Die Software-Entwicklung mittels UML wird heutzutage durch CASE-Tools wie Rational Rose [27] [38], Together J [35] oder Fujaba [10] unterstützt. Diese Programme erlauben aus dem UML-Design entsprechenden Code eine 29 Programmiersprache zu generieren. Der Einsatz von UML mit Hilfe von CASE-Tools wirkt sich auf die Punkte 1 bis 4 des Software-Entwicklungsprozesses aus. 2.6 Das Werkzeug Fujaba Fujaba (From UML to Java and back again) ist eine Entwicklungsumgebung, die in der AG Softwaretechnik an der Universität Paderborn [10] entwickelt wurde. Fujaba ermöglicht es, aus UML- Spezifikationen Java-Code zu generieren. Weiterhin ist es möglich, aus bestehendem Quellcode durch geeignete Heuristiken die entsprechenden UML-Spezifikationen wieder zurückzugewinnen (Reengineering), um diese auf einer höheren Abstraktionsebene zu modifizieren. Dadurch wird einerseits die übersichtliche Handhabung auch größerer Projekte ermöglicht, und andererseits deren Entwicklungszeit verkürzt. Durch entsprechende Konsistenzprüfungen werden fehlerhafte Programme vermieden. Im Folgenden wird eine kleine Einführung über die in Fujaba definierten UML Klassen-, Aktivitäts- und Storydiagramme gegeben. 2.6.1 Fujaba UML-Klassendiagramme Fujaba schafft dem Benutzer Voraussetzungen für die Erstellung und Visualisierung von Klassendiagrammen nach UML. Daraus besteht die Möglichkeit, Java-Quelltexte zu generieren, die die modellierten Eigenschaften der Klassendiagramme widerspiegeln. Klassendiagramme werden verwendet, um statische Eigenschaften eines Systems zu modellieren. Unter Eigenschaften versteht man in diesem Zusammenhang die Struktur von Klassen beziehungsweise Datentypen (durch Variablen), sowie ihre Beziehungen (durch Methoden) zueinander. Bei der Spezifikation von Variablen und Methoden werden die UML-Sichtbarkeitsbereiche (private, public, etc) angegeben. Bei Variablen können noch Initialisierungen definiert werden. Man hat auch die Möglichkeit, Vererbungsbeziehungen und Assoziationen zwischen Klassen zu spezifizieren. Dabei werden Kardinalität, Rollenname, Art und Name der Assoziation modelliert. Bei der Quelltexterzeugung werden Klassen und Interfaces auf Java-Klassen und JavaInterfaces abgebildet. Klassen-Variablen werden als private Java-Attribute mit entsprechenden Zugriffsmethoden, deren Sichtbarkeit der der Klassen-Variablen entspricht, in Java modelliert. Für die Klassenmethoden werden, wenn kein Rumpf in Fujaba spezifiert wurde, leere Java-Methoden erzeugt. Assoziationen werden auf Paare von Referenzen in den beteiligten Klassen abgebildet. Dabei werden für die Referenzen Zugriffsmethoden generiert, die sich gegenseitig aufrufen. Dadurch wird der Konsistenzzustand von Referenzen sichergestellt. 30 Assoziationen mit Kardinalitäten größer als eins werden durch Container-Klassen dargestellt. Auch hier wird durch die Zugriffsmethoden die Konsistenz der Assoziationen garantiert. Mittels Klassendiagrammen werden statische Eigenschaften eines Systems modelliert. Abbildung 15 stellt als Beispiel ein Klassendiagramm dar. Abbildung 15: Beispiel für einen UML Klassendiagramm aus dem Diagnosesystem Die Erläuterung zu den Elementen von Klassendiagrammen wird in [11, Seiten 13-21] beschrieben. 2.6.2 Fujaba Interaktions-Diagramme Mit einem Klassendiagramm werden statische Eigenschaften eines Software-Systems spezifiziert. Programmabläufe werden dadurch nicht beschrieben. Die dynamische Spezifikation einer Methode oder des Software-Systems kann durch den Einsatz von Diagrammen des dynamischen Modells realisiert werden. Methoden in Fujaba werden durch Blöcke unterteilt, die durch Bedingungen zum Kontrollfuß der Methode zusammengesetzt werden. Außerdem erweitert Fujaba die dynamische Modellierung durch eine neue Diagrammart: Storydiagramm. 31 2.6.2.1 Fujaba UML-Aktivitätsdiagramme Ein Aktivitätsdiagramm ist eine Variante eines Statchart-Diagramms [11, Seiten 26-28] in dem Aktivitäten anstelle von Zuständen verwendet werden. Eine Aktivität repräsentiert die Ausführung von Operationen sowie Transitionen, die durch die abgeschlossene Ausführung der Operationen feuern. Dieser Diagrammtyp soll die Arbeitsweise einer Methode veranschaulichen. Mittels Aktivitätsdiagrammen werden Methoden einer Klasse implementiert. Abbildung 16 stellt als Beispiel die Implementierung der Methode patientSelection () der Klasse Anmelde aus dem Klassendiagramm in der Abbildung 15 dar. Abbildung 16: Beispiel eines Aktivitätsdiagramms Ein Aktivitätsdiagramm (vgl. Abbildung 16) wird mit einer Klassenmethode assoziiert. Der Name wird in der Form Klasse::Methode über dem Diagramm angegeben. Eine normale Aktivität besitzt mindestens eine ausgehende Transition, die nach Beendigung der internen Aktion, die Aktivität feuert. Aktivitäten werden durch ein Rechteck mit konvex gekrümmter linker und rechter Seite dargestellt. Der Ausdruck der Aktion wird innerhalb des Rechteckes aufgeführt. Die Aktion kann durch eine natürliche Sprache, Pseudocode oder in einer Programmiersprache dargestellt werden, wobei Attribute des zugehörigen Objektes verwendet werden können. Jedes Diagramm muss zwangsläufig genau einen 32 Startzustand besitzen. Neben Startzuständen können noch beliebig viele Stoppzustände verwendet werden. Die Erreichbarkeit der Stoppzustände wird in Fujaba nicht verifiziert. Eine ausführliche Beschreibung ist in [11, Seiten 28-29] zu entnehmen. 2.6.2.2 Fujaba UML-Storydiagramme Storydiagramme bestehen aus erweiterten UML-Aktivitätsdiagrammen, wobei die Aktivitäten entweder Java-Quellecode oder Story-Pattern ([11, Seiten 42-52] [45]) enthalten. Story Patterns sind Graphersetzungsregeln, die das dynamische Verhalten eines Systems beschreiben. Sie spezifizieren die Modifikationen an Objekten und deren Beziehungen und damit die Objektstruktur des Systems, die sich von der Laufzeitobjektstruktur oder dem Wirtsgraphen beschreiben lässt. Ein Story Pattern wird durch ein modifiziertes Kollaborationsdiagramm dargestellt. Dieses Diagramm besteht aus Variablen (oder Objekten) und Links, die die Variablen miteinander verbinden. Die Modifizierungen, die nach der Ausführung des Story Patterns im Wirtsgraphen stattfinden sollen, werden von den Elementen, die mit «create» oder «delete» markiert sind, modelliert. Ferner ist es möglich, mit Attributzuweisungen die Attributwerte von Objekten zu verändern oder mit Attributbedingungen Bedingungen über Attributwerte zu setzten. Diese Eigenschaften eines Story Patterns beschreiben dessen grundlegende Semantik. Die Darstellungsform von Story-Diagrammen ähnelt also der der UML-KollaborationsDiagrammen. Rechtecke repräsentieren Objekte und es wird zwischen gebundenen und ungebundenen Objekten unterschieden. Ein gebundenes Objekt ist dem Story-Pattern bereits bekannt, während ein ungebundenes noch erzeugt werden muss. Die Objekte werden durch ihren Namen und die Angabe ihres Typs im Diagramm beschrieben. Linien zwischen Objekten sind „Links“ und repräsentieren Ausprägungen von Assoziationen, die im Klassendiagramm spezifiziert sind. Objekte und „Links“ können durch „Modifier“ wie «create» (Objekt oder Link wird bei der Ausführung des Story-Pattern neu im Speicher angelegt), «delete» (Objekt oder Link wird bei der Ausführung des StoryPattern gelöscht) etc. zugeordnet werden. Objekte und Links ohne Modifier gehören zu dem Ausgangsgraph, der in der Objektwelt existieren muss, bevor das Story-Pattern ausgeführt wird. Man kann auch Story-Pattern-Bedingungen mit dem Zustand der Objekte im Ausgangsgraph verknüpfen. Wird ein Ausgangsgraph gefunden, so werden zugehörige Objekte und Links erzeugt bzw. gelöscht, um den gewünschte Zielgraph zu erreichen. Auch beim Erzeugen von Objekten können Operationen angegeben werden (z.B. Variablenzuweisungen), die die Zustände neu erzeugter Objekte verändern. Mittels Story-Diagrammen werden Methoden einer Klasse implementiert. Abbildung 17 stellt als Beispiel eine Aktivität der Methode patientSelection der Klasse Anmelde aus dem Klassendiagramm der Abbildung 15 dar. 33 Abbildung 17: Beispielaktivität 34 3. Verwandte Ansätze Im Bezug auf Web-Applikationen gibt es Tools, Technologien und Skriptsprachen, die für ihre Entwicklung zuständig sind. Diese Tools sind allgemein für die Pflege von Datenbanken geeignet. Will man jedoch komplexe Geschäfte realisieren, fehlt es an Werkzeugen zu ihrer Modellierung. Diese erweist sich für solche Applikationen als wichtig, um einerseits die bei der Motivation genannten Nachteile zu beheben und andererseits ihre Komplexität in den Griff zu bekommen. In Abschnitt 3.1 wird das Coocon Projekt [8] als ein geeignetes Tool für den Transport von Daten vorgestellt. Abschnitt 3.2 thematisiert die UML-Methodiken für die Modellierung von Web-Applikationen. Abschnitt 3.2.1 präsentiert eine UML Erweiterung für das Design von Web-Sites [4] [5]. In Abschnitt 3.2.2 wird eine UML Erweiterung für den Entwurf von Web-Sites [21] [22] [23] beschrieben. Eine modulare Modellierung von dynamischen Web-Seiten mit UML [24] [51] wird in Abschnitt 3.2.3 vorgestellt. Jeder Abschnitt dieses Kapitels wird mit einem Fazit abgeschlossen, das die Einschränkungen der vorgestellten Ansätze in Bezug auf die Ziele dieser Arbeit beschreibt. 3.1 Das Cocoon Projekt Das Cocoon-Projekt ist ein in Java geschriebenes Framework für Web-Inhalte, das im Rahmen des Apache XMLProjects Cocoon entwickelt wird. Cocoon ermöglicht die XMLFähigkeit in den Server zu übertragen. Mit Cocoon werden XML/XSL-Dokumente derartig aufbereitet, dass ein beliebiger Client sie darstellen kann, wobei der Client nicht immer ein Browser sein muss, sondern etwa auch ein WAP Handy. So können durch Definition verschiedener Stylesheets für dieselben Inhalte unterschiedliche Ausgaben am Client erzielt werden - sei es, um die Darstellung für unterschiedliche Browser zu optimieren oder überhaupt um den Inhalt in einem anderen Format zu präsentieren (XHMTL, HTML, XML, WML, PDF, etc.). Wenn in Zukunft die Browser selbst XML/XSL unterstützen, fallen keine Umstellungen an, so können die Daten direkt ohne den heute noch notwendigen Zwischenschritt der Transformation in HTML dargestellt werden. Ein weiterer Vorteil besteht darin, dass ein und dieselben Daten in verschiedenen Formaten dargestellt werden können. Ohne XML/XSL wäre dies mit erheblichem Wartungsaufwand verbunden. Durch die Trennung von Inhalt (in XML Dokumenten hinterlegt), der Geschäftslogik (in eXtensible Server Pages) und dem Layout (der Präsentation am Client) wird es möglich, umfangreichere Web-Projekte zu entwickeln und entsprechend zu warten. Die drei 35 Teilbereiche können von unterschiedlichen Personen betreut werden, ohne jeweils die anderen beiden Bereiche zu beeinflussen, sofern man sich an die vereinbarten Schnittstellen hält. Das XML-Dokument wird mit Hilfe eines XML-Parsers, dem im XML-Apache-Project entwickelter Apache Xerces, in eine interne Baumstruktur, dem Document Object Model (DOM), überführt. Auf diese Datenstruktur kann dann einer der zahlreichen Prozessoren (XSP Processor, SQL Processor, LDAP Processor, DCP Processor, etc) angesetzt werden, der die Daten entsprechend der gewünschten Programmlogik bearbeitet und verändert. Anschließend wird mit dem XSLT-Processor Apache Xalan eine Ausgabe für den jeweiligen Client erzeugt. Abbildung 18: Funktionsprinzip von Cocoon Zusammenfassend ist Cocoon ein leistungsfähiges Framework für die Manipulation von XML-Dokumenten. Cocoon eignet sich besonders zur Schaffung von Portalen, die viele unterschiedliche Endgeräte mit einer Datenbasis bedienen möchten. Dabei ist die flexible Anpassung an die verschiedenen Formate von großem Vorteil. Abbildung 18 stellt das Funktionsprinzip von Cocoon dar. Das Erzeugen von XML-Daten geschieht mit JSP und wird bei der Realisierung von Web-Anwendungen auf Basis von Cocoon manuell implementiert. 3.2 UML Erweiterung für den Entwurf von WebApplikationen Die Entwicklung von Web-Applikationen wird von verschiedenen Teams (Designer, Entwickler) realisiert. Für eine bessere Verständigung und Integration ihrer Arbeit ist eine gemeinsame Sprache notwendig, die ihre Arbeit auf dem gleichen Abstraktionsniveau beschreibt. Die UML wird hierfür eingesetzt, da sie die Rolle der verschiedenen Entwicklungsteams unterstützt. 36 3.2.1 Modellierung von Web-Applikationen mit UML Dieser Ansatz stammt von Conallen [4] [5] und bezieht sich auf das Layoutmodell von Web-Applikationen. Er spricht Designer von Web Applikationen an. Mit der Annahme, dass Web Applikationen sich nicht von dynamischen Web-Seiten unterscheiden, geht es bei dem Ansatz von Conallen darum, ein Design-Modell für Web-Seiten mit UML zu modellieren. Die Formatierung der Seite ist an dieser Stelle irrelevant und hat auch keinen Einfluss auf die Geschäftslogik des Systems, die eher von einer Skriptsprache gesteuert wird. UML ermöglicht eine Web-Seite als UML-Objekt auszudrücken. Auch die Eigenschaften der Web-Seite können mit UML ausgedrückt werden. Offen bleibt die Frage, wie die Skripte, die die Interaktionen innerhalb der Seite realisieren, einzuordnen sind. Man kann leicht Variablen und Funktionen, die innerhalb des Skripts definiert sind als Attribute bzw. Methoden des UML-Objekts einordnen. Da diese Skripte beim Client oder Server ausgeführt werden können, sollten ihre zugehörigen Attribute und Methoden unterschieden werden, um ihren Ablauf besser steuern zu können. Conallen benutzt eine UMLErweiterung, die auf dem Stereotypenprinzip aufbaut, um ein Design-Modell für WebApplikation zu modellieren. Web-Komponenten werden stereotypisiert, um einerseits Seiten mit Client- bzw. Server- basierten Skripten unterscheiden zu können und andererseits, um die zugehörigen Komponenten bzw. Attribute und Methoden dieser Skripte modellieren zu können. Der Ansatz umfasst die Layoutmodellierung und Implementierungsaspekte. Web-SeitenElemente wie Form, Frameset, Target und Web-Applikation Komponenten wie Serverpage und Clientpage werden durch eine UML-Erweiterung von Conallen definiert. Will man allerdings Abläufe der Applikation mit UML modellieren, fehlen bei diesem Ansatz nicht nur eine Zugriffsschicht auf die Geschäftslogik und auf die Datenbank, sondern auch eine geeignete Schnittstelle, die ihre Zuordnung realisiert, um dadurch die Modellierung der Interaktionen der Applikation ermöglichen zu können. 3.2.2 Eine UML Erweiterung für den Entwurf von Web-Sites Die hier vorgestellte Erweiterung ([21] [22] [23]) ist mit einer Methodik für HypermediaDesign verbunden, die ausgehend von einem Use-Case Modell der Anwendung aus den folgenden grundlegenden Schritten besteht: Erstellung eines konzeptionellen Modells, ein Navigationsentwurf und eine Präsentationsmodellierung. Bei der Erstellung des konzeptionellen Modells werden die in den Use-Cases beschriebenen Anforderungen berücksichtigt. Dabei werden traditionelle objektorientierte 37 Vorgehensweisen zur Erstellung von Klassendiagrammen verwendet. Als Ergebnis wird ein konzeptionelles Modell als Grundlage für den Navigationsentwurf erstellt. Beim Navigationsentwurf wird zunächst ein Modell des Navigationsraums entworfen, das darüber Auskunft gibt, welche Objekte durch Navigationen innerhalb der HypermediaAnwendung besucht werden können. Aus dem konzeptionellen Modell werden sozusagen navigierbare Objekte festgelegt. Als Ergebnis wird ein Navigationsraum-Model erstellt. Danach wird beschrieben, wie auf diese Objekte zugegriffen werden kann. Eine Erweiterung der UML zur Modellierung von Zugriffselementen wie Indizes, GuidedTours, Queries und Menus wird realisiert. Das Ergebnis erfolgt als NavigationsstrukturModel. Bei der Präsentationsmodellierung wird in einem „abstract Interface Design“ beschrieben, wie dem Benutzer die einzelnen Objekte des Navigationsraums und ihre Zugriffselemente präsentiert werden. Aus diesem Vorgang kommt ein Präsentationsmodell als strukturelle Organisation der Präsentation heraus, jedoch nicht das konkrete physische Erscheinungsbild der Informationen. Die meisten Schritte der vorgestellten Methodik können automatisch durchgeführt werden und bilden daher eine geeignete Grundlage für die Entwicklung von Werkzeugen zur Generierung von Web-Seiten. Der Ansatz modelliert Web-Seiten und ihre Zuordnung innerhalb der Applikation. Serverskripte und ihre Zuordnung zu Layout-Elementen, Geschäftslogik und Datenbankzugriff werden bei diesem Ansatz nicht berücksichtigt. Sie sind allerdings notwendig, um mit UML die Client/Server-Interaktionen modellieren zu können. 3.2.3 Modulare Modellierung von dynamischen Web-Seiten mit UML Der Ansatz von Lohmann & Schattkowsky [24] ermöglicht den Entwurf von WebApplikation in Modulen. Er basiert auf UML und ist für kleine und mittelmäßige WebApplikationen geeignet. Spezifische Use-Case Diagramme, Aktivitätsdiagramme und Klassendiagramme werden eingesetzt, um die strukturellen und verhaltensgemäßen Aspekte der Applikation festlegen zu können. Diese Aspekte ermöglichen Sichten, die von verschiedenen Arbeitsteams modelliert werden. Eine Web-Seite wird als Komposition von wiederverwendbaren Modulen betrachtet. Man unterscheidet ein Modul der Logik und ein Design-Modul, das einer Menge von wiederverwendbarem Design Template entspricht. Beide Module haben eine Darstellung sowohl auf der Clientebene (Client Seite Modul) als auch auf der Serverebene (Server Seite Modul) (vgl. Abbildung 19). 38 Client ClientPageModule consists of LogicInterface Server ClientPage DesignElement Serv erPage generates 0..n 1 0..n 0..n BusinessLogic «use» Hyperlink DesignTemplate «use» Abbildung 19: Abstraktes Model der Web Applikation Auf der Clientebene existieren Layout-Elemente, die ein verwendbares Design-Modul und eine Logikschnittstelle darstellen. Weil die Generierung der Clientseiten die Aufgabe des Logikmoduls in diesem Model enthält, und Logik und Design vermischt, wird das Logikmodul in kleinere Module (Renderer-Modul, Processor-Modul) unterteilt. Ziel dabei ist die Trennung und die Verkapselung der Logik und das Design bei der Modellierung der Applikation und eine konsistente Integration ihrer Ergebnisse. Auf diese Weise wird die Trennung von Geschäftslogik und Design der generierten Seite vollbracht. Verschiedene Use-Cases des Logikmoduls werden als Worksflows, bestehend aus Elementen des Logikmoduls, beschrieben. Die Logikschnittstelle, die auf der Clientebene das Logikmodul darstellt, wird von dem Renderer Modul generiert. Seine Aufgabe besteht in der Generierung des Client-SeiteModuls mit Hilfe von Daten, die aus dem Processor Modul stammen. Die Berechnung dieser Daten findet in dem Processor-Modul statt, und benutzt Angabedaten aus der Clientanfrage oder aus Datenbanken. Falls keine Daten existieren, generiert das Renderer Modul immer das gleiche Client-Seite-Modul und kann so mit dem entsprechenden Design-Modul ersetzt werden. Um das Erfassen und die Präsentation der Systemanforderungen zu ermöglichen, wird das Use-Case-Diagramm eingesetzt. Es beschreibt den funktionellen Aspekt des Systems aus der Sicht des Users. Das Use-CaseDiagramm wird danach mit Hilfe weiterer Use-Cases und schließlich Aktivitätsdiagrammen verfeinert. Abläufe der Use-Cases werden somit beschrieben und auf diese Weise zu Client/Server-Interaktionen. Um Web-Seiten aus dem Server-Seiten Modul generieren zu können, muss die Struktur der Applikation entsprechend modelliert werden. Instanzen des Metamodels werden dafür benutzt, um die entsprechende Spezifikation zu erreichen. Struktur und Komposition von Transienten und persistenten Daten der Web Applikation werden mit Hilfe von UMLStereotypen und Elementen aus dem Metamodel (vgl. Abbildung 20) realisiert. Die Methodik von Lohmann & Schattkowsky verwendet Use-Case-, Aktivitäts- und Klassen-Diagramme, um Struktur und Verhalten der Web-Applikation zu verwirklichen. Dadurch wird die Entwicklung der Applikation in verschiedene Module verteilt, so dass verschiedene Entwicklungsteams unabhängig arbeiten können. Der Ansatz von Lohmann und Schattkowsky ermöglicht eine Trennung von Design und Logik bei der Entwicklung 39 von Web-Applikationen. Dynamische Inhalte werden von Skript-Templates durch den Entwickler der Applikation realisiert und den vom Designer zu erstellenden Web-Seiten hinzugefügt. Die Formatierung der dynamischen Inhalte und das Einfügen in der richtigen Web-Seite werden manuell implementiert. Der Ansatz bietet keine UML-Zugriffsschicht auf die Layout-Elemente und auf die Datenbank, die eine UML-Modellierung von dynamischen Web-Seiten ermöglichen kann. contains Serv erPage 1..n Serv erPageModule 1..n contains Link DesignModule LogicModule 1..n Alternativ e BeginUseCase 1..n UseCase 1 LogicElement next uses 1..n 1..n 1..n UserDecision allows Abbildung 20: Metamodel für den Aufbau des Klassendiagramms 40 4. Modellierung von dynamischen Web-Seiten mit UML Dieses Kapitel beschäftigt sich mit der Konzeption und der Realisierung eines Mechanismus, der die Modellierung und Generierung von dynamischen Web-Seiten mittels UML ermöglicht. Durch diesen Mechanismus soll die Kommunikation zwischen Layout-Elementen, Geschäftslogik und Datenbank zustande kommen. Mit Hilfe der Kommunikation werden die dynamischen Web-Seiten modelliert. Das Fujaba CASE-Tool wird eingesetzt, um die Interaktionen der Web-Applikation bzw. die dynamischen WebSeiten zu realisieren. 4.1 Konzept Die Modellierung einer Web-Applikation lässt sich allgemein auf die Realisierung von dynamischen Web-Seiten zurückführen. Bei der Ausführung des durch eine Clientanfrage angesprochenen Serverskripts wird die dynamische Web-Seite generiert. Die Ausführung des Serverskripts besteht allgemein aus folgenden Schritten: die Aktualisierung der Geschäftslogik und die Generierung einer dynamischen Seite als Antwort auf die Clientanfrage. Das Serverskript, das die dynamische Seite generiert, wird meistens manuell Implementiert. Es gilt allgemein als eine Mischung von Logikcode und Layout-Elementen, die die generierten dynamischen Inhalte für die Präsentation an den Client formatiert. In diesem Abschnitt möchten wir einen Mechanismus konzipieren, der die Generierung und das Layout von dynamischen Inhalten mit UML modelliert. 4.1.1 Template Mechanismus Die Modellierung und Generierung von dynamischen Web-Seiten wird mit Hilfe des Templates-Mechanismus realisiert. Bei diesem Mechanismus ist das Template eine Schablone, welche das Layout der fertigen Antwortseite beinhaltet. An bestimmten Stellen beinhaltet das Template jedoch leere Layout-Elemente. Diese leeren Layout-Elemente werden erst durch Aufruf und Abarbeitung des Serverskripts mit dynamischem Inhalt ausgefüllt. 41 Für die Modellierung der Web-Applikation wird dem Entwickler vom Designer eine Template-Bibliothek zur Verfügung gestellt. Für jede Clientanfrage genügt allgemein mindestens ein Template. Bei der Modellierung der Antwortseite wird das Template eingelesen und mit dynamischem Inhalt ausgefüllt. Abbildung 21 stellt den Ablauf für die Generierung einer dynamischen Web-Seite dar. Das Layout-Schema stellt die Layout-Elemente dar. Die Web-Schnittstelle definiert eine Zugriffsschicht auf das Layout-Schema und die Geschäftslogik. Templates werden von der Web-Schnittstelle eingelesen. Für jede Anfrage wird das entsprechende eingelesene Template mit Hilfe der Zugriffe auf das Layout-Schema und die Geschäftslogik mit dynamischem Inhalt erweitert. Die Web-Schnittstelle wird eingesetzt, um die Geschäftslogikaktualisierung und die Generierung von dynamischen Web-Seiten zu modellieren. Bei der Modellierung der dynamischen Web-Seiten werden dynamische Inhalte erzeugt, formatiert und in passenden leeren Layout-Elementen des eingelesenen Templates eingefügt. Nach der Ausarbeitung aller leeren Layout-Elemente wird die Antwortseite zurückgeneriert. Die Zugriffe auf die Layout-Elemente des Templates werden durch geeignete Methoden von der Web-Schnittstelle zur Verfügung gestellt. Abbildung 21: Ablauf der Modellierung und Generierung von dynamischen Web-Seiten Für die Verwirklichung der Abläufe aus Abbildung 21 müssen das Layout-Schema, die Web-Schnittstelle, die Geschäftslogik und das DB-Schema auf das gleiche Abstraktionsniveau beschrieben werden. Mit UML werden das Layout- und das DBSchema in Klassendiagrammen abgebildet. Dadurch definieren wir eine objektorientierte Zugriffsschicht, die der Web-Schnittstelle ermöglicht, die Zugriffe auf die LayoutElemente und auf die Datenbank zu realisieren. Außerdem definiert die Web-Schnittstelle Methoden anhand der Zugriffsschicht auf das Layout-Schema, die das Zugreifen auf die Layout-Elemente ermöglichen. 42 Abbildung 22 stellt die Zuordnung der zu realisierenden Komponente aus Abbildung 21 in UML-Modellen dar. Die Modellierung der Struktur und des Verhaltens einer WebApplikation wird durch die zu realisierenden Modelle verwirklicht. Das Layout-Schema, das die Struktur von Layout-Elemente und ihre Beziehung miteinander definiert, wird in einem UML-Klassendiagramm überführt. Auch das DB-Schema wird eingelesen und im Klassendiagramm abgebildet. Die Web-Schnittstelle wird durch eine UML-Klasse definiert und realisiert die Zuordnungen zur Geschäftslogik und zu den Layout-Elementen. Somit wird die Meta-Struktur für die Realisierung von Web-Applikationen im Klassendiagramm erstellt und das Verhalten des Systems anschließend im UMLAktivitätsdiagramm modelliert. Die Abbildung des Layout-Schemas im UMLKlassendiagramm wird im Abschnitt 4.1.2 beschrieben. Die objektorientierte Zugriffsschicht auf die Datenbank [40] ist nicht Teil dieser Arbeit gewesen und wurde in einer früheren Diplomarbeit realisiert. Abbildung 22: UML-Zuordnung der zu realisierenden Komponente. 4.1.2 Layout-Elemente Um eine Flexibilität bei der Auswahl der einzusetzenden Layout-Elemente zu gewährleisten, wird die Überführung des Layout-Schemas in ein UML-Klassendiagramm mit der Unterstützung der immer beliebter werdenden Sprache XML realisiert. XML wird nicht nur von vielen Browsern unterstützt, sondern wird auch für die Entwicklung von vielen UML-Tools eingesetzt. Die Struktur der einzusetzenden Layout-Elemente wird durch ein XML-Schema beschrieben. Layout-Elemente und ihre Zuordnungen miteinander werden durch das Schema festgelegt. Ziel in diesem Abschnitt ist die Überführung des XML-Schemas in ein UML-Klassendiagramm. Es soll außerdem aus dem UML- 43 Klassendiagramm des Layout-Schemas möglich sein, das XML-Schema zurückzugewinnen. Dieses Austauschen zwischen XML-Schema und UMLKlassendiagramm soll eine gewisse Flexibilität bei der Modellierung von WebApplikationen garantieren. Damit wird jede Änderung bzw. Erweiterung des XMLSchemas leicht in ein UML-Klassendiagramm zu aktualisieren sein und umgekehrt. Für die Modellierung der Web-Applikation wird das XML-Schema in einen UMLKlassendiagramm eingelesen. Durch diese objektorientierte Zugriffsschicht auf die Layout-Elemente möchten wir nicht nur die Überführung von Templates als Instanz des XML-Schema in einer Baumstruktur für ihre Modellierung (vgl. Abbildung 23) erreichen, sondern auch das Layout bzw. die Formatierung der zu generierenden dynamischen Inhalte und ihr Einfügen in ASG ermöglichen. Diese Zugriffsschicht unterstützt bei der Modellierung der Applikation die Einhaltung der in der XML-Schema-DTD vorgeschriebenen Regel bezüglich die Layout-Elemente. Abbildung 23: Überführung des XML Schemas in einem UML-Modell Das XML-Schema soll nach der Modellierung einer Applikation weiterhin zur Verfügung gestellt werden, um weitere modellieren zu können. Ein Konzept, das das Austauchen beide Formate unterstützt, ist dafür notwendig. Zu diesem Zweck wird XMI (XML Metadata Interchange [42]) eingesetzt. XMI definiert ein XML-basiertes Austauschformat für UML Metadaten. Anhand XSLT [49], die so genante eXtensible Stylesheet Language Transformation, wird der gewünschte Austausch erreicht. Das XML-Schema wird eingelesen und durch Transformationen in einem UML-Klassendiagramm abgebildet. Fujaba bietet bereits einen Mechanismus für den Austausch von Daten. Dadurch ist es möglich, Fujaba-Projekte in einem GXL - (Graph eXchange Language, [34]) oder XMIFormat zu importieren oder zu exportieren. GXL kennzeichnet ein XML-Format für den Austausch zwischen Software-Entwicklungsumgebungen. Bei der Transformation werden XSLT-Stysheets und DTD des Zielschemas eingesetzt. Das Einlesenkonzept des XML-Schemas in Fujaba wird sich auf den existierende Import/Exportmechanismus stützen. Abbildung 24 stellt den Transformationsablauf dar. Fujaba-Projekte können als FPR-Format gespeichert werden. Das FPR-Format kann mittels eines FPR-XML-Parsers in ein Fujaba-XML-Format überführt werden, das 44 wiederum durch XSLT in ein GXL- oder XMI-Format abgespeichert werden kann. Die erzeugten XMI-, GXL-, Fujaba-XML- und FPR-Formate lassen sich wiederum durch entsprechende Transformationen in einem Klassendiagramm abbilden. Es reicht für das XML-Schema, eine Transformation nach GXL zu realisieren, um das gewünschte UMLModell für Layout-Elemente durch die existierenden Transformationen zu erreichen. Abbildung 24: Ablauf des Transformationsprozesses 4.1.3 DB-Zugriffsschicht Die Überführung des DB-Schemas in einem UML Modell ist in dieser Arbeit in Form einer Diplomarbeit [40] vorausgesetzt. Die „Entwicklung eines Generators für eine objektorientierte Zugriffsschicht auf einer relationalen Datenbank“ erweitert das Projekt Fujaba um die Fähigkeit, eine Verbindung zu einer relationalen Datenbank aufzubauen, die Struktur der Datenbank auszulesen und als logisches Schema in Form eines EER Diagramms anzuzeigen. 45 Aus dem erhaltenen Schema kann ein initiales konzeptionelles Schema in Form des Fujaba UML-Klassendiagramms (vgl. Abbildung 25) erzeugt werden. Der in [40] vorgestellte Generator erzeugt eine objektorientierte Zugriffsschicht auf Datenbanken. Die Zugriffsschicht unterstützt das aus der Datenbankwelt bekannte ACID – Transaktionskonzept bei der Änderung von Daten. Die öffentliche Schnittstelle zu der Zugriffsschicht ist vollkommen datenbankunabhängig. Die datenbankabhängigen Einstellungen sind intern in eigenen Paketen für jede Datenbank gekapselt und prinzipiell austauschbar. Abbildung 25: Überführung der Datenbank in Fujaba 4.1.4 Die Web-Schnittstelle Die Web-Schnittstelle erweist sich als wichtigste Komponente für die Modellierung und Generierung der dynamischen Web-Seiten. Sie wird durch eine UML-Klasse realisiert und modelliert mit Hilfe von UML-Assoziationen die Kommunikation zu Layout-Elementen und zu Geschäftslogikklassen. Abbildung 26 stellt das Konzept der Web-Schnittstelle dar. Sie wird von der WebProviderKlasse repräsentiert. Zwischen den HTMLElement- und WebProvider-Klassen wird eine UML-Assoziation mit dem Namen „hasElement“ definiert. Mit weiteren Eigenschaften einer Assoziation wird zusätzlich an dem jeweiligen Ende die Kardinalität festgelegt. Die „hasElement“-Assoziation drückt aus, dass eine WebProvider-Klasse beliebig vielen HTML-Elementen zugeordnet werden kann und jedes HTML-Element eindeutig einer WebProvider-Klasse gehört. Dadurch wird die Kommunikation zwischen LayoutElementen und der Schnittstelle verwirklicht. Damit lassen sich Layout-Elemente, die von einer Template-Seite eingelesen oder bei der Modellierung von dynamischen Inhalten neu erzeugt werden, mit dem WebProvider-Klasse verbinden. Die Bekanntgabe von LayoutElementen in die Schnittstelle ermöglicht nicht nur ihre Manipulation durch das 46 Serverskript bei der Modellierung von dynamischen Seiten, sondern auch die Generierung von neu erstellten Seiten, die bei Clientanfragen zurückgeschickt werden. Die Web-Schnittstelle muss außerdem mit der Datenbank (in manchen Fällen via Geschäftslogik wie in Abbildung 26 dargestellt) kommunizieren. Durch die „hasLogikClas_i“-Assoziationen werden Logikklassen von der Web-Schnittstelle erreicht. Die Logikklassen sprechen wiederum die Datenbanktabellen durch die „knowDBTable_i“Assoziationen an. Dadurch werden beispielsweise dynamische Inhalte von den Logikklassen mit Hilfe des Datenbankzugriffs erzeugt, und anhand Layout-Elemente, die durch die Kommunikation zwischen Logikklassen und WebProvider-Klasse erreicht werden können, formatiert. Die formatierten Inhalte können dann von dem Serverskript, erreicht werden und in die Template-Seite eingefügt werden. Somit wird die Erreichbarkeit von Datenbanktabellen, von Geschäftslogikklassen und von Layout-Elementen bei der Modellierung von dynamischen Web-Seiten mit dem Serverskript realisiert. Abbildung 26: Konzept der Web-Schnittstelle 47 Die Modellierung von dynamischen Web-Seiten mit UML lässt sich in folgenden Punkten zusammenfassen: • • • • Realisierung einer objektorientierten Zugriffsschicht auf die Layout-Elemente (vgl. 4.1.2). Realisierung einer objektorientierten Zugriffsschicht auf die Datenbank (vgl. 4.1.3). Realisierung einer UML Web-basierten Schnittstelle mit Zugriff auf DesignElemente, Geschäftslogikklassen und Datenbank(vgl. 4.1.4). Modellierung und Generierung von dynamischen Web-Seiten mit dem TemplateMechanismus (vgl. 4.1.1). In den folgenden Abschnitten wird durch die Festlegung eines Serverskripts (für die Modellierung von dynamischen Inhalten) und eines Layout-Schemas (für die Darstellung von Clientseiten) das vorher erwähnte Konzept umgesetzt. 4.2 Technische Umsetzung Das UML-Case Tool Fujaba wird in dieser Arbeit für die Erstellung der UML Diagramme genutzt. Klassen-, Aktivitäten- und Storydiagramme lassen sich bereits durch Fujaba unterstützen. Diese Diagrammarten werden unverändert verwendet. Für sie besteht die Möglichkeit, mittels Forward-Engineering Java-Quelltexte zu generieren. Die Konzepte zur Quelltextgenerierung werden für Klassen-, Aktivitäts- und Storydiagramme in [11, Seiten 137-213] beschrieben. Fujaba bietet außerdem die Möglichkeit, nicht nur neue Diagrammarten zu definieren, sondern auch einer Klasse mit zusätzlichen Eigenschaften durch benutzerdefinierte Stereotypen zu versehen. Die Modellierung der Web-Applikation verwendet die HTML-Sprache für das Layout von Web-Seiten. Mit einem HTML-Diagramm als neues Objekt-Diagramm im Fujaba wird die Möglichkeit gegeben, Templates darzustellen. Für die Modellierung dynamischer WebSeiten werden Java-Servlets als Serverskript eingesetzt. Um Servlets-Klassen zu definieren, wird in Fujaba eine UML-Erweiterung mit Hilfe Stereotypen durchgeführt. Die Modellierung der Geschäftslogik erfolgt durch die in Fujaba definierten Diagramme. Eine objektorientierte Zugriffsschicht auf die Datenbank wird bereits zur Verfügung gestellt (vgl. 4.1.3). 4.2.1 UML-Modell für HTML-Elemente Ziel in diesem Abschnitt ist der Aufbau eines UML-Modells, das eine objektorientierte Zugriffsschicht auf HTML-Elemente ermöglichen soll. Im Rahmen dieser Arbeit ist die 48 HTML 4 eingesetzt worden. Mit Hilfe des Import/Exportmechanismus aus dem Abschnitt 4.1.2 bieten sich für die Realisierung des Modells zwei verschiedene Möglichkeiten an: 1. Überführung der HTML-DTD in ein XML-Schema: Die HTML-DTD kennzeichnet alle HTML-Elemente und Attribute, die in einem HTML-Dokument enthalten sind, sowie die Beziehungen, die zwischen diesen Komponenten bestehen. Sie spezifizieren also einen Satz von Regeln für die Struktur eines HTML-Dokuments. Aus der HTML-DTD kann ein XML-Schema erzeugt werden, das aus einem XMLSchema-DTD validiert wird. Folgende Gleichung beschreibt den Transformationsablauf: HTML-DTD + XML-Schema-DTD = XML-Schema. Das erhaltene XML-Schema kann letztendlich mit dem Mechanismus aus dem Abschnitt 4.1.2 in ein Klassendiagramm in Fujaba importiert werden. 2. Aufbau des Modells in Fujaba: die zweite Möglichkeit besteht darin, mit Hilfe der Beschreibung aus dem HTML-DTD das Klassendiagramm in Fujaba aufzubauen. Das entstehende Diagramm lässt sich wiederum mit Hilfe des Mechanismus aus dem Abschnitt 4.1.2 in ein XML-Schema exportieren, das bei Bedarf für die Modellierung anderer Anwendungen importiert (vgl. 4.1.2, Import/Exportmechanismus) werden kann. Das entstehende UML-Klassendiagramm stellt die globale Struktur von HTML-Elementen dar. HTML-Elemente bzw. -Tags, zugehörige Attribute und ihre Beziehung zueinander werden in einem Klassendiagramm, wie in [11, Seiten 13-20] beschrieben, dargestellt. Abbildung 27 stellt einen Ausschnitt aus dem UML-Modell für HTML-Elemente dar. Eine HTML-Tabelle (TableTag) ist ein HTML-Element (HTMLElement) und kann mehrere Zeilen (TrTag) beinhalten. Jede Zeile kann mehrere Spalten (TdTag) enthalten. TrTag und TdTag erben von der HTMLElement-Klasse und drücken somit ihre Zugehörigkeit zu HTML-Elementen aus. Attribute von HTML-Elementen werden entsprechend als UMLAttribute dargestellt. Durch die Attributswerte kann die Formatierung der HTML-Tabelle definiert werden. Das vollständige Klassendiagramm für HTML-Elemente wird im Anhang A1 dargestellt. 4.2.1.1 Aufbau von ASG’s Das UML-Modell für HTML-Elemente wird sowohl zum Einlesen des Templates als auch zu seiner Modellierung angewendet. Dieses Template wird durch einen Parser in eine Baumstruktur bzw. ASG (Abstract Syntax Graph) als Instanz des UML Models transportiert. Dabei werden alle enthaltenen Elemente des Templates und ihre Zuordnung in einer Datenstruktur gespeichert. 49 Abbildung 27: UML-Klassendiagramm - Struktur der HTML-Tabelle Für die Realisierung des ASG wurde eine JavaCC-Grammatik [13] verwendet. Sie benutzt kein DTD und speichert jedes HTML-Dokument in einer geordneten Liste als Baum. Das Hauptziel bei der Transformation ist die Validierung, die Formatierung, das Anzeigen oder die Analyse des erstellten Baumes für eigene Zwecke. Der Parser, der bei dieser Grammatik definiert und für die Transformation zuständig ist, wird mit einer VisitorDesign-Pattern-Struktur aufgebaut [9]. Dadurch bietet er eine geeignete Möglichkeit durch die Erstellung eigener Visitor-Klassen, den erstellten Baum zu manipulieren. Instanzen des UML-Modells für HTML-Elemente werden auf diese Art mit passenden Visitor-Klassen verwirklicht. Die Baumstruktur aus dem JavaCC-Parser wird somit analysiert und neu übersetzt, um den gewünschten Abstract Syntax Graph zu generieren. Die Ablaufgenerierung des ASG ist in Abbildung 28 dargestellt. Jedes Template wird durch den JavaCC-HTML-Parser in eine einfache Baumstruktur übersetzt. Der erstellte Baum wird von einem weiteren HTML-Parser eingelesen und mit Hilfe des UML-Modells neu validiert. Daraus wird ein ASG als Instanz des UML-Modells generiert. Der generierte ASG wird bei der Modellierung von dynamischen Web-Seiten mit Hilfe des UML-Modells erweitert. Dafür ist ein Mechanismus notwendig, der es erlaubt, neue erzeugte HTMLElemente an den richtigen Stellen in den Baum einzufügen. Der Mechanismus wird im Abschnitt. 4.2.3 erläutert. Nicht nur die Überführung von Templates in einer Baumstruktur für ihre Modellierung soll ermöglicht werden, sondern die Möglichkeit muss bestehen, aus den modellierten ASG den HTML-Code generieren zu können. Um diese Codegenerierung Zustande zubringen, werden HTML-Elemente um die Methoden addTochildren und generateHtmlCode (vgl. Abbildung 29) erweitert. 50 Abbildung 28: Einlesen des Templates und Aufbau des ASG Bei dem Aufbau des ASGs durch den HTML-Parser werden alle Elemente der Templates besucht. Der ASG wird in einer am Anfang leeren Liste gespeichert. Für jedes besuchte Element des Templates wird das entsprechende Objekt des UML-Modells kreiert, mit Attributswerten, falls vorhanden, initialisiert und in den ASG hinzugefügt. Jedes Objekt des ASGs wird nach der richtigen Zuordnung im Baum als das aktuelle Objekt gesetzt. Das erste besuchte Element (<HTML>) wird als Wurzel des ASGs platziert. Jedes neu erzeugte Objekt wird an die addToChildren-Methode des zuletzt in den Baum eingefügten Objekts für die richtige Zuordnung im ASG übergeben. Alle Objekte im Baum kennen ihren Vaterknoten und jeder Vaterknoten kann mehrere Kinderknoten beinhalten. Abbildung 29 präsentiert die Methoden der HTML-Tabelle. Für die Attribute der Tabellen werden Zugriffsmethoden generiert, die bei der Modellierung einer Seite für die Formatierung der Tabelle initialisiert werden können. Die addToChildren- und generateHtmlCode-Methoden bezeichnen Erweiterungen, die im UML-Modell für HTMLElemente durchgeführt wurden, um die Zuordnung innerhalb des ASGs und die Codegenerierung nach der Modellierung einer Template-Seite zu ermöglichen. Abbildung 29: Methoden einer HTML-Tabelle 51 In den folgenden Abbildung 30 wird die Struktur von HTML-Elementen nach einem Kompositum-Muster [9] skizziert. Diese Struktur entspricht den in der HTML-DTD definierten Regeln. Alle HTML-Elemente lassen sich als Inline-Elemente oder BlockElemente zuordnen. HTMLElement, InlineElement und BlockElement sind abstrakte Klassen, die die HTML-Elemente (Tabellen, Inputfelder, HTML-Formulare, etc.) durch eine Vererbungshierarchie strukturieren. Abbildung 30: Struktur von HTML-Elementen nach dem Kompositum-Muster Abbildung 31 stellt die Struktur einer HTML-Tabelle dar. Es ist die typische ASG-Struktur einer erstellten HTML-Tabelle. Die Nummerierung legt fest, in welche Reihenfolge die Tabelle aufgebaut wird. Diese Struktur wird von der generateHtmlCode-Methode benutzt, um den HTML-Code aus dem ASG wieder zu generieren. Abbildung 31: typische Struktur des ASGs einer HTML-Tabelle (vgl. Abbildung 27) 52 Abbildung 32 stellt den Quelltext der addToChildren-Methode von der HTML-TabelleKlasse dar. Sie sorgt bei der Erzeugung von Tabellen für die richtige Zuordnung der Zeilen-Elementen (TrTag). Die Methode bekommt das in den Baum einzufügende Element durch einen Parameter. Ist das neue Element ein TrTag-Element, wird es in die Liste der Tabellenzeilen angefügt, es sei denn, es gibt seinem Vater das Element weiter. Auf diese Art werden alle HTML-Elemente des Templates in eine Baumstruktur angelegt (vgl. Abbildung 31). 1 public void addToChildren (HTMLElement child) 2 { 3 if (child instanceof TrTag) 4 { 5 this.addToTrTag ((TrTag) child); 6 } 7 8 //delegate to the parent 9 else 10 { 11 if (this.getBodyTag () != null) 12 { 13 this.getBodyTag ().addToChildren (child); 14 } 15 else if (this.getDivTag () != null) 16 { 17 this.getDivTag ().addToChildren (child); 18 } 19 else if (this.getTdTag () != null) 20 { 21 this.getTdTag ().addToChildren (child); 22 } 23 else if (this.getLiTag () != null) 24 { 25 this.getLiTag ().addToChildren (child); 26 } 27 else if (this.getFormTag () != null) 28 { 29 this.getFormTag ().addToChildren (child); 30 } 31 else 32 { 33 System.out.println ("Fehler bei addToChildren in the 34 TableTag Class: " + this.getName () + " has no 35 parent!"); 36 } 37 } 38 } Abbildung 32: addToChildren - Methode für HTML-Tabelle Abbildung 33 stellt den Quelltext der generateHtmlCode-Methode von der HTMLTabelle-Klasse dar. Die Methode generiert den entsprechenden Stückcode des erzeugten Element „TableTag“ (HTML-Tabelle) und ruft die gleiche Methode auf allen Kinderknoten (vgl. Abbildung 33, Zeile 46-50). Somit wird der gesamte HTML-Code einer erzeugten HTML-Tabelle generiert. Bei der Codegenerierung wird die Methode auf dem Wurzelknoten des ASGs aufgerufen. Dabei generiert sie für jedes Element des ASGs den entsprechenden Stückcode und rekursiv die von seinen Kinderknoten. 53 1 public String generateHtmlCode () 2 { 3 StringBuffer s = new StringBuffer (); 4 s.append ("\n<"); 5 s.append (this.getTagName ()); 6 7 if (getAlign () != null && !getAlign().equals ("")) 8 { 9 s.append (" "); 10 s.append ("align=" + getAlign ()); 11 } 12 if (getWidth () != null && !getWidth().equals ("")) 13 { 14 s.append (" "); 15 s.append ("width=" + getWidth ()); 16 } 17 if (getBorder () != null && !getBorder().equals ("")) 18 { 19 s.append (" "); 20 s.append ("border=" + getBorder()); 21 } 22 if (getBgColor () != null && !getBgColor().equals ("")) 23 { 24 s.append (" "); 25 s.append ("bgColor=" + getBgColor ()); 26 } 27 if (getCellPadding () != null && 28 !getCellPadding ().equals ("")) 29 { 30 s.append (" "); 31 s.append ("cellPadding=" + getCellPadding ()); 32 } 33 if (getCellSpacing () != null && 34 !getCellSpacing ().equals ("")) 35 { 36 s.append (" "); 37 s.append ("cellSpacing=" + getCellSpacing ()); 38 } 39 if (getId () != null && !getId().equals ("")) 40 { 41 s.append (" "); 42 s.append ("id=" + getId ()); 43 } 44 s.append (">"); 45 46 Iterator iter = this.iteratorOfTrTag (); 47 while (iter.hasNext ()) 48 { 49 s.append (((TrTag) iter.next ()).generateHtmlCode()); 50 } 51 s.append ("\n</" + this.getTagName() + ">"); 52 53 return s.toString (); 54 } Abbildung 33: generateHtmlCode – Methode für HTML-Tabelle 4.2.1.2 Das HTML-Diagramm Fujaba wird im Rahmen dieser Arbeit um ein HTML-Diagramm erweitert. Das HTMLDiagramm bezeichnet ein UML-Objektdiagramm, welches Instanzen von HTML- 54 Elementen darstellen kann. Die durch den ASG erstellte Baumstruktur wird damit repräsentiert. Das Diagramm soll dem Entwickler eine Zugriffsicht auf die Elemente des ASG ermöglichen. Diese Zugriffssicht hilft dem Entwickler der Applikation bei der Auswahl von leeren HTML-Elementen, die aus dem ASG geholt und mit dynamischen Inhalten aktualisiert werden müssen. Das HTML-Diagramm ist ein Hilfsmittel für den Entwickler. Die zu verarbeitenden Objekte sind meistens durch Attributswerte, die innerhalb des ASGs eindeutig identifizierbar sein müssen, festgelegt. Objekte des ASGs werden im HTML-Diagram als Rechtecke dargestellt, die den Namen des HTML-Elementes kleingeschrieben beinhalten. Bei gleichnamigen Objekten werden sie durchnumeriert. Ein weiteres Feld im Rechteck beinhaltet Namen und Werte ihrer Attribute. Dieser Repräsentation entsprechen die in Fujaba definierten UML-Objekte [11, Seiten 24-25]. Abbildung 34 stellt in der ersten Spalte eine HTML-Template-Seite und in der zweite Spalte die entsprechende Baumstruktur. Die Inputfelder mit den Namen „mdslogin“ und „mdspassword“ des Templates entsprechen den Objekten input1 und input2 in dem ASG. Soll beispielsweise bei der Modellierung des Templates das Inputfeld mit NAME = „mdslogin“ mit dem Wert VALUE=“login“ initialisiert werden, muss der Entwickler auf das richtige Objekt input1 zugreifen können. Das Objektdiagramm ermöglicht es in diesem Zusammenhang dem Entwickler eine Zugriffssicht auf das zu modellierende Template, um dann durch geeignete Zugriffsmethoden von der Web-Schnittstelle (s. Abschnitt 4.2.3) die entsprechenden Objekte ansprechen zu können. Template ASG <HTML> <HEAD> <TITLE> Diagnose system </TITLE> </HEAD> <BODY> <DIV> <FORM METHOD="POST" ACTION="MDSServlet?call=anmeldeservlet"> <INPUT TYPE="hidden" NAME="mdslogin"> <INPUT TYPE="hidden" NAME="mdspassword"> </FORM> </DIV> </BODY> </HTML> Abbildung 34: Darstellung des ASGs eines Templates 55 4.2.2 Java-Servlets in Fujaba Die Realisierung der dynamischen Seiten geschieht durch die Serverskripte. In dieser Arbeit werden Java-Servlets für ihre Modellierung angewendet. Es muss daher die Möglichkeit gegeben werden, Servlets-Klassen in Fujaba zu definieren und damit die Interaktionen der Web-Applikation modellieren zu können. Das UML-Case Tool Fujaba bietet die Möglichkeit zusätzliche Eigenschaften einer Klasse, mit benutzerdefinierten Stereotypen zu versehen. Der in Fujaba definierte Editor zur Erzeugung einer Klasse wird durch den Stereotyp <<servlet>> um die Fähigkeit erweitert, Servlet-Klassen zu erzeugen. Diese Erweiterung ermöglicht es nicht nur bei der JavaCode-Generierung das Importieren von richtigen Servlets-Containern, sondern erzeugt auch automatisch Servlet-Klasse-Methoden durch geeignete Fujaba-Aktionen. Abbildung 35 zeigt die Erzeugung einer UML-Klasse mit dem Fujaba-Class-Editor. Unter den Inputfeld „ClassName“ muss der Klassenname (AnmeldeServlet) angegeben werden. Durch die Auswahl der User-Stereotyp „servlet“ wird festgelegt, dass die zu definierende AnmeldeServlet-Klasse eine Servlet-Klasse ist. Abbildung 35: Dialog zur Erzeugung einer UML Klasse in Fujaba In der folgenden Abbildung wird die in die Abbildung 35 definierte AnmeldeServletKlasse präsentiert. Bei der Ausführung der Aktionen für die Erzeugung von ServletKlasse-Methoden, wird die ausgewählte Methode in der definierten Servlet-Klasse mit den richtigen Parametern angelegt. In Abbildung 36 ist die doGet-Methode der AnmeldeServlet-Klasse zu erkennen. Durch die ausgeführte Aktion wird automatisch ein 56 Aktivitätsdiagramm für die definierte Methode angelegt. Dieses Diagramm muss mit Story-Pattern erweitern werden, um dadurch die vollständige Implementierung der Methode (vgl. Abbildung 37) zu erreichen. Abbildung 36: Erzeugung der Servlet doPost Methode in Fujaba Das angelegte Aktivitätsdiagramm der doGet-Methode von der Servlet-Klasse AnmeldeServlet wird in der folgenden Abbildung präsentiert. Die Modellierung der Methode soll Clientanfragen realisieren, die an die AnmeldeServlet-Klasse gerichtet werden. Dadurch werden die Client/Server-Interaktionen der Web-Applikation modelliert. Abbildung 37: Implementierung der doGet-Methoden der AnmeldeServlet – Klasse 57 4.2.3 Realisierung der Web-Schnittstelle in Fujaba Die Web-Schnittstelle soll die Kommunikation zwischen HTML-Elementen, Geschäftslogikklassen und Datenbank mit Hilfe der definierten objektorientierten Zugriffsschichten zustande bringen. Durch diese Kommunikation wird die Struktur der Web-Applikation, deren Implementierung im Aktivitätsdiagramm erfolgen muss, modelliert. Die Modellierung der Geschäftslogik ist von der zu realisierenden Applikation abhängig. Bei kleineren Applikationen bzw. bei der Pflege von Datenbanken kann die Geschäftslogik auch durch die Servlet-Klassen modelliert werden. Die Web-Schnittstelle wird durch die UML-Klasse (WebProvider) zum Einsatz gebracht. Wie im Abschnitt 4.1.4 beschrieben, stellt Abbildung 38 die Kommunikation zwischen der Web-Provider-Klasse und der HTMLElement-Klasse dar. HTML-Elemente, die aus dem Einparsen von Templates entstehen, werden durch die Verbindung zu der WebProviderKlasse für ihre Modellierung bekannt gegeben. Servlet-Klassen werden dann durch eine Verbindung zu der WebProvider-Klasse auf HTML-Elemente zugreifen können, sei es für die Modellierung des eingelesenen Templates oder für die Generierung der erstellten Clientseite. Abbildung 38: Kommunikation zwischen der Web-Schnittstelle und HTML-Elementen Die Modellierung der Template-Seite läuft allgemein über einige Objekte des ASG. Es ist nicht notwendig, für den Zugriff auf diese Objekte den vollständigen Baum mit der WebProvider-Klasse zu verbinden. Ein Mechanismus ist jedoch nötig, der aus dem ASG die zu modellierenden HTML-Elemente zur Verfügung stellt. Durch ihn werden nur die zu bearbeitenden Objekte des ASGs an die Schnittstelle bekannt gegeben. Erst nach der vollständigen Abarbeitung aller Objekte werden die übrigen für die Code-Generierung mit der WebProvider-Klasse verbunden. Unnötige Kanten zwischen HTMLElement- und 58 WebProvider-Klassen werden dadurch erspart. Dadurch wird eine optimale Suche der zu bearbeitenden Objekte bei der Modellierung des ASGs gewährleistet. Der Aufbau des ASGs wird durch die unparse(File template)-Methode in einer Liste in der WebProvider-Klasse (htmlTree – vgl. Abbildung 38) gespeichert. Die zu verarbeitenden Objekte werden mit Hilfe der in der Schnittstelle definierten parse- und checkHTMLElement(id:String)-Methoden mit der WebProvider-Klasse verbunden. Die parse()-Methode verbindet die WebProvider-Klasse mit allen Form-Controll-Objekten wie Inputfelder, mehrzellige Textfelder und Selektionslisten aus dem ASG. Mit der checkHTMLElement(id:String)-Methode wird im ASG nach dem Objekt mit dem Attributsnamen „id“ und dem Attributswert „id“ gesucht und mit der WebProviderKlasse in Verbindung gebracht. Die WebProvider-Klasse bietet außerdem weitere Methoden an, die andere Objekte wie HTML-Tabellen aus dem ASG zur Verfügung stellen. Somit werden vor der Modellierung der dynamischen Seite die zu verarbeitenden Objekte bekannt gegeben. Nach der Bearbeitung aller leeren HTML-Elemente des ASGs werden die übrigen Objekte durch die process()-Methode mit der WebProvider-Klasse verbunden. Die Bekanntmachung des vollständigen Baumes bei der WebProvider-Klasse ist notwendig, um den HTML-Code der modellierten Seite generieren zu können. Es stellt sich heraus, dass die Kommunikation zwischen WebProvider- und HTMLElement-Klasse nicht die einzige Maßnahme zu der Modellierung der dynamischen Inhalte ist. Die Interaktion zwischen der Schnittstelle und den Geschäftslogikklassen trägt auch dazu bei (vgl. Abbildung 26). Abbildung 39 stellt als Beispiel die Struktur einer Web-Applikation dar. Durch die Klassen ServletA und ServletB werden Abläufe der Applikation modelliert. Die LogikKlasseA und LogikKlasseB beschreiben die Geschäftslogik der Applikation und die DBKlasse, DBKlasseA und DBKlasseB die UML-Zugriffsschicht eines eingelesenen DB-Schemas. Abbildung 39: Beispielstruktur einer Web-Applikation In Folgenden wird anhand von Beispielen gezeigt, wie die Modellierung und die Generierung von dynamischen Web-Seiten realisiert werden. Abbildung 40 stellt das Anmeldeformular des medizinischen Diagnosesystems dar. Zur Anmeldung im System müssen die Inputfelder „Login“ und „Password“ ausgefüllt werden. Durch den „ANMELDEN“-Button wird die Anfrage an eine Servlet-Klasse für ihre Bearbeitung 59 weitergeleitet. Die Servlet-Klasse überprüft die Anmeldedaten und generiert eine Fehlerseite, falls die Daten falsch angegeben wurden; sonst generiert sie eine Antwortseite mit einer Liste der zugehörigen Praxispatienten falls vorhanden. Für die Überprüfung der Anmeldedaten und die Generierung der Praxispatienten werden Datenbanktabellen aus der generierten DB-Zugriffsschicht angesprochen. Abbildung 40: Anmeldeformular des medizinischen Diagnosesystems Die Struktur der Applikation, die das Formular aus Abbildung 40 modelliert, wird in der Abbildung 41 präsentiert. Die DiagnoseSystem-Klasse ist eine Oberklasse von ServletKlassen, die von der WebProvider-Klasse erbt und dadurch die Erreichbarkeit von HTMLElementen realisiert. Durch die Verbindung zu den Patienten- und Doktoren-Klassen werden alle dargestellten Datenbanktabellen (Praxis, Personen, Patienten, Doctoren) erreicht. Durch die definierten Methoden der DiagnoseSystem- und Anmelde-Klasse wird die Geschäftslogik realisiert. Die Anmeldeanfragen werden durch seine Unter-Klasse Anmelde verwirklicht. So wird durch den „ANMELDE“-Button aus der Abbildung 40 die Anfrage an die Anmelde-Klasse weitergeleitet. Die Servlet-Klasse Anmelde ist für alle Anmeldeanfragen im Diagnosesystem zuständig. 60 Abbildung 41: Klassendiagramm – Ausschnitt aus dem Diagnosesystem Eine Arztanfrage zur Anmeldung im Diagnosesystem wird von der in Abbildung 42 dargestellten DoGet-Methode modelliert. Nach der Ausführung der builServerPageMethode wird die Antwortseite in die nächste Aktivität, die mittels einer Transition erreicht wird, zurückgeneriert. In dieser Aktivität kennt die Servlet-Klasse den Baum der modellierten Seite. Für ihre Generierung wird auf die Wurzel des Baumes die generateHtmlCode-Methode angewandt. Abbildung 42: Modellierung der doGet Methode 61 Die Abbildung 43 präsentiert die Modellierung der buildServerPage-Methode, die die Anmeldedaten überprüft und die zu generierende Antwortseite modelliert. Es wird zuerst durch die CheckAnmeldung-Methode alle aus der Doctoren-Klasse eingetragenen Ärzte geholt und mit den Anmeldedaten (login und password, vgl. Abbildung 40) verglichen. Im Erfolgsfall wird das Template „patientauswaehlen.html“ als Schablone der Antwortseite eingelesen und durch die patientSelection-Methode modelliert. Vorher werden alle zu bearbeitenden Objekte des ASGs durch die parse()-Methode bekannt gegeben. Abbildung 43: Modellierung der buildServerPage Methode Die patientSelection-Methode (vgl. Abbildung 44) greift durch die Patienten-DBKlasse alle eingetragenen Patienten aus der Datenbank. Für jeden Patienten wird ein HTMLElement „OptionTag“ erzeugt, das mit dem Patientenname und Patientennummer initialisiert wird. Der erzeugte Listeneintrag wird in dem HTML-Listenelement „select“, das aus dem eingelesenen „patientauswählen.html“-Template geholt wird, hinzugefügt. Auf diese Art werden alle Praxispatienten aus der Datenbank in die Schablone der Antwortseite eingetragen. Jede Anfrage wird also durch die buildServerPage-Methode (vgl. Abbildung 42) der entsprechenden Servlet-Klasse bearbeitet. Dabei werden nach der Bearbeitung alle leeren HTML-Elemente, die übrigen Objekte des Baumes durch die process-Methode mit der Anmelde-Klasse verbunden. Die Codegenerierung der Antwortseite wird schließlich durch den modellierten ASG ausgeführt und ausgegeben. Dafür wird die generateHtmlCodeMethode auf dem Wurzelknoten des ASGs ausgeführt. Die Methode generiert den entsprechenden Stückcode auf das Element und ruft die gleiche Methode auf alle Kinderknoten auf. Das gleiche Verfahren findet bei allen Elementen des ASG statt und generiert rekursiv (d.h. von dem Wurzelknoten bis zu den Blättern des Baumes) den entsprechenden HTML-Code als Antwortseite. 62 Abbildung 44: Modellierung der patientSelection Methode Abbildung 45 stellt die generierte Antwortseite aus der Anmeldeanfrage von Abbildung 40 dar. Abbildung 45: Antwortseite auf die Anmeldeanfrage aus Abbildung 40 63 Zusammenfassend wird bei der Modellierung einer Web-Applikation ein HTML-Schema in Form eines XML- oder GXL-Formats in Fujaba importiert. Das Importieren des Schemas stellt HTML-Elemente und ihre Beziehung miteinander, wie in die HTML-DTD beschrieben, in einem UML-Klassendiagrammn dar. Im nächsten Schritt muss das einzusetzende Datenbank-Schema eingelesen und in ein weiteres UML-Klassendiagramm abgebildet werden. Dann wird die Kommunikation zwischen HTML-Elementen und der Web-Schnittstelle, die durch die WebProvider-Klasse realisiert wurde, mittels einer UMLAssoziation erzeugt. Die Schnittstelle stellt außerdem eine Reihe von Methoden, die auf der Instanzebene das Zugreifen auf in die Schnittstelle hinzugefügte HTML-Elemente ermöglicht, zur Verfügung. Mit den definierten objektorientierten Zugriffsschichten und mit Hilfe von Servlet-Klassen kann dann das Design der Web-Applikation erstellt werden. Schließlich modelliert man die Interaktionen der Applikation bzw. die dynamischen WebSeiten in die Aktivitätsdiagramme nach dem Template-Mechanismusablauf (vgl. 4.1.1). Das realisierte HTML-Schema lässt sich für die Entwicklung weiterer Applikationen wieder verwenden. Bei verteilten Datenbanken können auch für die Realisierung der Applikation mehrere Datenbank-Schemas eingelesen werden. Die Web-Schnittstelle kann außerdem für eigene Bedürfnisse erweitert werden. 4.2.4 Codegenerierung Die Codegenerierung findet in dieser Arbeit auf zwei verschiedenen Ebenen statt. Für die modellierte Web-Applikation werden Java-Quelltexte generiert, kompiliert und dann für den Betrieb auf einem Web-Server vorbereitet. Andererseits lassen sich die dynamischen Web-Seiten, die mit der Erweiterung von den Template-Seiten bei der Modellierung der Web-Applikation realisiert worden sind, automatisch generieren. Die automatische Generierung von HTML-Seiten wurde durch die Erweiterung des UML-Modells für HTML-Elemente realisiert. HTML-Elemente wurden zu diesem Zweck um die generateHtmlCode-Methode erweitert, die nicht nur den entsprechenden Code des Elements ausgibt, sondern auch den der möglichen enthaltenden Elemente. Abbildung 46 verdeutlicht diese Codegenerierung. Aus dem Template (links im Bild), das von einem Editor erstellt wird, wird der entsprechende ASG (in der Mitte des Bildes) erstellt. Die Aktion „Edit Html Code“ führt die generateHtmlCode-Methode auf dem Wurzelknoten „html“ des ASGs aus und generiert daraus den HTML-Code (rechts im Bild) zurück. Die Methode läuft über alle Knoten des ASGs von dem Wurzelknoten bis zu den Blättern. So wird der HTML-Code aus dem eingelesenen und modellierten Template zurück generiert. 64 Abbildung 46: Aufbau und Codegenerierung eines ASGs Für die Generierung von Java-Quelltexten stellt Fujaba dafür eine Reihe von Aktionen zur Verfügung. Durch die Ausführung der Aktionen aus der Import/Export-Menüleiste (vgl. Abbildung 47) können entsprechende Code generiert werden. Die „Export All Classess To Java“-Aktion generiert beispielsweise alle Quelltexte von dem aktuellen Fuaja-Projekt. Das Konzept der Codegenerierung wird in [11, Seite 137-165 und S. 167-213] beschrieben. Abbildung 47: Codegenerierung in Fujaba 65 Abbildung 48 präsentiert als Beispiel den Java-Quelltext einer angelegten Servlet-Klasse. Für alle Servlet-Klassen in Fujaba werden bei der Codegenerierung die Servlet-Container (javax.servlet und javax.servlet.http) importiert. In Abbildung 48 ist auch der Rumpf der noch nicht implementierten doGet-Methode in den Code generiert. Abbildung 48: Quelltext einer Servlet-Klasse Bei der Codegenerierung können die generierten Java-Quelltexte in einer Verzeichnisbaumstruktur (Package name) gespeichert werden. Der Verzeichnisbaum ist bei der Erzeugung einer UML Klasse in Fujaba festzulegen (vgl. Class Editor Abbildung 35). Die generierten Java-Quelltexte werden dann kompiliert und anschließend für Ihre Ausführung an den Web-Server als neue Applikation in ein Basisverzeichnis angelegt. Bei dem Tomcat Web-Server müssen die Servlet-Klassen in einem „WEB-INF“Verzeichnis liegen. Das Verzeichnis beinhaltet ein XML-Dokument (web.xml), welches die neue angelegte Applikation beschreibt. Eine ausführliche Beschreibung für das Anlegen und die Konfigurationen von Web-Applikationen im Tomcat-Web-Server kann in [36] nachgelesen werden. Die Web-Applikation ist dann betriebsbereit nach der vollständigen Konfiguration und kann in jedem Web-Browser abgerufen werden. 66 5. Prototyp In den folgenden Abschnitten wird die Verwendung der in dieser Arbeit realisierten WebSchnittstelle für die Modellierung von Web Applikationen anhand eines Beispieles vorgestellt. Das Beispiel ist ein einfaches Expertensystem zur Unterstützung der Diagnosefindung in einer Arztpraxis (vgl. 1.3). Im Abschnitt 5.1 wird aus der textuellen Beschreibung des zu realisierenden Expertensystems eine Wissensbank in Form einer Datenbank erstellt. In diesem Zusammenhang wird durch das Einlesen des Datenbankschemas und die Überführung in ein Klassendiagramm eine UML-Zugriffsschicht erstellt. Dadurch werden automatisch die Zugriffsmethoden im UML Aktivitätsdiagramm generiert. Im darauf folgenden Abschnitt 5.2 wird eine Template-Bibliothek der zu realisierenden Applikation festgelegt. Das Einlesen und die Modellierung der Template wird durch das UML-Modell, das eine UML-Zugriffsschicht auf HTML-Elemente verschafft, erreicht. Schließlich wird im Abschnitt 5.3 mit Hilfe der Servlets-Klassen, der objektorientierten Zugriffsschichten auf die HTML-Elemente und die Datenbank, die Struktur des Diagnosesystems modelliert, dessen Implementierung die Template-Bibliothek benutzt. Um das Beispiel einfach zu halten, wird die Geschäftslogik mit den Servlets-Klassen modelliert. 5.1 Erstellung der Wissensbank Aus der Beschreibung des Diagnosesystems ist eine Sybase-Datenbank erstellt worden. Für die Modellierung des Prototyps wird in Fujaba das DB-Schema eingelesen und in einem SQL-Diagramm dargestellt. Aus dem erstellten Diagramm wird durch einen Generator das gewünschte UML-Klassendiagramm abgebildet. Dabei werden Zugriffsmethoden für die Manipulation von Daten im Aktivitätsdiagramm generiert. Abbildung 49 stellt einen Ausschnitt des erstellten SQL-Diagramms dar. Das Diagramm besteht aus einer Praxis- und Personen-Tabelle. Personen werden wiederum Doctoren-Tabelle oder Patienten-Tabelle zugeordnet. Patientenbehandlungen, die von einem Praxisdoktor durchgeführt werden müssen, werden unter der BehandlungenTabelle gespeichert. Dabei müssen die Patientennummer (PATNr) und die behandelte Doktorennummer (ANGNr) gespeichert werden. Jeder Behandlung werden eine Diagnose-Tabelle und ein Rezept-Tabelle zugewiesen, die durch die Tabellen BD und BR eindeutig identifizierbar sind. 67 Abbildung 49: Ausschnitt aus dem SQL-Diagramm des DB-Schemas 5.2 Template Bibliothek Aus der Beschreibung des Diagnosesystems (vgl. Abschnitt 1.3) wird eine TemplateBibliothek erstellt. Die Templates werden als Schablone bei der Modellierung der dynamischen Web-Seiten benutzt. Die Anzahl der zu erstellenden Templates werden abhängig von den zu realisierenden Anfragen festgelegt. Zu jeder Anfrage ist eine feste Anzahl von Templates zugeordnet. Aus der Anmeldeanfrage des Diagnosesystems werden beispielsweise für ihre Modellierung zwei Templates zugeordnet: ein Fehler-Template für eine fehlgeschlagene Anmeldung und ein Erfolg-Template als Schablone der Antwortseite bei einer erfolgreichen Anmeldung. Für die Realisierung des Diagnosesystems sind die Templates aus Abbildung 49 eingesetzt worden. Template Name Beschreibung Diagnosesystem.html Index-Seite, Anmeldeformular für das Diagnosesystem Patientauswaehlen.html Vorlage für eine erfolgreiche Anmeldung Anmeldungsfehler.html Vorlage für eine fehlgeschlagene Anmeldung Newpatient.html Formular für das Erzeugen eines neuen Praxispatienten Newpatientfehler.html Patient.html Vorlage für einen fehlgeschlagenen Patientenantrag in der Datenbank Vorlage bei der Patientenauswahl für eine neue Behandlung Diagnose.html Vorlage für die Erstellung der Diagnose Rezept.html Vorlage für die Erstellung des Rezepts Abmeldung.html Vorlage für die Abmeldung vom Diagnosesystem Abbildung 50: Template-Bibliothek des Diagnosesystems 68 5.3 Architektur des Diagnosesystems Das Design des Diagnosesystems wird ebenfalls aus der Beschreibung des Diagnosesystems (vgl. Abschnitt 1.3) erstellt. Da die Geschäftslogik mit Servlet-Klassen realisiert wird, geht es um die Festlegung der Struktur des zu realisierenden Diagnosesystems. Die traditionelle objektorientierte Vorgehensweise zur Erstellung von Klassendiagrammen kann dafür eingesetzt werden. Als Ergebnis werden folgende Klassen und Methoden festgelegt. Abbildung 51 schafft eine Übersicht über die Servlet-Klassen und Methoden, die dabei die Geschäftslogik modellieren. Servlet-Klassen Anmelde checkAnmeldung (HttpServletRequest) patientSelection () Patient checkAllData () checkPatient (String) checkPatientFormData (HttpServletRequest) createNewPatient (HttpServletRequest) getLastDiagnosis (Patienten) Diagnosis checkBK (String) checkSK (String) fillKrankheiten () Rezept checkKM (String) fillMedikamente () createNewBehandlung (HttpServletRequest) createNewRezept (HttpServletRequest) DiagnoseSystem buildServerPage (HttpServletRequest, HttpServletResponse) checkMaxID (String) MDSServlet init (String) Aufgabebeschreibungen Zuständig für die Anmeldung im System. Überprüft die Anmeldedaten und modelliert die Template patientauswaehlen.html und anmeldungsfehler.html Holt die letzten Behandlungsdaten des zu behandelten Patienten oder erzeugt neue Patientendaten falls noch nicht im System. Dabei wird ein neues Behandlungsformular erzeugt. Modelliert die Template patient.html, newpatient.html und newpatientfehler.html Erstellt eine neue Diagnose. Modelliert das Template diagnose.html Erstellt ein neues Rezept und schließt eine neue Behandlung ab. Modelliert die Template rezept.html und abmelden.html realisiert die gemeinsamen Eigenschaften aller Servlet-Klassen in einer Vererbungshierarchie. Die Hauptservlet-Klasse des Diagnosesystems. Delegiert mit Hilfe der init-Methode Clientanfrage an die richtige Servlet-Klasse weiter. Abbildung 51: Beschreibung der Servlet-Klassen des Diagnosesystems Abbildung 52 stellt die Struktur des Diagnosesystems dar. Die gemeinsamen Eigenschaften der Servlet-Klassen Anmelde, Diagnosis, Patient und Rezept werden in einer Vererbungshierarchie durch die DiagnoseSystem-Klasse realisiert. Die DiagnoseSystem–Klasse erbt von der WebProvider–Klasse und realisiert dadurch die Erreichbarkeit der HTML-Elemente von den Servlet-Klassen. Das Design der Servlet- 69 Klassen ist mittels des „STRATEGY“-Design-Patterns [9, Siete.315] realisiert. Alle Anfragen aus dem Diagnosesystem werden von der Servlet-Klasse MDSServlet verwaltet. Durch eine Parameterübergabe identifiziert die MDSServlet-Klasse die für die Bearbeitung der Anfrage zuständige Servlet-Klasse und leitet die Anfrage an sie weiter. Clientanfragen werden von der doGet-Methode der MSDServlet-Klasse modelliert und dann an die gleiche Methode der entsprechenden DiagnoseSystem-Klasse weitergeleitet, die durch die buildServerPage-Methode die Geschäftslogik aktualisiert und eine Antwortseite zurückgeneriert. Abbildung 52: Design des Diagnosesystem - Servlet-Klassen und HTML-Elemente Um das Design des Diagnosesystems zu vervollständigen, müssen die möglichen Zugriffe auf die Datenbanktabelle modelliert werden. Diese Zugriffe ermöglichen den Datenaustausch zwischen Servlet-Klassen und Datenbank. Aus technischen Gründen sind für die Modellierung diese Zugriffe nur reference Klassen für die Datenbanktabelle eingesetzt worden. Das liegt daran, dass das Projekt ReddMoM [28], das die Datenbankzugriffsschicht ermöglicht, im Zeitpunkt der Realisierung dieser Arbeit noch nicht vollständig im Fujaba integriert war. Somit wurden als Ersatzlösung Java-Code aus der Datenbankzugriffsschicht in ReddMom generiert, kompiliert und für die Ausführung der Applikation zur Verfügung gestellt. Für die Modellierung des Prototyps wurden dann reference Klassen für die Datenbankzugriffsschicht erzeugt. 70 In der folgenden Abbildung wird die Modellierung der Zugriffe auf die Datenbanktabellen präsentiert. Damit ist die Struktur des Diagnosesystems vollständig modelliert. Das Verhalten des Systems wird dann in das Aktivitätsdiagramm implementiert. Abbildung 53: Design der Kommunikation zwischen Servlet- und Datenbankklassen Die realisierte Struktur modelliert das Diagnosesystem zur Diagnosefindung in einer Praxis. Zur Anmeldung im System wird nach einem Login und Passwort verlangt. Abbildung 40 präsentiert in einem Browser das Anmeldeformular, dessen HTML-Code in der Abbildung 54 präsentiert wird. Mit dem „ANMELDEN“-Button (vgl. Abbildung 54 Zeile 15) wird die Anfrage an die doGet-Methode der MDSServlet-Klasse weitergeleitet. Abbildung 54 stellt die Index-Seite des Diagnosesystems dar. Wie alle Template-Seiten der Applikation beinhaltet sie ein Formular-Element, welches durch den Wert des Attributs „ACTION“ (Zeile 15), die anzusprechende Servlet-Klasse für die Bearbeitung der Anfrage angegeben wird. 71 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 <HTML> <HEAD> <TITLE> Diagnosesystem </TITLE> </HEAD> <BODY bgcolor="#FFFFFF" text="#000000" link="#123456"> <DIV align="center"> <TABLE border="0"> <TR><TD><IMG src="images/tomcat.gif"></TD> <TD><H1>Medizinisches Diagnosesystem</H1> <P>Es ist eine Beispielanwendung für die Realisierung von Web Applikationen auf Basis der UML und dient zur Unterstützung der Diagnosefindung in einer Praxis. </P> </TD> <TR> </TABLE> <BR> <FORM METHOD="POST" ACTION="mds/MDSServlet?call=anmeldeservlet"> zur Anmeldung, geben Sie Ihre Login und Password an! <BR><BR> Login :< INPUT TYPE="text" NAME="mdslogin" size=10> Password :< INPUT TYPE="password" NAME="mdspassword" size="10"> <BR><BR> <INPUT TYPE="SUBMIT" VALUE="ANMELDEN"> </FORM> </DIV> </BODY> </HTML> Abbildung 54: Indexseite des Diagnosesystems – diagnosesystem.html Alle Abläufe des Diagnosesystems werden nach dem folgenden Schema modelliert und ausgeführt. Die doGet-Methode der MDSServlet-Klasse leitet alle Arztanfragen an die doGet-Methode der anzusprechenden Servlet-Klasse weiter. Jede dieser Servlet-Klassen modelliert durch die buildServerPage-Methode die Anfrage. Dabei wird die Geschäftslogik aktualisiert, die Antwortseite modelliert und schließlich zurückgeneriert (vgl. Abbildung 42). Für das Formular aus der Abbildung 54 identifiziert die MDSServlet-Klasse durch den von der Formular übergebenen „call“-Parameter (vgl. Abbildung 54, Zeile 15: call=anmeldeservlet) die anzusprechende Servlet-Klasse und leitet die Anfrage an sie weiter. Abbildung 55: doGet Methode von der Klasse MDSServlet 72 Die Identifikation der richtigen Klasse erfolgt über die Ausführung der init-Methode (vgl. Abbildung 56). Die Methode erzeugt anhand des übergebenen Parameters eine Instanz der anzusprechenden Servlet-Klasse. Für das Formular aus der Abbildung 54 wird nach dem Aufruf der init („anmeldeservlet“)-Methode eine Instanz der ServletKlasse Anmelde erzeugt, die mit der MSDServlet-Klasse verbunden wird. Die Bearbeitung der Anfrage wird in diesem Fall an die erzeugte Anmelde-Klasse übergeben. Die Modellierung der Anfrage, die die Anmeldedaten überprüft und die Antwortseite modellieren, wurde im Abschnitt 4.2.3 vorgeführt. Abbildung 56: init Methode der Klasse MDSServlet Für eine neue Behandlung muss der Patient aus einer Liste ausgewählt werden (vgl. Abbildung 45). Durch den „ABSENDEN“-Button bekommt der Arzt als Antwort auf die Anfrage ein neues Behandlungsformular. Die Seite präsentiert in der ersten Reihe die Daten des ausgewählten Patienten. In der zweiten Reihe werden die letzten Behandlungsdaten, falls vorhanden, dargestellt. Die letzte Reihe stellt eine Auswahlmöglichkeit für Symptome und Untersuchungen vor, die aus der Datenbank stammen. Für die Behandlung müssen Symptome ausgewählt werden oder Untersuchungen durchgeführt werden. Die Symptome und Befunde, die aus den ausgewählten Untersuchungen festgestellt werden können, weisen in kausalen Zusammenhängen auf Krankheiten hin, die in der Wissensbank der realisierten Datenbank des Diagnosesystems gespeichert sind. 73 Ist der zu behandelnde Patient noch nicht in der Praxis angemeldet, kann durch den „NEWPatient“-Button (vgl. Abbildung 45) ein Formular abgerufen werden, das vor der neuen Behandlung die Patientendaten in die Datenbank abspeichert. Abbildung 57 präsentiert das Behandlungsformular, das bei der Auswahl des Patienten für eine neue Behandlung generiert wird. Für die Behandlung des gewählten Patienten mit dem Namen „Wadsack“ wird der Arzt nach der Auswahl von Symptomen und Befunden aus den durchgeführten Untersuchungen, eine neue Anfrage mit dem „Diagnose“-Button an die Diagnose-Servlet-Klasse senden. Abbildung 57: Patientenformular zur Erstellung einer neuen Behandlung Die Bearbeitung der Anfrage aus der Abbildung 57 wird in der folgenden Abbildung präsentiert und wird durch die BuildServerPage-Methode der Diagnosis-Klasse modelliert. Die Methode liest zuerst das „diagnose.html“-Template (vgl. Abbildung 59), das die Schablone der zu modellierenden Antwortseite enthält. Mit der Ausführung der parseMethode werden die zu bearbeitenden HTML-Elemente (vgl. Abbildung 59, Zeilen 9, 17, 26, 32 und 36) mit dem Diagnosis-Klasse verbunden. Die chekSK- und checkBK-Methoden holen aus der Wissensbank die von den Symptomen und Befunden abhängigen Krankheiten. Für diese Krankheiten werden Tabelleneinträge erzeugt, die in den entsprechenden Tabellen des ASG eingefügt werden. Nach der Generierung dieser Zusammenhänge werden durch die fillKranheiten-Methode alle in der Datenbank eingetragenen Krankheiten geholt und für die Diagnose in das SelektionslistObjekt des entsprechenden ASG-Elements hinzugefügt. 74 Abbildung 58: buildServerPage-Methode der Patient-Servlet-Klasse 8 <!-- Diagnose-checkSK --> 9 <TABLE border=0 align="left" id="sk"> 10 <TR> 11 <TD width="40%"><B>Symptom</B></TD><TD width="20%"><B>Pro/Contra</B></TD><TD width="40%"><B>Krankheit</B></TD> 12 </TR> 13 </TABLE> 14 <!-- Ende Diagnose checkSK--> 15 … 16 <!-- Diagnose-checkBK --> 17 <TABLE border=0 id="bk"> 18 <TR> 19 <TD width="40%"><B>Befund</B></TD><TD width="20%"><B>Pro/Contra</B></TD><TD width="40%"><B>Krankheit</B></TD> 20 </TR> 21 </TABLE> 22 <!-- Ende Diagnose checkBK--> 23 … 24 <!-- wahrscheinlische-Krankheiten-berechnen --> 25 <TABLE> 26 <TR><TD vAlign="top"><H4>wahrscheinliche Krankheiten:</H4></TD><TD><OL id="wk"></OL></TD></TR> 27 </TR> 28 … 29 <!-- Diagnose-checkKrankheiten-Tabelle --> 30 <TABLE border=0 width="50%"> 31 <TR><TD><B>Krankheit</B></TD> 32 <TD><SELECT NAME="krankheit" size="1"><option>none</option></SELECT></TD> 33 </TR> 34 <TR vAlign="top"> 35 <TD><B>Kommentar:</B></TD> 36 <TD><TEXTAREA NAME="kommentar" ROWS="10" COLS="50"></TEXTAREA></TD> 37 </TR> 38 </TABLE> 39 … Abbildung 59: Ausschnitt des Templates – diagnose.html 75 Abbildung 59 präsentiert einen Ausschnitt des Templates für die Erzeugung von Diagnosen. Die zu verarbeitenden HTML-Elemente sind meistens durch ein ID-Attribut gekennzeichnet (vgl. Abbildung 59, Zeilen 9 [<TABLE border=0 align="left" id="sk">] und 17 [<TABLE border=0 id="bk">]) oder bei den Form-Control-Elementen durch den Namen des Elements eindeutig identifizierbar (vgl. Abbildung 59, Zeilen 32 <SELECT NAME="krankheit" size="1"> - und 36 - <TEXTAREA NAME="kommentar" ROWS="10" COLS="50">). Abbildung 60 stellt die Modellierung der fillKranheiten-Methode dar. Dabei werden die Krankheitseinträge in die Selektionsliste der Antwortseite generiert. Es wird zuerst das anzusprechende Liste-Element (SelectTag mit dem selectName=“krankheit“) geholt. Es wird dann durch die DB-Tabelle Krankheiten alle in der Datenbank gespeicherten Krankheiten identifiziert. Für jede Krankheit wird durch das HTML-Element OptionTag und TextTag einen Listeeintrag erzeugt. Der erzeugte Eintrag (OptionTag) wird indem Liste-Element (SelectTag) eingefügt. Es werden schließlich die neu erzeugten Elemente (OptionTag und TextTag) mit der Diagonis-Klasse in Verbindung gebracht. Abbildung 60: fillKrankheiten-Methode der Diagnosis-Klasse Abbildung 61 präsentiert das Diagnosisformular des Patienten „Wadsack“ in einem WebBrowser. Die generierte Clientseite ist eine Erweiterung des in der Abbildung 59 dargestellten Templates. 76 Abbildung 61: Diagnoseformular eines Patienten 77 6. Zusammenfassung und Ausblick In dieser Diplomarbeit wurde die Entwicklung von Web-Applikation betrachtet. Mit HTML als Layout-Elemente und Java-Servlets als Server-Skript wurde das Projekt Fujaba, um die Fähigkeit erweitert, dynamische Web-Seiten zu modellieren und daraus Codes zu generieren. Mit dem Stereotypkonzept wurde die Erzeugung von Servlet-Klassen in Fujaba definiert. Danach wurden den Servlet-Klassen mit Hilfe objektorientierter Zugriffsschichten in Form von Fujaba Klassendiagramm ermöglicht, mit HTML-LayoutElementen und Datenbanktabellen durch eine erstellte Schnittstelle zu kommunizieren. Für die Modellierung von dynamischen Web-Seiten wurden Templates als Schablone der Antwortseiten eingelesen und durch die HttpServlet-Methoden von den ServletKlassen realisiert. Diese UML-Modellierung erlaubte die Aktualisierung der Geschäftslogik der Web-Applikation und die Erweiterung der eingelesenen Templates mit dynamischen Inhalten, die durch die Geschäftslogik und den Datenbankzugriff erzeugt und mit HTML-Layout-Elemente formatiert wurden. Der in dieser Arbeit erarbeitete Lösungsansatz ermöglicht durch eine objektorientierte Kommunikation zwischen Layout-Elementen und Datenbanken via einer Schnittstelle die Modellierung des Informationsaustausches bei Client/Server-Interaktionen und schließt somit die Lücke der manuellen Implementierung bei der Entwicklung von WebApplikationen. Es ist ein UML-Erweiterungsansatz für die Modellierung von dynamischen Web-Seiten und soll einen Beitrag für die Vollständigkeit von Entwicklungsprozessen für die objektorientierte Modellierung von Web-Applikationen und Datenbank-Anwendungen leisten. Das Beheben von Fehlern, die Anpassung, die Verbesserung oder die Erweiterung der Applikation an neue Anforderungen werden durch diesen Ansatz leichter. Die realisierten Zugriffsschichten und Schnittstellen können weiter angesetzt und erweitert werden, um neue Web-Applikationen zu modellieren. Dadurch werden eine bessere Wartbarkeit und Widerverwendbarkeit für die modellierte Applikation erreicht. Für die weitere Zukunft könnte das HTML-Objektdiagramm um mehr Funktionalität erweitert werden. Das in dieser Arbeit realisierte Objektdiagramm ermöglicht eine Zugriffssicht auf HTML Templates. Änderung und Erweiterung des Templates auf der Objektebene, Generierung und Speicherung der geänderten Templates wären von Vorteil für die Modellierung der Web-Applikation. So wären beispielsweise neue DesignKonzepte im HTML-Diagramm direkt aktualisierbar und nicht mehr unbedingt über das File System und das neue Einlesen und Überführung des Templates im HTML- oder StoryDiagramm nötig. So ergäbe es für die Designer von Web-Applikationen eine objektorientierte Zugriffsschicht für die Manipulation von HTML-Templates. Ihrer Realisierung entspräche beispielsweise die Integration des Ansatzes von Conallen in dieser Arbeit. 78 Sollen die Web-Inhalte als XML-Dokumente dem Client zur Verfügung gestellt werden, eignet sich auch das in dieser Arbeit realisierte Konzept für ihre Erstellung bzw. Erweiterung. Der Ansatz käme z.B. für die Pflege von Datenbanken in Frage oder man würde sich damit auch in der Richtung Web-Services bewegen, wo XML als geeignetes plattformunabhängiges Format für den Transport von Daten eingesetzt wird. 79 Literaturverzeichnis [1] Shelley Powers, Developing ASP Component, 2. Edition, O’Reilly, 2001. [2] AutoScout24, Online at http://www.autoscout24.de. [3] Caucho, Online at http://www.caucho.com/. [4] J. Conallen, Modeling Web Applictions with UML. Whitepaper, March 1999. Online at http://www.conallen.com/whitepapers. [5] J. Conallen, Building Web Applications with UML. The AddisonWesley Object Technology Series, 1999. [6] S. Guelich, S. Gundavaram and G. Birznieks, CGI Programmierung mit Perl, 2. Auflage,O’Reillly Verlag, 2001. [7] L. Wall, T. Christiansen and L. Schwartz, Programmieren mit Perl, 1. Auflage, O’Reilly Verlag, 1997. [8] Apache Cocoon, Online at http://xml.apache.org/cocoon/. [9] E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design Patterns, 22nd Printing, Addison-Wesley, 2001. [10] Fujaba – From Uml to Java And Back Again, Online at http://www.upb.de/cs/agschaefer/Lehre/PG/FUJABA/fujaba.html. [11] T. Fischer, J. Niere, and L. Torunski, Konzeption und Realisierung einer integrierter Entwicklungsumgebung für UML, Java und Story-Driven-Modeling. Master’s thesis, University of Paderborn, Department of Mathematics and Computer Science, Paderborn, Germany, July 1998. [12] Sun Microsystems Inc., Java Server Pages Technology. 95-01. Online at http://java.sun.com/products/jsp/. [13] JavaCC HTML Parser, Online at http://www.quiotix.com/downloads/html-parser/. 80 [14] HTTP (Hyper Transfer Text Protokol) Online at http://java.sun.com/j2ee/1.4/docs/tutorial/doc/HTTP. html. [15] HTML (HyperText Markup Language) Online at http://www.w3.org/TR/REC-html40/. [16] Stefan Münz and Wolfgang Nefzger, HTML 4.0 Handbuch, 3. Auflage, 1999. [17] Stefan Münz: SELFHTML, Online at http://selfhtml.teamone.de/. [18] HTML.Template.java, Online at http://html-tmpljava.sourceforge.net/. [19] Marty Hall, Servlets and JSP:An Overview. 1999. Online at http://www.apl.jhu.edu/~hall/java/ServletTutorial/Servlet-Tutorial-Overview.html. [20] Jrun, Online at http://www.macromedia.com/. [21] H. Baumeister, N. Koch and L. Mandel, Towards a UML extension for hypermedia design, In UML’99 - The Unified Modeling Language – Beyong the Standard, USA, October 1999, Springer Verlag. [22] R. Hennicker and N. Koch, A UML-based methodology for hypermedia design, UML’2000 - The Unified Modeling Language – Advancing the Standard, volume 1939 of Lecture Notes in Computer Science, York, England, October 2000, Springer Verlag Online at http://www.pst.informatik.uni-muenchen.de/~hennicke. [23] N. Koch, H. Baumeister, R. Hennicker and L. Mandel: Extending UML to Model Navigation and Presentation in Web Applications, In Geri Winters and Jason Winters, In Modelling Web Applications in the UML Workshop, UML’2000, York, England, October 2000. [24] T. Schattkowsky, M. Lohmann and R. Heckel: Leightweight Modeling of Dynamic Websites using UML, In Proc. ICSE 2002 Workshop on Web Engineering, Orlando, FL, Mai 2002. [25] J Krause, PHP4, Webserver-Programmierung unter Windows 81 and Linux, Hanser, München, 2000. [26] PHP (Hypertext Preprocessor), Online at http://www.php.net/. [27] Rational. Rose, the Rational Rose case tool. Online at http://www.rational.com. [28] ReddMom – Reengineering of distributed (federated) databases for multimedia oriented middleware, Online at http://www.upb.de/cs/agschaefer/Lehre/PG/REDDMOM. [29] Dustin R. Callaway, Inside Servlets, Server-Side Programming for the Java Platform, 2. Auflage, AddisonWesley, 2001. [30] P. Roßbach and H. Schreiber, Java Server und Servlet, portierbare Web-Applikationen effizient entwickeln, 1. Auflage, München, Addison-Wesley, 2000. [31] Java Servlets, Online at http://java.sun.com/products/servlet/index.html. [32] SVG, Online at http://www.xml-web.de/svg.html http://www.w3.org/Graphics/SVG/Overview.htm. [33] SGML (Standard Generalized Markup Language), Online at http://www.w3.org/TR/WD-html40970708/intro/sgmltut.html. [34] GXL, Graph Exange Language, Online at http://www.gupro.de/GXL/. [35] Object International. TogetherJ, the TogetherJ case tool. Online at http://www.togethersoft.com. [36] Tomcat, Online at http://jakarta.apache.org/tomcat/index.html. [37] Marty Hall, Tutorial on Servlets and JSP, Java Server Pages 1.0. 1999. Online at http://www.apl.jhu.edu/~hall/java/ServletTutorial/Servlet-Tutorial-JSP.html. [38] Rational Software Corporation. UML documentation version 1.3 (1999). Online at http://www.rational.com. 82 [39] UML - Unified Modeling Language, Online at http://www.omg.org/technology/documents/formal/uml.h tm. [40] Felix Wolf: Entwicklung eines Generators für eine objektorientierte Zugriffsschicht auf einer relationalen Datenbank. Master's thesis, University of Paderborn, Department of Mathematics and Computer Science, Paderborn, Germany, 2001. [41] W3C, W3-Konsortium, Online at http://www.w3c.org. [42] XMI, XML Metadata Interchange, Online at http://www.omg.org/technology/documents/formal/xmi.h tm. [43] XML, Extensible Markup Language, Online at http://www.w3.org/XML/. [44] XML Schema, Online at http://www.w3.org/XML/Schema. [45] Albert Zündorf, Rigorous Object Oriented Software Development; Habilitation Thesis, University of Paderborn, 2001. [46] Albert Zündorf, PROgrammierte GRAphErsetzungsSystem. Deutscher Universitäts Verlag ISBN 3-8244-2075-9. [47] XHTML, Extensible HyperText Markup Language, Online at http://www.w3.org/MarkUp/. [48] DTD, Dokument Type Definition, Online at http://www.w3.org/XML/1998/06/xmlspec-report19980910.htm. [49] XSLT, Extensible Stylesheet Language, Online at http://www.w3.org/Style/XSL/. [50] Apache Web-Server, Online at http://www.apache.de/. [51] T. Schattkowsky, M. Lohmann and R. Heckel: Rapid Development of Modular Dynamic Web Sites using UML, In Pra. 5th International Confrence on the Unified Modeling Language UML 2002, Dresden, Germany, September/October 2002, pp 336-350. 83 Anhang A1 HTML-Modell: Klassendiagramm Abbildung 62: Klassendiagramm - HTML Elemente 84 A2 Diagnosesystem: SQL-Diagramm Abbildung 63: SQLDiagramm aus der eingelesenen Datenbank des Diagnosesystems 85 A3 Diagnosesystem: Klassendiagramm Abbildung 64: Architektur des Diagnosesystems