Modellierung und Teilimplementierung eines Drag & Drop Diagrammerzeugungstools im Kontext von Ad-hoc Analysesystemen

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Quellcodeverzeichnis

Abkürzungsverzeichnis

1. Einleitung
1.1 Motivation
1.2 Ziel und Ergebnisse
1.3 Einordnung und Kontext
1.4 Vorgehensweise
1.5 Konventionen

2. Grundlagen
2.1 Wirtschaftsinformatische Grundlagen
2.1.1 Business Intelligence
2.1.2 Teilbereiche der Business Intelligence und Einordnung dieser Arbeit
2.1.3 Ad-hoc Analysesysteme
2.2 Grundlagen der Datenvisualisierung
2.2.1 Allgemeine Grundlagen
2.2.2 Tabellarische Visualisierung
2.2.3 Diagrammatische Visualisierung
2.3 Technische Grundlagen
2.3.1 Flex
2.3.2 ActionScript
2.3.3 JavaScript
2.3.4 Model, View, Controller Konzept
2.4 Sonstige Grundlagen
2.4.1 RIA (Rich Internet Application)
2.4.2 Drag and Drop

3. Analyse
3.1 Marketoolz Firmenprofil
3.2 Ist-Analyse
3.2.1 Diagrammerzeugung von Marketoolz Allgemein
3.2.2 Anwendungsbeispiel
3.3 Schwachstellenanalyse
3.4 Anforderungsprofil
3.5 Ist-Analyse vorhandener Business Intelligence Anwendungen
3.5.1 Definition der Analysekriterien
3.5.2 Auswahl der betrachteten Business Intelligence Anwendungen
3.5.3 SAS – JMP
3.5.4 Business Objects - Crystal Reports
3.5.5 Pentaho
3.5.6 Zusammenfassung der Ist-Analyse
3.6 Anforderungskatalog
3.7 Aktivitätsdiagramme

4. Entwurf
4.1 Vorüberlegungen
4.2 Architekturentwurf
4.2.1 Allgemeine Architektur
4.2.2 Events & Cairngorm
4.3 Klassendiagramm
4.4 Sequenzdiagramm
4.5 Hierarchische Multiple Achsenbeschriftung
4.6 Datenbeschaffung
4.7 Grafische Benutzeroberfläche
4.7.1 View-Verschachtelung & Menü
4.7.2 Weitere Ansichten

5. Umsetzung
5.1 Restriktionen
5.2 Werkzeuge
5.3 Integration des Chartbuilders
5.4 Datenbeschaffung
5.4.1 Datenidentifikation
5.4.2 Konfiguration
5.4.3 Aufruf einer Destination
5.4.4 Datenempfang
5.5 Datenverarbeitung
5.6 Aufruf eines Events
5.7 Achsenbeschriftung
5.8 Views
5.8.1 Laden einer View
5.8.2 Aktualisieren einer View
5.9 Probleme

6. Schlussbetrachtung
6.1 Zusammenfassung
6.2 Erreichte Ziele
6.3 Ausbaumöglichkeiten

7. Glossar

Literaturverzeichnis.

Abbildungsverzeichnis

Abbildung 1: Nutzenzuwächse durch MIS-Einsatz

Abbildung 2: Business Intelligence Ordnungsrahmen

Abbildung 3: Analysesysteme für das Management

Abbildung 4: Bedeutung der Ad-hoc Analyse

Abbildung 5: Schema einer Tabelle

Abbildung 6: Kreuztabellenstruktur

Abbildung 7: Flash Player Verbreitung

Abbildung 8: Diagramm für Anwendungsbeispiel

Abbildung 9: Marktanteile Business Intelligence Anbieter

Abbildung 10: JMP8 - Graph Builder

Abbildung 11: JMP8 – Diagrammerstellung

Abbildung 12: Crystal Reports Diagramm-Assistent

Abbildung 13: Pentaho Benutzeroberfläche der OLAP Analyse

Abbildung 14: Aktivitätsdiagramm Diagrammmodifikation

Abbildung 15: Diagramm Neuerstellung

Abbildung 16: Ablauf einer Benutzerinteraktion

Abbildung 17: Klassendiagramm

Abbildung 18: Sequenzdiagramm – Gruppierung hinzufügen

Abbildung 19: Achsenreihenfolge

Abbildung 20: Achsenreihenfolge II

Abbildung 21: Verschachtelte Views

Abbildung 22: Menüverschachtelung

Abbildung 23: Diagrammdarstellung

Abbildung 24: Fullscreen-Bearbeitungsmodus

Abbildung 25: Tooltip

Abbildung 26: Async Call und Response

Abbildung 27: Mehrfache Achsenbeschriftung für ein Säulendiagramm

Tabellenverzeichnis

Tabelle 1: Beispieldaten für Diagrammdefinitionen (Ausgaben in Mio. €)

Tabelle 2: Beispieltabelle für Anwendungsbeispiel

Tabelle 3: Vergleichstabelle Implementierungsgrad

Quellcodeverzeichnis

Quellcode 1: MXML und AS3 Vergleich

Quellcode 2: SWF Einbindung

Quellcode 3: Größe des embedded SWF

Quellcode 4: Flex Aufruf von JavaScript für TID

Quellcode 5: Channel-Definition in der services-config.xml

Quellcode 6: Service-Definition in der services-config.xml

Quellcode 7: Verfügbare RemoteObjects

Quellcode 8: Aufruf einer Java Methode per RemoteObject

Quellcode 9: Responder Weiterleitung

Quellcode 10: Erzeugung einer Serie für ein Balkendiagramm

Quellcode 11: Erzeugen und Dispatchen eines Events

Quellcode 12: Event-Identifikation

Quellcode 13: Labelposition – Rechnung

Quellcode 14: Beispiel Databinding

Quellcode 15: Databinding im ViewStack

Quellcode 16: ItemRenderer Zuweisung

Quellcode 17: MTSelectItemRenderer

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1.Einleitung

1.1Motivation

Das Wirtschaftsleben der heutigen Zeit ist für alle Marktteilnehmer durch hohe Komplexität und rasche Veränderungen interner und externer Rahmenbedingungen gekennzeichnet. Die daraus resultierenden Anforderungen an den Produktionsfaktor Information sind hierdurch in den letzten Jahren rapide gestiegen.^[1]

Es ist für ein Unternehmen heutzutage von zentraler Bedeutung, dass durch die anforderungsgerechte Verarbeitung, Präsentation und Analyse von Informationen Wettbewerbsvorteile gegenüber Konkurrenten erworben werden können. In Zeiten des zunehmenden Wettbewerbsdrucks und einem komplexen, schnellen Wettbewerbsumfeld ist es wichtig, der Konkurrenz einen Schritt voraus zu sein. Um die Entwicklung einer erfolgreichen Unternehmensstrategie vorausschauend zu planen und um letztendlich einen messbaren Wettbewerbsvorteil zu gewinnen ist die strategische Wettbewerbsanalyse unerlässlich.^[2]

Wichtiges Element bei der datengestützten Erkenntnisgewinnung ist die zielorientierte Visualisierung der der Analyse zugrundeliegenden Daten. Unabhängig von Art und Herkunft gilt es, diese nach den Vorstellungen des Benutzers schnell und prägnant darzustellen. Mit der Visualisierung durch Diagramme lassen sich Daten, Strukturen und Zusammenhänge graphisch darstellen. Es kann eine effizientere Analyse und Kommunikation, sowie ein verbessertes Verständnis der zu Grunde liegenden Prozesse erreicht werden. Das Aufzeigen und Erkennen von Zusammenhängen mündet somit auf lange Sicht in einer Einsparung von Kosten.

Durch das sich rasch wandelnde Informationsbedürfnis betrieblicher Entscheidungsträger rückt die Entwicklung des Business Intelligence Bereiches der Ad-hoc Analysesystemen stark in den Vordergrund. „Leistungsstarke und grafisch-orientierte Abfragetools, die bis auf die operativen Datenbasen zugreifen können, versprechen … besonders leichten Zugriff auf relevante Informationen.“^[3] Im Gegensatz zu Standardauswertungen, die Ergebnisse in einer vordefinierten Form liefern, liefern Ad-hoc Werkzeuge dynamisch erzeugte Auswertungen und Grafiken entsprechend den Benutzeranforderungen. Der Anwender bewegt sich hierbei frei im Datenbestand und kann mit wenigen Mausklicks beliebige Ausschnitte und Zusammenstellungen der Inhalte zur Anzeige bringen.^[4]

1.2Ziel und Ergebnisse

Ziel dieser Arbeit ist es, die diagrammatische Datenvisualisierung von Ad-hoc Analysesystemen der Business Intelligence zu erleichtern. Es soll dem Anwender ermöglicht werden, den Fokus der Visualisierung ausschließlich auf die Diagrammerstellung zu richten. Außerdem soll der Anwender, mit Hilfe von Drag and Drop, zielgerichtet, schnell und intuitiv arbeiten können.

Im Zuge dieser Arbeit wird eine Modellierung und Teilimplementierung eines Datenvisualisierungstools vorgenommen. Die Modellierung umfasst hierbei die Definition der funktionalen Anforderungen, sowie den Entwurf (s. Kap. 4) der Anwendung. Die Anforderungen ergeben sich aus den Schwachstellen der aktuellen Diagrammerzeugung der Firma Marketoolz und aus einer Analyse am Markt vorhandener Business Intelligence Anbieter.

Das Modell und die Anforderung einer bei Marketoolz einsatzfähigen Umsetzung bilden die Grundlage für die angestrebte Teilimplementierung, also die technische Umsetzung des erarbeiteten Modells. Das in der Umsetzung entworfenen Datenvisualisierungstool wird im weiteren Verlauf dieser Arbeit als Chartbuilder bezeichnet. Die angestrebte Teilimplementierung ist als Pilotsystem zu verstehen, aus dem nach und nach der endgültige Chartbuilder hervorgehen soll.

Die Teilimplementierung wird unter http://mm.marketoolz.com/ mit den entsprechenden Benutzerrechten zur Verfügung stehen. Die von Marketoolz designierte Programmiersprache zur Implementierung des Chartbuilders ist Flex 3.

1.3Einordnung und Kontext

Diese Arbeit ist im Bereich der Wirtschaftsinformatik der Business Intelligence zuzuordnen. Eine detaillierte Einordnung des Themas innerhalb der Business Intelligence wird in Kapitel 2.1.2 vorgenommen. Im Bereich der Informatik lässt sich diese Arbeit dem Bereich der RIAs, der Rich Internet Applications zuordnen.

Der Impuls für diese Arbeit entstand im Zuge eines Praktikums bei der Firma Marketoolz, welche im Bereich der Business Intelligence bzw. der Management Informations Systeme tätig ist. Eine nähere Beschreibung der Firma wird in Kapitel 3.1 gegeben. In diesem Kontext wird auch der Einsatz einer lauffähigen Teilimplementierung stattfinden.

1.4Vorgehensweise

Diese Arbeit ist unterteilt in einen theoretischen Teil, Kapitel 2 bis 4, und einen praktischen Teil in Kapitel 5. Im 2. Kapitel werden zunächst die zum Verständnis dieser Arbeit notwendigen fachlichen und theoretischen Grundlagen beschrieben. In Kapitel 3 folgt daraufhin eine Ist-Analyse der bisherigen Diagrammerzeugung bei Marketoolz anhand eines Anwendungsbeispiels. Anschließend werden eine Schwachstellenanalyse und ein aus den Schwachstellen resultierendes Anforderungsprofil erstellt. Dieses Anforderungsprofil dient als Grundlage für die dann folgende Analyse vorhandener Business Intelligence Anwendungen mit Fokus auf die Diagrammerzeugung. Danach wird in Kapitel 3.6 ein Anforderungskatalog entworfen. In Kapitel 4 wird aus dem zuvor entworfenen Anforderungskatalog das Anwendungssystem entwickelt, welches in Kapitel 5 praktisch umgesetzt wird. Abschließend folgt in Kapitel 6 eine Schlussbetrachtung, in der die vorliegende Arbeit zusammengefasst und ein Ausblick auf Weiterentwicklungs- und Verbesserungsmöglichkeiten gegeben wird.

1.5Konventionen

Da sich diese Arbeit auf eine Teilimplementierung des Chartbuilders beschränkt, wird ein Testing nur insofern vorgenommen, als dass alle bisherigen Diagramme von Marketoolz mit dem Chartbuilder darstellbar und modifizierbar sein sollten. Auch eine Fehlerbehandlung der Anwendung wird nur eingeschränkt durchgeführt.

Quellcode wird innerhalb dieser Arbeit mit einer grauen Einrahmung hervorgehoben. Die Syntaxhervorhebung des Quellcodes entspricht der des Flex Builders 3.

Für die Teilimplementierung des Diagrammerzeugungstools wird das Flex SDK 3.1, der BlazeDS Server in der Version 3-0-0-544 und Cairngorm Version 2.2.1 verwendet. Für die Modellierung der Software wird UML in der Version 2.0 verwendet.

Aus Gründen der Geheimhaltung sind die Achsenwerte innerhalb von Abbildungen der diagrammatischen Datenvisualisierung von Marketoolz unkenntlich gemacht.

2.Grundlagen

In diesem Kapitel werden die grundsätzlichen, zum Verständnis dieser Arbeit notwendigen Begriffe und Grundlagen erläutert. Im Teil über die wirtschaftsinformatischen Grundlagen wird auf den Kontext eingegangen, in dem diese Arbeit anzusiedeln ist.

Im folgenden Kapitel 2.2 werden anschließend Grundlagen der tabellarischen- und diagrammatischen Datenvisualisierung erläutert.

Im Abschnitt über die technischen Grundlagen wird auf die verwendeten Technologien eingegangen und diese einzeln mit ihren Grundcharakteristika beschrieben, sowie eine Definition des MVC Konzepts vorgenommen. Kapitel 2.4, sonstige Grundlagen, befasst sich abschließend mit den Themen RIA und Drag and Drop.

2.1Wirtschaftsinformatische Grundlagen

Im Abschnitt über die wirtschaftsinformatischen Grundlagen wird eine Definition der Business Intelligence gegeben, diese Arbeit einem Teilbereich der Business Intelligence zugeordnet und der Begriff der Ad-hoc Analysesysteme näher erläutert.

2.1.1Business Intelligence

Die steigende Marktdynamik und die rasant wachsenden Informationssysteme stellen Unternehmen heutzutage vor immer größere Herausforderungen. Unternehmen aller Branchen und Größen müssen zeitnah und dynamisch über alle geschäftlichen Realitäten, sowie über den Ablauf und die Effizienz ihrer Geschäftsprozesse informiert sein.^[5]

Business Intelligence versteht sich laut Kemper als „… integrierter, unternehmensspezifischer, IT-basierter Gesamtansatz zur betrieblichen Entscheidungsunterstützung…“^[6]

Der Teilbegriff „Intelligence“ wird hierbei ganz unterschiedlich interpretiert. Dies ist zum Teil auf die relative junge Geschichte des Begriffs der Business Intelligence zurückzuführen, welcher sich erst Ende der 90er Jahre langsam etablierte und den Oberbegriff der Management Support Systeme ablöste, da die Nutzung solcher Systeme nichtmehr alleine dem Management vorbehalten war.

Von Kemper und Baars wird „Intelligence“ als Information verstanden, die es zu generieren, zu speichern, zu recherchieren, zu analysieren, zu interpretieren und zu verteilen gilt.^[7] Gluchowski hingegen versteht „Intelligence“ als Einsicht oder Erkenntnis und Hansen und Neumann interpretieren „Intelligence“ im Sinne von Auskunfts- oder Nachrichtendienst.^[8]

Business Intelligence ist heutzutage ein zentraler Aspekt eines jeden Unternehmens, um das Bestehen am Markt und die Position gegenüber Wettbewerbern zu gewährleisten. Will man diesen Aufgaben gerecht werden, bedarf es angemessener Hilfsmittel, die den Führungskräften und Entscheidungsträgern bzw. dem Management in Planungs- und Entscheidungsprozessen effizient und zeitgemäß zur Seite stehen. Die IT-basierten Business Intelligence Lösungen werden allgemein auch als „ Management Information Systeme “ (MIS) bezeichnet.^[9]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Nutzenzuwächse durch MIS-Einsatz

(Quelle: Hannig (2002))

Abbildung 1 zeigt die Nutzenzuwächse, die sich laut einer Studie des Instituts für MIS e. V. Ludwigshafen für die Anwender aus dem Einsatz von MIS ergeben. Laut einer im Juni 2008 vom IDC veröffentlichten Studie hatte der Business Intelligence Markt von 2005 bis 2007 konstante Wachstumsraten von rund 11.5%.^[10] Des Weiteren haben sich die drei größten Business Intelligence Anbieter im Ranking der 500 größten Softwarefirmen, in dem genannten Zeitraum von den Plätzen 39, 61 und 71 auf die Plätze 28, 29, 36 verbessert.^[11] Diese Zahlen zeigen deutlich die wachsende Relevanz dieses Sektors im Bereich des Softwaremarktes.

2.1.2Teilbereiche der Business Intelligence und Einordnung dieser Arbeit

Generell kann festgehalten werden, dass die auf dem Markt erhältlichen IT-basierten Business Intelligence Lösungen weit von einer branchenübergreifenden und alle betrieblichen Bereiche umfassenden Gesamtlösung entfernt sind. In der Realität entwickeln die meisten Unternehmen im Laufe der Zeit mehr oder weniger eigenständige, und auf die jeweiligen Bedürfnisse angepasste, organisationsspezifische Lösungen.^[12]

Am Markt angebotene Lösungen sind daher, wie auch die Produkte der „marketoolz.com GmbH“, nur für die Lösung von Teilaspekten der unternehmensumfassenden Business Intelligence geeignet.^[13] Im Falle von Marketoolz ist dieser Teilbereich der des Marketing- und Vertriebscontrolling. Dieser Teilbereich wird aber von Marketoolz im vollen Umfang des Business Intelligence Ordnungsrahmen (s. Abbildung 2) abgedeckt: Von der Datenbereitstellung, über die Informationsgenerierung, -speicherung und -distribution bis hin zum Informationszugriff. Man könnte also auch von einem Marketing-Informations-System sprechen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Business Intelligence Ordnungsrahmen

(Quelle: Kemper et al. (2006))

Diese Arbeit, bzw. der im Zuge dieser Arbeit zu entwickelnde Chartbuilder, lässt sich innerhalb des in Abbildung 2 dargestellten Business Intelligence Ordnungsrahmen der Ebene der Informationsgenerierung zuordnen. Des Weiteren gibt es eine erneute Detaillierung innerhalb der Informationsgenerierung, bzw. der Analysesysteme (s. Abbildung 3). Hierbei werden die Analysesysteme aufgrund ihrer funktionalen Ausrichtung in generische Basissysteme und konzeptorientierte Systeme unterteilt.^[14]

Abbildung 3: Analysesysteme für das Management

(Quelle: Kemper et al. (2006))

Generische Basissysteme sind Systeme, die als eigenständige Komponenten in ein umfassendes Business Intelligence Anwendungssystem integriert werden können. Konzeptorientierte Systeme hingegen bilden ein bestimmtes betriebswirtschaftliches Konzept ab und beziehen sich auf bestimmte Managementprozesse. Innerhalb dieser Klassifizierung ist diese Arbeit den Generischen Basissystemen zuzuordnen.^[15]

Innerhalb der Generischen Basissysteme gehört diese Arbeit zum Bereich der Ad-hoc-Analysesysteme, da mit den Flex 3 Diagrammen die vom Benutzer ausgeführten OLAP -Analysen visualisiert werden.

2.1.3Ad-hoc Analysesysteme

Der Bereich der Ad-hoc Analysesysteme ist ein Teilbereich der Generischen Basissysteme. Ad-hoc meint hierbei eine spontane Abfrage von Daten, ohne dass eine im Voraus programmierte Abfrageroutine verwendet wird.^[16] Diese freien Abfragesysteme bieten dem Anwender eine große Flexibilität beim Aufsuchen und Zusammenstellen relevanter Daten. Die Abfrage wird hierbei meist an ein OLAP -System gestellt, welches die gewünschten Daten zurückliefert.^[17]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Bedeutung der Ad-hoc Analyse

(Quelle: Hannig (2002))

In Abbildung 4 ist zu erkennen, dass der Bereich der Ad-hoc Analyse eine der wenigen Analysefunktionen darstellt, bei der der Anwender nicht auf standardisierte Aufbereitung und Präsentation der Daten bedacht ist.^[18] „Der Anteil der Anwender, die aktiv mit den Business Intelligence Werkzeugen arbeiten und Analysen vornehmen, liegt seit Jahren bei etwas über 60%.“^[19]

Es wird dem Benutzer ermöglicht, eigenständig den Datenbestand zu analysieren, einzuschränken und die präsentierten Daten auf seine individuellen Bedürfnisse bzw. Analyseziele, zielgerichtet anzupassen. Hierdurch beschränkt sich der Benutzerkreis, der sich der Ad-hoc-Analyse bedient, auf erfahrene Anwender, denn diese stellen „… höhere Ansprüche an die Fähigkeiten des Bedieners, da es hier tieferer Einblicke in die Funktionalität des Abfragesystems bedarf. Ist das System etwa auf Basis eines Datenbanksystems realisiert, muss der Benutzer mit den zugrunde liegenden Datenstrukturen vertraut sein.“^[20]

2.2Grundlagen der Datenvisualisierung

Um das Verständnis für die Ergebnisse von Computerrechnungen oder Datenbankabfragen zu fördern, ist eine zielgerichtete Visualisierung nötig.^[21] Mit denen für diese Arbeit relevanten Visualisierungstechniken befasst sich dieses Kapitel. Als erstes werden einige, für das Verständnis der folgenden Kapitel, wichtige Grundlagen erläutert, darauf folgend wird die Tabelle als Visualisierungstechnik näher betrachtet und abschließend auf die diagrammatische Darstellung von Daten eingegangen.

2.2.1Allgemeine Grundlagen

Stetige Variable (Daten-Objekt)

Bei denen im weiteren Verlauf dieser Arbeit betrachteten Werten innerhalb von Tabellen und Diagramen handelt es sich ausschließlich um stetige Variablen. Stetige Variablen enthalten, im Gegensatz zu den kategorialen Variablen, nicht nur eine begrenzte Anzahl unterschiedlicher Codierungen. Eine kategoriale Variable ist z.B. das Geschlecht, bei der es nur die Variablenwerte „männlich“ und „weiblich“ gibt. Stetige Variablen können eine Vielzahl von Werten annehmen.^[22] Denkbare stetige Variable könnten z.B. „Einnahmen“ oder „Ausgaben“ sein. Die Variablen, die innerhalb eines Diagramms oder einer Tabelle vorkommen, werden im weiteren Verlauf dieser Arbeit, aufgrund der anwendungsinternen Begriffsdefinition innerhalb der Marketoolz Software als Daten-Objekte bezeichnet. Eine Tabelle, welche die Ausgaben sowie die Einnahmen enthält, ist folglich eine Tabelle mit 2 Daten-Objekten.

Merkmalsausprägungen

Die Werte die ein Merkmal (kategoriale Variable) annehmen kann, heißen Merkmalsausprägungen.^[23] Für die Beispieltabelle aus Abbildung 6 sind die Merkmalsausprägungen für die Spalte Marke: BMW und Audi.

2.2.2Tabellarische Visualisierung

Eine Tabelle ist ein Hilfsmittel für die Aufbereitung von Datenmaterial. Tabellen sind grundsätzlich in Form von Zeilen und Spalten organisiert.^[24] Sie sollen die abgefragten Daten, bzw. die aus der Abfrage resultierenden Informationen, wiedergeben. Weitergehend ist zu berücksichtigen, dass die Tabelle klar und deutlich aufgebaut sein muss und die Informationen verständlich und übersichtlich präsentiert werden. Wie in Abbildung 5 zu sehen, gibt der Tabellenkopf Auskunft über den Inhalt der Spalten, bzw. die Merkmalsausprägungen, und deren Häufigkeit. In der Vorspalte sind die entsprechenden Informationen der einzelnen Zeilen enthalten.^[25]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Schema einer Tabelle

(Quelle: Holland und Scharnbacher (2006))

Bei den im weiteren Verlauf dieser Arbeit betrachteten Tabellen handelt es sich hauptsächlich um sogenannte Kreuz- bzw. Kontingenztabellen. Bei dieser Art von Tabellen werden die Merkmalsausprägungen der betrachteten Daten in den Haupt- und Unterspalten einer Tabelle, sowie in den Haupt- und Unterzeilen definiert. Die Merkmalsausprägungen der Spalten werden mit denen der Zeilen über die Fächer der Tabelle verknüpft (s. Abbildung 6). Ein Tabellenfach bzw. eine -zelle besitzt somit alle Merkmale der dazugehörigen Spalten- und der Zeilenköpfe. Mit Hilfe von Kreuztabellen ist es möglich, die Frage zu beantworten, ob zwischen zwei Merkmalen einer Gruppe der untersuchten Merkmalsträger ein statistischer Zusammenhang besteht und ob eine derartige Beziehung gegebenenfalls auch für die Grundgesamtheit, aus der die Merkmalsträger ausgewählt wurden, angenommen werden kann.^[26]

Die im Zuge dieser Arbeit betrachteten Tabellen können aber prinzipiell auch wie die in Abbildung 5 zu sehende Tabelle strukturiert sein, mit Ausnahme der nie vorhandenen laufenden Zeilennummern und der optionalen Summenzeile. Eine Tabelle kann außerdem eine theoretisch unbegrenzte Zahl an Daten-Objekten anzeigen – mindestens aber eins.

Diejenigen Elemente, welche die einzelnen Merkmale der Hauptspalten in Unterspalten bzw. der Hauptzeilen in Unterzeilen unterteilen und hierdurch die Inhalte der Tabellenfächer spezialisieren, werden im weiteren Verlauf dieser Arbeit, aufgrund der anwendungsinternen Begriffsdefinition innerhalb der Marketoolz Software, als Gruppierungs-Objekte oder Gruppierungen bezeichnet (s. Abbildung 6).

Außerdem werden die gesamten Gruppierungen der Spalten und der Zeilen im weiteren Verlauf dieser Arbeit, aufgrund der anwendungsinternen Begriffsdefinition innerhalb der Marketoolz Software, als Row- und Column-Vector bezeichnet. In Abbildung 6 umfasst der Row-Vector die Marke und das Modell und der Column-Vector die Daten-Objekte, die Jahre und die Monate.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Kreuztabellenstruktur

(Quelle: Eigene Darstellung)

2.2.3Diagrammatische Visualisierung

Neben den Tabellen stellt ein Diagramm eine zweite wichtige Form der Darstellung von Datenmaterial dar. Mit Hilfe von Diagrammen sollen optische Eindrücke der zu Grunde liegenden Daten vermittelt werden.^[27] Es werden in diesem Kapitel zuerst einige Grundlagen bezüglich der Visualisierung per Diagramm erläutert und anschließend wird auf die einzelnen Diagrammtypen eingegangen.

2.2.3.1Grundlagen der diagrammatischen Visualisierung

Der Umfang der Daten ist hierbei generell unerheblich, da auch eine geringe Anzahl von betrachteten Objekten eine relevante Datenmasse darstellen kann. Allerdings sind gewisse Grenzen zu beachten, die z.B. aus der Größe eines üblichen Monitors oder den Grenzen der menschlichen Wahrnehmung resultieren. Ab einer gewissen Masse an Daten sind diese im Diagramm nichtmehr zu differenzieren.

Des Weiteren ist auf die Homogenität der Elemente bezüglich der angestrebten Visualisierung, bzw. des Untersuchungsziels zu achten. Es muss eindeutig feststehen welche Anzahl an Objekten zur betrachteten Masse gehört – die Objekte müssen sich also sachlich, räumlich oder zeitlich abgrenzen. Die für die Abgrenzung relevanten Kriterien oder Eigenschaften der Objekte werden als Merkmale bzw. Gruppierungen bezeichnet.

Hierbei bleiben für das Ziel der Untersuchung unwesentliche Merkmale unberücksichtigt. Jedes Merkmal muss mindestens zwei Merkmalsausprägungen aufweisen und die sogenannten Merkmalsträger (Objekte der betrachteten Masse bzw. Tabellenzellen) müssen eindeutig einem der beiden Ausprägungen zuzuordnen sein. Bei drei oder mehr Merkmalsausprägungen muss die Zuordnung eindeutig durch die Vorgabe einer Abstufung möglich sein.^[28]

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Beispieldaten für Diagrammdefinitionen (Ausgaben in Mio. €)

(Quelle: Eigene Darstellung)

Datenreihe

Eine Datenreihe ist eine Gruppe in einem Diagramm, die sich auf eine Zeile oder eine Spalte einer Tabelle gründet.^[29] Bezogen auf die Beispieldaten in Tabelle 1 könnten die Datenreihen für ein Diagramm entweder die Jahre oder die Marken sein. Datenreihen werden im weiteren Verlauf dieser Arbeit, aufgrund der Flex 3 Begriffsdefinition, als Serien bezeichnet.

Skalen/Lineare Achsen

Bei allen betrachteten Diagrammtypen werden eine oder mehrere Skalen für die Ausrichtung oder Positionierung der dargestellten Elemente benutzt. Skalen sind Linien, bei denen einzelne Punkte auf der Linie bestimmten Zahlen zugeordnet sind. Es wird also durch Markierungen in gleichmäßigen Abständen auf der Linie eine Einteilung vorgenommen.^[30] Die Einteilung und Beschriftung der Achsen kann entweder numerischen Typs sein oder es werden die Merkmalsausprägungen an der Achse abgetragen. Achsen mit numerischen Skalen werden in Form von Geraden als vertikale- oder y-Achse bei den Linien- und Säulendiagrammen benutzt. Beim Balkendiagramm ist die numerische Achse horizontal auf der x-Achse zu finden. Blasendiagramme haben auf der x-und der y-Achse numerische Achsen und bei den Kreis- oder Kuchendiagrammen sind sie, wie beim Ziffernblatt einer Uhr, als Kreisskala wiederzufinden. Bei dem für die numerische Achse gewählten Maßstab ist darauf zu achten, dass auch der größte vorhandene Wert der betrachteten Masse noch auf der Achse abgetragen werden kann, und dass außerdem der kleinste Wert nicht so weit am Ursprung der Achse liegt, dass die Säule oder die Line nicht mehr wahrnehmbar ist.^[31] Um die Verständlichkeit eines Diagramms zu maximieren, sollte bei der initialen Erzeugung die Skala auf der numerischen Achse bei 0 beginnen, sodass alle Werte angezeigt werden. Im weiteren Verlauf dieser Arbeit werden numerische, skalare Achsen aufgrund der Begriffsdefinition in Flex 3 als lineare Achsen bezeichnet.

Diagramme mit mehreren linearen Achsen

Die Darstellung eines Diagramms mit mehreren linearen Achsen ist nur dann sinnvoll, wenn die zu visualisierenden Daten mindestens zwei Daten-Objekte beinhalten. Hierbei wird je ein Daten-Objekt einer Skala auf einer linearen Achse zugewiesen. Besonders wichtig ist eine Darstellung mit zwei linearen Achsen, wenn die Daten-Objekte nicht dieselbe Maßeinheit haben (z.B. Euro- und Prozentwerte). Wenn es sich beispielsweise um ein Diagramm mit den Daten-Objekten Einnahmen und Ausgaben handelt, ist eine Darstellung mit zwei linearen Achsen nicht zu empfehlen, da dies zu Fehlinterpretationen der Daten führen kann. Handelt es sich hingegen um Daten, die Prozentzahlen und Eurowerte beinhalten, sind zwei lineare Achsen im Diagramm aufgrund der Lesbarkeit fast unumgänglich (z.B. wären 5% auf einer Skala mit Mio. Ausgaben in Euro nicht darstellbar). Mehrere lineare Achsen können im Säulen-, Linien- und Balkendiagramm vorkommen.

Kategorieachse

Bei den Linien-, Balken- und Säulendiagrammen wird zusätzlich zu den/der numerische/n, skalaren Achse/n eine Achse verwendet, auf der die Merkmalsausprägungen der betrachteten Daten abgetragen werden. Dieser Achsentyp wird im weiteren Verlauf dieser Arbeit aufgrund der Begriffsdefinition in Flex 3 als Kategorieachse bezeichnet.

Legende (Legend)

Ein weiteres unverzichtbares Element bei der graphischen Informationsvisualisierung ist die Legende. In einer Legende wird die Bedeutung der farblich oder durch Muster differenzierbar gemachten Serien innerhalb eines Diagramms angegeben. Auch für Grafiken, in der nur eine einzelne Serie dargestellt wird, kann eine Legende eingefügt werden. Es wird also auf jede in einem Diagramm dargestellte Serie in der Legende verwiesen.^[32] Legenden werden im Chartbuilder für alle Diagrammtypen, ausgenommen dem Blasendiagramm, dargestellt.

2.2.3.2Diagrammtypen

Im Folgenden wird nun auf die für diese Arbeit relevanten Diagrammtypen eingegangen und deren struktureller Aufbau erläutert. Bei der Definition und Beschreibung der einzelnen Diagrammtypen wird zur Veranschaulichung teilweise auf die Beispieldaten von Tabelle 1 Bezug genommen.

Säulendiagramm

Bei einem Säulendiagramm werden auf der horizontalen Achse die Ausprägungen der Merkmale abgebildet. Nach den Beispieldaten aus der Tabelle 1 wären das entweder die Jahre oder die Marke. Die horizontale Achse ist bei diesem Diagrammtyp folglich die Kategorieachse.^[33] Die vertikale Achse ist die lineare Achse, auf der der Maßstab eingetragen wird. Bezogen auf die Beispieldaten würden die eingetragenen Werte auf der linearen Achse zwischen 0 und 135 - 140 Mio. Euro liegen. Die vertikale Länge der einzelnen dargestellten Balken wird nun bestimmt durch den Punkt, der über den Merkmalsausprägungen in Höhe des entsprechenden Wertes liegt. Für die Breite der einzelnen Säulen gibt es keine festen Vorschriften, es sollten jedoch innerhalb eines Diagramms alle Säulen einheitlich gleich breit sein.^[34] Die Breite der Säulen ist abhängig davon, wie viele Elemente dargestellt werden sollen. Die Anzahl der Säulen ergibt sich aus der Anzahl der Merkmalsausprägungen auf der Kategorieachse multipliziert mit der Anzahl der Serien.

Balkendiagramm

Der Aufbau des Balkendiagramms ergibt sich direkt aus dem Säulendiagramm. Es werden lediglich Kategorieachse und die lineare Achse vertauscht. Die Kategorieachse ist also beim Balkendiagramm vertikal angeordnet und die lineare Achse/n horizontal.

Stapeldiagramm

Dieser Diagrammtyp kann als Stapelbalken- und Stapelsäulendiagramm auftreten. Auch das Stapeldiagramm ergibt sich direkt aus dem Säulen- bzw. aus dem Balkendiagramm und ist eine Variation, in der alle Elemente der einzelnen Merkmalsausprägungen übereinander gestapelt werden. Bezogen auf die Beispieldaten könnte für jede Marke ein Balken mit den drei Jahreswerten gebildet werden. Jeder Balken oder jede Säule enthält also alle Serien einer auf der Kategorieachse abgetragenen Merkmalsausprägung. Die Gesamthöhe des Elementes repräsentiert also den summierten Wert aller Serien für einen Wert auf der Kategorieachse, so dass ein Vergleich möglich ist.^[35]

Blockdiagramm

Das Blockdiagramm ist eine Variation des Stapeldiagramms. Es besteht aus mehreren rechteckigen Elementen der gleichen Höhe. Jede einzelne Säule und jeder Balken charakterisiert die relative Häufigkeitsverteilung eines diskreten Merkmales.^[36] Bei diesem Diagrammtyp richtet sich die Säulenhöhe, die je nach Darstellungsart vertikal (Säulenblockdiagramm) oder horizontal (Balkenblockdiagramm) ausgeprägt ist, nicht nach den absoluten Werten an der linearen Achse, sondern alle Säulen bzw. Balken haben dieselbe Höhe. Die absoluten Werte werden vernachlässigt und der Fokus auf die relative Verteilung innerhalb der einzelnen Merkmale gelenkt, und der Maximalwert auf der linearen Achse entspricht immer 100%.^[37]

Kreisdiagramm

Im Kreis- oder Kuchendiagramm “… wird zu jeder Merkmalsausprägung ein Kreissektor gebildet, wobei die Fläche der Sektoren und damit auch die Innenwinkel proportional zur Häufigkeit gewählt werden.“^[38] Kreisdiagramme eigenen sich besonders zur grafischen Darstellung von relativen Häufigkeiten und werden häufig für die Darstellung von Prozentzahlen (z.B. Wahlergebnisse) verwendet.^[39] Bei Kreisdiagrammen ist darauf zu achten, dass erstens nur eine geringe Anzahl an Elementen visualisiert werden kann, und es zweitens nicht dazu geeignet ist, geringe Veränderungen oder Unterschiede darzustellen.^[40] Ein Kreisdiagramm beinhaltet immer nur eine einzelne Serie. Im Kreisdiagramm werden, im Gegensatz zu den anderen Diagrammtypen, nicht die einzelnen Serien farblich voneinander abgehoben sondern die einzelnen Werte der visualisierten Serie.

Liniendiagramm

Das Liniendiagramm, welches bevorzugt für die Darstellung von Zeitreihen verwendet wird, ist von der Struktur dem Säulendiagramm sehr ähnlich. Die Merkmalsausprägungen, welche meist Datumswerte darstellen, befinden sich horizontal auf der Kategorieachse und die Werte werden vertikal auf der linearen Achse abgetragen. Die Datumswerte werden hierbei, entsprechend der im abendländischen Raum üblichen Leserichtung, von links nach rechts aufsteigend angeordnet. Also der am weitesten zurückliegende Datumswert wird als erstes auf der Kategorieachse eingetragen. Das Wertepaar Zeitpunkt und Größe des beobachteten Wertes wird nun im Diagramm markiert und durch das Verbinden der Punkte für jede Serie eine Linie gezeichnet.^[41]

Blasendiagramm

Um das Blasendiagramm sinngemäß darstellen zu können, müssen für jede Blase drei Daten-Objekte vorhanden sein. Auf die Beispieldaten bezogen wäre z.B. denkbar, dass für das Jahr 2007 der Marke Audi zusätzlich zu den Ausgaben die Einnahmen und die verkauften Fahrzeuge vorhanden sind. Der Zusammenhang dieser drei Variablen kann nun durch ein Blasendiagramm verdeutlicht werden.^[42] Beim Blasendiagramm sind sowohl die x- also auch die y-Achse lineare Achsen, die die Positionierung der einzelnen Blasen innerhalb der Diagrammmatrix ermöglichen. Die Größe der Blase wird durch das dritte Daten-Objekt bestimmt. Bezogen auf die Beispieldaten wäre denkbar, die Ausgaben an der horizontalen Achse abzutragen, die Einnahmen an der vertikalen und die Blasengröße durch die verkauften Fahrzeuge zu bestimmen. Die Lage der Punkte innerhalb der Matrix und das Verhältnis zu den Positionen anderer Punkte kann nun Aufschluss über den Zusammenhang zwischen den Blasen geben.^[43] Eine Darstellung als Blasendiagramm ist aber nur dann sinnvoll, wenn von den beobachteten Werten die jeweilige Ausprägung der an den x- und y-Achsen abgetragenen Daten-Objekten kaum übereinstimmen.^[44] Ansonsten führt dies zu einer Überlagerung der Blasen, was das Lesen und Interpretieren des Diagramms und der beinhaltenden Blasen stark erschwert oder gar unmöglich macht. Die im Chartbuilder erstellten Blasendiagramme beinhalten ausschließlich eine einzelne Serie.

2.3 Technische Grundlagen

Im folgenden Teil werden die Technischen Grundlagen beschrieben. Hierzu gehören einmal die verwendeten Technologien sowie das Model, View, Controller Konzept.

2.3.1 Flex 3

Adobe Flex 3 ist ein Open Source Entwicklungsframework für die Erstellung sogenannter RIAs (Rich Internet Applications). Flex 3 Anwendungen werden zu SWF-Dateien kompiliert und laufen mit dem Flash Player, plattformunabhängig in jedem gängigen Internetbrowser. Laut einer Statistik von Adobe lag die Verbreitung des Flash Players 7, im Dezember 2008 bei über rund 99% und die des Flash Players 9 bei ca. 98%.^[45] Der hieraus resultierende Vorsprung gegenüber anderen Softwareplattformen zeigt Abbildung 7.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Flash Player Verbreitung

(Quelle: Adobe (2008c))

Das Flex-Framework basiert auf einer Bibliothek von ActionScript-Objekten, die die Grundlage für den Aufbau und Flash laufender RIAs bilden. Es besteht aus dem Flex Builder IDE, welches auf Eclipse basiert, dem LiveCycle Data Service wie z.B. BlazeDS und den Flex Charting Komponenten. Die Charting Komponenten sind nicht in der Open Source Version des Flex SDK enthalten.

Das Programmieren einer Flex-Anwendung gestaltet sich als ein Mix aus ActionScript und einer XML-basierten Sprache namens MXML. MXML ist eine auf XML basierende, deklarative Markupsprache, die für die Benutzerschnittstellen bzw. Views einer Anwendung verwendet wird.^[46] Jedes Tag in MXML bildet eine Komponente ab und im Gegensatz zu HTML können leicht neue, eigene Komponenten bzw. Tags hinzugefügt und verwendet werden. Ein zentraler Aspekt von Flex 3 ist, dass es vollständig in ActionScript 3 integriert ist.

Die Flex Versionen 1 und 1.5, welche beide 2004 von Adobe Systems veröffentlicht wurden, waren zu diesem Zeitpunkt noch teure und serverbasierte Produkte, basierend auf ActionScript 2 und Flash 7.^[47] Die Lizenzen kosteten rund 10.000 €, und es musste für die Kompilierung der Anwendung ein Server vorhanden sein. Diese Art der Kompilierung wurde aber schon in Flex 2.0 abgeschafft und auch die Bindung an den hochpreisigen Enterprise-Server wurde verworfen, um Flex für die Masse der Anwendungsentwickler und Programmierer zugänglich zu machen.^[48]

Schon vor Flex konnte mit den Adobe Flash Produkten RIAs entwickelt werden, doch waren die RIA Ansätze mit Flash eher auf die Erstellung von grafisch interaktivem Content ausgelegt als auf Entwicklung ganzheitlicher Web-Applikationen.^[49] Flex vereint diese beiden Aspekte der Softwareentwicklung. Es ist ein ideales Framework, um grafisch anspruchsvolle, ganzheitliche Internetanwendungen zu entwickeln. Ein weiterer Vorteil von Flex ist, dass die SWF Dateien beim Aufrufen der Webseite einmalig heruntergeladen werden. Hierdurch wird die Darstellungsschicht auf den Client ausgelagert, Veränderungen in den „Sichten“ (Views) benötigen also normalerweise kein Nachladen von neuen Daten. Es werden ausschließlich Business Daten über das Netz abgerufen bzw. „nachgeladen“.^[50]

Flex 3 und AS3 sind im Zuge dieser Arbeit die beiden Hauptelemente aus denen sich das Endprodukt dieser Arbeit zusammensetzt. Der hierbei wohl wichtigste Teilaspekt des Flex 3 Frameworks sind die Charting Komponenten, mit denen die gesamte Visualisierung der Daten realisiert wird. Außerdem wird mit dem LiveCycle Data Service, BlazeDS die Datenbeschaffung umgesetzt, mit der External-Interface API via JavaScript mit dem das SWF umgebende HTML kommuniziert und mit den Flex Komponenten die Benutzeroberfläche gestaltet. Des Weiteren wird für die Applikations Architektur das Open Source Framework Cairngorm benutzt.

2.3.2 ActionScript

Bei der Programmierung einer Flex 3 RIA Applikation ist die Verwendung von ActionScript unumgänglich. Die erste Version von ActionScript wurde 1998 von Macromedia veröffentlicht, welches 2005 von Adobe Systems aufgekauft wurde, um simple 2D Vektor Animationen in Flash (damals noch Macromedia Flash) auszuführen.^[51] Gegenüber Flex, welches ausschließlich für die Benutzerschnittstellen verwendet wird und eine deklarative Programmiersprache darstellt, ist ActionScript eine imperative Sprache, welche wie JavaScript auf dem ECMA-Script („European Computer Manufacturers Association“) basiert. Mit ActionScript können Datenmodelle und clientseitige Geschäftslogiken entwickelt werden, die eine Flex-Web-Anwendung zu einer RIA werden lassen. ActionScript kann innerhalb von Flex in Form von Klassen, direktem Einbinden in MXML-Tags, verschachtelt in MXML-Tags oder in MXML-Skripten verwendet werden. Generell wird im Zuge dieser Arbeit, ActionScript Hauptsächlich für die Geschäftslogik und die Datenmodelle genutzt. Die Benutzerschnittstellen und das Layout der Applikation werden weitestgehend Flex bzw. MXML überlassen, da es hierfür weitaus besser geeignet ist als AS3. Theoretisch ließe sich aber auch die gesamte Anwendung in AS3 realisieren, da alle MXML Elemente und Strukturen auch in AS3 abgebildet werden können. Faktisch werden nämlich bei der Kompilierung einer SWF Datei MXML komplett in AS3 umgewandelt.^[52]

Ein Beispiel für die Darstellbarkeit von MXML in AS3 zeigt der folgende Code:

Quellcode 1: MXML und AS3 Vergleich

2.3.3JavaScript

Gegen Ende des Jahres 1995 stellte die Firma Netscape, im Zuge der neuesten Version ihres Internet-Browsers „Netscape Navigator“ eine Sprache namens LiveScript vor, mit der man auf HTML-Seiten Einfluss nehmen konnte. Da die Syntax von LiveScript an die der Programmiersprache JAVA angelehnt war – und zusätzlich wahrscheinlich aus marketingtechnischen Gründen - wurde LiveScript ab dem „Netscape Navigator 2“ in JavaScript umbenannt.^[53] Der Grundgedanke, mit dem JavaScript entwickelt wurde war, die statischen Inhalte von Webseiten durch dynamische Inhalte und durch die Möglichkeit der Interaktion zu erweitern.^[54] Der heutigen weiten Verbreitung von JavaScript gingen in der Anfangsphase aber einige Probleme voraus. Zum einen waren die Implementierungen selbst in der 2. Version des Netscape Navigators eher mangelhaft, und da die Deaktivierung von JavaScript in den frühen Browserversionen nicht implementiert war, ergaben sich erhebliche Sicherheitsmängel. Zum anderen wollte auch der Browserkonkurrent Microsoft (Internet Explorer), der auf den Erfolg aufmerksam geworden war, auf den Zug aufspringen und veröffentlichte eine eigene Auflage von JavaScript unter dem Namen JScript. JScript und JavaScript ähneln sich äußerlich sehr stark, sind aber nicht identisch. Der aus den Konkurrenzprodukten resultierende Wettkampf um Abgrenzung gegenüber dem Mitstreiter sowie um den Kreis der Benutzer, wurde glücklicherweise 1997/98 durch den von der ECMA erarbeiteten Standard ECMA-Script beseitigt.^[55]

Im Gegensatz zu HTML, welches eine Auszeichnungssprache ist, ist JavaScript eine vollwertige Programmiersprache. Da JavaScript mit Objekten arbeitet, spricht man von einer objektorientierten Sprache. JavaScript kann clientseitig bzw. im Browser, oder serverseitig, z.B. auf einigen WebServern, eingesetzt werden. Heutzutage ist die clientseitige Verwendung von JavaScript jedoch das primäre Einsatzfeld, da die serverseitige Verwendung durch populäre Server-Scriptsprachen wie PHP, ASP oder JSP an Bedeutung verloren hat.^[56]

Im Zuge dieser Arbeit wird JavaScript für die Kommunikation zwischen der eingebundenen SWF Datei und dem umgebenen HTML genutzt. Diese Art der Kommunikation zwischen Flex und JavaScript wird mit der „External-Interface API“ von Flex 3 realisiert. Hierbei kann einerseits die Flex Anwendung eine bestimmte JavaScript Funktion ansprechen, oder eine Funktion der Flex Anwendung wird andersrum von JavaScript aus referenziert. Ein Beispiel für die Relevanz dieses Kommunikationsweges ist der Fall, dass sich ein Anwender zu einem erstellten Diagramm eine Tabelle erstellen lassen will. Hierfür wird eine JavaScript Funktion aufgerufen, der das Diagrammobjekt übergeben wird, diese erstellt eine neue Tabelle bzw. aktualisiert eine bestehende, ohne dass die Seite neu geladen werden muss.

2.3.4 Model, View, Controller Konzept

Das MVC (Model, View, Controller) Konzept oder MVC-Paradigma ist für Anwendungen, besonders für solche, die eine grafische Benutzeroberfläche zur Verfügung stellen, ein Architekturmuster, mit dem sich die Software in drei strukturelle Einheiten einteilen lässt. Dieses Konzept oder Entwurfsmuster wurde in den 70er und 80er Jahren durch Smalltalk bekannt.^[57] Heutzutage sind Implementierungen von MVC für nahezu jede Programmiersprache erhältlich - z.B. für Actionscript, Java, PHP und Ruby. Das MVC Konzept besteht aus drei Objekten. Das Model-Objekt steht für die Anwendungslogik, das View-Objekt für die Benutzeroberfläche und das Controller-Objekt stellt die Interaktionsmöglichkeiten für die Benutzereingaben auf der Bedienoberfläche zu Verfügung.^[58] Das MVC-Konzept ermöglicht, durch die Trennung von View und Anwendungslogik die Erstellung eines flexibleren Systems. Außerdem steigert es die Wiederverwendbarkeit und Erweiterbarkeit einzelner Elemente. Das in dieser Arbeit verwendete Flex-Framework welches das MVC Prinzip unterstützt, ist Cairngorm von Adobe. Laut Simon Widjaja ist Cairngorm „… der De-Facto-Standard für Flex-Entwickler“.^[59]

[...]

^[1] vgl. (Chamoni und Gluchowski 1998)

^[2] vgl. (Michaeli 2006)

^[3] (Gluchowski et al. 2008, S. 126)

^[4] vgl. (Gluchowski et al. 2008)

^[5] vgl. (Abels und Degen 1981)

^[6] (Kemper et al. 2006, S. 8)

^[7] vgl. (Umbach 2007)

^[8] vgl. (Gluchowski et al. 2008), (Hansen und Neumann 2005)

^[9] vgl. (Gluchowski et al. 2008)

^[10] vgl. (McDonough und Vesset 2007)

^[11] vgl. (softwaremag.com)

^[12] vgl. (Umbach 2007)

^[13] vgl. (Kemper et al. 2006)

^[14] vgl. (Kemper et al. 2006)

^[15] vgl. (Kemper et al. 2006)

^[16] vgl. (Engels 2009)

^[17] vgl. (Chamoni und Gluchowski 1998)

^[18] vgl. (Hannig 2002)

^[19] (Hannig 2002)

^[20] (Chamoni und Gluchowski 1998, S. 183)

^[21] vgl. (Brause 2005)

^[22] vgl. (Brosius 2007)

^[23] vgl. (Kohn 2005)

^[24] vgl. (Brosius 2002)

^[25] vgl. (Holland und Scharnbacher 2006)

^[26] vgl. (Kähler 1996)

^[27] vgl. (Abels und Degen 1981)

^[28] vgl. (Abels und Degen 1981)

^[29] vgl. (Meixner 2005)

^[30] vgl. (Abels und Degen 1981)

^[31] vgl. (Abels und Degen 1981)

^[32] vgl. (Brosius und Brosius 1995)

^[33] vgl. (Fahrmeir et al. 2007)

^[34] vgl. (Abels und Degen 1981)

^[35] vgl. (Heiler und Michels 1994)

^[36] vgl. (Abels und Degen 1981)

^[37] vgl. (Brosius und Brosius 1995)

^[38] (Bosch 1992, S. 8)

^[39] vgl. (Polasek 1988)

^[40] vgl. (Abels und Degen 1981)

^[41] vgl. (Abels und Degen 1981)

^[42] vgl. (Leonhart et al. 2004)

^[43] vgl. (Abels und Degen 1981)

^[44] vgl. (Bosch 1992)

^[45] vgl. (Adobe 2008a)

^[46] vgl. (Kazoun und Lott 2008)

^[47] vgl. (Lott und Kazoun 2008)

^[48] vgl. (Kazoun und Lott 2008)

^[49] (Sorokin et al.)

^[50] vgl. (Wikipedia)

^[51] vgl. (Wikipedia)

^[52] vgl. (Kazoun und Lott 2008)

^[53] vgl. (Wenz 2007)

^[54] vgl. (Regionales Rechenzentrum für Niedersachsen 2005)

^[55] vgl. (Hirsemann et al. 2003)

^[56] vgl. (Regionales Rechenzentrum für Niedersachsen 2005)

^[57] vgl. (Wiener und Pinson 2000)

^[58] vgl. (Chopra 2005)

^[59] (Widjaja 2008)