Nun, seit dem Film sind einige Jahre vergangen und ich habe in der Zwischenzeit den ein oder anderen Helfer bzw. Zeitgenossen programmiert, gebaut oder einfach gekauft. Angefangen von Sunny, meinem persönlichen KI-Assistenten (Powered by NVIDIA) (Siehe meinen Beitrag „Intelligenter Home Assistant – Projekt Sunny„), über Google Home (Stark modifiziert), zu Microsoft’s AI Lösungen, bis hin zu Vector dem kleinen lustigen Kerlchen, der gerne kleine Würfel mit Barcodes transportiert.

Künstliche Intelligenz (KI), auch artifizielle Intelligenz (AI bzw. A.I.) bzw. Artificial Intelligence, in englischer Sprache, ist ein Teilgebiet der Informatik. Es umfasst alle Anstrengungen, deren Ziel es ist, Maschinen intelligent zu machen. Dabei versteht man unter Intelligenz die Eigenschaft, die ein Wesen befähigt, angemessen und vorausschauend in seiner Umgebung zu agieren. Dazu gehört die Fähigkeit, Sinneseindrücke wahrzunehmen und darauf zu reagieren, Informationen aufzunehmen, zu verarbeiten und als Wissen zu speichern, Sprache zu verstehen und zu erzeugen, Probleme zu lösen und Ziele zu erreichen.

Man kann die künstliche Intelligenz in verschiedene Teilgebiete aufteilen.

Diese sind:

• Computer Vision
• Robotik
• Mustererkennung, wozu auch Spracherkennung und Handschrifterkennung zählen
• Wissensmodellierung einschließlich Logischer Programmierung und Inferenzmaschinen
• Expertensysteme, Frage-Antwort-Systeme und Chatbots
• Maschinelles Lernen
• Künstliche neuronale Netze und Deep Learning
• Universelle Spieleprogramme.

Was ist künstliche Intelligenz?

Künstliche Intelligenz (KI) bezieht sich auf die Fähigkeit von Maschinen, Aufgaben auszuführen, die normalerweise menschliche Intelligenz erfordern. Dies kann beispielsweise das Erkennen von Sprache, das Verstehen von Bildern, das Lösen von Problemen und das Treffen von Entscheidungen umfassen.

KI-Algorithmen und -Systeme basieren auf einer Vielzahl von Technologien, darunter maschinelles Lernen, neuronale Netze, natürliche Sprachverarbeitung und Deep Learning. Diese Technologien ermöglichen es KI-Systemen, aus Erfahrungen und Daten zu lernen, ihre Fähigkeiten zu verbessern und Entscheidungen zu treffen, die auf den gelernten Mustern basieren.

Es gibt zwei Hauptarten von KI: schwache KI und starke KI. Schwache KI-Systeme sind auf spezifische Aufgaben beschränkt und können nur innerhalb des Bereichs operieren, für den sie entwickelt wurden. Beispiele für schwache KI-Systeme sind Spracherkennungsprogramme und Bilderkennungsprogramme. Starke KI-Systeme hingegen sind in der Lage, menschenähnliche Intelligenz auf einer Vielzahl von Gebieten zu demonstrieren. Dieses Niveau der KI ist jedoch offiziell bisher nicht erreicht worden und bleibt eine Herausforderung für Forscher auf dem Gebiet.

KI hat zahlreiche Anwendungen in vielen Branchen, einschließlich Medizin, Finanzen, Automobilindustrie, Bildung und vielen anderen. Einige Beispiele für KI-Anwendungen sind personalisierte Empfehlungssysteme, autonome Fahrzeuge, Chatbots, medizinische Diagnosesysteme und Prognosesysteme für die Wettervorhersage.

KI bietet große Vorteile für Unternehmen und Organisationen, insbesondere in Bezug auf Effizienz und Produktivität. Es gibt jedoch auch Bedenken hinsichtlich der Ethik und Sicherheit von KI, insbesondere in Bezug auf Datenschutz und Diskriminierung. Es ist wichtig, dass KI-Systeme transparent, verantwortungsbewusst und ethisch entworfen, implementiert und betrieben werden, um sicherzustellen, dass sie das Gemeinwohl unterstützen und nicht beeinträchtigen.

Kurze Zeitreise

Die Idee der künstlichen Intelligenz (KI) geht auf das frühe 20. Jahrhundert zurück, als der britische Mathematiker Alan Turing erstmals die Möglichkeit eines intelligenten Computers diskutierte. Turing schlug vor, dass ein Computer intelligent genug sein könnte, um menschenähnliche Gespräche zu führen.

In den 1950er Jahren begannen Wissenschaftler und Ingenieure, konkrete Forschung im Bereich der KI zu betreiben. Der amerikanische Mathematiker und Informatiker John McCarthy prägte den Begriff „künstliche Intelligenz“ und organisierte eine Konferenz, die als Geburtsstunde der modernen KI gilt. In den 60er Jahren hat man dann die ersten KI-Programme entwickelt, die einfache Probleme wie Schach spielen oder einfache mathematische Probleme lösen konnten.

In den 70er Jahren geriet die KI-Forschung jedoch in eine Krise. Die meisten KI-Systeme konnten nur sehr begrenzte Aufgaben ausführen und die Erwartungen an die Technologie waren zu hoch. Die KI-Forschung stagnierte bis in die 80er Jahre, als man neue Technologien wie neuronale Netze und maschinelles Lernen entwickelt hatte.

In den 90er Jahren begann man damit, KI-Systeme in verschiedenen Bereichen wie Spracherkennung, Bildverarbeitung und Robotik einzusetzen. Diese Anwendungen ermöglichten es der KI-Technologie, konkrete Ergebnisse zu liefern und die Aufmerksamkeit von Unternehmen und Investoren zu gewinnen.

Im 21. Jahrhundert hat sich die KI-Forschung und -Entwicklung rasant weiterentwickelt. Man verwendet KI-Systeme jetzt in vielen Branchen und Anwendungen. Von der Medizin bis zur Finanzindustrie, von autonomen Fahrzeugen bis hin zu intelligenten Assistenten. Es gibt jedoch auch Bedenken hinsichtlich der Ethik und Sicherheit von KI. Insbesondere in Bezug auf Datenschutz, Diskriminierung und Autonomie. Die KI-Forschung und -Entwicklung spielt eine wichtige Rolle in der Technologie- und Geschäftswelt und ist ein Bereich von großem Interesse für Wissenschaftler, Ingenieure und Unternehmer.

Wie lernt die künstliche Intelligenz?

Künstliche Intelligenz (KI) verwendet verschiedene Techniken des maschinellen Lernens, um aus Erfahrungen und Daten zu lernen. Das maschinelle Lernen basiert auf Algorithmen und mathematischen Modellen, die es dem System ermöglichen, Muster und Zusammenhänge in den Daten zu identifizieren und zu generalisieren. Das Lernen in KI-Systemen erfolgt in der Regel in drei Schritten: Datenvorbereitung, Trainingsphase und Anwendung.

1. Datenvorbereitung

In der Datenvorbereitung werden die Daten, auf denen das KI-System trainiert werden soll, vorbereitet und in ein Format gebracht, das von den Algorithmen und Modellen verarbeitet werden kann. Dies beinhaltet in der Regel das Sammeln, Reinigen, Strukturieren und Labeln von Daten.

2. Trainingsphase:

In der Trainingsphase wird das KI-System auf der Grundlage der vorbereiteten Daten trainiert. Das System wird mit Daten und deren zugehörigen Labels oder Zielen versorgt. Das System nutzt dann mathematische Algorithmen und Modelle, um Muster und Zusammenhänge in den Daten zu identifizieren und diese Muster in eine allgemeine Regel oder Funktion zu überführen. Während des Trainingsprozesses passt das System seine Modelle und Algorithmen an, um die Genauigkeit und Leistung des Systems zu verbessern.

3. Anwendung:

Nach Abschluss des Trainings kann das KI-System angewendet werden, um neue Daten zu analysieren und Vorhersagen oder Entscheidungen zu treffen. Das System kann auf verschiedene Weise eingesetzt werden, z.B. zur Vorhersage von zukünftigen Ereignissen, zur Identifizierung von Mustern in Daten, zur Entscheidungsfindung oder zur Automatisierung von Aufgaben.

Arten der künstlichen Intelligenz

Es gibt verschiedene Arten von maschinellem Lernen, darunter überwachtes Lernen, unüberwachtes Lernen und bestärkendes Lernen. Überwachtes Lernen wird verwendet, wenn das System mit gelabelten Daten trainiert wird, um Vorhersagen oder Entscheidungen zu treffen. Unüberwachtes Lernen wird verwendet, wenn das System mit unlabeled Daten trainiert wird, um Muster und Zusammenhänge in den Daten zu identifizieren. Bestärkendes Lernen wird verwendet, um ein System zu trainieren, indem es durch Versuch und Irrtum lernt, indem es Belohnungen oder Strafen für seine Aktionen erhält.

Insgesamt hängt das Lernen der künstlichen Intelligenz von den Daten ab, auf denen das System trainiert wird und von den verwendeten Algorithmen und Modellen. Die Genauigkeit und Effektivität des Lernens hängen auch von der Qualität der Daten ab, die für das Training verwendet werden, sowie von der Fähigkeit des Systems, Muster und Zusammenhänge in den Daten zu identifizieren und auf neue Situationen zu generalisieren.

Fazit

Künstliche Intelligenz (KI) hat das Potenzial, die Art und Weise zu verändern, wie wir leben und arbeiten. Durch maschinelles Lernen und fortgeschrittene Algorithmen können KI-Systeme menschenähnliche Intelligenz auf eine Vielzahl von Aufgaben anwenden, von der Bilderkennung bis hin zur Entscheidungsfindung.

KI bietet zahlreiche Vorteile in verschiedenen Branchen und Anwendungen, von der Verbesserung der medizinischen Diagnostik bis hin zur Automatisierung von Arbeitsabläufen. Unternehmen und Organisationen können von der Effizienz und Produktivität profitieren, die KI-Systeme bieten können.

Es gibt jedoch auch Bedenken und Herausforderungen im Zusammenhang mit KI, insbesondere in Bezug auf Datenschutz, Sicherheit, Ethik und Diskriminierung. Es ist wichtig, dass KI-Systeme transparent und verantwortungsbewusst entwickelt, implementiert und betrieben werden, um sicherzustellen, dass sie das Gemeinwohl unterstützen und nicht beeinträchtigen.

Die KI-Entwicklung spielt voraussichtlich auch weiterhin eine wichtige Rolle in der Technologie- und Geschäftswelt und man kann durchaus damit rechnen-, dass die Technologie in den kommenden Jahren noch weitere Verbesserungen erfährt und neue Anwendungsgebiete erschließt. Es ist wichtig, dass wir uns auf eine verantwortungsvolle und ethische Nutzung von KI konzentrieren, um sicherzustellen, dass wir die Vorteile nutzen und gleichzeitig sicherstellen, dass wir die Risiken und Herausforderungen im Zusammenhang mit dieser fortschrittlichen Technologie verstehen und berücksichtigen.

Der Beitrag Künstliche Intelligenz – Zukunft gestalten und menschliches Potenzial mit innovativen Technologien entfesseln erschien zuerst auf CEOsBay.

Man verwendet den Ausdruck Modultest unter anderem bei frühen Teststufen, in denen man die inneren, detailliertesten Komponenten der Software testet. Gemäß Software Validation & Verification Plan sind diese Tests nur für Module mit geringer Kritikalität nicht notwendig. Im Grunde genommen bei Fehlern, die dem User nur geringfügige Unannehmlichkeiten bereiten.

In einer Abstraktion der verwendeten Programmiersprache, spricht man von Komponente oder Softwarebaustein. Den Test eines solchen einzelnen Softwarebausteins bezeichnet man auch allgemeiner als Komponententest.

Als Testbasis kann man in der Regel die komponentenspezifische Anforderung und das Softwaredesign der Komponente (auch Komponentenspezifikation genannt) heranziehen. Für Whitebox-Testfälle oder um Aussagen zur Codeüberdeckung zu erhalten, kann man zusätzlich den Sourcecode einer Komponente analysieren und diesen als Testbasis verwenden. Wobei dabei auch Tools wie Jacoco helfen können. Ob die Komponente auf einen Testfall richtig reagiert, muss man allerdings auch hier auf Basis der Design- und Anforderungsdokumente beurteilen.

Typische Testobjekte sind wie bereits beschrieben Programmunits, -Module bzw. Klassen. Aber auch Kommandozeilenskripte des Betriebssystems (Shell-Skripte), Datenbankskripte, Datenkonvertierungs- oder Migrationsprozeduren, Datenbankinhalte sowie Konfigurationsdaten können Testobjekte sein. Kennzeichnend ist in der Regel der isolierte Test eines einzelnen Softwarebausteins. Dies dient primär, um komponentenexterne Einflüsse beim Testen auszuschließen. Alle so ermittelten Fehler kann man so dem spezifischen Modul zuordnen.

Klar zu unterscheiden ist auf jeden Fall der Integrationstest, den ich in einem separaten Beitrag thematisiere. Bei einem Integrationstest konzentriert man sich auf die Wechselwirkung mit Nachbarkomponenten.

Die Erstellung solcher Tests ist in der Regel die Aufgabe eines Programmierers. Dies liegt zum einen daran, dass man ein ausgeprägtes Verständnis für die Programmiersprache in der die Anwendung geschrieben ist haben muss. Und zum anderen daran, dass man meist auch einen Testtreiber benötigt, dessen Programmierung in der Regel auch der Entwickler übernimmt.

Einordnung im Testprozess

Algorithmen auf Unitebene besitzen meist nur eine begrenzte Komplexität und man kann sie über klar definierte Schnittstellen aktivieren. Daher kann sie mit relativ wenigen Testfällen weitgehend vollständig testen. Dies gilt als Voraussetzung für die anschließende Teststufe. Dem Integrationstest, um dort die Testfälle auf das integrierte Zusammenwirken größerer Funktionsteile oder der gesamten Anwendung ausrichten zu können. Die modulspezifischen Detailkonstellationen lassen sich damit auf Stichproben beschränken, was die Anzahl der erforderlichen Testfälle signifikant reduziert.

Zum Vergleich: Ein Gerät wird erst dann als Ganzes getestet, wenn die Funktionsfähigkeit seiner Einzelteile gesichert ist.

Test des Vertrages und nicht der Algorithmen

Man testet bei Modultests gemäß dem Design-by-contract-Prinzip möglichst nicht die Interna einer Methode, sondern nur ihre externen Auswirkungen (Rückgabewerte, Ausgaben, Zustandsänderungen, Zusicherungen). Sind die internen Details der Methode geprüft (dies wird als White-Box-Testing bezeichnet), kann der Test fehlschlagen, obwohl sich die externen Auswirkungen nicht geändert haben. Daher empfiehlt man in der Regel das sogenannte Black-Box-Testing, bei dem man sich auf das Prüfen der externen Auswirkungen beschränkt.

Was sind die Vorteile von Unit Tests?

• Mittels automatisierter Unittests kann man im Schnitt 30 % der Fehler erkennen. Bei der Verwendung von TDD (Test Driven Development) kann man im Schnitt 45 % und im besten Fall 85 % der Fehler vermeiden.
• Fehler erkennt man durch Modultests bereits während der Entwicklung. Die durch Unittests vermiedenen Fehlerkosten sind daher gemäß der Rule of Ten (Dazu später mehr) um ein Vielfaches höher als bei späteren Teststufen, was Unittests zur effizientesten Teststufe machen.
• Im Falle eines Fehlers kann man diesen sehr viel genauer eingrenzen und damit schneller finden und beheben.
• Die Tests erfüllen den Zweck einer lebenden Dokumentation. In Kombination mit einer sinnvollen Benamung der Objekte (Clean Code) können zusätzliche Dokumentationsmaßnahmen entfallen.
• Da einzelne Module nur wenige mögliche Codeausführungspfade besitzen, muss man viel weniger mögliche kombinatorische Ausführungspfade berücksichtigen als bei anderen Testarten. Bei übergeordneten Tests kann man sich dann stichprobenartig auf die wichtigsten Ausführungspfade konzentrieren und damit die Anzahl dieser Tests deutlich reduzieren.
• Da man nur einzelne Module testet, kann man Modultests, oft um mehrere Größenordnungen, schneller und damit öfter (bzw. kontinuierlich) ausführen als andere Testarten.
• Wenn man Fehler mit einem Test absichert, kann man den erneuten Auftritt des gleichen Fehlers verhindern.
• Durch die Fehlerreduktion ergeben sich Geschwindigkeitsvorteile in der Entwicklung in mittleren bis großen Softwareprojekten.
• Da man Abhängigkeiten zwingend vermeiden muss, um einen Modultest zu ermöglichen, bleibt der Code verhältnismäßig schnell änderbar. Hierdurch kann man schneller auf wechselnde Anforderungen reagieren. Siehe Agile Manifest 😉
• Da automatisch ausgeführte Tests um mehrere Größenordnungen schneller sind als manuelle Tests, reduziert sich der Zeitaufwand für das Testen deutlich. Hierdurch kann man die Entwicklungsstufen schneller durchlaufen und die Release-Zyklen signifikant verkürzen.

Was sind die Nachteile von Unit Tests?

• Bei der Implementierung neuer Funktionen muss man nicht nur die Funktion implementieren, sondern auch die dazugehörenden Tests vorbereiten bzw. definieren. Dadurch ergibt sich ein oft mehrfacher Implementierungsaufwand.
• Bei Änderungen muss man nicht nur die geänderten Funktionen, sondern auch die dazugehörenden Tests anpassen. Insbesondere bei der Entwicklung von Prototypen, bei der sich die Codebasis schnell verändert, ist das Testen daher oft eher ein Hindernis.
• Da man die Funktionalität der Tests verwendet, ist in den IDEs schwerer ersichtlich, ob eine Funktionalität keine Verwendung mehr findet und ob man es daher entfernen kann.
• Weisen die Tests untereinander Abhängigkeiten auf (z. B. durch gemeinsame Testdaten), so können einzelne Änderungen an der Codebasis eine Vielzahl von Tests beeinflussen, was den Änderungsaufwand mit der Größe der Codebasis exponentiell erhöht.

Fehlerkosten 10er Regel (Rule of ten)

Die Zehnerregel der Fehlerkosten besagt, dass je weiter ein Fehler sich unentdeckt in die späten Phasen des Werdegangs eines Produktes oder Prozesses bewegt – oder gar bis zum Kunden –, desto höher steigen die Kosten zur Behebung des Fehlers. Eindrucksvoll untermauert durch die Ergebnisse einiger Studien aus den 70er Jahren in Japan, USA und Großbritannien, die sich mit den Ursachen von Produkt- bzw. Qualitätsmängeln beschäftigten. Alle Analysen lieferten nahezu die gleichen Ergebnisse: Ca. 70 % aller Produktmängel hatten ihre Ursache bereits in der Entwicklung, Konstruktion und Arbeitsvorbereitung. Der Herstellungsprozess selbst hat bezüglich der Endqualität des Produktes offensichtlich eher einen sekundären Einfluss. Eine VDMA-Studie zum Thema „Qualitätsbezogene Kosten“ Anfang der 90er Jahre in der Bundesrepublik Deutschland bestätigt dieses Ergebnis.

Die Zehnerregel der Fehlerkosten oder „Rule of ten“ sagt aus, dass sich die Fehlerkosten für einen nicht entdeckten Fehler von Stufe zu Stufe der Wertschöpfung um den Faktor 10 erhöhen. Je früher ein Fehler entdeckt und beseitigt wird, desto kostengünstiger ist dies für die Organisation und schlussendlich auch für den User bzw. Kunden.

Ansonsten sind diese auch in der DIN 55350-11 im Rahmen des Qualitätsmanagements festgehalten. Doch darauf gehe ich in einem separaten Beitrag ein.

Wo sind die Grenzen der Unit Tests?

Unit Tests können (wie jeder Test) die Fehlerfreiheit der getesteten Units, Module usw. nicht garantieren oder nachweisen, sondern lediglich unterstützen. Die Grenzen von Unit Tests liegen primär nur in den Fällen vor in denen man Fehler finden kann, zu deren Entdeckung die verwendeten Tests geeignet sind. Eine Softwarekomponente, die „grün“ testet, ist also nur bedingt fehlerfrei.

Das Merkmal von Code, „grün“ zu testen, und durchaus auch der Wunsch nach diesem Ergebnis, kann dazu führen, dass man tatsächlich (unbewusst) nur so viel testet, bis alle Tests „grün“ sind. Module, die keine fehlschlagenden Modultests haben, als fehlerfrei zu behandeln, ist ein Fehlschluss in der Praxis des (TDD) Test Driven Development.

Um eine ausreichende Testabdeckung zu erzielen, lohnt es sich u.U., vor dem Erstellen der Testfälle Refactoring-Maßnahmen anzuwenden. Dies erst nach abgeschlossenen Unit Tests (für den alten Code) zu tun, schafft Raum (wie jede Änderung im Code) für neue Fehlerrisiken und kann deshalb wiederholtes Testen erforderlich machen.

Wenn der Autor von Unit Tests mit dem Autor der Module identisch ist, können Denkfehler in der Implementierung auch im Test erscheinen und verpasst gegebenenfalls die Chance, diese aufzudecken. Wenn es sich um dieselbe Person handelt, kann man die vorrangige Entwicklung der Tests ebenfalls nicht garantieren, da sowohl die beabsichtigte Funktionsweise des Codes als auch die zukünftige Gestalt bereits im Gedankengut des Testautors und späteren Codeautors präsent sein können. Dies kann im Extreme Programming durch „Test Ping-Pong“ abgefangen werden, bei der sich Entwickler bei der Implementierung der Funktionalität und der Tests abwechseln.

Bei der Entwicklung von Modultests können Testfälle entstehen, die der Zielsetzung und dem Charakter von Modultests nicht oder nur zum Teil entsprechen. Wie bei der Programmierung existieren daher auch für die Entwicklung von Modultests Anti-Pattern, die man möglichst vermeiden sollte.

Der Beitrag Unit Tests – Fundament für stabile und effiziente Software erschien zuerst auf CEOsBay.

Eine wirklich kurze Zeitreise

Die Extensible Markup Language wurde vom World Wide Web Consortium (W3C) am 10. Februar 1998 veröffentlicht. Die aktuelle Fassung ist die fünfte Ausgabe vom 26. November 2008. Alle bisherigen und aktuellen Publikationen kann man hier einsehen.

Was ist XML nun wirklich und was tut es?

Es ist eine Metasprache, auf deren Basis durch strukturelle und inhaltliche Einschränkungen anwendungsspezifische Sprachen definiert werden. Diese Einschränkungen werden entweder durch eine Document Type Definition (DTD) oder durch ein XML Schema ausgedrückt. Beispiele für XML-Sprachen sind: RSS, MathML, GraphML, XHTML, XAML, Scalable Vector Graphics (SVG), GPX, aber auch das XML-Schema selbst. Auf diese Sprachen gehe ich in zukünftigen Sprachen ein. Besonders SVG hat einen Großteil meiner persönlichen Entwicklung geprägt.

Die Standardzeichenkodierung eines XML-Dokumentes ist UTF-8. XML-bearbeitende Systeme müssen die Kodierungen UTF-8 und UTF-16 beherrschen. XML-Dokumente, die UTF-8 oder UTF-16 verwenden, können in allen Texteditoren, die diese Kodierungen unterstützen, angezeigt und bearbeitet werden. Damit sind so ziemlich alle „Browser“ gemeint 😉

Wenn das XML-Dokument Binärdaten enthalten soll, müssen diese Daten zu Text konvertiert bzw. umkodiert werden. Dazu kann z. B. die Base64-Kodierung verwendet werden.

Das Element

Die essenzielle Struktureinheit eines XML-Dokumentes ist das Element. Elemente können Text wie auch weitere Elemente als Inhalt enthalten. Elemente bilden die Knoten des Strukturbaumes eines XML-Dokumentes. Der Name eines Elementes kann in Dokumenten ohne Dokumenttypdefinition (DTD) frei gewählt werden. In XML-Dokumenten mit DTD muss der Name eines Elementes in der DTD deklariert sein und das Element muss sich in einer zugelassenen Position innerhalb des Strukturbaumes gemäß DTD befinden. In der DTD wird u. a. der mögliche Inhalt eines jeden Elementes definiert. Elemente sind die Träger der Information in einem XML-Dokument.

Tag

Für die Auszeichnung von Elementen werden Tags verwendet. Auf den ersten Blick sehen XML-Tags fast wie HTML-Tags aus. Start-Tags beginnen mit < und End-Tags mit </. Bei beiden folgt anschließend der Name des Elements, und sie werden beide durch > geschlossen. Anders als bei den HTML-Tags können Sie jedoch neue Tags erzeugen. Um eine Person zu beschreiben, benutzt man die Tags <person> und </person>. Um ein Tier zu beschreiben, verwendet man die Tags <tier> und </tier>. Die Namen der Tags spiegeln im Allgemeinen die Art des Inhalts innerhalb des Elements wider und nicht die Art und Weise, wie der Inhalt formatiert wird.

Wohlgeformtheit

Ein XML-Dokument ist „wohlgeformt“ (well-formed), wenn es alle Regeln einhält.

Die Regeln

• Das Dokument besitzt genau ein Wurzelelement. Als Wurzelelement wird dabei das jeweils äußerste Element bezeichnet, z. B. <html> in XHTML.
• Alle Elemente mit Inhalt besitzen einen Start- und einen Endtag (z. B. <eintrag>Eintrag 1</eintrag>). Elemente ohne Inhalt können mit einem Leertag gekennzeichnet werden (z. B. <eintrag />).
• Die Start- und Endtags sind ebenentreu-paarig verschachtelt. Dies bedeutet, dass alle Elemente geschlossen sind, bevor die End-Auszeichner des entsprechenden Elternelements oder die Beginn-Auszeichner eines Geschwisterelements erscheinen.
• Ein Element darf nicht mehrere Attribute mit demselben Namen besitzen.
• Attributwerte müssen in Anführungszeichen stehen („…“ oder ‚…‘).
• Die Start- und Endtags sind Case sensitive, also beachten die Groß- und Kleinschreibung (z. B. <eintrag></Eintrag> ist ungültig).

Gültigkeit (Validität)

Verwendet man es für den Datenaustausch, ist es von Vorteil, wenn das Format mittels einer Grammatik (z. B. einer Dokumenttypdefinition oder eines XML-Schemas) definiert ist. Der Standard definiert ein XML-Dokument als gültig (oder englisch valid), wenn es wohlgeformt ist, den Verweis auf eine Grammatik enthält und das durch die Grammatik beschriebene Format einhält.

Parser

Programme oder Programmteile, die XML-Daten auslesen, interpretieren und ggf. auf Gültigkeit prüfen, nennt man XML-Parser. Prüft der Parser die Gültigkeit, so ist er ein validierender Parser. Darauf gehe ich aber in einem zukünftigen Beitrag genauer ein.

Wie sieht die Extensible Markup Language eigentlich aus?

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<verzeichnis>
    <titel>Städteverzeichnis</titel>
    <eintrag>
        <stichwort>München</stichwort>
        <eintragstext>München ist der Sitz von ...</eintragstext>
    </eintrag>
    <eintrag>
        <stichwort>Donauwörth</stichwort>
        <eintragstext>Donauwörth ist eine Stadt, die ...</eintragstext>
    </eintrag>
</verzeichnis>

XML-Dokumente besitzen einen physischen und einen logischen Aufbau.

Der physische Aufbau

• Die Dokument-Entität (Document entity) enthält das Hauptdokument.
• Weitere mögliche Entitäten sind über Entitätenreferenzen (&name; für das Dokument bzw. %name; für die Dokumenttypdefinition) eingebundene Zeichenketten, eventuell auch ganze Dateien, sowie Referenzen auf Zeichenentitäten zur Einbindung einzelner Zeichen, die über ihre Nummer referenziert wurden (&#Dezimalzahl; oder &#xHexadezimalzahl;).
• Eine XML-Deklaration wird verwendet, um die Version, Zeichenkodierung und eine mögliche Verarbeitbarkeit ohne DTD zu spezifizieren.
• Eine DTD wird verwendet, um Entitäten sowie den erlaubten logischen Aufbau zu spezifizieren. Die Verwendung einer DTD kann in der Deklaration abgewählt werden.

Der logische Aufbau

Der logische Aufbau entspricht einer Baumstruktur und ist damit hierarchisch organisiert. Es gibt folgende Baumknoten:

• Elemente, deren physische Auszeichnung mittels eines passenden Paars aus Starttag <Tagname> und End-Tag </Tagname> oder eines Leertags <Tagname/> erfolgen kann.
• Attribute als bei einem Starttag oder Leertag geschriebene zusätzliche Eigenschaften der Elemente in der Syntax Attributname=Attributwert.
• Verarbeitungsanweisungen <?Zielname Daten?> (engl. Processing Instructions).
• Kommentare <!– Kommentar-Text –>.
• Text, der als normale Zeichendaten oder in Form eines CDATA-Abschnittes <![CDATA[ beliebiger Text]]> auftreten kann.

Ein XML-Dokument muss genau ein Element auf der obersten Ebene enthalten. Unterhalb dieses Dokumentelements können weitere Elemente und Texte verschachtelt werden.

Was ist DTD

Wie vorher kurz ausgeschrieben und angeschnitten, handelt es sich dabei um die Dokumenttypdefinition und beschreibt die Struktur sowie Grammatik von Dokumenten. Sie ist Systembestandteil von XML und per Standard aktiviert.

Werden Dokumente mit Bezug zu einer externen Dokumenttypdefinition oder mit einer integrierten Dokumenttypdefinition erstellt, prüft der Parser das Dokument bereits beim Öffnen (Lesen). Ein Dokument auf Basis einer Dokumenttypdefinition ist stets ein valides Dokument. Die Übereinstimmung des Dokumentinhaltes mit den Regeln der Dokumenttypdefinition steht im Vordergrund. Die technische Lesbarkeit, also auch das Lesen von nicht validen Dokumenten ist nachrangig. Das ist für Volltextdokumente (erzählende Dokumente, engl. narrative documents) vorgesehen und der Haupteinsatzzweck.

Dokumente ohne DTD sind eher für den beliebigen Datenaustausch geeignet. Der Parser prüft diese Dokumente nur nach den Regeln der Wohlgeformtheit. Die technische Lesbarkeit steht hier an erster Stelle. Das Prüfen und Auslesen der eigentlichen Informationen wird mit nachgelagerten Prozessen realisiert.

Lesbarkeit

Wie zu Beginn erwähnt, können alle Webbrowser wie Apple Safari, Google Chrome, Microsoft Edge, Mozilla Firefox, Opera usw. XML-Dokumente mit Hilfe des eingebauten Parsers direkt visualisieren. Dadurch werden keine zusätzlichen PlugIns oder der Gleichen benötigt.

Klassifizierung von XML-Dokumenten

XML-Dokumente lassen sich anhand ihrer Bestimmung und ihres Strukturierungsgrades in dokumentzentrierte und datenzentrierte Dokumente unterteilen. Die Grenze zwischen diesen Dokumentenarten ist fließend. Mischformen können als semistrukturiert bezeichnet werden.

Dokumentzentriert

Das Dokument ist an ein Textdokument angelehnt, dass für den menschlichen Leser größtenteils auch ohne die zusätzliche Metainformation verständlich ist. XML-Elemente werden hauptsächlich zur semantischen Markierung von Passagen des Dokuments genutzt. 

Das Dokument ist nur schwach strukturiert. Aufgrund der schwachen Strukturierung ist eine maschinelle Verarbeitung schwierig.

Datenzentriert

Das Dokument ist hauptsächlich für die maschinelle Verarbeitung bestimmt. Es folgt einem Schema, das Entitäten eines Datenmodells beschreibt und definiert, in welcher Beziehung die Entitäten zueinanderstehen und welche Attribute die Entitäten haben. Das Dokument ist somit stark strukturiert und für den unmittelbaren menschlichen Gebrauch weniger geeignet.

Semistrukturiert

Semistrukturierte Dokumente stellen eine Art Mischform dar, die stärker strukturiert ist als dokumentzentrierte Dokumente, aber schwächer als datenzentrierte Dokumente.

Es ist typisch für datenzentrierte XML-Dokumente, dass Elemente entweder Elementinhalte oder Textinhalte haben. Der sogenannte gemischte Inhalt (Mixed Content), bei dem Elemente sowohl Text als auch Childs (Kind-Elemente) enthalten, ist für die anderen XML-Dokumente typisch.

Verarbeitungskriterien der Extensible Markup Language

Grundsätzlich sind drei Aspekte beim Zugriff auf ein XML-Dokument von Bedeutung:

1. Wie erfolgt der Zugriff auf die XML-Datei: sequenziell oder wahlfrei?
2. Wie ist der Ablauf beim Zugriff auf die Daten gestaltet: „Push“ oder „Pull“? (Push bedeutet, dass die Ablaufkontrolle des Programms beim Parser liegt. Pull bedeutet, dass die Ablaufkontrolle im Code, der den Parser aufruft, implementiert ist.)
3. Wie erfolgt das Baumstrukturmanagement der XML-Daten: hierarchisch oder verschachtelt?

Programmgesteuerter Zugriff auf XML-Dokumente

Das Einlesen von XML-Dokumenten erfolgt auf unterster Ebene über eine spezielle Programmkomponente, einem XML-Prozessor, auch XML-Parser genannt. Er stellt eine Programmierschnittstelle (API) zur Verfügung, über die die Anwendung auf das XML-Dokument zugreift. Ich habe zwar in einem vorherigen Beitrag über die REST API geschrieben, doch werde ich definitiv die Programmierschnittstelle explizit nochmals ein einem Beitrag thematisieren.

Die XML-Prozessoren unterstützen dabei drei grundlegende Verarbeitungsmodelle

1. DOM: Ein DOM-API repräsentiert ein XML-Dokument als Baumstruktur und gewährt wahlfreien Zugriff auf die einzelnen Bestandteile der Baumstruktur. DOM erlaubt außer dem Lesen von den Dokumenten auch die Manipulation der Baumstruktur und das Zurückschreiben der Baumstruktur in ein XML-Dokument. Aus diesem Grund ist DOM sehr speicherintensiv.
2. SAX: Ein SAX-API repräsentiert ein XML-Dokument als sequentiellen Datenstrom und ruft für im Standard definierte Ereignisse vorgegebene Rückruffunktionen (callback function) auf. Eine Anwendung, die SAX nutzt, kann eigene Unterprogramme als Rückruffunktionen registrieren und auf diese Weise die Daten auswerten.
3. Pull-API: Eine XML-Pull-API verarbeitet Daten sequenziell und bietet sowohl ereignisbasierte Verarbeitung als auch einen Iterator an. Es ist hoch speichereffizient und ggf. leichter zu programmieren als das SAX-API, da die Ablaufkontrolle beim Programm und nicht beim Parser liegt.

Weitere Verarbeitungsmodelle sind das Data-Binding, welches die XML-Daten als Datenstruktur direkt für einen Programmzugriff bereitstellt. Die XML-Daten werden per Unmarshalling (Dies ist der Prozess der Umwandlung einer Art von Darstellung auf niedrigerer Ebene, oft ein „Drahtformat“, in eine Struktur auf höherer Ebene (Objekt).) direkt in z. B. Objekte gewandelt. Und die Nicht-extrahierende-XML-API, bei der die Daten auf Byte-Ebene sehr effizient verarbeitet sind.

Oftmals greift der Anwendungscode nicht direkt auf die Parser-API zu. Stattdessen wird es weiter gekapselt, so dass der Anwendungscode mit nativen Objekten / Datenstrukturen arbeitet, welche sich auf darauf abstützen. Beispiele für solche Zugriffsschichten sind JAXB in Java, der Data Binding Wizard in Delphi oder das XML Schema Definition Toolkit in .Net. Die Umwandlung von Objekten in die Extensible Markup Language ist üblicherweise bidirektional möglich. Diese Umwandlung bezeichnet man als Serialisierung oder Marshalling.

Transformation und Darstellung von XML-Dokumenten

Ein XML-Dokument kann mittels geeigneter Transformationssprachen wie XSLT oder DSSSL in ein anderes Dokument transformiert werden. Oftmals dient die Transformation zur Überführung eines Dokuments aus einer Extensible Markup Language in eine andere Extensible Markup Language, beispielsweise zur Transformation nach XHTML, um das Dokument in einem Webbrowser anzuzeigen.

Warum XML?

Unterstützung von und bei Transaktionen

Wenn ein Unternehmen eine Ware oder Dienstleistung an ein anderes Unternehmen verkauft, müssen die beiden Unternehmen Informationen wie Kosten, Spezifikationen und Lieferpläne austauschen. Man kann damit alle erforderlichen Informationen elektronisch teilen und komplexe Geschäfte automatisch abschließen, ohne dass ein menschliches Eingreifen erforderlich ist.

Aufrechterhaltung der Datenintegrität

Man kann damit Daten zusammen mit der Beschreibung der Daten übertragen und so den Verlust der Datenintegrität verhindern. Folglich kann man so die Datengenauigkeit überprüfen, automatische Anpassungen der Datenpräsentation für verschiedene Benutzer vornehmen und Daten konsistent über mehrere Plattformen hinweg speichern 

Sucheffizienz verbessern

Computerprogramme wie Suchmaschinen können die Dateien damit effizienter und präziser sortieren und kategorisieren als andere Arten von Dokumenten. Beispielsweise kann das Wort mark (markieren) entweder ein Substantiv oder ein Verb sein. Basierend auf XML-Tags können Suchmaschinen mark für relevante Suchergebnisse genau kategorisieren. Somit hilft es, die natürliche Sprache für Maschinen effizienter interpretierbar zu machen.

Flexible Anwendungen entwerfen

Man kann damit auch das eigene Anwendungsdesign bequem aktualisieren oder ändern. Viele Technologien, insbesondere neuere Technologien, verfügen dafür über eine integrierte Schnittstelle bzw. Unterstützung. So kann man automatisch Datendateien lesen und verarbeiten, sodass die Änderungen stattfinden können, ohne gleich die gesamte Datenbank neu formatieren zu müssen.

Der Beitrag XML – Effiziente Datenstrukturierung erschien zuerst auf CEOsBay.