DenkReiz

Multimedia im Netz

FB — Thu, 02 Sep 2010 17:24:15 +0000

Da ich lernbedingt derzeit nicht dazu komme, mich hier im Blog zum Weltgeschehen zu äußern, will ich wenigstens das Destillat meiner Mühen zu Protokoll bringen. Hier also der erste Teil zum Bereich Medieninformatik.

1 – Begriffsdefinitionen
2 – Dynamische Inhalte im Web
3 – Digitales Rechtemanagement
4 – Metadaten
5 – Streaming

1 – Begriffsdefinitionen

Zum Verständnis der weiteren Ausführungen sind einige Definitionen notwendig. Zuerst natürlich, was man unter Multimedia im Netz versteht.
Multimedia ist die Kombination von verschiedenen zeitabhängigen und zeitunabhängigen Perzeptionsmedien, insbesondere Audio und Video. Ein wichtiges Merkmal ist die Interaktivität.
Netz bezieht sich nicht auf die verschiedenen Telekommunikationsnetze der Vergangenheit, sondern auf das Internet als Overlay-Netzwerk. Endziel dieser Konvergenz ist es, dem Nutzer einen scheinbar allgegenwärtigen (ubiquitous) Service zu bieten, wobei sich der Nutzer nicht mehr um die Zugriffstechnologie kümmern muss.
Es geht also um interaktive Dienste mit physisch verteilten Dienstkomponenten.

Zentral ist der Begriff des Content, der mit “Inhalt” nur unzureichend übersetzt wäre und sich deswegen auch im Deutschen durchgesetzt hat. Dabei handelt es sich um interessante Information, meistens digitalisierte audiovisuelle Information, die eventuell urheberrechtsgeschützt ist. Ein Content Provider ist die Organisation, die verantwortlich ist für die Bereitstellung von Content für einen Multimedia-Dienst.

Ein Multimedia-Dienst ist ein Telekommunikationsdienst, der mehrere Medientypen synchronisiert aus Nutzersicht beinhaltet, evtl. mehrere Parteien und mehrere Verbindungen. Er erlaubt das Hinzufügen und Löschen von Ressourcen und Nutzern innerhalb einer einzelnen Session.

Eine Partei ist dabei entweder eine Organisation oder ein Mensch, der/die in das Angebot oder Nutzung eines Dienstes involviert ist. Endsysteme lassen sich weiter unterteilen in Allzweck-Endsysteme wie PC und PDA, Spezial-Endsysteme wie Handy oder Spielkonsolen und Hybrid-Endsysteme wie die Smartphones.

Ein Endsystem ist ein physisches Gerät, das teilnimmt an Multimedia-Diensten durch Informationsaustausch mit anderen Endsystemen übers Netzwerk.

Ein Terminal ist ein Endsystem, das direkt von einem Menschen bedient wird. Traditionell wird es Customer Premises Equipment (CPE) genannt. Ein Server ist dagegen ein Endsystem, das vom Dienstanbieter im Rahmen des Dienstangebots bereitgestellt und bedient wird.

Content Delivery ist die bedarfsgerechte Auslieferung des Contents. Sie kann mit unterschiedlicher Dienstgüte (Quality of Service = QoS) ausgeführt werden, je nach Fähigkeiten der zugrundeliegenden Netzwerktechnologie. Entscheidend sind dabei Bandbreite, Verzögerung, Jitter (Schwanken der Verzögerung) und Puffergröße. Content Delivery ist hauptsächlich relevant bei Conversational, Retrieval und Distribution Services, die gleich noch erläutert werden. Es sind drei Unterarten zu unterscheiden:

Live-Content Service: Verzögerung soll minimal sein.
Buffered-Content Service: Verzögerung soll sich in akzeptablem Rahmen befinden.
Stored-Content Service: Kompletter Download vorm Anschauen.

Multimedia-Dienste lassen sich in zwei Arten unterteilen: zum einen interaktive Dienste, zum anderen Distributionsdienste. Die interaktiven Dienste gliedern sich in Conversational Services, Messaging Services und Retrieval Services.
Conversational Services sind Dienste, bei denen ein synchroner Informationsaustausch zwischen den Terminals erfolgt (d.h. beide sind zeitgleich im Netz). Dabei kommunizieren Terminals miteinander. Eventuell sind auch Server zwischengeschaltet. Ein prominentes Beispiel für einen solchen Dienst ist Skype.
Messaging Services zeichnen sich hingegen durch einen asynchronen Informationsaustausch aus. Das Senden einer Nachricht fällt nicht notwendigerweise mit dem Empfang zusammen. Auch hier kommunizieren Terminals miteinander. Zwischengeschaltete Server speichern die Nachrichten zum späteren Abruf. Bekannte Beispiele sind SMS und MMS.
Bei Retrieval Services liegt die gewünschte Information auf Servern zum Download oder Streamen bereit. Die Quelle ist also extern (kein Terminal), meist ein Content Provider. Häufig kommt es zu einer Stern-Architektur, d.h. ein Server bedient viele Clients. In den letzten Jahren tauchen häufiger Communities auf, die Content teilen.
Distributionsdienste sind die zweite Art von Multimedia-Diensten. Es gibt sie ohne individuelle Präsentationskontrolle, im Sinne eines digitalen Ersatzes von Radio oder TV, mit einfachem Broadcast oder Multicast. Mittlerweile setzen sich auch Dienste mit einer solchen Kontrolle, also begrenzter Interaktivität, durch, z.B. Near Video on Demand, das zusammen mit zeitverschobenem Aufnehmen erlaubt, TV-Filme zu einer gewünschten (und nicht vorgegebenen) Zeit zu konsumieren.

2 – Dynamische Inhalte im Web

Dynamischer Web-Content sind Inhalte, die dem Nutzer im Browser gezeigt werden und abhängig sind von externen Variablen wie Zeit, Archivinformationen oder Nutzeraktionen. Große Anwendungsgebiete sind E-Commerce, Foren, Social Networks und Massenmedien.

Es klingt vielleicht komisch, aber in den ersten offiziellen Web-Standards waren weder dynamische noch audiovisuelle Inhalte vorgesehen. Die Entwicklungen in diese Richtung nahmen häufig bei Browser-Herstellern wie Netscape oder Microsoft ihren Anfang. So stammt der Object-Tag aus den Schmieden Microsofts (und ist mittlerweile im HTML-Standard enthalten), während der Embed-Tag (heutzutage verschmäht, aber von vielen Browsern noch unterstützt) aus den Werkstätten Netscapes kommt.

Einbindung

Die übliche Einbindung von audiovisuellem Inhalt sieht wegen der Inkompatibilitäten folgendermaßen aus:

Man bemerkt sofort die Redundanzen, die man sich eigentlich sparen könnte, wenn sich alle Browser an den Standard halten würden. Zur Erläuterung des Codes: Bei data ist der Ort anzugeben, wo man die Mediendatei findet. Type spezifiziert den Dateityp im MIME-Format. Weitere Attribute sind codebase (Basispfad als URI für die Interpretation relativer Pfade) und codetype (MIME-Typ für Player-Code). Die angegebenen Parameter muss der vom MIME-Format bestimmte Player interpretieren können, sonst werden sie verworfen. Alles, was innerhalb des Object-Tags steht, wird als Alternative angezeigt, falls die Anzeige des eigentlichen Objekts scheitert. Deswegen findet sich hier auch der Embed-Tag.

Funktionalitäten

Im Web gibt es klar spezifizierte Funktionalitäten von Server und Client.
Der Client ordnet anhand des erkannten Dateityps mithilfe der MIME-Registry des Browsers eine lokale Rendering-Software (Abspielprogramm) zu, die entweder als Browser-Plugin oder als eigenständiges Programm ausgeführt wird. Außerdem bietet der Client Interaktivität durch lokale Interaktionen, z.B. dynamische Menüs.
Der Server ist zuständig für die Speicherung der Mediendateien und der Meta-Informationen. Er managt die Indexierung und die Abfrage der Mediendateien. Auch der Server bietet Interaktivität durch Interaktionen mit serverseitigem Effekt (z.B. Datenbank-Updates) oder Interaktionen mit globalem Effekt (z.B. neuer Kommentar, neues Video).
Beide sind beim Streaming gefragt. Dabei handelt es sich um das Abspielen von unvollständigen Inhalten auf dem Client in vom Server gesteuerter Reihenfolge. Entscheidend beim Streaming sind Synchronisation, Buffering und Rate-Control. Eine Flusskontrolle (also Stop, Start, Pause etc.) sollte auch eingebunden sein, genauso wie eine Anpassung an Bedingungen des zugrundeliegenden Netzwerks. Zum Thema Streaming später noch mehr.

Realisation

Realisiert wird das Ganze clientseitig durch eine Skript-Execution-Engine im Browser. Der Webserver braucht dabei keine Skripts auszuführen, sondern nur die Skripts als Teil der Serverantwort mitzuschicken. Beispiele hierfür sind JavaScript und Java-Applets. Vorteil clientseitiger Skripts ist die Schnelligkeit, die Möglichkeit auch ohne Netzverbindung Skripts auszuführen und die Server-Unabhängigkeit. Nachteil ist natürlich die beschränkte Sicht und die Sicherheitseinschränkungen.

Serverseitige Realisation dynamischer Web-Inhalte bedingt, dass der Server eine Script-Execution-Engine hat. Der Client bzw. sein Browser brauchen dagegen keine Skripts auszuführen. Er erhält die vom Server berechnete Antwort. Beispiele dafür sind PHP, Servlets oder JSP. Vorteile serverseitiger Realisation sind die Möglichkeiten zur persistenten Speicherung großer Datenmengen, deren Vernetzung, der Zugriff auf Ressourcen, Eingabeverarbeitung und Berechnungen basierend auf vorhandenen Informationen und die Unabhängigkeit von Browsern. Außerdem kann der Server die Ausgabe speziell an die einzelnen Browser anpassen und deren Features nutzen (Cookies, User Agent ID).

CGI und PHP

Ein erster Ansatz auf dem Gebiet der dynamischen Inhalte war CGI (Common Gateway Interface), das Programme in beliebigen Sprachen erlaubt und auf Befehl auf dem Webserver ausführt. CGI ist allerdings nicht zu unrecht in Verruf geraten, da es einerseits große Sicherheitsrisiken birgt (Injektion von schädlichem Code, unbemerkte Bugs in den Programmen) und andererseits nicht die beste Skalierbarkeit besitzt. Calls sind nämlich teuer, da jeder Call einen neuen Prozess erzeugt. In verschiedenen Varianten von CGI wurde das natürlich verbessert. Trotzdem befindet es sich auf dem absteigenden Ast.

Anhaltender Beliebtheit und ungeheurer Verbreitung erfreut sich PHP (Personal Home Page Toolkit Hypertext Preprocessor). Seine Syntax hat Anleihen aus Skriptsprachen und aus C. PHP ermöglicht den einfachen Einsatz von verschiedensten Webtechnologien wie z.B. Cookies. Die Anbindung an Datenbanken wie MySQL ist auch schnell zu bewältigen. Einem PHP-Programm kann man Parameter mit den HTTP-Methoden GET und POST übergeben. Bei GET werden die Variablen als Bestandteil der URL codiert und übergeben. Man kann sie also auch manuell durch Eintippen manipulieren. Etwas sicherer ist POST, bei dem der Server auf die Übertragung der Variablenwerte nach der übrigen Anfrage wartet und sie vom Standard-Eingabekanal einliest.

Wie schon erwähnt fällt die dauerhafte Speicherung von Information auf Server-Seite leichter. Es gibt Datenbanken mit großen Datenmengen, die man auch extern aktualisieren kann und eine Anbindung an komplexe Systeme. Auf Client-Seite kann man hingegen nur geringe Datenmengen speichern und unterliegt aus Sicherheitsgründen diversen Einschränkungen. Eine wichtige Möglichkeit der Datenspeicherung sind Cookies, die aus Name/Schlüssel, Wert, Verfallsdatum und optional Domäne, Pfadname und Sicherheitsinformationen bestehen. Sie werden über HTTP übertragen, wenn eine Anfrage nach einem zugehörigen Dokument (der entsprechenden URL) erfolgt. Zugreifen kann nur der Erzeuger des Cookies. Die Erzeugung selbst erfolgt clientseitig per JavaScript, serverseitig über PHP.

AJAX

Einen großen Hype hat AJAX in den letzten Jahren verursacht. Es steht für “Asynchronous JavaScript And XML” und bedeutet, dass die Daten vom Server unabhängig von der (Änderung der) Präsentation geladen werden können. Der entscheidende Vorteil ist, dass dadurch eine flüssigere Interaktion möglich ist und durch regelmäßigere Updates die Präsentation immer aktuell gehalten werden kann. Der Kontrollfluss einer AJAX-Anfrage sieht wie folgt aus:

Aufruf des entsprechenden JavaScript-Codes durch den Browser
Aufsetzen eines Anfrage-Objekts (XmlHttpRequest)
Einrichten eines Callback-Handlers (vergleichbar mit einer Rückrufnummer)
HTTP-Request an Server schicken
Rückgabe der Kontrolle von JavaScript an den Browser
Server schickt HTTP-Antwort an den Callback-Handler
DOM der Webseite updaten

Nach Schritt 5 kann der Nutzer ganz normal weiterarbeiten, während im Hintergrund der Server seine Antwort berechnet und schickt. Durch Nutzung des DOM lässt sich die Antwort auch als lokale Änderung einflechten; ein Neu-Laden der Webseite bleibt einem somit erspart.

Dadurch entstehen aber auch eine Reihe von Problemen. Zum ersten funktioniert der Zurück-Knopf des Browsers nicht mehr, da der Browser dynamisch geänderte Seiten nicht speichert. Änderungen im Formular kann man also mit dem Knopf nicht rückgängig machen. Zum zweiten kommt es durch das Polling, also die regelmäßigen Anfragen, zu einer höheren Netzlast. Die Annahmen zum Traffic-Engineering ändern sich also. Außerdem sind Lesezeichen schwer möglich. Mithilfe von Anchors (#) lässt sich das Problem allerdings ganz gut umschiffen. Schwer wird es auch für Suchmaschinen – sie können dynamisch geänderte Webseiten nicht indexieren. Dynamische Änderungen sollten also nicht suchmaschinen-relevant sein. Da XML wegen der länglichen Dokumente zur Redundanz tendiert und bandbreitenhungrig ist, geht man neuerdings auch dazu über, das sparsamere JSON zu nutzen.

Applets, Servlets, JSP

Eine andere Möglichkeit dynamischen Webinhalt bereitzustellen sind Applets. Dabei handelt es sich um kleine Java-Programme, die man in HTML einbetten kann und von der Browser-Software direkt oder per Plugin ausgeführt werden. Auf Nutzereingaben wird per Eventhandler reagiert. Dadurch, dass Applets lokal ausgeführt werden, haben sie vollen Zugriff auf Eingabegeräte. Außerdem können sie alle Grafik- und Java-Bibliotheken nutzen (Java2D, Swing, …). Durch das Konzept der Sandbox-Security haben Applets weder Lese- noch Schreibrechte, können keine Anwendungen ausführen, keine Verbindungen öffnen und keine externen Bibliotheken laden. Es gibt auch Trusted Applets, die lokal installiert werden können und signiert und verifiziert sind.
Applets befinden sich dennoch auf dem absteigenden Ast, da ihre Vorteile (Interaktivität, Grafikprogrammierung, keine Netzlast, dezentrale Ausführung, Skalierbarkeit) von den Nachteilen überwogen werden. Sie sind immer abhängig vom Browsertyp, dessen Version und der Java-Version und (u.a. deswegen) als nicht sehr verlässlich berüchtigt. Außerdem ist das Debuggen problematisch.

Eine weitere Variante sind Servlets (Server Applets). Dabei wird der dynamische Inhalt von einem Java-Webserver produziert, der das gewünschte Servlet ausführt (Template Method). Sie sind Teil von JavaEE und benötigen einen entsprechend konfigurierten Server (z.B. mit Apache Tomcat).

Java Server Pages (JSP) bauen auf Servlets auf. Server Pages werden beim ersten Aufruf in Servlets übersetzt und benötigen deswegen eine ebensolche Infrastruktur zur Ausführung. JSP ist von der Nutzung her ähnlich wie PHP. Man schreibt Befehle entweder mitten in den HTML-Code oder generiert eigene Files mit den entsprechenden Kommandos. Manche empfinden die Mischung von Java und HTML als unordentlich und empfehlen deswegen JavaBeans, TagLibraries oder JSPX als bessere Wege. Alternativen zu JSP ist ASP und ASP.NET von Microsoft und Python Server Pages.

3 – Digitales Rechtemanagement

Zum Schutz des geistigen und materiellen Eigentums am produzierten Content wurde das Urheberrecht an die neuen Gegebenheiten angepasst. In den USA geschah dies schon 1976, als man drei Doktrinen zählte:

“Fair Use”: Die private Nutzung eines Werks ist erlaubt, solange keine Schädigung dessen Marktwertes eintritt.
“First Sale”: Der Käufer bekommt alle Erlaubnisse und Rechte abgesehen vom Urheberrecht auf den Inhalt.
“Public Domain”: Nach 70 Jahren wird jedes Werk vom Urheberrechtsschutz befreit.

1998 folgte der Digital Millenium Copyright Act, kurz DMCA, der neben anderen Dingen festlegte, dass es verboten ist, einen vorhandenen Kopierschutz zu umgehen.

Das Gesetz nahm sich Deutschland zum Vorbild, das sein 1995 geschaffenes Urheberrecht 2003 im ersten Korb novellierte. Es betrifft nur natürliche Personen (in Amerika auch juristische). Unterschieden werden zwei Rechte: zum einen der Urheber-Persönlichkeitsschutz, der nicht veräußerlich ist, und (veräußerliche) Verwertungsrechte, die besagen, dass der Rechteinhaber über die Vervielfältigung entscheidet. Eine Privatkopie ist grundsätzlich erlaubt (§53), allerdings nicht dann, wenn ein Kopierschutz vorhanden ist (§93a). Es wurde eine Pauschalvergütung für Privatkopien geschaffen (Geräteabgabe), deren Höhe unter den Beteiligten auszuhandeln ist. Der Tausch von urheberrechtlich geschützten Inhalten ist verboten. Eine Bagatellklausel existiert nicht.

Definitionen und vorhandene Modelle

Im Rahmen des Digitalen Rechtemanagement (DRM) gibt es eine Reihe von Begriffen, die zu erläutern sind:

Rightsholder: Partei mit geistigen Eigentumsrechten
User: Partei, die beabsichtigt, Inhalte mit geistigen Eigentumsrechten zu nutzen. Dabei gibt es Licensees (Lizenznehmer), Buyers (Käufer) und Grantees (Lizenzaussteller).
Content Owner: Rightsholder, der evtl. nur Teilrechte innehat
Rights Transaction: Übertragung von Rechten
Agent: Juristische Person, vom Rightsholder als Stellvertreter in der Übertragung autorisiert
Royalties: Ausgleichsahlung an Rightsholder oder Agent für die Nutzung der geistigen Eigentumsrechte
Rights Management: Geschäftsprozesse für juristische und kommerzielle Zwecke zum Verfolgen von Rechten, Inhabern, Lizenzen, Verkäufen, Abgaben und zugehörigen Vereinbarungen
DRM: Rechtemanagement mit Nutzung digitaler Technologien

Traditionelles Rechtemanagement zeichnete sich durch Zusammenschlüsse und formale Übereinkünfte aus. So wurden sogenannte Copyright Clearance Center geschaffen, die gebündelte Pakete anbieten und Abgaben gemäß statistischen Umfragedaten erheben. Hierzulande ist v.a. die VG Wort bekannt; ein anderes Beispiel wäre die IFRRO. Das Konzept ist erfolgreich und verursacht wenig Overhead. Andere Modelle sind separate Vereinbarungen, z.B. Pay-per-Use, oder die freiwillige Lizensierung. Auch verpflichtende Lizenzierungen sind bekannt, v.a. bei politischen Regulierungen. Für Furore sorgen immer mal wieder die Abgaben sammelnden Organisationen wie die GEMA oder die ASCAP, die z.B. für öffentliche Aufführungen einen Obolus verlangen. All diese Modelle sind im Internet schwer bis unmöglich anzuwenden.

Ein neuerer Ansatz ist Creative Commons, dessen Lizenzen auf dem Motto “Some Rights Reserved” basieren. Dabei gibt es vier Grundrechte, die sich zu einem Lizenzmodell kombinieren lassen:

BY – Attribution: Alles ist erlaubt, solange die Quelle angegeben ist.
SA – Share Alike: Vervielfältigung und Derivate sind ok, wenn sie derselben Lizenz unterliegen.
NC – Non-Commercial: Alles ist erlaubt, solange es nicht-kommerziell ist.
ND – No Derivative Works: Nur wörtliche Kopien sind erlaubt.

Grundlegend kann man die Welt des DRM in drei fundamentale Rechtetypen unterteilen:

Render-Rechte: Darunter fallen Drucken, Abspielen/Anzeigen und Exportieren.
Transport-Rechte: Kopieren, Transfer/Übergabe und Leihen.
Derivat-Rechte: Extrahieren, Editieren und Einbetten.

Mit den drei Rechtetypen und neun Grundrechten lässt sich jegliche Situation modellieren. Trotzdem wurden noch zur Präzisierung weitere Rechte geschaffen, so das Backup-Recht (Sicherheitskopie), Caching-Rechte (temporäre Kopie für bessere Performanz) und Datenintegritäts-Rechte (redundante Information gegen Dateifehler).

Um aus diesen Rechten Lizenzen zu konstruieren, benötigt man noch Attribute bzw. Dimensionen. Ein Attribut ist die Consideration, d.h. der finanzielle Ausgleich, z.B. in Form von Geld oder persönlichen Daten. Das zweite Attribut sind die Extents, sprich das Ausmaß der Nutzung, z.B. die zeitliche Länge, Anzahl der Wiederholungen oder Anzahl der einzelnen Kopien. Dazu kommen noch die Nutzertypen, z.B. Abokunden oder Besucher, Externe oder Studenten.
Ein Kinobesuch würde sich also folgendermaßen darstellen: Render-Recht = Abspielen, Consideration = Ticketpreis, Extents = einmalig, Nutzertyp = alle im erlaubten Alter.

Rechtetransaktionen können Rechte verändern. Eine Aufnahme macht beispielsweise den Extent ewig. Sie können auch Rechte hinzufügen, z.B. die Erlaubnis 30-Sekunden-Samples von Musikstücken im Radio abzuspielen (Extrahieren und Einbetten).

Herausforderungen

Die entscheidenden Fragen beim Rechtemanagement sind: Wie kann man die Einhaltung der Rechte absichern? Wie kann man den Ursprung (den Urheber) einer Datei herausfinden? Wie kann man den Inhalt nur bestimmten berechtigten Nutzern anzeigen?

Die Antworten darauf sind vielfältig und immer noch kontrovers diskutiert. So versucht man zum Beispiel mittels Superdistribution sicherzugehen, dass Lizenzen vorhanden sind. Superdistribution heißt, dass der Content innerhalb einer übergeordneten Komponente verpackt ist, die außerdem noch weitere Dinge beinhaltet, z.B. Bezahlmaßnahmen, Lizenzchecks oder dergleichen. Dafür ist allerdings sowohl beim Content Provider als auch beim Client Kompatibilität nötig: Der Provider muss das Paket so schnüren, dass ein Client, der die nötige Entpack-Software (meist in der Rendering-Software integriert) hat, die Superdistributionsroutinen ausführt und dann auf den Inhalt zugreifen kann.

Eine grundlegende Maßnahme ist die Standardisierung einer gemeinsamen Sprache. Bei DRM ist das die Extensible Rights Management Language (XrML). Mithilfe von XrML (oder ODRL) lassen sich die Rechte spezifizieren. Die Einhaltung der Rechte muss dann über geeignete Maßnahmen sichergestellt werden. XrML hat eine eigene Terminologie, die ich kurz erläutern will. Es gibt einen Grant, der alle Aspekte beschreibt:

Principal: Partei, der die Rechte zuerkannt werden.
Resource: Objekt, auf das sich der Grant bezieht (z.B. Datei).
Right: Verb, das der Nutzer auf der Resource ausführen darf.
Condition: Bedingungen, unter denen der Grant gilt.

Die Lizenz besteht dann aus einer Sammlung von Grants, dem Issuer (Herausgeber) und zusätzlicher Information wie Beschreibung oder Ablaufdatum. XrML erweitert außerdem die oben genannten Rechtetypen noch um Dateizugriffsrechte und Installationsrechte.

DRM mit Verschlüsselung

Um abzusichern, dass nur berechtigte Nutzer auf den Content zugreifen können, wird Verschlüsselung eingesetzt. Eine Lizenz beinhaltet dann also Schlüssel, die an die spezifizierten Rechte gebunden sind. Zur Durchsetzung der Rechte ist es nötig, dass die Nutzer und Geräte eine Identität besitzen. Die Nutzeridentifikation läuft dabei entweder über die Eingabe von Nutzername und Passwort ab (das ist kritisch, weil es weitergegeben werden kann) oder über biometrische Daten oder über ein Digitales Zertifikat, das von einer Dritten Partei ausgestellt wird. Die Geräteidentifikation geschieht über ein Auslesen der Seriennummern (Abspielgerät, Prozessor, etc.) durch Software, IP-Adresse (ungut wegen bspw. NAT) oder Kombination von Identifikationsinformationen wie Seriennummern, MAC-Adresse, Gerätekennung und anderen Daten. Dieser Eingriff in die Privatsphäre wird von vielen als Gegenargument zu DRM vorgebracht.

Das Abspielen von geschütztem DRM-Content läuft dann folgendermaßen ab:

Der Nutzer erwirbt ein verschlüsseltes Inhaltspaket, z.B. per Download
Der Nutzer verlangt seine Rechte auszuführen, z.B. das Abspielen der Audiodatei. Seine Rendering-Software (Abspielprogramm) aktiviert den DRM-Controller.
Der DRM-Controller bestimmt die Identität des Nutzers und des Inhalts und kontaktiert den Lizenzserver (evtl. nach Ausfüllen der Registrierung)
Der Lizenzserver authentifiziert den Nutzer mittels einer Identitäts-Datenbank.
Der Lizenzserver schaut die Rechtespezifikationen für den angefragten Inhalt nach.
Falls notwendig, wird eine Finanztransaktion gestartet.
Der Lizenzgenerator kombiniert die Rechteinformationen, die Client-Identität und die Decrypt-Keys (Schlüssel) und verpackt und verschlüsselt sie
Die Lizenz wird an den Client geschickt.
Der DRM-Controller entpackt und entschlüsselt den Inhalt und reicht ihn an die Rendering-Software weiter
Die Rendering-Software spielt den Inhalt ab.

Fast jeder Schritt kann zum Ziel von Angriffen werden. So kann aus dem Content Repository (so etwas wie die Lagerhalle) des Servers der unverschlüsselte Content geklaut werden. Eine andere Möglichkeit ist der Diebstahl des verschlüsselten Inhaltspakets. Außerdem könnte man die Decrypt-Keys klauen oder die Identitäten. Denkbar ist auch der Diebstahl des entschlüsselten Inhalts auf dem Client oder des gerenderten Inhalts. Aus diesem Grund ist es sehr wichtig, dass DRM-Controller und Abspielprogramm sehr eng gekoppelt bzw. ineinander integriert sind, sodass z.B. kein Zwischenspeichern nötig ist.

Trusted Computing

Eine weitere Möglichkeit des Schutzes ist Trusted Computing. Durch verschiedene Maßnahmen soll ein hardwarebasierter Schutz geistigen Eigentums ermöglicht werden:

Endorsement-Key in der Hardware
Memory Curtaining: Zugriffschutz auf bestimmte Speicherbereiche per Hardware. Dabei wird auch das Betriebssystem ausgeschlossen!
Secure IO: Absicherung der Eingabe/Ausgabe-Kanäle
Sealed Storage: Informationen wie Schlüssel werden generiert statt gespeichert. Verschlüsselung erfolgt samt Programm- und Hardware-ID.
Remote Attestation: Unautorisierte Änderungen der Hardware können von außen festgestellt werden.

Diese Brachialmethodik trifft natürlich auf erheblichen Widerspruch in der Internet-Gemeinde. Man befürchtet nebst anderen Gründen den Missbrauch der gewonnenen Daten und der möglichen Methoden, Probleme beim Wechseln der Hardware und schwere Probleme im Fehlerfall. Trusted Computing konnte sich bisher nicht durchsetzen. Auch DRM hat es schwer und wird zunehmend wieder zurückgefahren, z.B. im Online-Musikvertrieb. In anderen Bereichen wie dem Vertrieb von Kinofilmen (Master-Tapes) hat es sich allerdings bewährt.

Watermarks

Eine jahrtausendealte Technik ist das Setzen von Wasserzeichen (Watermarks). Im digitalen Bereich beinhalten sie meist Metadaten des Dokuments und werden genutzt, um die Integrität und den Ursprung eines Dokuments zu sichern. Es gibt universelle (beim gleichen Dokument immer gleich) und individuelle Watermarks, die auch “Fingerprint” genannt werden. Wasserzeichen haben fünf Charakteristika:

Undetectability: Watermark beeinflusst Inhalt nicht.
Robustheit: Watermark überlebt Kopiervorgänge.
Capacity: Soviel Inhalt wie möglich passt in das Wasserzeichen.
Sicherheit: Watermark widersteht Löschen und Ändern.
Effizienz: Der Overhead beim Einfügen und Extrahieren ist erträglich.

Wasserzeichen finden in vielen Bereichen Anwendung, darunter beim Urheberrechtsschutz, beim Verfolgen von individuellen Kopien (”Fingerprinting”), bei der “Copy Control” (Jedes Kopiergerät hat ein Wasserzeichen), beim “Broadcast Monitoring”, einem automatischen Tracking z.B. für Werbung, bei der Entdeckung unautorisierter Modifikationen, bei Annotation und Indexierung, in der Medizin zum Schutz von Patientendaten und bei der verdeckten Kommunikation.

Die Erstellung von Wasserzeichen kann man in zwei Bereiche klassifizieren. Der eine ist die Spatial Domain (räumliche Domäne). Zu den Techniken zählen LSB-Replacement (Ersetzen des niedrigwertigsten Bits), Patchwork (stochastische Prägung des Bildes) und Spatial Quantizer. Sie sind nicht so komplex, allerdings auch weniger sicher und robust als die Möglichkeiten der Frequency Domain. Ihre Techniken basieren auf der Transformation in den Frequenzraum (DCT, DFT, DWT). Ein Beispiel dafür ist Spread-Spectrum Encoding, d.h. das Signal wird über mehr Bandbreite als nötig gemäß dem Schlüssel verteilt und in den mittleren Frequenzen ein Wasserzeichen (z.B. mit Noise) versteckt.

Auch Wasserzeichen kann man angreifen. So gibt es die …

Removal Attack: Rekonstruktion der Originalinformation, z.B. per Medianfilter (Watermark wird als Noise betrachtet). Eine Variante für fingerprinted content ist die sogenannte Collusion Attack.
Oracle Attack: Durchführen minimaler Änderungen (z.B. an der Luminanz), bis der Detektor anspringt.
Stirmark Attack: Kleine geometrische Änderungen stören die Synchronisation in der Wasserzeicheninformation, wodurch es verlorengeht.

Robuste Wasserzeichen sind also verdammt schwer zu erstellen.

4 – Metadaten

Der Überfluss an Medien macht es immer schwerer, im digitalen Wald den gewünschten Baum zu finden. Für solche Zwecke wurden Metadaten eingeführt, die bei der Organisation, Indexierung und der Suche helfen sollen. Metadaten lassen sich für alle Inhalte erstellen. Content beinhaltet ergo nicht nur die Essence (also Programm-Material wie Audio, Video, etc.), sondern auch Metadata, die die Essence beschreiben oder deren Nutzung erklären. Sie können separat oder gemeinsam mit der Essence (embedded metadata) gespeichert werden.

Probleme mit Metadaten basieren meist auf Faulheit und Vernachlässigung. So werden die beim Erstellen der Essenz anfallenden Metadaten (Creation Metadata) oft ignoriert, z.b. EXIF bei JPEG. Die Administration und Pflege manuell hinzugefügter Metadaten wird oft vernachlässigt. Außerdem sind verschiedene Formate auf dem Markt, die speziell auf die Medientypen, Programme und Hersteller zugeschnitten sind. Dadurch sind sie untereinander inkompatibel. Es gibt außerdem eine solche Bandbreite an Metadaten, dass die Beachtung aller Ebenen sehr zeitaufwendig und teuer wird. Es stellt sich also die Frage, welche Metadaten sinnvoll sind und erzeugt werden sollten, wieviele davon genutzt werden und wann man sie erzeugen sollte.

RDF und AAF

Ein Ansatz in diesem Bereich ist RDF, das im Semantic Web Anwendung findet. Allerdings hat es sich nicht wirklich im Bereich Metadaten durchgesetzt.

Um die verschiedenen Metadaten in der Filmindustrie unter einen Hut zu bekommen, entwickelten die Verbände EBU und SMPTE Ende der 90er einen Standard, der sich zum Multimedia-Dateiformat Advanced Authoring Format (AAF) weiterentwickelte, das heute als Industriestandard gilt und cross-platform einsetzbar ist. In AAF gibt es folgende Arten von Metadaten (MD):

Identification & Location MD: dienen der Identifikation eines Items.
Administration MD: beschreiben Rechte, Zugriff, Sicherheitsklassifikation, Verschlüsselung, Hörerliste und andere Geschäftsinformationen.
Interpretive MD: zeigen Namen, Künstler, Organisation und Klassifikation.
Parametric MD: beschreiben Signalcodeparameter, Geräteigenschaften, Sensorparameter, Speicherungs- und Streamingparameter.
Process MD: Zusammensetzung der Essenz, z.B. Bearbeitung und Komposition.
Relational MD: zeigen Zusammenhänge und Beziehungen auf.
Spatio-Temporal MD: beschreiben Ort, Zeit, Aufnahmewinkel, Koordinaten, etc.

MPEG-7

Ein ambitionierter Standard auf dem Gebiet der Metadaten ist MPEG-7. Es unterteilt Metadaten in folgende Typen:

technische MD: Form (Datenformat, Auflösung), Datum (Zeit), technische Parameter (Beleuchtungszeit, …)
inhaltsbeschreibende MD: Hier wird noch in Low Level und High Level unterteilt. Low Level MD sind bei Video beispielsweise Objektformen, Positionen oder Pfade, bei Audio z.B. Tonart oder Tempo. High Level MD beschreiben höhere semantische Ebenen, bei Video z.B. die Szene, bei Audio Titel oder Komponist.
zusätzliche Informationen: Digitale Rechte, Klassifikation, Kontext, Links, …

MPEG-7 definiert einige Begriffe, die zu erläutern sind:

Feature: distinktives Charakteristikum mit bestimmter Bedeutung, kann durch mehrere Descriptoren repräsentiert werden.
Descriptor: definiert Syntax und Semantik von Feature-Repräsentationen.
Descriptorwert: Instanzierung eines Descriptors.
Descriptor Scheme: Strukturierte Komposition von Descriptoren und Description Schemes.
Description: Instanz eines DS mit passenden Descriptorwerten.

MPEG-7 klassifiziert Metadaten in die Teilgebiete Content Management (z.B. Medieninformation wie Dateiformat, Creation-Information wie Zeit oder Nutzungsinformationen wie Rechte), Content Structure (Segmente und deren Relationen) und Content Semantics (narrative Welt für einen Teil des Inhalts).

Auf die Strukturierung mit Segmenten soll noch etwas näher eingegangen werden. Segmente besitzen Attribute, die man in generische, medientypabhängige und spezielle Features unterteilen kann. Unter generische Features fallen die Medien-/Creation-/Nutzungsinformationen und Annotationen. Medientypabhängige Features sind visuelle oder akustische Features. Spezielle Features für Segmente sind Mask-Descriptor, die Wichtigkeit von Descriptoren (bestimmt durch MatchingHint und Point of View, z.B. Priorisierung der Heimmannschaft beim Sport) und Ink Segment Descriptoren, die der Handschrifterkennung dienen.

Segmente können in Subsegmente zerlegt werden, die sich in Raum und Zeit überlappen können und auch nicht das komplette Segment abdecken müssen. Außerdem lassen sich Segmente in Relation bringen, einerseits durch ihre inhaltliche Struktur (in Form von hierarchischer Dekomposition oder einem Segment-Relationship-Graphen) und andererseits durch vordefinierte Relationen (generisch, räumlich, zeitlich).

Um dem Nutzer unter die Arme zu greifen, gibt es verschiedene Techniken, die Features automatisch zu extrahieren. Bei Farben bewerkstelligt man dies mit einem Histogramm oder einem Farbcluster. Texturen kann man mittels Spektralverteilung extrahieren, Bewegungen mithilfe von Vektorhistogrammen und parametrischen Modellen. Konturen sind schwer herauszuziehen; hier behilft man sich mit “Moments” und Wavelet-Koeffizienten. Gesichtserkennung ist hingegen heutzutage kein Problem mehr; sie geschieht auf Vektorbasis und mittels Similarity-Matching (Ähnlichkeitserkennung). Bei komprimierten Datenformaten wie JPEG oder MPEG-2 kann man die Informationen der Frequenzraumtransformation bzw. der Bewegungsabschätzung wiederverwenden.

Auch für Regionen und Konturen gibt es Form-Descriptoren. Region Shapes definieren sich durch ihre Pixelverteilung und können komplexe Objekte mit mehreren unverbundenen Regionen beschreiben. Die Formanalyse basiert auf “Moments” und wird durch die Angular Radial Transformation berechnet, die invariant gegenüber Rotation und Verzerrung ist. Contour Shapes kann man mithilfe der Curvature Scale-Space-Repräsentation erkennen. Sie erlaubt die Extraktion charakteristischer Konturformen, ähnlich der menschlichen Wahrnehmung.

Im Falle von Musik werden individuelle Noten oder Akkorde extrahiert und daraus ggf. eine Tabulatur aufgebaut. Hilfreich dabei sind Sonogramme bzw. Spektrogramme. Auch eine Identifikation der beteiligten Instrumente ist möglich. Auch das Tempo und Phrasen/Abschnitte (Refrain usw.) können mithilfe einer Self-Similarity-Matrix erkannt werden. Gleiches gilt für das Genre.

5 – Streaming

Streaming bezeichnet die (Echtzeit-)Auslieferung von Bewegtbildern, Text und Ton übers Internet. Es gibt verschiedene Arten von Streaming:

Download & Play: Zuerst wird die Datei komplett heruntergeladen.
Progressive Download: Abspielen startet schon während dem Download, aber Abspielrate und Programm-Bitrate sind unabhängig voneinander.
True Streaming: Medium wird in Echtzeit betrachtet. Die Raten sind etwa gleich. Die Verzögerung zwischen Senden und Empfangen des Datenpakets wird gering gehalten. True Streaming lässt sich noch weiter unterteilen in Static File Streaming (Auslieferung von vorher aufgenommenen Medien on-demand) und Live Streaming (direkte Einspeisung während der Aufnahme, z.B. bei Webradios).

Streaming Delivery Chain

Streaming hat eine charakteristische Kette von Transfervorgängen, die sogenannte Streaming Delivery Chain. Sie spielt sich folgendermaßen ab:

Audio-/Video-Aufnahme
Encoding: Formatkonversionen, Kompression, Indexierung und Metadaten-Erzeugung. Hierbei helfen Encoding Service Provider und Content Distribution Service Provider (CDSP) als Organisationen, als Hardware dienen Enconding Stations, Workstations und automatische Server.
Serving: Speicherung von Live-Aufnahmen (Buffering und Archivierung) und Static Files (Archivmanagement und Retrieval), Streaming als Request-Response-Mechanismus wie bei Webservern und Interaktivität durch fernbedienungsähnliche Steuerung oder Hyperlinks. Fürs Speichern werden Media Archive Servers und organisatorisch CDSP und Hosting Service Provider (HSP) verwendet, beim Streaming kommen CDNs zum Einsatz und HSP, CDSP und ISP.
Distribution: Beachten der QoS, Overprovisioning (Überversorgung), detaillierte Reservierung (mit RSVP), Traffic Classes, Resourcenmanagement und technologie-spezifische Lösungen (wie der Asynchronous Transfer Mode). Auch hier werden CDNs eingesetzt nebst CDSP und ISP.
Anschauen bzw. Anhören des Streams.

Entscheidungen zur Infrastruktur sind abhängig von der erwarteten Geschäftsgröße und der benötigten Verlässlichkeit.

Streaming-Protokolle und Buffering

Fürs Streaming gibt es spezielle Protokolle, deren bekanntester Vertreter RTP (Real-Time Transport Protocol) ist. RTP basiert auf IP und UDP. Es benötigt also zusätzliche Netzwerktechnologien für QoS-Sicherung. Genutzt wird es von Apple Quicktime und RealSystems. In diesem Verbund gibt es auch noch das Real-Time Control Protocol (RTCP), das die Übertragung selbst kontrolliert. Es schickt periodisch Statusinformationen an die Teilnehmer der Streaming-Session. Sie enthalten Feedback zur Dienstgüte der Übertragung für die adaptiven Codecs, eine Identifikation des Senders, die Anzahl der Teilnehmer zur Anpassung der Senderate zwecks Verhinderung von Netzüberlast und weitere Infos wie die Namen der Teilnehmer o.ä.. Dritter im Bunde ist das Real-Time Streaming Protocol (RTSP). Es dient der Präsentationskontrolle im Sinne einer Fernbedienung, hilft beim Retrieval der Medien vom Server und kann einen Server zu einer Konferenz einladen.

Die Qualität beim Streaming ist abhängig vom Netzwerk und adaptiven Codecs auf Client- und Server-Seite. Außerdem ist Buffering entscheidend. Bei konstanter Verzögerung ist es nicht nötig, aber bei variierender Verzögerung (Jitter). Die benötigte Puffergröße wird mittels Testübertragungen und adaptiv während der Übertragung abgeschätzt. Dabei wird abgewägt zwischen einem möglichst kleinen Puffer für ein gutes Echtzeit-Gefühl und einem ausreichend großen Puffer, der vor Underrun bei richtig langen Verzögerungen schützt. Bei Paketverlust wird nicht auf eine Retransmission gewartet, sondern entweder das letzte bekannte Paket wiederholt oder zwischen den zwei umgebenden Paketen interpoliert. Zur Anpassung gibt es das Adaptive Transmission Rate Protocol, das eine Low- und eine High-Schranke im Puffer hat. Wenn die High-Schranke überschritten wird, wird die Übertragungsrate reduziert, bei Unterschreiten von Low wird sie erhöht.

Maßnahmen zur Skalierbarkeit

Kritisch beim Streaming ist immer die Skalierbarkeit. Deswegen musste man Wege ersinnen, Streaming-Dienste skalierbar zu halten. Eine Möglichkeit ist Splitting, d.h. die Verteilung der Medien auf vorgelagerte Server. Eine ähnliche Methode verfolgen Content Delivery Networks (CDN). Bei ihnen geht es darum, den Content möglichst nahe an möglichst vielen Nutzern zu haben, um die Kosten gering zu halten. Das wird mittels geschicktem Routing, Caching entlang der Kanten des Netzes, Proxy Caching und Splitting von Live-Sendungen bewerkstelligt. Da häufig der Stream schnell wieder vom Nutzer abgebrochen wird und Bandbreite begrenzt ist, sind effiziente Caching-Algorithmen wichtig. Folgende Möglichkeiten gibt es:

Sliding Interval Caching: Sequentieller Zugriff, v.a. effektiv bei ähnlichen Anfragen in kurzen Zeiträumen
Prefix Caching: Spart Zeit beim Laden der übrigen Teile
Segment Caching: Generalisierung von Prefix Caching mit Fast-Forward-Funktionalität
Rate-Split Caching: Niedrige Schicht vom Originalserver, höhere Schicht vom Proxyserver
Cooperative Proxy Caching

Möglichkeiten zur Anpassung der Datenraten sind…

Multiple Bitraten in einer Datei: Nur mit Streamingservern möglich, nicht mit Webservern
Alternate Movies (Quicktime): Verwendung von Pointern zum Wechsel zwischen verschiedenen Mediendateien (mit unterschiedlicher Qualität)
MPEG-4 Scalable Streams: ähnlich wie progressive JPEG, grundlegender Stream mit niedriger Auflösung wird übertragen, Rest bei Bedarf und Möglichkeit dazugeschalten

Die Bandbreite des gestreamten Videos wird von einigen Faktoren bestimmt:

Auflösung bzw. Pixelanzahl, die auch vom Abspielgerät abhängig ist.
Bildwiederholrate, normal 25 fps
Color(sub)sampling: Unterabtastung des Farbraums, da Farbe weniger wahrnehmbar ist als Luminanz
Audioqualität, z.B. Samplingrate, Auflösung, Mono/Stereo
Kompressionsgrad (Artefakte)

Trotz der Vielzahl an Möglichkeiten bleibt die bange Frage, ob die Maßnahmen ausreichend sind, um den enormen Strom von Medien an die Zuschauer und Zuhörer annehmbar ausliefern zu können. Manche tendieren nun dazu, bestimmten Übertragungen Vorrang vor anderen Übertragungen zu geben und dafür einen Obolus zu verlangen. Das Thema ragt also durchaus in politische Bereiche wie die eben angesprochene Netzneutralität hinein. Es wird interessant, was sich auf diesem neuen Markt noch alles tun wird.

Softwaretechnik

FB — Tue, 29 Jun 2010 22:04:29 +0000

Die letzte Lernzusammenfassung dieses Monats dreht sich um das Thema Softwaretechnik. Dabei wird es um die Herangehensweise an Softwareprojekte und die Modellierung der Software gehen.

Inhalt:
1 – Grundlagen
2 – Arbeitsmodelle für Softwareprojekte
3 – Statische Modellierung
4 – Dynamische Modellierung
5 – Gesamtbetrachtung
6 – Systemarchitektur
7 – Design Patterns
8 – Datenbankanbindung

1 – Grundlagen

Die Softwaretechnik, in diesem Fall die Objektorientierte Softwareentwicklung (OOSE), wurde geboren, als sich Ende der 60er Jahre herauskristallisierte, dass das bis dahin übliche intuitive Vorgehen an seine Grenzen stieß. Man ließ sich deswegen von den Ingenieurswissenschaften inspirieren (phasenweise Entwicklung, Muster) und versuchte so, ein wenig Ordnung ins Chaos zu bringen.

Softwaretechnik wird folgendermaßen definiert:

Softwaretechnik bzw. Software-Engineering ist die technische und organisatorische Disziplin zur systematischen Herstellung und Wartung von Softwareprodukten, die zeitgerecht und innerhalb vorgegebener Kostenschranken hergestellt und modifiziert werden.

Ziele der Softwaretechnik sind Software von hoher Qualität und Beherrschung der Kosten und Entwicklungszeit. Wie jedem aus dem Alltag bekannt ist, klappt das auch heute noch eher selten. Umso mehr ein Grund, sich mit der Softwaretechnik zu beschäftigen.

Für Software lassen sich zahlreiche Qualitätskriterien formulieren:

Korrektheit: Software erfüllt die in der Spezifikation beschriebenen Anforderungen. Der Nachweis ist nur mit formalen Methoden möglich.
Zuverlässigkeit: Die Wahrscheinlichkeit, dass die Software eine gewünschte Funktion in einer bestimmten Zeit erfüllt. Fehler sollten selten sein und, wenn vorhanden, dann nur schwach (ohne große Wirkung).
Robustheit: Die Software sollte sinnvoll auf Fehler reagieren, die in der Umgebung auftreten (z.B. Bedienfehler der Nutzer).
Benutzerfreundlichkeit: Einfache Erlernbarkeit und Bedienbarkeit.
Wartbarkeit: Fehler sollten einfach zu lokalisieren und zu beheben sein. Außerdem sollte die Software einfach zu ändern und zu erweitern sein.
Performanz: Angemessenes Laufzeitverhalten und Speicherbedarf.
Dokumentation: Für Benutzer und Entwickler wichtig.
Portabilität: Die Software sollte auf andere Rechner übertragbar sein.

Bei einem objektorientierten Softwaresystem handelt es sich um eine Menge von Objekten, die sich gegenseitig Nachrichten schicken. Der Empfang einer Nachricht löst eine Operation des empfangenden Objekts aus. Ein Objekt ist eine Instanz einer Klasse. Man könnte auch sagen: Eine Klasse beschreibt eine Menge von Objekten mit gemeinsamen Merkmalen. Objekte bestehen aus Attributen, Operationen und Beziehungen zu anderen Objekten. Der Zustand eines Objekts wird durch die aktuellen Attributwerte und Beziehungen zu anderen Objekten bestimmt. Der Systemzustand ist folglich der Zustand aller zu einem Zeitpunkt existierenden Objekte.

Der Vorteil einer objektorientierten Modellierung besteht darin, dass Objekte der realen Welt auf ein objektorientiertes System abgebildet werden können. Objektorientierte Techniken können auf verschiedenen Ebenen der Systementwicklung eingesetzt werden, von Analyse, über den Entwurf bis hin zum Programm selbst. Durch die Objektorientierung bleibt auch bei größeren Projekten der Überblick besser erhalten. Außerdem sind objektorientierte Systeme einfach erweiterbar und wartbar und man kann evtl. einzelne Teile davon bei anderen Projekten wiederverwenden.

Es gibt 3 Bereiche der Softwaretechnik. Das sind…

Software-Entwicklung: Anforderungsanalyse, Entwurf, Implementierung, Wartung und Dokumentation
Qualitätssicherung: Code-Inspection, Test, Validierung, Verifikation
Projektmanagement: Planung, Koordination, Kontrolle

2 – Arbeitsmodelle

Es gibt einige Modelle, wie man an Softwareprojekte herangeht. Alle haben ihre Vor- und Nachteile. So wirklich begeistert mich keines davon.

Zum einen gibt es das Wasserfallmodell. Es beschreibt Softwareentwicklung als sequentielle Abfolge: Anforderungsanalayse -> Entwurf -> Implementierung -> Test -> Wartung & Einsatz. Der Nachteil des Wasserfallmodells ist, dass der Kunde das Produkt erst ganz am Ende validieren kann. Außerdem ist ein streng sequentielles Vorgehen gar nicht möglich, da Anforderungen sich manchmal ändern und Fehler oft erst später erkannt werden.

Die einzelnen Phasen möchte ich näher erläutern:

Anforderungsanalyse: Sie dreht sich um die Frage “Was soll das System leisten?”. Sie basiert auf einer Anforderungsspezifikation, die der Entwickler mit dem Kunden (vertraglich) vereinbart. Sie dient als Grundlage für die weitere Entwicklung und legt z.B. eine grobe Terminplanung und Rahmenbedingungen fest.
Entwurf: Hier steht die Frage “Wie lösen wir das?” im Mittelpunkt. Der Entwurf legt die Systemarchitektur fest und spezifiziert einzelne Systemkomponenten. Ergebnis der Phase ist eine Entwurfsbeschreibung.
Implementierung: Der Entwurf wird in einer Programmiersprache codiert.
Test: einzelne Komponenten (Unit Tests), schrittweises Zusammenfügen der Einzelkomponenten mit jeweiligem Integrationstest, Systemtest und schließlich Abnahmetest.
Wartung: besteht aus Fehlerbeseitigung nach Inbetriebnahme und Änderung und Erweiterung des Systems. Sie verursacht 67% der Kosten (davon 40% zum Verständnis existierender Programme)

Eine weitere Herangehensweise bietet das Iterative Modell. Hier wiederholen sich die Phasen nach einem Durchlauf wieder: Analyse -> Entwurf -> Implementierung ->Test / Wartung -> Analyse -> …. Am Ende jedes Zyklus steht eine Version, die die vorherige verbessert und erweitert (sog. “evolutionäres Prototyping”). Vorteilhaft ist auch der häufige Kundenkontakt. Das Risiko besteht darin, dass die neu hinzukommenden Teile wegen der Anforderungen nicht zu den bestehenden passen. Eine spezielle Ausprägung des Iterativen Modells ist der Unified Process (anwendungsfall-getrieben).

Ähnlich dazu ist das prototyp-orientierte Modell. Hier wird nur mit Prototypen agiert und diese mit den Wünschen des Kunden abgeglichen. Nachteilig ist allerdings, dass lange Zeit nur eine eingeschränkte Funktionalität angeboten werden kann, die Ergebnisse selten robust sind und schlechte Performanz haben.

Etwas bekannter ist auch XP, “Extreme Programming”. Dabei setzt man sich meist mit einem zweiten Entwickler an einen Rechner (4 Augen sehen mehr und schneller Fehler als zwei). XP ist test-getrieben. Es wird das einfachste implementiert, das funktioniert, das System restrukturiert (Refactoring) und dann getestet.

Schließlich gibt es noch das Spiralmodell, desssen Grundidee die Risikobeherrschung ist. Es beginnt mit einem Life-Cycle-Plan, und spiraliert dann nach außen über die Sektoren Risikoanalyse, der jeweils ein Prototyp folgt, Entwicklung und Validierung, Planung der nächsten Phasen, die ein Review enthält, und dem Festlegen von Zielen, Varianten, Bedingungen und Einschränkungen. Meines Erachtens zu kompliziert, um wirklich genutzt zu werden.

3 – Statische Modellierung

Ein statisches Modell beschreibt strukturelle und datenbezogene Eigenschaften, ein dynamisches Modell dagegen das Verhalten der Objekte, deren Zustandsänderungen und Interaktionen. Die Notation nutzt UML (Unified Modeling Language).

Der verlinkte Wikipedia-Artikel erklärt so ziemlich alles wichtige, deswegen werde ich davon absehen die entsprechenden Klassen- und Objektdiagramme durchzukauen. Die Beziehungen zwischen Klassen möchte ich allerdings herausgreifen. Darunter befinden sich die Möglichkeiten…

Komposition: symbolisiert durch ausgefüllte Raute. Das Teil ist existenzabhängig vom Ganzen, wird erst nach ihm erzeugt und mit ihm gelöscht.
Aggregation: symbolisiert durch leere Raute. Gesamtheit-Teil-Beziehung.
Abhängigkeit: symbolisiert durch gestrichelte Linie plus Pfeil. Änderungen im Ziel verursachen mglw. Änderungen im abhängigen Element.
Vererbung: symbolisiert durch Linie mit leerer Pfeilspitze. Dabei ist die Oberklasse A die Generalisierung der Unterklasse B bzw. B die Spezialisierung von A. Es herrscht das Substitutionsprinzip, d.h. statt einem Objekt der Oberklasse kann ein Objekt der Unterklasse genutzt werden.
Schnittstellen: symbolisiert durch “<>” im Körper. Nutzende Klassen verbinden mit einem (gestrichelten) Pfeil, realisierende Klassen verbinden mit einer gestrichelten Linie mit leerer Pfeilspitze. Auch bei Schnittstellen herrscht das Substitutionsprinzip: Statt dem Interface-Typ kann auch die realisierende Klasse genommen werden. Schnittstellen sind ein wichtiges Strukturierungsmittel für flexible Softwarearchitekturen.

Die einzelnen Elemente können verschiedene Sichtbarkeiten haben: öffentlich = für alle sichtbar (+name), privat = nur innerhalb der Klasse (-name), protected = in der Klasse und ihren Subklassen und außerhalb des Pakets, wenn Klasse öffentlich (#name) und schließlich komponenten-privat = nur innerhalb des Pakets (~name), was bei Java die Grundeinstellung ist.

Zur statischen Modellierung gehört auch die Betrachtung der Use-Cases (Anwendungsfälle). Dabei nehmen Aktoren gegenüber einem System eine Rolle ein. Die Anwendungsfälle beschreiben die Interaktionen zwischen den beteiligten Aktoren und sind auf eine bestimmte Aufgabe bezogen. Definiert ist ein Use-Case folgendermaßen:

Ein Anwendungsfall ist eine Menge von verhaltensverwandten Sequenzen von Transaktionen, die durch ein System ausgeführt werden und ein messbares Ergebnis liefern.

Sonderlich viel schlauer ist man nach der Definition allerdings nicht. Bei der Erstellung eines Use-Case-Modells geht man so vor:
- Bestimmung der Aktoren, die mit dem System interagieren
- Bestimmung der Anwendungsfälle aufgrund der von Aktoren gewünschten Aufgaben
- Erstellung eines Use-Case-Diagramms
- Beschreibung der Anwendungsfälle nach dem Schema: Name, Kurzbeschreibung, Vorbedingung, Nachbedingung, Standardablauf, Alternativabläufe und evtl. Aktivitätsdiagramm.

4 – Dynamische Modellierung

Zur Modellierung des dynamischen Verhaltens verwendet man Interaktionsdiagramme, Aktivitätsdiagramme und Zustandsdiagramme.

Die Dynamik ist stark von Ereignissen bestimmt. Es gibt 5 Arten von Ereignissen:

Signal Event: Empfang eines Signals (z.B. “Knopf gedrückt”).
Call Event: Aufruf einer Operation (z.B. konto.einzahlen(50)…).
Change Event: Eine Bedingung wird wahr (z.B. when (temperatur < 0)…).
Time Event: Ablauf einer Zeitvorgabe (z.B. after(5sec)…).
Completion Event: Beendigung einer Aktivität (z.B. “Internetseite geladen”).

Zustandsdiagramm

Ein Zustandsdiagramm besteht aus einem Graph, dessen Knoten Zustände und dessen Kanten Transitionen sind. Die Transitionen werden bestimmt durch Ereignisse, die noch durch Bedingungen (Guards) und Aktivitäten ergänzt werden können. Die Bedingungen müssen nach Durchlaufen der Transition noch gelten.

Aktivitäten, die während eines Zustands ablaufen, können entweder als selbstbezogene Transition oder als innere Aktivität modelliert werden. Spezielle Aktivitäten sind entry (immer eingangs, nicht unterbrechbar), exit (immer ausgangs, n.u.), do (u.) und defer. Ein verzögertes Ereignis e, das mit e/defer markiert ist, aber im Zustand keine ausgehende Transition hat, wird aufbewahrt und erst dann verarbeitet, wenn sich das Objekt in einem anderen Zustand mit dieser Möglichkeit befindet.

Komplexe, sequentielle Unterzustände können mit einer umschließenden Box markiert werden. Wie normale Zustandsdiagramme können auch sie Start- und Endpunkt haben. Parallele Unterzustände markiert man mit horizontalen gestrichelten Linien, zwischen denen sich die nebenläufigen Zustände befinden.

Ein Zustand, dem eine Aktivität zugeordnet ist und der nur durch ein (evtl. bedingtes) Completion Event verlassen werden kann, heißt Aktivitätszustand. Ein Zustand, dem keine Aktivität zugeordnet ist, heißt stabiler Zustand oder inaktiver Zustand.

Aktivitätsdiagramme

Aktivitätsdiagramme dienen zur Darstellung des Ablaufs von Geschäftsprozessen, Use-Cases (s.u.) oder von Operationen. Ein Aktivitätsdiagramm ist ein gerichteter Graph, dessen Knoten Aktionen, Kontrollstrukturen und Daten sind, und dessen Kanten die Abläufe beschreiben. Aktivitätsdiagramme sehen ähnlich aus wie Zustandsdiagramme.

Fallunterscheidungen/Bedingungen modelliert man entweder durch Entscheidungsknoten (meist als Raute) oder durch einen Fork, dessen ausgehende Kanten die entsprechenden Bedingungen beinhalten (wie Guards bei ZD).

Interaktionsdiagramme

Interaktionsdiagramme sind entweder Kommunikationsdiagramme oder Sequenzdiagramme (SD). Beide Diagramme stellen i.W. die selbe Information dar.

Sequenzdiagramme heben die zeitliche Reihenfolge hervor, in der Nachrichten zwischen den Objekten versandt und empfangen werden. Sie verlaufen von oben nach unten (entlang der “Lebenslinie” der Objekte). Synchrone Nachrichten haben einen geschlossenen Pfeil, asynchrone einen offenen. Aktivierte Objekte haben ein fortlaufendes Rechteck auf ihrer Lebenslinie, das bei synchronen Nachrichten weiterläuft, solange auf die Rückgabe des Steuerungsfokus (gestrichelter offener Pfeil) gewartet wird. Alternative Abläufe (z.B. bei einer Fallunterscheidung) können durch ein entsprechendes überspannendes Feld markiert werden, das die entsprechenden Fälle nacheinander aufführt.

Kommunikationsdiagramme heben die strukturellen Beziehungen aller an einer Interaktion beteiligten Objekte hervor. Die zeitliche Reihenfolge wird durch fortlaufende Nummern dargestellt.

5 – Gesamtbetrachtung

Die Analysephase besteht aus den Abschnitten
1. Use-Case-Analyse
2. Entwicklung eines statischen Modells (Klassendiagramme)
3. Entwicklung eines dynamischen Modells (Interaktions-, Zustands-, Aktivitätsdiagramme)
4. Validieren, Überarbeiten und Erweitern der Modelle

Die in der Analyse erarbeiteten Dokumente (Use-Case-Modelle, Problembeschreibungen) dienen als Grundlage für die Entwicklung eines statischen Modells. Ihr Ziel ist ein Klassendiagramm (noch ohne Operationen). Dafür sind folgende Schritte notwendig:

Klassen identifizieren (Personen, Organisationen, Gegenstände, …)
Assoziationen bestimmen (konzeptionelle Verbindung, Besitzverhältnis, …)
Attribute identifizieren
Vererbung einführen (durch Generalisierung und Spezialisierung)
Modell überarbeiten (fehlende Klassen, Typen, Multiplizitäten, …)

Die Use-Case-Beschreibungen und das statische Modell sind schließlich der Input für den Entwurf von Interaktionsdiagrammen. Dazu identifiziert man die an einem Anwendungsfall beteiligten Objekte und die Nachrichten, die sie austauschen. Für jeden Anwendungsfall bzw. dessen Szenarien erstellt man dann ein oder mehrere Interaktionsdiagramme (i.d.R. Sequenzdiagramme).

Aufbauend auf den Interaktionsdiagrammen kann man dann Zustands- und Aktivitätsdiagramme entwickeln. Für jede Klasse mit “interessantem Verhalten” erstellt man ein Zustandsdiagramm.

Interessantes Verhalten heißt, dass das Objekt einen nicht-trivialen (=zustandsabhängigen) Lebenszyklus hat, d.h.:
1. Es gibt mindestens ein Ereignis, das in Abhängigkeit vom Objektzustand unterschiedliche Reaktionen auslösen kann.
2. Mindestens ein Ereignis wird in bestimmten Zuständen ignoriert bzw. kann dort nicht auftreten.

Bei der Konstruktion eines Zustandsdiagramms ist wie folgt vorzugehen:

Ein SD wählen, das eine typische Interaktion für ein Objekt der betrachteten Klasse zeigt (i.A. Primärszenario).
Der Lebenslinie des Objekts folgen und daraus eine Kette von Zuständen und Transitionen bilden, sodass
- inaktive Phasen sind stabile Zustände
- aktive Phasen sind Aktivitätszustände (Aufruf von lokalen Operationen)
- eintreffende Ereignisse modelliert man durch Transitionen von stabilen Zuständen in Akt.zustände
- Beendigung einer Aktivität ist eine Transition mit einem Completion Event von einem Akt.zustand in einen stabilen Zustand
Zyklen für sich wiederholende Folgen bilden.
Bei weiteren SDs für Objekte der betrachteten Klasse den Aktivitätszustand finden, wo die Sequenz vom bisherigen Verhalten abweicht und die neue Folge als Alternative an diesen Zustand anhängen.
Konstruiere Aktivitätsdiagramme für lokale Operationen, die in Aktivitätszuständen aufgerufen werden (siehe 2.)
Zustandsdiagramm verfeinern durch Einfügen von Bedingungen bei Transitionen, die von Aktivitätszuständen ausgehen.
Sekundärszenarien integrieren, soweit nötig.

Nun kann man zum Objektentwurf ansetzen und …

Operationen hinzufügen (aus den Sequenz- und Aktivitätsdiagrammen ersichtlich)
Assoziationen ausrichten
Zugriffsrechte bestimmen (dabei Attribute und Rollennamen nicht öffentlich)
Mehrfachvererbung auflösen (durch Einführung von Schnittstellen)
Wiederverwendung von Klassen einführen (durch Spezialisierung und Delegation)

Delegation bedeutet dabei, ein Attribut der verwendenden Klasse mit einer Referenz auf die Instanz der wiederzuverwendenden Klasse zuzugreifen.

Wenn man nun will, dass der Objektentwurf das im Zustandsdiagramm beschriebene Verhalten realisiert, kann man dies mit einer der folgenden Möglichkeiten bewerkstelligen:

Prozedurgesteuert: Ereignisse werden durch erzwungene Benutzereingaben realisiert (geht nur, wenn Objekt an der Systemgrenze). Nachteil: unflexibel.
Fallunterscheidung: Enumeration für die stabilen Zustände, explizites Zustandsattribut für betrachtete Klasse, zustandsabhängige Operationen durch Fallunterscheidung nach derzeitigem Zustand (siehe Attribut) realisieren. Nachteil: Bei neuen Zuständen muss jede Operation erweitert werden.
Zustandsobjekte: Jedes Objekt hat ein zugehöriges Zustandsobjekt. Der Aufruf einer zustandsabhängigen Operation wird an das Zustandsobjekt delegiert, das dann die gewünschte Aktivität ausführt. Bei Zustandsänderung wird ein neues Zustandsobjekt erzeugt und mit dem Basisobjekt verbunden. Nachteil: Bei neuen Operationen muss jeder Zustand erweitert werden. Siehe Design-Pattern State.
Zustandsmaschine: Alle Größen im Zustandsdiagramm (Zustände, Ereignisse, Transitionen, Aktivitäten) werden durch Objekte dargestellt. Ereignisse werden von einem Event-Handle (spezielle Operation) interpretiert. Das gesamte Zustandsdiagramm wird dann durch eine verzeigerte Objektstruktur repräsentiert.

6 – Systemarchitektur

Die Systemarchitektur beschreibt die Gesamtstruktur des Softwaresystems durch Subsysteme (Pakete und Komponenten) und Beziehungen zwischen diesen Subsystemen. Dabei gelten folgende Grundregeln:

Hohe Kohärenz: Zusammenfassung zusammengehörender Teile eines Systems in einem Subsystem.
Geringe Kopplung: Wenige Abhängigkeiten zwischen den einzelnen Subsystemen.

Der Vorteil davon ist, dass einzelne Teile dadurch leicht änderbar und austauschbar sind.

Gebräuchlich sind auch Schichtenarchitekturen, bekannt z.B. das OSI-Modell. Bei geschlossenen Architekturen darf eine Schicht nur auf die direkt darunterliegende Schicht zugreifen, ansonsten redet man von offenen Architekturen. Wenn verschiedene Schichten auf verschiedenen Rechnern sind, spricht man von Client-Server-Systemen. Eine Schicht kann selbst aus Subsystemen bestehen. Für die Softwaretechnik ist v.a. die 3-Schichten-Architektur für betriebliche Informationssysteme von Belang:

Benutzerschnittstelle
Anwendungskern
Datenbankschnittstelle
Datenbank

Die Datenbank wird nicht zum System dazugerechnet. Ein “Thick-Client” hat 1 und 2 auf dem selben Rechner, ein “Thin-Client” (z.B. eine Web-Anwendung) hat 1 und 2 auf unterschiedlichen Rechnern. Die Betrachtung der 3-Schichten-Architektur führt zum Model-View-Controller-Muster (MVC), einem Verbund von Entwurfsmustern bzw. Design Patterns.

7 – Design Patterns

Um MVC wirklich zu verstehen, muss man ein paar Muster kennen. Entwurfsmuster wurden geschaffen, um für oft wiederkehrende Probleme, die zueinander ähnlich sind, eine standardisierte Lösung zu haben. Sie haben den Vorteil, dass die Lösungsprinzipien wiederverwendbar sind, man damit Entwürfe abstrakt dokumentieren kann und Entwickler damit ein gemeinsames Vokabular zur leichteren Verständigung haben.

Man kann die gängigen Entwurfsmuster in drei Klassen unterteilen:

Creational Patterns: befassen sich mit der Erzeugung von Objekten. Beispiele sind Abstract Factory oder Singleton.
Structural Patterns: strukturelle Komposition von Objekten. Beispiele sind Adapter, Facade oder Composite.
Behavioral Patterns: Interaktion von Objekten und Verteilung von Verantwortlichkeiten. Beispiele sind Iterator, Observer, Template Method, State oder Strategy.

Davon möchte ich einige herausgreifen. Zuerst die Abstract Factory. Sie stellt eine Schnittstelle zum Erzeugen mehrerer zusammengehöriger oder verwandter Objekte zur Verfügung, ohne dass dazu die konkreten Objektklassen benötigt werden.

Klassendiagramm der Abstract Factory

Auch wichtig ist das Composite-Pattern. Es erlaubt, sowohl einzelne als auch zusammengesetzte Objekte einer Baumstruktur einheitlich zu behandeln. Es wird zum Beispiel für die GUI-Komponenten (AWT/Swing) in Java genutzt.

Klassendiagramm des Composite-Musters

Ein weiteres wichtiges Muster ist das State-Pattern. Es ermöglicht, dass ein Objekt sein Verhalten in Abhängigkeit von seinem Zustand ändern kann. Damit eignet es sich zur Realisierung von Zustandsdiagrammen via Zustandsobjekte.

Klassendiagramm des State-Musters

Eines der wichtigsten und häufigsten Muster ist Observer. Es arbeitet wie ein Newsletter-Verteiler: Wenn es etwas neues über das observierte Objekt gibt, dann schickt es an alle Angemeldeten eine Änderungsnotiz.

Klassendiagramm des Observer-Musters

Das vorhin genannte MVC ist eine Kombination aus Mustern, genauer gesagt eine Vereinigung von Observer, Strategy und Composite:

View und Controller implementieren Strategy. Alle Entscheidungen über das Verhalten delegiert View an Controller. View bleibt so entkoppelt vom Model, mit dem nur der Controller interagiert.
View selbst kann als Composite modelliert werden, z.B. indem jede Anzeigenkomponente (z.B. Fenster) ein Kompositum oder ein Blatt (z.B. Button) ist. Eine Aktualisierung des Views ruft einfach die entsprechende Funktion im Wurzelknoten auf, der dann entsprechend dem Muster den Aufruf weiterreicht.
Das Observer-Muster findet beim Model seine Anwendung. Interessierte Objekte werden bei Zustandsänderungen des Models informiert. So könnte man bspw. mehrere Views an ein Model binden.

MVC dient, wie bereits genannt, zur Implementierung der 3-Schichten-Architektur. Dabei dient View als Benutzerschnittstelle, Controller als Anwendungskern und Model als Datenbankanbindung. Diese Äquivalenz ist allerdings in Fachkreisen umstritten und wird von vielen Programmierern unterschiedlich gehandhabt (siehe dazu auch die Diskussionen im eher schlechten Wikipedia-Artikel).

Die “Kommunikation” im MVC spielt sich folgendermaßen ab:

V->M – attach(): V bindet sich als Observer an M.
V->C – handleEvent(): Der Nutzer hat im Interface ein Event ausgelöst, die View reicht es an den Controller weiter.
C->V – manipulate(): C manipuliert V (z.B. ein Dialog “Bitte Warten…”).
C->M – service(): C weist M an, entsprechende Daten zu ändern.
M->V – update(): M schickt eine Änderungsnotiz an seine Observer.
V->M – getData(): V holt sich die neuen Daten.
V – showData(): V zeigt dem Nutzer die aktualisierte Sicht auf die Daten.

8 – Datenbankanbindung

Es kann vorkommen, dass man Objekte in einer Datenbank speichern will. Das Objektmodell kann man folgendermaßen auf Tabellen/Relationen abbilden:

Bei der Abbildung von Klassen wird für jede Klasse ein Primärschlüsselattribut eingeführt.
Bei Multiplizität A* – *B (viele zu viele) erstellt man eine eigene Relation mit den Schlüsseln von A und B.
Bei Multiplizität A* – (0..1)B bindet man den Schlüssel von B als Fremdschlüssel in A ein.
Bei Multiplizität 0..1 – 0..1 nimmt man den Schlüssel der einen als Fremdschlüssel in die andere Relation auf.
Bei Vererbung hat man wie gehabt eine Tabelle pro Klasse, muss allerdings beachten, dass bei Anfragen, die Objekte der Unterklassen betreffen, ggf. Einträge in mehreren Relationen berücksichtigt werden. Man könnte auch in die Tabellen der Unterklassen die geerbten Attribute eintragen. Wenn sich allerdings die Oberklasse ändert, müssen auch die Unterklassen geändert werden. Eine dritte Möglichkeit ist, eine Tabelle für alle zu nutzen. Dann muss man allerdings an manchen Stellen NULL-Werte eintragen.

Der Rückweg (genannt Materialisierung) funktioniert umgekehrt analog.

So, das war’s erstmal wieder… genug Stoff zu lernen!

Datenbanksysteme

FB — Mon, 28 Jun 2010 21:21:21 +0000

Die nächste Lernzusammenfassung, heute zum Thema Datenbanksysteme, das sich um relationale Datenbanken, deren Formalisierung, Modellierung und SQL drehen wird.

Inhalt:
1 – Grundlagen
2 – Relationale Algebra
3 – Relationenkalkül
4 – Joins und weitere Operationen
5 – Views
6 – E/R-Modell
7 – Normalisierung
8 – Transaktionen

1 – Grundlagen

Relationale Datenbanken bestehen aus Relationen. Relationen kann man als Tabelle sehen, als Teilmenge des kartesischen Produkts von Domains oder als Ausprägung eines Relationenschemas. Domains sind in dem Fall die Spalten einer Tabelle bzw. Attribute und geben einen Wertebereich bzw. Typ vor. Als Grad oder auch Stelligkeit bezeichnet man die Anzahl der Domains bzw. Spalten. Die Zeilen werden Tupeln genannt.

Die Reihenfolge der Tupeln ist egal. Für die Reihenfolge der Attribute gilt das nicht, da sie durch ein Schema vorgegeben ist. Eine Ausnahme hiervon ist das ungeordnete Relationenschema, bei dem die Domain über ihren Namen referenziert wird (z.B. tupel3(domain2) = ‘Eintrag’).

Um Tupeln referenzieren zu können, benötigt man einen eindeutigen Identifikator, auch Schlüssel genannt. Ein Schlüssel ist wie folgt definiert:

Eine Teilmenge S der Attribute eines Relationenschemas R heißt Schlüssel, wenn gilt:

1. Eindeutigkeit: Keine Ausprägung von R kann zwei verschiedene Tupel enthalten, die sich in allen Attributen von S gleichen.

2. Minimalität: Keine echte Teilmenge von S erfüllt bereits die Bedingung der Eindeutigkeit.

Ein Schlüssel, der nur eindeutig ist, heißt Superschlüssel.

Oder mathematischer:

Sei r eine Relation über dem Relationenschema R und S eine Auswahl von Attributen und Teilmenge von R und t[S] ein Tupel t eingeschränkt auf die Attribute aus S (also alle anderen Attribute gestrichen). Dann muss für einen Schlüssel gelten:

1. Eindeutigkeit: Für alle möglichen Ausprägungen r und t1, t2 Element von r gilt: t1 =/= t2 => t1[S] =/= t2[S].

2. Minimalität: Für alle Attributmengen S und T, die die Eindeutigkeit erfüllen, gilt: Wenn T eine Teilmenge von S ist, dann muss T = S sein.

Es stellt sich natürlich die Frage, warum man unbedingt Datenbanken braucht. Man könnte ja stattdessen auch Dateien benutzen. Dateien haben allerdings zahlreiche Nachteile:

Bei einer Änderung des Dateiformates (z.B. neue Attribute) müssen alte Dateien konvertiert werden und nutzende Programme angepasst werden (logische Datenabhängigkeit).
Daten werden anhand ihrer Position adressiert => Die Suche nach bestimmten Attributwerten muss im Programm kodiert werden (physische Datenabhängigkeit).
Die Redundanz bei der Datenhaltung führt zu Änderungsanomalien (später mehr dazu), es müssen viele Dateien nach Einträgen durchsucht werden.
Es gibt eine Schnittstellenproblematik, die zur Unübersichtlichkeit bei mehrfachen Zugriffen führt, und allgemein keine Zugriffssynchronisation.
Es gibt keinen ausreichenden Schutz vor Datenverlust bei Systemabstürzen oder anderen Defekten.
Es gibt nur eine unflexible Zugriffskontrolle, der Datenschutz ist mangelhaft.

Deswegen verwendet man bei größeren geordneten Datenmengen ein Datenbanksystem, gerade wenn man spezielle Anforderungen hat. Diese können sein…

Integration: Einheitliche Verwaltung aller von Anwendungen benötigten Daten, redundanzfreie Datenhaltung
Operationen: O. zur Speicherung, Recherche und Manipulation der Daten müssen vorhanden sein
Data Dictionary: Ein Katalog erlaubt Zugriffe auf die Beschreibung der Daten
Benutzersichten bzw. Views: Für unterschiedliche Anwendungen unterschiedliche Sichten auf den Bestand
Konsistenzüberwachung: DBMS überwacht die Korrektheit der Daten bei Änderungen
Zugriffskontrolle: Ausschluss unautorisierter Zugriffe
Transaktionen: Zus.fassung einer Folge von Änderungsoperationen zu einer Einheit, deren Effekt bei Erfolg permanent in die Datenbank gespeichert wird
Synchronisation: Vermeidung von unbeabsichtigten gegenseitigen Beeinflussungen bei mehreren gleichzeitigen Datenbanknutzern
Datensicherung: Nach System- oder Medienfehlern wird die Wiederherstellung ermöglicht (Rekonstruktion des Zustands der letzten erfolgreichen Transaktion)

Ein Datenbanksystem kann man in 2 oder 3 Ebenen unterteilen.
Das 2-Ebenen-Modell kennt eine Intensionale und eine Extensionale Ebene. Das Datenbankschema wird als Intensionale Ebene bezeichnet. Es beschreibt den möglichen Inhalt, Struktur- und Typinformationen (Metadaten) und das Datenmodell. Änderungen sind möglich, aber selten. Die Extensionale Ebene ist die Ausprägung der Datenbank. Dabei handelt es sich um den tatsächlichen Inhalt, Objektinformationen und Attributwerte. Die Struktur ist durch das Schema vorgegeben. Änderungen kommen häufig vor.
Das 3-Ebenen-Modell teilt das Datenbanksystem in externe, konzeptionelle und interne Ebene. Die externe Ebene ist die Sammlung der individuellen Sichten aller Nutzer (bzw. externer Schemata) und zeigt, was der Nutzer sehen will, und zeigt nicht, was er nicht sehen soll. Die konzeptionelle Ebene ist die logische Gesamtsicht aller Daten, die mit einer Data Definition Language (DDL) beschrieben wird (Schema). Es handelt sich also um das Datenmodell des Datenbanksystems. Die interne Ebene bezieht sich auf die physische Speicherung der Datensätze, also auf das interne Schema (sprich Indexstrukturen etc.).

Eine DDL dient zu Deklarationen zur Beschreibung des Schemas, also bei relationalen Datenbanken z.B. zum Anlegen und Löschen von Tabellen, Festlegen von Integritätsbedingungen, etc.. Eine DML (Data Manipulation Language) bietet hingegen Anweisungen zum Arbeiten mit den Daten in der Datenbank.

Zu unterscheiden sind zwei Arten der Datenunabhängigkeit, die oben schon erwähnt wurden:
1. Logische Datenunabhängigkeit: Die Datenbank wird von Änderungen der Anwenderschnittstellen entkoppelt.
2. Physische Datenunabhängigkeit: Die Anwendungen sind von Änderungen des internen Schemas nicht betroffen.

2 – Relationale Algebra

Die relationale Algebra ist die mathematische Formalisierung von Tabellen und darauf möglichen Operationen. Sie ist abgeschlossen, d.h. Operationsergebnisse sind wiederum Elemente der Menge. Grundoperationen der relationen Algebra sind Vereinigung, Differenz, Kartesisches Produkt, Selektion (Auswahl von Zeilen) und Projektion (Auswahl von Spalten).Der Durchschnitt lässt sich als Kombination von Differenzen modellieren (A n B = A-(A-B) ). Joins sind Kombinationen von Selektion und Kreuzprodukt. Die auftretende Duplikatelimination ist kostenintensiv, der Aufwand beträgt O(n²) bzw. nach Sortieren O(n log n). Eine weitere Operation ist der Quotient, der die Umkehrung des Kartesischen Produkts darstellt.

SQL-Anfragen entsprechen den Grundoperationen. SELECT steht für eine Projektion, FROM für das Kreuzprodukt, WHERE für eine Selektion, UNION erlaubt Vereinigung mit Duplikatelimination und EXCEPT die Differenz. Zwar sind in SQL im Gegensatz zur Relationalen Algebra die Operatoren nicht beliebig schachtelbar, trotzdem sind aber alle algebraischen Ausdrücke darstellbar. Man nennt es deswegen relational vollständig.

3 – Relationenkalkül

Während die Relationale Algebra beschreibt, wie man zum Ergebnis kommt (prozedural), zeigt das Relationenkalkül, was das Ergebnis sein soll (deklarativ). Es gibt zwei Kalküle, nämlich das Tupelkalkül (mit angegebenem Schema) und das Bereichskalkül.

Das Tupelkalkül fokussiert sich auf die Ergebnistupel und beschreibt ihre Eigenschaften. Das sieht beispielsweise so aus:

Schema(t) = Schema(Städte) ~ (Name, Einwohner, Land)
{t | Städte(t) ∧ t.Land = Bayern ∧ t.SEinw ≥ 500.000}

Hier würden, die entsprechenden Relationen vorausgesetzt, die Tupel ausgewählt, die Großstädte in Bayern beinhalten. Das Tupelkalkül ähnelt nicht zufällig den aus der Mathematik bekannten Formulierungen zu Eigenschaften von Mengen. Die einzig freie Variable ist t, alle anderen Variablen müssen gebunden werden.

Das Bereichskalkül geht einen etwas anderen Weg und beschreibt den Bereich, in dem das Ergebnis liegt. Wieder ein anschauliches Beispiel:

{x3 | ∃ x2: (Städte(Passau, x2, x3) ) }

Hier wird abgefragt, in welchem Land Passau liegt. Die Anfrage besagt, dass x3 (also das Land) gesucht ist und irgendein x2 existiert, sodass bei einem x1 = Passau entsprechende Tupel in der Relation Städte existieren, die zurückgegeben werden sollen. Angefragte Elemente werden nicht beim Existenzquantor aufgeführt, Fremdschlüssel nur einmalig.

4 – Joins und weitere Operationen

Nach dem kurzen Ausflug in die Kalküle nun zu weiteren Operationen in SQL (Structured Query Language). Dazu zählen Joins, Gruppierungsoperationen, Aggregatfunktionen, Sortierung und Quantoren.

Ein Join ist die Vermengung von zwei Relationen. Es gibt verschiedene Arten von Joins:
- Inner Join: entspricht dem kartesischen Produkt eingeschränkt auf die Join-Bedingung, wobei die Tupeln ohne Joinpartner verloren gehen.. In SQL: SELECT * FROM a INNER JOIN b ON a.id = b.id
- Outer Join: Tupeln ohne Joinpartner bleiben erhalten und werden mit NULL-Werten aufgefüllt.
- Left bzw. Right Outer Join: linke bzw. rechte Relation bleibt verlustfrei
- Natural Join: Join über identische Attributnamen (im obigen Beispiel “id”)
- Cross Join: Kartesisches Produkt.

Gruppierungsoperationen werden mit GROUP BY eingeleitet, wobei alle Attribute der SELECT-Operation enthalten sein müssen. Einschränken kann man die Gruppierung mit HAVING, wobei nur Attribute aus der Gruppierung oder Aggregatfunktionen verwendet werden dürfen.

Sortieren ist möglich mit ORDER BY, bei Strings alphabetisch, bei Zahlen nach deren natürlicher Reihenfolge.

Aggregatfunktionen sind z.B. count(a), um die Vorkommen von a zu zählen, max(a), um das Maximum aller a zu bestimmen oder sum(a), um alle a zu summieren. Man kann sie entweder in der SELECT- oder in der HAVING-Anweisung verwenden, aber nicht in WHERE.

Quantoren sind ALL, SOME und ANY. Bei ALL müssen alle Elemente die spezifizierte Bedingung erfüllen, bei SOME einige und bei ANY irgendein Element. Quantoren finde ich nicht so intuitiv wie eine herkömmliche Formulierung, evtl. mittels Subqueries. Mann kann gottseidank auf sie verzichten.

Tabellen erstmal erstellen kann man mit CREATE TABLE name ( Attributdefinitionen ), siehe zusammenfassend hier. Eine Attributdefinition hat die Form name typ integritätsbedingung. Löschen kann man sie wieder mit DROP TABLE name. Neue Datensätze kann man einfügen mit dem Befehl INSERT INTO name (spalte1, spalte2, …) VALUES (wert1, wert2, …). Die Tabelle ändern kann mittels ALTER TABLE name ADD attr varchar(30), um z.B. ein neues Attribut hinzuzufügen, ALTER TABLE name DROP attr, um es zu löschen, oder ALTER TABLE name MODIFY attr float(3), um das Attribut zu ändern. Möglich ist eine Änderung auch mittels UPDATE name SET spalte1 = wert1 WHERE bedingung.

5 – Views

Views dienen als abstrahierte Benutzersichten auf die Datenbank. Im Grunde sind Views nichts anderes als Relationen, die eine bestimmte Ansicht auf in der Datenbank vorhandene Relationen geben. Für den Benutzer sehen sie aus wie eine Relation, sind aber nicht real, sondern aus anderen Relationen berechnet. Der Befehl dazu ist (mit angefügtem Beispiel):

CREATE VIEW name AS
SELECT s.ort, s.einwohner, l.name, l.einwohner
FROM Städte s NATURAL JOIN Länder l
WHERE l.einwohner > 5.000.000

Löschen kann man sie mit DROP VIEW name. Auf Views sind alle Operationen erlaubt außer Sortieren. Probleme gibt es bei DISTINCT und arithmetischen Anweisungen. Dann sind Insert, Delete und Update nicht möglich. Join-Views sind außerdem nicht aktualisierbar. Reale Views nennt man materialisierte Views.

Rechte kann man mit GRANT rechteliste/all ON relation/view TO benutzerliste [WITH GRANT OPTION] erteilen.

6 – E/R-Modell

Das E/R-Modell stellt eine Möglichkeit dar, ein reales Problem als Beziehung von Entitäten zu formalisieren. Die Entitäten besitzen im Normalfall noch Attribute. Das E/R-Modell hilft bei der Umsetzung in ein relationales Datenbankschema, das man ablesen kann, indem man die Entitäten in Relationen umwandelt, die Attribute in deren Domains und die Beziehungen als Fremdschlüssel oder als Schlüsselpaar-Relationen modelliert.

Beispiel für das E/R-Modell

Als Relationen für das obere Beispiel würden sich hier anbieten:
Angestellter(Name, Kürzel)
Projekt(Kürzel, AngKürzel)
Unterstrichen bedeutet hierbei, dass das Attribut der Schlüssel der Relation ist, Kursivdruck, dass es sich um einen Fremdschlüssel handelt.

7 – Normalisierung

Um in allen Fällen aus dem E/R-Diagramm die entsprechenden Relationen lesen zu können und dabei kein problematisches Datenbankschema zu bekommen, nutzt man die Normalisierung.

Die möglichen Probleme sind v.a. Anomalien, die durch Redundanzen entstehen. Es gibt Insert-, Update- und Delete-Anomalien. Eine Insert-Anomalie tritt dann auf, wenn für das Einfügen eines Datensatzes ein Attribut nötig ist, das in der Realität dafür belanglos ist. Wenn in obiger Relation bspw. noch Projekt als Attribut in der Relation Angestellter wäre, könnte man keinen Angestellten hinzufügen, der noch keinem Projekt zugewiesen ist. Eine Update-Anomalie würde dann bspw. auftreten, wenn der Mitarbeiter mehreren Projekten zugewiesen ist, also mehrere Tupel belegt und man zur Änderung seines Kürzels nur auf eine Tupel zugreift (anstatt sie in allen zu ändern). Eine Delete-Anomalie wäre, wenn durch das Löschen aller Projekte einer Person der Datensatz zur Person verschwindet.

Redundanzen sind eng verknüpft mit dem Begriff der Funktionalen Abhängigkeit. Sie ist wie folgt definiert:

Gegeben ein Relationenschema R und A, B als Mengen von Attributen bzw. Teilmengen von R.
B ist genau dann von A funktional abhängig (A->B), wenn für alle möglichen Ausprägungen von R gilt:
1. Für alle r, s ε R mit r.A = s.A gilt r.B = s.B
2. Zu jedem Wert in A existiert genau ein Wert in B.

Bei der Funktionalen Abhängigkeit (FA) handelt es sich um eine Verallgemeinerung des Schlüsselkonzepts. Der Unterschied zum Schlüssel besteht darin, dass ein Attribut auch von Nicht-Schlüssel-Attributen oder nur einem Teil des Schlüssels abhängig sein kann. Eine volle FA ist A->C, eine partielle FA A,B->C, wenn C in beiden Fällen nur von A funktional abhängig ist.

Es gibt auch mehrwertige Abhängigkeiten, die wie folgt definiert sind:

Gegeben a,b,c ε R mit R = a u b u c (Vereinigung)
b ist dann mehrwertig abhängig von a (a->->b), wenn für jede gültige Ausprägung von R gilt: Für jedes Paar aus Tupeln t1, t2 mit t1.a = t2.a, aber t1.bc =/= t2.bc existieren zwei weitere Tupel t3 und t4 mit den Eigenschaften:
t1.a = t2.a = t3.a = t4.a
t3.b = t1.b
t4.b = t2.b
t3.c = t2.c
t4.c = t1.c
Jede FA ist auch eine mehrwertige Abhängigkeit (MVD).

Die triviale Abhängigkeit ist die Abhängigkeit eines Elements von sich selbst. Jedes Element ist von sich selbst abhängig.

Neben Schlüsseln gibt es auch Schlüsselkandidaten. Das sind Attribute, die als Schlüssel in Frage kommen. Als Beispiel: In der Relation Auto(HerstellerName, HerstellerNr, Modell) wären die Schlüsselkandidaten (HerstellerName, Modell) und (HerstellerNr, Modell).

Nachdem wir nun wissen, was Funktionale Abhängigkeiten und Schlüsselkandidaten sind, können wir uns an die Normalisierung wagen. Es gibt verschiedene Normalformen, die folgende Voraussetzungen haben:

1. Normalform: Alle Attributwerte müssen atomar sein. In relationalen Datenbanken ist das eh nicht möglich (nur temporär bei GROUP).
2. Normalform: Jedes Attribut ist voll funktional abhängig von allen Schlüsselkandidaten (SK) oder prim, d.h. Teil eines SK. Sie besagt, dass es keine partiellen Abhängigkeiten geben soll.
3. Normalform: Für jede nichttriviale Abhängigkeit X->A gilt: X enthält einen SK oder A ist prim. Sie besagt, dass es keine transitiven Abhängigkeiten geben soll (z.B. A->C bei A->B->C). Außerdem besagt sie, dass es keine FA von nicht-primen Attributen geben soll.
Boyce-Codd-Normalform (BCNF): Für jede nichttriviale Abhängigkeit X->A gilt: X enthält einen SK. Der Grund dafür, dass die Prim-Möglichkeit der 3.NF wegfällt, ist, dass auch dort Anomalien auftreten können. In der obigen Relation Auto sind alle Attribute prim, aber HerstellerName->HerstellerNr. Solche Abhängigkeiten werden mit der BCNF eliminiert. Man könnte auch formulieren, dass es keine FA zwischen SK-Attributen geben darf.
4. Normalform: Für jede MVD a->->b gilt: Die MVD ist trivial oder a ist ein Superschlüssel.

Die Normalisierung führt zu einem ausgegorenen Datenbankschema. Um die einzelnen Anforderungen zu erreichen, werden Abhängigkeiten in eigene Relationen ausgelagert. Bis zur 3. Normalform kann das ursprüngliche Schema verlustfrei und abhängigkeitserhaltend zerlegt werden.Normalisierung ist allerdings teilweise schädlich für die Performanz. Deswegen sollte man in der Realität nicht jede FA berücksichtigen, sondern lieber Integritätsbedingungen formulieren, um Anomalien zu vermeiden.

Zur Normalisierung bis in die 3. NF gibt es eine eingängliche Vorgehensweise, den Synthesealgorithmus. Er funktioniert wie folgt:
1. Bestimmung der kanonischen Überdeckung
1.1. Linksreduktion: Eliminierung partieller FA
1.2. Rechtsreduktion: Eliminierung transitiver FA (dabei direkte FA auf leere Menge kürzen)
1.3. Entfernen rechtsleerer FA, die evtl. in 1.2. entstanden sind
1.4. Zusammenfassen von FA mit gleichen linken Seiten.
2. Relationenschema bilden
3. Rekonstruktion eines SK: Wenn SK nicht vollständig in einer Rel., dann neue Rel. bestehend aus SK
4. Elimination überflüssiger Relationen (in anderen Rel. enthaltene Rel.)

Als Beispiel hierzu:
Sei die Relation R(A,B,C,D,E) mit dem SK (A,B) gegeben mit den FA
a) A -> C, D // = A->C und A->D
b) A, B -> C
c) B, C -> E
d) A, B -> E
Die Schritte sind dann…
1.1. b) wird zu A->C, B fällt weg, da a) schon besagt, dass A->C
1.2. d) wird zu A,B -> Ø, da es mit c) eine transitive Abh. gibt: A, B -> B,C -> E
1.3. d) wird entfernt
1.4. b) wird mit a) zusammengelegt, übrig geblieben sind a) A->C,D und c) B,C->E
2. Relationenschema: R1(A,C,D) und R2(B,C,E)
3. Rekonstruktion eines SK (hier A,B) nicht möglich, deswegen neue Relation R3(A,B)
4. Eliminierung überflüssiger Relationen hier nicht möglich, da keine überflüssig ist.

8 – Transaktionen

Eine Transaktion ist eine Folge von Befehlen, die die Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand überführt, also ein Einheit integritätserhaltender Zuständsänderungen einer Datenbank.

Wichtig sind dabei als Aufgaben des Datenbankmanagementsystems (DBMS) Synchronisation bei Mehrfachzugriffen, Integritätserhaltung (Typintegrität, Schlüsselintegrität, Referentielle Integrität bzw. Fremdschlüsselintegrität) und Schutz gegen Datenverlust. Griffig formuliert wurden die Anforderungen an ein DBS bezüglich Transaktionen im sogenannten ACID-Prinzip:
A = Atomicity = Atomarität: Eine Transaktion wird entweder ganz oder gar nicht in die Datenbank übernommen.
C = Consistency = Konsistenz: Eine Transaktion führt von einem konsistenten Zustand zu einem konsistenten Zustand.
I = Isolation: Ein Nutzer nimmt einen anderen bei gleichzeitigen Zugriffen nicht wahr.
D = Durability = Persistenz: Eine abgeschlossene Transaktion bleibt dauerhaft in der Datenbank erhalten.

Befehle für Transaktionen sind BOT (Begin Of Transaction), der bei SQL implizit ist, EOT (End Of Transaction), bei SQL heißt es COMMIT, abort (SQL: ROLLBACK [TO name]) und save (SAVEPOINT name).

Bei Transaktionen können Fehler und Anomalien auftreten. Fehler sind entweder Transaktionsfehler (z.B. Fehler im Anwendungsprogramm, Deadlock), Systemfehler (z.B. Stromausfall, OS-Absturz) oder Medienfehler (z.B. Festplattencrash). Sie können durch Lokales Undo (Rücksetzung auf BOT), Globales Undo (Rücksetzung aller nicht-abgeschlossenen Transaktionen in der DB) und Globales Redo (Nachführen aller bereits abgeschlossenen Transaktionen, die noch nicht in der DB sind) überwunden werden. Dazu braucht es Zusatzinformationen aus einer Logdatei, die alle Aktionen protokolliert.

Anomalien können bei unkontrolliertem Mehrbenutzerbetrieb auftreten. Das können verlorengegangene Änderungen (Lost Updates, verursacht durch Überschreiben) oder der Zugriff auf schmutzige Daten (Dirty Read/Write, Lesen und Schreiben auf geänderten Werten, die später zurückgesetzt werden) oder nicht reproduzierbares Lesen sein (Non-Repeatable Read, nochmaliges Auslesen liefert anderen Wert durch Änderungen einer anderen Transaktion). Eine Ausprägung des Non-Repeatable Read ist das “Phantomproblem”, das beim Auslesen Aggregatfunktionen nutzt, deren Ergebnis nicht mit der Anfrage in Einklang zu bringen ist, da zwischendrin eine DB-Änderung durch eine andere Transaktion stattfand.

Diese Synchronisationsprobleme treten nur bei Schreibvorgängen auf. Um ihnen zu entgehen, nutzt man entweder Locking als pessimistische Ablaufsteuerung oder ein Zeitstempelverfahren als optimistische Ablaufsteuerung. Locking ist das Standardverfahren und sperrt bei kritischen Transaktionen die betroffenen Ressourcen. Beim Zeitstempelverfahren werden Transaktionen im Konfliktfall zurückgesetzt. Es ist deswegen nur geeignet, wenn Konflikte zwischen Schreibern selten auftreten. Es ist auch möglich, zur Performanzverbesserung mit SET TRANSACTION READ-ONLY festzulegen, dass eine Transaktion nur lesend zugreift.

Markupsprachen und semistrukturierte Daten

FB — Mon, 28 Jun 2010 21:19:44 +0000

Mal wieder eine Zusammenfassung meines Lernaufwands des vergangenen Monats, um mir das ganze leichter einzuprägen und nochmal gedanklich zu ordnen. Heute zum Thema “Markupsprachen und semistrukturierte Daten”, ein Überblick von HTML und XML bis Googles Funktionsweise.

Inhalt:
1 – Herkunft und Begriffsdefinition
2 – HTML und CSS
3 – XML, DTD und XML-Schema
4 – XPath, XQuery, XSLT
5 – RDF, SPARQL
6 – Information Retrieval und Suchmaschinen

1 – Herkunft und Begriffsdefinition

Markupsprachen sind Sprachen zur Auszeichnung von Text (und anderen Daten). Früher diente “Markup” den Typographen im Druckergewerbe für Notizen im Text, um z.B. zu wissen, welcher Abschnitt kursiv gedruckt werden soll. Außerdem wurde eine Druckseite zu Zeiten der Schreibmaschine als Matrix (bzw. Array) organisiert, sprich in gleich große Zeilen und Spalten unterteilt. Diese Festlegung bewirkt zahlreiche Probleme, darunter die Beschränkung auf ein unhandliches Layout, das teilweise der Struktur nicht gerecht wird, und zuvorderst die Schwierigkeit, einen bereits geschriebenen Text zu editieren.

Deswegen schwenkte man in der PC-Ära auf die sogenannte “Spaghetti”-Repräsentation um, d.h. der Text ist eine fortlaufende Zeile. Das hat den entscheidenden Vorteil, dass man für ein Update nur die Zeichennummer wissen muss (bzw. die Adresse/Pointer), wo man ein Zeichen einfügen, löschen oder ändern will. Editieren wird somit viel leichter. Der Nachteil ist allerdings, dass der Speicher dabei zugemüllt wird. Damit wird eine Bereinigung (Garbage Collection) nötig. Ein sehr großer Vorteil der “Spaghetti” ist außerdem, dass ein und die selbe Datenstruktur leicht auf unterschiedliche Weise darstellbar ist, z.B. die Anzeige zwischen lateinischen (l.n.r.), japanischen (o.n.u.) oder arabischen (r.n.l.) Zeichen wechseln kann, ohne dass man die komplette Matrix umschreiben müsste. Es genügen dafür entsprechende Layout-Anweisungen, auf die später noch eingegangen wird.

Heute dient Markup zur Datenmodellierung (bzw. Textformatierung), Datenstrukturierung (Repräsentation der logischen oder semantischen Struktur von Dokumenten) und zum Datenaustausch. Aus allen drei Bereichen sind Markupsprachen nicht mehr wegzudenken. XML und darauf basierende Eigenentwicklungen nehmen dabei eine herausragende Rolle ein.

Markup kann man in drei Arten unterteilen:
1. Spezifisches Markup: Dabei handelt es sich um layout-orientiertes Markup wie z.B. bei PostScript oder anderen Seitenbeschreibungssprachen. Dazu passende HTML-Befehle wären z.B. oder für Fett- bzw. Kursivdruck.
2. Generalisiertes Markup ist dagegen struktur-orientiert. HTML, LaTeX und RTF besitzen sowohl spezifische wie auch generalisierte Elemente. Ein Beispiel für diesen Bereich wäre MathML. Generalisiertes Markup für Fett- und Kursivdruck in HTML wären und .
3. Generisches Markup: Dazu zählen Metasprachen wie XML, mit deren Hilfe man selbst Markupsprachen entwickeln kann. Das obige Beispiel generisch weitergedacht würde z.B. als Element einführen.

2 – HTML und CSS

Seinen geschichtlichen Ursprung hat HTML am CERN in Genf, wo Tim Berners-Lee Ende der 80er eine Markupsprache entwickelte, um einfach wissenschaftliche Dokumente mit anderen austauschen zu können und darin Links zu Quellen zu plazieren. Wenig später wurde das WWW begründet und dazu das Konsortium (W3C) gegründet, das über HTML wachen sollte. 1992 wurde es erstmals standardisiert. Das W3C gab über die Jahre zahlreiche Empfehlungen zur HTML-Implementierung heraus (”Recommendations”), die es mit den großen Firmen der Branche erarbeitet. Im Jahr 2000 erschien XHTML, eine Anpassung von HTML an die XML-Spezifikationen, v.a. eine striktere Syntax mit dem Ziel einer einfacheren Interpretation durch Web-Browser und Prüfungswerkzeugen.

Ein (X)HTML-Dokument ist ähnlich aufgebaut wie ein XML-Dokument. Es besteht aus einem Prolog, der Sprache, Grammatik und Zeichensatz festlegt, einem Kopfteil bzw. “Head”, der den Titel des Dokuments, Links z.B. zu Stylesheets, Skripte und Metadaten beinhaltet und die Wiedergabe des Dokuments definiert und schließlich einem Körper bzw. “Body”, der den eigentlichen Text beinhaltet. Das sieht beispielsweise so aus:

“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

<br /> Beispieldokument<br />

….

Hier bestimmt die erste Zeile, welche XML-Version und welcher Zeichensatz benutzt wird. Diese Zeile ist im Web eher unnötig und führt z.B. beim Internet Explorer zu einem Performanzverlust. Die zweite weist zur DTD, die wir später noch besprechen werden. Der Header beginnt nach dem -Tag, der zusätzlich noch Namensraum und Sprache festlegt. Im Header ist wieder ein (hier redundanter) Hinweis auf den Zeichensatz gegeben (besser als Zeile 1 für IE) und ein Beispiel für die Integration von einem Stylesheet und einer JavaScript-Datei.

CSS

Nun war schon öfter die Rede von Stylesheets. Sie sind eine geordnete Sequenz von Regeln und werden genutzt, um der durch XHTML beschriebenen Struktur ein Layout zu geben. CSS (Cascading Stylesheets) ist hier das Mittel der Wahl. “Cascading” besagt hierbei, dass im Konfliktfall die geltende Regel nach einem kaskadierenden Muster ausgewählt wird, sprich die verschiedenen Regeln nach Wichtigkeit (Spezifizität) durchgegangen werden und die wichtigste ausgewählt wird.

CSS kann entweder als externe Datei eingebunden werden (wie oben im Beispiel mit ) oder im Header als Style-Anweisung (