Download (5Mb) - oops/ - Oldenburger Online-Publikations-Server

92 Umsetzung des Prototyps
der Erstellung solcher Spezifikationen miteinbezogen werden. Aus Sicht des Softwareentwicklers
werden im Fall von BDD einzelne Beispiele des erwarteten Verhaltens des Quelltextes erstellt,
die auch als Akzeptanz-Tests oder Integrationstests (engl. acceptance und integration test)
bekannt sind. Ein Unterschied zwischen TDD (Test-Driven Development, testgetriebene Softwareentwicklung)
zu BDD ist, dass bei TDD normalerweise die Struktur, Organisation und Robustheit
der Softwarelösung getestet werden, während eine TDD-Spezifikation die Softwarelösung als eine
Black-Box betrachtet und nur die Erfüllung einer gewissen Funktionalität (oder eines Verhaltens)
erwartet.
• Verwendung von open-source Bibliotheken und Projekte: Alle bei der Umsetzung des Softwareproduktes
eingesetzten Technologien bzw. Produkte sind im Internet frei verfügbar und für
präzisere Zwecke anpassbar. Dieses Kriterium stellte sich als Hauptmerkmal für die Auswahl der
Werkzeuge dar, die im Laufe der Entwicklung verwendet worden sind. Die Möglichkeit einer
Anpassung war essentiell im Fall von einigen Werkzeugen, die beispielsweise hinsichtlich ihrer
Fehlerausgabe oder allgemeinen Funktionsweise anhand des frei verfügbaren Quelltextes untersucht
worden sind. Hiermit ist auch die Gelegenheit verbunden, einige kleinere, für diese Arbeit
benutzten Software-Teile als open-source “Produkte” veröffentlichen zu können.
Nachdem in einer zusammengefassten Weise die einzelnen bei dem Entwicklungsvorgang beachteten
Merkmale zur Sicherung einer erhöhten Quelltextqualität beschrieben worden sind, wird
der Fokus auf die tatsächliche Umsetzung der Bestandteile der Softwarelösung gelegt. Zu diesem
Zweck wird zuerst die für die Umsetzung des “Home Sharing” Szenarios entwickelte Ausprägung
des Kontext-Modells (hier als “Datenmodell” gekennzeichnet) vorgestellt.
7.2 Datenmodell für Home Sharing
Während in Kapitel 6 die Definition eines allgemein anwendbaren Kontext-Modells gegeben wurde,
muss eine weitere Definition einer konkreten Ausprägung bzw. Umsetzung dieses Modells eingebracht
werden. In dieser Arbeit wurde zugleich ein Datenmodell erstellt, welches die in Kapitel 3
beschriebenen User-Stories unterstützt. Eine visuelle Darstellung dieses Modells erfolgt anhand der
Abbildung 7.1.
Neben den genannten, in Kürze zu erläuternden Bestandteilen des Datenmodells befinden sich in
dem dargestellten Modell außer den impliziten (s.u.) Verknüpfungspunkten mit dem verallgemeinerten
Kontext-Modell auch tatsächliche Verknüpfungen: die Klassen Location und Source. Die
Einbeziehung der Location Klasse liegt im Bedarf begründet, Kontext-Informationen zu erzeugen
und zu bearbeiten, die auch in der Wohnung verortet sind. Weiterhin wurde die Klasse Source in
diesem Modell verknüpft, um den Unterschied zwischen vordefinierten, statischen, vom System anfänglich
bereitgestellten Daten (siehe auch 7.3.1) und dynamischen, “auftretenden” Datensätze ausdrücken
zu können.
Die genannte Art von “impliziten” Verknüpfungspunkten mit dem grundlegenden Kontext-Modell
bezieht sich darauf, dass versucht wurde, die Komplexität der entwickelten Softwarelösung zu verringern.
Unter diesem Gesichtspunkt handelt es sich um implizites Wissen, das im Datenmodell enthalten
ist. Die räumlichen Daten werden nicht durch einzelne Fakten wie im Paragraph 6.3 im Fall
der beispielhaften Instanziierung dargestellt, sondern sie werden durch eine Assoziation zwischen
den teilnehmenden Klassen (bzw. Relationen aus Sicht des Datenbankmodells) ausgeprägt. Außer-