Technologische und qualitative Betrachtung von Internetprogrammen und angewandte Programmierung

Inhaltsverzeichnis

1. Einleitung
1.1. Motivation
1.2. Problemstellung und Ziel

2. Internetprogramme
2.1. Definition
2.2. Entwicklung
2.2.1. Dokumentenzentrierte
2.2.2. Interaktive
2.2.3. Transaktionale
2.2.4. Workflow-basierte
2.2.5. Kollaborative
2.2.6. Portalorientierte
2.2.7. Ubiquitäre
2.2.8. Semantisches Internet
2.3. Qualität
2.3.1. Qualitätssicherung
2.3.2. Qualitätsmerkmale
2.3.2.1. Ordnungsmäßigkeit und Richtigkeit . .
2.3.2.2. Sicherheit
2.3.2.3. Interoperabilität und Austauschbarkeit
2.3.2.4. Fehlertoleranz
2.3.2.5. Verständlichkeit
2.3.2.6. Bedienbarkeit

3. Derzeitige Entwicklungen
3.1. AJAX
3.1.1. Potential
3.1.2. Gefahren und Schwierigkeiten
3.1.3. Fehlerbehebung
3.1.4. Schlussfolgerungen und Ausblick
3.2. Semantisches Internet
3.2.1. Vision
3.2.2. Technologien
3.2.2.1. Ressource Description Framework (RDF)
3.2.2.2. Ontology Web Language (OWL)
3.2.2.3. RSS
3.2.3. Anwendungen, Schlussfolgerungen und Ausblick

4. Angewandte Programmierung auf Basis von Zope
4.1. Zope
4.1.1. Architektur
4.1.2. Content Management Framework (CMF)
4.1.3. Zope Page Templates (ZPT)
4.1.4. Erweitern von Zope
4.2. Das Projekt
4.2.1. Entwurf
4.2.2. Bestandteile
4.3. Umsetzung
4.3.1. Grundlegende Konzepte
4.3.1.1. Funktion
4.3.1.2. Präsentation
4.3.1.3. Interaktion
4.3.2. Qualitätsmerkmale
4.3.2.1. Ordnungsmäßigkeit und Richtigkeit . .
4.3.2.2. Sicherheit
4.3.2.3. Interoperabilität und Austauschbarkeit
4.3.2.4. Fehlertoleranz
4.3.2.5. Verständlichkeit
4.3.2.6. Bedienbarkeit
4.3.3. Fehlerbehebung und Qualitätssicherung

5. Schlussfolgerungen und Ausblick

Quellenverzeichnis

Abbildungsverzeichnis

A. Umfangreichere Quellcode Beispiele

B. CD-Inhalte

Ehrenwörtliche Erklärung

Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbständig angefertigt habe, die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Es wurden keine anderen als die angegebenen Quellen und Hinweise verwandt. Die vorliegende Arbeit wurde bisher noch keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht.

Wismar, den 29. Januar 2006

Danksagung und Vorwort

Danksagung

Für ihre finanzielle, moralische und kulinarische Unterstützung während meines Studiums möchte ich mich bei meiner Mutter, meinem Vater und meiner Schwester bedanken. Helga, Pauli und Ilse danke ich für Dach, Speis und Trank - es war mir eine FRE UDE. Heiner möchte ich u.a. für Mobilität und Wissenschaft danken.

Ein besonderes Dankeschön an all die Leidensgenossen, Seelenverwandten, (Flur-) Nachbarn, Musikliebhaber, Sandplatzfussballer etc. in Wismar für die bisherige schöne Zeit und außerdem an Meikel Steiding für viele fruchtbare Diskussionen, Billard und safeplaces. Ein Dankeschön auch an Malte Dreyer und Marcel Bluhm für eine ganz wich- tige Zeit. Danke an Johannes Großmann für das Staffen für das überraschende Geschenk. ”Anfixen“undHostingundanFrau Und natürlich danke ich allen anderen für alles andere.

Vorwort

An dieser Stelle soll kurz auf Konventionen, die in dieser Arbeit genutzt werden ein- gegangen werden. Wichtige Begriffe werden hervorgehoben. Wenn diese zusätzlich am Wichtige Begriffe rechten Rand vermerkt sind, werden diese im weiteren Verlauf wieder verwendet. Durch die prominente Platzierung soll ein Suchen erleichtert und ein Glossar ersetzt werden. Textstücke, die sich auf Elemente innerhalb von Abbildungen und Quelltexten beziehen werden mit gleicher Zeichenbreite dargestellt.

1. Einleitung

1.1. Motivation

Das Internet hat sich in den letzten Jahren in wirtschaftlichen und privaten Teilen der Gesellschaft etabliert. Knapp zwei Drittel der deutschen Bevölkerung haben sich im ersten Quartal 2004 mit dem Internet verbunden (vgl. DESTATIS, 2005, Seite 6). Euro- paweit (EU-25) sind es knapp 50% der Bevölkerung, die in den vergangenen 12 Monaten das Internet genutzt haben. Davon gehen nahezu 54% täglich oder fast täglich ins Inter- net, und mehr als 82% stellen mindestens einmal pro Woche eine Verbindung her (vgl. Demunter, 2005, Seite 1).

Speziell in der Wirtschaft ist das Internet von einer großen Bedeutung. Unterneh- men wie zum Beispiel der Online-Händler für Informations- und Unterhaltungsprodukte ”Amazon.de“nutzenalsVertriebskanalausschließlichdasInternetundsinderfolgreich. 2004 setzten 84 % der Unternehmen Computer im Geschäftsablauf ein und 78 % nutzten davon das Internet.59% verfügten sogar über eine eigene Internetseite (vgl. DESTATIS,2005, Seite5).

Unternehmen verlagern zunehmend Geschäftsbereiche ins Internet, um Kosten sparen zu können. Der ”KarstadtQuelle“KonzernverkündetetvorkurzeminseinenInvestoren- nachrichten, dass der Verkauf über den Katalogversand zusehends stagniert und mit dem Versand über den firmeneigenen Internetshop ein Wachstum von 30 % zu verzeichnen ist. In Zukunft soll verstärkt in diesen Bereich investiert werden (heise, 2005 b,a). Dieser Internetshop ist ein prominentes Beispiel eines Internetprogramms. Solche In-ternetprogramme lassen uns das Internet in der Form nutzen wie wir es heutzutage gewohnt sind. Sie befähigen uns Emails zu verschicken, lassen uns an Diskussionen teil-nehmen, ”online“einkaufenodersuchenunsInformationen.EssindWerkzeuge,dieuns die Möglichkeit geben mit dem Medium Internet zu kommunizieren.

Internetprogramme haben sich nicht nur in der Wirtschaft und den Haushalten durch- gesetzt, sondern auch in der Wissenschaft. Sie gelten als vollwertige Softwareanwendung- en und es gibt eine Vielzahl von Richtlinien, die bei der Erstellung beachtet werden sollten.

”WebEngineering“isteinerelativneueDisziplindesSoftwareEngineeringsund beschäftigt sich ausschließlich mit Internetprogrammen. Web-Engineering will durch den Einsatz von softwareingenieurmäßigen Methoden bei der Erstellung und Wartung von Internetprogrammen versuchen, eine ”Web-Krise“¹ zuverhindern.

Aufgrund der steigenden Nachfrage und umfangreichen Materie ist eine intensivere Auseinandersetzung mit Internetprogrammen empfehlenswert, um auch in Zukunft der wachsenden Anzahl der Internetnutzer qualitativ hochwertige Werkzeuge zur Verfügung stellen zu können und den Ruf des Internets als innovationsfreudiges Medium zu wahren.

1.2. Problemstellung und Ziel

Diese Arbeit hat bis auf wenige Abschnitte einen einführenden Charakter und soll Ein- steiger befähigen Internetprogramme in ihrer technischen Funktionsweise besser zu ver- stehen. Außerdem soll sie dabei helfen die ”fundamentaleÄnderungderAusrichtungdes Internets von einem Informationsmedium zu einem Anwendungsmedium“ (vgl. Kappel u. a.,2004, Seite2) bewusst mitzuerleben und vielleicht sogar aktiv mitzugestalten.

Dies soll durch kurze Einführungen in die Basistechnologien (Kapitel 1) und einer Bewertung aktueller Entwicklungen (Kapitel 3) geschehen. Darauf aufbauend wird ein realisiertes Internetprogramm erläutert, welches einen Großteil der behandelten Themen praktisch demonstriert (Kapitel 5).

Aber auch Aspekte jenseits der Technologie sollen dem Leser näher gebracht werden. Dazu wird auf die geschichtliche Entwicklung von Internetprogrammen eingegangen und die wirtschaftlichen und gesellschaftlichen Auswirkungen werden beschrieben. Außerdem wird die Qualität, speziell die Qualitätssicherung und Qualitätsmerkmale, anhand von Vorgaben aus nationalen und internationalen Normen untersucht (Kapitel 1). Diese The- men werden ebenfalls, soweit möglich, durch das realisierte Internetprogramm praktisch weiter illustriert (Kapitel 5).

Am Ende der Arbeit werden Schlussfolgerungen bezüglich der Themen aller Kapitel gezogen und ein Ausblick auf die weitere Entwicklung von Internetprogrammen auch bezüglich der Koexistenz mit Desktop-Programmen versucht (Kapitel 6).

Die Arbeit wird zeigen, dass viele Wissenschaften von Internetprogrammen tangiert werden und dass die Aufgaben in einem Beruf, der mit Internetprogrammen zu tun hat, dementsprechend weit gefächert sein können. Trotz des einführenden Charakters dieser Arbeit kann diese nicht nur Einsteigern Basiswissen und/oder neue Anregungen vermitteln. Durch die theoretische und praktische Heranführung an die Thematik soll ein tieferes Verständnis erreicht werden und so zu einem weiterhin qualitativen und inno- vativen Internet beigetragen werden. Außerdem bemüht sich die Arbeit einen möglichst aktuellen Überblick über die derzeitigen Entwicklungen zu geben und bemerkenswerte Teile der dazugehörigen Diskussion zu integrieren. Durch die Wahl der Normen, die für die qualitative Betrachtung gewählt wurden, sind auch Zusammenhänge zwischen Inter- netprogrammen und Desktop-Anwendungen Teil dieser Arbeit. Schließlich soll durch die Einführung in den Applikations-Server Zope, sein ”ContentManagementFramework“ und die Produktentwicklung mit beiden Technologien innerhalb des praktischen Kapitels ein wenig mehr deutschsprachige Dokumentation zu diesen Themen verfügbar sein.

Um diesen Zwecken besser genügen zu können, ist diese Arbeit unter der Internet- adresse http://diplom.phelix.de/ frei erhältlich².

2. Internetprogramme

Dieses Kapitel legt die wissenschaftlichen und technischen Grundlagen. Alle folgenden Kapitel werden auf ihre Weise das erarbeitete Wissen erweitern und sich dazu auf dieses Kapitel berufen. Das Kapitel erhebt den Anspruch, dass es, von wenigen Ausnahmen abgesehen, auch von Einsteigern gelesen werden kann, obwohl es einen recht umfassenden Einblick in die Thematik gibt.

2.1. Definition

Um eine Vorstellung von Internetprogrammen haben zu können, muss man wissen, was das Internet ist. Streng genommen muss man zwischen dem Internet und dem World Wide Web (WWW oder auch ”Web“)unterscheiden.DasWWWistdieextremgroßeWWW Informations- und Datenansammlung, auf die wir mit Hilfe des Internets zugreifen können. Das Internet stellt also die Infrastruktur zur Verfügung und das WWW ist eine darauf aufbauende Dienstleistung, welche das Medium ”Internet“revolutionierte.

Genauer bezeichnet man das WWW als ein Hypermediasystem, welches sich aus einem Hypertextsystem entwickelt hat (vgl. Meinel u. Sack, 2004 , Seite 18 ). In theoretischen Hy- pertextsystemen können beliebig viele verschiedene Dokumente miteinander verknüpft werden. Auf solch ein Medium muss nicht mehr sequentiell, wie beim Blättern eines Buches, zugegriffen werden, sondern der Zugriff kann über Querverweise (Hyperlinks) Hyperlinks nicht-linear, sprunghaft erfolgen.

Abbildung in dieser Leseprobe nicht enthalten

(a) Struktur sequentieller Medien

Abbildung in dieser Leseprobe nicht enthalten

(b) Struktur eines Hyper- textsystems

Bereits 1945 beschrieb Vannevar Bush mit seinem ”Memex-System“einemechani- sche Vorrichtung zur Speicherung von Büchern und persönlichen Aufzeichnungen, welche einen schnellen und zielgerichteten Zugriff erlaubte. Nach dieser gedanklichen Konzeption eines Hypertextsystems wurde das Konzept 1989 durch Tim Berners-Lee konkretisiert und realisiert. Berners-Lee gilt deswegen als Erfinder des WWW und ist der heutige W3C Direktor des World Wide Web Consortiums (W3C). Dies hat bis heute nur einen klei- nen Teil des ursprünglich erdachten Hypertextsystems umgesetzt. Jedoch setzt es durch seine Multimedialität und Vernetzung derselben andere Prioritäten und wird dadurch auch als Hypermediasystem bezeichnet.

In der Einleitung wurden Internetprogramme als Werkzeuge beschrieben, die uns die Möglichkeit geben mit dem Medium Internet zu interagieren. Das Internetprogramm tauscht sich dabei stellvertretend für den Menschen mit dem Medium aus. Der Mensch kommuniziert also mit dem Internetprogramm und dieses mit dem WWW. Das Inter- netprogramm erhält dabei Eingaben über eine für den Menschen definierte Schnittstelle Benutzer- (Benutzerschnittstelle) und stellt diesem als Endergebnis eine Ausgabe basierend auf den schnittstelle verfügbaren Daten aus dem WWW zur Verfügung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.: Kommunikation des Menschen mit dem WWW über Internet- Programme

Wie auf der Abbildung zu sehen ist, benötigen Internetprogramme für den Datenaus- tausch in Richtung Menschen Hilfe. Die vom Internetprogramm benötigte Schnittstelle Browser zur Kommunikation wird meistens von den so genannten Internetbrowsern (kurz: Brow- ” ser“¹ ) zur Verfügung gestellt. Ein Browser ist ebenfalls ein Computerprogramm, welches aber meist auf dem lokalen Computer ausgeführt wird und dem Menschen die Informationen des Internets sichtbar macht bzw. ihn dazu befähigt im Internet zu ”surfen“².

ÜberBrowserkönnen Menschen Internetprogramme direkt über ihre Adresse anspre- URL chen. Diese Internetadresse ist auch als Uniform Resource Locator (URL) bekannt und spezifiziert einen eindeutigen bekanntesten gehören der ”Ort“imWWW.EsgibtverschiedeneBrowser-zuden ”InternetExplorer“undderOpen-SourceBrowser ”Firefox“. Browser sind für viele Endgeräte und Computerplattformen verfügbar.

An dem Beispiel des Browsers wurde deutlich, dass nicht jedes Programm ein In- Desktop- ternetprogramm ist und dass ein Desktop-Programm (auch Desktop-Anwendung³ ) ein Anwendung Internetprogramm gesteuert hat. Allein der Begriff ”Desktop-Programm“lässtvermuten, dass es noch andere Programmarten gibt, die nicht auf dem ”Desktop“ablaufen.

Was aber sind Internetprogramme? Der Begriff war für einige Zeit unbestimmt (vgl. Wurzenberger, 2000 , Seite 15 ) ist nun aber Teil einer Wissenschaftsdisziplin und dennoch schwierig zu kategorisieren (vgl. Kappel u. a., 2004, Seite 108). Die Definition von einem Internetprogramm⁴ im Web Engineering lautet:

”EineWeb-AnwendungisteinSoftwaresystem,dasaufSpezifikationendes World Wide Web Consortiums (W3C) beruht und Web-spezifische Ressour- cen wie Inhalte und Dienste bereitstellt, die über eine Benutzerschnittstelle, den Web-Browser, verwendet werden.“ (Kappel u. a., 2004, Seite 2)

Die einleitenden Bemerkungen sind in der Definition berücksichtigt worden und die Funktion von Internetprogrammen lässt sich erkennen. Interessant ist die Aussage, dass ein Internetprogramm ein Softwaresystem ist, da dies aufgrund der ”vermeintlichenEin- fachheit der Web-Anwendungsentwicklung“ (Kappel u. a., 2004, Seite 3) oft bestritten wurde. Tatsächlich können Internetprogramme unterschiedliche Komplexitätsgrade aufweisen und vollwertige, komplexe Softwaresysteme, welche interaktive, datenintensive und personalisierbare Dienste für verschiedene Endgeräte zur Verfügung stellen, sein (vgl. Kappel u. a., 2004, Seite 2).

2.2. Entwicklung

Die Existenz des Internets hat sich auf die Gesellschaft ausgewirkt aber auch sie hat durch immer neue Forderungen das Internet geformt. Diese wechselseitigen Einflüsse sollen chronologisch und exemplarisch geschildert werden. Dabei werden weitere elemen- tare Begriffe eingeführt und die Basistechnologien, die eine Phase ermöglicht haben, vorgestellt. Diese Vorstellungen sind allgemeiner Natur und keinesfalls vollständig. Wis- senschaftliche Grundlage ist die folgende Kategorisierung von Internetprogrammen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.: Entwicklung von Internetprogrammen (vgl. Kappel u. a., 2004, Seite 5)

Der Zusammenhang zwischen zeitlicher Entwicklung und Komplexität der Anwendung- en wird auf der Abbildung deutlich. Die Kategorien bauen aufeinander auf. Jüngere Anwendungen sind daher komplexer und können Elemente aus darunterliegenden Ka- tegorien enthalten. Aufgrund der möglichen Komplexität von Aufgaben nutzen Inter- netprogramme teilweise mehrere Ansätze. Daher können sie auch mehreren Kategorien zugeordnet sein.

Die Ursprünge des Internets reichen zurück bis in die Zeit des beginnenden ”Kalten Krieg“. Ausfallsichere Verbindungen sollten im Falle eines Atomkrieges eine Kommunikation ermöglichen. Die amerikanische Regierungsbehörde ”AdvancedResearchProjects Agency“ (ARPA) ließ dafür ein Kommunikationsnetzwerk errichten. Dieses ARPANET wurde anfangs für militärische Zwecke genutzt. Später wurde das Netz in einen wis- senschaftlich und einen militärischen genutzten Teil aufgespalten und es war rasch ein rasanter Wachstum im zivilen Teil zu verzeichnen. Das Internet als Medium für Massen- kommunikation entwickelte sich aus dem zivilen Teil nach der Öffnung für die Allgemein- heit und der Bereitstellung einer einfachen Benutzerschnittstelle durch Browser.

2.2.1. Dokumentenzentrierte

In den Anfängen bestand das WWW aus einer Vielzahl von manuell erstellten Doku- menten bzw. Dateien, die verteilt gespeichert und untereinander durch Hyperlinks (kurz: ”Links“)verknüpftwaren.DieDateienlagertenaufverschiedenenComputern,diemit dem Internet verbunden waren und den Inhalt der Dateien übermittelten (Server ), wenn Client-Server ein Browser (Client⁵ ) diese anfragte. Dieses Client-Server Modell ist die Grundlage für die Kommunikation von Internetprogrammen. Um diese Kommunikation zu verstehen ist es notwendig mehr über das Hypertext Transfer Protocol (HTTP) einer der Basistech- nologien des Internets zu wissen.

HTTP HTTP ist ein Standard, der den Austausch von Informationen zwischen Server und Client vereinheitlicht und dadurch ermöglicht⁶. Jeder Austausch oder auch Transaktion besteht aus einer Anfrage und einer Antwort (engl. ”request/reply“).DieArtder Kommunikation ist dabei synchron, das bedeutet, dass Sender und Empfänger zeitgleich kommunizieren. Die Anfrage und Antwort sind vom Aufbau her einheitlich. Sie bestehen aus der eigentlichen Anfrage und Antwort, einem Kopf (engl. (engl. ”body“).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3.: Transaktionsablauf (engl. ”header“)unddemKörper ”requestcycle“)

Eine Anfrage kann auf verschiedene Arten bzw. Methoden geschehen. Die abgebildete Methode GET ist eine der am häufigsten genutzten Methoden und fordert in diesem Fall Methode GET das Dokument test.html aus dem Wurzelverzeichnis des Servers an. Durch die zusätzli- chen Informationen ( ”Host“)imKopfderAnfrage,istdieangeforderteRessourcenicht nur auf dem Server, sondern auch im Internet eindeutig identifizierbar. Beide Informa- tionen zusammen ergeben nämlich die URL des Dokumentes. Für die Transaktion soll HTTP der Version 1.1 genutzt werden. Die dreistellige Nummer der Antwort gibt den Status der Antwort an. Es folgt seine kurze Beschreibung.

In der Abbildung ist ein wichtiger Teil der Kommunikation noch nicht vorgestellt wor- den. Was also steht im Körper der Antwort bzw. was wird übermittelt? Da der Client ein Dokument auf dem Server angefordert hat und die Statusbeschreibung der Übertra- gung OK war, muss im Körper der Inhalt der Datei übermittelt worden sein. Der Inhalt ist Klartext, der nach bestimmten Regeln geschrieben wurde. Die Regeln sind die der Hypertext Markup Language (HTML). Diese kann von Browsern verarbeitet und optisch HTML interpretiert werden. Die visuelle Ausgabe des Browsers ist weitgehend als bekannt. HTML ist eine Auszeichnungssprache (engl. ”Internetseite“ ”markuplanguage“),dieineinem offenen Standard definiert ist. Zur Zeit des dokumentenzentrierten Ansatzes befand sich HTML in der Version 2.0, dieser erlaubte es Anwendern Informationen in einer präsenta- tionsorientierten Weise (Absätze,Überschriften, Bilder) abzubilden und über Links zu verknüpfen. Zur Einführung soll ein kleines HTML-Dokument erläutert werden.

Abbildung in dieser Leseprobe nicht enthalten

Die einzelnen Auszeichnungen (engl. ”tags“)wiezumBeispieldasTag<html>oder Aus- <body> sind in einer hierarchischen Art organisiert. Zu einem Tag gehören zwei Teile, zeichnungen die den Wirkungsbereich der Auszeichnung eingrenzen⁷. Es ist zu erkennen, dass die Verschachtelungen der Tags das HTML-Dokument ausmachen. Die Existenze der beiden innerhalb des body Bereiches wird als Attribut bezeichnet und gibt in diesem Fall diesem Attribut Tag eine eindeutige Identifikation.

Internetprogramme haben sich aus dem dokumentenzentrierten Ansatz entwickelt (vgl. Kappel u. a., 2004, Seite 6). Sie sind also keine Internetprogramme, sondern deren Vorläufer. Charakteristisch für diesen Ansatz sind die, durch die manuellenÄnderungen als statisch bezeichneten, Auszeichnungen der Internetseiten und die Verknüpfungen zwi- schen den Internetseiten. Die Gesamtheit der verknüpften Dokumente, welche durch eine einheitliche Navigation zusammengefasst ist und verknüpft wird, wird als Webpräsenz oder Website bezeichnet. Beispiele für diese Gattung sind manuell erstellte Homepages, Website Linksammlungen und Tagebücher.

2.2.2. Interaktive

Interaktion Die einzige mögliche Interaktion bzw. Möglichkeit des Eingriffs beim dokumentenzentrier- ten Ansatz ist das Besuchen von Internetadressen (beispielsweise durch das Verfolgen von Links). Was zuerst faszinierte, wurde schnell selbstverständlich und die Nutzer des Mediums wollten mehr mit dem WWW interagieren.

Um eine Interaktion gewährleisten zu können ist ein Austausch von individuellen Daten notwendig. Durch einen erweiterten Einsatz von HTML in Form von Formularen und Eingabelementen war es möglich eine Schnittstelle für eine Kommunikation zu realisieren. So wurden zusätzlich zur üblichen Seitenanforderung Daten zum Server übermittelt und entsprechende Ausgaben zurückgeliefert. Diese Vorgehensweise ist elementar für alle komplexeren Internetprogramme und bis heute üblich.

Wie wirkt sich diese Vorgehensweise auf die Kommunikation aus? Anfragen an einen Server über HTTP sind nicht nur auf GET beschränkt. Es kann auch über die Metho- Methode POST de POST⁸ kommuniziert werden. Der Unterschied ist, dass auch ein Körper bei der Anfrage übermittelt wird. In diesem können Wertepaare stehen, die den serverseitigen Programmablauf steuern können. Zwar können solche Daten auch über GET transferiert werden⁹ diese Methodik ist aber nachteilig, da im Körper mehr Daten transportiert wer- den können als in der Adresse. Anfragen mit POST empfehlen sich also wenn eine große Menge an Daten (lange Texte aber auch Dateien) übertragen werden sollen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4.: Beispielhafter Transaktionszyklus mit POST

Um eine erfolgreiche Transaktion zu gewährleisten, sind bei dieser Art von Anfrage weitere Daten im Kopf zu transportieren. Diese Informationen wie zum Beispiel Länge und Art der Daten befähigen den Server den Körper auszulesen und entsprechende Ant- worten zu generieren. Dazu nutzt der Server Programme, die sich dem Common Gateway CGI Interface (CGI) bedienen. Das Protokoll CGI spezifiziert die Kommunikation zwischen dem Server und einem CGI-Programm (vgl. Balzert, 2001, Seite 968).

Wenn zusätzliche Argumente durch die Anfrage zum Server gelangen, werden diese an das CGI Programm, im Sinne von Kommandozeilenargumenten, weitergeleitet.

Abbildung in dieser Leseprobe nicht enthalten

Das obige CGI Programm ist in der Programmiersprache Python geschrieben und gibt alle an das Programm übermittelten Wertepaare aus. Python ist eine objektorientierte Python Programmiersprache. Die Funktionsweise von Python beruht auf der Ausführung eines Programms bzw. seines kompilierten Zwischencodes (Bytecode) durch einen installier- ten Interpreter. Python verfügt über eine große Standardbibliothek, welche besonders auf die Internetprogrammierung zugeschnitten ist. Diese unterstützt eine große Anzahl von Standardformaten und -Protokollen. Große Teile der Bibliothek sind plattformun- abhängig, so dass auch umfangreiche Programme oft auf den geläufigsten Plattformen ohne Änderung laufen.

Bei einer Anfrage würde der Internetserver das Programm in einem neuen Prozess ausführen (vgl. Spainhour u. Eckstein, 1999, Seite 480). Dieser Prozess beendet sich nach Abschluss der Programmanweisungen und muss bei einer erneuten Anfrage eines Clients wieder gestartet werden. Trotz dieser nicht sehr performanten Vorgehensweise können so Daten eines Servers im Internet nutzbar gemacht werden.

Die Funktionalität von interaktiven Internetprogrammen beschränkt sich lediglich auf lesenden Zugriff. Beispiele für diese Gattung sind Suchmaschinen, Fahrplanauskünfte und Produktübersichten.

2.2.3. Transaktionale

Vor dem Hintergrund, dass die Kategorien aufeinander aufbauen, kann man diese Kate- gorie als ”interaktivere“Internetprogrammebezeichnen,dabeidieserKategorieauchein Schreibzugriff realisiert wird. Dies gelingt durch Integration von Datenbanken. Internet- programme nutzen dazu ”Datenbankverwaltungssysteme“(engl. ”databasemanagement systems“, abgek. DBMS), die aus einer Menge von Daten und den zur Datenverarbei- tung notwendigen Programmen wie zum Beispiel einer strukturierten Abfragesprache¹⁰ bestehen (Kemper u. Eickler, 2004). Zugriffe auf Datenbanken erfolgen in Form von Transaktionen, welche durch eine feste Folge von Operationen die Integrität der ent- Transaktionen haltenen Daten sicherstellen. Transaktionen fassen dabei verschiedene Änderungen am Datenbestand zusammen, welche bei auftretenden Fehler vollständig zurückgenommen werden können (engl. ”rollback“).

Das CGI-Programm des vorherigen Abschnittes könnte leicht erweitert werden, um eine Verbindung mit einem Datenbankserver herzustellen. Dazu müsste es sich mit ei- nem Benutzernamen und Passwort beim Datenbankverwaltungssystem autorisieren. Bei einer solchen Nutzung wird keine Unterscheidung zwischen den zugreifenden Nutzer ge- macht. Alle haben bei diesem Programm gleiche Zugriffsrechte. Oft ist es aber sinnvoll Rechte und sicherer nicht allen Nutzern Schreibzugriff zu ermöglichen. Dazu sind Mechanismen zur Identifikation des Nutzers notwendig. HTTP stellt solch eine Möglichkeit aber nicht zur Verfügung, da es ursprünglich als schnellesÜbertragungsprotokoll mit wenig zu ver- waltenden Zusatzinformationen gedacht war. Für das übermittelnde Protokoll ist jede Anfrage für sich allein gestellt, dass heißt das zusammenhängende Anfragen eines Nutzers nicht als solche identifiziert werden. HTTP wird daher auch als ein statusloses Protokoll bezeichnet. Da man aber nicht jedem Nutzer erlauben darf Daten zu ändern, wurden Programme geschrieben, die solche zusammenhängenden Anfragen eines Nutzers (Sit- zungen) erkennen und so zu jeder Anfrage den Anfragenden identifizieren können. Die- Sitzungs- ses Sitzungsmanagement basiert entweder auf clientseitig gespeicherten Informationen Management (Cookies), zusätzlich übertragene versteckte HTML-Formularfeldern oder auf speziell manipulierten Adressen (engl. ”URL-rewriting“)undaufeinerInterpretationaufder Seite des Servers. Alle erreichen auf dem Anfrageweg den Server und führen dort zu zusätzlichen Auswertungen. Daher ist diese Seite in der folgenden Abbildung genauer aufgeführt. Die Kommunikation könnte die gleiche wie auf den vorherigen Abbildungen sein - nur notwendige Unterschiede wurden kenntlich gemacht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5.: HTTP-Transaktionszyklus bei Sitzungen auf Basis von Cookies (vgl. Meinel u. Sack,2004,780)

ÜberCookieswerdenZustandsinformationenmitdemServerausgetauscht,diefür die Identifikation des Anfragenden genutzt werden können. Cookies werden ausgelöst durch das zusätzliches Feld Set-Cookie im Kopfbereich der Serverantwort vom Client angelegt. Der Server kann den Client so veranlassen Informationen, wie zum Beispiel die ausgewählte Sprache oder eine eindeutige Identifikationsnummer zu speichern. Bei einer Antwort des Clients an diesen Server wird das Cookie ebenfalls in einem zusätz- lichen Feld im Kopfbereich (Cookie) übermittelt. Der Internetserver leitet das Cookie an das Internetprogramm weiter, welches eine Zuordnung der Anfragen zu einem Nutzer ermöglichen kann. Ein Problem bei der Verwendung von Cookies ist die Möglichkeit die Nutzung von Cookies in Browsern aus Sicherheitsgründen zu beschränken oder zu deaktivieren. Daher müssen diese Internetprogramme bei fehlender Cookie-Unterstützung das Sitzungsmanagement auf einer der anderen Methoden realisieren.

Durch diese Identifikation des Nutzers entstehen viele neue Möglichkeiten für Internetprogramme. Beispiele für diese Gattung sind Online-Banking, semi-automatische Reservierungssysteme, Datenbank-Eingabemasken und Foren.

2.2.4. Workflow-basierte

Die rudimentäre Unterscheidung zwischen Schreib- und Lesezugriff genügt meist nicht, um Geschäftsprozesse ( ”Workflows“)inderrealenWirtschaftabbildenzukönnen.Es gibt viele unterschiedliche Rollen, die mit entsprechenden Rechten durch die Internetprogramme interagieren sollten. Das lässt sich am besten mit einem praktischen Beispiel veranschaulichen. In einem Verlag gibt es vereinfacht folgende Rollen:

- Autoren, die Inhalte erstellen.
- Redakteure, die diese Inhalte überprüfen und veröffentlichen können.

Ein einfacher Workflow wäre es, wenn der Autor seinen Text an den Redakteur wei- terleitet und dieser diesen veröffentlicht oder ablehnt. Bei einer Ablehnung würde dieser Prozess ein zweites Mal durchlaufen. Um diesen Geschäftsprozess abbilden zu können, ist es also notwendig, dass ein Autor selber nicht dazu priviligiert sein darf einen Text zu veröffentlichen. Eine solche Rechteverwaltung muss durch ein Internetprogramm zur Verfügung gestellt werden.

Um einen Workflow abzubilden reicht es nicht, lediglich den Text zu übermitteln. Es sind weitere Informationen über das übermittelte Dokument notwendig (Meta-Daten). Meta-Daten Um diese mitsamt dem Inhalt speichern zu können, ist ein eigenes Dateiformat von Vorteil. Der offene Standard Extensible Markup Language (XML) wird durch seine hier-XML archische Speicherung von Informationen und praktische Erprobtheit oft verwendet. Der Zugang zu den Daten, die in XML-Dokumenten übermittelt werden, gelingt den verar- beitenden Programmiersprachen meist über das vom W3C spezifizierte Document Object Model (DOM). Dieses stellt eine einheitliche, sprachneutrale Schnittstelle für die Extrak-DOM tion und Modifikation von XML zur Verfügung. XML-Dokumente können auch über XSL Transformationen (XSLT) verarbeitet werden und durch Definition von Regeln in XSLT andere Formate umgewandelt werden.

Durch solch eine standardisierte Kommunikation und Verarbeitungsweise können Pro- zesse zwischen den Akteuren abgebildet werden und effizienter durchgeführt werden. Die Akteure müssen sich nicht unbedingt im gleichen Unternehmen befinden. Ein Aus- tausch eines Unternehmens mit anderen Unternehmen (Business to Business - kurz: B2B ) kann ebenso realisiert werden wie der Austausch von Kunde zum Anbieter eines B2B Internetshops (Business to Consumer - kurz: B2C ). Solche Anwendungen haben elek- tronische Geschäfte (engl. ”e-commerce“)überdasInternetermöglicht.

Hinsichtlich der Entwicklung von Internetprogrammen ist es auch lohnend sich den Prozess der Inhaltserstellung durch den Autor näher anzuschauen. Der Ansatz statische Internetseiten, wie im dokumentenzentrierten Ansatz, zu erstellen, verursachte erhebli- chen redaktionellen Aufwand und damit große Kosten. Ein solches Vorgehen ist heu- te undenkbar, da Aktualisierungen immer häufiger stattfinden und Internetseiten sich teilweise entsprechend dem Verhalten eines Nutzers dynamisch ändern. Da die Redak- teure auch elementare Erfahrung im Umgang mit Internettechnologien haben mussten, hätten diese sich bei dem unglaublich hohen Arbeitspensum noch nicht einmal auf ihre Kernkompetenz konzentrieren können. Außerdem wären durch die manuelle Bearbeitung Redundanzen und Inkonsistenzen entstanden.

Aus diesen Problemen wurde die Idee einer einheitlichen Lösung zur Erstellung von Inhalten geboren. Bald entstanden die ersten Anwendungen, die sich dieser Aufgabe an- CMS nahmen. Diese Content Management Systeme (CMS) werden in Unternehmen oft für die Pflege von Intranet- und Internetauftritten benutzt. Sie ermöglichen es technisch weitgehend ungeschulten Mitarbeitern Inhalte in eine Internetpräsenz einzufügen und die Konsistenz zu erhalten. Es existieren zahlreiche CMS auf dem Markt (Typo3, Vignette, CoreMedia, ZECMS etc.), welche sich durch unterschiedliche Funktionalitäten, Programmiersprachen, Lizenzen und Kosten auszeichnen. Die Funktionalität eines CMS geht teilweise durch integrierte Skriptsprachen so weit, dass diese eine erlauben ”rekursiveÄnderung“ (Internetprogramme ändern Internetprogramme).

Viel von der mühsamen Arbeit der Redakteure wird auf den Server übertragen, was sich in Form von rechenintensiven Prozesse auf der Seite des Servers bemerkbar macht. Diese Rechenarbeit war kaum noch mit dem vorgestellten Prinzip der CGI Programmier- ung zu bewältigen, denn dass bei jeder Anfrage ein CGI-Programm im eigenen Prozess im Betriebssystem arbeitet, hat einige Nachteile. Wenn beispielsweise mit einem CGI Pro- gramm auf eine Datenbank zugegriffen wurde und der Prozess nach Abarbeitung beendet wird, muss bei der nächsten Anfrage eine neue Datenbankverbindung hergestellt werden. Bei vielen Anfragen ist daher eine erheblichere Verschlechterung der Performanz festzu- stellen. Ein effizienterer Ablauf wurde zuerst durch Module, die zusätzlich in den Inter- netserver einkompiliert wurden und dann durch Skriptsprachen, deren Interpreter auch nach dem Aufruf im Speicher blieb und so einen schnellen Zugriff ermöglichte, erreicht. Mit der Zeit wurden noch leistungsfähigere Konzepte entwickelt, um Internetprogram- Applikations- me zu erstellen. Mit den Applikationsservern konnte man die gemeinsame Nutzung von server Ressourcen wie zum Beispiel Datenbankverbindungen erreichen ( ”Pooling“).Weiterhin führten diese Server ihre Programmanweisungen in vielen Unterprozessen ( ”Threads“) innerhalb des eigenen Prozesses aus. Dadurch war ein Neustarten des Serverprozesses nur selten nötig. Diese Applikationsserver benutzen zwar weiterhin ähnliche oder gleiche Internetserver, bilden um diese aber noch weitere Programmlogik ab, um fortgeschrit- tene Anwendungen realisieren zu können. Dadurch wird es Programmierern ermöglicht sich auf die Implementierung der Logik der Geschäftsprozesse zu konzentrieren.

Das Ziel von Workflow-basierten Internetprogrammen ist das Abbilden von robusten aber dennoch weitgehend flexiblen Geschäftsprozessen, die verschiedene Unternehmen oder Personen bei fortbestehender Autonomie miteinander verbinden. Praktische Exem- plare dieser Gattung sind beispielsweise Internetshops, CMS, Supply Chain Management Systeme, Just-in-Time Partnerprogramme und vollautomatische Reservierungssysteme durch eine Anbindung an ein Backend (Warenwirtschaft, Hotelverwaltungssystem. . . ).

2.2.5. Kollaborative

Die Stärke workflow-basierter Internetprogramme liegt in der effizienten Verbindung weniger Kommunikationspartner aufgrund einer Fixierung des Datenaustausches in Form von XML Schemata. Bei unstrukturierten Prozessen, Vorgängen und Daten können Informationen bei solch einer Fixierung in ein Schema verloren gehen.

Kollaborative Internetprogramme versuchen sich diesem Problem anzunehmen und gemeinsame Arbeits- und Informationsräume zu schaffen. Oft werden sie bei Bedarf an sehr flexibler, offener Kommunikation eingesetzt und so zur kollaborativen Erstellung von Inhalten genutzt. Kollaborative Internetprogramme zeichnen sich dabei durch ihren einheitlichen Zugang aus. Problematisch ist dabei, neben der intuitiven Gestaltung der Schnittstelle, der Unterschied der optischen Darstellungen verschiedener Browser, der den Zugang erschweren kann, obwohl diesen auf den gleichen Auszeichnungen basieren. Diese Unterschiede sind in der Entwicklung der Internet-Standards und der Browser begründet.

Nach der gedanklichen Konzeption eines Hypertextsystems durch Vannevar Bush wur- de dieses 1989 durch Tim Berners-Lee in Teilen umgesetzt. HTML und HTTP bilde- ten die zentralen Stützen seines Entwurfes. Auf dieser Basis entstand 1994 die HTML Version 2.0. Dieser erste HTML-Standard stellte lediglich rudimentäre Fähigkeiten wie Überschriften,Absätze und Listen zur Verfügung. Durch die wachsende Anzahl an Nut- zern und der drohenden ”Verwässerung“ durch selbständige unternehmensstrategische Erweiterungen des Standards durch die Browserhersteller wurde 1997 die Version 3 .2 verabschiedet, die nun unter anderem auch Tabellen ermöglichte. Diese HTML Version ist als kleinster gemeinsamer Nenner, der von den verschiedenen Browsern unterstütz- ten HTML-Elementen zu verstehen und hat so die Version 2.0 erweitert. Dadurch war diese Version aber auch schon veraltet als sie veröffentlicht wurde. Daher kam es be- reits Ende des Jahres zu einem ersten Vorschlag eines HTML 4.0 Standards. In diesem wurde u.a. dem Wunsch der Industrie pixelgenaue Layouts wie im Druckbereich reali- sieren zu können mit der Unterstützung für Cascading Style Sheets (CSS) entsprochen. CSS Durch CSS war nun eine, lang geforderte¹¹, Trennung zwischen Dokumentenstruktur und -darstellung möglich. Durch die Einführung von CSS wurden viele Formatanweisungen früherer HTML-Versionen missbilligt (engl. ”deprecated“).

Die nächste Version von HTML wurde Extensible Hypertext Markup Language XHTML XHTML genannt. Der Grund für diese Umbenennung ist ein technischer. Durch den Erfolg von XML bei der Entwicklung von Workflow-basierten Internetprogrammen, entschied man sich gegen die ”StandardGeneralizedMarkupLanguage“(SGML)als Sprache zur Defi- nition von HTML und für das transparentere XML¹². Mit dem XHTML 1.1 Standard wurden alle als missbilligt gekennzeichneten Elemente endgültig verworfen. Eine Modu- larisierung des Standards sichert aber weiterhin eine Abwärtskompatibilität. Dazu kann der Autor eines HTML-Dokumentes entscheiden, welches Modul des Standards verwen- det wird.

Aufgrund der Existenz unterschiedlicher Standards, Standardversionen, Browser und Browserversionen, welche wiederum unterschiedliche Standards und Standardversionen umsetzen, ist eine vollkommen interoperable Schnittstelle fast unmöglich zu erstellen. Ei- ne Entwicklung wird sogar noch schwieriger, wenn Interaktionen mit Programmierspra- JavaScript chen auf der Clientseite wie zum Beispiel durch JavaScript hinzugefügt werden. Java- Script ist eine objektorientierte Skriptsprache, die ursprünglich von der Firma Netscape entwickelt wurde. JavaScript implementiert unter anderem eine Schnittstelle zum DOM.

Die verwalteten Inhalte dieser Gattung werden nicht mehr nur über eine Veröffent- lichung wie bei einem CMS erreicht, sondern auch durch eine Beteiligung der Nutzer. Über verschiedene Instrumente wird versucht möglichst viele Nutzer zu möglichst großer Teilnahme zu bewegen. Solche Internetprogramme sind ab einer unterschiedlichen hohen kritischen Masse von teilnehmenden Nutzern nicht mehr auf Inhalte des eigentlichen Seitenbetreibers angewiesen. Die entstehende Eigendynamik produziert genügend Inhalte, die wiederum von den Nutzern konsumiert werden und diese dazu veranlasst ihrerseits wieder Inhalte zu produzieren (engl. ”community-drivencontent“).DieserKreislaufbe- darf aber kontrollierender Maßnahmen durch den Seitenbetreiber wie zum Beispiel Foren Moderation, um einen qualitativen Standard zu etablieren.

Das wahrscheinlich populärste Mitglied dieser Gattung ist die Wikipedia, die auf Ba- sis der Wiki-Funktionalität durch weltweites kollaboratives Arbeiten die größte Enzy- klopädie unseres Planeten geschaffen hat. Anwendungen des Dokumenten- oder Wis- sensmanagement, Content-Management-Systeme, Groupware, Internettagebücher (engl. ”Weblogs“oderauch ”Blog“),andereWikisund ”SozialeNetzwerke“¹³ sindweitere bekannte Beispiele dieser Gattung.

2.2.6. Portalorientierte

Bisher konnte man erkennen, dass Internetprogramme während ihrer Entwicklung im- mer wieder neue Funktionalitäten oder Methoden hervorbrachten. Mit dieser Gattung wird keine neuartige Funktionalität eingeführt. Diese Art von Internetprogramm verbin- det verschiedene potentiell heterogene Informationsquellen und/oder auch andere Inter- netprogramme inklusive deren Datenquellen miteinander. Diese so genannten Internet- Portal portale (kurz: Portal) stellen vorhandene Dienstleistungen innerhalb einer einheitlichen Umgebung mit einer einheitlichen Bedienbarkeit zur Verfügung. Portalorientierte Inter- netprogramme sammeln viele nützliche Informationen und können viele Anwendungen rund um eine bestimmte Ausrichtung zur Verfügung stellen. Wenn personalisierte Dien- ste angeboten werden, sind diese meist über eine einzige Identifikation beim System nutz- bar (engl. ”singlesignon“).PortalefunktionierenaberauchineinerB 2 B-Umgebung, um beispielsweise viele Informationen bei einer Zusammenarbeit zweier Unternehmen zu organisieren. Portale implementieren auch eigene Funktionalität, da ein Mehrwert wie zum Beispiel über eine Durchsuchbarkeit aller verbundenen Inhalte durch die interne Verwaltung über Meta-Daten erreicht wird.

Durch solche zentralen Einstiegspunkte (engl. ”singlepointofaccess“)kannspeziellbei öffentlichen Portalen eine starke Kundenbindung erreicht werden, da manche Nutzer mit wenig Erfahrung im Internet solche Portale mit dem WWW verwechseln¹⁴. Außerdem kann bei einer Identifikation des Nutzers durch seine Anmeldung speziell auf den Nutzer abgestimmtes Marketing (engl. ”one-to-onemarketing“)betrieben werden.

Beispiele dieser Gattung sind Marktplatzportale wie gebot wie ”eBay“,PortalemitbreitemAn- ”WEB.DE“oderCommunity-PortalewieSinglebörsen,welchesichdurchdie Kommunikation der Nutzer untereinander auszeichnen.

2.2.7. Ubiquitäre

Durch die Miniaturisierung von Computerprozessoren haben diese in immer kleineren Endgeräten Platz. Angefangen beim Laptop bis hin zum Handy ist Software fast omni- präsent. Handys wurden für die Kommunikation über das Telefonnetz entwickelt. Es ist also schlüssig, dass auch andere Endgeräte als Browser eines PC Dienstleistungen des Web nutzen können.

Ubiquitäre Internetprogramme stellen personalisierte Dienste zu jeder Zeit an jedem Ort für jedes Medium zur Verfügung, womit ein nahezu allgegenwärtiger Zugriff auf diese Internetprogramme möglich wird. Auch diese Gattung stellt keine neue Funktionalität bereit, da diese Internetprogramme ebenfalls vorhandene Funktionalitäten zugrunde lie- gender Gattungen nutzen. Diese müssen jedoch meist sowohl auf der Client- als auch auf der Serverseite erweitert werden, um dem zentralen Merkmal eines ubiquitäre Internet- programmes genügen zu können. Ubiquitäre Internetprogramme müssen sich dynamisch, dass heißt zur Laufzeit an sich ändernde Kontexte anpassen können. Kontexte können zum Beispiel die Präferenzen des Benutzers, das genutzte Endgerät und seine verfügbare Bandbreite, die aktuelle Uhrzeit oder der momentane Aufenthaltsort sein. Anwendungen wie eine Ausgabe einer Liste von bevorzugten Restaurants mit Mittagstisch der Stadt in der sich ein Nutzer gerade befindet sind somit denkbar. Eine solche Nutzbarkeit setzt das Vorhandensein entsprechender Endgeräte (Handy, Palmtop, Blueberry) voraus, die mit den Internetprogrammen kommunizieren können. Vor diesem Hintergrund wurden Browser auch für portable Geräten entwickelt. Diese Geräte unterstützen meist andere Darstellungssprachen, da auch unterschiedlichen Interaktionsmöglichkeiten als bei der Bedienung einer Desktop-Anwendung vorhanden sind. Das ”WirelessApplicationProto- col“ (WAP) ermöglicht das Anzeigen von Internetseiten auf dem Handy. Das Internet- programm muss diesen Standard unterstützen und dementsprechend erweitert worden sein. WAP wird schon seit längerem eingesetzt, wird aber bei weitem nicht so oft ge- nutzt wie das HTML-Equivalent. Der Umfang der Darstellungsmöglichkeiten ist auch erheblich geringer. Mittlerweile werden auch portable Geräte, die eine normale HTML Darstellung unterstützen, verkauft.

Ubiquitäre Internetprogramme sind die erste Gattung, die sich heute noch nicht in dem Ausmaß etabliert hat wie ihre Vorgänger. Ihr wird in der nahen Zukunft ein großes Potential eingeräumt.

2.2.8. Semantisches Internet

Dieser Thematik widmet sich das Kapitel ”DerzeitigeEntwicklungen“ausführlicher.Es sei daher an dieser Stelle nur auf die Seite 42 verwiesen.

2.3. Qualität

Qualität wird je nach Kontext verschiedenartig definiert. Für die Zwecke dieser Arbeit kann man den Begriff mit dem ”AusmaßanÜbereinstimmungvonProduktansprüchen und Produktionsleistungen“ beschreiben. ”DerQualitätsbegriffkannsichdabeisowohl auf die Beschaffenheit als auch die Eigenschaften eines Produktes beziehen.“ (Diller, 1998)

Durch die annähernde Omnipräsenz von Software hat die Gesellschaft ein berechtigtes Interesse an Softwarequalität. Daher wurden Richtlinien von Standardisierungsorganisa- tionen formuliert, welche helfen sollen, Softwarequalität zu gewährleisten. Da sich die Qualitätsbetrachtung auf jede differenzierbare ”EigenschafteinesProduktes“beziehen kann, wurden 1994 Qualitätsmerkmale von herkömmlichen Programmen im Rahmen der Normenfamilie DIN EN ISO 9000( ”Qualitätsmanagementsysteme“)formuliert.

Da Internetprogramme bereits einen Großteil der heute entwickelten Individualsoft- ware (Kappel u. a., 2004; Ginige u. Lowe,2001) ausmachen, beide Programmarten teil- weise große Unterschiede aufweisen und speziell in der Informatik zehn Jahre eine äußerst lange Zeit ist, ist ein Transfer dieser Qualitätsmerkmale sinnvoll. Diese Merkmale sind meist auch Anforderungen an Internetprogramme, die oft von Kunden in einer Anforder- ungsdefinition festgehalten werden. Diese werden daher im übernächsten Abschnitt auf Internetprogramme bezogen.

Die Qualität von Software setzt sich aus der Beschaffenheit der einzelnen Qualitäts- merkmale zusammen (vgl. nationales Vorwort DIN,1994). Überspitzt und beispielhaft kann daher gesagt werden, dass selbst einwandfrei funktionierende Programme von kei- nem Nutzen sind, wenn sie nicht bedient werden können. Um die vielen unterschiedli- chen Anforderungen erfüllen zu können bzw. die Qualität von Software gewährleisten zu können, wird Qualitätssicherung im Rahmen des Qualitätsmanagements durchgeführt.

2.3.1. Qualitätssicherung

Qualitätsmanagement ist die ”GesamtheitderqualitätsbezogenenTätigkeitenundZiel- setzungen“ (Petrasch,1998, Seite 39). Unter Qualitätssicherung im speziellen versteht man ”allegeplantenundsystematischenTätigkeiten,dieinnerhalbdesQualitätsmanage- mentsystems verwirklicht sind, und die wie erforderlich dargelegt werden, um angemes- senes Vertrauen zu schaffen, dass eine Einheit die Qualitätsforderung erfüllen wird“¹⁵.

Es ist möglich eine Qualitätssicherung von Software auf unterschiedliche Arten und Ebenen zu erreichen, daher kommen in der Praxis konzeptionell unterschiedliche Ansätze wie CMMI¹⁶, iterative Entwicklung¹⁷, Tests und/oder agile Methoden wie das Extreme Extreme Programming zum Einsatz, um die Qualität von Software sicherzustellen. Programming Beim Extreme Programming (XP) wird auf eine strikte Abarbeitung einer Anforder- ungsdefinition verzichtet, da Kundenwünsche noch während der Softwareentwicklung berücksichtigt werden. Möglich ist das durch Entwicklungszyklen, die im Gegensatz zu klassischen Modellen in kürzerer Zeit sämtliche Phasen der klassischen Softwareentwick- lung durchlaufen und dabei nur die im aktuellen Iterationsschritt benötigten Merkmale implementieren.

Tests spielen nicht nur beim XP eine tragende Rolle. Sie sind eine der wichtigsten Maßnahmen der Qualitätssicherung und gehören zu den dynamischen Techniken der analytischen Qualitätssicherungsmaßnahmen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6.: Einordnung der Qualitätssicherung und beispielhafte Techniken

Diese Arbeit wird sich lediglich mit dem Testen als qualitätssichernde Maßnahme ausführlich auseinandersetzen. Softwaretests werden folgendermaßen definiert:

”TestenistderProzess,einProgrammmitderAbsichtauszuführen,Fehler zu finden.“ (Myers,2004, Seite 4)

Es existieren bereits zahlreiche Methoden und Techniken für das Testen von Softwaresystemen. Üblichsinddie ”Schreibtischtests“(Myers,2004,Seite 32),diedurchden Autor selbst durchgeführt werden. Da dieser eine voreingenommene Ansicht auf seinen Entwurf hat, ist dieses Verfahren jedoch suboptimal. Vor diesem Hintergrund und da- durch, dass noch andere Qualitätsmerkmale zu überprüfen sind, wurden viele Testarten entwickelt, die erfolgreicher sind. Definitionsgemäß ist ein Test umso erfolgreicher, je mehr Fehler er findet (vgl. Myers, 2004, Seite 4). Der Ansatz des Testens ist also Fehler zu finden und nicht eine Abwesenheit von Fehlern zu beweisen¹⁸. Eine Qualitätsverbesserung tritt ein, wenn ein Fehler korrigiert wird.

Mit entsprechenden Tests kann der Qualitätszustand eines Internetprogramms durch die Identifikation von Fehlern in den einzelnen Merkmalen ermittelt werden. Fehler können an unterschiedlichen Positionen (Programmsteuerfluss, Datenvereinbarungen, Einund Ausgabefehler) auftreten. Speziell an der Schnittstelle für die Eingaben durch Nutzer können Tests nur noch schwierig formuliert werden, da kaum Gesetzmäßigkeiten auftreten. Daher wird auch manchmal die Sinnhaftigkeit prominenter Testmethoden angezweifelt¹⁹ und diesbezüglich kontroverse Diskussionen geführt.

Was aber ist ein Fehler? Wir sprechen von einem Fehler, wenn ein unerwartetes Er- gebnis eintritt, dass uns falsch erscheint. Im Rahmen der Qualitätssicherung hat dieser Begriff auch in Anlehnung an die Qualitätsdefinition noch eine weitere Bedeutung, denn ”einFehlertrittauf, wenn ein Ergebniseines Tests nich tmitdemErgebniseinerAn- forderungsdefinition übereinstimmt“ (vgl. Kappel u. a.,2004, Seite 163). Wenn getestet wird, ob sich das Programm gemäß der Anforderungsdefinition verhält, spricht man von Verifikation Verifikation. Testet man hingegen, ob es sich gemäß der Erwartungen der Nutzer verhält, Validierung wid von Validierung (auch bekannt als High-Order Testing“) gesprochen. Meist wird ” die Verifikation vor der Validierung durchgeführt.

Durch kurze Projektzyklen werden Tests oft vernachlässigt. Dabei ist Testen in den meisten Fällen wirtschaftlich, da es im Idealfall viele schwerwiegende Fehler früh findet. Dadurch kann sich das Testen schnell amortisieren, da im weiteren Projektverlauf ein ”Summationseffekt“ der Fehlereintritt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.7.: Summationseffekt von Fehlern in einem Projekt (vgl. Balzert,1998)

Fehler sind in späteren Stadien außerdem oft schwieriger und daher teurer zu finden und zu beheben. Aber nicht nur die unterschiedlichen Projektphasen wirken sich auf die Tests aus. Die 3-dimensionale Struktur der Abbildung 2.8 spiegelt die verschiedenen Einflussfaktoren auf Tests wieder. Diese werden von den Projektphasen, den Testarten und Qualitätsmerkmalen beeinflusst. Jede Schnittmenge bedarf einer adäquaten Berück- sichtigung. Vor diesem Hintergrund sind Tests in verschiedenen Kontexten unterschied- lich sinnvoll. Eine wesentliche Aufgabe der Qualitätssicherung ist daher die Auswahl einer effektiven Testtechnik für die jeweilige Situation. Vor der Phase tung“ wird beispielsweise ein sogenannter ”Betriebund War- ”Abnahmetest“durchgeführt.Qualitätssicher- ung sollte aber projektbegleitend in allen Phasen geschehen (vgl. Balzert,1998).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.8.: Einflussfaktoren auf Tests (vgl. Kappel u. a.,2004, Seite 174)

Das Testen als projektbegleitende, integrierte Aktivität wird von agilen Methoden speziell im Bereich der Internetprogrammierung immer öfters angewendet (vgl. Eckstein, 2004). Bei einer testgetriebenen Entwicklung werden sogar zunächst gemäß einer An- forderungsdefinition sogenannte ”Testszenarien“festgelegt,welchewährendderEntwicklungdurch ”Testfälle“(engl. ”testcases“)undUnit-Testsimplementiertwerden. ”Unit-Unit-Tests Tests (auch Komponententests) dienen zur Validierung der Korrektheit von Modulen einer Software, z.B. von einzelnen Klassen“ (Wikipedia,2005d). Durch die konkreten Programmanweisungen eines Unit-Tests wird dann laufend die eigentliche Anwendungs- funktionalität überprüft. Der Test wird also vor der Anwendungslogik implementiert.

Tests spielen immer öfters eine elementare Rolle innerhalb des Entwicklungsprozesses. Deshalb können diese ebenfalls einer Qualitätssicherung unterliegen, die nach den glei- chen Merkmalen differenziert. Für die Änderbarkeit“(vgl.DIN,1994)vonInternetpro- ” grammen ist es beispielsweise wichtig, dass auch Tests so konzipiert und implementiert sind, dass diese ”mitwachsen“und wiederverwendet werden können.

Aufgrund der praktischen Relevanz werden im nächsten Abschnitt einige Qualitäts- merkmale ausführlicher erläutert und entsprechende qualitätssichernde Methoden und Werkzeuge genannt. Durch die vielfältigen Einflüsse, die die Umwelt an das Projekt und damit auch die Tests stellen kann, wird deutlich, dass in der Praxis Projektmitglieder, die für die Qualitätssicherung zuständig sind, ein aktuelles und adäquates Repertoire an Methoden und Werkzeugen für unterschiedliche Situationen bereithalten sollten. Einige Anregungen sind bei der folgenden Diskussion der Qualitätsmerkmale zu finden.

2.3.2. Qualitätsmerkmale

Die folgenden Qualitätsmerkmale sind an die der ISO/IEC Norm Nummer 9126 bzw. deren deutsche Entsprechung der DIN 66272 angelehnt.

Es wurden speziell diese Qualitätsmerkmale ausgewählt, da verhältnismäßig große Unterschiede zu herkömmlichen Anwendungen existieren und/oder weil das realisierte Projekt erwähnenswerte Lösungen für diese Merkmale bereitstellt (Kapitel 4.3.2). Es sei aber betont, dass jedes Merkmal seine Daseinsberechtigung hat und bei der Entwick- lung mit einer projektspezifischen Gewichtung berücksichtigt werden sollte. So kann ein Erfolg eines Produktes eher erreicht werden. Diese Merkmale sind aber natürlich nicht hinreichend für einen Erfolg, da viele wirtschaftliche Zusammenhänge unberücksichtigt bleiben.

Eine Kontrolle des Zustandes der Qualitätsmerkmale kann durch verifizierende und va- lidierende Tests erreicht werden. Manche Tests sind nicht vollständig objektiv durchführ- bar, weil die Zufriedenstellung des Menschen bzw. seine Meinung gemessen werden muss. Solche Benutzer- oder Zielgruppentests müssen mit einer repräsentativen Auswahl an Personen durchgeführt werden und nahe an der eigentlichen Anwendung und den Anfor- derungen konzeptioniert sein. Daher sind Beispiele für validierende Tests und Messzahlen meist aus dem Kontext gerissen. Dennoch werden exemplarische Messzahlen am Schluss der Erläuterung jedes Merkmals neben beispielhaften verifizierenden und validierenden Tests angegeben.

2.3.2.1. Ordnungsmäßigkeit und Richtigkeit

”MerkmalevonSoftware,diebewirken,dassdieSoftwareanwendungsspe- zifische Normen oder Vereinbarungen oder gesetzliche Bestimmungen und ähnliche Vorschriften erfüllt und die richtigen oder vereinbarten Ergebnisse oder Wirkungen liefert.“ (vgl. DIN (1994))

Ordnungsmäßigkeit

Bei der Situation auf dem heutigen Browsermarkt sind einheitliche Implementierungen von Internet-Standards bzw. ”anwendungsspezifische Normen oder Vereinbarungen“ eine Idealvorstellung. Es ist eine schwierige Aufgabe Inhalte im WWW ordnungsmäßig darzu- stellen, denn es sollte jedermann, mit jeglicher Art von Browsing-Technik²⁰ jede beliebige Internet Seite besuchen können und ein vollkommenes Verständnis der angebotenen In- formationen erhalten, sowie vollständig mit der Internetseite interagieren können (vgl. Accessibility Letourneau (2003)). Diese Zugänglichkeit bzw. Barrierefreiheit (engl. Accessibility“) ist von diversen Faktoren abhängig.

Bislang gibt es keine ”gesetzlicheBestimmungenundähnlicheVorschriften“,dieInter- netseitenbetreiber dazu verpflichten auch körperlich behinderte Personen an der Nutzung der Inhalte teilhaben zu lassen. Dennoch nutzen 80 % der 6,7 Millionen Deutschen, die als schwerbehindert eingestuft sind das Internet (Chancen,2002). Es besteht also bei der Entwicklung von Internetprogrammen zusätzlich zu der moralischen Verpflichtung sogar ein wirtschaftlicher Anreiz diese Personengruppe zu berücksichtigen. Aber auch durch die unterschiedliche Programmierung und Ausstattung verschiedener Browser können Schwierigkeiten auch für körperlich unversehrte Nutzer entstehen.

Für die Accessibility von Inhalten des WWW fehlt bisher ein allgemein gültiges Re- gelwerk. Erste Ansätze zur Standardisierung bilden die Guidelines“ (WCAG) des W3C oder auch das ”WebContentAccessibility ”WebStandardsProject“²¹.DerUm- fang dieser Arbeit lässt es nicht zu alle Richtlinien zu diskutieren. Im folgenden werden daher lediglich einige wichtige Elemente vorgestellt²².

Equivalente Alternativen zu hör- und sehbaren Inhalten anbieten. Textalternativen sollten für jedes Nicht-Text Element zum Beispiel mit den Attributen ”alt“oder ”longdesc“angebotenwerden.BeispielefürNicht-TextElementesindGrafiken und Symbole, Imagemaps, Animationen (animierte GIFs, Flash), Applets, Frames, Audio und Video.

Farben vorsichtig verwenden. Es sollte möglich sein die Inhalte ohne eine Darstellung der Farben erfassen zu können. Nutzer mit Sehschwächen sollten keine Nachteile durch geringen Kontrast von Schrift- und Hintergrundfarbe haben. Informationen, die über farbigen Text angeboten werden, sollten durch entsprechende Auszeichnun- gen (semantisches Markup wie mit dem <strong/> Tag statt Formatierungsmar- kup wie mit dem <bold/> Tag) oder aus dem Kontext erschlossen werden können. Vor diesem Hintergrund kann es auch sinnvoll sein verschiedene Darstellungsarten durch CSS anzubieten.

Korrekte Nutzung von Auszeichnungen und CSS. Der Missbrauch von Auszeichnun- gen hindert Nutzer mit speziellen Browsing-Techniken beim Zugang. Eine immer noch oft praktizierte inkorrekte Anwendung ist das Nutzen von Tabellen (<table/> Tag) zur Anordnung nicht-tabellarischer Daten bzw. zu Zwecken des Layouts.

Der Einsatz neuer Technologien sollte geordnet zurückfallen können. Die Inhalte sollten auch ohne den Einsatz von CSS und JavaScript erkennbar und nutzbar sein können, da ältere Browser diese Technologien möglicherweise nicht unterstützen oder Nutzer diese deaktivieren können. Bedienelemente, welche ausschließlich in JavaScript oder Flash realisiert wurden, sind ein ungenügender Weg, um mit einer Seite zu interagieren. Aufgrund der Plug-In Charakteristik von Flash oder Shock- wave ist ein erheblicher Teil²³ der Browser nicht mit solcher Software ausgestattet.

Es muss daher möglich sein die Inhalte auch ohne solche Zusatzsoftware nutzen zu können.

Nutzung von Technologien und Richtlinien des W3C. Der korrekte Einsatz von Stan- dards wie HTML und CSS hat automatisch eine gute Zugänglichkeit des Produktes zur Folge, da die Spezifikationen vom W3C schon während des Entwurfs auf Acces- sibility überprüft und in einem offenen und die Interessen der Industrie in einem Konsens vereinigenden Prozess entwickelt werden.

Bei der Erstellung eines Internetprogramms ist immer die Zielgruppe zu berücksichtigen. Es ist offensichtlich, dass die zu beachtenden Faktoren je nach Internetprogramm variieren können. Es kann aber nie schaden, möglichst wenige Nutzer, durch umsichtigen Einsatz dieser und anderer Richtlinien, auszuschließen.

Um den Zustand eines Produktes bzgl. dieses Qualitätsmerkmales bestimmen zu können, sind Tests und Messzahlen nötig. Die folgende Tabelle zeigt einige Beispiele zur Überprüfung der Ordnungsmäßigkeit.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1.: Testtechniken und Messzahlen für die Ordnungsmäßigkeit

Richtigkeit

Im Rahmen einer Qualitätssicherung werden viele Methoden genutzt, um Fehler in Pro- grammen zu finden bzw. die Richtigkeit von Internetprogrammen zu überprüfen. Sol- che Fehler können sich auf unterschiedlichste Weise auswirken. Zum Beispiel sollten in Internet-Shops als bestellbar ausgezeichnete Waren nicht vergriffen sein (Aktualität) oder der Preis sollte richtig angezeigt werden (Verlässlichkeit). Die Datenintegrität und -korrektheit ist daher von besonderer Wichtigkeit für den E-Commerce, da auf Basis der angezeigten Informationen Verträge abgeschlossen werden. Ein Internetprogramm, welches Daten in richtiger Art verarbeitet und darstellt, erlangt kein Alleinstellungsmerkmal, erfüllt aber eine selbstverständliche Forderung.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2.: Testtechniken und Messzahlen für die Richtigkeit

2.3.2.2. Sicherheit

”MerkmalevonSoftware,diesichaufihreEignungbeziehen,unberechtigten Zugriff, sowohl versehentlich als auch vorsätzlich, auf Programme und Daten zu verhindern.“ (DIN,1994)

Das Vertrauen, welches täglich in Internetprogramme gesetzt wird, konnte sich nur auf Basis von sicheren Internetprogrammen entwickeln. Jedoch sind illegale Handlungen im Internet wie die Sammlung und der Missbrauch persönlicher Daten ( ”Phishing“), ”Hacking“oderauch ”Denial-of-Service“AttackenimmeröftersThemajuristischerDis- kussionen. Eine frühzeitige Planung der Sicherheit von Internetprogrammen kann einige solcher negativen Auswirkungen vermeiden.

Vollständige Sicherheit kann es in einer Software nur geben, wenn nicht mit dieser interagiert wird. Da dies Programme überflüssig machen würde, ist die Sicherheitsfrage immer auch eine der Zugeständnisse von Kompromissen. Auf der einen Seite möchte man dem Nutzer ermöglichen möglichst frei mit der Anwendung zu kommunizieren auf der anderen Seite fürchtet man schädliche Interaktionen.

Die Norm unterscheidet zwischen versehentlich und vorsätzlich unberechtigten Zugriff auf Daten. Bei versehentlich mehrmaligen Abschicken eines Bestellformulars will der Nutzer sicher sein können, dass der fällige Betrag nur einmal von seinem Guthaben abgezogen wird. Durch serverseitige Sitzungsverwaltungen, die sich auf vom Client übermittelte Daten stützt, ist es möglich solche ”Mehrfach-Bestellungen“zuidentifizieren.Esistaber auch möglich durch vorsätzlich manipulierte Daten die Sicherheit des Internetprogram- mes zu gefährden. Solche oder andere Eingaben von Nutzern an den Server sollten nicht ohne Kontrolle an Programme weitergeleitet werden. Durch den offenen Quellcode und freie Bezugsmöglichkeiten mancher Internetprogramme, können sich Angreifer intensiv auf ihre Angriffe vorbereiten. Man sollte freie Internetprogramme also nicht kontrolllos installieren oder zumindest in einer eingeschränkten Umgebung ( ”Sandbox“)zuerst testweise betreiben. Installationsroutinen sollten nach erfolgreichem Gebrauch aus den Verzeichnissen gelöscht werden, da es ansonsten bei erneuter Ausführung zu Datenverlusten kommen kann.

Innerhalb einiger Internetprogramme ermöglichen Rechteverwaltungssysteme eine differenzierbare Authorisierung von verschiedenen Nutzern. Dies macht beispielsweise in einem Internetforum eine Unterscheidung zwischen normalen Mitgliedern, die lediglich Beiträge verfassen dürfen und Administratoren, welche mehr Rechte (zum Beispiel das Löschen von Beiträgen) als die Genannten besitzen, möglich.

Diese Rechteverwaltung und alle anderen Funktionalitäten sollten über eine sichere Art der Programmierung realisiert werden. Es sollten also keine potentiell anfälligen, zum Beispiel den Speicherschutz des Betriebssystems gefährdenden, Anweisungen ge- nutzt werden. Diese könnten nämlich von Angreifern genutzt werden, um eigene Pro- grammanweisungen auszuführen. Da solche Sicherheitslücken oft erst nach einer länge- ren Testphase erkannt werden, ist es ratsam immer den aktuellsten Stand einer Software zu installieren²⁴.

Außerdem sollten in öffentlich zugreifbare und mit zusätzlichen Rechten versehenen Ordnern (zum Beispiel ”cgi-bin“)keineInterpreter(PERL,Python...)liegen,dadiese ansonsten ebenfalls mit beliebigen Argumenten zur Ausführung gebracht werden könnten. Um eventuellen Schaden zu minimieren, sollten Internetserver niemals mit Administratorrechten betrieben werden. Unter Unix-ähnlichen Betriebssystemen sollte der Server mit einem eingeschränkten Benutzer ( ”nobody“oder ”httpd“)ausgeführtwerden.

Auf der Ebene des Anwenders entstehen im allgemeinen durch die Abhängigkeit von zusätzlicher Software zusätzliche Sicherheitslücken. Alleine durch die Verwendung von Browsern entstehen Gefahren²⁵. Wenn zusätzlich noch mit Programmiersprachen, die beim Client ausgeführt werden, gearbeitet wird (zum Beispiel ActiveX, Java oder JavaScript) erhöht sich das Sicherheitsrisiko nochmals.

Generell ist der Wunsch vieler Anwender nach einer sicheren Kommunikation durch den offenen und verteilten Aufbau des Internets schwierig zu entsprechen. Denn ein sicherer Datenaustausch hängt von einigen Faktoren ab. Empfänger von Daten eines sicheren Internetprogrammes erhalten ihre Daten von dem erwarteten Absender (Au- thentizität), ohne Kenntnisnahme, auch der Verbindung, durch Dritte (Vertraulichkeit), in einer unverfälschten Weise (Integrität) und mit einer nachträglichen Nachprüfbarkeit des Absenders (Verbindlichkeit) (vgl. Kappel u. a., 2004, Seite 320). Die Kryptographie befasst sich mit der Verschlüsselung von Informationen und hat Technologien wie Secure Sockets Layer (SSL) hervorgebracht, welches in Verbindung mit Hypertext Transfer Pro- 2.3. Qualität tocol Secure (HTTPS) eine gesicherte HTTP-Verbindung bzw. eine verschlüsselte Kom- munikation zwischen Rechnern im Internet ermöglicht.

Es ist ungewöhnlich, dass dieses Merkmal in der Norm nicht eine Ebene höher anzufinden ist und keine Unterpunkte aufweist. Sicherheit wird vom Nutzer als Selbstverständlichkeit aufgefasst und wurde deswegen ausführlicher behandelt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.3.: Testtechniken und Messzahlen für die Sicherheit

2.3.2.3. Interoperabilität und Austauschbarkeit

”MerkmalevonSoftware,diesichaufdieEignungbeziehen,mitvorgegebenen Systemen zusammenzuwirken oder diese anstelle einer spezifizierten anderen Software in der Umgebung jener Software zu verwenden. Austauschbarkeit kann Merkmale der Installierbarkeit und Anpaßbarkeit einschließen.“ (vgl. DIN (1994))

Interoperabilität

Eine Interoperabilität zwischen Internetprogrammen und Desktop-Programmen wird in den wenigsten Fällen von Internetprogrammen angeboten²⁶. Die Gründe sind in der architektonischen Unterschiedlichkeit beider Programmarten und im Fehlen eines allge- mein gültigen Standards bei der Erstellung von Internetprogrammen zu finden. Durch die weite Verbreitung beider Gattungen und die damit verbundene parallele Nutzung ist aber oft der Wunsch nach Synchronisation vorhanden. Solch eine Interoperation erfor- dert standardisierte Methoden des Datenaustausches, die in der Praxis oft über XML realisiert werden.

Aufgrund der Vielzahl von unterschiedlichen Internetprogrammarten haben sich in der Praxis daher viele XML-Dialekte herausgebildet, die fast alle sehr spezielle Ziele verfolgen (zum Beispiel SVG²⁷, MathML²⁸ oder OPML²⁹ ). Solche Derivate werden durch eine Document Type Definition (DTD) oder ein XMLSchema definiert. In diesen sind die Regeln für eine valide XML Auszeichnung dieser Derivate festgelegt.

Ein allgemeineres und prominentes Beispiel für eine Interoperation mit Internetpro- Web grammen auf Basis von XML sind die sogenannten Web Services. Ein Web Service stellt Services eine Dienstleistung bereit, die von Internetprogrammen unter Angabe seiner Adresse in Form eines Uniform Resource Identifier (URI)³⁰ unter Verwendung XML-basierter Nachrichten und durch den Austausch über internetbasierte Protokolle genutzt werden kann (vgl. Wikipedia, 2005e). Durch die dadurch zur Verfügung gestellte einheitliche und internetübergreifende Nutzbarkeit der Dienstleistungen aus anderen Programmen heraus, werden Web Services speziell bei ubiquitären Internetprogrammen und im Semantischen Internet wahrscheinlich eine wichtige Rolle spielen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.4.: Testtechniken und Messzahlen für die Interoperabilität

Austauschbarkeit

Die mögliche Interpretation dieses Merkmals im Sinne von der Wiederverwendbarkeit von Programmanweisungen (engl. ”code-reuse“)sollebenfallsnäheruntersuchtwerden.

Mit der Beurteilung von Programmen anonym gehaltener Autoren (engl. bzgl. Qualitätscharakteristika wie ”PeerRating“) ”Wartungsfreundlichkeit,Erweiterbarkeit,Anwendbar- keit und Klarheit“ (Myers,2004, Seite 33) existiert eine Testmethode, die sich nicht mit der algorithmischen Korrektheit eines Programms befasst.

Oft werden diese Charakteristika in Form von Programmierrichtlinien anhand erfolgreicher Strategien (engl. ”best-practises“)unternehmensweitfestgelegt.WennProgram- mierrichtlinien richtig angewendet werden, führen diese zu einheitlicheren, besser lesbaren Quellcode mit weniger Fehlern³¹. Diese Richtlinien sollten zum Beispiel im Intranet öffentlich erreichbar sein.

Außerdem kann Austauschbarkeit Merkmale der Installierbarkeit einschließen (vgl. DIN, 1994). Einige Internetprogramme wie zum Beispiel das Content Management Sys- teme ”Typo 3 “bieteneineInstallationsroutinean,diedenenvonherkömmlichenPro- grammen ähnelt. Dort werden Umgebungsvariablen abgefragt (Datenbankserver, -nutzer, -kennwort . . . ) und dann notwendige Installationen vorgenommen (Anlegen von Daten- banktabellen, Füllen der Tabellen mit Daten für die erste Nutzung. . . ). Solche Installati- onsroutinen funktionieren, da solche Softwareprodukte meist in einer ähnlichen Architek- tur und Konfiguration (LAMP³² oder andere Variationen) genutzt werden. Bei komplexe- ren Installationen speziell bei einer Eingliederung von ”Legacy“-Anwendungen³³ würde die Programmierung solcher Installationsroutinen unwirtschaftlich werden. Dennoch gibt es Integrationsmodelle bspw. durch Applikationsserver, welche auf einer zusätzlich eingeführten Abstraktionsschicht, über der konkreten Software basieren.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.5.: Testtechniken und Messzahlen für die Austauschbarkeit (die Bewertungs- grundlage für die Validierung ist nun ein anderer Entwickler)

2.3.2.4. Fehlertoleranz

”MerkmalevonSoftware,diesichaufihreEignungbeziehen,einspezifiziertes Leistungsniveau bei Software-Fehlern oder Nicht-Einhaltung ihrer spezifizier- ten Schnittstelle zu bewahren.“ (DIN,1994)

Fehlerfreie, komplexe Computerprogramme sind eine Idealvorstellung. Das bedeutet, dass man mit auftretenden Fehlern innerhalb eines Programms umgehen muss. Viele Computersprachen bieten die Möglichkeit an auftretende Fehler während der Programmausführung über Ausnahmen (engl. ”exceptions“)behandelnzulassen.DadurchmüssenAusnahmen illegale Operationen wie zum Beispiel eine Division durch Null nicht mehr zu einem Programmabsturz führen. Beim Auftreten einer Ausnahme, zum Beispiel eben diese Division durch Null, werden alternative Anweisungen ausgeführt, die für diese Situation vom Entwickler definiert wurden. Auf diese Weise können geordnete Rückfälle (engl. oder ”gracefuldegradations“)implementiertwerden.

”fallbacks“geordnete Rückfälle Der eingeführte Fehlerbegriff der Seite 18 gilt auch hier. Daher sollten programminterne Regelungen zu Datentypen, Berechnungsgenauigkeit usw. festgelegt werden, um Fehler auch identifizieren zu können.

Da speziell an der Schnittstelle für die Eingaben durch die Nutzer Willkürlichkeiten auftreten, können diese nur schwer und meist unzureichend simuliert werden. Deshalb sollten fehlertolerante Computerprogramme Eingaben des Nutzers überprüfen und ggf.

korrigieren bevor sie mit diesen arbeiten. So können zusätzlich zu den Vorgesehenen auch noch fehlerhafte bzw. im Sinne des Entwickler nicht vorgesehene Interaktionen durch den Nutzer durchgeführt werden. Ein bekanntes Beispiel für eine mögliche Aus- prägung eines fehlertoleranten Internetprogramms ist die dem Nutzer vorgeschlagene Alternative bei zum Beispiel fehlerhafter Buchstabierung eines Suchwortes bei der Such- maschine ”Google“. Es ist jedochdaraufzuachtennichtzuvieleEingabenodererst nach entsprechender internen Umformulierung zuzulassen, da ein Zielkonflikt mit dem Qualitätsmerkmal Sicherheit besteht.

Viele fehlerhafte Eingaben durch Nutzer entstehen durch die subjektive Interpretation der visuellen Darstellung des Programms, die von der durch den Entwickler Beabsichtigten abweichen kann. Daher ist durch eine klare Nutzerschnittstelle darauf zu achten, dass so wenig Fehler wie möglich entstehen. Die nächsten beiden Abschnitte werden sich näher mit dieser Thematik befassen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.6.: Testtechniken und Messzahlen für die Fehlertoleranz

2.3.2.5. Verständlichkeit

”MerkmalevonSoftware,diesichaufdenAufwandfürdenBenutzerbeziehen, das Konzept und die Anwendung zu verstehen.“ (DIN,1994)

Metapher Gängige Praxis ist eine Adapation von gewohnten Metaphern und Idiomen. Beispie- Idiom le für Metaphern sind ”DragandDrop“undder ”Schreibtisch“.BeispielefürIdiome sind Programmfenster, Titelleisten, Hyperlinks und Dropdown-Menus. Durch die An- wendung vertrauter Konzepte ist eine relativ gute Verständlichkeit gewährleistet, da kein aufwändiges Umlernen erforderlich ist. Dennoch ist die Darstellung von Internet- programmen uneinheitlich. Bei herkömmlichen Programmen ist das Erscheinungsbild bspw. in den Steuerelementen schon vorgegeben. Bei dem Betriebssystem Mac OS X sorgt ”Aqua“³⁴ füreineeinheitlicheDarstellung.WeiterhinwerdenEntwicklernvonOS X Programmen Richtlinien für die Benutzerschnittstelle gegeben³⁵.

Viele Unternehmen pflegen solche Darstellungskonventionen (engl. ”styleguides“),um zu gewährleisten, dass ein einheitlicher Eindruck des Unternehmens (engl. ”corporate identity“) im WWW entsteht. Dadurch, dass die visuelle Darstellung von Internetanwendungen auf HTML basiert, welches große Freiheit in der Gestaltung lässt, kann ein Wettbewerbsvorteil erreicht werden. Vor dem Hintergrund der uneinheitlichen Gesaltung verschiedener Internetpräsenzen ist auf eine interne Konsistenz zu achten, um eine Akzeptanz beim Nutzer zu erreichen. Die größere gestalterische Freiheit sollte daher nicht überstrapaziert werden. Es sei denn dies ist explizit erwünscht. Der Nutzer sollte jedoch immer ohne ein Lesen von langen Dokumentationen in der Lage sein eine Anwendung in ihren Grundfunktionalitäten bedienen zu können.

Durch die non-lineare Verknüpfung von Hypertext sind besondere redaktionelle Vorge- hensweisen bei der Strukturierung und Erstellung der Inhalte nötig. Neben einer klaren und einfachen Sprache³⁶ sollten auch die Vorzüge des Mediums genutzt werden. Oft wer- den Inhalte noch wie für ein druckbares Medium aufbereitet. Sichtbar wird dies bspw. in der Bezeichnung von Links. Die immer noch häufig anzufinden Hypertextmodellierung- en im Stil von ”mehrInformationenfindenSie hier “zeugendavon,dassderAutorden Umgang mit dem Medium Internet nicht verstanden hat. Linktexte sind ”sichtbareEnt- sprechungen von einer URL“ (Kappel u. a.,2004, Seite 120) und sollten daher kompakt und selbsterklärend sowohl die Inhalte der Zielseite beschreiben und damit den Nutzer motivieren den Verweis zu verfolgen als diesen auch über die Konsequenzen aufklären - unterstützend können für diesen Zweck auf kleine aber trotzdem unterscheidbare und verständliche Bilder bzw. Symbole (engl. ”icons“)benutztwerden.DerNutzersolltekog- nitiv nicht belastet werden oder sich desorientiert fühlen. Speziell sollte er sich folgende Fragen nicht stellen müssen (vgl. Kappel u. a. (2004)).

- Verlasse ich die Seite?
- Wo kann ich die Auswirkungen der Aktivierung des Links sehen?
- Wird eine Datei heruntergeladen?
- Benötige ich zur Anzeige zusätzliche Software (zum Beispiel ”Plug-Ins“)?
- Löse ich eine rechenintensive Operation auf dem Server aus und muss lange auf meine Antwort warten?
- Kann ich die Aktion rückgängig machen?

Verschiedene Strategien helfen Orientierungslosigkeit auf einer Internetpräsenz zu ver- mindern. Sogenannte ”Sitemaps“helfendemNutzerdurcheineAnzeigedesgesamten Hypertextgeflechts aber auch eine Liste der besuchten Seiten und/oder sichtbare Unter- scheidung zwischen besuchten, noch nicht besuchten und aktiven Links sind willkommene Hilfestellungen. Bei nicht gefundenen Knoten sollte der Internetserver dem Nutzer diese unterstützenden Massnahmen zur Verfügung stellen, anstatt eine einfache Fehlermeldung auszugeben. Generell sollte ein zugängliches und verständliches Zugriffsmodell umgesetzt sein, welches die Fähigkeiten des Hypertextes nutzt. Oft wird jedoch die interne Unter- nehmensstruktur als Vorbild für die Struktur des Hypertextgeflechtes genommen. Dies muss nicht sinnvoll sein, da so gegebenenfalls alltägliche Begriffe der Seitenbetreiber für externe Nutzer als bekannt vorausgesetzt werden. Die Internetpräsenz sollte nur die Benutzerbedürfnisse wiederspiegeln.

Durch das Gruppieren von Elementen und zusätzliche Informationen bzgl. der Bezie- hungen zwischen diesen Gruppen ist eine Unterscheidbarkeit gewährleistet, die Nutzern beim Verständnis hilft (Chisholm u.a., 1999). Ein Beispiel wäre eine semantische Orga- Interaktions- nisation durch Unterteilung der Interaktionselemente nach -kanälen³⁷.

kanäle Die Schriftart und -größe sollte so gewählt sein, dass eine gute Lesbarkeit sichergestellt ist. Da die Schriftgröße durch den Browser geändert werden kann, ist darauf zu achten, dass in diesem Falle weiterhin eine zugängliche, verständliche und bedienbare Oberfläche zur Verfügung steht.

Die ISO-Norm 9241-12 beschäftigt sich mit Informationsdarstellung und nennt als Schlagworte: Klarheit, Unterscheidbarkeit, Kompaktheit, Konsistenz, Erkennbarkeit, Lesbarkeit und Verständlichkeit. Diese Zielvorgaben sind sowohl auf die Gesamtheit der Präsentation und Struktur eines Internetprogrammes als auch auf einzelne Bestandteile beziehbar und wurden exemplarisch erläutert.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.7.: Testtechniken und Messzahlen für die Verständlichkeit

2.3.2.6. Bedienbarkeit

”MerkmalevonSoftware,diesichaufdenAufwandfürdenBenutzerbeider Bedienung und Ablaufsteuerung beziehen.“ (DIN,1994)

Oft wird Bedienbarkeit nicht als Merkmal (engl. ”feature“)erkannt.Esisteineübli- che Geschäftsstrategie vieler großer Softwarehersteller ihre Kunden zu einem Kauf durch möglichst viele Merkmale zu bewegen ( ”Featuritis“³⁸ ).UmdiesevielenMöglichkeiten eines Programm in der Benutzerschnittstelle unterzubringen wird oft eine implementierungszentrierte Unterteilung³⁹ gewählt (vgl. Cooper u. Reimann, 2003), welche den eigentlichen Zweck von Software, den Nutzer seine Arbeit möglichst schnell bei bestmöglicher Qualität machen zu lassen, nicht immer zuträglich ist.

Ein Bereich der Software Ergonomie, der in der international ausgerichteten Fachspra- che als Usability ”Usability“⁴⁰ bekanntist,widmetsichdiesenProblemen.Ursprünglichbeschäftig- te sich die Usability nur mit herkömmlichen Programme. Inzwischen gibt es aber viele Transfers⁴¹ auf Internetprogramme. Dies ist auch nötig, da Internetprogramme lediglich einige Metaphern und Idiome von herkömmlichen Programmen übernehmen. Nicht vorhandene wie zum Beispiel der ”Doppelklick“müssendurchentsprechendeInteraktions- gestaltung kompensiert werden.

Die Freiheit der Gestaltung von Internetprogrammen und die, verglichen mit der von der Programmierung von Desktop-Programmen, relative flache Lernkurve und die damit zusammenhängende Unbedarftheit einiger Entwickler, haben schon so manches ”Usability-Monster“erschaffen.OftwirdauchvonerfahrenenEntwicklernnichtzwi- schen der Bedienbarkeit eines Internetprogrammes durch den Endnutzer und durch einen Administrator unterschieden. Mit einigen CMS ist es möglich gut bedienbare Nutzeroberflächen zu gestalten, trotz oder gerade weil die interne Oberfläche zur Administration nur als ein schlechtes Beispiel aufgeführt werden könnte⁴². Gerade in diesem Bereich kann aber eine unverständliche Bedienbarkeit zu schwerwiegenderen Fehlern wie zum Beispiel versehentlicher Löschung führen.

Es ist unmöglich allgemein verbindliche Regeln für die Organisation einer Benutz- eroberfläche zu geben. Schlagwörter wie Klarheit, Konsistenz usw. sind zwar hilfreich, müssen aber für jede Oberfläche neu ausgelegt werden. Einfacher ist es häufig wieder- kehrende Probleme zu nennen. Eine Schwierigkeit besteht zum Beispiel darin viele Infor- mationen und/oder Interaktionsmöglichkeiten auf wenig Platz darzustellen. In diesem Kontext ist meist die Frage nach den wirklich notwendigen Interaktionsmöglichkeiten konstruktiv.

Bei der Abbildung 2.9 wird deutlich wie dieses Problem von der Software ”iTunes“⁴³, einer Software zum Abspielen und Verwalten von Musikdateien, gelöst wurde. Bei Betäti-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.9.: Reaktion von Teilen der

gung des ”iTunes“BenutzerschnittstelleaufInteraktion ”Abspielen“-Knopfes(linkesBild)wirddieserdurchden ”Pause“-Knopf(rech- tes Bild) ersetzt - vorher ist eine Anzeige auch nicht notwendig. Auch der Vor- und Rücklauf macht erst Sinn, wenn ein Musikstück abgespielt wird.

Eine weitere Annäherung von Internetprogrammen an die Bedienbarkeit bekannter Desktop-Programme durch die Nutzung von Technologien wie JavaScript oder Flash kann sich interaktiv in Vorteilen bemerkbar machen. Latent ist jedoch immer die Gefahr vorhanden Nutzer auszuschließen. Wenn solche Technologien unbedingt erforderlich oder von einem Kunden gewünscht sind, ist es notwendig auf die Möglichkeit einer Nutzbarkeit ohne diese Technologie zu achten.

Im Zusammenhang mit ubiquitären Internetprogrammen bzw. der Unterstützung vieler unterschiedlicher Clients (engl. ”multi-plattformdelivery“)stelltdieUnterschied- lichkeit der Interaktionsmöglichkeiten der Clients eine Herausforderung dar. Für jeden Client-Typ sind entsprechende Strategien umzusetzen, um möglichst wenig Nutzer aus- zuschließen.

Nicht nur die Links sind eine Besonderheit bei Interaktionsabläufen von Internetprogrammen. Die oft genutzten Steuerelemente des Browsers wie zum Beispiel der Button oder die ”Zurück“- ”Lesezeichen“-FunktionstellenbesondereAnsprücheaneinenInterakti- onsdesigner. Diese zusätzlichen, immer gegenwärtigen Interaktionsmöglichkeiten sind besonders bei Internetprogrammen, die AJAX nutzen schwierig zu berücksichtigen. AJAX wird im nächsten Kapitel ausführlich behandelt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.8.: Testtechniken und Messzahlen für die Bedienbarkeit

3. Derzeitige Entwicklungen

Die beiden in diesem Kapitel behandelten Themen werden derzeit häufig diskutiert. Sowohl das ”SemantischeInternet“alsauch ”AJAX“werdendasInternetrevolutionieren, wenn man einigen Quellen Glauben schenkt. Es soll daher untersucht werden, ob dieser ”Hype“auchnachvollziehbareGründehat,welcheNachteilemitdenVorteileneinher gehen und inwiefern die Techniken aktuell eingesetzt werden.

Auch sollen diese beiden Themen voneinander abgegrenzt werden, da in der Diskussion um diese beiden Neuerungen in der Entwicklung des WWW oftmals Begriffe durcheinander gebracht werden.

3.1. AJAX

Die Bezeichnung ”AsynchronousJavaScriptandXML“(AJAX)tauchtezumerstenMal in dem Weblog der amerikanischen Firma ”AdaptivePath“imFebruar 2005 auf.Dort wurde eine Art der clientseitigen Programmierung beschrieben, welche einen asynchro- nen Datenaustausch ermöglichte, der dazu genutzt werden kann Teile von Internetseiten zu aktualisieren. Im Gegensatz dazu basierte der im Kapitel 2.3 vorgestellte Transak- tionszyklus auf einem synchronen Austausch von Daten, welcher alle Auszeichnungen einer Internetseite neu lädt - auch wenn Abschnitte unverändert geblieben sind.

Teile des Vorgehens, welches AJAX beschreibt, wurden aber schon vorher eingesetzt und waren unter dem Namen XMLHttp- ”XMLHttpRequest“bekannt.XMLHttpRequestistder Name eines JavaScript-Objektes, welches die asynchrone Kommunikation ermöglicht. Request AJAX ist daher weder eine neue noch generell eine Technologie. AJAX ist ein Ansatz, der die kombinierte Nutzung von den bestehenden Standards XHTML, CSS, DOM, XML, XSLT, dem XMLHttpRequest-Objekt und der clientseitigen Programmiersprache Java- Script beschreibt.

In welcher Art werden diese Technologien genutzt? Es ist sinnvoll diese Frage anhand eines Beispiels zu beantworten. Basis des Beispiels ist ein einfaches Registrierungsformular, welches aus XHTML- und CSS-Anweisungen besteht.

Zur Verdeutlichung ist die Oberfläche dieser Anwendung an der Seite abgebildet. Eine Email-Adresse, ein Anmeldename und ein Kennwort werden abgefragt und serverseitig gespeichert. Beim fehlerlosen Ausfüllen und erfolgreicher Registrierung wird der Nutzer angemeldet und erhält eine Nachricht, dass seine Sitzung begonnen hat. Dies alles wird auf lediglich einer Internetseite realisiert.

Der Nutzer wird wahrscheinlich aufgrund der vorgegebenen Reihenfolge als erstes seine Email-Adresse eingeben.

Wenn er dann zu dem nächsten Eingabefeld entweder mit der Maus oder über die Tabulator-Taste wechselt, kann das Verlassen des Adressen-Eingabefeldes bzw. das Wech- seln des Fokus von JavaScript abgefangen werden und mit entsprechenden Aktionen ver- Event-Handler bunden werden. So genannte Fall kann der Event-Handler getragenen Daten über das Event-Handler“ ermöglichen diese Behandlung. In diesem ” ”onChange“eineJavaScript-Funktionaufrufen,diedieein- ”XMLHttpRequest“-ObjektandenServerübermittelt.Für den Nutzer geschieht dies nicht sichtbar, da die Email-Adresse weiterhin im Eingabefeld eingetragen bleibt. Auf diese Weise könnte also die Email-Adresse gespeichert werden.

Abbildung in dieser Leseprobe nicht enthalten

Bei den nächsten Eingabefeldern reicht diese einseitige Kommunikation nicht mehr aus. Für eine Anmeldung müssen sowohl Daten gesendet als auch empfangen werden. Der Nutzername wird auf die gleiche Weise wie bei der Adresse übermittelt. Serverseitig muss nun eineÜberprüfung ablau- fen, ob der angegebene Nutzername schon in Verwendung ist. Entsprechend des Ergebnis der serverseitigen Berech- nung wird entweder eine Fehlermeldung oder eine Bestäti- gung an den Client übermittelt.

Abbildung in dieser Leseprobe nicht enthalten

Der Server kann in diesem Falle fertige Auszeichnungen erzeugen, welche zum Client geschickt und dort eingesetzt werden. Wenn der Name noch nicht registriert ist, erscheint ein Bestätigungssymbol neben dem entsprechenden Feld und es kann das Passwort eingegeben werden. Nach der Ein- gabe und beim Drücken eines ”Anmelden“-Knopfeswird das Passwort an den Server gesendet, gespeichert und eine Bestätigung der Anmeldung an den Client gesendet.

Dieses Beispiel hat die AJAX-Bestandteile XML, XSLT und DOM nicht genutzt. XML wird bei AJAX für dieÜber- mittlung von Daten benutzt. Bei kleinen Anwendungen muss meist kein Dateiformat wie XML eingesetzt werden. Für einfache Anwendungen reicht eine Kommunikation über ein- fachen Text. Wenn XML zum Datentransfer eingesetzt wird, erfolgt der Zugriff auf die Daten dann aber meist über DOM. Aus diesen Daten könnten dann sogar clientseitig Auszeichnungen über XSLT oder JavaScript generiert und über JavaScript eingesetzt werden.

Wie schon beschrieben wurde, ist das XMLHttpRequest-Objekt ein JavaScript-Objekt. Dieses erlaubt clientseitigen JavaScript-Anweisungen HTTP-Anfragen an den Ursprungs- server zu senden und die ensprechende HTTP-Antwort vollständig zu nutzen. Genauer gesagt sind solche Anfragen nur an die selbe Domain von der auch die Dateien stammen erlaubt. Alle anderen werden von den Sicherheitsrichtlinien des Browsers abgeblockt.

Das XMLHttpRequest-Objekt wurde zuerst von Microsoft im Internet Explorer 5 als ActiveX-Objekt entwickelt. Das ”Mozilla“Projektimplementierteeinentsprechendes natives Objekt für ihren Browser ab der Version 1.0, für Netscape 7 und für den Firefox. Apple stellt dieses Objekt ab Safari 1.2 zur Verfügung. Das W3C hat eine ähnliche Funktionalität in dem noch nicht verabschiedeten Standard ”DocumentObjectModel Level 3 Load and Save Specification“ vorgeschlagen (vgl. Connection, 2005).

In diesem Objekt werden Statusvariablen gespeichert, welche für den Aufruf von ex- ternen Funktionen ( Callback ”Callback“-Funktionen)genutztwerdenkönnen.Einsolches ”event- gesteuertes“ Programmieren ist zum Beispiel von der GUI-Programmierung unter dem Betriebssystem ”Windows“oderauchvonderNutzungvonSAXbeiderVerarbeitung von XML bekannt.

Ein Quellcode-Beispiel soll diese Art der Programmierung verdeutlichen. In der folgen- den JavaScript-Funktion wird zuerst das browserspezifische XMLHttpRequest-Objekt er- stellt und diesem ein eigener Event-Handler zugewiesen. Schließlich wird die eigentliche asynchrone Anfrage durchgeführt.

Abbildung in dieser Leseprobe nicht enthalten

Der Event-Handler ruft die angegebene Callback-Funktion nur auf, wenn die angeforderten Daten komplett übermittelt worden sind. In der Callback-Funktion selber kann auf die Antwort des Servers entweder über die Attribute ”responseText“oder ”response XML“ des XMLHttpRequest-Objektes auf die übermittelten Texte oderdas übermittelte XML zugegriffen werden. Entsprechend weiterer Anweisungen in dieser Funktion können die erhaltenen Daten in die Internetseite eingesetzt werden. Für eine komplette Liste aller Attribute und Methoden des Objektes sei auf die entsprechenden Seiten der Browserhersteller verwiesen.

Die asynchrone Kommunikation, die über dieses Objekt realisiert wird, benötigt ei- ne Ausweitung der Darstellung des Transaktionszyklus im Kapitel 2.3. Bei diesem Mo- dell mussten Anwender nach jeder Aktion warten, bis die neue Internetseite komplett übertragen wurde. Mit AJAX sind nicht mehr nur synchrone Transaktionen möglich, sondern auch mehrere asynchrone gleichzeitig. Der Benutzer kann also weitere Aktionen durchführen, während die asynchrone HTTP-Anfrage oder Antwort noch übertragen wird.

Die Darstellung auf der folgenden Abbildung wird nun nicht mehr vom Browser allein gesteuert, sondern auch über die AJAX-Schicht, welche zum BeispielÄnderung auch

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1.: Durch den AJAX-Ansatz erweiterter Transaktionszyklus

vor dem Erhalt der angeforderten Daten vornehmen kann (zum Beispiel Systemrückmeldungen). Bei Erhalt der Daten könnten dann die Rückmeldungen durch die erhaltenen Daten ausgetauscht werden. Auf die Darstellung mehrerer asynchron ablaufender Kommunikationen gleichzeitig wurde wegen höhererÜbersichtlickeit verzichtet.

Für den Browser bleibt der Benutzer dabei immer bei der gleichen Internetadresse, da die dargestellte Seite durch JavaScript Anweisungen und asynchronen Datenaustausch verändert wird und keine herkömmlichen HTTP-Anfragen durchgeführt werden. Kon- krete Schwierigkeiten, die sich aus diesem Verhalten ergeben, werden im übernächsten Abschnitt illustriert. Zuerst soll jedoch das Potential von AJAX veranschaulicht werden.

3.1.1. Potential

Schon lange haben Entwickler versucht die Verbindung mit dem Server über das Maß, was durch herkömmliche Nutzung von Browsern möglich ist, zu erweitern und neue Inhalte vom Server dynamisch nachzuladen. Dies geschah über Tricks wie versteckte, sich selber neu ladende Frames¹ oder so genannte ”faceless Java Applets“².

Aufgrund der beschriebenen Erweiterung des Transaktionszyklus durch den AJAX- Ansatz sind solche Vorgehensweise nicht mehr nötig und Internetprogramme können dadurch speziell in den Qualitätsmerkmalen Funktionalität, Effizienz und Benutzbarkeit positiv beeinflusst werden. Durch die meist voreingebaute Vorhandenheit der genutzten Technologien in den Browsern müssen keine Plug-Ins, wie zum Beispiel bei Flash oder SVG, heruntergeladen und installiert werden oder langwierige Initialisierungsprozesse wie bei Java-Applets gestartet werden. Dies wirkt sich positiv auf die Akzeptanz bei den Nutzern aus.

Durch AJAX sind Anwendungen im WWW möglich, die Desktop-Anwendungen ähneln.

Durch die asynchrone Kommunikation kann die Anwendung jederzeit ansprechbar sein und die Wahrnehmung der Anwendung wird nicht durch Anzeige eines leeren Browserfen- sters während des Datentransfers gestört. Dadurch ist eine Annäherung an die Bedienung von Desktop-Programmen möglich. Ein Internetprogramm wird so eher vom Nutzer als ganzheitliches Programm verstanden - und nicht mehr als eine Abfolge oder ”Diashow“ von Internetseiten. Generell können durch die Nutzung dieses Ansatzes intuitivere Benutzerschnittstellen zur Verfügung gestellt werden.

AJAX kann auch in Verbindung mit anderen Technologien genutzt werden. In Ver- bindung mit XSLT können auf der Clientseite umfangreiche Transformationen des über- mittelten XML geschehen. XSLT wird aber nicht von so vielen Browsern wie AJAX unterstützt³. Auch die bisher verwendeten Seitenvorlagen können genutzt werden. Es ist also oft keine Überarbeitung der Darstellung des Internetprogrammes notwendig, denn über diesen Ansatz können Portionen der ”normalen“Seitewiederverwendetwerden. Über XML kann AJAX sogar in Verbindung mit Web Services eingesetzt werden⁴.

Auch serverseitig kann es zu einer Entlastung durch AJAX kommen. Zum einen kann der Server durch Verlagerungen von Berechnungen auf die Clientseite wie zum Beispiel bei der Überprüfung von Formulardaten entlastet werden. Zum anderen generell da- durch, dass zielgerichteter kommuniziert werden kann. Es ist nicht mehr nötig Teile von Internetseiten zu übermitteln, die unverändert geblieben sind. Es ist sogar vorstellbar, dass der Client die komplette Generation der Darstellung anhand weniger übermittelter Daten vom Server übernimmt.

3.1.2. Gefahren und Schwierigkeiten

Es gibt viele Gefahren und Schwierigkeiten, die bei einer Verwendung von AJAX entstehen können (vgl. Bosworth, 2005). Sollten diese entstehen und ungelöst bleiben, können die positiven Effekte in den Qualitätsmerkmalen zunichte gemacht werden oder sogar ein schlechterer Qualitätszustand erreicht werden. Im folgenden werden viele mögliche Gefahren und Schwierigkeiten den Qualitätsmerkmalen zugeordnet.

Funktionalität

Da eine wie von AJAX vorgeschlagene Verwendung der Technologien nicht von den Browserherstellern vorgesehen ist, harmoniert AJAX nicht mit den eingebauten Interaktionsmöglichkeiten des Browsers. Zum einen kann durch den Gebrauch von AJAX das Zurückspringen auf die zuletzt besuchte Seite durch Betätigung des dafür vorgesehenen Knopfes in der Oberfläche des Browsers ( ”Zurück-Button“)funktionsuntüchtig werden. Zum anderen ist es auch oft nicht möglich Adressen von Seiten als Lesezeichen (engl. ”bookmarks“)zuspeichernoderdieseanBekanntezusenden.DieUrsachebeider Probleme liegt darin, dass die Adresse in der Adressleiste nicht immer den aktuellen Status des Programms wiederspiegelt, da viele Prozesse asynchron ablaufen und diese Aktivitäten den Browser nicht veranlassen die angezeigte Adresse zu aktualisieren.

Auch in Sachen Accessibility bzw. Ordnungsmäßigkeit gibt es Gefahren hinsichtlich des Gebrauches von AJAX. Projektverantwortliche müssen sich darüber im Klaren sein, dass AJAX ein Aufsatz auf bestehende Anwendungen darstellt. Wenn AJAX eingesetzt wird, sollte immer auch eine Strategie entwickelt werden, was mit Nutzern geschieht, die Java- Script nicht aktiviert haben⁵. Auch beim automatisierten Zugang durch Suchmaschinen- Roboter oder ”Spider“ kann es zu einer falschen Indizierung durch dasasynchroneNach- laden von Inhalten kommen. Außerdem wäre es falsch anzunehmen, dass Internetpro- gramme mit AJAX Desktop-Anwendungen ersetzen können. Eine AJAX-Programm soll- te also Werkzeuge bereitstellen, die eine Interoperabilität mit Anwendungen für den Desktop bereitstellt.

Der Sicherheitsaspekt ist ebenfalls ein wichtiger in der Entwicklung mit AJAX. Wenn das XMLHttpRequest-Objekt im Browser arbeitet, gelten für dieses die gleichen Sicher- heitsrichtlinien wie für jede andere JavaScript Aktivität, denn JavaScript läuft in einer so genannten ”Sandbox“.Lediglichinnerhalbdieses ”Sicherheitskäfigs“kanndieProgram- miersprache agieren. Daher sind sicherheitskritische Anweisungen wie Dateien auslesen oder ändern verboten.

Es wurde bereits erwähnt, dass die Kommunikation über das XMLHttpRequest-Objekts ausschließlich mit dem Ursprungsserver funktioniert. Außerdem kommt noch hinzu, dass Kommunikation über HTTP ablaufen muss. AJAX Anwendungen können also zum Bei- spiel nicht lokal von der Festplatte über das Die ersten Sicherheitslücken des ”File“-Protokollgetestetwerden.

”XMLHttpRequest“-ObjektesimInternetExplorer sind bereits nachgewiesen worden⁶. Diese könnte unter anderem zur Verschleierung der verweisenden Seite (engl. ”referrer-spoofing“) genutzt werden.

Benutzbarkeit

Die Benutzbarkeit von Internetprogrammen wird durch die Möglichkeiten einer asynchronen Kommunikation beeinflusst.

Wenn ein Link bei einer synchron arbeitenden Internetseite geklickt wurde, vergeht eine bestimmte Zeit, während die Daten ausgetauscht werden und anschließend wird die neue Seite aufgebaut. Bei asynchronen Verbindungen kann die Oberfläche weiterhin ansprechbar bleiben und weitere Aktionen können durchgeführt werden. Damit es zu keinen Missverständnissen bei der Benutzung kommt, sind visuelle Signale an adäqua- ter Position von Nöten, die den Nutzer auf die ausgelöste Aktivität hinweist. So wird sozusagen die Pause der herkömmlichen Internetseiten gefüllt. Dem Nutzer muss nicht unbedingt bewusst werden, dass keine normale Transaktion ausgeführt wird. Der Nutzer muss auch nicht unbedingt wissen, dass er nicht auf eine andere Internetseite gelangt, sondern den Status eines Programms ändert, wenn dieser einen Link verfolgt. Er muss aber verstehen, dass etwas ausgeführt wird. Da dieser sonst ggf. mehrmals die gleiche Aktion ausführt.

Die Freiheiten durch die neue Technologie sollten nicht dazu eingesetzt werden alle Regeln des Designs von Benutzerschnittstellen zu vergessen. Viele AJAX Demonstrati- onsprogramme bedienen sich einer Oberfläche, die nur schwer zu verstehen ist. Dies wirkt sich negativ auf die Akzeptanz bei den Nutzern aus. Richtlinien wie die ”Grundsätzeder Dialoggestaltung“ der DIN 9241-10 mit Merkmalen wie Aufgabenangemessenheit, Selbst- beschreibungsfähigkeit, Erwartungskonformität usw. sollten berücksichtigt werden.

Die Zeit, die vergeht bis eine asynchrone Anfrage beantwortet wird, kann genauso wenig wie eine synchrone Anfrage beinflusst werden. Daher können AJAX Meldungen unerwartet eintreffen und in die Internetseite eingesetzt werden. Wenn lange Texte über- mittelt werden, kann es dazu kommen, dass die Leseposition des Nutzers verschoben wird und dieser seine alten Position wieder finden muss. Es ist trotzdem wichtig, dass der Nutzer Änderungen an der Seite mitbekommt. Dies sollte aber nicht über aufwändige visuelle Effekte geschehen, da dies ebenfalls die Aufmerksamkeit vom Inhalt nimmt.

Effizienz

Die verschiedenen Technologien, die AJAX nutzt, werden durch JavaScript zusammengehalten. Dieses wird auf dem Client ausgeführt und kann bei langsamen/überforderten Rechnern, schlecht programmierten Programmanweisungen und aufwändiger Funktionalität die Akzeptanz durch die Nutzer gefährden. Außerdem sollten diese wissen, dass bei bestimmten Aktionen eine Menge Rechenarbeit auf dem Server verursacht wird und die Antwort entsprechend lange auf sich warten lassen könnte. Rechtzeitige und sinnvoll positionierte Rückmeldungen vom System sollten den Nutzer davon abhalten eine aufwändige Operation gleich mehrmals anzustoßen.

3.1.3. Fehlerbehebung

Der größte Teil von Fehlern bei der Entwicklung mit AJAX entsteht schätzungsweise bei der Entwicklung mit JavaScript. Eine Vorstellung der Möglichkeiten der Fehlerbehebung der anderen AJAX-Bestandteile würde den Rahmen dieser Arbeit sprengen. Daher beschränkt sich diese Betrachtung fast ausschließlich auf JavaScript.

Beim Auftreten von Fehlern, egal in welcher Programmiersprache, ist es wichtig zu wissen welche Werte in den angelegten Variablen gespeichert sind. Für die Behebung von Fehlern in JavaScript bzw. deren Identifikation gibt es verschiedene Möglichkeiten und Ansätze.

Die vordefinierte Funktion alert() gibt einen Text in Form einer Dialogbox aus. Diese Funktion erwartet als Argument eine Zeichenkette, die auch durch eine Konkatenation von Zeichenketten und Variablen entstehen kann. Je nachdem in welchem Abschnitt eines Programms diese Funktion eingesetzt wird, stehen dem Entwickler unterschiedliche Schnappschüsse der Variablenwerte zur Verfügung.

Abbildung in dieser Leseprobe nicht enthalten

Das Beispiel-Skript setzt natürlich voraus, dass die beiden Variablen id und knoten definiert sind. Speziell bei fortgeschrittenen Programmiertechniken wie verschachtelten Schleifen oder Rekursion artet diese Form der programminternen Informationsausgabe Logging (engl. OK“-Knopfes aus, da man oft nur an der Aus- ”Logging“)inhäufigenKlickendes ” gabe eines bestimmten Fensters interessiert ist, bedingt durch den Programmdurchlauf mehr als nur diese eine Box erhält. Diese Methode des Fehlerfindung ist also nur bei kleineren und einfachen Skripten sinnvoll.

Ein Logging über eine Ausgabe der Informationen in Textdateien ist sinnvoller, da das umständliche Bestätigen der Dialogboxen entfällt. Das Logging wie man es von anderen Programmiersprachen wie Java oder Python kennt, wird in JavaScript durch Pakete wie ”fvlogger“⁷ umgesetzt.

Die vorgestellten Techniken geben Aufschluss über den Zustand des Programms über selbstdefinierte Ausgaben. Fehler müssen anhand dieser Ausgaben selber bestimmt wer- den. Ein direktere Identifikation kann manchmal über die Fehlermeldungen der Browser geschehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2.: Screenshot des ”JavaScriptConsole“desFirefox.

Der in dem Bild sichtbare JavaScript-Ausdruck alert(test); enthält einen Fehler und dieser wird mit Fehlerbeschreibung bei der Ausführung ausgegeben. Die Fehlermeldungen dieser Konsolen sind nicht immer so eindeutig wie bei diesem Beispiel, welches die oben eingeführte alert-Funktion benutzt und das Argument nicht als Zeichenkette durch umschließende Anführungsstriche kennzeichnet bzw. die Variable test nicht findet, da sie nicht definiert wurde. Speziell die Fehlermeldungen des Internet Explorers sind meist unverständlich und helfen wenig bei der Fehlersuche.

Debugging-Umgebungen wie man sie von anderen Programmiersprachen kennt, sind in solch einer Anzahl und Ausstattung nicht vorhanden. Der Mozilla-Browser stellt aber eine Debugging-Umgebung namens anweisungen mittels ”Venkman“zurVerfügungmitdersichProgramm- ”Breakpoints“näheruntersuchenlassen.

In Kombination mit AJAX wird die Fehlerfindung nochmals mühevoller, da bei einem Austausch von Teilen einer Internetseite zwar visuell eine Änderung zu verzeichnen ist. Jedoch wirkt sich diese ÄnderungnichtaufeinedenQuelltextaus.Dieskannzu Verwirrung führen. Es gibt Werkzeuge mit denen man dennoch den aktualisierten Auszeichnungsbaum einsehen kann (zum Beispiel den ”DOM Inspector “ bei Firefox).

Aufgrund der vielfältigen Fehlermöglichkeiten bei der Entwicklung mit AJAX ist es wichtig von den vorgestellten Methoden bei der Fehlerfindung zu wissen, um die jeweils passende Methodik für eine Situation parat zu haben. Der Unterstützungskomfort bei der Fehlerfindung und -behebung wie bei anderen Programmiersprachen kann von JavaScript nicht erreicht werden. Dies ist unter anderem ein Grund für den hohen Kostenfaktor bei der Entwicklung von AJAX-fähigen Internetprogrammen.

3.1.4. Schlussfolgerungen und Ausblick

AJAX hat es mittlerweile von einem wenig dokumentierten und fast nur diskutierten Ansatz zu einer ansehnlichen Verbreitung geschafft. Unternehmen wie ”Google“und ”Yahoo!“(Flickr⁸ )sehenPotentialinAJAXundsetzenesinproduktivenUmgebungen ein. Sogar von Adobe selbst wird AJAX als Alternative für viele Anwendungen von Flash angesehen⁹. Das Internetprogrammierungs-Framework ”RubyonRails“hatUn- terstützung von AJAX eingebaut. Sogar Microsoft bietet mittlerweile ein Framework für AJAX Anwendungen auf Basis von ”.NET“mitdemNamen ”Atlas“an.Esgibt noch eine Vielzahl anderer Framworks, die meist aus Anweisungen für die serverseitige Kommunikation und das Ersetzen von HTML auf der Clientseite bestehen.

Diese anfängliche Etablierung lässt sich auf viele Gründe zurückführen. Zum einen entstehen durch die Offenheit der verwendeten Standards keine Abhängigkeiten von Her-stellern und es ist eine Zukunftssicherheit gewährleistet. Die Unterstützung durch die Browser ist meist schon eingebaut und kein Plug-In ist nötig. Aus der Sicht von IT-Verantwortlichen sind die größtenteils bekannten Technologien und der damit verbunde-ne geringere Trainingsaufwand für Web Entwickler bzw. die geringeren Kosten ebenfalls ein zu beachtender Faktor.

Jedoch ist AJAX kein ”Allheilmittel“.

Eine Benutzerschnittstelle mit AJAX auszustatten, ist mit nicht unerheblichen zusätz- lichen Kosten verbunden. Es muss daher vorher überlegt werden, ob AJAX zum Internet- programm passt bzw. ob durch den Einsatz von AJAX ein Mehrwert für die Anwendung entsteht. Eine Aufgabenangemessenheit muss also gewährleistet sein. Technologien zum Selbstzweck¹⁰ bzw. in nicht adäquaten Situationen zu verwenden, bringt den Nutzern nichts und auf diesen sollte der Fokus bei der Entwicklung mit AJAX liegen. Die Ge- fahr ist groß, dass mit fehlerhafter Programmierung und Verwendung der nicht überall vorhandenen Technologien Nutzer ausgeschlossen werden. Vor diesem Hintergrund ist auch zu berücksichtigen, dass aufwändige AJAX Programme viel Rechenleistung auf dem Client erfordern. Die Zeiteinsparungen durch das nur noch teilweise notwendige Nachladen der Seite könnte in Extremsituationen (aufwändiges Programm und langsa- mer Client) wieder zunichte gemacht werden. Die PCs werden zwar immer schneller, jedoch ist dieser Faktor zu berücksichtigen, da auch nicht nur eine Internetseite oder ein Programm gleichzeitig geöffnet sein kann. Wenn AJAX produktiv eingesetzt wer- den soll, muss die Funktionalität Maßnahmen einer Qualitätssicherung durchlaufen (vgl. Kapitel 2.3.1). Außerdem ist eine Alternative für Browser, die JavaScript nicht verwenden, entweder durch eine Implementierung geordneter Rückfälle oder einer alternativen Internetseite bereitzustellen.

Schließlich kann gesagt werden, dass bei einem Einsatz von AJAX darauf geachtet werden muss, dass Internetprogramme die beschriebenen Gefahren und Schwierigkeiten auf eine adäquate Art lösen und so durch das beschriebene Potential ein Mehrwert für die Anwendung entstehen kann.

3.2. Semantisches Internet

Das Web hat das Verständnis von Computern als Rechenknechte zu ”Einstiegspunkten zu Informationen“ geändert (vgl. Antoniou u. van Harmelen, 2004, Seite 1). Internetpro- gramme wie Suchmaschinen ermöglichen uns die Nutzung von enormen Datenbeständen. Dies führt aber auch zu Problemen. Es scheint so als ob die Menge an Web-Inhalten den technologischen Vorsprung überholt (vgl. Antoniou u. van Harmelen,2004, Seite 24). Unvorstellbar große Mengen an Informationen müssen verwaltet werden und eine gerin- ge Präzision bei der Ermittlung von gesuchten Informationen wird erbracht. Dies liegt unter anderem an der Vokabularabhängigkeit und daran, dass das angezeigte Ergebnis nicht das Ergebnis ist was gesucht wurde. Bei der Eingabe eines Suchbegriffes bzw. ei- ner Vokabel in eine Suchmaschine wird keine sinngemäße oder semantischeÜberprüfung der verwalteten Informationen vorgenommen, sondern diese wird anhand von teilwei- se umfangreichen Rechenoperationen auf Basis von Zeichenketten verglichen. Anhand zusätzlicher Kriterien wie zum Beispiel dem PageRank-Algorithmus¹¹ oder Heuristiken werden als Ergebnis dann Links zu Internetseiten angezeigt. Das Ergebnis wird selbst nicht angezeigt¹². Die gesuchte Information kann sich dabei sogar über mehrere Sucher- gebnisse verteilen. Daher ist es richtig Suchmaschinen nicht als Informationsbeschaffer (engl. ”information retrieval“) ,sondern als Standortermittler (engl. ”locationfinder“)zu bezeichnen (vgl. Antoniou u. van Harmelen, 2004, Seite 24).

Das Haupthindernis einer effizienteren Nutzung der Wissensbestände des WWW ist die fehlende semantische Erfassung der Inhalte von Internetseiten. Für die Suchmaschi- nen sind die Suchergebnisse isolierte Instanzen - es existiert also keine Verbindung zwi- schen den Inhalten. Das ”SemantischeInternet“versuchtWeb-InhalteineinerForman- zubieten, die für Computer verarbeitbar ist. Es wird auch irreführenderweise als ”Web 2.0“ (vgl. Saffer,2005) bezeichnet. Denn es wird kein neues Internet sein, welches parallel zum derzeitigen existiert oder es ersetzt. Das Semantische Internet soll sich aus dem heutigen WWW entwickeln.

3.2.1. Vision

”Theideaofhavingdataonthewebdefinedandlinkedinawaythatit can be used by machines not just for display purposes, but for automation, integration and reuse of data across various applications.“ (Tim Berners-Lee)

Das Semantische Internet besteht für Berners-Lee aus Definitionen und Verknüpfungen von Web-Inhalten in einer Art, die nicht nur für Darstellungszwecke nutzbar ist, sondern auch für eine Automatisierung, Integration und Wiederverwendbarkeit über verschiedene Anwendungen hinweg.

Der ursprüngliche Name ”SemanticWeb“istdaheroftfehlleitend,dadieCompu- ter, aus denen das WWW aufgebaut ist, Daten oder Informationen nicht verstehen oder interpretieren können. Es ist weiterhin lediglich möglich Daten symbolisch zu verarbeiten. Nichtsdestotrotz ist das Potential von solch verknüpften Web-Inhalten enorm. Zukunfts- szenarios wie das folgende sollen durch die Verwendung von verschiedenen Technologien näher rücken (vgl. die folgende Abbildung mit Davies u. a.,2003, Seite 12).

Abbildung in dieser Leseprobe nicht enthalten

Persönliche Agenten könnten selbständige Ver- handlungen untereinander im Auftrag ihrer Besit- zer führen. Diese Verhandlungen können alltägli- che Situationen wie Terminabstimmungen mit all ihren Konsequenzen umfassen. Laut Berners-Lee u. a. (2001) ist es denkbar, dass ein persönlicher Agent mit dem Agenten eines Arztes einen Termin abstimmt. Wenn kein Termin ausgehandelt werden kann, wird der Agent automatisch versuchen mit Agenten anderer Ärzte des gleichen medizinischen Bereiches im Umkreis von 10 Kilometer einen Al- ternativtermin zu vereinbaren. Die Ergebnisse der Agenten können dabei transparent durch den Nutzer nachvollzogen werden.

Dadurch dass es kaum etablierte Anwendungen des Semantischen Internets gibt, sollen drei Kerntechnologien allgemein näher behandelt werden.

3.2.2. Technologien

In den folgenden Unterabschnitten werden vom W3C empfohlene Technologien für die Umsetzung von Anwendungen des Semantischen Internets erläutert. Durch die Bereitstellung dieser Technologien und Verwendung für konkrete Zwecke hofft das W3C die derzeit ungenügend ausgeprägte Standardisierung, die Anzahl von Werkzeugen und die Akzeptanz bei den Nutzern zu verbessern.

Wie wird die Semantik technologisch erreicht? Das semantische Internet versucht die Verknüpfung der Inhalte nicht über intelligentere Suchalgorithmen zu erreichen, sondern das Problem auf der Seite des Inhalts zu lösen. Da der Inhalt des WWW größtenteils über HTML ausgezeichnet ist und dieses für eine präsentationsorientierte Darstellung von Informationen für den Menschen gedacht ist und dementsprechend von Autoren angewendet wird, ist es für Algorithmen schwierig diese Informationen zu verarbeiten.

Ansätze wie die Isolation des eigentlichen Inhalts von Internetseiten über die Identifi- kation von präsentationsorientierten Auszeichnungen wurden zwar versucht, waren aber wenig erfolgreich¹³.

Zusätzliche Informationen über die Internetseiten also Meta-Daten sollen die Informationen verknüpfen. Die Technologie, die für diesen Zweck vom W3C empfohlen wird, ist das Ressource Description Framework, welches im folgenden Abschnitt untersucht wird. Um mit diesen Zusatzinformationen umgehen zu können, ist wiederum eine andere Technologie nötig. Ontologie-Sprachen ermöglichen durch eine logische Analyse der verknüpften Daten letztlich eine Semantik-orientierte Interpretation. Stellvertretend für die Ontologie-Sprachen wird die Ontology Web Language untersucht. Als Beispiel eines sich etablierenden Standards wird RSS untersucht.

3.2.2.1. Ressource Description Framework (RDF)

Mit RDF steht eine Methode bereit Informationen in ihre Einzelteile zu zerlegen und so beispielsweise Web-Inhalte zu verknüpfen. RDF lehnt sich an den grammatikalischen Aufbau vieler gesprochener Sprachen an, denn es definiert, dass Informationen als Li- ste von Ausdrücken, bestehend aus Subjekt, Prädikat und Objekt, ausgedrückt werden müssen. Dabei sind das Subjekt und das Objekt Namen für bestimmte Dinge bzw. Res- sourcen, die beschrieben werden sollen und das Prädikat ist ein Name für die Beziehung zwischen beiden. Mit diesem Ansatz können kompliziertere Zusammenhänge durch das Zusammenführen mehrerer Informations-Tripel beschrieben werden.

Abbildung in dieser Leseprobe nicht enthalten

Dadurch dass der in unterschiedlichen Kontexten und mit verschiedenen Prädikaten genutzte Name ”meineWohnung“sichaufeinetatsächlicheRessourcebezieht,isteine semantische Interpretation wie ”IchwohneinBerlin“denkbar.DurchdieseAusdrücke wird ein Graph beschrieben, der in folgender Abbildung dargestellt wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3.: Ressourcen, Beziehungen und deren Identifikation durch eine URL

Die Ressourcen dieses Graphs könnten durch RDF-Ausdrücke, welche zum Beispiel die Konstante Berlin näher beschreiben zu einem größeren Graphen erweitert werden.

Eine Verarbeitung dieser durch Ausdrücke und Graphen beschriebenen Informationen könnte von Computern allerdings noch nicht erreicht werden. Wie schon von der Vision von Berners-Lee gefordert, müssen die Daten in maschinenverarbeitbarer Form vorliegen. Diese Informationen könnten in XML wie folgt ausgedrückt werden.

Abbildung in dieser Leseprobe nicht enthalten

Die Beispiele zeigen, dass die Semantik nicht in einer Auszeichnungsart festgelegt werden kann, denn beide Beispiele sind nicht falsch. Eine allgemeine Validierung der Auszeichnungen ist also nicht möglich. Eine Einschränkung der zulässigen Ausdrücke muss aber in irgendeiner Weise geschehen, da Ausdrücke wie ”meineWohnungbesitze Berlin“ als ungültig abgewiesen werden sollten. Diese Funktionalität wird durch RDFSchema zur Verfügung gestellt¹⁴. RDFSchema ist zum Zwecke der Inferenz gedacht (vgl. Butler, 2005, Seite 31). Diese Funktionalität wird über Klassen, Objekte und Vererbung wie in objektorientierten Programmiersprachen gelöst. Dadurch wird RDFSchema zu einer einfachen Ontologie-Sprache. Die vom W3C vorgeschlagene Sprache zur Arbeit mit Ontologien wird im nächsten Abschnitt vorgestellt.

Die tatsächliche Notation von RDF kann über die Nutzung von XML erfolgen. Eine XML basierende Syntax hätte Vorteile wie die Unterstützung durch vorhandene Werkzeuge und die von XML implementierten Namensräume, die die unterschiedlichen RDF Auszeichnungen in einem denkbaren Semantischen Internet zuordnen könnten. Eine mögliche Notation des Beispiels wäre die folgende:

Abbildung in dieser Leseprobe nicht enthalten

Diese Notation ist nicht sehr gut für Menschen lesbar. Eine menschenfreundlichere Syntax bietet der ”N3“Ansatz¹⁵.DieserwiederumhatdieVorteiledesanderenAnsatz als Nachteile, da nicht XML als Basis verwendet wird. Gemeinsam ist beiden Notatio- nen, dass sie scheinbar serialisieren, da die Beschreibungen in bestimmter Reihenfolge auftreten. Das zugrundeliegende Datenmodell von RDF ist aber ein Graph und die Notationen ermöglichen lediglich verschiedene Arten der sequentiellen Repräsentation (vgl. Antoniou u. van Harmelen, 2004, Seite 66).

3.2.2.2. Ontology Web Language (OWL)

Eine Ontologie für Computeranwendungen¹⁶ ist der Versuch, die Konzepte eines Wissensraums und die ihm innewohnenden Abhängigkeiten und Wechselwirkungen darzustellen. Dabei wird üblicherweise die Ontologie als das allgemein gültige Schema für alle in diesem Wissensraum möglichen Aussagen definiert. Ontologien können mit OWL in einer computerzugänglichen Art formuliert werden. Ein bekanntes Beispiel für hierarchische Ontologien sind Taxonomien¹⁷. Solche Einteilungen werden durch die in der EDV geläufige Ablage von Inhalten in Ordnern erreicht.

Durch OWL definierte Ontologien setzen sich aus Objekten bzw. deren Klassen, Attributen und den Zusammenhängen zwischen allen Elementen zusammen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.4.: Visualisierung eines Ausschnittes einer Ontologie (vgl. Weikum, 2004)

Zur Verarbeitung bietet OWL zusätzlich zu den von RDF bereitgestellten Möglich- keiten weitere wie Gleichheit und Ungleichheit (zum Beispiel Disjunktheit), Attributein- schränkungen (einige oder alle Attribute eines Objektes können betrachtet werden) und Kardinalitäten (zum Beispiel ”genaueinzugehörigesObjekt“),umdieOntologiezube- trachten. Wenn beispielsweise ein Objekt von der Klasse ”Bello“einerKlasse ”Hund“existiertunddiese ”Säugetier“erbt,ist ”Bello“aucheinObjektvon ”Säugetier“.Durchsol- che Schlussfolgerungen kann durch OWL das zugrunde liegende Datenmaterial intensiver und für Zwecke des Semantischen Internets genutzt werden.

OWL hat sich aus der Ontologie Sprache drei Untersprachen ”DAML+OIL“entwickeltundkanndurch ”OWLLite“, ”OWLDL“und ”OWLFull“genutztwerden.Die Syntax basiert auf XML und wird auf weiterführenden Internetseiten¹⁸ erläutert.

3.2.2.3. RSS

RSS ist eine Familie von XML-basierten Dateiformaten. Eine mittlerweile geläufige An- wendung, die mithilfe von RSS realisiert werden kann, sind die so genannten ”Newsfeeds“. In diesen werden Inhalte ohne präsentationsorientierte Auszeichnungen bereitgestellt (engl. Syndication ”syndication“) .ObwohldieNachrichtenverteilungdiehäufigsteAnwendungvon Feeds sind, kann fast jede Art von Inhalt durch RSS abgebildet werden. Die Syndi- cation mit RSS wurde durch die Popularität von Weblogs gefördert, da diese ihre Inhalte oft zusätzlich im RSS Format anbieten. Diese RSS-Feeds können von speziellen Desktop-Programmen, sogenannten ”News-Readern“,genutztwerden,umNeuigkeiten dieser Blogs lokal zur Verfügung zu stellen¹⁹. Ohne diese Anwendung hätte die Internetadresse eines Blogs immer wieder aufgesucht werden müssen - oft nur um festzustellen, dass keine neuen Beiträge vorliegen.

Die Abkürzung RSS hat in verschiedenen Versionen eine unterschiedliche Bedeutung. Eine Übersicht über die wichtigsten²⁰ Versionen dieses Dateiformates und deren Besonderheiten soll durch die folgende Tabelle gegeben werden:

Abbildung in dieser Leseprobe nicht enthalten

Als Beispiel eines RSS-Feeds soll ein Ausschnitt dieser Arbeit zur Verfügung gestellt werden. Der Feed auf der nächsten Seite entspricht den Anforderungen von RSS 2.0.

Im Vergleich zu den auf RDF basierenden Ansätzen ist die Syntax auch für Menschen Dublin recht einfach lesbar. Auffällig ist die Nutzung des Dublin Core Standards. Dubin Core Core ist ein Meta-Daten Standard, um digitale Objekte zu beschreiben. In dem Beispiel wird es genutzt um die Meta-Daten Autor und Erstellungsdatum des Feeds zu organisieren. Dublin Core spezifiziert aber noch weitere Daten²¹.

Abbildung in dieser Leseprobe nicht enthalten

3.2.3. Anwendungen, Schlussfolgerungen und Ausblick

Wissen wird heutzutage oft als vierter Produktionsfaktor neben Arbeit, Kapital und Boden genannt. Nur ein Unternehmen, welches das interne Wissen effizient nutzen kann, wird am Weltmarkt erfolgreich sein. Das Semantische Internet will durch eine Vernetzung von Inhalten Wissen besser nutzbar machen und hat daher ein großes Potential. Dem Wis- sensmanagement stehen durch eine einheitliche semantische Organisation von Informatio- nen zahlreiche Möglichkeiten zur Verfügung. Zum Beispiel könnte Wissen und ”verwand- tes Wissen“ besser extrahiert, zusammengeführt, gefiltert und dargestellt werden. Sogar Konsistenzüberprüfungen von Wissen sind denkbar (Wissenswartung). Auch das Wissen aus Geschäftsprozessen könnte besser genutzt werden, da Angebote von Internetshops in ihrem Gesamtzusammenhang (Tests und Ruf der Waren oder der Geschäftspartner, Preise vergleichbarer Produkte. . . ) betrachtet werden könnten. Zukunftsszenarien wie selbstständige Verhandlungen von persönlichen Agenten aufgrund der aktuellen Markt- situation sind daher nicht ganz abwegig. Trotzdem ist es noch ein weiter Weg zu solchen Funktionalitäten. Hindernisse auf diesem Weg sind aber nicht mehr wissenschaftlicher Natur, sondern es bedarf vielmehr einer Standardisierung, Integration, Werkzeugentwick- lung und Akzeptanz (vgl. Antoniou u. van Harmelen,2004). Speziell die Notwendigkeit, dass Informationen öffentlich zur Verfügung gestellt werden sollen, erfordert ein massives Umdenken vieler Beteiligter im Bereich des geistigen Eigentums.

Die ersten Schritte werden aber schon gegangen wenn man O’Reilly (2005) glaubt. Er schreibt, dass der Wechsel vom reinen Veröffentlichungsansatz von Inhalten zur Beteili- gung des Nutzers und einer entsprechenden Speicherung die ersten Ansätze eines seman- tischen Internets sind. Beispielsweise werden Blogs über so genannte ”Trackbacks“²² maschinenlesbar verbunden. Aber auch Initiativen, die sich um eine Einhaltung der Internet-Standards kümmern, sind Wegbereiter eines Semantischen Internets.

Die vereinzelt festzustellende Abkehr von Taxonomien zur Einteilung von Inhalten ist schon ein größerer Schritt. Diese nicht sehr menschenlesbare Weise der Organisation wur- de durch das zusätzliche Auszeichnen mit Meta-Daten (engl. Vorgehen ist zum Beispiel in dem ”tagging“)ersetzt.Dieses ”social-bookmarkmanager“del.icio.us²³ umgesetzt. Dort werden von Nutzern angelegte URL mit Meta-Daten versehen und entsprechend organisiert. Auch die Verwaltung von Emails bei baute Suche Prinzip.

”Gmail“vonGoogleoderdieeinge- ”Spotlight“desBetriebssystemsMacOS 10.4 funktionierennachdiesem Die direkte Bereitstellung von Inhalten zur Nutzung in anderen Kontexten bzw. Syndi- cation stellt einen Fortschritt gegenüber dem so genannten ”ScreenScraping“dar.Durch Syndication zum Beispiel mit RSS besteht eine einheitliche und einfache Adressierbar- keit und Nutzbarkeit von Inhalten, welche für eine semantische Organisation von Vorteil ist. Aber auch wenn RSS sich schon verhältnismäßig gut etabliert hat, ist die Akzeptanz der Industrie nicht vollständig gegeben. Zum Beispiel verzichten noch viele Unternehmen darauf einen RSS-Feed anzubieten, da sie durch diese Dienstleistung einen Verlust an Be- suchern ihrer eigentlichen Website, auf der Werbung geschaltet ist, befürchten. Was den Einsatz von RDF und OWL angeht, können wenig etablierte Anwendung genannt wer- den. Die ”friend-of-a-friend“-Netzwerke²⁴ sind ein Beispiel von einem möglichen Einsatz von RDF. Die zusätzlichen Funktionalitäten von OWL werden bisher nur experimentell angewandt.

Wie bereits erwähnt sind laut dem W3C wissenschaftlich alle Hürden für das Seman- tische Internet genommen. Nun muss sich die Praxis um die Umsetzung (Standards, Best-Practises) und die Lösung geschilderter Probleme kümmern. Dabei ist die Namens- gebung durch das W3C keine gute Unterstützung, da unterschiedliche Erwartungen im- pliziert werden. Auch die parallele Existenz verschiedener Ansätze zur Nutzung zugrun- de liegender Technologien (zum Beispiel RDF Notation in XML oder N3) und fehlende technologieübergreifende Beispiele (beispielsweise kombinierte Anwendung von RDF und OWL) können zu einer falschen Einschätzung der Möglichkeiten führen. Die relativ breite Nutzung von RSS zeigt aber auch, dass Nutzer und Hersteller Potential in einer besse- ren Verknüpfung von Inhalten sehen und Fortschritte in Richtung einer Vision gemacht werden.

4. Angewandte Programmierung auf Basis von Zope

In diesem Kapitel wird ein umgesetztes Projekt anhand der aufgebauten Begriffswelt beschrieben. Dieses Internetprogramm ist auch im WWW zu erreichen¹.

Um das Projekt ausführlicher betrachten zu können, wird der Applikationsserver auf dessen Basis die Anwendung realisiert wurde, vorgestellt.

4.1. Zope

Das ”Z Object Publishing Environment “ (Zope) von dem amerikanischen Unternehmen ”DigitalCreations“isteinOpenSourceApplikationsserver(engl. ”ApplicationServer“), welcher die Programmiersprache Python im WWW nutzbar macht. Für den Einsatz von Zope sprechen u.a. folgende in einer Übersicht gesammelten Aussagen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4.1.: Leistungsübersicht von Zope bezogen auf einige der Oberkategorien der Qualitätsmerkmale

Zope wird von einer immer größer werdenden Zahl von Entwicklern und Nutzern eingesetzt. Außerdem wird Zope von namhaften Firmen², sowohl im Intranet als auch für deren offizielle Internetpräsenz verwendet und wird oft als der führende Open-Source Applikationserver bezeichnet.

4.1.1. Architektur

Zope als Applikationsserver hat einen speziellen Aufbau (Architektur), der von einigen Faktoren bestimmt wird. Allgemein beschrieben sind Applikationsserver Server in einem Computernetzwerk, auf denen eine spezielle Software ausgeführt wird. Charakteristisch für Applikationsserver und daher auch für Zope ist eine Aufteilung in Schichten. Bei einer dreischichtigen Architektur ist es das Ziel, die drei Aufgaben Präsentation, Datenhaltung und Geschäftslogik voneinander zu trennen. Um dies zu erreichen sind die Bestandtei- le Internetserver, Datenbank und entsprechende Programmanweisungen ( ”Middleware“), um diese unterschiedliche Software miteinander zu verbinden, notwendig. Diese drei Be- standteile können sich dabei auf einem Rechner befinden (vgl. Bernstein u. Robertson, 2002, Seite 562). Diese allgemeine Beschreibung soll in der folgenden Abbildung auf Zope übertragen werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.1.: Zope Architektur (vgl. Latteier u. a.,2005, Seite 44)

Auf der Abbildung sind die einzelnen Bestandteile und ihre Schnittstellen zu erkennen. Zope kann direkt mit seinem eingebauten Server ( ”ZServer“)eineVielzahlvonClients bedienen. Es ist aber auch möglich diese über einen anderen vorgeschalteten Webserver³ mit Daten zu versorgen. Diese Daten können aus unterschiedlichen Datenquellen kom- men. Entweder aus der internen Objektdatenbank, externen relationalen Datenbanken (Oracle, MySQL. . . ) über entsprechende Adapter oder vom Dateisystem des Betriebssy- stems. Außerdem kann man erkennen, dass der diese Bestandteile vom Kern verwaltet Zope werden. Dieser kann über ZKlassen (engl. Zope Produkte Products“) erweitert werden.

”ZClasses“)oderZopeProdukte(engl. ” ”InZopeistalleseinObjekt.“(vgl.Watch,2002)

Objekttypen Zope stellt verschiedene Objekttypen bereit, die intern angelegt und genutzt werden können. Ein Beispiel für solch einen Objekttyp sind Filesystem Directory Views, welche Directory View Ordner des Dateisystems für die Nutzung durch Zope freigeben. Ein anderes Beispiel sind Ordnerobjekte, die Zope für die interne Organisation bereitstellt. Auch die Instru- mente, die in den nächsten beiden Abschnitten vorgestellt werden, werden als Objektty- pen bereitgestellt. Die Verwaltung dieser Objekttypen geschieht über das so genannte Object File System (OFS). Dieses Objekt-Dateisystem übernimmt das Idiom bekann- ter Dateisysteme, in denen Dateien in einem hierarchischen Baum organisiert werden.

Sogar elementare Interaktionsmöglichkeiten wie ”CopyandPaste“ummitdenObjek- ten zu arbeiten sind implementiert. Die Objekte, die in diesem Dateisystem angelegt werden, können über verschiedene Protokolle Clients veröffentlicht werden (engl. ”object publishing“). Die Objekttypen werden durch den Kern von Zope definiert. Dort werden Object Publishing aber noch weitere Funktionalitäten wie eine mächtige Art der Adressierung ( on“) zur Verfügung gestellt.

”Akquisiti- Alle von Zope verwalteten Objekte werden in der Zope Object Database (ZODB) ist ZODB eine Objektdatenbank in der alle von Zope benötigten Objekte gespeichert werden. Dies hat Vorteile bei der Entwicklung mit einer objektorientierten Sprache wie Python, da keine umfangreiche Serialisierung notwendig ist.

Die ZODB ist eine transaktionsorientierte Datenbank. Modifikationen werden in Trans- aktionen gekapselt und können gegebenenfalls zurückgefahren werden. Tritt während ei- ner Modifikation durch mehrere Transaktionen ein Konflikt auf, wird dieser erkannt und eine der Transaktionen abgebrochen und zurückgefahren. Wie bereits erwähnt können als physikalisches Speichermedium auch andere Datenbanken unterschiedlicher Konzeption genutzt werden.

Anfragen vom Client werden an den ZServer gesendet. Dieser ist ein multi-threaded Internet Server, der viele Anfragen gleichzeitig bearbeiten kann. Er unterstützt außer HTTP weitere Protokolle wie FTP, Fast CGI (FCGI)/Persistent CGI (PCGI) und Web- DAV und bietet darüber hinaus Möglichkeiten zum Statistik-Logging an. Der ZServer nimmt also Internet-Anfragen entgegen, bearbeitet sie entsprechend dem CGI-Standard und übergibt sie dann an den ZPublisher . Dieser findet anhand der Anfragen des Clients ZPublisher bzw. der Parameter vom ZServer entsprechende von Zope verwaltete Objekte. Die Me- thode ”traverse“derKlasse ”BaseRequest“⁴ istzuständigfürdasSuchendesObjektes, welches über den ZServer angefragt wurde. In dieser Methode sind neben den Anweisung- en eine URL in den Objektraum von Zope umzusetzen noch zahlreiche Sicherheitsvorkehrungen implementiert (zum Beispiel ist es notwendig Funktions-Objekten innerhalb des Quellcodes zu dokumentieren, bevor diese veröffentlicht werden dürfen - vgl. auch Seite 82). Nachdem die Ressource entsprechend der internen und externen Vorgaben ausgeführt wurde, baut ZPublisher eine gültige Antwort im gleichen Protokoll mit allen notwendigen Feldern und den Ergebnissen der Berechnungen auf. Sind Fehler beim Bearbeiten der Anfrage aufgetreten, wird eine entsprechende Fehler-Antwort generiert. Diese Antworten werden dann wieder zurück zum Client geschickt.

Die angefragte Ressource kann dabei entweder zu einer Erweiterung oder zu Zope selbst gehören. Die Definition von neuen Objekttypen wird in der Abbildung 4.1 durch die ZKlassen und Zope Produkte angedeutet. Eine solche selbstdefinierte Erweiterung wird im nächsten Abschnitt beschrieben.

4.1.2. Content Management Framework (CMF)

Speziell für dieses Projekt wurde das Content Management Framework (CMF) instal- liert. Das CMF⁵ ist auf inhaltsorientierte Internetpräsenzen ausgerichtet in denen große Teile oder alle Inhalte von Mitgliedern des Portals stammen (übersetzt nach Zope.org). Wie der Name schon andeutet handelt es sich beim CMF um so etwas wie einen ”Bau- kasten für CMS“. Denn es ist möglich mit dem CMF und mit Zope ein CMS nach den eigenen Bedürfnissen selber zu entwickeln. Je nach Wunsch kann dadurch zum Teil ho- her Programmieraufwand entstehen. Die gebräuchlichsten Anforderungen sind jedoch fertig implementiert und durch eine API oder sogar durch grafische Assistenten leicht anzupassen.

Das CMF hat einen hohen Stellenwert in der Entwicklung von Zope. Um das CMF und Zope hat sich sogar eine zweite Entwicklergemeinde verselbstständigt. Das Projekt ”Plone“⁶ stellteinfertigesCMSaufBasisvonZopebereitundergänztdasCMFneben komfortableren Installationsroutinen in erster Linie durch neu gestaltete und zugängli- chere Seitenvorlagen.

Durch die Open-Source Basis und dem ebenfalls quelloffenen CMF ist je nach Aufwand ein vollständiges Customizing möglich - es ist daher meist flexibler im Gegensatz zu anderen proprietären Lösungen. Im speziellen erweitert das CMF Zope um viele Funktionalitäten. Ein Blick in den ”CMFCore“-OrdnerinnerhalbderDistributiongenügt,um sich ein Bild von den Gewinnen für die Plattform zu machen.

Im Ordner CMFCore werden die grundlegenden Datentypen und Anweisungen definiert. Diese allgemeinen Bestandteile werden in verschiedenen Modulen wiederverwendet. Die spezielleren Teile, die illustrieren wie diese allgemeinen Bestandteile angepasst, erweitert und genutzt werden können, befinden sich im Ordner Inhaltstypen werden Inhaltstypen (engl. ”CMFDefault“.Indiesem content-types“) definiert, die innerhalb von CMF-Portalen ” genutzt werden können. Beispielhaft zu nennen sind die Typen ionItem“, ”Document“, ”Discuss- ”Favorite“und ”File“, welche das Anlegen von Dokumenten ,Diskussionen, Favoriten und Dateien erlauben. Diese Inhaltstypen sind beispielhafte Implementierung- en von den allgemeinen Bestandteilen des Frameworks. Denn alle diese Inhaltstypen leiten sich von der Klasse ”PortalContent“ab,welcheimModul ”PortalContent.py“des Paketes CMFCore elementare Definitionen für abstrakte Inhaltstypen bereitstellt. Der Name dieser Klasse deutet schon darauf hin, dass eigene Inhaltstypen definiert werden können. Diese Inhaltstypen können schließlich innerhalb eines Portals von Nutzern an- gelegt werden. Die Inhaltstypen können sich erheblich in Form und Anzahl von den bisher bekannten Objekttypen, die lediglich innerhalb von Zope angelegt werden können unterscheiden.

Abbildung in dieser Leseprobe nicht enthalten

(a) Liste anlegbarer Objekttypen innerhalb von Zope

Abbildung in dieser Leseprobe nicht enthalten

(b) Anlegbare Inhaltstypen innerhalb von ei- nem CMF-Portal

Abbildung 4.2.: Weboberflächen der gleichen Zope Installation

”DCWorkflow“stellteineweiterewichtigeFunktionalitätfürZopezurVerfügung.Dort wird ein Workflow angelegt dem ein Inhaltstyp zugewiesen werden kann. Ein Workflow besteht aus Stati und Übergängen zwischen den Stati. Der voreingestellte Workflow realisiert einen Arbeitsablauf der dem im Kapitel 2.2.4 ähnlich ist.

”CMFCalendar“und ”CMFTopic“sindBeispielefürumfangreichereErweiterungen durch Dritte.

Neben den Inhaltstypen, die vom CMF verwaltet werden können, stellt es vordefinierte Werkzeuge (engl. Tool ”tools“)zurVerfügung,welchedemPortalfunktionaleErweiterungen beinhalten und auch selber definiert werden können. Auf der Ebene des Softwareent- wurfes kann man diese Tools als Entwurfsmuster des Frameworks bezeichnen. Entwurfsmuster ”EinEnt- wurfsmuster (engl. ,design pattern‘) beschreibt eine in der Praxis erfolgreiche, generische Lösung für ein mehr oder weniger häufig auftretendes, wiederkehrendes Entwurfsproblem und stellt damit eine wiederverwendbare Vorlage zur Problemlösung dar“ (Wikipedia, 2005a). Einige vom CMF bereitgestellten Werkzeuge sollen in der folgenden Übersicht kurz erklärt werden:

portal catalog Um die genutzten Inhaltstypen systemweit auffindbar machen zu können, nutzt das CMF, die in der Dublin Core Spezifikation festgehaltenen Meta-Daten. Dadurch ist die Grundlage für ein Indizieren und Katalogisieren des gesamten Inhalts durch das Tool gegeben.

portal types Mit diesem Werkzeug werden Inhaltstypen registriert und verwaltet.

portal workflow regelt die Workflows, die für das jeweilige Portal und die darin enthal- tenen Inhaltstypen gelten sollen.

portal skins organisiert die Darstellung über eine Verwaltung von anzeigespezifischen Dateien.

Diese anzeigespezifischen Dateien sind meist spezielle wiederverwendbare Vorlagen, welche im nächsten Abschnitt vorgestellt werden.

4.1.3. Zope Page Templates (ZPT)

”ZopeSeitenvorlagen“sindeinWerkzeug,umInternetseitendynamischzuerstellen. Durch einfache Programmanweisungen innerhalb der Auszeichnungen können Seitenvor- Vorlagen lagen oder kurz Vorlagen (engl. templates“) für die Generation von zum Beispiel dem ” HTML der Internetseiten definiert werden. Diese Vorgehensweise ist von anderen Internetprogrammiersprachen (PHP, ASP, JSP. . . ) bekannt und weit verbreitet. Durch solche Template-Systeme können bessere Wartbarkeit und eine Trennung von Logik und Präsentation erreicht werden. Die Syntax der ZPT unterscheidet sich von der anderer Ansätze, da sowohl die Vorlage selber als auch die generierte Ausgabe valides XHTML sein kann. Das folgende Beispiel soll dies veranschaulichen:

Abbildung in dieser Leseprobe nicht enthalten

Dieser mögliche Inhalt einer ZPT begrüßt den angemeldeten Nutzer mit seinem Vor- namen. Dies wird durch das zusätzliche Attribut replace mit dem XML-Namensraum TAL tal erreicht. TAL steht für Template Attribute Language“ und ist ein Teil der von ” Zope bereitgestellten Funktionalität für die Erstellung dynamischer Internetseiten. Diese Anweisung resultiert in einer Abfrage der durch den Wert des Attributes angegebenen Variablen. Durch das replace Attribut wird das gesamte <span/> Tag durch den Inhalt dieser Variable ersetzt.

Abbildung in dieser Leseprobe nicht enthalten

Durch die Ähnlichkeit der Eingabe und Ausgabe harmoniert dieser Ansatz gut mit WYSIWYG Editoren wie zum Beispiel ”Dreamweaver“.AußerdemunterstützenZPT die Trennung von Logik und Darstellung. Aufgrund dieser Richtlinien können die Page Templates die Zusammenarbeit zwischen Designern und Programmierern vereinfachen (vgl. Zope.org, 2005).

Bei der Betrachtung des ZPT-Beispieles wurde noch nicht auf die vordefinierte Variable oder die Notation von dieser eingegangen. Trotz der Ähnlichkeit sind ZPT keine HTML-Dokumenten, sie sind Objekte, die durch Zope verwaltet werden. Diese Objekte haben ihren eigenen Namensraum der von Zope verwaltet wird. Um dies zu demonstrieren sollen ZPT ohne Zope verwendet werden. Dies geschieht über die Nutzung eines Python-Paketes, welches über das Internet⁷ zu beziehen ist.

Mit Hilfe dieses Paketes wird eine Klasse definiert aus welcher die ZPT-Objekte erzeugt werden. Zu lange Zeilen können in Python mit einem ”Backslash“umgebrochenwerden.

Abbildung in dieser Leseprobe nicht enthalten

Um Variablen an die Page Template zu übergeben, muss diese eine Methode definie- ren, welche Variablen in den Objekten speichern kann. Diese Methode ”KontextSetzen“ speichert übergebene Variablen in das Attribut context. Dieses wird beim Ausführen des ZPT-Objektes an vordefinieren Variablen angehängt. Genau wie das Attribut sind die vordefinierten Variablen in einem Dictionary gespeichert. Dieser Python Datentyp Python- organisiert Werte wie in einem Worterbuch und ist in anderen Programmiersprachen Dictionary auch als ”Hashtable“ bekannt. Werte eines Dictionaries können wiederum Dictionaries sein. Durch diese Hierarchie erklärt sich auch die Pfad-Notation des ersten Beispieles.

Die gewünschten Variablen befinden sich nun in dem Namensraum der Seitenvorlage. Die ZPT stellt einige Möglichkeiten zur Verfügung, wie mit diesen Variablen gearbeitet werden kann, um Auszeichnungen von Internetseiten zu generieren.

So können zum Beispiel Anweisungen wie Bedingungen und Schleifen, die aus Programmiersprachen bekannt sind, verwendet werden. Diese können mit der im Beispiel verwendeten TAL Notation genutzt werden. Es ist auch möglich Python-Anweisungen innerhalb der TAL-Ausdrücke zu verwenden. Außerdem können ”Macros“und ”Slots“ durch die Verwendung von Macro Expansion Tag Attribute Language (METAL) defi- METAL niert werden. Macros sind wiederverwendbare Teile einer Seitenvorlage wie zum Bei- spiel eine Navigation. Macros (dt. Macro ”Makros“)könnenmitallenzurVerfügungstehen- den Anweisungsmöglichkeiten erstellt werden und können damit beispielsweise wieder verwendbare Navigationen definieren, welche sich entsprechend der Anweisungen auch verändern können. Macros werden oft in für diese angelegte Slots (dt. Slot ”Einschübe“)plat- ziert. Diese können in Seitenvorlagen eingearbeitet werden und verschiedene Inhalte bis hinzu Macros enthalten. Auf diese Weise ist es möglich übersichtlichere und besser zu wartende Seitenvorlagen zu erstellen. Auf diese Weise ist auch eine Modularisierung von Vorlagen möglich. Daher können durchaus Vorlagen existieren in denen wenig Auszeichnung enthalten ist und andere Vorlagen ”eigene“ ”nur“ineinerspeziellenArtundWeise arrangiert werden. Die neuen Begriffe sollen durch ein Beispiel auch praktisch veranschaulicht werden:

Abbildung in dieser Leseprobe nicht enthalten

In der ersten Zeile wird durch die metal Anweisung ein Macro einer Seitenvorlage entsprechend der Pfadangabe bestimmt, welches als Grundlage für dieses Beispiel dient. Die vierte Zeile füllt den Slot main, der innerhalb des genutzten Macros definiert wur- de mit den teilweise dynamisch generierten Inhalten des div Bereiches. Außerdem wird durch die tal Anweisung der Wert der vordefinierten Variablen wurzel in die Varia- ble knoten geschrieben. In der Zeile sechs werden Attribute dynamisch durch Python Ausdrücke, einmal durch Zeichenketten-Konkatenation und das zweite Mal durch einen Aufruf eines Funktionsobjektes, welches in dem Python-Dictionary der Seitenvorlage gespeichert ist, definiert. Zeile acht bindet den Inhalt eines Macros aus einer anderen Seitenvorlage (OutlineTemplate) ein und die Anweisung in Zeile neun veranlasst, dass der div Bereich dabei nicht mit ausgegeben wird. Die restlichen Zeilen müssen angege- ben werden, damit die ZPT genutzt werden kann. ZPT zwingen den Entwickler also zu einer syntaktisch korrekten Auszeichnung.

Neben den ZPT können Internetseiten auch mit der Document Template Markup Language (DTML) von Zope erstellt werden. DTML gliedert sich aber nicht in die Auszeichnungen ein und erinnert von der Syntax her an PHP. Bis auf wenige Ausnahmen⁸ können alle Aufgaben mit ZPT gelöst werden. DTML wird daher und hauptsächlich aus Gründen der Abwärtskompatibilität weiterhin von Zope unterstützt.

4.1.4. Erweitern von Zope

Viele Aufgaben können mit Zope alleine durch interne Anpassungen (engl. ”customi- zing“) des CMF oder durch Änderungen an den ZPT gelöst werden. Falls jedoch Auf- gaben gelöst werden müssen, welche eine Erweiterung der Funktionalität von Zope zur Folge haben, muss dafür nicht der Quellcode von Zope bearbeitet werden. Entwicklern werden Möglichkeiten gegeben Zope zu erweitern ohne dessen Quellcode zu ändern.

Zope kann auf verschiedene Arten erweitert werden. Auf der Abbildung 4.1 wurden bereits zwei Möglichkeiten vorgestellt. Mit den ZKlassen können neue Objekttypen über das ZMI ”zusammengeklickt“werden.ZopeProduktewerdendagegenimDateisystem entwickelt und können bei der Definition der Objekttypen alle Vorteile nutzen, die Python bietet.

Diese Arbeit behandelt nur die Produktentwicklung für Zope und/oder das CMF. Diese ist als schwierig bekannt, was wahrscheinlich daran liegt, dass es wenig Dokumen- tation gibt. Um in die Produktentwicklung einzusteigen, ist man oft dazu gezwungen die Funktionsweise über frei verfügbare Produkte⁹ zu lernen. Dieses Kapitel stellt also auch eine, von den seltenen und oft unvollständigen, deutschen Einführungen in diese Art der Internetprogrammierung dar.

Durch Produkte werden neue, massgeschneiderte Objekte definiert, die innerhalb des Objekt-Dateisystems von Zope angelegt und genutzt werden können. Betreiber eines Zope-Servers können fertige Produkte installieren und so auf eine umfangreiche Liste fertig implementierter Lösungen zurückgreifen¹⁰. Installierte Produkte können über eine Liste ausgewählt werden, die auf der Abbildung 4.2(a) zu sehen ist. Bei einer Auswahl wird dann eine Instanz des definierten Objekttyps angelegt.

Programmiertechnisch gesehen ist ein Zope Produkt ein Python Paket in dem Python Module definiert sind. In mindestens einem Modul muss mindestens eine Klasse definiert werden. Während der Laufzeit erstellt Zope dann Objekte aus den definierten Klassen entsprechend den Anweisungen des Produktes. Durch den quelloffenen Ansatz von Zope kann spezifische Funktionalität von bestehenden Basisklassen bezogen werden, indem sich Klassen des Produktes von diesen Basisklassen ableiten. Produktklassen können bei- spielsweise von der Klasse ”Persistent“oder ”SimpleItem“erben.Erstereerlaubteine persistente Speicherung in der ZODB und ”SimpleItem“ermöglichtunteranderemdie Nutzung von Akquisition und des Sicherheitssystems. Von diesen beiden Klassen gleich- zeitig zu erben wäre aber nicht sinnvoll, da sich SimpleItem schon von Persistent ableitet.

Ein Produkt wird installiert, indem es an einen von der jeweiligen Installation abhängi- gen Platz innerhalb des Zope Verzeichnisses¹¹ bewegt wird. Das Produkt selber hat eine interne Struktur. In dem Ordner mit dem Namen des Produktes können sich folgende Elemente befinden:

- Initialisierungsanweisungen ( init .py)
- die Python Klassen
- Präsentationsdateien (ZPT oder DTML)
- Hilfedateien
- refresh.txt
- weitere Pakete

Durch einen Neustart stellt Zope das neue Produkt systemweit zur Verfügung. Optio- nal ist auch ein Auffrischen während der Laufzeit möglich. Dies kann durch ein Anlegen einer leeren Datei ”refresh.txt“erreichtwerden.BesonderswährendderProduktentwick- lung muss ein Produkt oft neu geladen werden, da Änderungen am Quellcode vorgenommen werden. Eine solche schnelle Art der Aktualisierung ist daher zum Testen sinnvoll.

Im folgenden soll die Produktentwicklung beispielhaft an einsetzbarem Code besprochen werden. Für ein einfaches Produkt werden lediglich zwei Dateien benötigt. In der einen wird die Klasse definiert (BeispielProdukt.py) und in der anderen werden Initialisierungsanweisungen gegeben ( init .py). Außerdem macht letztere Datei den Ordner zu einem Python-Paket und so durch Zope nutzbar.

Abbildung in dieser Leseprobe nicht enthalten

Die Datei ” init .py“ regelt das Initialisieren des Produktes.

Abbildung in dieser Leseprobe nicht enthalten

Diese beiden Dateien definieren ein einfaches Zope-Produkt. Man könnte es nun durch Platzieren im ”Products“OrdnerinstallierenundeswäredannmöglichInstanzendes Objekttyps über das ZMI anzulegen. Es ist aber noch nicht möglich Instanzen dieser Klasse im CMF zu nutzen. Um dieses Produkt mit dem CMF interoperieren lassen zu können, muss das Produkt einen zusätzlichen Inhaltstyp für das CMF definieren¹².

Das CMF benötigt bestimmte Informationen in einem bestimmten Format, um ein Produkt als neuen Inhaltstypen einsetzen zu können. Diese sogenannten Factory Type Information (FTI) kann man sich als Schablone für Inhaltstypen vorstellen¹³. Die FTI FTI können unter anderem den Namen des neuen Inhaltstypen, den Typ des zugehörigen Zope-Produktes, den Produktnamen, die Fabrikfunktion des Produktes¹⁴, die Anfangs- seite im Unterschied zum Zope-Produkt und Aktionen enthalten. Diese actions werden Aktionen bei einer Anzeige des Portals als Links in bestimmten Bereichen dargestellt. Das CMF un- terscheidet drei große Bereiche und stellt diese mittels vordefinierten Macros innerhalb der ZPT zur Verfügung. Innerhalb dieser Macros werden noch weitere Unterscheidun- gen getroffen, die die Seitenbetreiber übernehmen oder anpassen können. Es ist daher darauf zu achten, dass auch entsprechende Methoden existieren, die durch eine Aktion aufgerufen werden können.

top bar Portalweite Interaktionsmöglichkeiten wie die portalweite Suche, Auswahl neu erstellter Objekte und ein Überblick der Mitglieder werden hier bereitgestellt.

user menu bar Hier werden nutzerspezifische Verweise zur Anmeldung oder Registrie- rung bei nicht angemeldetem Nutzer oder zum privaten Ordner, den Einstellungen oder zur Speicherung von Favoriten bei identifizierten Nutzer angezeigt.

actions box Objektspezifische, workflow-spezifische (z.b. Veröffentlichen), ordner- spezifische und systemweite Links können hier angezeigt werden. Objektspezifische werden innerhalb des Produktes definiert. Ordner-spezifische Verweise wie Ordnerinhalt oder lokale Rollen werden von jedem ordnerähnlichen Objekt bereitgestellt. Ein Beispiel für einen systemweiten Verweis ist die Undo-Funktion.

Es sind aber noch mehr Zusätze für eine Nutzung in Kombination mit dem CMF notwendig. Um die vom CMF zusätzlich bereitgestellten Funktionalitäten nutzen zu können, ist eine Ableitung von bereitgestellten Klassen, die diese implementieren sinnvoll und praktisch. Das Ableiten von ”PortalContent“stelltdemeigenenInhaltstypmehrFunk- tionalitäten zur Verfügung als SimpleItem, da PortalContent selber von SimpleItem erbt. Von PortalContent abgeleitete Klassen müssen das in dem Ordner beschriebene Interface von ”CMFCore/interfaces“ ”DublinCore.py“ implementieren. DiesgeschiehtdurchAbleiten ”DefaultDublinCoreImpl“,welchesdemInhaltstypeinekompletteMeta-DatenVer- waltung gemäß dem Standard von Dublin Core zur Verfügung stellt.

Um weitere nützliche Funktionalitäten nutzen zu können, kann die API des CMF oder die der Werkzeuge des CMF genutzt werden. Die Methode SearchableText überschreibt die Methode aus PortalContent und wird durch portal catalog für die Indizierung ge- nutzt. Dadurch werden die angegebenen Variableninhalte der Instanzen durchsuchbar.

Der Quelltext dieser Modifikationen des Objekttyps sind im Anhang aufgeführt. Durch diese Erweiterungen an den beiden Dateien des ersten Beispiels kann das Zope-Produkt als neuer Inhaltstyp innerhalb des CMF genutzt werden. Um das Anlegen von diesem neuen Typ zu ermöglichen, muss dieser noch beim portal types Tool registriert werden. Durch die angegebene FTI kann der neue Inhaltstyp aus einer Liste ausgewählt werden und so semi-automatisch angemeldet werden.

Eine Methode um Zope, während der Laufzeit, zu erweitern ist das sogenannte MonkeyPatching. Es sei hier aber lediglich auf weiterführende Quellen verwiesen¹⁵.

4.2. Das Projekt

Das Internet und seine Dienstleistungen erweitern den körperlichen Aktionsradius des Menschen beträchtlich und es wird eine weitreichende gedankliche Mobilität erreicht. Es spielt fast keine Rolle mehr, ob der Mensch, der einen Gedanken über das WWW kommuniziert, sich gerade in Australien aufhält oder in Deutschland. Der globale Zu- griff auf Informationen lässt Ländergrenzen fast verschwinden. Das Internet ist derzeit das idealste Medium für einen schnellen, globalen und (halb)öffentlichen Austausch von Gedanken.

Auf dieser Auffassung vom WWW basiert das umgesetzte Projekt. Es soll Menschen helfen Gedanken, Ideen, Konzepte oder im allgemeinen Inhalte auszutauschen und es den Nutzern außerdem ermöglichen zusammen an diesen zu arbeiten. Durch ein bestimm- tes Angebot an Werkzeugen soll eine interdisziplinäre Kommunikationsplattform mit Möglichkeiten zur arbeitsteiligen Erstellung von Inhalten geschaffen werden. Die Inhalte sollen durch Werkzeuge abgebildet und innerhalb eines Portals verwaltet werden können. Das Konzept für die Erfassung der Inhalte sollte allgemein genug sein, um möglichst viele Arbeitsbereiche, auch im Bereich der Kultur, abdecken zu können. Vor diesem Hinter- grund spielt das Portal die Rolle eines Interpreten, da es zwischen Autoren und deren Rezipienten vermittelt. Aber auch weitere Funktionalitäten wie Durchsuchbarkeit und Rechteverwaltung soll dieses bereitstellen, wodurch eine sichere Verknüpfung aller ver- walteten Inhalte erreicht werden soll. Die Bedienung und Funktionalität der Werkzeuge sollte sich an der von Desktop-Anwendungen anlehnen und auch eine Interoperabilität mit diesen anbieten. Innerhalb dieser Arbeit wird auf die beschriebene Plattform mit myideas.de dem Namen myideas.de verwiesen. Innerhalb dieses Portals stehen verschiedene Werk- zeuge zur Verfügung. Eines dieser Werkzeuge soll durch eine neuartige Kombination verschiedener bestehender Anwendungsansätze die Kollaboration und das Teilen von In- halten erleichtern. Dieses Werkzeug stellt also einen elementaren Teil der Plattform dar.

Daher beschäftigt sich die folgende Erläuterung der Umsetzung zu großen Teilen mit ZOL diesem Werkzeug. Dieses Werkzeug wird innerhalb dieser Arbeit mit dem Namen ZOL bezeichnet.

Um ein genaueres Verständnis der Betrachtungen dieses Kapitels zu erhalten, emp- fiehlt es sich das erstellte Internetprogramm unter der Adresse http://myideas.de anzuschauen. Aufgrund der internationalen Ausrichtung der Plattform sind dort alle Texte auf Englisch. Ergänzend kann auch das Video auf der beiliegenden CD angeschaut werden in dem wichtige Merkmale erläutert werden.

4.2.1. Entwurf

Nach der eben vorgenommenen allgemeinen Beschreibung des Projektes und der Analyse vorhandener Technologien im Kapitel 4.1 soll nun gemäß Schwarze (1995) die Umsetzung erfolgen. Diese soll mit dem Entwurf beginnen und mit einer Betrachtung der Implementierung im Abschnitt 4.3 fortgeführt werden.

Gemäß der Vorgaben aus der Projektbeschreibung ist ein Einsatz von Zope in Kom- bination mit dem CMF sinnvoll, da ein Großteil der Anforderungen schon von diesen bereitgestellt werden und diese somit nicht implementiert werden müssten. Durch das CMF steht ein portalorientiertes Internetprogramm mit Möglichkeiten der Speicherung von Inhaltstypen zur Verfügung, welche zum Festhalten von Inhalten genutzt werden können (myideas.de). Das CMF ist außerdem um weitere Inhaltstypen erweiterbar und eine Integration eines weiteren maßgeschneiderten Werkzeuges ist somit möglich und vorgesehen (ZOL).

Im folgenden sollen die benötigten Funktionalitäten unter Berücksichtigung der Vorgaben, die durch die Nutzung dieser Softwareplattform entstehen, modelliert werden. Im Allgemeinen wird das Framework CMF durch die Anforderungen dieses Projektes spezialisiert, indem anwendungsspezifische Unterklassen aus den abstrakten Klassen des Frameworks gebildet werden.

Als ein erster Schritt zu dieser Spezialisierung sollen einige beschriebene Funktiona- litäten des Projektes in einem ”Use-Case“-Diagrammfestgehaltenwerden.Diese ”Anwen- dungsfälle“ werden oft während des Entwicklungsprozesses angewendet und beschreiben einen Ablauf wie zum Beispiel einen Geschäftsprozess. Der Anwendungsfall beschreibt den Prozess in einer abstrakten Weise und nennt keine umsetzungsrelevanten Details.

Abbildung in dieser Leseprobe nicht enthalten

Dieses allgemein gehaltene Diagramm stellt wichtige Gebrauchsfälle eines Nutzers der Plattform dar. Die Nutzung von ZOL innerhalb des Portals bedarf einer näheren Erläut- erung. Deswegen wurde dieser Use-Case lediglich als ”Black-Box“eingefügtundwirdin einem anderen Use-Case Diagramm näher beschrieben. Man kann dadurch schon erken- nen, dass solche Funktionalitäten später bei der Umsetzung in ein eigenes Softwarepaket ausgelagert werden sollten. Die Nutzung von ZOL ist von den jeweiligen Situationen abhängig. EinenÜberblick über wichtige Nutzungsarten bringt das folgende Use-Case Diagramm, welches auch die unterschiedlichen Rechte der Akteure berücksichtigt¹⁶.

Abbildung in dieser Leseprobe nicht enthalten

Dabei werden aus Gründen derÜbersicht umfangreichere Anwendungsfälle ebenfalls nicht näher dargestellt (beispielsweise Outline bearbeiten)¹⁷. Zu erkennen sind aber die unterschiedlichen Zugriffsmöglichkeiten der Nutzer. Ein Outline bearbeiten dürfen nur Nutzer, welche auch Besitzer von diesem sind. Ein Besitzer kann weitere durch lokale Rollen anlegen und dadurch andere Mitglieder zu Besitzern machen. Besitzer können außerdem den Workflow Status ändern und so das Outline für Gäste sichtbar machen, damit diese in eingeschränkter Art mit diesen interagieren können, indem sie zum Beispiel das Outline kommentieren. Ein Versionsmanagement könnte in einem erweiterten Konzept eine wichtige Rolle spielen.

Abbildung in dieser Leseprobe nicht enthalten

Dieses Use-Case schildert eine erhebliche Erweiterung des Werkzeuges in seiner kolla- borativen Funktionalität, da durch die Speicherung von Zusätzen anderer Mitglieder als Version ein leichterer und lebhafterer Austausch zwischen den Mitgliedern der Plattform möglich ist. Das Versionsmanagement soll dabei sowohl Versionen von Knoten als auch von Knotenhierarchien bzw. Unter-Outlines verwalten können und sogar verschachtelte Versionen ermöglichen.

Nach diesem allgemeinen Entwurf des Werkzeuges ZOL, soll nun das umgebende portalorientierte Internetprogramm betrachtet werden. Diese Plattform muss für dieses Projekt einige Entwurfsmuster des CMF spezialisieren.

Durch Zope als Basis steht dem Portal die Sicherheitsfunktionalität des Applikations- servers zur Verfügung. Diese basiert auf verschiedene Rollen, die ein Nutzer einnehmen kann und verschiedenen Rechten, die den Rollen zugeordnet werden können. Das benötig- te Rollensystem des Portals kann durch Vererbung folgendermaßen dargestellt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.3.: Die Akteure des Portals (oben) bzw. Rollen von Zope und deren Rechte (unten)

Im unteren Screenshot des Sicherheitsmanagements von Zope kann man beispielhaft benötigte Rechte für bestimmte Funktionalitäten und deren Zuordnungen zu den Rollen erkennen. Durch die Möglichkeit Rechte durch Auswählen der Checkboxen innerhalb von Zopes Sicherheitsmanagement hinzuzufügen, ist es theoretisch auch möglich der Rolle ”Gast“mehrRechtezuzuweisenalsderRolle ”Mitglied“.DieRechtederRollenbasieren daher nicht auf einer Vererbung.

Außerdem wird das Portal einen speziellen Workflow benötigen, um seine Inhaltstypen zu kontrollieren. Das CMF bietet die Möglichkeit Workflows zu definieren und stellt einen Voreingestellten zur Verfügung. Dieser existierende Workflow muss angepasst werden, um den Bedürfnissen des Portals zu genügen. Der gewünschte Workflow des Portals lässt sich über die Visualisierung in Statusdiagrammen wie in der Abbildung 4.4 darstellen.

Dieser einfache Workflow erlaubt die Unterscheidung zwischen veröffentlichten und pri- vaten Inhalten, deren Status vom Besitzer des Inhaltstyps gesteuert werden kann. Das CMF bietet in dem Tool portal workflow entsprechende Konfigurationsmöglichkeiten an, die für die Nutzung eines solchen Workflows genutzt werden müssen. Da diese Plattform einen einfachen Austausch ermöglichen möchte, ist daher auch nur ein einfacher Work- flow notwendig. Mit dem Tool können aber weitaus kompliziertere Geschäftsprozesse umgesetzt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.4.: Umsetzung eines Statusdiagramms im portal workflow Tool

Das portalorientierte Internetprogramm des Projektes muss noch andere Entwurfsmuster spezialisieren. Zum Beispiel muss die Darstellung des Portals durch Änderung der ZPT angepasst werden. Aber auch die Werkzeuge, die die Inhalte der Plattform festhalten, könnten zum Teil angepasst werden.

Die vorgestellten Entwürfe sind genau auf diese oder in ähnlicher Form in das umgesetzte Projekt eingeflossen.

4.2.2. Bestandteile

Outliner Das visuelle und funktionale Gerüst von ZOL wird durch einen Outliner bereitgestellt.

Diese Art von Programmen ermöglichen es Informationen in hierarchischen Gliederungen (engl. Knoten ”outlines“)zustrukturieren.DasOutlinebestehtauseinzelnenGliederungspunkt- en bzw. Knoten, die in Hierarchien wie Unterknoten, Geschwister oder Oberknoten mit- einander in Beziehung stehen können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.5.: Outliner des Webpublishing-Programms

Durch diese Beziehungen der Knoten untereinander, entstehen aufgrund der seman- tischen Interpretation des Menschen neue Informationen über die Informationen - also Meta-Daten. Outliner werden oft in konzeptionellen Arbeitsbereichen zum Beispiel im Projektmanagement als Werkzeug eingesetzt. Outliner unterschiedlicher Lizensierungen sind für verschiedene Plattformen erhältlich¹⁸.

Die zweite Komponente bildet die Wiki-Funktionalität. Wikis sind Werkzeuge, die zur Wiki kollaborativen Inhaltserstellung genutzt werden. Diese Internetprogramme stellen Seiten- sammlungen zur Verfügung, die von Nutzern nicht nur gelesen, sondern auch geändert werden können. Wikis ähneln damit CMS. Die Inhalte eines Wikis werden in einer spe- ziellen Syntax verfasst, welche auch dazu genutzt werden kann die Texte zu formatieren.

Diese Wiki-Syntax ist nicht so umfangreich wie HTML und daher einfacher zu gebrau- chen¹⁹. Der Name stammt von dem hawaiianischen Wort für ”schnell“.

Jeder Knoten eines Outlines ist mit einem eigenen Wiki ausgestattet. Es ist also an einen Knoten gebunden²⁰. Ein einziges Outline stellt somit schon eine hierarchisch geord-nete Seitensammlung zur Verfügung, wenn man die Texte der Knoten als Seitennamen interpretiert.

Der dritte Baustein ist ein Versionsmanagement , welches die Knoten des Outlines Versions- wiederum erweitert. Zu jedem Knoten konnen dadurch beliebig viele parallele Versionen management existieren. Wenn ein Knoten Unterknoten beinhaltet, werden für diese ebenfalls Versio- nen angelegt, welche dann wiederum die gleiche Funktionalität zur Verfügung stellen. Es können also auch verschachtelte Versionen erzeugt werden.

Umgeben wird dieses aus den drei Komponenten aufgebaute Werkzeug von dem beschriebenen portalorientierten Internetprogramm, welches dem Nutzer einen zentralen Einstiegspunkt für die Nutzung von ZOL und den anderen Werkzeugen bereitstellt. Durch die Plattform können Inhalte ähnlich wie in einem Dateisystem verwaltet werden. Die Verwaltung ist nicht auf das Anlegen und Löschen von Dokumenten begrenzt, sondern schließt das Teilen, die Interoperation mit Desktop-Programmen und die kollaborative Bearbeitung und andere Möglichkeiten mitein.

Trotz der Erreichbarkeit über das Internet sollen an dieser Stelle Screenshots des Projektes abgebildet werden, um sich auch ohne Medienbruch visuell ein Bild dieses Werkzeuges in seiner Umgebung machen zu können.

Auf der ersten Abbildung der nächsten Seite ist der dreigeteilte Aufbau des Portals zu erkennen. Die linke Spalte beeinhaltet eine portalübergreifende Navigationsbox und in der Mitte befindet sich die Darstellung des aktuell ausgewählten Objektes. In diesem Falle ist es das ZOL-Werkzeug. Die Instanzen des ZOL-Werkzeug werden zukünftig als ”Outlines“ bezeichnet. Die rechte SpalteenthälteineobjektspezifischeNavigationsbox, welche Interaktionsmöglichkeiten wie das Exportieren oder Kommentieren des Outlines zur Verfügung stellt.

Die nächste Abbildung zeigt das Outline detaillierter und bezeichnet wichtige Bestandteile. Zur näheren Erläuterung sei gesagt, dass die Werkzeuge-Box knotenspezifisch ist und die Reiternavigation das gesamte Outline steuert. Die knotenspezifische Reiternavigation des Knotens ”2 .Punkt“rührtvondemVersionsmanagementher,dadieser Knoten eine Version mit dem Namen ”eineandereVersion“hat.

Abbildung in dieser Leseprobe nicht enthalten

Die dritte Abbildung zeigte einen Knoten und seine Werkzeuge-Box genauer. Die dort abgebildeten Symbole haben folgende Bedeutung.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4.2.: Position und Beschreibung der Knotenfunktionen (von links nach rechts)

4.3. Umsetzung

Die vorgestellten Technologien von Zope ermöglichen eine schnelle Umsetzung vieler Vorhaben, da auf grundlegende Funktionalitäten zurückgegriffen werden kann. In diesem Abschnitt werden die beschriebenen Möglichkeiten von Zope anhand der Anforderungen des Projektes erläutert. Dieser Abschnitt setzt damit den Entwurf (4.2.1) fort und gibt einen detaillierten Überblick über die Funktionalitäten von myideas.de und ZOL. Um einen ersten Einblick in die software-technische Umsetzung des Projektes zu erlangen, sind im folgenden die Ordnerstruktur und viele Module beschrieben.

init .py Enthält Initialisierungsanweisungen für Zope und das CMF. Außerdem macht diese Datei den Ordner zu dem Python-Paket ”ZOL“(69 Zeilen).

hilfe Ordner, welcher Hilfedateien enthält. Diese werden über die intern abrufbare Zope- Hilfe angezeigt.

inhalt.py Enthält die Klasse für die Inhaltsfunktionalität der Knoten (zum Beispiel Text des Knotens und Einbindung des Wikis) (46 Zeilen).

knoten.py Enthält Klassen, welche unterschiedliche Knotenarten definieren (320 Zeilen).

outline.py Enthält die Outline-Klasse, welche die Knoten verwaltet (417 Zeilen).

refresh.txt Für die Aktualisierung des Produktes

test.opml Eine OPML Beispieldatei

tests.py Enthält alle Unit-Tests (151 Zeilen).

utils Ordner mit Werkzeugen

init .py Initialisierungsmodul, welches den Ordner zu einem Python-Paket macht.

bilder Enthält von ZOL genutzte Bilder. Diese werden durch ein DirectoryView- Objekt und durch Registrieren beim portal skins Tool für Zope zugänglich.

handler.py Stellt einen SAX OPML Handler für den Import von Outlines bereit (54 Zeilen).

js css Ordner für JavaScript- und CSS-Dateien

init.js Initialisiert für AJAX notwendige Variablen und stellt zwei Funktio- nen für die Darstellung und die Interaktion mit der Werkzeuge-Box zur Verfügung (60 Zeilen).

ol lib.js Stellt allgemein gehaltene JavaScript Funktionen wie zum Beispiel das Ermitteln von Koordinaten und Objekten und die Abwicklung der asynchronen Kommunikation zur Verfügung (166 Zeilen).

ol.js Definiert die AJAX-Funktionalitäten und die aufgerufenen Callback- Funktionen (209 Zeilen).

style-layout.css Enthält die Stylesheets für myideas.de.

style.css Enthält die Stylesheets für ZOL.

konstanten.py In dieser Datei werden systemweit genutzte Konstanten definiert.

listquote.py Modul, welches zum Verarbeiten von Comma Seperated Values (CSV) benötigt wird.

ol utils.py Modul, welches verschiedene Zusatzfunktionen enthält (110 Zeilen).

pwyky.py Ein Wiki, welches mit Python programmiert wurde.

XMLDOM.py Enthält eine experimentelle und nicht genutzte DOM- Implementierung der Funktionalitäten des SAX Handlers.

version.py Stellt den Knoten die Versionsfunktionalitäten zur Verfügung (79 Zeilen).

ZPT Ordner, der Seitenvorlagen für die Darstellung enthält (ca. 100 Kilobytes). Enthält aber auch die Datei ”PageTemplates.py“,welchedieVorlagenfürdieKnotenklas- sen nutzbar macht (68 Zeilen).

Dieses Projekt bediente sich bei der Erstellung einiger Methoden des Extreme Pro- grammings, da eine Integration der einzelnen Komponenten zu einem lauffähigen Ge- samtsystem in kurzen Zeitabständen durchgeführt wurde. Zusätzlich zu den schon auf Seite 17 genannten Charakteristiken dieses Ansatzes fand außerdem eine ständige Re- faktorisierung bis hin zu einem Architekturwechsel²¹ statt. Da das XP ein teamorien- tierter Ansatz ist und dieses Projekt nur von einer Person umgesetzt wurde, konnten wichtige Prinzipien nicht umgesetzt werden. Außerdem wurde nicht Testgetrieben ent- wickelt. Die integrierten Unit-Tests stellen eine Rückversicherung dar, dass überprüfte Funktionalitäten des Gesamtsystems bei neuen Implementierungen aber auch bei der Refaktorisierung noch oder nicht mehr funktionieren. Der Quellcode dieses Projektes wurde mithilfe des Versionsmanagementsystems ”Subversion“(Nachfolgerdes ”Concur- rent Version System“ (CVS)) verwaltet und befindet sich auf der beiliegenden CD.

4.3.1. Grundlegende Konzepte

Die grundlegende Implementierung orientiert sich an den Empfehlungen von Kappel u. a. (2004, Seite 101). Dort wird ein Internetprogramm in die drei Teile ”Look&Feel“, ”Interaktionsdesign“und ”Kern“eingeteilt.EinersolchenEinteilungenvonInternetpro- grammen können projektspezifische Implementierungen zugeordnet werden. So wird das Look & Feel über die ZPT, das Interaktionsdesign über die Nutzung von AJAX und der Kern über die ”Outline“-Klasseundder ”Knoten“-Klassenerreicht.Dabeiorientiert sich die Interaktion an der Funktion und die Präsentation an der Interaktion²².

Diese Empfehlungen haben eine große Ähnlichkeit zu dem Model View Controller (MVC) Muster. In diesem Entwurfsmuster werden Daten in einem ”Daten-Modell“ge- speichert, welches die Zusammenhänge zwischen den Daten definiert. Zugang zu diesen Daten-Modell gelingt nur über eine ”Kontrollinstanz“,welchedieKonsistenzderDa- ten gewährleistet. Menschliche Nutzer interagieren mit dem Daten Modell durch die ”Darstellungsebene“ ,welche eine für Menschen verständliche Repräsentation der Daten darstellt (übersetzt nach Speirs, 2005)²³.

Entsprechend dieser beiden Vorgaben ist auch die weitere Gliederung aufgebaut. Im er- sten Teil ”Funktion“wirdaufdiefunktionalenEbeneeingegangen.DerzweiteAbschnitt ”Präsentation“ beschäftigt sich mit der darstellendenEbeneundderdritteTeil ”Interak- tion“ geht auf grundlegende interaktive Konzepte ein. Um diese Konzepte vorzustellen, wird der Quelltext des Projektes zitiert und erläutert. Es wird daher zusätzlich zu den eingeführten Technologien eine Bekanntheit von objektorientierter Programmierung und XML vorausgesetzt. Der Quellcode wird nicht vollständig besprochen, sondern nur auszugsweise vorgestellt. Bei Unklarheiten lohnt es den Quellcode des Zope Produktes zu konsultieren, da dort zusätzliche Kommentare enthalten sind²⁴.

4.3.1.1. Funktion

Alle grundlegenden funktionalen Konzepte sind in der Datei Dieses Python-Modul stellt drei Klassen zur Verfügung:

Basisknoten Stellt grundlegende Funktionalitäten aller Knoten bereit (Unterknoten an- legen, Knoten suchen. . . ). Darüber hinaus werden zusätzliche Werkzeuge aus dem Paket ”utils“genutztz.B.fürdasImportieren von XML.

Knoten Erbt von Basisknoten, von der Klasse von ”Inhalt“desModuls ”inhalt.py“und ”Version“ausdemModul ”version.py“.InstanzenwerdenalsKnotendesOut- lines genutzt mit denen gearbeitet wird. Knoten haben Funktionalitäten wie Ver- sionsmanagement, Wiki und elementare Verschiebungsmöglichkeiten (Einrücken, Ausrücken, Tauschen. . . ).

Wurzel Erbt von Basisknoten und symbolisiert eine spezielle Art des Knotens. Die Wur- zel hat keinen Oberknoten.

Instanzen von ”Wurzel“und ”Knoten“werdenalsKnotendesOutlinesgenutzt.Jede Instanz verwaltet hierzu die zwei Listen ausgehend und eingehend. In diesen werden Unter- und Oberknoten gespeichert. Bei der visuellen Ausgabe wird von der ausgehendListe der Wurzel ausgegangen. Die ausgehenden Knoten der Wurzel und deren ausgehende Knoten usw. werden also angezeigt. Die Wurzel selber wird nicht mit ausgegeben - alle dargestellten Knoten sind also Unterknoten.

Das Versionsmanagement ist durch Dictionaries implementiert. Eine Version eines Knotens ist ein weiterer Eintrag in diesem Dictionary namens versionen in dem als erster Eintrag immer das Original steht. Das Original ist daher eigentlich auch eine ”Version“-nämlichdieOriginalversion.ÜberdieVariableversionwirddieaktuelle Version (voreingestellt ist das Original) des Knotens bestimmt.

Abbildung in dieser Leseprobe nicht enthalten

Die obige Methode liefert bei der Ausgabe die aktuelle oder eine angegebene Version eines Knotens zurück. Dadurch dass in der ausgehend Liste weiterhin die Originale ste- hen, kann die folgende Methode Unterknoten die Methode holeVersion nutzen, um die eingestellten Knotenversionen beispielsweise bei einer Anzeige der Knoten zurückgeben zu lassen.

Abbildung in dieser Leseprobe nicht enthalten

Die durch Backslashes aufgeteilte zweite Zeile dieses Auszuges der Originalmethode bedarf vielleicht einer Erläuterung. In der Variable erg wird für alle Knoten, die sich in der Liste der ausgehenden Knoten befinden geprüft, ob der Oberknoten offen ist. Aus den Knoten bei denen das der Fall wird jeweils die aktuelle Version an eine Liste angehängt und diese letztlich in die Variable erg geschrieben²⁵.

Knoten werden über Interaktion mit einer Outline-Instanz in Form von HTTP-Anfragen an Zope angelegt. Bei dem Anlegen eines Outlines speichert dieses eine Wurzelinstanz als Attribut. Ausgehend von diesem Knoten werden durch die Nutzung der Methoden AddUnterknoten der Klassen ”Outline“und ”BasisKnoten“weitereKnotenangelegt.

Abbildung in dieser Leseprobe nicht enthalten

4.3.1.2. Präsentation

Alle grundlegenden präsentativen Konzepte sind in den ZPT implementiert. Diese befin- den sich im Ordner ”ZPT“desProduktordners.

Die Hierarchie der Knotenstruktur wird durch eine Verschachtelung von <ul/> bzw. <li/> Auszeichnungen innerhalb des HTML erreicht. Diese auch als Listen (engl. ”bul- letpoints“) bekannte und oft genutzte Darstellungsmöglichkeit ermöglicht eine beliebige Tiefe bzw. Anzahl von Knoten. Vor diesem Hintergrund ist der rekursive Aufbau der Sei- tenvorlage ”outline. zpt“ sinnvoll und wird im folgenden vereinfachten Auszug deutlich:

Abbildung in dieser Leseprobe nicht enthalten

In der ersten Zeile wird ein angegebenes Wurzel-Objekt an die Seitenvorlage übergeben. Der Zusatz nocall stellt sicher, dass nicht der Wert des Methodenaufrufes der Wurzel (Wurzel()) an die Vorlage übergeben wird. Der rekursive Aufruf findet in der Zeile 10 statt. Jedoch nur wenn die Abbruchbedingung, dass keine Unterknoten vorhanden sein dürfen, nicht erfüllt ist. Durch den rekursiven Aufruf des Macros ist eine beliebige Verschachtelungstiefe möglich. Bei diesem Ansatz gab es mit der Performanz auch bei großen Dokumente keine Probleme²⁶.

CSS wird in hohem Maße für die Darstellung sowohl des Portals als auch der Outlines genutzt. Zum Beispiel werden Regeln mittels CSS definiert, die es ermöglichen die Abstände der Einrückungen einzustellen (ul), die Anführungspunkte der Liste zu entfernen (li) oder eine farbige Trennlinie für die bessere visuelle Abgrenzung von Versionen zu definieren (li.version:hover). Diese stark gekürzten CSS Anweisungen können auf alle Vorlagen angewendet werden. Für ein genaueres Verständnis dieser Anweisungen sei auf weiterführende Internetadressen²⁷ verwiesen.

Abbildung in dieser Leseprobe nicht enthalten

Je nach Kontext können unterschiedliche Vorlagen aus dem ”ZPT“-OrdnerzurDar- stellung ausgewählt werden. Voreingestellt werden Outlines mitsamt dem Portal durch die Vorlage ZPT ”mitCMF.zpt“angezeigt.EinealleinigeDarstellungvonOutlinesistmitder ”haupt.zpt“möglich,welchealsMacroinderVorlagemitCMF.zptgenutztwird. Denkbar ist demzufolge auch eine Darstellung von Outlines ohne umgebendes Portal zum Beispiel in mehreren Browser-Fenstern nebeneinander.

Um eine vollständige Trennung der Präsentation zu erreichen, werden auch die Dialoge in einer ZPT zentral definiert ( ”dialoge.zpt“)undkönnenausdenanderenVorlagen heraus aufgerufen und genutzt werden. Die Präsentationsschicht ruft sich also selber auf und es ist nicht notwendig Logik außerhalb zu definieren. Um bei den Dialogen eine Konsistenz in der Darstellung und Positionierung zu erreichen, werden diese wie Nachrichten wie zum Beispiel Fehlermeldungen behandelt.

Abbildung in dieser Leseprobe nicht enthalten

Es ist zu erkennen, dass ein Dialog über das Schlüsselwort VersionsVerwaltung ausgewählt wird und die entsprechend zurückgegebenen Auszeichnungen als Nachricht an die eigentliche Ausgabe übergeben werden.

Bei der Gestaltung der Oberfläche wurden so wenig Bilder wie möglich verwendet, um die Ladezeiten möglichst gering zu halten bzw. das Look & Feel der Anwendung auch von ihrer Antwortschnelligkeit an Desktop-Programmen erinnern zu lassen. Grafi- ken wurden lediglich für die geöffneten und geschlossenen Pfeile benutzt. Es wäre zwar möglich gewesen diese durch die Zeichen > und v zu ersetzen. Eine solche Lösung würde aber zu unterschiedlich weiten Einrückungen der Knoten führen, da diese Zeichen eine unterschiedliche Breite aufweisen. Als Bilder wurden GIFs mit transparenten Hinter- grund und konstanter Breite verwendet. Auf Bilder im PNG²⁸ -Format musste wegen der mangelnden Unterstützung durch den Internet Explorer verzichtet werden.

4.3.1.3. Interaktion

Alle grundlegenden interaktiven Konzepte werden an zwei Orten festgelegt.

Das Python Modul ”outline.py“bzw.diedortenthalteneKlasse ”Outline“stelltmithil- fe des ZPublishers Interaktionsmöglichkeiten mit Outline-Instanzen anhand der veröffent- lichten Methoden bereit. Dabei organisiert diese Klasse die funktionalen Konzepte aus ”knoten.py“ in einer bestimmtenFormundbestimmtsodieInteraktionsmöglichkeiten. Ein Aufruf einer der beiden Adressen²⁹ führt zum Ausführen der folgenden Programm- anweisungen (Object Publishing).

Abbildung in dieser Leseprobe nicht enthalten

Dabei ist in der Variable self der Kontext also das Outline-Objekt ”MeinOutline“ge- speichert. Die Outline-Klasse stellt noch weitere speziell kombinierte funktionale Konzepte bereit, welche unter anderem alle Funktionalitäten eines Knotens abdecken (Einrücken, Tauschen. . . ). Bei einer normalen synchronen Anfrage wird das Outline mitsamt dem umgebenden Portal als HTML zurückgegeben. Bei einem asynchronen Aufruf über AJAX wird nur das Outline zurückgegeben, um dieses auf Seite des Clients in das HTML einzufügen. Dieses dynamische Einfügen der HTML Dateien in dem Ordner ”Portionen“wirdvondenJavaScript- ”utils/jscss“,welcherderzweiteDefinitionsortvoninteraktiven Konzepten ist, durchgeführt. Dort werden die AJAX-spezifischen Interaktionsmöglichkeiten festgelegt.

Die AJAX Interaktionen sind ein Aufsatz auf die Präsentation. Deswegen ist es auch möglich JavaScript, während des Betriebes auszuschalten. Dieser Sachverhalt soll durch einen Ausschnitt aus der ZPT ”outline.zpt“nochpraktischverdeutlichtwerden:

Abbildung in dieser Leseprobe nicht enthalten

Dadurch, dass die JavaScript Funktion async (bereitet asynchrone Kommunikation vor- und nach) die ersten beiden Parameter in der gleichen Weise konkateniert wie es in der Python Anweisung davor der Fall ist, wird deutlich, dass die gleichen von der Outline-Instanz bereitgestellten Ressourcen genutzt werden.

Eine Veränderung der Präsentationsschicht durch AJAX geschieht immer in 2 Pha- sen. Angewandt auf Veränderungen von Knoten wird zuerst nach dem Namen des <li> Elementes innerhalb der Auszeichnungshierarchie gesucht und danach wird das HTML innerhalb dieses Knotens ersetzt. Realisiert wird diese Methodik durch folgende Funkti- on:

Abbildung in dieser Leseprobe nicht enthalten

Die Funktion ObjektHolen ist auf Seite 79 definiert. Interessant ist an dieser Stel- le lediglich der Rückgabewert. Zurückgegeben wird ein JavaScript-Objekt, welches von der JavaScript-Implementierung des Browsers generiert wurde. Diese erstellt von allen HTML-Auszeichnungen entsprechende JavaScript-Objekte und macht diese adressierbar. Die Objekte stellen eine je nach Browser unterschiedliche Anzahl von Methoden und At- tributen bereit. Das Attribut innerHTML erlaubt es den Inhalt eines Auszeichnungsblocks zu ändern und wie in diesem Beispiel mit variablen Inhalt zu füllen. Bei Veränderungen an Knoten werden noch andere Phasen wie das Neuschreiben und -positionieren der Werkzeuge-Box, ein Fokus-Wechsel des Eingabeelementes und ggf. ein Austausch von Bildern durchlaufen. Diese weiteren Schritte werden in der Funktion Datei ”Aktualisieren“der ”ollib.js“definiert.

Die Interaktion beim Speichern von Formulardaten wurde im Kapitel über AJAX erklärt. AJAX Interaktionen, welche vom Server berechnete Daten anzeigen, werden wie bei der Registrierung bzw. Anmeldung des Beispiels im Kapitel 3.1 abgewickelt.

4.3.2. Qualitätsmerkmale

In den nächsten Abschnitten wird die projektspezifische Umsetzung der Qualitätsmerk- male des Kapitel 2.3.2 beschrieben. Dazu werden lediglich Auszüge oder gekürzte Ver- sionen der tatsächlichen Programmanweisungen oder Auszeichnungen als Beispiele ein- gebunden.

Alle Bildschirmabbildungen (engl. ”screenshots“)stammenvondemBrowser ”Safari“ in der Version 2.0.1 unter dem Betriebssystem Mac OS X Version 10.4.2, wenn diese nicht anders gekennzeichnet sind.

4.3.2.1. Ordnungsmäßigkeit und Richtigkeit Ordnungsmäßigkeit

Um eine möglichst große Ordnungsmäßigkeit und Accessibility zu erreichen, werden HTML, CSS und JavaScript weitgehend in einer vom W3C empfohlenen Art eingesetzt.

Der dreispaltige Aufbau des Portals wurde durch die Nutzung von HTML in Kombi- nation mit CSS erreicht. Speziell ausgezeichnete logische Blöcke (<div></div>) mar- kieren die Spalten und CSS definiert für diese Bereiche Regeln für die Darstellung. Im linken Auszug wird ein relevanter Auszug aus der Haupt-Seitenvorlage des Portals (”mainTemplate.zpt“³⁰ ) gezeigt. In diesem werden die einzelnen Bereiche der Seitever- einfacht ausgezeichnet und im rechten Auszug der Datei ”stylelayout.css“wirdbeispiel- haft die CSS Regel für die mittlere Spalte (Inhaltsbereich) angegeben. Dieser so genannte Selektor von CSS definiert Regeln für alle HTML-Auszeichnungen, die den Wert content für das Attribut class haben.

Abbildung in dieser Leseprobe nicht enthalten

Dies gilt für das erste <div> Element. Neben dem aufgeführten Selektor gibt es in dem tatsächlich genutzten Stylesheet weitere für die linke und rechte Navigationsbox und noch andere, die die Darstellung für Tags wie <p/> oder <div/> festlegen. Man kann an diesem Beispiel erkennen, dass derselbe Inhalt unterschiedliche Darstellungen durch CSS haben kann, denn man könnte die Inhaltsspalte auch leicht an den Rand (engl. ”margin“) positionieren, indem man die Daten für diesen anpasst.Das HTML würde von dieserÄnderung unberührt bleiben³¹.

Bei der Umsetzung wurde versucht auf Tabellen für Layoutzwecke zu verzichten. Die Anzeige von Navigationselementen vor und nach den vollbreiten Eingabeboxen jedes Knotens erforderten aber weiterhin einen Missbrauch von Tabellen³².

Es ist möglich sowohl das Outline als auch die komplette Portalseite ohne CSS zu nutzen. Alle Auszeichnungen sind so aufgebaut, dass eine erkennbare Darstellung auch ohne den Einsatz von CSS gewährleistet ist. In dem Beispiel wird diesbezüglich deut- lich, dass durch die Reihenfolge der Definition der Spalten die Betrachtung ohne CSS beeinflusst wird. Die Inhaltsspalte wird als erstes definiert, daher ist diese bei nicht ak- tivierten CSS auch ganz oben zu sehen. Dies ist sinnvoll, da der Inhalt der Grund ist warum eine Seite besucht wird. Zur Visualisierung der Zugänglichkeit sollen hier beide Darstellungsmöglichkeiten des ZOL-Werkzeuges abgebildet werden.

Abbildung in dieser Leseprobe nicht enthalten

(a) Anzeige mit CSS (b) Anzeige ohne CSS

Man kann weiterhin die Baumstruktur erkennen und mit dem Internetprogramm ar- beiten. Diese Accessibility wurde durch die Nutzung von Listen innerhalb des HTML erreicht. Listen werden von allen relevanten Browsern unterstützt³³. An diesem Beispiel wird auch eindrucksvoll demonstriert welche optischen Veränderungen durch die Nutz- ung von CSS zu erreichen sind. Weitere Maßnahmen für eine bessere Zugänglichkeit des Internetprogramms ist die Hierarchie der Knoten durch die Kontext- und Orientierungs- informationen entstehen (vgl. Chisholm u. a., 1999, Abschnitt 2.1). Außerdem wurden alle Bilder, die angezeigt werden sowohl mit einem ”alt“alsauchmiteinem ”longdesc“ Attribut versehen.

Die Anwendung ist auch mit oder ohne JavaScript bedienbar. Bei nicht aktiven Java- Script ist eine Interaktion immer noch über die ”traditionelle“NutzungvonLinks möglich.Über JavaScript gesteuerte Funktionen führen zu den gleichen serverseitigen Programmschritten wie es bei Interaktionen über Links der Fall wäre. Das Programm läuft daher in gleicher Weise ab und der JavaScript Status des Clients ist unerheblich.

Es findet daher auch keine Kommunikation über JavaScript Einstellungen der Clients statt. Das An- und Ausschalten von JavaScript während des Betriebes ist daher kein Problem.

Bei der JavaScript Programmierung wurde ebenfalls darauf geachtet, möglichst vie- le Browser zu unterstützen. Der allgemeine Grundsatz keine Browserweichen, sondern Objektweichen einzusetzen (vgl. Koch) wurde bei der browserübergreifenden Programm- ierung zum Beispiel in der folgenden Funktion der Datei ”ollib.js“beachtet.

Abbildung in dieser Leseprobe nicht enthalten

In der Funktion wird in den if Abfragen auf die Existenz verschiedener Objekte getestet mit denen im Erfolgsfall gearbeitet wird. Diese Objekte werden von unterschied- lichen Browsern zur Verfügung gestellt. Es ist weniger sinnvoll eine Browserweiche zu implementieren, da zuviele Versionen unterschieden werden müssten und weil diese Wei- chen meist auf der Identifikationszeichenkette des Browser basieren. Diese Identifikation, die an Server gesendet wird, kann manuell geändert werden oder ist oft auch fehlerhaft voreingestellt. Daher ist sie nicht als eindeutige Identifikation hinreichend.

Auf die im allgemeinen Abschnitt geforderten geordneten Rückfälle bei der Nutzung von JavaScript wird im Abschnitt ”Fehlertoleranz“diesesKapitelseingegangen.Zum Abschluss noch eine Tabelle, die über die korrekte Anzeige der Anwendung mit einigen Browsern Aufschluss gibt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4.3.: stichprobenartige Browserkompatibilitätstabelle (mit diesen Browsern kann die Anwendung sowohl mit als auch ohne CSS und JavaScript korrekt an- gezeigt werden.)

Richtigkeit

Die Richtigkeit der angezeigten Daten ist elementar für dieses Internetprogramm. So sollte man sich sicher sein können, dass sich zum Beispiel ein Knoten auch an der angezeigten Position befindet.

Die Integrität und Korrektheit von Daten wird durch die ZODB gewährleistet. Diese verwaltet Versionen von Objekten und speichert Änderungen an trivialen Datentypen wie Zahlen und Zeichenketten automatisch. Bei der Speicherung von veränderbaren Da- tentypen wie Listen, Dictionaries oder zusammengesetzten eigenen Datentypen wird die ZODB jedoch nicht bei einer Veränderung der Unterobjekte benachrichtigt. Daher muss eine Markierung von modifizierten Datentypen durch das sogenannte ”Dirty-Bit“ (_p_changed) durchgeführt werden. Der folgende Programmausschnitt ist der KnotenKlasse entnommen und zeigt eine solche Arbeitsweise. Auf diese Weise markierte Objekte werden nach der Bearbeitung in der Objektdatenbank gespeichert.

Abbildung in dieser Leseprobe nicht enthalten

Um die korrekte Funktionsweise einiger Funktionalitäten sicherzustellen werden beim Laden des Zope Produktes die definierten Unit-Tests der Datei ”tests.py“durchgeführt.

Dies ist speziell während der Entwicklung sinnvoll, verursacht aber längere Wartezeiten beim Hochfahren des Servers. Bei einer öffentlichen Distribution ist es ratsamer die Tests in Dateien auszulagern, die optional ausgeführt werden können (wie zum Beispiel bei den Unit-Tests vom CMF, welche sich im Ordner ”tests“befinden).

Die Richtigkeit der Daten bei einer simultanen kollaborativen Bearbeitung kann momentan noch nicht sichergestellt werden, da kein (asynchroner) Abgleich bei Änderungen des Outlines durch andere Personen, Semaphoren oder ein Sperrmechanismus zum exklusiven Bearbeiten implementiert ist. Diese äußerst wichtige Funktionalität sollte so schnell wie möglich realisiert werden.

4.3.2.2. Sicherheit

Es wurde schon einiges über das zugrunde liegende Sicherheitssystem von Zope und die Anwendung auf das umgesetzte Projekt geschrieben. Das Rechtesystem des Portales und von ZOL wird komplett über Zope, wie in dem Kapitel 4.2.1 beschrieben, geregelt. An dieser Stelle soll nun noch genauer auf die von Zope bereitgestellten Sicherheitsmaßnah- men eingegangen werden.

Zusammenfassend lässt sich sagen, dass Zope Sicherheit durch drei grundlegende Prinzipien gewährleistet.

Rechte Diese ”Permissions“sindmeistvonZopevordefiniert,könnenaberauchinner- halb von Produkten definiert werden, falls diese sich von denen von Zope unter- scheiden müssen. ZOL definiert keine eigenen Rechte und nutzt lediglich das von Zope definierte ”View“RechtfürdieAktionenderFTI.

Entwickler von Zope Produkten können die Ausführung jeder einzelnen Methode von unterschiedlichen Rechten abhängig machen. Dadurch kann ein Zugriff von au- ßen kontrolliert werden. Jedes Produkt, das eigene Rechte definiert, braucht einen ”Security Manager“, welcher durch eine Instanzierung der Klasse ClassSecurityInfo bereitgestellt werden muss. ZOL kommt ohne zusätzliche Rechte aus, benötigt diese Methodik aber um die Seitenvorlagen aus dem Dateisystem durch die Klassen des Produktes nutzbar zu machen.

Abbildung in dieser Leseprobe nicht enthalten

Dieser verkürzt entnommene Inhalt des Moduls ”PageTemplates.py“demonstriert die programmatische Nutzung der Sicherheitsimplementierung von Zope während der Produktentwicklung.

Benutzerordner ”UserFolders“ermöglicheneinAnlegenundVerwaltenvonBenutzern innerhalb von Zope und dem CMF. Diese Ordner können ihre Daten auch von Verzeichnisdiensten wie LDAP o.ä. erhalten. Bei einer Registrierung eines Nutzers bei myideas.de wird ein neuer Eintrag in dem zugehörigen Benutzerordner erstellt, welcher danach administrativ verwaltet werden kann.

Rollen ”Roles“oderauch ”Gruppen“könnendenNutzerninnerhalbderBenutzerordner zugeordnet werden. Den Rollen werden darüber hinaus unterschiedliche Rechte bzw. Permissions zugeordnet. Rollen kann man sich daher als Anhäufungen von Rechten vorstellen. Durch dieses kombinierte Konzept ist eine feine und sichere Zuteilung von Ressourcen möglich, die es ermöglicht verschiedene Zope-Produkte parallel auf einem Server zu betreiben. Zope definiert folgende Rollen:

Anonymous Die ”Gast“-RolleistfüralleNutzerkonzipiert.MeistenswerdenRech- te zum Betrachten von Inhalten mit dieser Rolle verbunden.

Authenticated Authentifiziert sind alle Nutzer, die nicht anonym (engl. mous“) sind. Diese Rolle hat meist keine Rechte voreingestellt.

Manager Die ”anony- ”Administrator“-RollehatmeistalleRechtezugeordnetundkann in diesem Falle Zope komplett konfigurieren.

Owner Der ”Besitzer“einesObjektesinnerhalbvonZopeistmeistensauchder Autor. Bei der Überprüfung, ob ein Nutzer ein Objekt auf eine bestimmte Art nutzen kann, wird auch überprüft, ob der Besitzer dieses Objekt die entsprechende Berechtigung hat. Durch diese Methodik soll serverseitiger Missbrauch eingeschränkt werden.

CMF Rollen Innerhalb von CMF-Portalen sind voreingestellt die Rollen ber“ (dt. ”Mem- ”Mitglied“)und ”Reviewer“(dt. ”Rezensent“)zusätzlichangelegt. Diese Rollen können für zusätzliche Funktionalitäten wie den auf Seite 11 beschriebenen Geschäftsprozess genutzt werden.

Bei den Rollen ist zu beachten, dass Zope allgemein annimmt, dass eine Verbindung anonym ist. Nur wenn eine Authentifizierung in Form von Nutzernamen und Passwort vom Browser mitgesendet wird, überprüft Zope den Benutzerordner auf die Existenz des anfragenden Nutzers und seine Berechtigung eine Antwort auf seine Anfrage zu erhalten. Benutzer eines Benutzerordners können verschiedenen Rollen angehören. Diese Rollen können sogar je nach Zugriffskontext unterschiedlich sein. Ein Nutzer kann innerhalb eines Ordners mehr Rechte bzw. zusätzliche oder andere Rollen haben als in anderen.

lokale Rollen Solche lokale Rollen (engl. local roles“) werden von myideas.de zum Teilen und kollabo- ” rativen Bearbeiten der Outlines genutzt. Besitzer von Ordnern können diese freigeben bzw. andere Mitglieder zu zusätzlichen Besitzern dieses Ordners und der Inhalte machen. So können Schreib- und Leserechte autonom durch die Nutzer definiert werden.

Weitere Details, welche zu den Sicherheitsbetrachtungen des Projektes gehören, sind zum einen die folgende beispielhafte Überprüfung und Anpassung von Parametern. Diese Anweisung wird im Modul ”outline.py“beimAnlegeneinesneuenOutline-Objektes ausgeführt, um Leerzeichen im Namen des Objektes durch Unterstriche zu ersetzen.

Abbildung in dieser Leseprobe nicht enthalten

Zum anderen soll die schon oft angewandte Nutzung der Dokumentationszeichenkette für die Veröffentlichung von Methoden an dem folgenden Beispiel erklärt werden.

Abbildung in dieser Leseprobe nicht enthalten

Diese Art der Veröffentlichung während der Produktentwicklung ist der gesamten beschriebenen Sicherheitsarchitektur von Zope vorgelagert³⁴.

4.3.2.3. Interoperabilität und Austauschbarkeit Interoperabilität

Ein verbreiteter Standard zum Austausch von Outlines zwischen verschiedenen Outliner- Anwendungen ist das XML-Derivat OPML. Dieses Format wurde im Zuge der Entwick- lung der ”Frontier“-AnwendungvonDaveWinerdefiniertundwirdvonvielenOutlinern unterstützt. Es besteht jedoch Uneinigkeit über die Funktionalitäten, die OPML in Zu- kunft abbilden soll. Entwickler sind daher eingeladen den ”Standard“umfürihreZwecke nötige Elemente zu erweitern. Die offizielle Spezifikation ist über eine Internetadresse³⁵ verfügbar.

Eine beispielhafte OPML-Datei besteht wie auch HTML aus einem Kopf und einem Körper. Im Kopf können unter anderem der Titel der Datei und die Nummern der offe- nen Knoten, beginnend bei Null und durch Kommata getrennt, gespeichert werden. Im Körper wird die Struktur der Knoten durch Verschachtelung von <outline/> Tags for- muliert. Mögliche Attribute dieses Tags sind der Textinhalt des Knotens und zusätzliche Notizen zum Knoten. Alle Regeln des Aufbaus von OPML sind in der entsprechenden DTD nachzulesen³⁶.

Abbildung in dieser Leseprobe nicht enthalten

Dieses Format wird zum internen und externen Austausch der Outlines innerhalb von ZOL verwendet. Zum Importieren von Outlines wird das XML über SAX eingelesen und entsprechend der Auszeichnungen des OPML werden Knoten generiert. Das DOM hätte auch genutzt werden können, um das OPML zu verarbeiten. Bezüglich ZOL hat SAX aber Vorteile gegenüber DOM, da nur wenige bestimmte Informationen gesucht werden und ein sequentieller Zugriff ausreicht. Daher muss die Hierarchie des eingelesenen OPML nicht wie bei DOM üblich im Speicher abgebildet werden und ein schnellerer Zugriff kann erfolgen. Der für die XML Verarbeitung nötige SAX-Handler ist in dem Modul ”handler.py“definiert³⁷.

Eine Instanz dieses Handlers wird beim Import von OPML innerhalb der folgend aufgeführten Methode importOPML angelegt. Dieser Instanz wird der aktuelle Knoten übergeben und in der nächsten Zeile beginnt der Parser die OPML Zeichenkette zu überprüfen und Events wie zum Beispiel die Identifikation eines neuen Knotens an den Handler zu übergeben. Dieser reagiert entsprechend darauf, indem er zum Beispiel einen neuen Knoten anlegt. Der Handler speichert außerdem Variablen wie die Wurzel der angelegten Knotenstruktur oder die Anzahl der angelegten Knoten. Diese Anzahl wird in der letzten Zeile zurückgegeben.

Abbildung in dieser Leseprobe nicht enthalten

Die für den Export benötigte OPML Zeichenkette wird durch die rekursive Metho- de OPMLexport generiert. Diese legt sowohl die Tag-Verschachtelungen sowie die durch Kommata getrennten Nummern der offenen Knoten an. Nachfolgend ist eine vereinfachte Methode aufgeführt.

Abbildung in dieser Leseprobe nicht enthalten

Die Methode ”exportOPML“ausdemModul ”olutils.py“bringtdievonderFunktion OPMLexport erzeugte Zeichenkette in den nötigen Gesamtzusammenhang. Das durch diese Funktionen generierte OPML kann auch in externen Anwendungen genutzt werden.

Auf der folgenden Abbildung ist das Programm generierten OPML zu sehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.6.: Interoperabilität mit Desktop-Anwendungen

Die Inhalte der Plattform können über verschiedene Kanäle bezogen werden. Zum Bei- spiel können die Meta-Daten jedes Objektes auch über RSS übermittelt werden, wenn diese Art der Nutzung vom jeweiligen Portalmitglied freigeschaltet wurde. Wenn dies der Fall ist können Ordner von anderen Mitgliedern aber auch von Dritten ”abonniert“ werden. Diese erhalten dann einen aktuellen aus den Dublin Core Meta-Daten der Ob- jekte des Ordners generierten RSS-Feed, der über viele verschiedene RSS-Reader genutzt werden kann.

Es ist auch möglich die Inhalte Web Services zur Nutzung freizugeben. Dazu könnten Produkte von Drittherstellern genutzt werden, die die gängigen Standards unterstützen.

Austauschbarkeit

Auf der Präsentationsebene wird eine Wiederverwendung durch Seitenvorlagen erreicht. Bei diesem Ansatz muss für jeden darzustellenden Seitentyp ein entsprechendes Template angelegt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.7.: Wiederverwendbare Seitentypen des Portals

Durch die Definition und Befüllung von Slots können sich diese Seitentypen modu-lar aufgebauten ZPT wie zum Beispiel der ”outline.zpt“bedienenunddieselediglich in einer bestimmten Weise anordnen. Aus diesem Grund enthalten die Definitionsdatei- en der Seitentypen meist wenig spezifische Auszeichnungen. Das hat den Vorteil, dass wenn eingebundene ZPT-Module geändert werden, dieseÄnderungen in allen betroffe- nen Seitentypen automatisch wirksam werden. In der folgenden gekürzten Seitenvorlage ”mitCMF.zpt“werdennurSlotsderVorlagemain_templateaufeinebestimmteWeise gefüllt. Man kann erkennen, dass Slots auch im Kopfbereich angelegt und befüllt werden können. Außerdem ist bei der letzten Befüllung zu erkennen, dass sich die Slot-Definition in einer Schleife befinden muss, da auf Variablen zugegriffen wird, die in dieser Vorlage nicht definiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Die Funktionsweise der Befüllung des Slots main durch die rekursive Nutzung von Macros wurde schon im Kapitel 4.3.1.2 erwähnt. Es ist offensichtlich, dass durch solch eine rekursive Nutzung ein hohes Maß an Wiederverwendung und daraus resultierend Konsistenz entsteht.

Die definierten Vorlagen können auch in unterschiedlichen Kontexten verwendet wer- den. Die Grundlage dafür ist der Aufruf der ZPT mit unterschiedlichen Parametern. Die folgende Methode orientiert sich an dem Beispiel von Seite 56 und ermöglicht die auf- zurufende Vorlage zu spezifizieren und somit den Rückgabewert zu beeinflussen. Dieser unterscheidet sich auch je nachdem welchen Knoten man als Wurzel übergibt.

Abbildung in dieser Leseprobe nicht enthalten

In diesem Ausschnitt der Original-Methode können abhängig von der übergebenen Seitenvorlage und dem übergebenen Wurzelknoten entweder alle Unterknoten dieser wurzel (bei Übergabe der Vorlage ”outline.zpt“)oderalleUnterknoteninklusivedes angegebenen Wurzelknoten (bei Übergabe der Vorlage ”inklusive.zpt“³⁸ )alsErgebnis zurückgegeben werden. Auf dieser Basis ist es auch möglich Teile des Outlines über AJAX anzufragen und einzubauen. So muss nicht das gesamte Outline aktualisiert werden, sondern kann in Teilen übermittelt werden. Dies wirkt sich bei großen Dokumenten positiv auf die Antwortzeiten des Internetprogramms aus. Durch die Nutzung derselben Quelle wie die der synchronen Anfrage ist eine Konsistenz sichergestellt.

Die im vorigen Abschnitt beschriebene OPML-Export und -Import Funktionalität wird für das Anlegen von Versionen wiederverwendet. Da Versionen nicht nur von einzel- nen Knoten, sondern auch von ”Unter-Outlines“angelegtwerdenkönnen,werdendiese innerhalb des Speichers nach OPML exportiert und mit dem Knoten für den die Ver- sion angelegt werden soll als Wurzel reimportiert. Diese Funktionalität wird von der Methode Klasse ”neueVersion“desModuls ”knoten.py“implementiert,welchedieMethodeder ”Version“ um knotenspezifischeAnweisungenergänzt.DieKlassedesModuls ”version.py“ stellt eine einfache Versions-Implementierung dar,welcheaufgrundihrer generischen Objektorientierung, teilweise in anderen Projekten wiederverwendbar sein könnte.

Die Analyse der Wiederverwendbarkeit kann mit einem Vergleich zwischen der Ver- wendung des eingesetzten Template-Ansatzes und einem Ansatz, der Logik und Präsen- tation vermischt, abgeschlossen werden. Ein direkter Vergleich ist möglich, da frühere Versionen von ZOL ohne Seitenvorlagen arbeiteten. Für diesen Vergleich wurde die ZPT ”outline.zpt“entsprechend der Funktionalität des älteren Ansatzes angepasst.Diebei- den Ansätze wurden also auf den gleichen Funktionsumfang gebracht. Beide Dateien befinden sich im Anhang.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4.4.: Vergleich des Einsatzes von ZPT und Listen-Auszeichnungen und einem Skript-Ansatz mit Tabellen-Layout für ZOL

Verwunderlich ist die nahezu gleiche Größe der generierten Auszeichnungen. Dies lässt sich auf den nicht vollständigen Verzicht von Tabellen für Layout-Zwecke bei der neueren Variante zurückführen. Auffallend ist, dass der ”Programmcode“fastumeinDrittel geringer beim Einsatz der Templates ist.

Da Austauschbarkeit auch Merkmale der Installierbarkeit miteinschließen kann (vgl. DIN, 1994), sei noch auf die bereitgestellten Funktionalitäten diesbezüglich eingegangen. Das Zope Produkt kann durch einfaches Bewegen innerhalb des ”Products“-Ordnerder Zope-Instanz installiert werden. Es ist also einfach möglich dieses Produkt unter aktuel- len Zope-Versionen und CMF-Versionen zu installieren. Bei einer Aktualisierung der Pro- dukte wird die Datei ” init .py“ ausgeführt. In dieser sind Anweisungen enthalten, die eine weitgehende Installation des Produktes veranlassen. Dort werden zuerst Directory Views erstellt, welche Zope den Zugriff auf die ZPT des Produktes und die nötigen CSS und JavaScript-Dateien ermöglichen. Dann wird ZOL in der Funktion initialize zuerst als Zope Produkt initialisiert. Danach wird ZOL durch Aufruf von Methoden des Frameworks als Inhaltstyp von CMF initialisiert.

4.3.2.4. Fehlertoleranz

Bei der Organisation der Oberfläche wurde darauf geachtet, dass unsinnige Interaktionsmöglichkeiten, wie zum Beispiel dasÖffnen eines Knotens ohne Unterknoten, nicht angeboten werden. Falls doch fehlerhafte Interaktionen zum Beispiel durch Laden veralteter Adressen entstehen, sind entsprechende Vorsichtsmaßnahmen in der Outline-Klasse implementiert, welche diese abfangen.

Abbildung in dieser Leseprobe nicht enthalten

Bei Eingaben des Nutzers, die in einer bestimmten Situation nicht gewollt sind bzw. auf eine subjektive Weise fehlerhaft sind, besteht die Möglichkeit diese rückgängig zu ma- chen. Solch eine ”Undo“-FunktionistvonDesktop-Anwendungenbekannt.Esistauch möglich eine rückgängig gemachte Manipulation rückgängig zu machen (engl. ”redo“).

Diese Funktionalität wird durch die ZODB bereitgestellt, welche verschiedene Versionen aller Objekte speichert und verwalten kann. Diese Funktionalität erlangt eine beson- dere Wichtigkeit bei der kombinierten Nutzung mit AJAX. Da durch die asynchrone HTTP-Kommunikation der ”Zurück“-ButtondesBrowsers,alseinbekanntesWerkzeug, um fehlerhafte Interaktionen rückgängig zu machen, entfällt, findet der Nutzer in einer solchen Funktionalität Unterstützung.

Eine Überprüfung der Eingaben von Nutzern kann sowohl serverseitig als auch client- seitig zum Beispiel über JavaScript Formularüberprüfung erfolgen. Die im Abschnitt ”Sicherheit“beschriebeneFunktionalitätderErsetzungvonLeerzeichenwirdbeimAn- legen eines Outlines über das CMF aufgerufen. Außerdem können serverseitig innerhalb von Python auftretende Fehler während der Programmausführung über Ausnahmen be- handelt werden. In dem folgenden Auszug der Methode tauschen der Klasse ”Knoten“ wird zuerst geprüft, ob mindestens ein Geschwisterknoten, welcher für die Tauschfunktion notwendig ist, vorhanden ist.

Abbildung in dieser Leseprobe nicht enthalten

Wenn ein zu tauschender Knoten alleine unter einem Oberknoten steht, wird eine Ausnahme ( ”AttributeError“)ausgelöstundandieaufrufendeFunktionweitergeleitet. Dieses ist in diesem Fall die Methode HochTauschen der Outline-Klasse, welche allgemein verständliche Fehlermeldung ausgibt.

Abbildung in dieser Leseprobe nicht enthalten

Die tatsächlich genutzten Fehlermeldungen werden in der Datei niert und in das Modul ”konstanten.py“defi- ”outline.py“eingebunden.EleganterwärebeiderAusnahmen- behandlung des obigen Auschnitts die Ausnahme (in diesem Falle ”AttributeError“) genauer zu spezifizieren, damit nicht alle Ausnahmen behandelt werden.

Bei den unterschiedlichen JavaScript Implementierungen der Browser ist es notwendig fehlertolerant zu programmieren. Auch JavaScript stellt Ausnahmen zur Steuerung des Programmablaufes zur Verfügung. In der folgenden gekürzten Funktion Oberknoten ist dieses Vorgehen sichtbar. Die Ausnahme wird bei dieser Funktion durch den Zugriff auf das Attribut parentNode ausgelöst, da es nicht beim obersten Element definiert ist.

Abbildung in dieser Leseprobe nicht enthalten

Geordnete Rückfälle können nicht nur über Ausnahmen realisiert werden. ZOL erreicht eine Fehlertoleranz in der Werkzeuge-Box über eine Nutzung verschiedener Links. Diese Links werden je nach Status von JavaScript und Auftreten von Fehlern unterschiedlich verfolgt. Dies bedeutet eine Verkomplizierung und einen Missbrauch der InternetStandards erlaubt aber eine unterschiedliche Reaktion auf Interaktionen.

Der normale Link der Werkzeuge-Box wird ausgeführt, wenn das JavaScript Fehler enthält. Daher ist es auch wichtig, dass serverseitig die Zustände der Anwendung gespei- chert werden. Da so Fehler bei der Darstellung, die durch JavaScript entstanden sind durch ein Neuladen der Seite behoben werden können. Die Links der Werkzeuge-Box, die von der ZPT vorgesehen sind, werden angezeigt, wenn ein Nutzer den Link ”tools“ der Reiternavigation verfolgt und JavaScript deaktiviert hat. In diesem Fall erscheinen Links der Funktionalitäten anstatt der beweglichen Werkzeuge-Box rechts neben jedem Eingabefeld. Ergänzend soll dieser Sachverhalt noch in der folgenden Tabelle dargestellt werden.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4.5.: geordneter Rückfall von rechts nach links

4.3.2.5. Verständlichkeit

Das Projekt übernimmt gewohnte Idiome und Metaphern von Desktop-Anwendungen.

So ist zum Beispiel eine Reiternavigation weitgehend bereits aus Browsern ( ”Tabbed Browsing“) bekannt. Dieses Idiom geht zurück auf die visuelle Erscheinung und die Interaktionsmöglichkeiten mit Karteireitern.

Viele der Navigationsmöglichkeiten sind über Dreiecksformen realisiert. Diese Form in ihren unterschiedlichen Ausprägungen wurde auch schon in Desktop-Programmen wie zum Beispiel im ”Finder“³⁹ fürInteraktionszweckegenutzt.Dortstehteineunter- schiedliche Ausrichtung der Dreiecke für offene oder geschlossene Ordner. Im Equivalent von Windows wird diese Symbolik durch die abstrakten Das ”+“-oder ”-“-Zeichenerreicht. ”+“-ZeichenassoziiertderAutoraberehermitWortenwie ”Addieren“oder ”Hin- zufügen“ und nicht mit einer ”Erweiterung“.DaherwirddiesesZeichenvonZOLauch für das Hinzufügen eines Knotens verwendet.

Die Bildsprache der Outliner-Komponente funktioniert in hohem Maße über Formen. So ist auch der Gebrauch der unterschiedlichen Dreiecke zu verstehen wie der Abbildung 4.2.2 zu entnehmen ist. Das linke Dreieck wird dazu genutzt den Status des Knotens zu kommunizieren und öffnet oder schließt diesen bei Betätigung. Das umgekehrte Dreieck auf der anderen Seite ermöglicht das Aufklappen des erweiterten Inhaltes bzw. die Nutzung des Wikis. Da das Dreieck in Leserichtung hinter dem Text des Eingabefeldes steht, steht dieses Dreieck schon metaphorisch für zusätzlichen Inhalt. Die vier unterschiedlichen Dreiecke in der Werkzeuge-Box, impliziert durch entsprechende Zeichen, stehen für die Funktionen nach oben tauschen, Einrücken, nach unten tauschen und Ausrücken. Durch diese Verknüpfung wird ein relativ leicht erlernbares Idiom erreicht, welches auf der bekannten Metapher von Richtungen beruht.

Auch die abgebildete Werkzeuge-Box ist an ein Bedienelement eines herkömmlichen Programms angelehnt. Denn sie orientiert sich an einer Menuleiste, bewegt sich aber zu einer adäquaten Stelle. Durch die Positionierung ist eine intuitive Verbindung zwischen Funktionaliät der Werkzeuge-Box und dem entsprechenden Objekt hergestellt. Durch den Einsatz von Text für die einzelnen Werkzeuge kommt die Anwendung auch mit sehr großen Schriftgrößen zurecht und skaliert entsprechend. Dadurch ist eine gute Lesbarkeit gewährleistet.

Die fehlende Unterscheidung zwischen Anzeige- und Bearbeitungsmodus trägt eben- falls zu einem besseren Verständnis der Anwendung bei. Denn dadurch, dass man nicht durch einen Klick zwischen Modi hin- und herspringen muss, kann das bearbeitet werden, was man sieht und es wird das gespeichert was geschrieben wird. Dieses automatische Speichern erfolgt, durch die Verwendung von AJAX, ähnlich wie auf einem Blatt Papier fast automatisch (dort werden Notizen beim Schreiben ”gespeichert“) .Beim Wiki wird jedoch zwischen den zwei Modi unterschieden⁴⁰. Das Wiki ist über eine so genannte WikiSyntax nutzbar, welche sich auf wenige Auszeichnungsmöglichkeiten beschränkt und so eine größere Gruppe von Menschen mit weniger Lern- und Schreibaufwand an diesem System teilhaben lässt.

Beim Aufbau der Portalseite wurde auf eine Konsistenz der Platzierungen der einzelnen Elemente geachtet. Das Outline befindet sich immer im mittleren Bereich und relevante Aktionen befinden sich im Kasten rechts daneben. Der Platz für die Outlines ist entsprechend begrenzt. Er kann zwar durch Vergrößern des Browserfensters erweitert werden, jedoch sind die Eingabeboxen fürÜberschriften und kurze Texte gedacht. Für längere Texte ist das Wiki des Knotens vorgesehen.

Durch die Unterteilung der Interaktionselemente nach Interaktionskanälen wird eine semantische Organisation erreicht. Diese Interaktionskanäle werden durch das CMF bereitgestellt und wurden noch um Eigene durch eine Definition von Slots und Macros innerhalb der ZPT erweitert. So ist zum Beispiel bei der Organisation der Oberfläche auffällig, dass sich über dem Inhalt eine weitere Box befindet in der zum einen die aktuelle Position im Hypertextgeflecht angezeigt wird und zum anderen eine weitere Navigationsmöglichkeit bis hin zur Startseite gegeben ist ( Beispiel ist die ”Breadcrumbs“).Einanderes ”Undo“-BoxunterdemZOL-Werkzeugbzw.demInhalt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.8.: Organisation der Interaktionskanäle des Portals

Das Wegfallen von unsinnigen Interaktionsmöglichkeiten bei der Organisation der Oberfläche wurde bereits erwähnt. Falls doch fehlerhaft interagiert wird, ist es für die Verständlichkeit eines Programms wichtig, dass fehlerhafte Eingaben des Benutzers die- sem in einer adäquaten Weise mitgeteilt werden. Es wäre möglich die Fehlermeldungen von Python ungefiltert an den Nutzer weiterzuleiten, jedoch sind diese nur für Entwick- ler sinnvoll. Eine ÜbersetzungauchunterBerücksichtigung der angewandten Aktion ist daher notwendig. Für den Nutzer verständliche Fehlermeldungen werden daher an adäquater Position angezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.9.: Angemessene Fehlerbeschreibung an adäquater Position

Schließlich ist das ZOL Zope-Produkt mit Hilfedateien ausgestattet, die eine Verständlichkeit auch auf der Administratorseite erhöhen kann. Diese interne Dokumentation ist durch die interne Zope-Hilfe aufrufbar.

4.3.2.6. Bedienbarkeit

Bedienbarkeit und Verständlichkeit sind zwei Untermerkmale des Qualitätsmerkmales ”Benutzbarkeit“. Demzufolge ist eine AbgrenzungzumvorherigenAbschnittnichtimmer eindeutig möglich und einige Betrachtungen der Merkmale könnten beiden Merkmalen zugeordnet werden.

Die Bedienbarkeit von myideas.de unterscheidet sich nicht von der anderer Portale. Die gewohnten Interaktionsmöglichkeiten in Form von Links und Formularen bilden die Basis für Nutzeraktivitäten. Durch die Annäherung von ZOL an Desktop-Anwendungen und die dadurch zusätzlich entstehenden Bedienmöglichkeiten unterscheidet sich dessen Bedienbarkeit von der des Portals. Basis für die Interaktion sind zwar weiterhin die ge- wohnten Navigationsmittel - die Auswirkungen sind aber teilweise unterschiedlich. Zum Beispiel verändert das Fokussieren von Eingabeelementen über Eingaben der Maus oder das ”Springen“zwischenEingabefeldernmitderTabulator-Tastenichtnurdasaktive Element, sondern auch den Status der Anwendung. Dieses Beispiel zeigt, dass darauf geachtet wurde, dass gelernte Idiome der Bedienung von Internetprogrammen weiterhin nutzbar sind aber teilweise um zusätzliche Funktionalität erweitert wurden. Auf der an- deren Seite werden jedoch nicht die gleichen Erwartungen an eine Bedienbarkeit von Desktop-Anwendungen erfüllt, da die Tabulator-Taste meist für das Einrücken von Kno- ten bei Outliner-Programmen verwendet wird⁴¹. Der angewandte Ansatz ist also ein Konsens zwischen den Bedienbarkeiten beider Programmarten.

ZOL versucht Unzulänglichkeiten, die durch den Einsatz von AJAX entstehen durch ein Angebot alternativer Interaktionsmöglichkeiten wie zum Beispiel der Undo-Box oder Adressen, welche den Status der Anwendung wiederspiegeln, auszugleichen. Bezüglich des Gebrauches von AJAX ist noch zu sagen, dass AJAX nicht beim Versand von For- mulardaten genutzt wird. Es sollte aber ein Interaktionsmuster eingehalten werden. Da- her sollte diese Funktionalität noch durch den ”onSubmit“ Event-Handler implementiert werden.

Durch die Wiederverwendung von Seitenvorlagen entsteht eine einheitliche aufgebaute Benutzerschnittstelle. Da Mitglieder des Portals gleichzeitig Administratoren ihrer Inhalte sind, ist auf eine entsprechende Umgebung zu achten. Durch die Einheitlichkeit der Darstellung auch bei den administrativen Vorlagen von Zope entsteht für den Nutzer kein Bruch zwischen Administrationsumgebung und dem Portal⁴².

Einheitlich ist auch die Platzierung häufig benötigter Funktionen wie das Anlegen und Öffnen bzw. Schließen von Knoten. Entsprechende Links sind prominent platziert und nicht so häufig genutzte Zusatzfunktionen sind voreingestellt nicht sichtbar und können bei Bedarf hinzugefügt werden (Werkzeuge-Box). Dies, die Tatsache, dass Navi- gationsmöglichkeiten nur angezeigt werden, wenn diese Sinn machen und dass Funktiona- litäten nicht wiederholt angezeigt werden führen zu einer Entlastung und somit besseren Bedienbarkeit der Oberfläche.

4.3.3. Fehlerbehebung und Qualitätssicherung

Zope bietet Entwicklern einige Möglichkeiten, um Programmfehler zu beheben bzw. zu ”debuggen“.Das ”ControlPanel“vonZope,welchesdurchdasZMIzuerreichenist, stellt diverse nützliche aber eher auf den Bereich der Performanz spezialisierte Informa- tionen zur Verfügung. Eine andere Möglichkeit ist Zope während der Entwicklung im ”DebugModus“zubetreiben.DieskannzumBeispieldurchSetzeneinerentsprechen- den Umgebungsvariablen erreicht werden. Dieser Modus verringert die Performanz, da Zope bei jedem Aufruf die ZPT- und DTML-Dateien auf Änderungen überprüft. Im Debug-Modus bleibt Zope im Vordergrund der Terminal-Sitzung und die wichtigsten Logging-Ausgaben werden direkt auf im Terminal angezeigt. In Kombination mit der refresh-Funktionalität gibt es wenig Gründe den Server während der Produktentwicklung neu starten zu müssen.

Eine weitere Möglichkeit der Fehlerbehebung ist das ”interaktiveDebuggen“.Beidie- sem Ansatz wird der Python-Interpreter mit den aktuellen Zope-Objekten aufgerufen und mit diesen kann während einer interaktiven Sitzung gearbeitet werden. Eine beispielhafte Sitzung ist folgend aufgeführt.

Abbildung in dieser Leseprobe nicht enthalten

In der ersten Zeile wird das interaktive Debuggen durch das Kommandozeilen-Werkzeug zopectl gestartet. Die eigentliche Python-Sitzung startet in Zeile 3. Man kann erkennen, dass zuerst alle verfügbaren Oberobjekte dieser Sitzung ermittelt werden und dann, ähn- lich wie in einem Dateisystem, auf das Outline test des Nutzers schendel des Portals myideas zugegriffen wird. Das Outline speichert die Wurzel und mittels der implemen- tierten Fassade 0 kann auf den ersten Unterknoten zugegriffen werden, welcher bei einer Ausführung seinen Inhalt in Form einer Unicode-Zeichenkette ausgibt.

Ein beispielhaftes Refactoring sei im Zuge des Einsatzes von ZOL unter Zope 2.7 aufgeführt⁴³. Der Grund für diese Maßnahme war ein Unterschied bei der Verarbeitung von Datei-Uploads. Daher musste eine Angleichung in der Datei ”outline.py“stattfinden.

Abbildung in dieser Leseprobe nicht enthalten

Dieser Ausschnitt der Methode zeigt das Umwandeln von einem ”FileUpload“-Objekt (Definition im Modul ZPublisher.HTTPRequest) zu einer Zeichenkette. In Zeile 2 wird zuerst geprüft, ob der Parameter OPML als Zeichenkette vorliegt, wenn das nicht der Fall ist, wird eine entsprechende Konvertierung vorgenommen.

Bei der Entwicklung von ZOL wurde mit einer Validierung durch Unit-Tests gear- beitet. Der im Anhang auf Seite 105 aufgeführte Ausschnitt aus der Datei ”tests.py“, welche die gesamten Unit-Tests enthält, zeigt exemplarisch drei Tests, um die Funktionsweise zu erläutern. Erkennbar ist, dass ein Großteil der Anweisungen die Klasse OutlinerTestCase definiert. Diese wiederum definiert drei Methoden, die unterschiedliche Funktionalitäten des Outlines testen. Diese drei und die Methode Vorbereitung werden während des Testens bzw. dem Abarbeiten der Methode Testen ausgeführt. Bei erfolgreichen Testen wird eine Ausnahme ( ”AssertionError“)miteinerFehlermel- dung entsprechend der assert Anweisungen ausgegeben. Als Beispiel soll der Test test_marshalling erklärt werden. In der Zeile 20 wird zuerst das gesamte Outline in OPML überführt und zwei Zeilen später in einem neuen Outline importiert. Getestet wird in den beiden nächsten Zeilen zum einen auf eine Wohlgeformtheit des exportierten OPML und zum anderen darauf ob das exportierte OPML des importierten Outlines gleich dem anfangs exportierten OPML ist.

5. Schlussfolgerungen und Ausblick

Die für Einsteiger einfach zu nutzenden Technologien haben dem WWW zu einem rasan- ten Aufschwung verholfen und es in wirtschaftlichen und privaten Teilen der Gesellschaft etabliert. Im Abschnitt ”Entwicklung“(Kapitel 2.2)wurdedeutlich,dassdieseTechnolo- gien allmählich erweitert wurden, um neuen Anforderungen entsprechen zu können. Vor dem Hintergrund der erwähnten Entwicklung des WWW hin zu einem Anwendungsme- dium geht dies sogar so weit, dass Internetprogramme mit der Zeit auch in Bereichen betrieben wurden in denen vorher lediglich herkömmliche Anwendungen eingesetzt wur- den. Außerdem ist zu beobachten, dass aufgrund derzeitiger Entwicklungen wie AJAX der Unterschied zwischen Desktop-Anwendungen und Internetprogrammen für den Nut- zer kleiner wird.

Diese Vermischung wird auch in Publikationen diskutiert, denn Browser werden manch- mal sogar als das ”Betriebssystem“fürunternehmensweiteAnwendungenbezeichnet (vgl. Frank,2005). Ob solche zeitgeistlichen Aussagen wissenschaftliche Relevanz be- sitzen, soll nicht näher geklärt werden. Fest steht aber dass Internetprogramme oft elementare Teile für unternehmensweite Lösungen zur Verfügung stellen. Um den An- forderungen solcher umfangreicher Anwendungen genügen zu können, hat die Komple- xität von Internetprogrammen mit der Zeit zugenommen (vgl. Abbildung auf Seite 5). Um diese wachsende Komplexität verwalten zu können, haben sich Hersteller stärker hin zu software-technischen Methoden ausgerichtet. Dies wird beispielsweise durch die Entwicklung des Profils eines Entwicklers von Internetprogrammen bestätigt. Dieses ist heutzutage informatischer ausgeprägt und ergänzende Fertigkeiten wie Bildbearbeitung, Animationserstellung, Web-Design o.ä. wurden mit der Zeit weniger wichtig. Es ist al- so eine Spezialisierung zu erkennen, um die umfangreichen, weit gestreuten und viele Wissenschaftsbereiche umfassenden Aufgaben, die bei der Umsetzung von Internetpro- grammen anfallen, lösen zu können.

Das umgesetzte Projekt illustrierte aufbauend auf den wissenschaftlichen Abschnitten dieser Arbeit viele dieser Aufgaben. Es hat deutlich gemacht, dass Internetprogram- me komplexe Anwendungen sein können, die unter Zuhilfenahme von Frameworks und software-technischen Methoden umsetzbar sind und qualitativen Betrachtungen stand- halten. Dabei stehen Entwickler von Internetprogrammen viele Werkzeuge bereit, um die Qualität ihrer Anwendungen sichern zu können. Speziell die Methodik des Testens stellt ein passendes Mittel für die Gewährleistung bestimmter Funktionalität dar und wurde daher besprochen und durch die Integration von Unit-Tests in das Internetprogramm eingebunden.

Angesichts des geschilderten Ersatzes von Desktop-Anwendungen und der Angleichung der beiden Programmarten ist der Transfer der alten DIN Norm 66272 reizvoll, da diese ursprünglich für Desktop-Anwendungen konzipiert wurde. Durch den Abschnitt ”Qualitätsmerkmale“(Kapitel 2.3.2)wurdedeutlich,dasstrotzderarchitektonischen Unterschiede beider Ansätze viele Berührungspunkte existieren. Daher konnten für die Qualitätsmerkmale entsprechende Ausarbeitungen angelegt werden. Einige Qualitätsmerkmale wurden auch nicht zu einer näheren Betrachtung herangezogen, da die Unterschiede beider Programmarten offensichtlich gering sind (beispielsweise Analysierbarkeit, Reife, Stabilität). Trotzdem war eine Zuordnung der beiden Begriffswelten oft schwierig und teilweise sind Prioritäten durch die Norm falsch eingeschätzt worden (Sicherheit ist lediglich Untermerkmal). Um zukünftig die von der Norm vorgeschlagenen Qualitätsmerkmale in Bezug auf Internetprogramme nutzen zu können, sollte über eine Anpassung der Formulierung und Hierarchie nachgedacht werden.

Diese eingeschränkte Empfehlung impliziert, dass trotz der Annäherungen zwischen den beiden Programmarten immer noch elementare Unterschiede existieren. Angetrieben vielleicht durch eine gewisse Überheblichkeit,diefälschlicherweise durch den Erfolg von Internetprogrammen entstanden ist, werden derzeit viele Versuche unternommen Desktop-Anwendungen zu ”portieren“(vgl.beispielsweise ”GoogleOffice“).Solche Massnahmen haben nicht nur positive Auswirkungen. Trotz der unterschiedliche Idiome (z.B. der Doppelklick) zwischen beiden Programmarten, wird die Unterscheidbarkeit im- mer geringer. Der Nutzer könnte dadurch immer wieder in seiner Arbeit gestört werden. Wenn eine Alternative zu einer Desktop-Anwendung für den Nutzer keinen klar erkenn- baren Vorteil darstellt, sollte von einer Portierung abgesehen werden. Es gab Desktop- Anwendungen schon vor Computernetzwerken und dem Internet und Nutzer haben diese Anwendungen produktiv nutzen können. Zum Beispiel könnte eine Office-Anwendung, die nur über das Internet betrieben wird, dem Nutzer ein Gefühl von Abhängigkeit vermitteln, da vielleicht keine ausreichende Grundfunktionalität ohne Datentransfer zur Verfügung gestellt werden kann. Daher kann die Forderung formuliert werden, dass Inter- netprogramme herkömmliche Anwendungen ergänzen und nicht ersetzen sollten, wenn nicht nahezu dauerhaft das Internet verfügbar ist. Eine zusätzliche Untersuchung der Auf- gabenangemessenheit sollte immer entscheiden, welcher Ansatz besser für ein bestimmtes Problem ist.

In dieser Hinsicht ist noch bemerkenswert, dass weiterhin Potential beim Ansatz von Internetprogrammen vorhanden ist. Das WWW setzt nur einen Ausschnitt des eigentli- chen Hypertextmodells um. Erweiterungen wie beispielsweise Rückwärtslinks (vgl. Kap- pel u.a., 2004,108), welche den Klickpfad berücksichtigen sind also denkbar¹. Auch die aufgezeigten Potentiale und Technologien des Semantischen Internets (vgl. Seite 42) können Internetprogramme beispielsweise durch Integration von Business Intelligence² Architekturen unterstützen.

Beide Ansätze haben Vorteile und Entwicklungsmöglichkeiten und es ist nicht abzuse- hen, dass ein Ansatz den anderen in naher Zukunft verdrängt. Daher sollten Entwickler aus beiden Lagern entstehende Synergieeffekte identifizieren und nutzen (vgl. Speirs, 2005). Aufgrund dieser parallelen Existenz beider Programmarten kommen Mechanis- men zur Synchronisation eine große Wichtigkeit zu. Die derzeitigen Fusionen von Soft- warehäusern³ beider Lager bestätigt die Nachfrage nach kombinierten Einsatzmöglichkei- ten. Viele Nutzer möchten die nutzen und so beide ”online“ erstellten Inhalte nativ in Desktop-Anwendungen ”Welten“effektivundeffizientverbinden.VordiesemHintergrund ist der Trend der Softwarehersteller hin zu offenen Standards positiv zu bewerten, da so eine Interoperabilität hergestellt werden kann. Beispielsweise bedienen sich schon viele Desktop-Anwendungen Internetstandards wie HTML, CSS und XML, XLST, um Teile der Darstellung zu definieren. Bei Internetprogrammen gibt es zusätzlich zu den herkömmlichen Ansätzen Versuche Darstellungssprachen, die für Desktop-Anwendungen entwickelt wurden (beispielsweise XUL und XAML⁴ ), zu nutzen. Dies lässt sich auf die Schwäche von HTML als anwendungsorientierte Darstellungssprache zurückführen.

Diese ist symptomatisch für den derzeitigen Zustand von Internetprogrammen. Die eingangs genannte Stärke der Technologien des WWW hat zwar ein anfängliches rasan- tes Wachstum ermöglicht, bremst nun aber die weitere Entwicklung aus. Die meisten derzeitigen Entwicklungen haben nicht geholfen einen klaren und standardisierten Weg in die Zukunft des Internets und der Internetprogramme aufzuzeigen, sondern haben sogar mehr offene Fragen geschaffen. Es bleibt daher abzuwarten, welche Entwicklungen die Standards durchlaufen werden oder ob sich neue Standards etablieren. Die techno- logische Unterschiedlichkeit beider Programmarten sollte Verantwortliche beider Lager jedenfalls nicht davon abhalten zusammen an Lösungen zu arbeiten und so zukünftige Technologien und Standards gemeinsam zu formen.

Quellenverzeichnis

[Antoniou u. van Harmelen 2004]

Antoniou, G. ; Harmelen, F. van: A Semantic Web Primer. Cambridge, Massachusetts London, England : The MIT Press, 2004. - 6, 7 S

[Balzert 1998]

Balzert, Helmut: Lehrbuch der Software-Technik - Software-Management, Software Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag, 1998

[Balzert 2001]

Balzert, Helmut: Lehrbuch der Software-Technik (2. Auflage). Spektrum Akademischer Verlag, 2001

[Berners-Lee u. a. 2001]

Berners-Lee, Tim ; Hendler, James ; Lassila, Ora: Scientific Ameri- can: The Semantic Web. http://www.sciam.com/print version.cfm?articleID= 00048144-10D2-1C70-84A9809EC588EF21. Version: 05 2001

[Bernstein u. Robertson 2002]

Bernstein, M. ; Robertson, S.: Zope Bible. Hungry Minds, 2002

[Bosworth 2005]

Bosworth, Alex: Ajax Mistakes. http://alexbosworth.backpackit.com/pub/ 67688. Version: 06 2005

[Butler 2005]

Butler, Dr Mark H.: Is the Semantic Web hype? HP, 2005

[Chancen 2002]

Chancen, Stiftung D.: Schwerbehindertenstatistik 2002. http://www. digitale-chancen.de/content/stories/index.cfm/key.1528/secid.13/ secid2.19. Version: 01 2002

[Chisholm u. a. 1999]

Chisholm, Wendy ; Vanderheiden, Gregg ; Jacobs, Ian: Web Content Accessibiliy Guidelines. http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505. Version: 05 1999

[Connection 2005]

Connection, Apple D.: Dynamic HTML and XML: The XMLHttpRequest Object. http://developer.apple.com/internet/webcontent/xmlhttpreq.html. Version: 06 2005

[Cooper u. Reimann 2003]

Cooper, A. ; Reimann, R.: About Face 2.0 - The Essentials of Interaction Design. Wiley, 2003

[Davies u. a. 2003]

Davies, J. ; Fensel, D. ; Harmelen, F. van: Towards The Semantic Web - Ontologydriven Knowledge Management. John Wiley, 2003

[Demunter 2005]

Demunter, Christophe: Internetnutzung in Europa. Statistikreport, 6 2005

[DESTATIS 2005]

DESTATIS: Informationstechnologie in Unternehmen und Haushalten 2004. DESTA- TIS, 2005

[Diller 1998]

Diller, Hermann: Vahlens großes Marketing Lexikon. dtv, 1998

[DIN 1994]

DIN: DIN 66272 Bewerten von Softwareprodukten. Beuth Verlag, 1994

[Eckstein 2004]

Eckstein, Jutta: Agile Softwareentwicklung im Großen. dpunkt.verlag, 2004

[Everitt 2001]

Everitt, Paul: Introducing Zope. Paul Everitt, 2001

[Frank 2005]

Frank, Jordan: Is AJAX Here to Stay. http://www.xml.com/pub/a/2005/10/05/ ajax-web-20-soa.html. Version: 10 2005

[Ginige u. Lowe 2001]

Ginige, A. ; Lowe, D.: Web Engineering - An Introduction. IEEE Multimedia, 2001

[heise 2005a]

heise: KarstadtQuelle setzt auf das Internet. http://www.heise.de/newsticker/ meldung/66211. Version: 11 2005

[heise 2005b]

heise: KarstadtQuelle wächst online. http://www.heise.de/newsticker/meldung/ 63347. Version: 08 2005

[Kappel u. a. 2004]

Kappel, G. ; Pröll, B. ; Reich, S. ; Retschitzegger, W.: Web Engineering. dpunkt.verlag, 2004

[Kemper u. Eickler 2004]

Kemper, Alfons ; Eickler, Andre: Datenbanksysteme. Oldenbourg, 2004

[Koch ]

Koch, Peter-Paul: Javascript - General Introduction. http://www.quirksmode.org/ js/intro.html

[Latteier u. a. 2005]

Latteier, A. ; Pelletier, M. ; McDonough, C. ; Sabaini, P.: The Zope Book (2.6 Edition). Zope Corporation, 2005

[Letourneau 2003]

Letourneau, Chuck: Starling Access Services - Accessible Web Design. http:// www.starlingweb.com/webac.htm. Version: 08 2003

[Meinel u. Sack 2004]

Meinel, C. ; Sack, H.: WWW. Springer, 2004

[Merikallio u. Pratt 2003]

Merikallio, Bill ; Pratt, Adam: Warum Layout mit Tabellen dumm ist: Probleme definiert, Lösungen angeboten. http://seybold.jan-andresen.de/. Version: 2003

[Myers 2004]

Myers, G.J.: Methodisches Testen von Programmen. Oldenbourg, 2004

[O’Reilly 2005]

O’Reilly, Tim: What Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software. http://www.oreillynet.com/lpt/a/6228. Version: 09 2005

[Petrasch 1998]

Petrasch, Roland: Einführung in das Software-Qualitätsmanagement. Logos Verlag Berlin, 1998

[Raggett 2005]

Raggett, Dave: HTML Tidy Library Project. http://tidy.sourceforge.net/. Version: 02 2005

[Saffer 2005]

Saffer, Dan: The Web 2.0 Metaphor. http://www.odannyboy.com/blog/new archives/2005/10/the web 20 meta.html. Version: 10 2005

[Schwarze 1995]

Schwarze, Jochen: Systementwicklung. NWB-Studienbücher Wirtschaftsinformatik, 1995

[Spainhour u. Eckstein 1999]

Spainhour, S. ; Eckstein, R.: Webmaster in a nutshell. O’Reilly, 1999

[Speirs 2005]

Speirs, Fraser: Model-View-Controller in Web 2.0. http://www.oreillynet.com/ pub/wlg/8032. Version: 10 2005

[W3C 2005]

W3C: The W3C Markup Validation Service. http://validator.w3.org/. Version: 10 2005

[Watch 2002]

Watch, CMS: Zope Content Management Framework. http://www.cmswatch.com/ Feature/61-Zope. Version: 02 2002

[webhits.de 2005]

webhits.de: WebHits - Web-Barometer: Marktanteile und Marktentwicklung. http: //www.webhits.de/deutsch/webstats.html. Version: 11 2005

[Weikum 2004]

Weikum, Gerhard: Effiziente Informationssuche im Web der Zukunft. http://www.mpg.de/bilderBerichteDokumente/dokumentation/jahrbuch/2004/ informatik/forschungsSchwerpunkt1/index.html. Version: 11 2004

[Wikipedia 2005a]

Wikipedia, die freie E.: Entwurfsmuster. http://de.wikipedia.org/w/index.php? title=Entwurfsmusteroldid=9866430. Version: 10 2005

[Wikipedia 2005b]

Wikipedia, die freie E.: Ontologie. http://de.wikipedia.org/w/index.php? title=Ontologie&oldid=11019244. Version: 11 2005

[Wikipedia 2005c]

Wikipedia, die freie E.: Taxonomie. http://de.wikipedia.org/wiki/Taxonomie. Version: 10 2005

[Wikipedia 2005d]

Wikipedia, die freie E.: Unit-Test. http://de.wikipedia.org/w/index.php? title=Unit-Test&oldid=10155311. Version: 10 2005

[Wikipedia 2005e]

Wikipedia, die freie E.: Web Services. http://de.wikipedia.org/wiki/Web Services. Version: 11 2005

[Wurzenberger 2000]

Wurzenberger, Georg: Aspekte moderner Web-Applikationen, Technische Universität Graz, Diplomarbeit, 2000

[Zope.org ]

Zope.org: System Architecture. http://www.zope.org/Products/CMF/docs/ design/system architecture/

[Zope.org 2005]

Zope.org: Using Zope Page Templates. http://www.zope.org/Documentation/ Books/ZopeBook/2 6Edition/ZPT.stx. Version: 2005

Abbildungsverzeichnis

2.1. Kommunikation des Menschen mit dem WWW ¨uber Internet-Programme

2.2. Entwicklung von Internetprogrammen (vgl. Kappel u. a., 2004, Seite 5)

2.3. Transaktionsablauf (engl. ”request cycle“)

2.4. Beispielhafter Transaktionszyklus mit POST

2.5. HTTP-Transaktionszyklus bei Sitzungen auf Basis von Cookies (vgl. Meinel u. Sack, 2004, 780)

2.6. Einordnung der Qualit¨atssicherung und beispielhafte Techniken

2.7. Summationseffekt von Fehlern in einem Projekt (vgl. Balzert, 1998)

2.8. Einflussfaktoren auf Tests (vgl. Kappel u. a., 2004, Seite 174)

2.9. Reaktion von Teilen der ”iTunes“ Benutzerschnittstelle auf Interaktion

3.1. Durch den AJAX-Ansatz erweiterter Transaktionszyklus

3.2. Screenshot des ”JavaScript Console“ des Firefox

3.3. Ressourcen, Beziehungen und deren Identifikation durch eine URL

3.4. Visualisierung eines Ausschnittes einer Ontologie (vgl. Weikum, 2004)

4.1. Zope Architektur (vgl. Latteier u. a., 2005, Seite 44)

4.2. Weboberfl¨achen der gleichen Zope Installation

4.3. Die Akteure des Portals (oben) bzw. Rollen von Zope und deren Rechte (unten)

4.4. Umsetzung eines Statusdiagramms im portal workflow Tool

4.5. Outliner des Webpublishing-Programms ”Radio Userland“ (der Knoten ”Austauschbarkeit“ ist geschlossen und hat Unterknoten)

4.6. Interoperabilit¨at mit Desktop-Anwendungen

4.7. Wiederverwendbare Seitentypen des Portals

4.8. Organisation der Interaktionskan¨ale des Portals

4.9. Angemessene Fehlerbeschreibung an ad¨aquater Position

A. Umfangreichere Quellcode Beispiele

Dieser Ausschnitt aus der Datei ”tests.py“, welche die gesamten Unit-Tests enth¨alt, zeigt exemplarisch drei Tests:

Abbildung in dieser Leseprobe nicht enthalten

Die folgenden Programmanweisungen sind eine Zusammenfassung der Änderungen, die für die Verwendung eines Objekttyps innerhalb des CMF gemacht werden müssen bzw. die nötigen Anweisungen für die Definition eines einfachen Inhaltstyps.

Abbildung in dieser Leseprobe nicht enthalten

Die Importanweisungen des Beispiels funktionieren für Zope 2.7.5 korrekt. Bei neueren Versionen sind Anpassungen der Paketpfade notwendig.

Die Datei ” init .py“ muss wie folgt modifiziert werden. Auf diese Weise ist das Produkt sogar sowohl als Objekttyp als auch als Inhaltstyp nutzbar.

Abbildung in dieser Leseprobe nicht enthalten

B. CD-Inhalte

Im folgenden werden die Inhalte der beiliegenden CD kurz beschrieben. Diese Inhalte sind auf der CD durch eine Ordnerstruktur, die sich an der Kapitelhierarchie orientiert, eingeteilt. Allgemein lässt sich sagen, dass sich alle Internetquellen in Form von PDF- Dokumenten, sonstige frei verfügbare Quellen und Quelltexte auf der CD befinden.

1 Einleitung Enthalten sind in das Format PDF umgewandelte Internetquellen und sta- tistische Quellen.

2 Internetprogramme Enthalten sind in das Format PDF umgewandelte Internetquel- len, eine andere Diplomarbeit und die ”Human Interface Guidelines “ von Apple.

3 Derzeitige Entwicklungen Enthalten sind in das Format PDF umgewandelte Inter- netquellen.

4 Angewandte Programmierung Enthalten sind in das Format PDF umgewandelte In- ternetquellen, die DTD von OPML, die Dateien zum Vergleich des vorlagenbasier- ten und skriptbasierten Ansatzes, die Datei ” BaseRequest.py “ der Zope Distribu-tion und das Zope Buch.

5 Schlussfolgerungen und Ausblick Enthalten sind in das Format PDF umgewandelte Internetquellen.

ZOL Zope Produkt In diesem Ordner befindet sich der für diese Arbeit entwickelte Inhaltstyp ”ZOL“.AlleQuellcodeBeispieleausdemKapitel ”Umsetzung“(Seite 69) sind in diesem Ordner enthalten. Dieses Zope Produkt kann durch einfaches Kopieren in den Zope Produkte Ordner installiert werden.

Latex Quellen Enthalten sind die LATEX Quellen dieser Diplomarbeit.

diplom.pdf Dieses PDF Dokument ist die Arbeit in digitaler Form und kann zum Bei- spiel für Suchen im kompletten Text genutzt werden.

diplom print.pdf Dieses PDF Dokument ist die Arbeit in digitaler Form und ist mit Bildern höherer Auflösung ausgestattet. Diese Version sollte zum Druck verwendet werden.

myideas.mov Dieses Video beschreibt wichtige Merkmale des erstellten Projektes in Bild und Ton.

[...]

---

¹ Diese Wortwahl basiert auf einer Anlehnung an die Softwarekrise der 60er Jahre.

² Eine Nutzung ist gemäß der Angaben der Creative Commons Lizenz (http://creativecommons.org/ licenses/by-nc-sa/2.0/de/) zulässig.

¹ Diese sind nicht mit den Dateibrowsern des Betriebssystems zu verwechseln.

² Wenn man auf Basis dieser Metapher Internetprogramme definieren wollte, könnte man sagen, dass ein Internetprogramm das Wasser und die Wellen zum

³ Mit ”surfen“bereitstellt. ”Desktop“ wird der physikalisch lokal vorhandene Computer bezeichnet.MitDesktop-Programm sind daher Programme gemeint, welche auf einem PC ablaufen.

⁴ Internetprogramme werden auch oft als wie zum Beispiel ”Web-Anwendungen“ bezeichnet. Es gibt noch weitere Namen ”Web-Applikation“ oder entsprechende Kurzformen(”Web-App“).

⁵ Es gibt aber auch noch andere mögliche Clients.

⁶ Eine Kommunikation im Internet ist aber nicht nur auf HTTP beschränkt. Es gibt weitere solche Kom- munikationsschemata (SMTP, RTSP), die sich auf andere Formen des Datenaustausches spezialisiert haben.

⁷ In dem Beispiel wäre es auch möglich den Kopfbereich mit dem Tag <head/> abzukürzen.

⁸ Zusätzlich zu GET und POST gibt es noch weitere Methoden - zum Beispiel weniger gebräuchliche Methoden.

⁹ Dazu werden diese an die Adresse (URL) in der Form http://www.adresse.org?Monat=1&Tag=2 über- mittelt

¹⁰ Die englische Übersetzung lautet ”StructuredQueryLanguage“(SQL).

¹¹ Durch die wenigen von HTML bereitgestellten Instrumente haben Web-Designer lange Zeit versucht, mit Tabellen und transparenten Bildern Layouts, die sich wie an Gitternetzlinien ausrichten zu errei- chen. Durch die inkorrekte Nutzung von Tabellen kam es zu einer Vermischung zwischen Präsentati- on und Struktur. Außerdem waren diese Auszeichnungen semantisch falsch (vgl. Merikallio u. Pratt, 2003).

¹² Die Definition von SGML umfasst 500 Seiten, jene von XML nur 26.

¹³ Ein Beispiel ist der ”OpenBusinessClub“(http://openbc.com).

¹⁴ Oft auch aufgrund einer entsprechend von den Betreibern gewählten Internetadresse.

¹⁵ Aus der DIN EN ISO 8402, die in die DIN 9000 eingeflossen ist.

¹⁶ Nähere Informationen bezüglich der ”CapabilityMaturityModelIntegration“kannunterderAdresse http://www.sei.cmu.edu/cmmi/ nachgelesen werden.

¹⁷ Siehe auch http://en.wikipedia.org/wiki/Iterative and incremental development

¹⁸ Vollständige Tests sind durch die Vielzahl von Möglichkeiten meist unmöglich.

¹⁹ http://wilshipley.com/blog/2005/09/unit-testing-is-teh-suck-urr.html

²⁰ ”Browsing-Technik“schließtauchBraille-Zeilenu.ä.spezielleEin-und Ausgabegeräte mit ein.

²¹ http://www.webstandards.org/about/

²² Englischer Originaltext (siehe Chisholm u. a. (1999)).

²³ 66.3% aller Browser sind mit dem ”ShockwaveFlash“Plug-Inausgestattet(webhits.de, 2005).

²⁴ Natürlich ist Aktualität auch nicht gleichbedeutend mit totaler Sicherheit - die potentiell vorhandenen Sicherheitslücken sind nur noch nicht solange bekannt wie bei älterer Software.

²⁵ http://www.heise.de/security/dienste/browsercheck/demos/

²⁶ Andersherum bieten Desktop-Programme oft die Möglichkeit an HTML zu exportieren. Eine Export- Möglichkeit in ein ausführbares Internetprogramm konnte aber nicht gefunden werden.

²⁷ Scalable Vector Graphics

²⁸ Mathematical Markup Language

²⁹ Outline Processer Markup Language

³⁰ URL sind eine Untermenge.

³¹ Einige Python-Programmierrichtlinien verbieten ”Star-Imports“ (fromfooimport*) -eine häufige Fehlerquelle.

³² Durch die Abkürzung werden die genutzten Softwarepakete spezifiziert (Linux Apache MySQL PHP).

³³ Aus Kostengründen zu integrierende ältere Systeme.

³⁴ http://www.apple.com/de/macosx/overview/aquauserinterface.html

³⁵ http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/

³⁶ Dies hat auch positive Seiteneffekte für fremdsprachige Besucher.

³⁷ Breadcrumbs (dt. ”Brotkrümmel“, die zur aktuellen Position im Geflecht führen - wahrscheinlich ange- lehnt an ein bekanntes Märchen) oder Hauptnavigation sind zwei Beispiele von Interaktionskanälen.

³⁸ Kontraproduktive Überfrachtung mit Funktionalität.

³⁹ Jede Klasse erhält eine Box in der Oberfläche und jede Funktion einen Knopf.

⁴⁰ Accessibility ist eine Untermenge von Usability.

⁴¹ Zum Einstieg sei folgende Internetadresse genannt: http://www.useit.com/alertbox/20021125.html

⁴² Dieses Beispiel gilt unter anderem für das CMS Typo3.

⁴³ Näheres kann unter der Adresse http://www.apple.com/itunes/ erfahren werden.

¹ Ein Beispiel ist unter der Adresse http://www.mollerus.net/development/javascript/frameset2. cfm zu sehen.

² Diese Nutzung ist unter der Adresse http://www.skybuilders.com/Users/Derek/research/ clientjshttp.html beispielhaft erklärt.

³ Die aus diesem Grunde von Google entwickelte JavaScript Datei ”XSLT.js“ermöglichtähnlicheFunk- tionalitäten wie der eigentliche Standard. Die hängt stark von den eingesetzten Browsern ab (vgl. http://blogs.ebusiness-apps.com/dave/?p=40).

⁴ Aufgrund der Sicherheitsrichtlinien der Browser müssen diese jedoch von der selben Domain bereitgestellt werden.

⁵ Denn ungefähr 10% der Nutzer haben kein JavaScript aktiviert (W3C Statistik)

⁶ http://www.cgisecurity.com/lib/XmlHTTPRequest.shtml

⁷ Die entsprechenden Dateien können direkt von der Adresse http://www.alistapart.com/d/ jslogging/fvlogger.zip bezogen werden.

⁸ http://www.flickr.com/

⁹ http://radar.oreilly.com/archives/2005/05/flash is ajax o.html

¹⁰ http://zingzoom.com/ajax/ajax with image.php

¹¹ Eine Erlätuerung ist unter der Adresse http://pr.efactory.de/d-index.shtml zu finden.

¹² Die Suchmaschine ”Google“ bietet dem Nutzerzusätzliche Befehle wie define :o.ä.an,umdasErgeb- nis gleich eine Antwort anzeigen zu können.

¹³ Dieser als ”ScreenScraping“bezeichneteAnsatzwurdez.B.mitPERLModulenwiezumBeispiel ”HTML::Template“umgesetzt.

¹⁴ Der Name ist ungünstig gewählt, da eine Verwandtschaft zur Validierungsfunktionalität von XML- Schema impliziert wird.

¹⁵ http://www.w3.org/DesignIssues/Notation3

¹⁶ ”DieOntologieisteinephilosophischeDisziplin,diesich(primär)mitdemSein,demSeiendenals solchem und mit den fundamentalen Typen von Entitäten beschäftigt.“ (Wikipedia,2005 b)

¹⁷ ”DieTaxonomieistdieEinteilungvonDingen,insbesondereOrganismen,inTaxa(Sing.:Taxon) (Gruppen)“ (Wikipedia,2005c)

¹⁸ http://www.w3.org/TR/owl-ref/

¹⁹ Das erwähnte Dateiformat OPML wird mittlerweile auch zur Auflistung mehrerer RSS-Feeds genutzt, um diese zwischen Newsreadern austauschen zu können.

²⁰ Es gibt auch Ansätze, welche versuchen auf Basis von XHTML Formate wie RSS zu realisieren (vgl. http://www.microformats.org/).

²¹ Für nähere Informationen sei auf die Internetadresse http://dublincore.org verwiesen.

²² Auf Pings basierender automatischer Benachrichtigungsdienst, der die Primärquelle über Zitationen informiert.

²³ http://del.icio.us

²⁴ http://www.foaf-project.org/

¹ Das Internetprogramm ist unter der Adresse http://www.myideas.de zu finden.

² Eine Liste ist unter der Adresse http://www.zope.org/Resources/ZopePowered/ zu finden.

³ Es ist zum Beispiel möglich Zope durch einen ”Apache“Server zu betreiben.

⁴ Der entsprechende Quelltext von Zope 2.7.5 befindet sich auf der CD.

⁵ Dieses Softwarepaket kann von der Adresse http://cmf.zope.org bezogen werden. Es ist empfehlens- wert sich dieses Paket herunterzuladen, da im weiteren Verlauf näher auf die Inhalte eingegangen wird.

⁶ Nähere Informationen unter der Adresse http://plone.org

⁷ http://zpt.sourceforge.net/

⁸ Mit DTML können Email-Nachrichten generiert werden - was aber auch mit Python-Skripten möglich ist.

⁹ Zum Beispiel kann dies über das CMF erfolgen, welches selber ein Produkt ist.

¹⁰ Digital Creations verwaltet unter der Adresse http://zope.org/Products eine Liste von frei verfügba- ren Produkten.

¹¹ Allgemein lautet der Pfad meist Zope Wurzelordner/ZopeInstanzname/Products/

¹² Auf die Erstellung zusätzlicher Tools für das CMF wird nicht eingegangen.

¹³ Eine Weiterentwicklung sind die ”Archetypes“ von Plone.

¹⁴ Daher kommt auch der Name der FTI. Eine Fabrik ist ein Begriff aus der Software-Modellierung und bezeichnet Programmanweisungen, die dazu genutzt werden können Instanzen anzulegen.

¹⁵ http://www.dzug.org/Members/Raphael/MonkeyPatching

¹⁶ Falls die Notation der Vererbung nicht geläufig sein sollte, sei auf die Abbildung 4.3 verwiesen, welche die Rechte oft verwendeter Benutzergruppen zuordnet. Zusätzlich sei auf die genauere Beschreibung von Benutzergruppen von Seite 80 verwiesen.

¹⁷ Eine Beschreibung der nutzbaren Funktionalitäten wird im Kapitel 4.3 gegeben.

¹⁸ Eine Liste einiger verfügbarer Outliner: http://john.redmood.com/organizers.html

¹⁹ Die Syntax ist vielen aber immer noch zu umständlich (siehe auch http://writeboard.com).

²⁰ In der ”UnifiedModelingLanguage“(UML)wirdeinsolcherSachverhaltmiteinerKompositionbe- schrieben.

²¹ Die ersten Versionen wurden nicht mit Zope, sondern mit

siert. ”CherryPy“(http://cherrypy.org) reali-siert.

²² Dies ist in den meisten Fällen so. Bei zum Beispiel ästhetisch anspruchsvollen Seiten kann es aber auch vorkommen, dass ”rückwärts“ entwickelt wird.

²³ Speziell für Internetprogramme wurde das Muster sogar zum MVC2 weiterentwickelt.

²⁴ Der Quellcode des realisierten Zope Produktes befindet sich auf der beiliegenden CD.

²⁵ Diese anfänglich schwierig zu durchschauende Notation ist eine verkürzte Schreibweise einer Schleife in der Bedingungen getestet werden. Diese kompakte Notation liest sich fast wie ein englischer Satz.

²⁶ Die Neugierde, ob die Möglichkeit solch einer Nutzung besteht, stand bei diesem Ansatz jedoch im Vordergrund ;-)

²⁷ http://www.css4you.de/

²⁸ Portable Network Graphic

²⁹ http://myideas.de/MeinOutline/ oder http://myideas.de/MeinOutline/index html

³⁰ Diese Vorlage ist in der ZODB gespeichert.

³¹ Aufgrund dieser Gesetzmäßigkeit bieten viele Browser die Definition von persönlichen Stylesheets an. Diese Funktionalität wird oft von sehschwachen Menschen genutzt, um die Schriftgröße der angezeig- ten Seite zu erhöhen.

³² Um die Konformität zu wahren, sollen noch Definitionslisten ausprobiert werden.

³³ http://de.selfhtml.org/html/text/listen.htm

³⁴ Eine bessere Steuerung wäre über ”Decorator“möglich(http://www.python.org/peps/pep- 0318. html). Auf die praktizierte Weise wird der Entwickler zu einem Kommentarstil gezwungen.

³⁵ http://www.opml.org/spec

³⁶ http://static.userland.com/gems/radiodiscuss/opmlDtd.txt

³⁷ Eine Erläuterung wird aus fächerübergreifenden Gründen nicht vorgenommen.

³⁸ Bei einer versuchten Ausgabe des tatsächlichen Wurzelknotens tritt eine Ausnahme auf.

³⁹ Equivalent des ”Explorer“vonWindowsunterMacOS.

⁴⁰ Das hat technische Gründe. Es wurde kein zufriedenstellender Weg gefunden, die Größe einer Textbox serverseitig berechnen zu lassen und entsprechend große Textfelder, welche auf allen unterstützten Browsern funktionieren, auszugeben. Hauptproblem ist hier die unterschiedliche Größe der Schriften und Buchstaben.

⁴¹ Die browserübergreifende Abfrage von Tastenkombinationen gestaltet sich außerdem schwierig mit JavaScript.

⁴² Die von Zope vordefinierten Seitenvorlagen halten sich aber nicht an die Vorgaben, die in dem Ab- schnitt ”Ordnungsmäßigkeit“(Seite 20)vorgegebenwurden.

⁴³ Diese Anpassung war notwendig, da der Produktionsserver lediglich Zope 2.7 installiert hat und die Entwicklung unter der Version 2.8.1 durchgeführt wurde.

¹ Entsprechende Technologien wie die ”XLink“-ErweiterungvonXMLstrebenindieseRichtung.

² Weiterführende Informationen sind unter der Adresse http://businessintelligence.ittoolbox. com/topics/ zu finden.

³ Als Beispiel ist die Akquise von ”NetNewsWire“durch ”NewsGator“zunennen.

⁴ Weiterführende Informationen sind unter den Adressen http://www.mozilla.org/projects/xul/ und http://www.ondotnet.com/pub/a/dotnet/2004/01/19/longhorn.html zu finden.