Konzeption und Realisierung von hoch-interaktiven Rich ... · Als Programmiersprache wird C#...

Johannes Gutenberg-Universität Mainz

Institut für Physik, Mathematik und Informatik

Studiengang Bachelor Informatik

Bachelorarbeit für die Prüfung zum

Bachelor of Science

Konzeption und Realisierung von hoch-interaktiven Rich

Interactive Applications (RIAs) mit Microsoft Silverlight(am Beispiel einer Projektmanagementsanwendung mit IBM ILOG Gantt)

Bachelorand: Andreas Congiu

Matrikelnummer: 2644278

Fachbereich: 08 � Informatik

Betreuer (Universität): Herr Dr. Thomas Hillebrand

Betreuer (IPSWAYS) Herr Dipl.-Phys. Marc Lucas

Abgabedatum: 26. August 2010

Eidesstattliche Erklärung

Hiermit erkläre ich eidesstattlich, dass ich die vorliegende Bachelorarbeit

�Konzeption und Realisierung von hoch-interaktiven Rich Interactive Applica-

tions (RIAs) mit Microsoft Silverlight�

selbständig und ohne fremde Hilfe angefertigt habe. Ich habe dabei nur die in der Arbeit

angegebenen Quellen und Hilfsmittel benutzt. Die Arbeit wurde in gleicher oder ähnlicher

Form noch keiner anderen Prüfung vorgelegt und auch noch nicht verö�entlicht.

Ort, Datum Unterschrift

Inhaltsverzeichnis

I Theoretische, konzeptionelle und technische Grundlagen 1

1 Einleitung 2

1.1 Motivation und Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Aufbau des Dokuments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Grundlagen und Einführung in die Basistechnologien 5

2.1 Rich Internet Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Was sind RIAs? De�nitionsversuch und Merkmale . . . . . . . . . . . 8

2.1.2 RIA-Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.3 Kritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Web Services und Service-orientierte Architekturen . . . . . . . . . . . . . . . 12

2.2.1 Verzeichnisdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.2 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.3 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.4 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.5 WCF RIA Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Microsoft Silverlight 19

3.1 Das Silverlight Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Architektur, Browserintegration und Deployment . . . . . . . . . . . . . . . . 22

3.3 Entwicklungsumgebungen und SDKs . . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Visuelle Schicht: XAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4.1 Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4.2 XAML-Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4.3 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.4.4 Ressourcen, Styles und Templates . . . . . . . . . . . . . . . . . . . . . 32

3.4.5 Silverlight Animationen . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.5 Logische Schicht: Code-Behind-Dateien . . . . . . . . . . . . . . . . . . . . . . 39

3.5.1 Dependency Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

I

INHALTSVERZEICHNIS

3.5.2 Eventhandling und Routed Events . . . . . . . . . . . . . . . . . . . . 42

3.5.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.6 Data Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.6.1 Binding in XAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.6.2 Binding in der Anwendungslogik . . . . . . . . . . . . . . . . . . . . . 48

3.6.3 Datenvalidierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.7 Kommunikation mit dem Server . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.8 Weitere Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.9 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.10 Marktverbreitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.11 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

II Konzeption und Realisierung der Beispielanwendung 62

4 Zum Grundverständnis der Anwendungsdomäne 63

5 Funktionale und Nichtfunktionale Anforderungen 66

6 Entwurf 71

6.1 IBM ILOG Gantt for .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.2 Gesamtarchitektur: Das Model-View-ViewModel-Entwurfsmuster . . . . . . . 77

6.3 Komponenten der Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.4 Entwurf zur Realisierung der Funktionalitäten . . . . . . . . . . . . . . . . . . 88

6.5 Datenmodell und Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . 91

7 Implementierung 96

7.1 Umsetzung des Model-View-ViewModel-Musters . . . . . . . . . . . . . . . . 96

7.1.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7.1.2 ViewModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

7.1.3 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7.2 Serveranbindung und Datenspeicherung . . . . . . . . . . . . . . . . . . . . . 117

7.2.1 Kommunikation mit dem Server . . . . . . . . . . . . . . . . . . . . . . 117

7.2.2 Datenspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

7.3 Erläuterungen zu sonstigen Klassen . . . . . . . . . . . . . . . . . . . . . . . . 121

7.3.1 UserControls der Anwendung . . . . . . . . . . . . . . . . . . . . . . . 121

7.3.2 Die Hauptanwendung App.xaml . . . . . . . . . . . . . . . . . . . . . . 125

7.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

8 Evaluation 127

8.1 Umsetzung der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 127

II

INHALTSVERZEICHNIS

8.2 Zusammenfassung und Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

III Anhang 129

A Zusätzliche Abbildungen und Listings i

A.1 WSDL-Datei des verwendeten Web Service . . . . . . . . . . . . . . . . . . . i

A.2 Klassendiagramm GanttWebServiceSoapClient . . . . . . . . . . . . . . . . . vi

A.3 Funktion zum Auslesen einer Gantt-Projekt-Datei . . . . . . . . . . . . . . . . vi

A.4 Klassendiagramm der Praxisanwendung . . . . . . . . . . . . . . . . . . . . . xi

B Verzeichnisse xii

Literaturverzeichnis xvi

Abbildungsverzeichnis xvi

Tabellenverzeichnis xix

Listingverzeichnis xx

C Abkürzungen und Begri�e xxiv

D CD-Inhalt xxvi

E Quellcode Übersicht xxvii

F CD xxix

III

Teil I

Theoretische, konzeptionelle und

technische Grundlagen

1

Kapitel 1

Einleitung

1.1 Motivation und Aufgabenstellung

Die Inhalte des Internets und die Form ihrer Präsentation auf Websites haben sich in den

letzten Jahren grundlegend verändert. Das sogenannte �Web 2.0� ermöglicht den Besuchern

eine Form von Interaktion durch und mit dynamischen Internetseiten, welche in Aussehen und

Inhalt von den Nutzern selbst mit einem kollaborativen Verständnis geprägt werden können.

Geschah dies in den Anfangsstadien des �Mitmachweb� hauptsächlich durch (zum Groÿteil ser-

verabhängige) Techniken wie PHP und ASP.NET in Kombination mit JavaScript und Ajax,

gewinnen heute rein Client-basierte Internetanwendungen zunehmend an Bedeutung. Insbe-

sondere die Rich Internet (oder Interactive) Applications (kurz RIAs) erlauben es, komplexere

und stark interaktive Programme auf Internetseiten zu platzieren und damit den Anwendern

reichhaltigere Möglichkeiten anzubieten. RIAs und insbesondere deren zu Grunde liegende

Frameworks sind technisch und konzeptionell an einem Punkt angelangt, der sie (nicht nur

für Unternehmen) in vielen Bereichen interessant macht. Dabei haben diese Anwendungen heu-

te nicht nur einen unterhaltenden (�Flash-Games�), kommerziellen (interaktive Werbebanner)

oder visualisierenden (�Streaming-Videos�, Präsentation von Multimedia) Gedanken. Sie ha-

ben das Potential eine eigene Art von Programmen hervorzurufen und der Webnutzung einen

neue Richtung zu geben, indem die Ausführungsumgebung einer Anwendung nicht mehr ein

spezi�scher Rechner des Endanwenders, sondern das Web an sich ist.

Die Entwicklung und insbesondere der Markt der Rich Internet Applications sind zwar nicht

in allen Bereichen vollständig ausgereift, jedoch existieren dort solide Grundlagen. Die tech-

nischen Möglichkeiten, welche die einzelnen Frameworks bieten, stehen denen von klassischen

Desktopanwendungen nur in wenigen Punkten nach. Schnell hintereinander auftretende Ver-

sionsverö�entlichungen der RIA-Plugins und Software-Development-Kits belegen, dass sie für

2

1.2 Aufbau des Dokuments

die �groÿen� Frameworkanbieter (wie Adobe, Sun, Microsoft) eine hohe Priorität am Markt

haben.

Mit stetig zunehmender Akzeptanz und Verbreitung der einzelnen Plugins setzt sich eine

Technik durch, die selbst für anspruchsvolle, in betrieblichem Umfeld eingesetzte Program-

me (sog. line-of-business-Anwendungen), �exible und dennoch mächtige Lösungen mitbringt.

Dabei können RIAs sowohl leichtgewichtigere, webbasierte Anwendungen ergänzen oder gar

komplett ersetzen, als auch Desktop-Applikationen im täglichen Umgang ablösen.

Diese Arbeit soll beschreiben, auf welche Weise sich hoch interaktive Rich Internet Appli-

cations mit Microsoft Silverlight konzipieren und realisieren lassen. Dazu werden zunächst

die grundlegenden Techniken zur Implementierung einer Silverlight-Anwendung erläutert. An-

schlieÿend wird dargestellt, was RIAs (speziell Microsoft Silverlight) zu leisten vermögen bzw.

wo ihre Schwächen liegen.

Nach der Herausarbeitung der wichtigsten Geschäftsprozesse einer Projektmanagementanwen-

dung, setzt ein praxisnahes Beispielprogramm die diskutierten Techniken, Anforderungen und

Modelle exemplarisch um. Im Zuge des Entwurfs muss ein Konzept entwickelt werden, welches

die Komponenten der Anwendung und ihre Gesamtarchitektur berücksichtigt. Dazu ist es u.a.

nötig, weitere Funktionalität in Form von Web Services bereitzustellen. Eine Beschreibung

der Implementierung auf Serverseite wird hier bewusst ausgelassen. Der Fokus dieser Arbeit

liegt auf der clientseitigen Realisierung der Benutzerober�äche, deren Geschäftslogik, sowie er

Kommunikation mit dem Server unter Verwendung von Web Services.

Zur weiteren Unterstützung kommt das IBM Framework ILOG Gantt for .NET (Kapitel 6.1)

zum Einsatz, welches einige vorgefertigte, hoch-interaktive Silverlight-Controls zur Planung

und Bearbeitung von Gantt-Diagrammen (S. 63) bereitstellt. Das Framework wird im Rahmen

der Arbeit technisch und funktional kurz erläutert.

1.2 Aufbau des Dokuments

Die Arbeit gliedert sich in zwei Bereiche. Im ersten, theoretischen, konzeptionellen und tech-

nischen Teil, werden die Grundlagen, Modelle, Konzepte und der Mehrwert von Rich Internet

Applications � insbesondere von Microsoft Silverlight 4 � erläutert. Es wird allgemein auf die

Basistechnologien und Grundlagen eingegangen. Neben technischen Merkmalen von Silver-

light (z.B. Architektur des Frameworks, funktionelle und logische Schichten, Abgrenzung zur

Windows Presentation Foundation) stehen die Kommunikation mit dem Server (über Web Ser-

vices), Sicherheitsaspekte und die Ober�ächen-Entwicklung mit Silverlight im Vordergrund.

Unter Nutzung der Library �IBM ILOG Gantt for .NET� wird im Praxisteil ein Editor für

3

1.3 Abgrenzung

Projektablaufsdiagramme (Gantt-Diagramme) innerhalb der .NET Umgebung implementiert.

Des Weiteren werden die Verwendung des Model-View-ViewModel-Entwurfsmusters mit Sil-

verlight und die Konzepte einer Service-orientierten Architektur (SOA) zur Realisierung von

line-of-business Aplications mit erhöhten Anforderungen beschrieben.

Der zweite Teil behandelt das oben genannte Praxisbeispiel einer hoch-interaktiven RIA zum

Projektmanagement mit Gantt-Diagrammen, deren allgemeinen bzw. speziellen Anforderun-

gen und Besonderheiten, sowie Architekturentwurf und Realisierung mit Silverlight in Kombi-

nation mit IBM ILOGGantt. Die im ersten Teil erarbeiteten Konzepte sollen hier exemplarisch

eine praxisnahe Anwendung �nden.

Als Programmiersprache wird C# verwendet. Zusätzlich kommt .NET und Silverlight Version

4.0 zum Einsatz. IBM ILOG Gantt for .NET liegt hier ebenfalls in Version 4.0 vor.

1.3 Abgrenzung

Für das Verständnis der Implementierung und der hier gezeigten Codefragmente werden

Grundkenntnisse in C# und .NET vorausgesetzt. Wissen über Markup-Sprachen wie XML

ist ebenfalls von Vorteil. Realisierung und Bereitstellung der genutzten Web Services sollen

aufgrund der umfangreichen Thematik nicht detailliert erläutert werden.

4

Kapitel 2

Grundlagen und Einführung in die

Basistechnologien

2.1 Rich Internet Applications

Das Internet diente ursprünglich zum globalen Transport von Dokumenten und Informatio-

nen über ein Netzwerk verschiedenster Rechner. Das Abrufen oder Bereitstellen von Daten

(hauptsächlich einfacher Textdokumente) galt lange Zeit als Hauptfunktion des World Wide

Web. Seit etwa Mitte der 1990er wurden weitere Möglichkeiten zur simplen Datenveränderung

über das Internet populär. Reine HTML-basierte Internetseiten waren weit verbreitet, jedoch

wurden bald speziellere Anforderungen benötigt. Internetseiten, generiert aus vielen dynami-

schen Komponenten in Zusammenarbeit zahlreicher Technologien (z.B. JavaScript, PHP, CSS,

Datenbanken, Web Services), bereichern die Landschaft der Internetanwendungen in heutiger

Zeit erheblich. HTML ist jedoch noch immer das endgültige Darstellungsformat der Inter-

netseite beim Benutzer. Für die Interpretierung des HTML-Dokumentes ist dabei stets der

Browser verantwortlich.

HTML leidet an beschränkten Möglichkeiten hinsichtlich Vielfalt der Seiten. Die fehlende

Multimediaintegration, gestiegene Anforderungen und eine relativ geringe Komplexität und

Ra�nesse der Webanwendungen im Vergleich zu normalen Desktop-Applikationen beförderten

neue Technologien. Heute sind vereinzelte Java- oder Flash-basierte Teilkomponenten, die

HTML nicht als Beschreibungssprache nutzen, sondern nur als Plattform, nicht mehr aus

dem Internet wegzudenken und erö�nen eine neue Dimension für Webanwendungen.

Einerseits bestehen gehobene Ansprüche des Nutzers hinsichtlich seines Wunsches nach In-

formationen, Unterhaltung und Interaktion mit der Internetseite, andererseits lassen sich

5


gegenwärtig auch bei Unternehmen umfassendere Anforderungen an repräsentative Interne-

tangebote (wie auch an Softwareprodukte allgemein) ausmachen.

Diese Trends führten zur Entwicklung von sog. �rich clients�. Ein erster Schritt in diese

Richtung waren Skriptsprachen wie JavaScript. In heutiger Zeit reicht deren Funktionalität

aber häu�g nicht aus. Umfangreiche und komplexere Anwendungen sind damit nur bedingt

realisierbar. Problematisch ist auch die relativ geringe Leistungsfähigkeit des Browser als

Laufzeitumgebung dieser Skripte. Bei Entwicklern von Internetseiten kam der Wunsch auf,

die Vorteile der klassischen Desktopanwendung mit denen des Internets zu vereinen. Tabelle

2.1 gibt dazu eine allgemeine Übersicht der wichtigsten Merkmale beider Paradigmen.

klassische HTML-Internetseite klassische Desktopanwendung

Ober�äche und Funktionalität sind relativ

einfach. Keine maximale Ausnutzung der

Arbeits�äche (d.h. kein Vollbild).

Ober�äche beliebig dynamisch gestaltbar

und der jeweiligen Programmsituation an-

gepasst (auch Vollbildmodus). Sehr viele

Möglichkeiten.

Statuslos, d.h. für Server muss bei jeder

Anfrage die Identität des Aufrufers neu ge-

klärt werden. Statuserhaltung ist Aufgabe

der Webseitenentwickler.

Statusbewusst. Lokale Instanz der Anwen-

dung hat genaue Informationen zum aktu-

ellen Zustand.

Nach Benutzerinteraktion in der Regel

vollständiger Seitenneuaufbau. Kurzzeiti-

ges Verschwinden der Seite.

Partielle Veränderung von Teilen der Ober-

�äche ohne Unterbrechung und/oder Ser-

veranfrage.

Nutzung nur �online�. Internetseite kann

nicht erreichbar sein

Allgemein auch ohne Internetverbindung

ausführbar.

Weitgehend standardisierte, einheitliche

und etablierte Techniken (z.B. (X)HTML,

CSS, PHP, JavaScript, XML).

Sehr vielfältige (häu�g auch standardisier-

te) Techniken, Vorgehensweisen und Me-

thoden.

Plattformunabhängig und ressourcenscho-

nend auf Clientseite.

Systemabhängig und ggf. gehobene An-

sprüche an Ressourcen (z.B. besondere

Hardwareanforderungen) auf Nutzerseite.

Server und Datenbank kontrollieren Da-

ten.

Lokaler Speicher für Daten unter Kontrolle

des Betriebssystems.

Eingeschränkte Möglichkeiten bei visueller

Gestaltung, Benutzerinteraktionen, Hard-

warekomponentennutzung des Clients.

Geregelter Zugang und Zugri� zu nahezu

allen Bereichen des Systems.

Keine direkte Kommunikation der Weban-

wendung zu anderen Internetseiten: server-

to-server über Netwerkprotokolle.

Kommunikation mit anderen Prozessen,

Anwendungen, Systemen über viele Kanä-

le möglich.

6


klassische HTML-Internetseite klassische Desktopanwendung

Gröÿere potentielle Erreichbarkeit von

Kunden.

Eingeschränkter Kundenkreis, abhängig

von System und Software.

Einfache Distribution der Software über

Seitenbesuch.

Vertriebsmöglichkeit durch Programmin-

stallation aus einer Datei, von CD/DVD

oder anderen portablen Quellen.

Tab. 2.1: Vergleich von Web- und Desktopanwendungen

Rich Internet Applications (RIAs) versuchen diese Lücke zu schlieÿen, indem eine Schnitt-

menge der zwei Anwendungsparadigmen gebildet wird. So sollen die Vorzüge beider Ansätze

vereint und jeweilige Nachteile ausgegrenzt werden.

Abb. 2.1: Einordnung der RIA-Technologie

Obwohl die ersten Ansätze des heutigen RIA-Gedankens schon ab 1996 bestanden1, dauer-

te es noch einige Jahre, bis die ersten Frameworks marktreif und für die Entwicklung von

anspruchsvollen Anwendungen interessant waren.

Schon 1996 versuchte Microsoft mit den ActiveX-Controls, Komponenten applikationsunab-

hängig zu machen, um diese beispielsweise im Internet Explorer zu nutzen. Die ActiveX-

Technologie scheiterte jedoch an Systemabhängigkeiten und Sicherheitsrisiken (Janowicz, 2006).

Andererseits erfreute sich Macromedia2 Flash als reiner Videoplayer ohne groÿe Interaktions-

möglichkeiten (Version 1 im Jahre 1997) wachsender Beliebtheit. Die Wiedergabe von beweg-

ten Flash-Inhalten steigerte die Fähigkeit Multimedia-Inhalte auf Internetseiten darzustellen.

Mit Version 4 des Flash-Players 1999 (Adobe, 2010) wurden Schleifen und bedingte Anwei-

sungen ermöglicht, welche grundlegende, minimal-interaktive Flash-Anwendungen zulieÿen.

Ein 2002 von Jeremy Allaire3 verö�entlichtes Whitepaper (Allaire, 2002) beschreibt erstmals

Anforderungen an Webapplikationen, die mit bisherigen Techniken nicht realisierbar waren1Damals noch mit anderen Namen und Zielen, z.B. Microsofts ActiveX (1996), Microsoft Remote Scripting

(1998) oder Forester Research: X Internet (2000)2Später Adobe3Chief Technology O�cer bei Adobe

7


und die zur Verö�entlichung von Adobe Flash �MX� (Version 6) führten � damals noch als

�next-generation rich Client� bezeichnet. Der folgende Auszug daraus beschreibt die Grundge-

danken des neuen Ansatzes, der bereits viele Aspekte der heute verfügbaren RIAs berücksich-

tigt.

Rich Client technologies should:

1. Provide an efficient, high-performance runtime for executing code, content andcommunications. (...)

2. Integrate content, communications, and application interfaces into a common en-vironment. (...)

3. Provide powerful and extensible object models and interactivity. (...)

4. Enable rapid application development through components and re-use. (...)

5. Enable the use of web and data services provided by application servers. (...)

6. Embrace connected and disconnected clients. (...)

7. Enable easy deployment on multiple platforms and devices. (...)

Flash MX 6 kann somit als erstes, ernstzunehmendes Framework zur Entwicklung von Rich

Internet Applications betrachtet werden, da mit dem Flash-Plugin im Browser nun einfache,

interaktive, jedoch von Skriptsprachen unabhängige Programme auf Internetseiten clientseitig

ausgeführt werden konnten.

2.1.1 Was sind RIAs? De�nitionsversuch und Merkmale

Eine allgemeingültige De�nition einer Rich Internet Application ist schwierig zu �nden, da ein

breites Spektrum der Nutzung möglich ist.4 Genauso wie für klassische Desktopanwendungen,

gilt auch für eine RIA, dass sie vom Benutzer angewendet wird, um eine gewisse Funktion zu

erreichen. Schon die wörtliche Übersetzung besagt, dass es sich um eine reichhaltige Internet-

Anwendung handelt, welche über die Möglichkeiten einer klassischen Internetseite (basierend

z.B. auf Skriptsprachen und statischen Inhalten) weit hinausgeht.

Die Identi�zierung einer RIA kann anhand verschiedener Merkmale erfolgen, die jedoch auch

zum Teil für klassische Desktopapplikationen und Webanwendungen typisch sind:

• Ein Ablauf im Browser macht die Anwendung theoretisch relativ plattformunabhän-

gig. Voraussetzung ist die Verfügbarkeit des RIA-Plugins für das System bzw. den Brow-

ser und eine Internetverbindung.4Selbst die Bezeichnung ist nicht unumstritten: Scott Barnes (Microsoft) spricht lieber von Rich Internet

Applications, während Ryan Stewart (Adobe) Rich Interactive Application vorzieht (vgl. o.A., 2007). BeideBegri�e bezeichnen aber das Selbe, wobei die Variante �Rich Internet Application� häu�ger verwendet wird.

8


• Es ist ein Browser-Plugin zur Ausführung nötig, aber es �ndet keine Installation der

spezi�schen RIA-Anwendung selbst auf dem Clientrechner statt.

• Es erfolgt kein Seitenneuaufbau nach einer Aktion (d.h. lokale Statuserhaltung) und

wenige kommunikations-bedingte Verzögerungen treten auf.

• Der Server hat nur eine unterstützende Rolle als Datenlieferant. Die Rechenlast

liegt beim Client. Für Nutzer ist die Serverkommunikation �unsichtbar� (auch ohne

aktiven Benutzerbefehl). So werden Serveranfragen durch häu�ge Seitenaufrufe stark

reduziert.

• RIAs nutzenKontrollelemente und Funktionen die aus Desktopapplikationen bekannt

sind z.B. Buttons, Listen. Menüs. Umfassende und gewohnte Bedienmöglichkeiten

(Drag and Drop, Tastaturbedienung) stehen dort zur Verfügung.

• Häu�g werden RIAs nach dem SOA-Ansatz (siehe Kapitel 2.2) entwickelt und es

entstehen damit modular gekapselte Serviceschichten.

• Entwickler können vorgefertigte Framework-Komponenten nutzen oder aus diesen

neue kreieren und somit funktional und graphisch anspruchsvolle Ideen umsetzen.

• �Richer user experience� , d.h. in der Regel native Unterstützung für Multimediawie-

dergabe und interaktive Verwendung der RIA.

• Eine Indexierung durch Suchmaschinen (z.B. für dynamische Inhalte) ist nur einge-

schränkt möglich. Dies kann natürlich auch positiv bewertet werden, falls nicht ö�entli-

che Daten enthalten sind.

• Identisches �look and feel� auf allen Systemen, da die Laufzeitumgebung unverändert

bleibt.

• Deploymentkosten und -aufwand sind durch zentrale Bereitstellung der Anwendung

auf einem Server reduziert. Neue Versionen stehen dem Nutzer bei Programmstart auto-

matisch zur Verfügung und manuelle Updates sind weitgehend unnötig. Nur das Plugin

selbst muss ggf. von Hand aktualisiert werden.

• Eingeschränkte Hardwarenutzung einer RIA auf dem ausführenden Rechner.

• Eingeschränkte Rechte der Anwendungen bzw. Ablauf in einer abgeschlossenen Um-

gebung (Sandbox).

(Vgl. Pfeil, 2009, S. 2)

Hinzuzufügen ist auch, dass RIAs relativ virenresistent, jedoch gegen bösartige Nutzung an-

fällig sind. Da die Anwendung isoliert von anderen Nutzern ausgeführt wird, ist das Potential

9


Abb. 2.2: Allgemeine Übersicht der Integration einer RIA

für einen Angri� auf den Client selbst niedriger. Bei solider Implementierung hat der Benut-

zer nur eine graphische Ober�äche und deren Funktionalität ohne �kritischen Code�. Daten

und die Sicherheitsrelevanten Programmanteile liegen auf Serverseite, welche in der Regel

durch umfassende Maÿnahmen geschützt sind. Weitere Aspekte zur Sicherheit (speziell von

Silverlight) werden in Kapitel 3.9 behandelt.

Eine technische Beschreibung der Gesamtarchitektur von Rich Internet Applications (speziell

Silverlight) wird in Kapitel 3 gegeben. Abbildung 2.2 gibt eine simple Übersicht, wie eine

RIA verö�entlicht ist. Die Anwendung selbst ist in einer Internetseite gekapselt und wird vom

Plugin im Browser ausgeführt. Über Netzwerkprotokolle steht die RIA mit einem Server in

Verbindung. Das Grundkonzept der hier beschriebenen Ebenen und Komponenten ist recht

allgemein und unterscheidet sich für die verschiedenen RIA-Frameworks meist nur geringfügig.

2.1.2 RIA-Frameworks

Neben Silverlight, dem hier ein eigenes Kapitel gewidmet ist, sind folgende alernative Platt-

formen und Frameworks zu nennen:

Adobe Flash/Air/Flex ist die bisher am weitesten verbreitete Technik, da es das älteste

aller Frameworks ist. Entwicklungssprache ist das objektorientierte ActionScript. Die Aus-

führung der Programme erfolgt mit dem Adobe Flash Player. Nutzbar ist Flash mittlerweile

mit den meisten Systemen (abgesehen von einigen mobilen Geräten). Mehrheitlich wird es

für Präsentation mit geringer Interaktion (z.B. reine Ersetzung von Websites ohne zusätzli-

che Funktionalität, dafür mit erweitertem optischen Eindruck), Werbung und Spiele benutzt.

�Echte� RIAs im Sinne eines Ersatzes von Desktopanwendungen sind relativ selten, da die

Vorteile von Flash in der Darstellung von bewegten Animationen und allgemein Multimedia

liegt. OpenLaszlo ging aus diesem Framework hervor und nutzt die gleichen Prinzipien, legt

10


aber Wert auf ein quello�enes Software Developement Kit.

JavaFX ist o�ziell seit Ende 2008 für Entwickler und Nutzer verfügbar. Es baut auf die Java

Technologie und deren Laufzeitumgebung auf und ist in der aktuellen Version 1.2 verfügbar

für Windows ab XP und Mac OS X (Version 10.5, nur Intel-Prozessoren). OpenSolaris und

Linux-Versionen be�nden sich im Beta-Status. Unterstützte Browser sind der Microsoft In-

ternet Explorer ab Version 6.0, Mozilla Firefox und Safari von Apple (jeweils ab Version 3).

Entwickelt werden die Anwendungen mit der deklarativen Sprache JavaFX Script und Java.

Kompiliert wird zunächst in bytecode, welcher dann beim Client mit der JRE ausgeführt wird

(bzw. als Java Web Start oder Java Applet). Vorteil dieses Frameworks ist die relativ weit

verbreitete Java-Umgebung.

Skriptbasierte Frameworks, die intensiv z.B. Ajax und JavaScript nutzen, ermöglichen auch

die Realisierung von RIAs. Beispiele hierfür sind das Google Web Toolkit, ZK, Google Gears

und Curl. Der Vorteil dieser Varianten besteht darin, dass keine zusätzliche Software nötig ist

(auÿer natürlich JavaScript unterstützende Browser). Nachteilig ist die geringe Performanz

und der hohe Entwicklungsaufwand bei komplexeren Anwendungen.

HTML5 ist zwar noch kein o�zieller Standard, ermöglicht aber eine umfangreichere Multi-

mediaeinbindung in Internetseiten als beim Vorgänger. Jedoch ist eine komplexe Interaktion

allein auf HTML5 beruhend nicht möglich. Der Fokus dieser Entwicklung liegt auf der Er-

weiterung der Multimediafähigkeiten von Internetseiten. Der Browser fungiert hier als Aus-

führungsumgebung und interpretiert den Code. Auch hier wird auÿer einem unterstützenden

Browser keine zusätzliche Software vorausgesetzt.

2.1.3 Kritik

Das Konzept der Rich Internet Applications hat zwar praktische und technische Vorteile,

jedoch fallen auch negative Faktoren auf, die den Einsatz einschränken oder � bei speziellen

Anforderungen � diesen auch fragwürdig erscheinen lassen. Nachteilige Punkte sind z.B.

• Zur Nutzung ist ein Plugin nötig. Dies erfordert einen (wenngleich geringen) Installati-

onsaufwand beim Benutzer und erzwingt eine Bindung an das Produkt. Vergleicht man

die Installation aber mit der einer klassischen Desktopanwendungen ist der Umfang zur

Nutzung der Software recht gering.

Für mobile Endgeräte kann das Plugin eine Hürde darstellen, da Hersteller dort häu�g

ein eigenes Betriebssystem verwenden, für das sie einen Kundensupport berücksichtigen

müssen, der Software von Fremdherstellern mit einschlieÿen muss. Zusätzlich sind durch

das Plugin neue Sicherheitslücken möglich.

11

2.2 Web Services und Service-orientierte Architekturen

• Es lassen sich keine neuen Anwendungsfenster auÿerhalb der RIA anzeigen. Alles spielt

sich innerhalb des Browsers ab.

• Die Laufzeitumgebung der RIAs führt ihre Anwendungen in der Regel in einem begrenz-

tem Umfeld (Sandbox, siehe Kapitel 3.9) aus, welche den Zugri� auf Systemressourcen

(z.B. Hardware- oder Programmzugri�e) stark einschränkt.

• Zum Start einer RIA muss JavaScript im Browser aktiviert sein.

• Die Ressourcenbelastung liegt beim Client und nur zu kleinem Teil auf dem Server. Oft-

mals sind im Vergleich zu klassischen Internetseiten erhöhte Anforderungen des Plugins

an die Rechnerleistung zu stellen. Nicht alle Anwender können diese Voraussetzungen

erfüllen.

• Die Ladezeit der umgebenden Internetseite ist vergröÿert, denn selbst simple Rich Inter-

net Applications sind relativ groÿe Dateien, die schnell einige hundert Kilobyte erreichen.

Eine Breitbandverbindung zum Internet ist daher sinnvoll.

• Die Indizierung von RIA-Inhalten durch Suchmaschinen ist bisher nicht vollständig mög-

lich, da die Anwendungen und ihre Inhalte von �auÿen� nicht zugreifbar sind. Lediglich

die umliegende Internetseite ist zugänglich. Für Silverlight existieren Möglichkeiten diese

Problematik zu korrigieren (siehe Shetty, 2009).

• Auf Entwicklerseite von RIAs ist ein herstellerspezi�scher initialer Lernaufwand der neu-

en Techniken nötig. Auch aktuelle Neuentwicklungen der Plugins, die sehr schnell voran-

getrieben werden, müssen im Auge behalten werden (vgl. den raschen Verö�entlichungs-

Rhythmus von Silverlight-Versionen in Abbildung 3.13).

• Die erstrebenswerte Standardisierung von Rich Internet Applications (z.B. durch das

W3C) ist nicht einfach, da viele Hersteller und Interessengruppen daran teilhaben.

• Dem Benutzer ist häu�g nicht klar, dass es sich bei einer RIA um eine im Browser

eingebettete Anwendung handelt, die gewisse Restriktionen oder eine veränderte Bedie-

nung mit sich bringt. Standardfunktionen wie das Anfertigen eines Ausdruckes oder das

setzen von Lesezeichen können hier zu Irritationen führen und eine gewissen Eingewöh-

nung erfordern. Bei der Entwicklung einer RIA sollte daher auf solche Aspekte geachtet

werden.


Eine Service-orientierte Architektur (oder service-oriented architecture, kurz SOA) ist eine dy-

namische Menge von abstrakten Designprinzipien einer verteilten Softwarearchitektur. Sie ist

12


nicht an bestimmte Technologien gebunden, sondern relativ plattform- und programmierspra-

chenunabhängig. Wichtigstes Merkmal ist das Service-orientierte Paradigma: es gibt Dienste

(Services) die spezi�sche Funktionen kapseln und implementieren. Dabei gilt:

„Alle Funktionen in einem realen System (...) lassen sich als Services darstellen undaus Services aufbauen.“ (Masak, 2007, S. 17)

Oder kürzer:

„Alles was aus- oder durchgeführt werden kann ist ein Service“. (Masak, 2007, S. 17)

Hierbei hat jeder Dienst mindestens einen Provider, der als Lieferant den Kunden oder Nut-

zern den Service anbietet. Auÿerdem gilt: die Funktionalität und die Randbedingungen eines

jeden Services sind vorab de�niert.

Die Dienste müssen also hinsichtlich aller Nutzungsaspekte hinreichend gut beschrieben sein,

damit sie sinnvoll verwendet werden können (funktionale Beschreibung). Daneben existiert

auch eine nichtfunktionale Beschreibung, die für die Suche und Entdeckung essentiell sein kön-

nen (z.B. Providername, Servicezeiten, Verfügbarkeit, Nutzungseinschränkungen etc.) Für bei-

de Beschreibungen stellen Web Services eine standardisierte Schnittstelle bereit (siehe WSDL,

Kapitel 2.2.2) um eine Kommunikation und Interaktion nach auÿen hin mit bestehenden Sys-

temen zu ermöglichen.

Eine SOA-Anwendung ist modular aus einzelnen, lose gekoppelten Diensten zusammenge-

setzt (orchestriert). Dies gewährleistet es im Optimalfall, �exibel auf mögliche Änderungen

des Marktes bzw. der Programmanforderungen zu reagieren, indem bestehende Dienste ande-

rer Anwendungen wiederverwendet oder ausgetauscht werden können. Daraus resultiert eine

leichte Wartung und damit verbunden eine Entwicklungs- und Kostenersparnis. Dies sind

wichtige Merkmale der SOA. Die verteilte Architektur ermöglicht es, ein weites Spektrum

an Plattformen und Systemen miteinander zu verbinden, ohne dabei groÿe Anpassungen an

Altsystemen vorzunehmen. Für webbasierte Anwendungen kann dies ein erheblicher Vorteil

sein. In diesem Bereich gehören Web Services zum Fundament datengetriebender Dienste und

Anwendungen. (Vgl. Papazoglou, 2007, S. 253�)

EinWeb Service ist ein über ein Netzwerk bereitgestelltes, selbstbeschreibendes Softwaremo-

dul, welches auf Anweisung anderer Applikationen hin Aufgaben erledigt, Probleme löst oder

Transaktionen ausführt. Da ein solcher Dienst auf automatisierte Anfragen ausgerichtet ist,

wird er fast ausschlieÿlich als Kommunikationspartner von Maschinen verwendet. Der Aufruf

geht zwar von einer Interaktion des Nutzers aus, jedoch wird die Anfrage stets vom System

getätigt � beispielsweise in einer optimierten und standardisierten Form.

13


Dabei bauen Web Services auf den XML-Standard auf und verwenden weitere Technologien

wie SOAP, WSDL und UDDI, die in den folgenden Kapiteln behandelt werden. Die Diens-

te sind aufgrund ihres Ursprungs im Bereich der Webanwendung zustandslos und erfüllen

letztendlich stets den Zweck eines Datenaustauschs. Dadurch kann leicht eine lose Kopplung

(siehe S. 78) erreicht werden, was eine Wiederverwendbarkeit des Dienstes ermöglicht. Ein

Service kann zudem synchron oder asynchron implementiert werden und unterstützt i.d.R.

auch Fehlermeldungen. Als de facto-Standard sind die Kommunikationsprotokolle HTTP(S),

SMTP und FTP am weitesten verbreitet, da diese Protokolle von nahezu allen Systemen un-

terstützt werden und das Kon�iktpotential mit einer Firewall sehr niedrig ist. Es ist aber zu

beachten, dass die Leistungsfähigkeit dieser Übertragungsart geringer ist, als bei binären Pro-

tokollen5, welche einen höheren Verarbeitungsaufwand benötigen (z.B. durch Analysierungs-

und Umwandlungsprozesse der empfangenen Antwortdokumente zum Herauslösen der darin

enthaltenen Informationen).

Um einen Web Service zu Realisieren, werden zwei wichtige Komponenten benötigt: eine

Schnittstellenbeschreibung und die Funktionsimplementierung selbst. Der Konsument des

Dienstes benötigt für den Nachrichtenaustausch die standardisierte Schnittstelle, welche die

konkrete Implementierung des Services verbirgt.

Zur Nutzung eines Web Services sind zusammengefasst mehrere Schritte notwendig, welche

in Abbildung 2.3 aufgeführt sind.

Abb. 2.3: Das Prinzip der Web Services (Quelle: nach Martin, 2009)

5Beispielsweise ist HTTP in den oberen ISO/OSI-Schichten angesiedelt ist.

14


Die Schritte, welche nötig sind um einen Web Service zu verwenden, könnten etwa wie folgt

ablaufen:

1. Der Verfasser eines Dienstes verö�entlicht eine Beschreibung seines Web Services in

einem Verzeichnisdienst.

2. Ein Konsument sucht dort nach seinen Wünschen entsprechenden, potentiellen Diensten.

3. Das Diensteverzeichnis liefert eine Referenz (URI) auf das WSDL-Dokument des Diens-

tes auf dem Server/Provider des Anbieters.

4. Der Konsument fordert die Schnittstellenbeschreibung beim Anbieter an.

5. Der Dienstnutzer kann aufgrund des WSDL-Dokuments eine spezi�sche Anfrage an den

bereitgestellten Web Service senden.

Im Folgenden sollen die wichtigsten Komponenten der Web Services näher beleuchtet werden.

2.2.1 Verzeichnisdienste

Der Verfasser eines Web Services stellt die zugehörige Beschreibung einem Verzeichnisdienst

zur Verfügung. Diese sind Kataloge, welche Referenzen zu verschiedensten Diensten sammeln

und anbieten. Die am weitesten verbreiteten Abfragesprachen zur Interaktion mit diesen sind

UDDI (Universal Description, Discovery and Integration) und dieWeb Service Inspection Lan-

guage (WS-Inspection). Eingebunden in eine Service-orientierte Architektur ermöglichen es

Verzeichnisdienste, dynamisch lose gekoppelte Dienste zu orchestrieren und damit die SOA-

Landschaft zu füllen. Ö�entliche Verzeichnisse werden jedoch kaum noch genutzt, da Unter-

nehmen ihre Dienste meist nur intern anbieten und häu�g essentielle Informationen z.B. zur

Qualität des Dienstes oder zur Verfügbarkeit fehlen. (Vgl. Papazoglou, 2007, S. 177�))

2.2.2 WSDL

Die Web Service Description Language (WSDL) ist eine XML-basierte Sprache welche Adres-

se, Funktion und Benutzung des Dienstes darlegt. Sie ermöglicht die funktionale und nicht-

funktionale Beschreibung. In einer abstrakten Schnittstellenbeschreibung werden verwendete

Datentypen, Operationen und Nachrichten angegeben, die der Web Service unterstützt. Da-

neben werden in der konkreten Schnittstellenbeschreibung die zuvor de�nierten Operationen

auf real existierende Operationen referenziert. Die WSDL enthält weder Quality-of-Service

Informationen (Dienstgüte) noch Taxonomien (Klassi�zierung, Katalogisierung). Da solche

15


Daten aber vor allem in betrieblichem Umfeld häu�g vorausgesetzt werden, existieren einige

Zusatz-Spezi�kationen � die Web Service Erweiterungen � mit deren Hilfe die geforderten

Ansprüche realisiert werden können (z.B. WS-Security oder WS-Policy). Der W3C-Status zur

aktuellen WSDL Version 2.0 ist der einer Empfehlung (W3C Recommendation). Häu�g wird

jedoch Version 1.1 verwendet. (Vgl. Papazoglou, 2007, S. 147�)

2.2.3 SOAP

Das Simple Object Access Protocoll (SOAP) ist ein XML-basiertes Protokoll um Informationen

zwischen Web Services auszutauschen. SOAP Nachrichten bestehen aus:

Envelope: Umschlag, der die nächsten beiden Teile enthält und eine Nachricht von anderen

abgrenzt. Er de�niert zudem die verwendete SOAP-Spezi�kation.

Header: Der optionale Kopfteil der Nachricht enthält weitere ergänzende Nachrichtenspezi-

�sche Daten (z.B. Sicherheits- oder Strategierichtlinien).

Body: Enthält die eigentlichen Daten (message payload) im wohlgeformten XML Format

(Erklärung dazu in der Fuÿnote auf S. 27), d.h. alles was sich als XML-Dokument

abbilden lässt, kann in einer Nachricht übermittelt werden. Beispielsweise lassen sich

Variablen und Objekte durch eine hierarchischen Baumstruktur repräsentieren (siehe

Kapitel 6.5).

Das Übertragungsprotoll ist dabei frei wählbar, jedoch meist HTTP. SOAP unterstützt auch

Fehlernachrichten mit Fehlerdaten. Das Protokoll kann jedoch nicht den eigentlichen Web

Services aktivieren, denn dieser wartet immer auf Anfragen. Auch können weder Nachrichten

gruppiert werden, noch ist eine Referenzierung von Objekten möglich. Ein Transport von

Teilobjekten ist ausgeschlossen.

Eine Kommunikationsvariante von SOAP ist der Extensible Markup Language Remote Procedu-

re Call (XML-RPC). XML-RPC ist strukturell simpel aufgebaut und damit relativ schnell zu

verstehen, lässt aber nur eine synchrone Übermittlung zu. Alternativ kann der sog. document-

style verwendet werden, welcher wohlgeformte XML-Dokumente nach festem Schema de�niert.

Hier ist auch eine asynchrone Übertragung möglich, da durch Identi�zierer Antworten eindeu-

tige zu Anfragen zugeordnet werden können. (Vgl. Papazoglou, 2007, S. 119�))

2.2.4 REST

Representational State Transfer (REST) ist ein Architekturstil für verteilte Informationssys-

teme wie das Internet. Es ermöglicht, jede Ressource des Dienstes mit einer eigenen URL

16


über HTTP zu adressieren. Dies stellt sicher, dass auf einfache, standardisierte Art für ei-

ne Vielzahl von Clientsystemen ein Web Service zur Verfügung gestellt werden kann, ohne

eine Transportschicht wie SOAP nutzen zu müssen. Ein REST-konformer Service (RESTful

Service) ist zustandslos. Die übermittelte HTTP-Botschaft enthält alle semantischen Informa-

tionen zur Einordnung einer Nachricht. Das Antwortdokument ist üblicherweise eine einfache

XML-basierte Struktur, JSON und/oder ein HTML-Dokument Desweiteren können wohlde�-

nierte Operationen auf die bereitgestellten Ressourcen angewendet werden:

GET fordert die angegebene Information vom Server an,

PUT setzt oder ändert eine gegebene Ressource auf dem Server,

POST fügt neue Daten zu einer Information hinzu,

DELETE dient zum Löschen von Daten.

REST ist aufgrund der zu Grunde liegenden Struktur und Anwendungsweise als Rückbesin-

nung auf ursprüngliche Ansätze einer einfachen, weiträumig nutzbaren Kommunikationsinfra-

struktur im Internet zu sehen. (Vgl. Scribner & Seely, 2009, S. 2f)

2.2.5 WCF RIA Services

Microsoft bietet (insbesondere zur Entwicklung von RIAs) die Windows Communication Foun-

dation Rich Internet Applications Services (kurz WCF RIA Services) für Systeme in einer

.NET integrierten Umgebung an. Dieses Framework deckt die Kommunikationsschicht einer

Anwendung (mid-tier) ab und bietet umfassende Möglichkeiten der Datenkontrolle, Daten-

änderung und Datensteuerung. Sie soll vor allem die Entwicklungszeit von Silverlight- und

ASP.NET Programmen verkürzen, indem schnell und e�zient Code für datengetriebene An-

wendungen erzeugt und verwendet werden kann. Beispielsweise generieren die Dienste aus

ausgewählten Entities einer Datenbank alle Datenobjektklassen sowie den Kommunikations-

code auf Server- und Clientseite. Die WCF RIA Services halten dabei sowohl den nötigen

Programmode in der Präsentationsschicht, als auch in der Applikationslogik aktuell, sobald

sich an der Kommunikationsinfrastruktur eine Komponente ändert, indem sie die genutzten

Entity-Mengen überwachen und aktiv werden. (Vgl. Wahlin, 2010)

Durch die solide Integration in bestehende Microsoft-Umgebungen (ASP.NET, Silverlight,

SQL-Server) verkürzt sich der Entwicklungsaufwand von Internetanwendungen, da viele wie-

derkehrende Elemente wie z.B. die Authenti�zierung, Datenvalidierung und Sicherheitsaspekte

bereits automatisch unterstützt werden. Das Framework ist zudem in hohem Maÿe in Visual

Studio integriert. Es bringt Projektvorlagen mit, die ein Grundgerüst für line-of-business-

Anwendungen in Silverlight bilden können. Diese Vorlagen besitzen schon von Beginn an

17


Funktionen und Inhalte wie z.B. komfortable Navigationsstrukturen, Benutzerlogin und diver-

se UI-Ober�ächen (Views). Vieles kann mit der Maus über Assistenten und Menüs geändert

werden, ohne selbst Programmcode anzupassen. (Vgl. Microsoft, 2010c)

2.2.6 Zusammenfassung

Eine Service-orientierte Architektur hat das Potential, groÿe Entwicklungs- und Wettbewerbs-

vorteile zu erzeugen. Sie kann jedoch nicht alle Probleme lösen und bedarf einer sorgfältigen

Planung und Ausführung. Web Services bilden das Fundament einer verteilten Architektur �

insbesondere im Bereich der Webapplikationen.

Die Technologie der Web Services ist aufgrund ihrer Flexibilität und normierten Benutzung

bestens für die Realisierung einer SOA geeignet, denn sie vereinfacht die Kommunikation zwi-

schen verschiedenen Systemen und beruht auf anerkannten sowie weit verbreiteten Standards

des W3C. Auch RIAs passen sehr gut in dieses Konzept. Bedingt durch den Ablauf im Brow-

ser und den damit verbundenen eingeschränkten Rechten einer RIA auf dem Nutzersystem,

wird ein zentraler Server zur Datenhaltung und Datenkommunikation benötigt. Dieser muss

Schnittstellen und Funktionen anbieten, um den Anforderungen verschiedenster Applikationen

Genüge zu tun.

18

Kapitel 3

Microsoft Silverlight

Silverlight ist ein Framework zur Erstellung von .NET-basierten und in Internetseiten inte-

grierten Rich Internet Applications. Auch zur Ausführung einer Silverlightanwendung wird ein

Browser-Plugin benötigt, welches das Programm in einem Container innerhalb der Internetsei-

te startet und zeichnet. Wie andere RIA-Frameworks auch, bietet das Plugin umfangreichere

Möglichkeiten als HTML oder JavaScript an. Dabei bringt Silverlight mit .NET eine ausge-

reifte, mächtige und weit verbreitete Programmierplattform mit, die es erlaubt clientseitigen

Code in C# oder VisualBasic zu schreiben. Das Framework ist nicht nur eine Ober�äche

um reichhaltige, interaktive Inhalte im Web zu präsentieren. Es bietet auch das Potential, zur

Entwicklung von diversi�zierten, plattformübergreifenden, in Netzwerke eingebundene Anwen-

dungen, die ihre Daten und Services aus verschiedenen Quellen beziehen (Microsoft, 2010b).

Das Silverlight-Framework bildet eine reduzierte und speziell auf die Bedürfnisse einer RIA

angepasste Teilmenge der Windows Presentation Foundation (WPF) ab. Die WPF und Sil-

verlight beruhen auf gleichen Architekturen und stellen ähnliche Techniken, Funktionen und

Eigenschaften bereit. Beispielsweise wird die Benutzerober�äche einer Silverlightanwendung

ebenfalls durch XAML (Kapitel 3.4) beschrieben, während prozeduraler, objektorientierter

Code in sog. Code-Behind-Dateien für die nötige Funktionalität sorgt. Dabei begrenzt Silver-

light jedoch die Entwicklung, indem bestimmte Komponenten der windows-basierten WPF

darin (aus Leistungs-, Kompatibilitäts- und Ausführungsgründen) für den Entwickler nicht

zur Verfügung stehen.

Die im Plugin enthaltene Silverlight Laufzeitumgebung ist eine reduzierte Version der .NET

Common Language Runtime (CLR), welche u.a. essentielle Kernklassen, garbage collection

sowie Unterstützung für Generics und Threading mitbringt. Die angepasste CLR ist insbeson-

dere daraufhin entwickelt worden, eine kompakte Form der .NET-Umgebung zu repräsentieren

und die Programme schnell und e�zient auszuführen. Das Silverlight-Plugin ist beim Down-

19

load nur sechs Megabyte groÿ.1

Die Einschränkungen, die Silverlight inhaltlich mit sich bringt, beziehen sich z.B. auf fehlen-

de ADO.NET-Klassen, ein nur in Ansätzen bestehendes Modell für Commands, reduzierte

Funktionalität der Trigger (siehe Kapitel 3.5.3 bzw. S. 38) und eine geringere Menge bereit-

gestellter Controls (wie baumartige Strukturen oder Kontextmenüs) als die WPF. Microsoft

versäumte es jedoch nicht, die wichtigsten Grundlagen zur Erstellung eigener Komponenten

mit einzubeziehen, sodass die Entwickler benötigte Programmteile selbst realisieren können.

Daneben stellen Unternehmen und Programmierer aus aller Welt ihre eigens entwickelten

Silverlight-Klassen zur Verfügung � nicht zuletzt aus wirtschaftlichen Interessen. Ein Beispiel

wäre IBM ILOG Gantt for .NET.

Eine detaillierte Di�erenzierung der beiden Modelle würde hier den Rahmen sprengen, wes-

halb auf (Wintellect, 2009) verwiesen wird. Tabelle 3.1 stellt jedoch kurz die wichtigsten

Di�erenzen dar.

Silverlight WPF

Webbasiert Desktop-Anwendung

Auch auf nicht-Windows Betriebssyste-

men ausführbar

Benötigt Microsoft Windows ab XP

mit.NET-Laufzeitumgebung

Unterstützt gängigste Browser für Win-

dows und Mac

XBAP-Anwendungen2 arbeiten nur im In-

ternet Explorer

Plugin benötigt .NET-Laufzeitumgebung benötigt

XAML als Beschreibungssprache der Be-

nutzerober�äche enthält reduzierte Menge

an Elementen

XAML hat Zugri� auf groÿe Control-

Bibliothek

Zur Wiedergabe von Medien wird keine zu-

sätzliche Software benötigt

Medienwiedergabe erfordert Installtion

des Windows Media Players

Tab. 3.1: Vergleich von Silverlight und WPF (Nach: Wildermuth, 2007, S. 19))

Die im Jahre 2007 verö�entlichte Version 1 von Silverlight basierte noch in vollen Umfang

auf JavaScript und war nicht in die .NET-Umgebung integriert, sodass die Möglichkeiten der

Entwicklung auf einfache skriptbasierte Anwendungen mit wenigen Animationen und multi-

medialen Fähigkeiten sehr beschränkt war.

Aus diesem Grunde folgte bereits ein knappes Jahr später die zweite Version, welche nun

durch die Integration in .NET, die Einführung von XAML zur Ober�ächenbeschreibung so-

wie der common language runtime (CLR) und erweiterten Funktionen zur Medienwiedergabe

dramatische Veränderungen in den Möglichkeiten mit sich brachte. Silverlight war mit diesem

1Zum Vergleich: die volle Standard-.NET Laufzeitumgebung hat einen Umfang von rund 48 MB2Eine XAML Browser Application (XBAP) ist eine WPF-Anwendung, die über das Web geladen und vom

Browser gestartet wird. Auch hier wird auf dem Client eine installierte .NET-Laufzeitumgebung benötigt.

20

3.1 Das Silverlight Plugin

Schritt zu einem relativ mächtigen Werkzeug im Gegensatz zu rein scriptbasierten Frame-

works geworden.

Mitte 2009 brachte Microsoft Version 3 auf den Markt, welche wiederum mit erweitertem Funk-

tionsumfang aufwartete. Beispielsweise wurde dort das Konzept der out-of-browser-Applications

eingeführt, mit dem es möglich wurde, Silverlightanwendungen auch ohne geö�neten Browser

zu starten (ähnlich einer klassischen Desktopanwendung). Zahlreiche weitere Features weck-

ten so das Interesse vieler Entwickler.

Daher ist es nicht verwunderlich, dass Microsoft die Entwicklung des Frameworks schnell vor-

antreibt, denn der rasch fortschreitende Markt der RIAs ist in den Augen Vieler die Zukunft

des Internets, da sie versuchen, vermeintliche Schwächen klassischer Internetanwendungen zu

korrigieren. Weniger als ein Jahr später erschien im April 2010, gleichzeitig mit .NET 4.0

Silverlight in Version 4. Neue Funktionen, die dort hinzukamen, sind u.a. eine lang erwartete

Druckfunktion, Kontextmenüs über die rechte Maustaste, Kompatibilität mit sog. multitouch-

Eingabegeräten, Webcam- und Mikrofonunterstützung sowie Verbesserungen der allgemeinen

Leistungsfähigkeit.

Jede neu verö�entlichte Silverlight-Version rückte funktional näher an die Windows Presenta-

tion Foundation. Allerdings bleibt zu beachten, dass Silverlight ein browserbasiertes Plugin

bleibt und somit stets im Umfang (zu .NET) reduziert sein wird.

Die Abwärtskompatibilität der Versionen ist ab Silverlight 3 stets gegeben.

3.1 Das Silverlight Plugin

Das zur Ausführung von Silverlightanwendungen benötigte Plugin steht als kostenloser Down-

load bei Microsoft zur Verfügung. Lädt ein Anwender eine Seite, die das Plugin benötigt,

erhält der Nutzer den Link zum Herunterladen der Installationsdatei. Wird diese anschlie-

ÿend ausgeführt und der Browser neu gestartet, lässt sich das besuchte Silverlightprogramm

direkt verwenden.

Abbildung 3.1 zeigt die von den unterschiedlichen Silverlightversionen unterstützten Brow-

ser und Betriebssysteme. Ein �X� kennzeichnet nicht verwendbare Kon�gurationen. Die mi-

nimalen Hardwareanforderungen sind wie folgt: x86 oder x64 Prozessor mit 500 MHz und

Unterstützung für SSE-Instruktionen, sowie 128 MB Arbeitsspeicher.

Für Linux- und FreeBSD-Systeme entwickelt das Communityprojekt �Moonlight� (ein Teil

des Mono Projects3) in Zusammenarbeit mit Microsoft und Novell eine .NET-Laufzeit- und

Entwicklungsumgebung und das Silverlightplugin für Unix-basierte Rechner. Moonlight ist

derzeit kompatibel mit Silverlight 2 und soll im Laufe des Jahres 2010 auch Anwendungen für

3http://www.mono-project.com/Moonlight

21

3.2 Architektur, Browserintegration und Deployment

Abb. 3.1: Silverlight Kompatibilitätsmatrix (Quelle nach: (Tesar, 2009, S. 8) und (Wikipedia.org,2010))

Silverlight 3 ermöglichen. Der Browser Opera wird derzeit nur ino�ziell unterstützt, soll aber,

neben weiteren Plattformen in zukunftigen Silverlightversionen, ebenfalls integriert werden.

Zudem ist eine Portierung des Plugins auf mobile Endgeräte (Mobiltelefone, Tablet PCs)

geplant. Windows Phone 7 nutzt Silverlight bereits genauso, wie Nokias Betriebssystem Sym-

bian für die herstellereigenen Smartphones (Virki, 2008). Eine Portierung auf die Android-

Plattform ist wahrscheinlich (vgl. Foley, 2010). Ob Apple die mobilen Produkte iPhone und

iPad für Rich Internet Applications wie Flash und Silverlight ö�net oder in naher Zukunft

auf HTML5 setzt, ist zur Zeit fraglich (can/AP/apn, 2010).


Microsoft Silverlight setzt die mehrschichtige Architektur der Windows Presentation Founda-

tion fort, indem die graphische Benutzerober�äche von der Logik getrennt wird. Die daraus

resultierenden Schichten erlauben eine bessere Kapselung der Komponenten, als es beispiels-

weise bei klassischen Windows-Forms-Anwendungen der Fall war.

Abb. 3.2: Vereinfachte Silverlight-Architektur

22


Die sog. visuelle Ebene umfasst die Benutzerober�äche mit der der Nutzer interagiert und kom-

muniziert. Sie wird durch die deklarative Beschreibungssprache XAML (siehe Kapitel 3.4) er-

zeugt und beinhaltet keinerlei oder nur geringe Anteile der Funktionalität und Programmlogik.

Diese be�ndet sich hauptsächlich in prozeduralen, C#- oder VisualBasic-basierten Codedatei-

en (sog. Code-Behind-Dateien, siehe Kapitel 3.5), welche die funktionelle Logik implementie-

ren. Abbildung 3.2 verdeutlicht diesen Zusammenhang modellhaft.

Silverlight verwendet zwei Programmiermodelle: Die JavaScript API und den des managed

code für .NET. Erstere ist verantwortlich für die Integration der Applikation in den Browser

bzw. die Internetseite und den initialen Programmstart. Die managed code-API ist wiederum

Teilmenge des .NET-Frameworks und verwaltet durch die CLR u.a. die Code-Behind-Dateien.

Die Kernkomponenten der Silverlight Plattform werden in Tabelle 3.2 beschrieben. Neben

den zwei auf der managed code API beruhenden Hauptbestandteilen existiert zusätzlich der

JavaScript-basierte Installer und Updater.

Komponente Beschreibung

core-presentation-

framework

Komponenten und Funktionen der Benutzerober�äche, inklusi-

ve XAML, Verarbeitung der Benutzereingabe, Medienwiederga-

be, Vektorgraphiken, Texte, Animationen, Digital Rights Mana-

gement (DRM), Data Binding usw.

.NET-Framework für

Silverlight

Teilmenge des .NET-Frameworks mit Bibliotheken und Klassen

für Datenintegration, Netzwerkbasisklassen, uvm. Die CLR ist

ebenso Teil dieser Kompononente.

Installer & Updater Eine JavaScript-Logik zur vereinfachten Installation bzw. auto-

matischen Aktualisierung des Silverlightplugins oder der Silver-

lightanwendungungen.

Tab. 3.2: Kernkomponenten der Silverlight Plattform (Quelle: Microsoft, 2010b)

Abbildung 3.3 zeigt wie die beschriebenen Komponenten in die Silverlight-Architektur einge-

bettet sind. Auf die übrigen Details der Abbildung soll nicht näher eingegangen werden, um

den Rahmen dieser Bachelorarbeit nicht zu sprengen.

Wie zuvor bereits beschrieben, basiert die Silverlight-Laufzeitumgebung auf einer reduzierten

Form der .NET-Plattform und nutzt ähnliche Kernklassen und Bibliotheken wie die WPF.

Das Silverlightplugin bündelt diese Komponenten und bindet sie in eine Browserumgebung

ein. Dort arbeitet es in einem abgeschlossenen Bereich mit restriktiven Sicherheits- und Sys-

temzugri�seigenschaften, der Sandbox.

Diese limitierte Umgebung schränkt die Silverlightanwendung insofern ein, dass sie bestimm-

te Rechte, die klassische Desktop-Applikationen besitzen können, nicht gewährt. So darf das

23


Abb. 3.3: Übersicht der Silverlight Architektur (Quelle: Microsoft, 2010b))

Programm beispielsweise weder beliebig Datenträger beschreiben und lesen, noch erhält es

Zugri� auf bestimmte Funktionen die etwa das Betriebssystem anbietet (Nutzerkonten, Sys-

temvariabeln, etc.). Eine genauere Beschreibung der Sandbox erfolgt in Kapitel 3.9.

Um dennoch Daten ablegen zu können, wird jeder im Plugin ausgeführten Anwendung ein

virtueller, begrenzter Bereich der Festplatte zugeordnet (Isolated Storage), wo nur dieses Pro-

gramm Zugri� hat. Neben einer Verbindung zu einem Web Service und dem Isolated Storage,

ist die einzige Möglichkeit für eine Silverlightanwendung, Dateien auÿerhalb der Sandbox zu

Laden oder Speichern über einen Benutzerdialog, wobei eine Interaktion des Anwenders (und

somit eine gewisse Kontrolle) statt�ndet.

Eine Silverlightanwendung kann, nachdem sie kompiliert und in einer komprimierten, vom

Plugin extrahier- und ausführbaren XAP-Datei4 vorliegt, auf einer HTML-Internetseite ver-

ö�entlicht werden. Dazu wird in einem <object>-Tag u.a. der Typ

type="application/x-silverlight-2" sowie die XAP-Datei als Quelle in einem weiteren Pa-

rameter <param name="source" value="ClientBin/MySilverlightApp.xap"/> angegeben.

Andere, im <object>-Tag de�nierte Angaben beziehen sich z.B. auf die Gröÿe des Silverlight-

4Der Server muss diesen Datentyp zulassen.

24


containers im Browserfenster oder die Update-Adresse bei Microsoft für das Plugin selbst.

Listing 3.1 demonstriert eine Verö�entlichung der Silverlightanwendung �MySilverlightApp�

auf einer Internetseite. In der Regel wird der dortige Quelltext von der Entwicklungsumge-

bung erzeugt und muss nur geringfügig manuell kon�guriert werden. Näheres zum Deployment

erläutert Kapitel 7.4.

1 <object data="data:application/x-silverlight -2," type="application/x-silverlight -2"

width="100%" height="100%">

2 <param name="source" value="ClientBin/MySilverlightApp.xap"/>

3 <param name="onError" value="onSilverlightError" />

4 <param name="background" value="white" />

5 <param name="minRuntimeVersion" value="4.0.50401.0" />

6 <param name="autoUpgrade" value="true" />

7 <a href="http ://go.microsoft.com/fwlink /? LinkID =149156&v=4.0.50401.0" style="text -

decoration:none">

8 <img src="http ://go.microsoft.com/fwlink /? LinkId =161376" alt="Get Microsoft

Silverlight" style="border -style:none"/>

9 </a>

10 </object >

Listing 3.1: Deployment einer Silverlightanwendung in einer HTML-Internetseite

Abbildung 3.4 verdeutlicht den Sachverhalt auf einer höheren Ebene sowie die Verknüpfun-

gen der verschiedenen Systeme und Komponenten untereinander. Das im Browser ablaufende

Silverlight Plugin lädt auf dem Anwendungsrechner das eigentliche Programm (zusammenge-

fasst in der XAP-Datei) vom Server. Dieser beherbergt die Silverlightanwendung an sich und

leitet Anfragen der RIA (etwa an Datenbanken) weiter.

Abb. 3.4: Übersicht zum Deployment einer Silverlightanwendung

Das Plugin selbst wird mit JavaScript gestartet5. Ebenso überprüft die weiter oben im <head>

eingebundene Datei Silverlight.js die Verfügbarkeit des Silverlightplugins, bzw. fordert zu

5Durch eine Anpassung des JavaScript-Codes und unter Nutzung der Application-Klasse von Silverlight mitihren Events, kann beispielsweise ein individueller Ladebildschirm implementiert werden (MacDonald, 2009,S. 192�).

25

3.3 Entwicklungsumgebungen und SDKs

dessen Installation auf, falls es noch nicht vorhanden ist. Scheitert eine Silverlightanwendung

an einem internen Fehler, wird dieser gleichfalls durch eine JavaScript-Routine onSilverligh-

tError an die Fehlerkonsole des Browsers weitergeleitet (siehe auch <object>-Parameter des

Silverlight-Containers).

Eine detaillierte Beschreibung der Möglichkeiten und Vorgänge des Deployment �ndet sich

beispielsweise bei (Tesar, 2009) oder (MacDonald, 2009).

Über die JavaScript API der Silverlight Plattform ist auch eine durch managed code gesteu-

erte dynamische Generierung von DOM-Objekten des Browsers möglich, sodass eine Silver-

lightanwendung auch auf die HTML-Elemente der umschlieÿenden Seite zugreifen und diese

manipulieren kann.

In der Regel ist eine Entwicklungsumgebung für die Generierung des <object>-Elements und

der JavaScript-Dateien verantwortlich, sodass die Programmierer dies nicht manuell erledigen

müssen.

3.3 Entwicklungsumgebungen und SDKs

Wie bei anderen Bereichen der Softwareentwicklung ist eine Entwicklungsumgebung (IDE)

zwar nicht nötig, jedoch aus E�zienzgründen sehr zu empfehlen, da von dieser häu�g wie-

derkehrende Aufgaben und Funktionen übernommen werden, die den Entwicklungsalltag er-

leichtern. Für Silverlight und .NET allgemein ist Microsoft Visual Studio eine weit verbreitete

IDE, die maÿgeblich zur Produktivität (nicht nur) der Programmierer erhöht.

Um eine Silverlight 4 Anwendung zu implementieren, werden folgende Komponenten von

Microsoft zur Verfügung gestellt:

• Microsoft Silverlight 4 Tools für Visual Studio 2010 stellt Vorlagen und Addons für

die Entwicklungsumgebung sowie nötige Bibliotheken bereit. Ohne dieses Paket ist die

Entwicklung von Silverlightanwendungen nicht möglich.

• Das Microsoft Silverlight 4 SDK enthält Onlinedokumentationen, Onlinebeispiele,

Bibliotheken und Tools für die Entwicklung. Diese Komponente wird von den Silverlight

4 Tools ebenfalls installiert.

• Das optionale Paket Silverlight 4 Toolkit bringt zusätzliche, den Funktionsumfang der

Standardinstallation vergröÿernden Funktionen und Klassen mit (z.B. neue Controls).

• Expression Blend 4 RC ist ein XAML-Editor und Werkzeug zur Gestaltung der

Anwendungsober�äche von Silverlight und WPF-Anwendungen.

26

3.4 Visuelle Schicht: XAML

Expression Blend erleichtert dabei vor allem den GUI-Designern die Arbeit, indem sie � un-

terstützt durch die IDE � die Ober�äche der Anwendung entwerfen und realisieren. Dazu ist

es den Gestaltern überlassen, ob sie direkt XAML-Code schreiben oder ob sie das Werkzeug

die nötigen Codefragmente generieren lassen. Expression Blend lässt sich nahezu vollständig

ohne Programmierkenntnisse (in XAML oder C#) bedienen.


Die Extensible Application Markup Language (XAML) ist � wie der Name schon andeutet � ei-

ne wohlgeformte6, XML-basierte Beschreibungssprache zur Ober�ächengestaltung von WPF-

oder Silverlightanwendungen. Eingeführt in .NET Version 3.0 etablierte sich XAML schnell

als Nachfolgemodell zu der bis dahin üblichen Herangehensweise der GUI-Erstellung über pro-

zeduralen Programmcode in C# (bzw. C/C++). Diese Art der Trennung von Benutzerober�ä-

chendesign und -logik bringt einige Vorteile mit sich. Dennoch ist eine reine C#-Realisierung

einer Ober�äche weiterhin möglich, da XAML lediglich ein Format zur Serialisierung von Ob-

jekten ist (Huber, 2008, S. 143). Zur Laufzeit werden aus den dort angegebenen Elementen

.NET-Objekte erzeugt.

Im traditionellen Entwicklungsprozess wird häu�g schon zu Beginn das äuÿere Erscheinungs-

bild einer Anwendung entworfen. Dies ist in der Regel Aufgabe eines oder mehrerer Designer

mit gestalterischen Kenntnissen zur Verbesserung der �user-experience� (UX-Design). Ist die-

se Arbeit abgeschlossen, wird das Ergebnis den Programmentwicklern meist in Form einer

Bilddatei übergeben, welche die GUI nach diesem Entwurf realisieren. Sie erledigen also im

Grunde nochmals die Arbeit der gestalterischen Abteilung, wobei es häu�g zu Kon�ikten oder

Abweichungen kommen kann (insbesondere bei visuell komplexen Anwendungen).

XAML bietet hier einen Lösungsansatz, indem sich beide Gruppen ein gemeinsames Aus-

tauschformat teilen. Die Benutzerober�äche wird weiterhin vom Team der GUI-Entwickler

mit Designwerkzeugen (Kapitel 3.3, Expression Blend) entworfen, das Ergebnis jedoch dann

in XAML exportiert. Sie stellen den Entwicklern das Frontend zur Verfügung, welche es dann

mit der nötigen Funktionalität und Logik versehen. Dieser Arbeiten können natürlich auch in

umgekehrter Reihenfolge oder parallelisiert durchgeführt werden.

Die durch die Trennung von visueller und logischer Schicht mit XAML weiter entstehenden

Vorteile sind z.B.:

• Es werden neue Möglichkeiten des Software Engineerings erlaubt. Beispielsweise hat sich

6Wohlgeformt heiÿt: 1. Die XAML-Datei hat genau ein Wurzelelement, das alle anderen Elemente ein-schlieÿt. 2. Auf ein ö�nendes Element folgt stets ein schlieÿendes Element, oder es wird explizit ein leeresElement mit einem �/>� am Ende angegeben. 3. Die Elemente müssen überschneidungsfrei verschachtelt sein.

27


für die Architektur vonWPF- und Silverlight-Anwendungen das Model-View-ViewModel-

Muster (Kapitel 6.2) bewährt.

• Da XAML kürzer, besser strukturiert und damit leichter zu lesen ist als prozeduraler

Code, lässt sich die GUI zeitnah implementieren.

• XAML ist relativ leicht zu erlernen, da es an bekannte Konzepte wie XML und HTML

angelehnt ist. Ein Designer mit Erfahrung in webbasierten Beschreibungssprachen kann

sich schnell darin zurecht�nden.

• Gegenüber einer prozeduralen Ober�ächenimplementierung in C# entstehen durch XAML

keine Leistungsnachteile, da XAML lediglich eine alternative Repräsentation von .NET

Objekten ist.

• XAML-Dateien können zur Laufzeit dynamisch geladen werden, um die darin enthalte-

nen Objekte in der Anwendung zu Nutzen.

Die folgenden Abschnitte erläutern die wesentlichen Aspekte zur GUI-Erzeugung in Silverlight

und geben einen Einblick in XAML.

3.4.1 Controls

Eine Benutzerober�äche lässt sich mit Silverlight aus sog. Controls zusammensetzen. Dies sind

vorde�nierte (built-in) Bausteine der GUI, wie etwa Schalt�ächen (Button), Auswahlboxen

(CheckBox, RadioButton), Listen (ListBox, ComboBox, StackPanel), Tabellen oder Gitternet-

ze (Grid). Viele dieser Elemente geben nach einer Benutzerinteraktion ein visuelles Feedback.

Beispielsweise ändert sich das Aussehen eines Button-Controls, sobald man mit der Maus

darüber fährt. Eine fertige Anwendungsober�äche wird aus verschiedensten built-in-Controls

(also vom Framework bereitgestellte Elemente) und aus eigens für einen spezi�schen Zweck

kreierten Controls zusammengebaut (z.B. ein erweitertes Calendar-Control zur Anzeige eines

Kalenders).

Die Grundlagen objektorientierter Programmierung gelten auch hier, sodass jedes Element

der GUI durch eine entsprechende Klasse im Quelltext repräsentiert werden kann.

Die Basisklasse Control erbt von FrameworkElement und erweitert diese um einige wichti-

ge Attribute bzw. Properties (Properties werden in Kapitel 3.5.1 genauer behandelt). Dies

sind z.B Background Width/Height oder Margin/Padding. Die in den Controls enthalten

Properties sind in der Regel selbsterklärend und dienen meist der visuellen Anpassung an ei-

gene Bedürfnisse. Zudem werden einige logische Attribute bereitgestellt, z.B. IsTabStop oder

IsEnabled.

28


Abbildung 3.5 zeigt exemplarisch einige der wichtigsten Silverlight-Controls. Diese Controls

sind im Allgemeinen lookless, d.h. die Logik, welche sie bereitstellen, ist nicht an ihr Äuÿe-

res gebunden. Ihr Erscheinungsbild ist daher fast beliebig veränderbar, ohne ihre Logik zu

beein�ussen.

Abb. 3.5: Übersicht der wichtigsten Controls

Mit dem Silverlight-Toolkit existieren bereits viele vorgefertigte Controls zur Gestaltung der

Anwendungen. Obwohl sich das Aussehen dieser mit Hilfe von Styles, Triggern und Templates

individuell anpassen lässt, ist es dennoch manchmal nötig eigene Controls zu erstellen. Die ist

etwa der Fall, wenn mit den Bestehenden eine gewünschte Funktionalität nicht realisierbar

ist. Es lassen sich zwei Arten von Controls entwickeln, Custom Controls und User Controls.

Custom Controls unterstützen Templates und haben somit dasselbe lookless-Verhalten wie

die Controls von WPF und Silverlight. Es ist dann besonders geeignet, wenn es äuÿerlich

stark verändert werden soll, aber gleichzeitig die eigentliche Funktionalität beibehält. Nach

dem Erstellen eines Custom Controls liegt mindestens eine Code-Behind-Datei (*.cs) mit einer

von Control abgeleiteten Klasse vor. Ebenso existiert eine .xaml-Datei, welche das Default-

Template (das standardmäÿige, äuÿere Erscheinungsbild) des Controls beschreibt. Auch wenn

man bestehende Controls erweitern (also Aussehen und Funktion von ihnen erben) will, erstellt

man ein Custom Control.

Eigene User Controls dagegen leiten direkt von der Klasse UserControl ab und bieten

keine Unterstützung für Templates. Man erstellt ein User Control, falls man in einer Anwen-

dung mehrere Controls zu einem einzigen gruppieren möchte, um Komplexität zu kapseln

oder diese Gruppe an anderer Stelle wiederzuverwenden. Ein Beispiel hierfür wäre etwa ein

29

Visitenkarten-User-Control, welches mehrere formatierte Text-Blöcke (Adressangaben) und

ein Bild zusammenfasst. Listet man diese Controls (beispielsweise zum Drucken eines Adress-

buchs) auf, verwendet man mehrere der erstellten User Controls mit jeweils anderen Perso-

nendaten. Dies ermöglicht es, bestehende Komponenten wiederzuverwenden. (Huber, 2008,

S. 897�, 928f)

3.4.2 XAML-Grundlagen

Hinweis

Die hier genannten Funktionen und Objekte stehen häu�g für die WPF und Silver-

light gleichermaÿen zur Verfügung. Wenn in den folgenden Kapiteln also von Silver-

light die Rede ist, gilt das Gleiche in der Regel auch für die WPF. Der Umkehrschluss

gilt nicht unbedingt.

Ein gültiges XAML-Dokument, bestehend aus einem roten Rechteck der Gröÿe 140x90 Pixel

hinter einem Button mit der Aufschrift �OK�, wird in Listing 3.2 beschrieben. Man kann leicht

das erzeugte Ergebnis in Abbildung 3.6 aus der XAML-Datei ableiten.

1 <UserControl

2 xmlns="http: // schemas.microsoft.com/winfx /2006/ xaml/presentation"

3 xmlns:x="http: // schemas.microsoft.com/winfx /2006/ xaml"

4 xmlns:d="http: // schemas.microsoft.com/expression/blend /2008"

5 xmlns:mc="http:// schemas.openxmlformats.org/markup -compatibility /2006"

6 mc:Ignorable="d"

7 x:Class="Examples.MainPage"

8 Width="640" Height="480">

9 

10 <Grid x:Name="LayoutRoot" Background="#FFAAAAAA">

11 <Rectangle

12 Fill="Red"

13 HorizontalAlignment="Center"

14 VerticalAlignment="Center"

15 Width="140" Height="90"

16 />

17 <Button Content="OK"

18 x:Name="btnOk"

19 Click="btnOk_Clicked"

20 HorizontalAlignment="Center"

21 VerticalAlignment="Center"

22 Width="66" />

23 </Grid>

24 </UserControl >

Listing 3.2: Ein gültiges XAML-Dokument für Silverlight

Im Beispiel 3.2 werden zur Laufzeit die Elemente UserControl, Button und Rectangle den

entsprechenden .NET Klassen zugeordnet und von diesen dann Instanzen erzeugt. Das XAML-

30


Abb. 3.6: Die von Listing 3.2 erzeugten Elemente

Attribut Content des Button-Elements wird dabei von Silverlight auf die passende Content-

Property (Kapitel 3.5.1) der Button-Klasse abgebildet.

Auf die gleiche Weise lassen sich über diese Attribute auch Events zuordnen. Hier wird bei

einem Click-Event beispielsweise die Methode btnOk_Clicked in der Code-Behind-Datei auf-

gerufen (siehe Kapitel 3.5.2)7. Diese als Attribut-Syntax8 bezeichnete Zuweisung ist die sim-

pelste Deklarierungsmöglichkeit von Werten in XAML.

Die Zuordnung zwischen XAML und C# erfolgt dabei mit in Attributen des Wurzelelements

(UserControl) angegebenen Namespaces durch das Attribut xmlns. Der XAML-Parser durch-

sucht dazu alle im Projekt referenzierten Assemblies und erstellt Objekte der gesuchten Klas-

sen. Im Beispiel werden Instanzen der Klassen UserControl, Grid, Rectangle und Button

aus dem Namespace System.Windows.Controls erzeugt.

In den Attributen des Wurzelelements be�nden sich weiterhin Referenzen zu Schemade�nitio-

nen, verwendenten Namespaces und Bibliotheken.

Das Konzept der XAML wird mit jeder neuen Verö�entlichung einer .NET-Version mächtiger.

Es existieren zahlreiche Eigenschaften, die die Entwicklungsarbeit leichter machen. Da deren

Beschreibung aber den Rahmen dieser Arbeit sprengen würde, werden in hier nur ausgewählte

Merkmale beschrieben und erläutert.7Die zugehörige Code-Behind-Datei wird durch x:class=�Examples.MainPage� de�niert. In diesem Fall

bezeichnet Examples den Namespace der Anwendung und MainPage die Code-Behind-Klasse mit dem Kon-struktor MainPage().

8Mit Hilfe von Markup-Extensions gibt es eine weitere Möglichkeit Objekte einer Property zuzuweisen,indem beispielsweise mit einem Data Binding ein bereits existierendes Objekt referenziert wird. Siehe dazuKapitel 3.6.

31


3.4.3 Layout

Es muss bei Entwurf und Realisierung von webbasierten Ober�ächen darauf geachtet werden,

dass Browserfenster keine feste Gröÿe haben. Die GUI-Elemente sollten entweder dynamisch

dem zur Verfügung stehenden Bereich angepasst werden, oder eine fest de�nierte Gröÿe im

Sichtbereich besitzen. Silverlight bietet hierfür umfassende Möglichkeiten der Layoutgestal-

tung über eine Menge von Panels (Container), welche verschiedene Kindelemente enthalten

dürfen. Da diese Containerklassen alle von Panel abgeleitet werden (welches wiederum ein

FrameworkElement ist) verfügt es über Properties wie Width, Height, Margin und Padding

(bekannt z.B. aus CSS) sowie die Horizontal- bzw. VerticalAlignment und Visibility-

Eigenschaften. Damit lassen sich nahezu alle gewünschten Anordnungen und Positionierungen

realisieren. Für komplexere Fälle existieren Transformationen.

Die wichtigsten Panel-Klassen werden im Folgenden kurz erläutert.

Das Canvas ist das einzige Panel, in dem die Elemente absolut positioniert werden. Dazu

werden die Properties Bottom, Left, Right und Top bereitgestellt, die den jeweiligen Abstand

zur Kante in logischen Einheiten9 angeben. Für �exible Layouts ist das Canvas daher unge-

eignet, jedoch kann es bei �xen Gröÿen sehr gut als Zeichenbereich etwa für geometrische

Formen genutzt werden.

Ein StackPanel stapelt seine Kindelemente horizontal oder vertikal. Dies ist für gleichmäÿige

Strukturen sehr vorteilhaft. Beispielsweise kann so leicht eine Reihe von Buttons in einer

Toolbar angeordnet werden.

Das Grid ist eines der wichtigsten und vielseitigsten Containerelemente, denn es erlaubt

zahlreiche �exible Kon�gurationen. Es de�niert Zeilen und Spalten mit variabler oder fester

Gröÿe, zu denen sich die Kindelemente einordnen.

In der Praxis verwendet man eine Vielzahl ineinander verschachtelter Panels um das gewünsch-

te Aussehen zu erreichen.

3.4.4 Ressourcen, Styles und Templates

Beim Entwickeln von Benutzerober�ächen ist es von Bedeutung, dass die Anwendung ein kon-

sistentes Design und Farbschema verwendet. Ressourcen, Styles und Templates verscha�en

hier Abhilfe, indem sie zentral de�niert und von anderen Elementen verwendet werden. So

kann das äuÿere Erscheinungsbild der Silverlight-Applikation bei Änderungen e�ektiv aktua-

lisiert werden, ohne mehrere Kopien des gleichen XAML-Codes in den Dateien zu ersetzen.

9Diese Werte sind geräteunabhängig, sodass die Elemente auf jedem Monitor gleich groÿ dargestellt werden.Bei einer Au�ösung von 96dpi entspricht eine logische Einheit (= 1/96 Inch) genau einem Pixel.

32

Zudem steigert dies die Übersichtlichkeit der Quelltexte.

Logische Ressourcen sind Objekte, die nachdem sie separat deklariert wurden, in der An-

wendung referenziert werden können. Häu�g sind dies Instanzen von Brush, Color, Bilder oder

die später beschriebenen Styles. Ressourcen müssen nicht unbedingt visuelle Objekte, sondern

können auch logische Elemente wie Converter oder Validatoren sein. Dadurch kann vermie-

den werden, dass identischer XAML-Code an mehreren Stellen verwendet wird. Man de�niert

stattdessen zentral Ressourcen und referenziert diese dann dort, wo sie benötigt werden.

Üblicherweise werden logische Ressourcen applikationsweit de�niert, d.h. in der Haupt-XAML-

Datei der Anwendung (App.xaml). Möchte man mehrere Anwendungen im gleichen Design

erstellen, lassen sich Ressourcen sich auch in einer separaten Datei auslagern, welche dann

in den jeweiligen Ober�ächen referenziert wird. Das Praxisbeispiel verwendet diese Methode

des resource dictionary, in dem (zentral und applikationsweit) Stile für Schalt�ächen oder

Farbverläufe angegeben werden. Es heiÿt dictionary, da jede darin abgelegte Ressource durch

einen eindeutigen Schlüssel identi�ziert ist.

Zur De�nition einer logischen Ressource, wird ein Objekt zur Resources-Property eines Ele-

ments (oder dem resource dictionary) hinzugefügt. Kindelemente können diese mit der Sta-

ticResource-Markup-Extension referenzieren.

In Beispiel 3.3 wird lokal eine Color-Ressource de�niert, die als Hintergrundfarbe über den

im zwingend notwendigen x:key-Attribut eindeutig de�nierten Identi�kator von einem Grid

verwendet wird.

1 <UserControl

2 xmlns="http:// schemas.microsoft.com/winfx /2006/ xaml/presentation"

3 xmlns:x="http:// schemas.microsoft.com/winfx /2006/ xaml"

4 x:Class="MySilverlightApplication.MainPage"


6

7 

8 <UserControl.Resources >

9 <Color x:Key="BackgroundColor">#FF444544 </Color>

10 </UserControl.Resources >

11

12 

13 <Grid x:Name="LayoutRoot">

14 <Grid.Background >

15 <SolidColorBrush Color="{StaticResource BackgroundColor}"/>

16 </Grid.Background >

17 <Button Content="Button">

18 <Button.Foreground >

19 <SolidColorBrush Color="{StaticResource BackgroundColor}"/>

20 </Button.Foreground >

21 </Button >

22 </Grid>

23 </UserControl >

Listing 3.3: Ressourcende�nition und Referenzierung

33

Das Button-Element verwendet ebenfalls die selbe Ressource als Vordergrundfarbe der Be-

schriftung. Da diese Property aber nur Objekte vom Typ SolidColorBrush entgegen nimmt,

muss eine solche mit der Color-Ressource instanziert werden.

Ressourcen werden in Silverlight nur einmal instanziert. Jeder Zugri� auf diese ist also ein

Zugri� auf dieselbe Instanz. Bei bestimmten Objekten kann es zu Problemen10 führen, mehrere

Referenzierungen auf eine einzelne Ressource zu setzen. Um Fehler zu vermeiden, sollte in

solchen Fällen das x:shared-Attribut der Ressource auf false gesetzt werden, damit es für

jede Referenzierung neu instanziert wird.

Sollten sich die Ressourcen zur Laufzeit verändern (z.B. der Hintergrund wechselt die Farbe),

würde dies von den referenzierten Elementen nicht bemerkt werden. DynamicResources wie

sie in der WPF angeboten werden, existieren in Silverlight nicht. Eine mögliche Lösung wäre

es, stattdessen Data Binding zu benutzen, wie es in Kapitel 3.6 beschrieben ist.

Binäre Ressourcen sind in der Regel nicht ausführbare Dateien, die zusammen mit der

Anwendung ausgeliefert werden und Teil dieser sein können. Dies können Bilder, Symbole,

Programmbibliotheken oder Lokalisierungsdateien (für unterschiedliche Länder und Kulturen)

sein. Häu�g werden diese Dateien als binäre Datenströme in eine Assembly kompiliert (als

sog. eingebettete Ressourcen). Zur Laufzeit können diese dann ausgelesen werden (vgl. Huber,

2008, S. 530�).

Mit einem Style lassen sich gruppierte Werte für mehrere Properties de�nieren. Objekten

kann somit eine Instanz der Klasse Style zugewiesen werden, die verschiedenen Attributen des

Objektes verschiedene Werte setzt. Ein Style ist am besten mit einer CSS-Klasse vergleichbar,

welche einem Element ein neues Aussehen oder Verhalten zuweist. Eingesetzt als logische

Ressource, tragen Styles ebenfalls zur strukturierten und konsistenten Ober�ächengestaltung

bei.

Die Style-Klasse de�niert einen Setter mit den Attributen Property und Value zum Setzen

der Werte. Listing 3.4 und Abbildung 3.7 zeigen die Verwendung exemplarisch.

1 <UserControl

2 xmlns="http:// schemas.microsoft.com/winfx /2006/ xaml/presentation"

3 xmlns:x="http:// schemas.microsoft.com/winfx /2006/ xaml"

4 x:Class="MySilverlightApplication.MainPage"


6


8 

9 <Style x:Key="bigBtnStyle" TargetType="Button">

10 <Setter Property="FontSize" Value="16" />

10Ein Element darf nur einmal im sog. Element Tree vorkommen. Näheres dazu in (Huber, 2008, S. 195�).Einfache Objekte wie Brush und Color sind nicht dieser Objekthierarchie und können daher mehrfach verwen-det werden.

34

11 <Setter Property="Foreground" Value="Red" />

12 </Style>

13 

14 <Style x:Key="bigEmphasizedBtnStyle" TargetType="Button" BasedOn="{StaticResource

bigBtnStyle}">

15 <Setter Property="FontWeight" Value="Bold" />

16 </Style>

17 

18 <Style TargetType="Button">

19 <Setter Property="Foreground" Value="Green" />

20 </Style>

21 

22 <Style x:Key="commonStyle" TargetType="Control">

23 <Setter Property="Control.RenderTransform">

24 <Setter.Value>

25 <RotateTransform Angle="10" />

26 </Setter.Value >

27 </Setter >

28 </Style>


30

31 

32 <Grid x:Name="LayoutRoot">

33 <Button Content="Button A" Style="{StaticResource bigBtnStyle}" />

34 <Button Content="Button B" Style="{StaticResource bigEmphasizedBtnStyle}" />

35 <Button Content="Button C" />

36 <Button Content="Button D" Style="{StaticResource commonStyle}" />

37 <TextBox Text="TextBox" Style="{StaticResource commonStyle} />

38 <CheckBox Content="CheckBox" Style="{StaticResource commonStyle}"/>

39 </Grid >

40 </UserControl >

Listing 3.4: Verwendung von Styles

Hinweis

Um die Beispiele übersichtlich zu halten, werden in den Listings einige Layoutde�-

nitionen (z.B. HorizontalAlignment oder Margin) auÿer Acht gelassen, sodass das

Kopieren und Ausführen des Codes zu einer abweichenden Darstellung führen könnte.

Die de�nierten Styles müssen in Silverlight einen TargetType angeben, wo der Typ des den

Style benutzenden Elements bestimmt wird, damit die zugehörigen Setter auch tatsächlich

in die entsprechende Property umgesetzt werden können. Die ersten drei werden einem But-

ton-Objekt zugewiesen, weshalb der TargetType auf Button gesetzt wird. Die vierte Stylede-

�nition bleibt allgemein, indem der Typ als Control (von welchem alle Silverlight-Elemente

abgeleitet werden), gesetzt wird. Die Setter innerhalb der jeweiligen Styleangaben setzen -

entsprechend der Angabe im Property-Attribut und des Values - die Eigenschaften der den

Style referenzierenden Elemente. Zur Referenzierung wird wie schon bei den logischen Resour-

cen üblich ein Binding an einen eindeutigen x:key angegeben Beispielsweise erhält Button A

35


eine vergröÿerte, rote Schrift aus dem Style bigBtnStyle, während Button B einen Style bi-

gEmphasizedBtnStyle verwendet der auf bigBtnStyle basiert und diesen um einen weiteren

Setter ergänzt. Durch diesen wird die Schrift zusätzlich noch fett gezeichnet.

Button C macht explizit keine Styleangabe, jedoch wurde in der dritten Stylede�nition oben

der TargetType auf Button gesetzt, ohne dabei ein x:key zu vergeben. Dadurch referenzieren

alle Elemente vom Typ Button automatisch diesen Style und Button C hat eine grüne Schrift.

Die Elemente der unteren Reihe erben alle von der Klasse Control und können daher mit der

vierten Stylede�nition commonStyle referenziert werden, welcher die Objekte um 10 Grad

dreht.

Abb. 3.7: Durch Styles veränderte Controls

Ein Template de�niert das spezi�sche Aussehen für ein Control oder für Daten. In Silverlight

werden drei Arten von Templates Unterschieden:

ItemsPanelTemplate - de�niert das Panel, das von einem ItemsControl (z.B. eine ListBox),

für das Layout der darin enthaltenen Items verwendet wird. Üblicherweise wird hierfür

ein StackPanel genutzt, mit dem diese gestapelt werden.

DataTemplate - de�niert das Aussehen für Daten einer Klasse, damit alle Objekte dieser Klas-

se in der Anwendungsober�äche visuell repräsentiert werden können. Ein DataTemplate

wird dann beispielsweise als Vorlage für einzelne Items einer ListBox verwendet

ControlTemplate - beschreibt das allgemeine Aussehen eines Controls, welches komplett von

der Logik getrennt ist.

(Vgl. Huber, 2008, S. 586)

Das ControlTemplate soll hier nun näher erläutert werden, da es essenziell für eine indivi-

duelle Anwendungsober�äche ist. In Listing 3.5 wird erneut eine Ressource erstellt, die ein

ControlTemplate für einen Button de�niert. Dazu erhält die Schalt�äche ein komplett neues

Aussehen - die Funktionalität bleib allerdings bewahrt. Wie im Codeausschnitt ersichtlich

besteht der Button aus einer grauen Umrandung, deren Inhalt einen roten Hintergrund hat.

Zusätzlich wird der Text �Red Button� angezeigt. Beim Testen fällt allerdings auf, dass die

36


Schalt�äche weder wie gewohnt ihr Aussehen beim Klicken verändert, noch ist es möglich

einen neuen Text über die Content-Property zu setzen � dieses Verhalten wurde ja nicht

de�niert. Abbildung 3.8 zeigt das Ergebnis in Button A.


2 <ControlTemplate x:Key="RedButtonTemplate" TargetType="Button">

3 <Border BorderBrush="Gray" BorderThickness="2" CornerRadius="10" Background="Red

">

4 <TextBlock Foreground="White" Text="Red Button" />

5 </Border >

6 </ControlTemplate >


8

9 <Grid x:Name="LayoutRoot" Background="White">

10 <Button Template="{StaticResource RedButtonTemplate}" Content="My New Button" />

11 </Grid>

Listing 3.5: Ein einfaches Template

Abb. 3.8: Ein Button mit einfachem (A) und verbessertem (B) Template

Der ContentPresenter wird von allen Controls benötigt, die eine Content-Property (also

weitere eigenen Kindelemente) anbieten. Vereinfacht gesagt, gibt er Silverlight an, wo die

Inhalte hineingehören (MacDonald, 2009, S.452). Fügt man diesen in das Template ein, lässt

sich über die Content-Property des Buttons wieder der Inhalt setzen.

Ähnlich verhält es sich bei den Template Bindings. Sie ermöglichen es Werte aus dem das

Template verwendende Control zu lesen, und diese im Template anzuwenden. Listing 3.6

korrigiert die Einschränkungen aus dem vorherigen Beispiel, indem ein ContentPresenter und

mehrere Template Bindings hinzugefügt werden. Button B in Abbildung 3.8 hat nun die

gewünschten Eigenschaften.


2 <ControlTemplate x:Key="RedButtonTemplate" TargetType="Button">

3 <Border BorderBrush="Gray" BorderThickness="2"

4 CornerRadius="10" Background="Red">

5 <ContentPresenter

6 Content="{TemplateBinding Content}"

7 Margin="{TemplateBinding Padding}"

8 />

9 </Border >

10 </ControlTemplate >


12


37


14 <Button Template="{StaticResource RedButtonTemplate}"

15 Content="My New Button"

16 HorizontalAlignment="Center" VerticalAlignment="Center"

17 Padding="14,15,14,14" />

18 </Grid>

Listing 3.6: Das verbesserte Template

Um eine visuelle Veränderung des erstellten Elements nach Benutzerinteraktion (z.B. nach

einem Mausklick) zu erreichen, verwendet Silverlight sog. Visual States, die jeweils ein spezi-

elles Aussehen de�nieren, je nachdem in welchem Zustand (Disabled, IsMouseOver, Clicked,

etc.) sich das Control be�ndet. Visual States werden üblicherweise in Zusammenhang mit

Animation verwendet.

Die aus der Windows Presentation Foundation bekannte Funktionalität der Trigger, zur De�-

nition von dynamischen Aktionen in XAML, die zur Laufzeit statt�nden und auf Bedingungen

reagieren, steht standardmäÿig in Silverlight nicht zur Verfügung. Mit der Installation von Ex-

pression Blend 3 (oder höher) wird allerdings der Namespace System.Windows.Interactivity

hinzugefügt, welcher sog. Behaviors und Actions einführt. Diese kapseln ein allgemeines Ver-

halten für Funktionalitäten des User Interfaces (z.B. das Starten einer Animation oder dem

Aufrufen einer Verknüpfung). Ebenso lassen sich komplexere Verhalten realisieren die bei-

spielsweise das Scrollen über ein Mausrad ermöglichen.

Der Vorteil dieser Variante gegenüber einer Implementierung von Events in der logischen

Schicht ist zum einen die Möglichkeit der Wiederverwendung der Codefragmente an ande-

rer Stelle und zum anderen vereinfacht es dem Ober�ächendesigner die Arbeit indem die

gewünschten Behaviors einfach per Drag&Drop in Expression Blend den Controls zugeordnet

werden. Sie erlauben eine saubere, modulare und zentrale Art der Implementierung von Funk-

tionalität. Dieses Thema soll aufgrund des recht umfangreichen Konzepts hier nicht näher

erläutert werden.

3.4.5 Silverlight Animationen

Ein wichtiges Designmerkmal von interaktiven Rich Internet Applications ist die visuell-

dynamische Reaktion der GUI-Komponenten auf Benutzerinteraktionen. Selbst kleine, kaum

bemerkenswerte Veränderungen eines Buttons nachdem die Maus darüber fährt, bereichern

die Anwendung ungemein. Fehlen diese Animationen wirkt das Programm häu�g statisch und

unvollständig. Eine Schalt�äche, die nach einem Klick den Eindruck erweckt nach hinten zu

gleiten, lässt sie realistisch aussehen und macht die Bedienung intuitiv. Zur Realisierung sol-

cher gra�schen Feinheiten bietet Silverlight die Animations. Diese beruhen auf drei Prinzipien:

• Silverlight Animationen sind zeitbasiert. Der Entwickler setzt den Initialzustand, den

38

3.5 Logische Schicht: Code-Behind-Dateien

Endzustand und die Dauer der Animation. Silverlight berechnet daraus die nötigen

Zwischenschritte für einen weichen Übergang.

• Eine Silverlight Animation verändert Properties über einen Zeitraum.

• Jeder Datentyp erfordert eine eigene Animationsklasse. Um einen double-Wert zu

animieren, wird beispielsweise die DoubleAnimation-Klasse verwendet. Für einen Farb-

übergang kommt analog eine ColorAnimation zum Einsatz.

Silverlight bietet eine Vielzahl von Möglichkeiten zur Gestaltung von Animation, die hier nicht

alle betrachtet werden sollen. In der Regel unterstützt Expression Blend bei deren Erstellung,

indem dort automatisch der nötige XAML-Code generiert wird, nachdem der Designer die

Animation mit Hilfe der Funktionen der Entwicklungsumgebung anpasst. So lassen sich leicht

individuelle Animationen mit einem einfachen Werkzeug realisieren. Silverlight kann dabei

auch von der Hardware unterstützt werden, indem die Gra�kkarte zum Zeichnen der Anima-

tionen oder cachen der Bitmaps genutzt wird.


Wie in Kapitel 3 bereits angeklungen, besteht das Programmiermodell von Silverlight grund-

legend aus zwei Schichten: der visuellen Schicht, de�niert durch XAML-Dateien, und der

logischen (oder funktionalen) Schicht, die prozeduralen Programmcode zur Steuerung der

Anwendung enthält. Letztere, Code-Behind genannten Dateien, bilden das ausführbare Pro-

gramm. Üblicherweise existiert zu jeder XAML-Datei eine entsprechende Code-Behind-Datei

mit konventionsgemäÿ gleichem Namen wie das XAML-Dokument (allerdings mit der Endung

.cs oder .vb), in der die für die Ober�äche gewünschte Funktionalität bereitgestellt wird.

Eine �leere� Silverlight-Anwendung wird in Listing 3.7 und 3.8 beschrieben. In der XAML-

Datei MainPage.xaml de�niert das Wurzelelement UserControl im x:Class-Attribut die zu-

gehörige Code-Behind Datei bzw. die bei der Erstellung zu instanzierende Klasse MainPage

(in der Datei MainPage.cs), welche von UserControl abgeleitet ist. Der dortige Konstruktor

ruft zunächst eine automatisch generierte Methode InitializeComponent() auf, die die in

der XAML mit x:key oder x:name benannten Elemente mit den in der logischen Schicht er-

zeugten Objekten verknüpft11. Denn: in XAML verwendete Controls repräsentieren Klassen,

welche erst zur Laufzeit in der logischen Schicht instanziert werden. Sind diese erzeugt worden,

kann beliebiger Code folgen, der die XAML-Elemente als normale Objekte verwendet und so

die Anwendung mit Funktionalität ausstattet.

11Dazu stellt die Klasse UserControl die Methode FindName(string name) zur Verfügung, die im XAML-Objektbaum nach den mit name benannten Elementen sucht.

39

1 <UserControl 

2 x:Class="SilverlightApplication1.MainPage" >

3


5 </Grid>

6 </UserControl >

Listing 3.7: XAML einer leeren Silverlight-Anwendung

1 using System;

2 (...)

3

4 namespace SilverlightApplication1

5 {

6 public partial class MainPage : UserControl

7 {

8 public MainPage ()

9 {

10 // auto generated: required to initialize variables

11 InitializeComponent ();

12 }

13

14 }

15 }

Listing 3.8: Code-Behind Datei einer leeren Silverlight-Anwendung

Um die in XAML de�nierten Elemente im prozeduralen Code anzusprechen, wird diesen mit

dem x:Name- bzw. x:Key-Attribut ein eindeutiger Identi�er vergeben. x:Key und x:Name sind

nicht identische Begri�e. x:Key wird ausschlieÿlich in Ressourcenwörterbüchern, x:Name für

alle Bereiche von XAML verwendet. Listing 3.9 zeigt ein CheckBox-Control in XAML, das

mit �myCheckBox� einen eindeutigen Namen hat. In der zugehörigen Code-Behind-Datei des

XAML-Dokuments ist das Control über diesen Identi�er als instanziertes Objekt erreichbar.

Der Quelltext aus Listing 3.10 setzt exemplarisch den Haken der Box, sobald das Programm ge-

laden wird. Alternativ kann dies auch direkt in XAML durch das Attribut IsChecked=�true�

erreicht werden. Der XAML-Parser erzeugt entsprechend zur Laufzeit in der logischen Schicht

ein neues Objekt vom Typ CheckBox und setzt das IsChecked-Attribut auf true.

1 <UserControl 

2 x:Class="SilverlightApplication1.MainPage">

3


5 <CheckBox x:Name="myCheckBox" Content="CheckBox" HorizontalAlignment="Left"

VerticalAlignment="Top"/>

6 </Grid>

7 </UserControl >

Listing 3.9: CheckBox in XAML mit eindeutigem Identi�er

40


1 using System;

2 (...)

3


5 {


7 {


9 {



12 myCheckBox.IsChecked = true;

13 }

14

15 }

16 }

Listing 3.10: Code-Das IsChecked-Attribut wird gesetzt

3.5.1 Dependency Properties

Mit der Windows Presentation Foundation führte Microsoft ein neues property model ein,

welches auch in Silverlight zum Einsatz kommt. Die sog. Dependency Properties erweitern

einfache Properties von .NET-Objekten so, dass neue, mehrschichtige12 und dynamische Be-

nutzerober�ächen mit Data Binding, Animationen und Styles diese e�zient und korrekt ein-

setzen können. Z.B. wurde eine Prioritätsmodell benötigt, welches Animationen (während sie

ablaufen) stets aktuelle Werte liefert, und andere gleichzeitig zugreifende Prozesse hinten an-

stellt. Daher stammt auch der Name � ein Dependency Property (in deutscher Literatur und

von Microsoft gerne als Abhängigkeitseigenschaft bezeichnet) hängt von mehreren property

providern ab, die alle ihrer eigene Priorität haben (dynamic value resolution, (vgl. MacDo-

nald, 2009, S. 107f, 110). Vorteile gegenüber klassisch implementierten Properties, sind z.B.

ein integrierte Benachrichtigungsmechanismus für Änderungen, Default-Werte, Vererbung des

Wertes über den Logical Tree oder Metadaten (Huber, 2008, S. 389�).

Die meisten der Elemente von Silverlight und WPF sind als Dependency Properties implemen-

tiert; ihre Nutzung erfolgt wie gewohnt über gekapselte getter und setter, die die Properties

von der sog. Property Engine erhalten. Festzuhalten ist hier, dass bestimmte Funktionen und

Elemente von XAML Dependency Properties benötigen.

12Gemeint ist hier eine mögliche Überschneidung oder Überlappung von Elementen der GUI.

41


Abb. 3.9: Vereinfachtes Konzept der Routed Events

3.5.2 Eventhandling und Routed Events

Aufgrund der mehrschichtigen Benutzerober�äche wurde auch ein neues Modell der Events

entworfen. Die Routed Events erlauben einem Event, von einem ursprünglichen Initiator aus-

gehend, entlang dessen Elementhierarchie (dem visual tree) nach oben hin aufgegri�en zu

werden. Das als event bubbling bezeichnete Verhalten wird z.B. für den Fall benötigt, dass ein

Mausklick auf ein in einen Button integriertes Image auch das Click-Ereignis der Schalt�äche

auslösen soll und nicht nur auf der Image-Komponente registriert wird. Abbildung 3.9 zeigt

dies exemplarisch.

Auf dem Image-Element in Abbildung 3.9 wird ein MouseClick-Event gefeuert, welcher zu-

nächst den Elementbaum nach oben wandert (bubbling), bevor er wieder als PreviewMouse-

Click-Event nach unten weitergereicht wird (tunneling). Auf diese Weise kann jedes betei-

ligte Control das Click-Ereignis behandeln (sie agieren als sog. listener oder Abonnenten des

Events). Ist eine Unterbrechung dieses Routings auf anderen Hierarchie-Ebenen gewünscht,

kann der Event durch setzen des Handled-Attribut jederzeit abgebrochen werden. Silverlight

verwendet allerdings nur stark reduzierte Routed Events: Tunneling ist beispielsweise genauso

wenig möglich wie ein Routing für das einfache Click-Ereignis (vgl. Microsoft, 2010a).

In der Regel stellt dies allerdings kein Hindernis bei der Entwicklung von Programmen dar,

denn es lassen sich (wie bei .NET gewohnt) Event-Handler in der logischen Ebene de�nieren,

die solche Ereignisse durch die CLR behandeln.

Ein zusätzlicher Unterschied zu WPF-Anwendungen besteht im Ursprung der Events. Auf

klassischen Desktop-Anwendungen reagiert die Anwendung direkt auf einen Maus- oder Tas-

taturevent. Da Silverlight als Plugin einer Webseitenanwendung ausgeführt wird, ist registriert

der Browser zunächst die z.B. durch Mausklicks ausgelösten Events und leitet diese an die

Silverlight API weiter. Dort �angekommen� kann darauf reagiert werden. Im Normalfall muss

42


sich der Silverlightentwickler nicht um diesen Umstand kümmern.

Listing 3.11 und 3.12 demonstrieren die Registrierung eines Events via XAML auf einem

Button-Control und die Behandlung des Ereignisses im prozeduralen C#-Code der logischen

Schicht, indem dort die Beschriftung der Schalt�äche verändert wird. Silverlight stellt für jeden

Event, in XAML ansprechbare Attribute bereit, in denen eine Methode der Code-Behind-Datei

angegeben werden kann. Der XAML-Parser erstellt bei der Kompilierung die Eventhandler

und registriert sie auf die jeweiligen Objekte und referenzierten Methoden.

1 <Button x:Name="myButton" Content="push me" Click="Button_Click"/>

Listing 3.11: Dem Click-Event eines Buttons wird eine Methode zugewiesen

1 private void Button_Click(object sender , System.Windows.RoutedEventArgs e)

2 {

3 myButton.Content = "Button clicked!";

4 }

Listing 3.12: Code-Behind Datei mit aufzurufender Methode

3.5.3 Commands

Der Nachteil des Eventmodells ist eine starke Bindung zwischen Auslöser und Verarbeiter

(bzw. listener) eines Ereignisses. Üblicherweise wird auf ein solches direkt in der zugehöri-

gen Code-Behind-Datei mit Programmtext reagiert, der die gewünschte Funktionalität erfüllt.

Möchte man die Silverlightanwendung mit Hilfe eines modernen Softwareentwurfsmusters (Ka-

pitel 6.2) verwirklichen, kann diese enge Bindung von groÿem Nachteil sein.

Ein Command kapselt eine Funktionalität und fügt häu�g benötigte Routinen hinzu, die ei-

ne manuelle Implementierung von Event-behandelndem Code üblicherweise mit sich bringt.

Dadurch können Aktionen gekapselt, zu einem gewissen Grad abstrahiert und vom Kontext

losgelöst werden.

Typisch für ein Command wären Funktionen wie cut, copy und paste oder eine globale

�Beenden�-Funktion, die an mehreren Stellen der Anwendung aufgerufen und verwendet wer-

den können. Diese Aktionen lieÿen sich auch über Eventhandler realisieren, jedoch müsste

dann umfangreicher, teils wiederkehrender und identischer Code beispielsweise zur Steuerung

der (De-)Aktivierung von mehreren Buttons oder Menüeinträgen, implementiert werden. Die

Commands übernehmen diese Aufgaben und halten den Status der Controls, die sie verwenden

stets aktuell.

43


Commands sind seit Silverlight 4 für Button und HyperlinkButton möglich. Sie reagieren

standardmäÿig nur auf ein Mausklick oder nach Betätigung der Enter-Taste auf einem fokus-

siertem, Commands unterstützenden Control.

Um mit einem Command auf andere, evtl. selbst de�nierte Events zu reagieren, wird die Bi-

bliothek System.Windows.Interactivity benötigt, welche mit Microsoft Expression Blend

3 (und höher) installiert wird. Darin enthalten sind EventTrigger De�nitionen, die ein belie-

biges Event (z.B. MouserOver, KeyDown) an ein Command oder eine Methode binden13. Im

Gegensatz zur WPF besitzt Silverlight für Commands allerdings keine integrierte Unterstüt-

zung für Tastenkürzel (sog. shortcuts), welche klassisch über Events realisiert werden können.

Eigens erstellte Commands müssen das Interface ICommand implementieren. Darin sind zwei

Methoden (Execute, CanExecute) mit jeweils einem Objektparameter und ein Event (CanExe-

cuteChanged) de�niert. Execute(object param) kapselt und beinhaltet die Funktionalität

des Commands und stellt sie für alle Aufrufer bereit. Die Routine wird von den an den Com-

mand gebundenen Controls aufgerufen, sobald diese ein Click-Event registrieren oder mit

Enter aktiviert werden und führt daraufhin eine Aktion aus. Der Parameter könnte z.B. den

Sender (also Auslöser) der Aktion beinhalten. Die Execute-Methode würde dann in ihrer Lo-

gik überprüfen, wer der Aufrufer war und entsprechend darauf reagieren.

CanExecute(object param) ist für den Zustand des Commands verantwortlich und steu-

ert die Verfügbarkeit dessen für die Aufrufer. An diesen getter wird häu�g das IsEnabled-

Attribut eines Controls gebunden. Liefert CanExecute true, ist der Command von den But-

tons, Menüeinträgen etc. ausführbar und diese sind automatisch aktiviert. Ansonsten wird

false zurückgegeben und die Elemente sind im deaktivierten Zustand.

Der Event CanExecuteChanged ermöglicht diesen Automatismus, indem er jedes mal manuell

gefeuert werden muss, sobald sich die logischen Gegebenheiten des Commands ändern. Durch

ihn werden die gebundenen Controls über den neuen Zustand informiert.

Listings 3.13, 3.14 und 3.15 demonstrieren exemplarisch die Implementierung und Verwendung

einer eigenen Command-Klasse.

1 public class MyWorkCommand : ICommand

2 {

3 public event EventHandler CanExecuteChanged;

4

5 public bool CanExecute(object parameter)

6 {

7 // if (...)

8 return true; // or false

9 }

10

11 public void Execute(object parameter)

12 {

13 // do some work

14 }

13Näheres dazu z.B. bei (o.A., 2010)

44


15 }

Listing 3.13: ICommand wird von MyWorkCommand implementiert

1 using System;

2 (...)

3


5 {


7 {

8 // define command to bind in XAML

9 public ICommand DoSomeWorkCommand {get; set;}

10


12 {



15 DoSomeWorkCommand = new MyWorkCommand ();

16 // command is now ready for action

17 }

18

19 }

20 }

Listing 3.14: Der Command wird in der Code-Behind-Datei instanziert

1 <Button Content="doSomeWork" Command="{Binding DoSomeWorkCommand}" />

Listing 3.15: Dem Button wird ein MyWorkerCommand zugewiesen

Zunächst wird wie oben beschrieben das Interface ICommand durch den spezi�schen Command

MyWorkerCommand implementiert. Die Execute-Methode beinhaltet Code für eine beliebige

Funktionalität. In der Code-Behind-Datei der Anwendung wird der Command de�niert, in-

stanziert und durch den getter aus XAML via Data Binding (Kapitel 3.6) ansprechbar. Im

Command-Atttribut des Buttons wird dann der Command mit der Schalt�äche im XAML-Code

verknüpft. Für den Button referenziert Silverlight automatisch IsEnabled an CanExecute des

Commands. Für andere Controls muss dies explizit in XAML angegeben werden. Zu beachten

ist hier, dass kein Event de�niert ist, der die Aktion bzw. den Command auslöst � Silverlight

übernimmt diese Aufgabe.

Eine weitere Beschreibung der Verwendung von Commands erfolgt im zweiten Teil dieser

Bachelorarbeit.

45

3.6 Data Binding

3.6 Data Binding

Eine Anwendung ohne grundlegende Daten ist sehr selten � kaum eine kommt ohne sie aus.

Silverlight stellt ein ausgereiftes Modell zur dynamischen Datenanbindung der logischen und

visuellen Ebene zur Verfügung. Wie zuvor bereits beschrieben können in XAML gesetzte

Attribute von Controls Werte entgegennehmen. Bisher waren dies (bis auf Listing 3.15) stets

statische Daten wie einfache Strings (Text, Content), boolesche oder Zahlenwerte (Width,

Margin). Für RIAs kann es erforderlich sein, auch komplexere Objekte (sog. Data Objects) und

dynamische Werte (z.B. ein formatiertes Datum) an ein Element zu binden. Das Data Binding

von Silverlight (und das noch mächtigere der WPF14) ermöglichen es, eine (Dependency)

Property eines Elements an den Wert einer anderen Property zu binden. Anders ausgedrückt

ist Data Binding...

(...) ein Prozess der Silverlight mitteilt, den Wert einer Property von einem Quellob-jekt entgegen zu nehmen und diesen zu verwenden um die Property eins Zielobjekts zusetzen. (Vgl. MacDonald, 2009, S. 542)

Das Konzept des Data Binding ist ein recht umfangreiches Thema, welches hier nur in seinen

grundlegendsten Aspekten wiedergegeben werden kann. Auf Merkmale wie ValueConverter,

DataTemplates, das Binding an LINQ-Ausdrücke oder an Resourcen, muss hier aus verständ-

lichen Gründen verzichtet werden. In den folgenden Kapiteln wird das Data Binding anhand

von simplen Beispielen veranschaulicht und teilweise im zweiten Teil der Arbeit vertieft.

3.6.1 Binding in XAML

Das einfachste Binding ist das element to element Binding von in XAML de�nierten Controls.

Auf diese Weise kann ein Element das Attribut eines anderen auslesen und übernehmen. So

kann beispielsweise ein Slider-Control mit einer TextBox verknüpft werden, die die aktuelle

Position des Schiebers als (Zahlen-)Wert wiedergibt. Listing 3.16 demonstriert das Vorgehen,

indem ein solches Beispiel implementiert wird.

1 <Slider x:Name="mySider" Width="100" Height="20" Maximum="100" Value="75" />

2 <TextBox Width="40" Height="24" Text="{Binding ElementName=mySlider , Path=Value}" />

Listing 3.16: Data Binding zweier Elemente in XAML

Die Schiebereglerposition des Sliders wird im Attribut Value festegelegt. Die TextBox bin-

det dynamisch an diesen Wert, indem für das Text-Attribut eine Bindinganweisung verwendet

wird.14Z.B. untersützt Silverlight kein Binding zu ADO.NET DataSet-Klassen.

46

3.6 Data Binding

Allgemein lautet die Syntax: {Binding <OPTIONS>}, wobei <OPTIONS> die Instanz eines ein-

deutig bezeichneten Objekts ist, oder über Parameter wie ElementName, Path, Converter,

Mode, Source usw. das Binding genauer angepasst werden kann. Im Beispiel wird das XAML-

Element mit dem Namen mySlider gebunden; genauer dessen Value-Attribut.

Startet man die Anwendung und bewegt den Slider, zeigt die TextBox stets die aktuelle Positi-

on an. Gibt man stattdessen dort einen Zahlenwert ein, verschiebt sich der Schieber nicht. Die-

ses Verhalten resultiert aus der standardmäÿigen Verwendung des Modus' OneWay-Binding.

In Silverlight existieren drei Modi, die über den Mode-Paremeter der Bindinganweisung gesetzt

werden können (MacDonald, 2009, S. 547). Abbildung 3.10 verdeutlicht den Zusammenhang

modellhaft.

Abb. 3.10: Silverlights Data Binding und Bindingsmodi (Quelle: nach Huber, 2008, S. 627))

OneWay Die Ziel-Property wird aktualisiert, wenn sich die Quell-Property ändert.

TwoWay Sobald sich eine der beteiligten Properties ändert, wird auch die andere geändert.

OneTime Die Ziel-Property wird bei der Erstellung einmalig, basierend auf dem Wert der

Source-Property, gesetzt. Änderungen werden weiterhin nicht beachtet.

Besteht andererseits die Anforderung, ein komplexeres Objekt (wie es durch Listing beschrie-

ben wird 3.17, das exemplarisch einen Adressbucheintrag wiederspiegelt), an ein Element der

Benutzerober�äche zu binden, kann wie folgt vorgegangen werden:

1 public class Person

2 {

3 public String Name {get; set;}

4 public int TelNumber {get; set;}

5 private long _ID;

6 }

Listing 3.17: Klassende�nition eines Adressbucheintrages

47

3.6 Data Binding

Die Klasse Person de�niert zwei ö�entliche Attribute, auf welche mit gettern und settern

zugegri�en werden kann (ein Binding benötigt logischerweise public properties). In der Code-

Behind-Datei wird die Klasse instanziert und mit einigen Werten versehen.

1 using System;

2 (...)

3


5 {


7 {

8 // define person to bind in XAML

9 public Person MyPerson {get; set;};

10


12 {



15 MyPerson = new Person ();

16 MyPerson.Name = "Andreas";

17 MyPerson.TelNumber = 123456;

18 }

19

20 }

21 }

Listing 3.18: Instanziierung und Verö�entlichung eines Objekts in der Code-Behind-Datei

Statt nun im XAML-Code wieder über die Bindingparameter ElementName und Path zu gehen,

wird hier das DataContext-Attribut des hierarchisch übergeordneten Controls verwendet.

1 <Grid DataContext="{Binding MyPerson}">

2 <TextBox Text="{Binding Name}" />

3 <TextBox Text="{Binding TelNumber}" />

4 </Grid>

Listing 3.19: XAML für ein Object-Binding

Durch diese Anweisung erhalten alle Kindelemente des Grids Zugri� auf das in DataCon-

text de�nierte Objekt. Die beiden TextBoxes können direkt die ö�entlichen Attributwerte

der Objektinstanz MyPerson lesen und setzen (vgl. die Implementierung des MainViewModel-

Bindings in Teil Zwei der Arbeit). Um den Zugri� auf ein anderes Objekt als es im Da-

taContext angegeben wurde zu forcieren, können natürlich die o.g. Parameter (z.B. Path)

verwendet werden.

3.6.2 Binding in der Anwendungslogik

Ebenso wie in XAML lässt sich das Data Binding auch in der logischen Schicht mit pro-

zeduralem Programmcode realisieren. Dies kann für die Fälle vorteilhaft sein, in denen der

48

3.6 Data Binding

DataContext ebenfalls dynamisch ist und der jeweiligen Programmsituation angepasst werden

soll. Silverlight stellt mit der Klasse Binding ein Instrument zur Verfügung, das Binden von

Daten komplett über die Code-Behind-Dateien zu lösen, was aber selten die optimale Wahl

ist, denn: die logische Schicht sollte möglichst wenig von der Ober�äche wissen, um einem

modularen, mehrschichtigen Programmaufbau treu zu bleiben.

In den meisten Fällen genügt es, das in XAML mit einem Namen de�nierte Element in der

Code-Behind-Datei anzusprechen, um dort objektorientiert das DataContext-Attribut neu zu

setzen.

Dennoch muss die funktionale Ebene das Data Binding in vielen Situationen unterstützen. So

ist es z.B. äuÿerst wichtig, einen Benachrichtigungsmechanismus für gebundene Objekte zur

Verfügung zu stellen, der die GUI auf Änderungen der Datengrundlage hinweist, sodass diese

stets die aktuellsten Werte anzeigt und nicht statisch auf den Anfangswerten verharrt. Für

diesen Zweck müssen gebundene Objekte, ihre Änderungen verkünden, indem das Interface

INotifyPropertyChanged von diesen Klassen implementiert wird.15 Dieser Vertrag de�niert

einen PropertyChangedEventHandler, welcher bei Änderungen gefeuert werden sollte. Nor-

malerweise geschieht dies im setter der jeweiligen Property, direkt nach dem Setzen des neuen

Wertes.

Listing 7.3 auf S. 103 zeigt exemplarisch das Vorgehen für einen solchen Fall.

3.6.3 Datenvalidierung

Das Data Binding von Silverlight reagiert auf ungültige Daten gleichgültig, indem diese igno-

riert werden. Soll der Benutzer beispielsweise eine Zahlenreihe eingeben, tippt stattdessen

aber auch (versehentlich) Buchstaben ein, so muss die Anwendung auf irgendeine Art dar-

auf reagieren. Üblicherweise wird dem Benutzer ein zweckdienlicher Hinweis angezeigt, sodass

er die Eingaben korrigieren kann. Alternativ kann auch ein interner Prozess gestartet wer-

den, der versucht den Fehler zu beseitigen, indem etwa ein ausgereiftes Exception-Handling

implementiert wird.

Zum Zwecke der Datenvalidierung hat Silverlight ein einfaches System, welches erneut nicht

so mächig ist wie das der WPF, aber dennoch eine stabile Fehlerbehandlung ermöglicht. Die

Controls, die dieses Feature (ohne Zusatzarbeit) unterstützen sind TextBox, PasswordBox,

CheckBox, RadioButton, ListBox und ComboBox (MacDonald, 2009, S. 549). Sie stellen den

Binding Parameter ValidatesOnException zur Verfügung, der mit einem booleschen Wert

belegt werden kann. Wird es true gesetzt, erhält das Control beim Auftauchen einer Exception

(etwa ausgelöst im setter eines Property, bei falscher Dateneingabe) einen roten Rahmen mit

15Einige höhere Klassen von Silverlight realisieren dieses bereits, so z.B. die ObservableCollection; jedochnicht die weit verbreitete generische List.

49

3.7 Kommunikation mit dem Server

einem Hinweis auf den Fehler (siehe Abbildung 3.11).

Abb. 3.11: Geglückte und fehlgeschlagene Validierung

Eine weitere Option ist der Parameter NotifyOnValidationError. Wird er auf true gesetzt,

feuert Silverlight bei Validierungs-Fehlern automatisch den Event BindingValidationError,

der dann wiederum in der Code-Behind-Datei aufgefangen oder verarbeitet werden kann.

Zusätzlich steht dem Silverlightentwickler die Validation-Klasse zur Verfügung, welche die

Fehler gesammelt und zusammengefasst anzeigt


Das Rückgrat einer jeden Rich Internet Application, sind die dahinter liegenden Data Services.

Verwendet eine Silverlightanwendung ein oder mehrere Web Services, be�nden sich diese ent-

weder auf dem gleichen Server wie die Host-Internetseite, oder das Programm erhält Daten

von externen Anbietern und ihrer Services.

Aus Sicherheitsgründen ist es Silverlightanwendungen zunächst nicht gestattet, Dienste anzu-

fragen, die nicht vom eigenen Server angeboten werden (sog. cross-domain calls). Da dies den

Betrieb einer Webanwendung extrem einschränkt, kann die Restriktion durch Anlegen einer

XML-Datei namens clientaccesspolicy.xml, welche Richtlinien zum Umgang mit fremden

Domains enthält, gesteuert werden.

Fordert eine Silverlightanwendung Daten von einem Server an, wird zunächst im Root-Verzeichnis

des angeforderten Servers nach diesem Dokument gesucht16. Erlaubt der Server der Anwen-

dung den Zugri� nicht, oder existieren keine Richtliniendokumente, wird die Verbindung

von Silverlight verweigert. Eine einfache clientaccespolicy.xml, welche keine Restriktionen

setzt und HTTP-Anfragen von allen Domains zu allen eigenen Unterverzeichnissen erlaubt ist

in Listing 3.20 beschrieben. Auf eine Erklärung der einzelnen Elemente einer solchen Datei

soll hier verzichtet werden.

1 ï�¾<?xml version="1.0" encoding="utf -8" ?>

2 <access -policy >

3 <cross -domain -access >

4 <policy >

16Ist clientaccesspolicy.xml nicht vorhanden, wird nach einer Datei crossdomain.xml gesucht, welche ur-sprünglich für Flash-Anwendungen entwickelt wurde und den gleichen Zweck erfüllt.

50


5 <allow -from http -request -headers="*">

6 <domain uri="*" />

7 </allow -from>

8 <grant -to>

9 <resource path="/" include -subpaths="true" />

10 </grant -to>

11 </policy >

12 </cross -domain -access >

13 </access -policy >

Listing 3.20: Eine simple clientaccesspolicy.xml (Quelle: nach Microsoft, 2010d)

Benötigt man Daten von einem Server, der so den Zugri� verbietet, bleibt als einzige Mög-

lichkeit einen serverseitigen Proxy-Web Service zu implementieren. Dieser be�ndet sich auf

dem gleichen Host wie die Anfragende Anwendung. Der Dienst agiert als eine Art Vertreter

der Silverlightanwendung, der die Anfragen an den restriktiven Server weiterleitet. Da ein

Web Service die cross-domain policy nicht beachtet, zudem auf einem (vermeintlich sicheren)

Server läuft und nicht im Browser, wird die Anfrage vom Server beantwortet und Silverlight

erhält die geforderten Daten über den Proxy-Service. Abbildung 3.12 zeigt zusammengefasst

die möglichen Varianten einer cross-domain-Anfrage.

Abb. 3.12: Web Service-Anbindung in Silverlight (Quelle: nach MacDonald, 2009, S. 681)

Die Verwendung eines Proxy-Dienstes ist aufgrund der zusätzlichen Zwischenstation v.a. aus

Gründen der Leistungsfähigkeit für gröÿere Datenmengen problematisch. Auch die zusätzliche

Zeit für die Implementierung und Veri�zierung des Services muss beachtet werden.

Überwindet man die Hürde der cross-domain accessibility, besteht die einfachste Möglichkeit

einen bestehenden Web Service in das Programm zu integrieren, über den von Visual Studio

51

3.8 Weitere Features

angebotenen Assistenten. Gibt man dort die Adresse des Dienstes und einige weitere Optionen

an, erzeugt die IDE automatisch die nötigen Verbindungsklassen zum Zugri� auf den Service.

Beispielsweise zeigt Listing 7.16 aus Teil zwei eine solche Anfrage an den Server über diese

Referenzierungsklasse.

Alternativ stellt Silverlight (bzw. das .NET-Framework) zahlreiche Bibliotheken und Klassen

bereit, die Webanfragen durchführen und bearbeiten können; z.B. WebRequest, WebRespon-

se, HttpContext etc. Dabei ist zu beachten, dass Serveranfragen von Silverlightanwendungen

stets asynchron ablaufen. Das heiÿt: wird ein Dienst aufgerufen, blockiert das Programm nicht,

indem es auf eine Antwort des Services wartet. Dazu wird ein Event auf das Completed- bzw.

Error-Ereignis der Anfrage registriert, welcher nach erfolgreicher (oder fehlgeschlagener) Ser-

verantwort gefeuert wird. Dort kann dann entsprechend reagiert und das Ergebnis verarbeitet

werden.

Eine detaillierte Implementierung und Beschreibung einer asynchronen Serviceverbindung

wird im zweiten Teil gegeben.


Neben den bisher genannten Funktionen und Merkmalen soll hier nun kurz auf weitere er-

wähnenswerte Features von Silverlight 4 eingangen werden. Viele davon, sind vor allem für

multimedialastige Anwendungen interessant, andere können auch gut im kommerziellen Um-

feld zum Einsatz kommen.

Merkmal Beschreibung

out-of-browser Eine Silverlightanwendung lässt sich auf Wunsch lokal auf dem

Rechner des Nutzers installieren (Windows und Mac OS). Sie ver-

hält sich danach nicht anders, als liefe sie im Browser ab. Das Pro-

gramm wird in der gesicherten Umgebung der Sandbox installiert

und ausgeführt und kann über eine Verknüpfung im Startmenü

oder auf dem Desktop starten (äquivalent auf Mac). Zur Imple-

mentierung dieser Funktion sind nur wenige Zeilen notwendig.

trusted apps Benötigt eine Silverlightanwendung umfassendere Rechte als ihr

normalerweise eingeräumt wird, kann sie durch den Benutzer als

trusted application eingestuft werden, sodass diese beispielsweise

mehr Speicherplatz innerhalb der Sandbox erhält, Zugri� auf Teile

des Dateisystems des Nutzers (Eigene Dateien) hat oder im Voll-

bildmodus Tastaturbefehle entgegennimmt. Ein solch höher privi-

ligierte Anwendung ist ähnlich der Ausführung einer .exe-Datei.

52



Multimedia-

funktionen

Es existieren Controls und Funktionen die eine Wiedergabe von

(hochau�ösenden) Audio- und Videodaten ermöglichen und digi-

tales Rechtemanagement (DRM) unterstützen. Seit Version 4 kön-

nen auch Webcam, Mikrofon und erweiterte Eingabegeräte (Multi-

touch, Stylus) in einer Silverlightanwendung verwendet werden.

Druckfunktion Ebenfalls in Version 4 wurde eine lang erwartete Druckfunktion be-

reitgestellt, die es den Entwicklern ermöglicht individuelle Druck-

ausgaben der Anwendung zu erstellen.

Deep Zoom Eine Funktion, die vor allem in multimedialastigen Anwendungen

zum Einsatz kommen kann, ist Deep Zoom für Bildergalerien. Das

besondere an der fertigen Galerie ist die Präsentationsform: der Be-

nutzer kann mit Hilfe einer interaktiven Zoomfunktion die Bilder

dynamisch verkleinert/vergröÿert betrachten, welche automatisch

in der besten Au�ösung gerendert und ggf. vom Server nachgela-

den werden. Ein Beispiel kann z.B. auf der Seite des �Hard Rock

Cafes�17 betrachtet werden.

Controls des Sil-

verlight Toolkit

Die Silverlight Tools bzw. das optionale, die Entwicklung erwei-

ternde Silverlight Toolkit und die Bibliotheken, welche mit Micro-

soft Expression Blend installiert werden, vergröÿern die Menge der

Controls beachtlich. Darunter ist beispielsweise, eine ausgefeilte

Darstellung von Graphen und Diagrammen, Funktionen für �Drag

and Drop�, das aufklappbare Accordion, Controls für hierarchische

Elemente (tree views) oder ein visuelles Ratingsystem (z.B. 1 bis

5 Sterne). Eine Übersicht dieser Komponenten �ndet sich bei den

Silverlight Toolkit Samples von Microsoft18.

multithreading Silverlight lässt (im Gegensatz zu anderen RIAs) parallele Prozes-

se auf der CPU zu und ermöglicht so die Implementierung von

rechenintensiven Aufgaben. �Unter der Haube� nutzt Silverlight

multithreading intensiv z.B. zum Durchführen von Animationen,

Transformationen oder Übergängen. Das Plugin kann daher auch

im Hinblick auf simple physikalische Simulationen, groÿe Daten-

mengen, Spieleprogrammierung, cloud computing oder dem seman-

tischen Web (�Web 3.0�, (vgl. Schibrowski, 2007)) interessant sein,

da threads optimiert und im Hintergrund ausgeführt werden kön-

nen (vgl. Czernicki, 2008a,b).

17http://memorabilia.hardrock.com18http://www.silverlight.net/content/samples/sl4/toolkitcontrolsamples/run/default.html

53

3.9 Sicherheit


deep linking Für den Laien ist es oft schwierig das Prinzip des Programms in-

nerhalb eines anderen Programms (RIA im Browser) zu verstehen.

Eine kleine Abhilfe verscha�t die Möglichkeit, die Silverlightanwen-

dung mit Hilfe des Browsers zu steuern, d.h. zur Navigation die

Vor- und Zurück-Buttons zu benutzen oder Hyperlinks auch auf

Elemente innerhalb der RIA zu verweisen. Auf diese Weise wird

ein vertrautes Konzept der Browsernutzung bewahrt (vgl. Pfeil,

2009, S. 40).

Lokalisierung Silverlight übernimmt weitgehend das Konzept der WPF zur Lo-

kalisierung einer Anwendung für verschiedene Sprachen und Kul-

turen.

3.9 Sicherheit

Grundlage eines sicheren Programms ist seine Aktualität durch regelmäÿige Updates. Das

Silverlightplugin aktualisiert sich selbstständig; ebenfalls die damit entwickelten Anwendun-

gen im Internet und als out-of-browser-Application beim ersten Zugri� auf eine neue Version.

Dabei verbleiben nie Reste einer alten Version auf dem System - es existiert immer nur eine

Version des Plugins oder Programms.

Zur Installation des Silverlightplugins sind Administratorrechte notwendig.

Eine Silverlightanwendung kann in drei verschieden Sicherheitsmodi ausgeführt werden.

• Standardmäÿig im Browser � die Anwendung agiert als Teil einer Internetseite und

unterliegt den gleichen Einschränkungen wie andere Webinhalte des Browsers.

• Out Of Browser: Sandboxed � Vor der lokalen Installation wird eine Bestätigung

des Nutzers eingefordert. Dieser Modus unterliegt den gleichen Einschränkungen der

Sandbox wie Anwendungen, die innerhalb des Browsers laufen.

• Out Of Browser: Trusted Applications � Die installierte Anwendung hat nach Nut-

zerbestätigung zusätzliche Rechte in einer ausgeweiteten Umgebung. Aus der Perspek-

tive der Sicherheit hat eine solche Anwendung ähnliche Privilegien wie eine .exe-Datei.

Sie hat z.B. Zugri� auf die Benutzerdokumente (Eigene Dateien o.ä.) und kann andere

COM-Objekte aufrufen. Einer solchen Anwendung sollte nur insofern vertraut werden,

wie man der ursprünglichen Herkunftswebseite vertraut.

Die Einschränkungen bzw. Besonderheiten der Sandbox (ohne erhöhte Rechte) werden im

54

3.9 Sicherheit

Folgenden kurz erläutert.

OpenFileDialog/SaveFileDialog � Silverlight kann Dateien auÿerhalb der Sandbox nur le-

sen oder schreiben, wenn der Nutzer diese durch einen expliziten Standard-Dateiauswahldialog

bestätigt. Für gespeicherte Dateien vergibt das Plugin die Kennzeichnung, dass diese aus dem

Internet stammen.

Isolated Storage� Silverlightanwendungen ist es erlaubt Daten in einem speziellen Bereich

des Dateisystems abzulegen. Ähnlich wie bei Cookies hat jeweils nur die eigene Domain der

RIA Zugri� auf diesen Bereich, welcher ein Gröÿenlimit von 1 MB, nach Bestätigung durch

den Benutzer bis zu 100 MB, hat.

Vollbildmodus � Soll die Anwendung den ganzen Bildschirm ausfüllen (randlos, ohne Fenster-

oder Startleiste), wird der Nutzer kurzzeitig mit �Press ESC to exit full screen mode� und der

Adresse der Website benachrichtigt. Das Programm kann eine Beendigung des Vollbildmodus'

nicht verhindern und währenddessen auch nicht auf Tastatureingaben (auÿer ESC) reagieren.

Dies soll sog. �spoo�ng� verhindern.

In einer out-of-browser-Anwendung mit normalen Fenster darf das Programm dessen Gröÿe

und Position nur nach Bestätigung des Nutzers programmatisch ändern (als Mittel gegen

�click jacking attacks�, wo das Fenster sich genau dort hinbewegt wo sich die Maus be�ndet).

Manuell kann natürlich das Programm klassisch am Rahmen gepackt und verändert werden.

Rechtsklick � Wenn die Silverlightanwendung keine Events der rechten Maustaste au�ängt,

zeigt das Plugin in jedem Fall einem Kontextmenü mit Einstellungen an. Dort kann der Nutzer

die Pluginversion sehen und z.B. den Isolated Storage sowie verschiedene Berechtigungen der

Anwendung verwalten.

Wie in Kapitel 3.7 bereits beschrieben, werden Netzwerkzugri�e des Silverlightplugins über po-

licy �les geregelt. Dieses Konzept kommt auch bei den out-of-browser-Applications zum tragen

und kann (auÿer bei trusted tpplications!) nicht umgangen werden. Zusätzlich zu HTTP(S)

anfragen, erlaubt Silverlight die Verwendung von TCP und UDP sockets, welche in der clien-

taccesspolicy.xml spezi�ziert werden müssen.

Für Cross-Site-Scripting-Attacken (XSS), bei denen ein Angreifer versucht Code auszuführen,

der vermeintlich vom �Opfer� selbst stammt, ist Silverlight weniger anfällig. Probleme durch

XSS entstehen in traditioneller HTML-Entwicklung häu�g dadurch, dass bösartige Strings in

Markup-Elemente injiziert werden und diese darau�n ohne Validierung oder Escaping ausge-

führt werden.

Da XAML selten durch Kombination von einzelnen Strings, dynamisch in der Programmlo-

gik aufgebaut wird, sind solche Attacken bei Silverlight recht ungebräuchlich. Z.B. würde ein

Silverlightentwickler einen String im Programm anzeigen in dem er Zeile 1 statt eine Kombi-

55

3.10 Marktverbreitung

nation wie in Zeile 2 aus Listing 3.21 verwendet.

1 textblock.Text = attackerString;

2 XamlReader.Load("<TextBlock Text='" + attackerString + "'/>");

Listing 3.21: Sicherheitsrisiken durch Silverlight

Im ersten Ansatz wird der String nicht geparsed oder ausgeführt, sondern nur im Textelement

angezeigt. Die zweite Zeile zeigt eine Anfälligkeit für XSS bei der Verwendung von dynamisch

geladenen XAML-Teilen.

Aber auch die XAP-Dateien selbst sind nicht automatisch sicher. Da deren Adresse lesbar im

HTML-Quelltext steht, können diese runtergeladen und der Inhalt durch Ö�nen mit einem

Komprimiertool betrachtet werden. Die darin enthaltenen DLLs, welche die clientseitige Logik

der Silverlightanwendung kapseln, sind durch .NET-Obfuscators mit genügend Ausdauer für

Angreifer decompilierbar, lesbar und beliebig veränderbar. Daher sollten darin keinesfalls sen-

sitive Informationen wie Nutzernamen, Passwörter oder ö�entliche Schlüssel enthalten sein.

Sicherheitsrelevante Programmlogik ist auf dem eigenen Server, in einem vertrauten Umfeld

am besten aufgehoben und gehört nicht in clientseitigen Code.

Silverlight bietet neben Bibliotheken zur Sicherung von Services über Netzwerke, auch Klassen

zur Erhaltung der Integrität und Privatsphäre der Anwendung. HTTPS kann beispielsweise

für XAP-Dateien an sich verwendet werden, oder auch für Serviceanfragen der RIA.

Unter dem Namespace System.Security.Cryptography be�nden sich Klassen zur Verschlüs-

selung und für verschiedene Hashing-Verfahren (AES, SHA1, SHA256, HMAC Signaturen).

(Vgl. Kramer, 2010; Esposito, 2008; Collins, 2009).


Die Technologie der Rich Internet Applications steht noch relativ am Anfang der Entwicklung.

Die folgenden Statistiken zeigen jedoch eine zunehmende Akzeptanz auf Anwenderseite über

die letzten Jahre. Dies spiegelt sich auch durch steigende Zahlen der RIAs selbst wieder, denn

ein Plugin wird erst dann vom Nutzer installiert, wenn es für eine Anwendung benötigt wird.

Folgende Punkte sind auch in Zukunft treibende (Wachstums-)Kräfte der RIAs (Noda &

Helwig, 2005) und tragen zu deren weiteren Verbreitung und Entwicklung bei:

1. Steigende Verfügbarkeit des Breitbandnetzes als infrastrukturelle Voraussetzung für in-

haltlich gröÿere Webanwendungen.

2. Zunehmende Akzeptanz des Internets als Kommunikationsmedium

56


3. Wachsende nutzbare Rechenleistung auch beim Endanwender (nicht nur auf Serverseite)

ermöglichen die Verlagerung von technischen Resourcen auf die Seite des Nutzers.

4. Technische Vorteile, neue Entwurfsmuster und Modelle können hier konsequent zum

Einsatz kommen und weitere Vorteile mit sich bringen, z.B. SOA, Web Services, XML,

n-tier-Architektur.

5. Bessere Möglichkeiten der Distribution von Software

6. Häu�g starke Benutzer(inter)aktivität gewünscht und z.T. auch für anspruchsvollere

und komplexere Möglichkeiten der Nutzung von Software benötigt. (Diese soll und kann

auch in Webanwendungen vorkommen.)

7. Kürzere Entwicklungszeiten und geringere Kosten durch leistungsfähige Entwicklungs-

software.

8. Viele �Big Player� ziehen bei der Entwicklung von RIA-Frameworks mit: Microsoft, Ad-

obe, Java.

9. Potentiell mehr Kunden mit plattformunabhängigen, browserbasierten Anwendungen

erreichbar.

(Vgl. Pfeil, 2009, S.40)

Abb. 3.13: Verfügbarkeit von RIA-Plugins (Statistik: nach StatOwl, 2010, Stand: Juni/Juli 2010)

Es nicht verwunderlich, dass die �alten Hasen�, das RIA-Plugin Adobe Flash und Java, auf

über 95% bzw. knapp 80% der Anwendersysteme, seit geraumer Zeit installiert sind. Vor allem

57


als Videoplayer und Werbe�äche ist Flash von vielen Internetseiten nicht mehr wegzudenken.

Die Java Laufzeitumgebung wird ebenfalls für einige wichtige Bedien- und Visualisierungs-

merkmale von Internetseiten benötigt, sodass diese überwiegend zur Standardausstattung

eines Internetnutzers gezählt werden kann.

Die Statistiken (siehe Abbildungen 3.13 und 3.14) belegen auch, dass seit Verö�entlichung

Ende 2007, Silverlight eine stetig zunehmende Verbreitung und Akzeptanz �ndet. Im Juni

2010 waren bereits über 50% der Anwendungsechner fähig, Silverlightprogramme auszufüh-

ren. Dabei fand die neuste Version 4 sehr schnell Verbreitung, denn es dauerte nur wenige

Wochen bis Silverlight 3 von der aktuelleren Version überholt wurde. Hauptgrund dafür ist die

automatische Updatefunktion, was auf eine regelmäÿige Nutzung von Silverlightanwendungen

schlieÿen lässt.

Anzumerken ist aber auch, dass mehr als ein Drittel aller Nutzer noch kein Plugin für Micro-

softs RIA installiert haben. Steigende Nutzerzahlen durch einen nach oben gerichteten Trend

der Pluginverfügbarkeit deuten aber auf eine zukünftig positive Entwicklung hin.

Hinweis

Die Datenbasis beider statistischen Quellen beruht auf Besucherstatistiken von Inter-

netseiten. Berücksichtigt wurden alle Betriebsysteme und Browser in verschiedenen

Untersuchungszeiträumen.

Riastats.com bewertet täglich durchschnittlich 14 Millionen Browserinformationen

in einen Netzwerk von ca. 111 Internetseiten (unbekannter nationaler Herkunft) aus

verschiedenen Themenbereichen. Die Datenerhebung umfasst einen Zeitraum von 30

Tagen im Juni/Juli 2010.

StatOwl.com sammelt Daten von etwa 28 Millionen monatlichen Seitenbesuchen aus

einem Netzwerk von überwiegend in den USA gehosteten Websites. Diese werden als

e-commerce (ca. 32%), corporate (ca. 29%) und content-delivery (Blogs, Nachrichten-

seiten, etc. ca. 20%) klassi�ziert. 19% der Seiten stammen aus sonstigen Bereichen.

Zu beachten ist daher, dass die Zahlen je nach Datenquelle voneinander abweichen

können und bloÿ eine grobe Tendenz angeben.

58


Abb. 3.14: Versionsverbreitung einzelner Frameworks (Statistik: nach Riastats, 2010, Stand: Juni/Juli2010)

59

3.11 Zusammenfassung


Mit Silverlight hat Microsoft einen groÿen Schritt in den Markt der Rich Internet Applicati-

ons gewagt und kann sich dort mit wachsender Fan- und Entwicklergemeinde behaupten. Das

Framework ist in hohem Maÿe in die .NET-Umgebung integriert, versucht dabei aber weitge-

hend plattformunabhänig zu bleiben (sowohl für den Anwendungsprovider, als auch für den

Endbenutzer). Die Plattform verspricht dynamische und �exible Lösungen mit einem hohen

Grad an Wiederverwendbarkeit einzelner Komponenten.

Seit Version 3, spätestens jedoch mit Version 4 Anfang 2010, etabliert sich Microsoft Silverlight

als Werkzeug zur Realisierung von interaktiven und komplexen Anwendungen, eingebettet in

Standard-konforme Internetseiten und vertraute Umgebungen. Die Plat�orm macht es für

Entwickler einfacher, reichhaltige, interaktive und in Netzwerke eingebundene Programme zu

entwickeln.

Obwohl es auch ohne Silverlight mit verschiedenen Werkzeugen des Webs möglich ist solche

Applikationen zu realisieren, ist dort häu�g von Schwierigkeiten mit inkompatiblen Plattfor-

men, Datenformaten, Browsern und Protokollen auszugehen. Eine interaktive Webanwendung,

die perfekt auf einem System und Browser läuft, kann sich in anderen Umgebungen völlig an-

ders verhalten oder komplett versagen. Unter Benutzung zahlreicher heutiger Tools, Protokolle

und Technologien, ist es häu�g ein kostspieliges Bemühen, Anwendungen zu entwickeln, die

gleichzeitig folgende Anforderungen erfüllen:

• Identisches Aussehen und Funktion auf allen Browsern und Systemen, sodass überall

die Selbe user-experience erreicht wird.

• Integration von Daten und Services aus verschiedenen Netzwerken und Orten unter

Zuhilfenahme vertrauter Techniken, Bibliotheken und Funktionen.

• Realisierbarkeit einer reichhaltigen, hoch-interaktiven, multimedial geprägten und gleich-

zeitig komfortabel zugänglichen Benutzerober�äche

Silverlight macht es für Entwickler relativ einfach solche Anwendungen zu realisieren, denn

das Framework überwindet viele Hindernisse der derzeitigen Technologien. Gleichzeitig stellt

es eine Vielzahl an Werkzeugen und Methoden zur Verfügung, um solche Programme zu er-

möglichen (Microsoft, 2010b). Gerade für, mit dem .NET-Framework vertraute, Entwickler

kann Silverlight eine interessante weil auf bestehende Konzepte aufbauende Technik sein.

Da das Plugin und die darin zu Grunde liegenden Konzepte aber weitgehend plattformunab-

hängig sind, bietet sich Silverlight für viele Bereiche clientseitiger Webanwendungen an.

Das RIA-Framework von Microsoft bietet nicht nur eine Lösung für Anwendungen im Inter-

net. Auch unternehmens-interne Intranet-Netzwerke können davon pro�tieren, indem Softwa-

60


re dort verteilt und verö�entlicht wird, anstatt aufwendig, lokal auf dem Arbeitsplatzrechner

der Angestellten installiert zu werden. Auf diese Weise können Kosten sinken und Updates

erreichen schnell und e�ektiv den Anwender.

Es ist allerdings kritisch anzumerken, dass vor allem die Entwicklung unterstützende Werk-

zeuge (Expression Blend, WCF RIA Services) stark auf die .NET-Umgebung zentriert sind

und wenig Spielraum für alternative Lösungen bieten. Zwar bemüht sich Microsoft auch kon-

zernfremde Möglichkeiten zu unterstützen19, jedoch ist eine aktive Zusammenarbeit nicht

auszumachen.

Obwohl die Entwicklung und Bereitstellung von Tools, Werkzeugen und Anwendungen in der

Regel nicht mit zusätzlichen Restriktionen verbunden ist, bleibt Silverlight das Produkt eines

kommerziellen Anbieters und wird daher nie völlig frei einsetzbar sein.

Erreichen RIAs als potentielle Softwarepakete von und für kommerzielle Lösungen im Un-

ternehmensbereich eine breitere Akzeptanz, werden diese zukünftig maÿgeblich die Software-

landschaft verändern. Die dafür notwendigen Voraussetzungen eines leistungsfähigen Entwick-

lungsframeworks werden von Silverlight gröÿtenteils bereits erfüllt.

19Microsoft kündigte an, keine Klagen patentrechtlicher Natur gegen das Mono-Project oder damit entwi-ckelte Anwendungen einzureichen.

61

Teil II

Konzeption und Realisierung der

Beispielanwendung

62

Kapitel 4

Zum Grundverständnis der

Anwendungsdomäne

Dieser Teil behandelt den Entwurf einer hoch-interaktiven, line-of-business-RIA mit IBM

ILOG Gantt for .NET im Rahmen einer SOA-Architektur. Es wird versucht, anhand der

zuvor erarbeiteten Konzepte und technischen Grundlagen, eine reichhaltige Webanwendung

zu planen und entwickeln. Die dazu nötigen Überlegungen werden in den folgenden Kapiteln

erläutert.

Die Software soll ein allgemeines Projektmanagement realisieren. Die zeitliche Planung, Ver-

waltung und Visualisierung von Projekten und deren Ressourcen durch sog. Gantt-Diagramme1

wird durch die fertige Anwendung möglich sein. Eine �nanzielle Seite der Projektplanung

(Projektkosten) sowie dessen Aquisition werden hier auÿer Acht gelassen, da diese nicht zur

Demonstration der in dieser Arbeit dargestellten Konzepte nötig sind. Der hier beschriebene

Entwurf konzentriert sich auf die Kern-Prozesse und Dienste.

Ein Gantt-Projekt muss im wesentlichen vier Elemente berücksichtigen: Aktivitäten, Bezie-

hungen, Ressourcen und Ressourcenreservierungen.

Komponente Funktion

Aktivitäten (activities,

tasks)

Stellen die Aufgaben eines Projekts dar. Eine Aktivität wird

anhand eines Zeitraums, beginnend ab einer Startzeit de�-

niert und gra�sch durch einen Balken dargestellt. Aktivitä-

ten können auch Meileinsteine eines Projektes sein und/o-

der als kritisch gekennzeichnet werden, falls die Aufgabe be-

stimmte Kriterien erfüllt..

1Benannt nach dem Unternehmensberater Henry L. Gantt (1861-1919)

63

Komponente Funktion

Beziehungen (cons-

traints)

Bedingungen legen Abhängigkeiten zwischen zwei Aktivitä-

ten fest. Beispielsweise muss Aktivität A abgeschlossen sein,

bevor Aktivität B begonnen werden darf. Die Darstellung

der Beziehungen erfolgt durch die Aktivitätem verbindende

Linien und Peile.

Ressourcen Ressourcen repräsentierenMenschen, technisches Equipment

oder beliebige andere Objekte, die zur Erfüllung der Aktivi-

täten benötigt werden. Diese bearbeiten und beenden Akti-

vitäten nach einem gewissen (oft von anderen Variablen ab-

hängigen) Zeitraum und schlieÿen diese damit ab. Im Gantt-

Diagramm kann an Stelle des Aktivitätsplans auch eine Über-

sicht zur Belastung der Ressourcen durch Aktivitäten erfol-

gen.

Reservierungen Um Ressourcen mit Aktivitäten zu belegen werden Reservie-

rungen verwendet. Eine Ressource kann dabei häu�g nur eine

Aktivität gleichzeitig bearbeiten, während Aktivitäten durch-

aus von mehreren Ressourcen erfüllt werden können.

Tab. 4.1: Hauptkomponenten eines Gantt-Diagramms

Ein tabellarisches Gantt-Diagramm stellt die zeitliche Abfolge von Projektaktivitäten gra�sch

(in Form von Balken auf einer Zeitachse) dar. Diese Teilaufgaben werden zeilenweise in der

ersten Spalte aufgelistet. Rechts daneben folgt ein Kalender in dem die Aktivitäten zeitlich in

Form eines waagerechten Balkens platziert sind. Die Länge des Balkens entspricht der benö-

tigten Zeit zur Erfüllung dieser Aktivität. Abhängigkeiten zwischen den Aktivitäten werden

durch sie verbindende Linien und Pfeile deutlich gemacht. Weitere Spalten enthalten z.B.

textuelle Informationen wie Zeiträume (Start- und Enddatum der Aktivität) und benötigte

menschliche bzw. technische Ressourcen.

Damit das Projekt auch in der Realität umgesetzt werden kann, ist es nötig die Kapazitäten

der Ressourcen (entstanden durch ihnen zugewiesene Aktivitäten) zu überwachen. Mensch-

liche Kräfte sind beispielsweise nur zu regulären Arbeitszeiten (Wochentags von 9 bis 17

Uhr) verfügbar und können nicht zwei Aktivitäten gleichzeitig bearbeiten, während bei tech-

nischen Geräten (etwa Computeranlagen) auch Wartungszeiten eingeplant werden müssen.

Die ressourcenbezogene Ansicht des Gantt-Diagramms dient somit auch der Überwachung

des Arbeitseinsatzes und der Produktivität. Auf diese Weise können nicht nur personelle und

technische Kapazitätsengstellen erkannt, sondern auch Leerlaufzeiten bzw. Unterlastungen

verhindert und korrigiert werden. (Wegmann & Winkelbauer, 2006)

64

Aktivitäten und Ressourcen besitzen dabei durchaus auch eine hierarchische Struktur. Ebenso

lassen sich einzelne Phasen des Projekts gruppiert zu einer groÿen Eltern-Aktivität zusammen-

fassen.

Abbildungen 4.1 und 4.2 zeigen zwei einfache, exemplarische Gantt-Diagramme.

Abb. 4.1: Ein einfaches Gantt-Diagrammmit kritischen Vorgängen. (Quelle: Wegmann &Winkelbauer,2006, S. 108)

Abb. 4.2: Personenspezi�sches Gantt-Diagramm für Wegmann. (Quelle: Wegmann & Winkelbauer,2006, S. 117)

65

Kapitel 5

Funktionale und Nichtfunktionale

Anforderungen

In diesem Kapitel werden die qualitativen und quantitativen Eigenschaften der Beispielanwen-

dung beschrieben. Die Anforderungen ergeben sich teilweise bereits aus der oben aufgeführten

Erklärung der Gantt-Diagramme.

Hauptaugenmerk der Anwendung ist es, eine visuelle Übersicht über das Projekt darzustellen,

in der durch Beziehungen verknüpfte Aktivitäten, sowie deren Ressourcen editierbar sind. Die

Anordnung der Elemente in der aktivitätsbezogenen Ansicht orientiert sich dabei stark an der

klassischen Darstellung von Gantt-Diagrammen: eine zeilenweise Anordnung der Aufgaben

(durch Balken visualisiert), welche entlang einer Zeitachse, je nach ihrer Anordnung und

Dauer im Projektzeitplan, horizontal in Gröÿe und Position variabel sind. Klassi�zierbare

Abhängigkeiten zwischen diesen sollen durch entsprechende Linien und Pfeile deutlich gemacht

werden.

Die ressourcenorientierte Darstellung erfolgt ähnlich der der Aktivitäten: die Ressourcen wer-

den zeilenweise aufgelistet. Dahinter folgen jeweils die zugeordneten Aktivitäten in einem

Kalender. Um die Darstellung übersichtlich zu halten, wird es daher notwendig sein die An-

sicht zur Arbeitsbelastung der Ressourcen (die Kapazitätsplanung) von der Aktivitätsansicht

zu trennen. Dazu muss ein Mechanismus bereitgestellt werden, der zwischen der Ressourcen

bezogenen Ansicht und der Aktivitätsansicht wechselt.

Ein Ziel dieser Arbeit ist es, das Praxisbeispiel unter Nutzung von Microsoft Silverlight und

IBM ILOG Gantt for .NET zu realisieren. Zu den Anforderungen gehören daher neben den

o�ensichtlichen Grundfunktionen wie Projekteditierung und eine Speicherung der Daten auch

daraus resultierende technische Funktionalitäten und Geschäftsprozesse, z.B. die Anbindung

66

an einen oder mehrere Web Service(s).

Da die RIA über das Internet genutzt wird, werden an die Datenhaltung spezielle Ansprüche

gestellt. Die Speicherung der Projektdaten kann sowohl lokal auf dem Rechner des Benutzers

erfolgen als auch zentral auf einem Server, der von der Anwendung über Web Services erreicht

wird. Da eine Gantt-Projektdatei nicht nur von der Rich Internet Application genutzt, sondern

durchaus auch durch andere Software bearbeitet oder gelesen werden kann (z.B. Microsoft

Project), ist es von Vorteil die Daten in einem XML-Format mit festem Schema abzulegen.

Diese Exportierung ermöglicht eine standardisierte Verbreitung von Projekten an verschiedene

Ziele. Näheres dazu in Kapitel 6.5.

Das Programm hebt sich insbesondere durch eine erleichterte Benutzung mittels hoher In-

teraktivität der verschiedenen Elementen von klassischen Internetseiten ab, die nur schwer

einen solchen Funktionsumfang bereitstellen können. Aus Desktop-Applikationen bekannte

Funktionen wie ein Kontextmenü über die rechte Maustaste oder ein Verschieben von Akti-

vitätsbalken zur Veränderung von Start- bzw. Enddatum bereichern die Webanwendung und

machen sie leicht zugänglich.

Zur eigentlichen Editierung eines Projektes durch einen Benutzer müssen zumindest folgende,

allgemeine Anwendungsfälle berücksichtigt werden, die im Use Case Diagramm aus Abbildung

5.1 dargestellt sind. Die drei dabei auftretenden Akteure sind der Benutzer, der ausführende

Rechner der RIA und der zugehörige Web Server mit welchem die Anwendung in Verbindung

steht.

Neues Projekt erstellen führt zu einer leeren Projektdatei, die mit Elementen gefüllt und

zur weiteren Bearbeitung gespeichert werden kann. Dieser Vorgang erfolgt zunächst nur

lokal auf Nutzerseite.

Die Editierung eines Projektes impliziert zuvor das Ö�nen vorhandener Projektdaten1.

Dies kann über einen Dateiauswahldialog oder ähnliches geschehen. Soll lokal keine

Datei geö�net werden, wird ein Projekt über einen Web Service vom Server angefragt.

Das Programm lädt die Projektdaten, bereitet sie für die Darstellung vor und zeigt sie

wie oben beschrieben an.

Die editierbaren Komponenten sind Aktivitäten, (evtl. zugeordnete) Ressourcen und de-

ren Beziehungen zueinander, sowie alle damit implizierten Informationen (z.B. Startzeit,

Dauer, Art und ggf. Bearbeitungsfortschritt der Aufgaben, Vorgänger- oder Nachfolge-

aktivitäten, zusätzliche Anmerkungen). Sie werden überwiegend mit der Maus ange-

passt, in bestimmten Fällen ist jedoch eine Tastatureingabe vorzuziehen (z.B. bei der

Benennung der Aktivitäten). Dazu werden verschiedene Dialogfelder angeboten, die die

1Dazu sollte die angeforderte Datengrundlage für die Dauer der Bearbeitung für andere Benutzer gesperrtwerden.

67

Abb. 5.1: Vereinfachtes Use Case Diagramm der wichtigsten Programmfunktionen

jeweiligen Eigenschaften anpassen. Neben der Veränderung bestehender Elemente müs-

sen auch neue hinzugefügt werden können - die RIA kontrolliert dabei die Korrektheit

der Eingaben und erhält die Konsistenz der geänderten Projektdaten bevor etwa ein

Projekt auf dem Server gespeichert wird.

Da die Planung der Ressourcen und der Aktiviäten gleichzeitig in einer Ansicht unüber-

sichtlich werden kann, soll der Benutzer die Möglichkeit haben zwischen der ressourcen-

bezogenen Ansicht (Kapazitätsplanung) und der Aktivitätsansicht zu wechseln. Damit

einhergehend muss es möglich sein, den visuellen Projektbaum derart zu verschieben

und dessen Gröÿe zu variieren, so dass der Benutzer optimal damit arbeiten kann. Der

Prozess der Editierung an sich benötigt im einfachsten Fall keine Kommunikation mit

einem Server, da die Änderungen zunächst lokal erfolgen.

Persistierung: Nach Abschluss der Bearbeitung müssen die Änderungen am Projekt ge-

speichert werden2. Verschiedene Exportierungsformate fördern dabei die System- und

2Folgt man einem alternativen Ansatz, kann jede vom Benutzer getätigte Änderung auch direkt an denServer übertragen werden, anstatt das vollständige Projekt am Ende der Bearbeitung dort abzubilden. Vorteildieser Variante ist, dass auch mehrere Nutzer gleichzeitig an einem Projekt arbeiten können und die Verände-

68

Programmunabhängigkeit. Aus Sicht der Geschäftsprozesse ist dies ein wichtiger Punkt,

denn die Übertragung zum Server geschieht typischerweise über einen Web Service.

Programmeinstellungen: Zur komfortableren Benutzung und Anpassung an die Bedürfnis-

se des jeweiligen Nutzers, lassen sich einige Aspekte der Bedienung bzw. des Aussehens

der Anwendung verändern. Diese individuellen Optionen sollten zentral auf dem Server

gespeichert werden, damit die Anpassungen von jedem beliebigem ausführenden Rech-

ner bei Programmstart geladen werden können. Ein Benutzerpro�l beinhaltet dabei für

alle im System registrierten Anwender die jeweils spezi�schen Einstellungen.

Login/Logout zur An- bzw. Abmeldung eines Nutzers am System.

Eine zusätzliche Anforderung ist auch die Folgende: Aktivitäten oder Aufgaben besitzen eine

hierarchische Struktur um Parent-Child-Beziehungen wiederzugeben. Dies ist etwa dann nötig,

wenn Aktivitäten zu einer Gruppe zusammengefasst werden müssen; beispielsweise für einzelne

Projektphasen.

Die Elemente des Gantt-Diagramms, also Aktivitäten, Beziehungen und ihre Ressourcen sollen

durch den Benutzer leicht über Eingabemasken und interaktive Bedienelemente editierbar

sein. Beispielsweise können die Dauer bzw. die Start- und Endzeit einer Aktivität durch ein

Vergröÿern oder Ziehen am Aktivitätsbalken verändert werden. Alternativ lassen sich diese

Werte auch in der zugehörigen Tabellenspalte oder in Dialogfenstern mit Tastatureingaben

anpassen. Zur besseren Übersicht über die Aufgaben soll der Maÿstab der Zeitleiste variabel

sein. Damit kann das Projekt in gewünschtem Detailgrad skaliert werden, um z.B. nicht nur

den ungefähren Startzeitraum einer Aktivität innerhalb eines Monats, sondern auch die genaue

Uhrzeit am Starttag sichtbar zu machen.

Mögliche Benutzereinstellungen die ein Anwender vornehmen kann sind z.B.

• Automatisches Ö�nen des Dialoges zur Editierung einer Aktivität oder Ressource, direkt

nachdem eine neue Zeile dem Diagramm hinzugefügt wurde.

• Automatische Laden einer Beispieldatei nach Programmstart.

• Erlauben der Anpassung von Spaltengröÿen und -anordnung.

• Anzeige von Hilfslinien auf der Zeitachse für aktivitäts- oder ressourcenorientierte An-

sichten.

• Anzeige von Tooltips während des Verschiebens einer Aktivität oder Ressource entlang

der Zeitachse

rungen direkt verfolgen können. Nachteil ist der hohe Bedarf an leistungsfähiger Kommunikationsinfrastrukturund eine stabile Datenverarbeitung.

69

• . . .

Hinweis

Einige der hier beschriebenen Anforderungen und Funktionen sind in der Implemen-

tierung der Beispielanwendung aus Zeitgründen nicht realisiert worden. Darunter

fallen z.B. die Unterstützung für mehrere Benutzer und Rollen (�Normalnutzer�, Ad-

ministrator) durch einen Login-Vorgang sowie das Exportieren der Projekte in un-

terschiedliche Dateiformate. Diese Funktionen tragen nicht zum grundlegenden Ver-

ständnis einer Service-orientierten RIA-Architektur bei. Es wurde jedoch bemüht,

den Entwurf so zu gestalten, dass neue Merkmale der Software leicht integriert wer-

den können.

Des Weiteren entfällt eine detaillierte Beschreibung der serverseitigen Komponenten,

da der Fokus dieser Arbeit auf der Rich Internet Application selbst liegt.

70

Kapitel 6

Entwurf

Die Implementierung des Prototypen soll an einem praxisnahen Beispiel eine Service-orientierte,

hoch-interaktive Rich Internet Application und deren Architektur vermitteln. Aus diesem

Grund wurde das Projektmanagement auf die oben beschriebenen Grundfunktionen beschränkt

und einige Vereinfachungen vorgenommen, um sich auf die wesentlichen Aspekte einer solchen

RIA zu konzentrieren. Auÿerdem wurde auf die detaillierte Beschreibung der serverseitigen

Services verzichtet. Der Prototyp konzentriert sich auf die Implementierung der Kernprozesse

und -dienste und nicht auf die gesamte SOA-Architektur.

Da Silverlight Teil des .NET-Frameworks ist, sind beim Entwurf der Anwendung auf die

dortigen Funktionen, Möglichkeiten und Restriktionen zu achten. Als Programmiersprache

soll C# verwendet werden.

6.1 IBM ILOG Gantt for .NET

Bevor mit dem Entwurf der Anwendung begonnen wird, ist hier nun eine kurze Übersicht

über IBM ILOG Gantt for .NET 4.0 gegeben, damit in Kapitel 6.5 die technischen Grundla-

gen des Datenmodells näher erläutert werden können. Auf eine detaillierte oder vollständige

Beschreibung wird hier verzichtet, denn die Möglichkeiten die mit diesem Framework dargebo-

ten werden sind sehr vielfältig. In den Kapiteln 6.5 und 7 wird näher auf einzelne verwendete

Klassen des Frameworks eingegangen. Weitere Themen können z.B. in (IBM, 2009a) und

(IBM, 2009c) nachgelesen werden.

IBM ILOG Gantt for .NET beherbergt Komponenten mit Visualisierungsmöglichkeiten für

Gantt-Diagramme und eine umfassende Logik zu deren Steuerung und Anpassung. Die für

die Silverlight-Plattform verwendbaren Klassen und Controls sind in Bezug auf Funktion und

71


Umfang zu denen der für WPF ebenfalls verfügbaren ILOG Gantt Version reduziert, bieten

aber immer noch eine ausreichende Menge an Möglichkeiten. Beispielsweise steht der XML-

Serialisierer für Gantt-Projektmodelle in Silverlight nicht zur Verfügung und muss in der

Beispielanwendung manuell erstellt werden.

Das Framework bietet viele Eigenschaften, Funktionen und Möglichkeiten, deren detaillierte

Beschreibung nicht Ziel dieser Arbeit sein soll. Dennoch sind für dessen Verwendung einige

Merkmale erwähnenswert, die im Folgenden erläutert werden.

Abb. 6.1: Die Klassen der ChartControls

Die Bibliotheken stellen u.a. die zwei wichtigen Controls GanttChart und ScheduleChart zur

Verfügung, mit denen Gantt-Diagramme aktivitätsorientiert bzw. ressourcenorientiert darge-

stellt werden können. Die Klassen leiten von HierarchyChart ab, dessen Verwendung auf

S. 101 beschrieben ist. Abbildung 6.1 zeigt die in den Klassen enthaltenen Properties und

Methoden. Sie bieten z.B. Optionen zum Anpassen der Darstellung oder Events, die gefeuert

werden sobald der Nutzer das Gantt-Diagramm editiert. Einige der Properties werden in den

Folgenden Kapitel näher erläutert. Zur besseren Übersicht wurde das Klassendiagramm um

72


diverse, in diesem Kontext unwichtige Elemente reduziert.

Die Visualisierung der beiden Diagramme orientiert sich dabei an den klassischen, oben be-

schriebenen, Vorstellungen vom Aussehen eines Gantt-Diagrammes. Die Charts sind modu-

lar aufgebaut und bestehen (visuell) aus den Komponenten Table, welche links zeilenweise

Aktivitäts- oder Ressourceninformationen au�isten und GanttSheet bzw. ResourceSheet, die

rechts davon die zugehörigen Aktivitäts- oder Ressourcen-Balken entlang einer Zeitachse bein-

halten.

Bei ILOG Gantt for .NET existieren zudem Klassen, welche die Entitäten aus den Anforderun-

gen repräsentieren können. Dies sind beispielsweise SimpleActivity oder SimpleResource.

Sie können grundlegende Attribute und Logik einer solchen Entität beinhalten (z.B. Name,

StartTime, EndTime, Duration, Parent, isMilestone, etc.).

Umfassendere Möglichkeiten der Projektplanung bieten jedoch die Scheduling-Klassen Sche-

dulingActivity, SchedulingResource usw., welche unter Berücksichtigung eines Kalenders

(z.B. WorkCalendar für gängige tägliche Arbeitszeiten) automatisch zeitlich angeordnet und

für das Projekt optimiert werden können. Dieses Leveling der Entitäten lässt sich natürlich

beein�ussen. Beispielsweise wird der vollständige Zeitplan des Gesamtprojekts jedesmal er-

neut berechnet, falls sich die Dauer einer einzelnen Aufgabe verändert. ILOG kalkuliert die

nötigen zeitlichen Veränderungen an anderen Aktivitäten automatisch und führt sie aus. Die

Property Duration der SchedulingActivity-Klasse repräsentiert in diesem Zusammenhang

die Arbeitszeit, welche benötigt wird, um die Aufgabe komplett zu beenden. Bei deren Be-

rechnung wird der zu Grunde liegende Kalender, welcher Arbeits- und Freizeiten de�niert,

berücksichtigt.

So kann es beispielsweise vorkommen, dass man eine dreistündige Aufgabe für Freitag, 15 Uhr

ansetzt, die dann aber im Projektplan nicht um 18 Uhr am selben Tag endet, sondern erst am

kommenden Montag (nach dem Wochenende) um 9 Uhr, da die Aktivität mit arbeitsfreien

Zeiten überschneidet. Im Standard-Kalender hat jeder Arbeitstag (Montag bis Freitag) eine

achtstündige Schicht von 8 bis 17 Uhr mit einer Mittagspause von 12 bis 13 Uhr.

Abbildung 6.2 gibt eine Übersicht aller ö�entlichen Attribute der Scheduling Klassen von

ILOG Gantt for .NET. Die Funktion der Properties ist in den meisten Fällen bereits am

Namen ersichtlich und soll daher i.A. hier nicht weiter erläutert werden.

Die wichtigsten Attribute der SchedulingActivity-Klasse sind StartTime (die Startzeit der

Aktivität, EndTime bzw. Duration (zum Festlegen einer Aufgabendauer), IsCritical, IsMi-

lestone und IsSummary (zur teilweise durch ILOG selbst geregelten, automatischen Typisie-

rung einer Aktivität) sowie das geerbte Parent-Attribut für Hierarchien.

Eine Instanz vom Typ SchedulingResource beinhaltet u.a. eine Property für die Aktivitäten,

73


Abb. 6.2: Übersicht der Scheduling Klassen von ILOG Gantt

74


zu welchen sie mittels Reservierungen1 zugeordnet wurde. Das bedeutet, dass jede Ressource

des Projektes auch stets darüber Bescheid weiÿ, wo und wie sie im Projekt eingeplant wurde.

Das ProjectSchedulingModel (siehe weiter unten) hält dabei die Informationen stets aktuell

und konsistent.

Die Klasse SchedulingConstraint repräsentiert eine Beziehung zwischen genau zwei Sche-

dulingActivity-Instanzen. Diese werden in den Attributen FromActivity bzw. ToActivity

referenziert, wobei der Typ der Relation durch einen enum-Wert gesetzt wird.

Eine SchedulingReservation spiegelt die Reservierung einer Ressource wider. Sie ist logi-

scherweise nur dann gültig, wenn sowohl deren Property Activity, als auch Resource gesetzt

wurden.

Daneben ist leicht zu erkennen, dass sowohl Aktivitäten als auch Ressourcen von einer Klasse

erben, die ein Parent-Attribut einer Activity de�niert, sodass beide Klassen von hierarchischer

Struktur sein können. Damit ist es möglich die in den Anforderungen benötigte Parent-Child-

Beziehungen umzusetzen. Das Parent-Attribut nimmt in diesem Kontext eine Aktivität vom

Typ SchedulingActivity entgegen.

Ebenso erben alle hier beschriebenen Klassen von GanttData, welches das PropertyChanged-

Event bereitstellt um beispielsweise Elemente der Benutzerober�äche auf Änderungen der

Daten aufmerksam zu machen.

Hinweis

Entgegen der Beschreibung der SchedulingResource-Klasse in der Dokumentati-

on von IBM ILOG Gantt for .NET, war es nicht möglich eine hierarchische Bezie-

hung zwischen Ressourcen herzustellen. Auch ein von IBM mitgeliefertes Beispielpro-

gramm unterstützt dies nicht.

Weiterhin sind im Diagramm verschiedene enum-Typen dargestellt. Z.B. gibt ActivityCons-

traintType über die Art einer Beziehung zwischen zwei Aktivitäten Auskunft. Der Resour-

ceType beschreibt eine Ressource näher und LagFormat de�niert für das Leveling der Diagram-

me verwendete Werte. Diese Typen werden in der Praxisanwendung nicht explizit verwendet,

weshalb eine genauere Beschreibung hier nicht nötig ist.

Verwaltet werden diese Klassen und Funktionen im ProjectSchedulingModel, einer Klasse

die die Entitäten und ihre Beziehungen zueinander beherbergt und verwaltet. Das Klassendia-

gramm ist in Abbildung 6.3 gegeben und zeigt ö�entlich zugängliche Elemente.

Die Klasse berechnet die optimalen Zeitpläne und verwaltet das Projekt. Sie dient zudem

als Grundlage für den Gantt- bzw. ScheduleChart und wird in der Silverlight Beispielanwen-

1In diesem Kontext als ReadOnlyCollection, da Reservierungen vom ProjectSchedulingModel und nichtvon den Ressourcen selbst verwaltet werden.

75


dung verwendet und an diese referenziert, sodass die Diagramme daraus erzeugt und visuell

dargestellt werden können.

Abb. 6.3: Die ProjectSchedu-

lingModel-Klasse

Die wichtigsten Properties des ProjectSchedulingModels wer-

den geerbt: die Listen Activities, Resources, Constraints

und Reservations. Daneben bietet es einige Optionen zum

Gantt-Diagramm, wie ein automatisches Berechnen der op-

timalen Aufgabenzeiten (AutomaticResourceLeveling vom

Typ bool) oder ein Projektweit gültiges StartDate (Startda-

tum des Projekts), anhand dessen alle Aufgaben ausgerichtet

werden.

Mit den Methoden Begin- bzw. EndScheduleSession() sol-

len hier erwähnt werden, denn mit ihnen kann kurzzeitig das

automatische Leveling der Aufgaben temporär unterbunden

bzw. wieder gestartet werden, um beispielsweise manuell ei-

ne Aktivität zu editieren. Denn bei einem solchen Vorgang

ist es wünschenswert, dass die endgültige Einpassung in das

Gantt-Projekt erst dann vorgenommen wird, wenn die Ak-

tivität auch wie gewünscht bearbeitet und festgelegt wurde.

Ansonsten würde das ProjectScheduleModel ständig versu-

chen, die Aufgabe (mit möglicherweise unvollständigen Da-

ten) passend im Diagramm unterzubringen.

Ein weiteres Feature das das Framework mit sich bringt ist ei-

ne hohe Interaktivität der Controls: Komponenten wie Aufga-

ben, Ressource oder Beziehungen sind intuitiv mit der Maus

veränder- und verschiebar. Die Ansicht des Projektplans lässt

sich bei gedrückter Maustaste bewegen, sodass der Nutzer navigieren und sich leicht orientie-

ren kann.

Zur Anpassung des Aussehens der Controls von IBM ILOG Gantt for .NET bietet das Frame-

work einerseits vorgefertigte Templates und Styles. Andererseits sind auch benutzerde�niert

Möglichkeiten gegeben um die Ansicht des Projektplans visuell nach eigenen Wünschen zu

verändern (z.B. Aussehen der Aktivitätsbalken, allgemeine Diagrammhintergründe, Darstel-

lung der Beziehungen durch Pfeile, Spaltende�nitionen, alternierende Zeilenhintergrundfarbe,

Mauszeiger usw.). Eigene visuelle Anpassungen am Gantt-Diagramm werden in Kapitel 7.1.3

beschrieben.

Als Kritikpunkt zu diesem Framework ist anzumerken, dass bei gröÿeren Projekten die Leis-

tungsfähigkeit der Anwendung leidet und manche Aktionen verzögert ausgeführt werden. Al-

76

6.2 Gesamtarchitektur: Das Model-View-ViewModel-Entwurfsmuster

lerdings lieÿ sich nicht genau feststellen, ob dies an den zahlreich verwendeten Silverlight-

Komponenten von ILOG Gantt liegt oder an den dortigen, zu Grunde liegenden Datenstruk-

turen.

6.2 Gesamtarchitektur: Das Model-View-ViewModel

Entwurfsmuster

Für eine Silverlightanwendungen bieten sich verschiedene, mehrschichtige Software-

Entwurfsmuster an, die hier kurz vorgestellt werden. Gemeinsam ist allen ihre n-tier Architek-

tur, sowie die Möglichkeit eine serverseitige Ebene hinzuzufügen, dabei jedoch möglichst eine

lose Kopplung aller Schichten zu erhalten.

1. Das Model-View-Controller (MVC)-Muster verwendet drei voneinander getrennte

Ebenen. Das Model kapselt Daten und interne Systemzugri�e, die Ansicht (View) ist

die Benutzerober�äche und der Controller ist die programmgesteuerte Schnittstelle zwi-

schen Ansicht, Modell und Benutzereingabe, welche gegenseitige Zugri�e steuert und

reglementiert. Dieses Muster funktioniert jedoch für deklarative Benutzerober�ächen

wie bei Silverlight nicht optimal, da XAML ebenfalls einen Teil der Schnittstelle zwi-

schen der Eingabe und der Ansicht de�nieren kann (da Datenbindung, Trigger und

Zustände in XAML deklariert werden können). Es kommt zu einer nicht erwünschten

Vermischung der Schichten.

2. Model-View-Presenter (MVP) ist ein anderes, häu�g verwendetes Muster, ähnlich

des MVC. Im MVP-Muster ist jedoch der Presenter für das Festlegen und Verwalten des

Zustands einer Ansicht verantwortlich. Genau wie MVC passt MVP nicht hundertpro-

zentig zu Silverlight, da ebenfalls die deklarative Datenbindung von XAML, z.B. Trigger

und Statusverwaltung enthalten könnte.

3. Das Model-View-ViewModel (MVVM) ist eine Anpassung des MVC- und MVP-

Musters, welches aus deren Schwächen aber den Stärken von XAML (insbesondere des

dortigen Data Binding-Konzepts) hervorgegangen ist. Die View ist eine Mischung aus

XAML mit nur sehr geringen Anteilen an Code-Behind-Dateien und stellt reine ansichts-

pezi�sche Logik, wie die Steuerung von Animationen oder Stylezuweisungen bereit. Das

ViewModel liefert die zugehörige Steuerungslogik und bildet eine Brücke zum Model. Es

ermöglicht der Ansicht (View), sich deklarativ an das ViewModel zu binden und so die

bereitgestellten Komponenten zu nutzen. Das Model stellt wiederum die Daten dar und

ist besonders wichtig, da es den Zugri� auf die Daten umschlieÿt, und zwar unabhängig

davon, ob der Zugri� durch einen Satz von Webdiensten oder eine andere Form des

77


Datenabrufs erfolgt. Es ist komplett vom ViewModel getrennt, sodass das Datenmodell,

die View und das ViewModel jeweils isoliert von den anderen Ebenen getestet werden

können. In der Praxis erlaubt das MVVM es, dass Designer kaum oder gar keinen Code

schreiben müssen, um sich voll auf den Ober�ächenentwurf zu konzentrieren, während

Programmierer für ViewModel und Model verantwortlich sind.

Das MVVM geht auf Martin Fowler zurück, der 2004 erste Ansätze und Gedanken,

damals unter dem Begri� des �Presentation Model�, verö�entlichte (Fowler, 2004).

(Vgl. Wildermuth, 2009)

Eine enge Kopplung zwischen den Schichten einer Anwendung entsteht, wenn eine Ebene In-

formationen darüber hat, wie eine andere ihre Arbeit ausführt. Müssen Anpassungen in einer

Schicht gemacht werden, müsste in allen gekoppelten Ebenen die Änderung synchronisiert wer-

den und sie hätte globale Auswirkungen. Dies ist vor allem dann kritisch, falls eine modulare

und gekapselte Architektur erwünscht ist, die möglichst austauschbare oder wiederverwend-

bare Komponenten nutzen soll. Problematisch kann es ebenfalls sein, Komponententests auf

den einzelnen Anwendungsschichten durchzuführen, um sie separat zu validieren.

Diese Punkte sprechen für eine lose Kopplung, bei der die Ebenen nur über wenige Schnitt-

stellen miteinander in Verbindung stehen. Das MVVM-Entwurfsmuster bietet sich daher als

ideale Architektur für das Praxisbeispiel an. Abbildung 6.4 verdeutlicht das Model-View-

ViewModel für Silverlight sowie die Beziehungen der Ebenen untereinander.

Die View enthält überwiegend XAML-Code zur reinen Ober�ächenbeschreibung und wird

nur geringfügig durch eine eigene Code-Behind-Datei im klassischen Sinne unterstützt. Spezi-

�sch für die einzelne View kann dort in den *.cs-Dateien, Programmlogik zur Steuerung von

visuellen Elementen der Ober�äche implementiert werden. Wird das MVVM-Muster strikt

befolgt, �ndet sich dort kein Code, auÿer der vom Framework erzeugten Initialisierungslogik

(z.B. InitializeComponent()). Das MVVM ist jedoch eine Richtlinie, keine zu befolgende

Regel. So kann es im Einzelfall durchaus angebracht sein, in den Code-Behind-Dateien weitere

Programmlogik anzugeben.

Steuerung, Entgegennahme von Eingaben, Weitergabe der Daten, Validierung und die Event-

behandlung von Benutzeraktionen (und einigen Model-Ereignissen) übernimmt das ViewMo-

del, welches lose über Silverlights Data Binding-Mechanismen an die Ansicht gebunden ist.

Dazu werden im ViewModel ö�entliche Properties bereitgestellt, die (bei Bedarf) im XAML-

Code der View referenziert werden.

Auf diese Weise hat das ViewModel keine Kenntnisse über ansichtsspezi�sche Merkmale, so-

dass eine beliebige View daran gebunden werden kann. Es stellt die Werte nur zur Verfügung,

ohne zu wissen wer/was sie benutzt. Beispielsweise kann eine Hauptober�äche für Silverlight

erstellt werden und zusätzlich eine WPF-basierte für andere Zwecke (z.B. Administration).

78


Abb. 6.4: Das Model-View-ViewModel für Silverlight

Möchte man die Anwendung um eine kompaktere, für mobile Endgeräte nutzbare (Windows

Phone 7) Ansicht erweitern, benutzt man ebenfalls das selbe ViewModel und wählt daraus

die benötigten Properties zur Anzeige der reduzierten Ober�äche.

Die Steuerungsebene ist also einerseits (nur) ein Bindeglied zwischen Ober�äche und Daten,

leistet aber andererseits die wichtige Aufgabe der Kontrolle und behält insgesamt den verwal-

tenden Überblick über die Anwendung, indem es dort Daten validiert und weiterleitet. Alle

ViewModel-Klassen sollten so implementiert werden, dass sie auch ohne die View instanziiert

und somit getestet werden können. (Thomas Claudius Huber, 2007).

Anschaulich gesprochen hält das ViewModel alle Fäden zusammen und dirigiert das Zusam-

menspiel der einzelnen Akteure � ähnlich dem Halten der Fäden eines Marionettenspielers.

Das Model kapselt das zu Grunde liegende Datenmodell und stellt es für das ViewModel be-

reit. In diesem sind z.B. business objects und Schnittstellen für den Zugri� auf Web Services

enthalten. Ein das Model beschreibendes Interface hält dazu alle notwendigen Attribute, Me-

thoden und Events fest und kann bei Bedarf für andere Implementierungen verwendet werden

(z.B. Tests). Diese Schnittstelle wird vom ViewModel benutzt und bildet die Kommunikati-

onsbasis zwischen den beiden Ebenen ohne dabei dem Aufrufer spezi�sche Prozesskenntnisse

zu vermitteln.

79


Die im Interface de�nierten ö�entlichen Methoden geben jedoch keine Daten zurück denn

sie sind mit der Signatur public void gekennzeichnet. Stattdessen lösen sie entsprechende

Ereignisse für Erfolg oder Fehlschlagen des Prozesses aus, welche vom ViewModel abonniert

werden. Die Resultate der Methoden sind in den übermittelten Parametern der Events ent-

halten (Event-Arguments) und so auf Empfängerseite erreichbar. Dieses Verhalten ermöglicht

eine zeitlich versetzte Ausführung, um der Silverlight-Anforderung für asynchrone Netzwerkak-

tivität nachzukommen (siehe Abb. 6.8 und 6.9).

Auch hier hat das Model also keinerlei Wissen, welche Komponenten auf die Events reagieren,

sodass eine lose Kopplung auf beiden Seiten vorliegt.

(Vgl. Wildermuth, 2009)

Alternativ zur Weitergabe von Daten über die EventArgs kann auch in jeder Methode des

Models, die vom ViewModel aufgerufen wird, die Instanz des ViewModels als Parameter

übergeben werden. Anstatt die errechneten Daten über einen Event weiter zu reichen, können

diese so direkt in das ViewModel geschrieben werden. Der Nachteil an dieser Lösung, ist die

entstandene Bindung, da eine Instanz des ViewModels übermittelt wird und das Model damit

über die Steuerungslogik Bescheid weiÿ. Kommt ein anderes ViewModel zum Einsatz muss

das Model auch mit diesem umgehen können.

Ein Nachteil des MVVM-Musters ist die wachsende Komplexität der Codestruktur, denn es

ist deutlich mehr Quelltext zu entwerfen und schreiben als bei reinen Code-Behind-Dateien.

Jede Aktion muss sorgfältig untersucht und auf die einzelnen Schichten verteilt werden. Gleich-

zeitig steigt jedoch das Abstraktionsniveau der Anwendung, indem die Komponenten leicht

austauschbar sind und sich ggf. durch andere ergänzen lassen.

Des Weiteren ist nicht gesichert, dass die Ober�ächendesigner (und Expression Blend) auch in

Zukunft mit immer komplexeren Data Binding-De�nitionen umzugehen wissen. Die Arbeits-

teilung zwischen dieser Gruppe und den Programmierern der Logik kann daher in manchen

Fällen nicht gewährleistet werden.

Ebenfalls kritisch anzumerken ist eine Unterstützung und Kompatibilität des MVVM durch

Controls von Drittherstellern, welche häu�g eigene Steuerungslogik kapseln anstatt sie, wie

das Entwurfsmuster fordert, im ViewModel unterzubringen. (Thomas Claudius Huber, 2007)

Anhand dieser Überlegungen zeigt Abbildung 6.5 die daraus resultierenden vier notwendigen

Schichten des Praxisbeispiels. Die austauschbare View wird via Silverlights Data Binding an

das ViewModel gebunden. Dieses steht wiederum über das Interface des Model (IModel) mit

diesem in Verbindung, welches alle benötigten Daten bereitstellt und ggf. vom Server neue

empfängt.

Der Service-orientierte Ansatz einer Silverlightanwendung erlaubt dem Model die Verwendung

von Web Services zur serverseitigen Datenbescha�ung im Sinne einer SOA. Der Client ist da-

bei Konsument und löst die Anfrage aus. Wird die Antwort dann empfangen, muss sie in der

80


Abb. 6.5: MVVM-Schichten der Beispielanwendung

Regel erst, beispielsweise aus einem XML-Dokument heraus, in verwendbare Objekte umge-

wandelt und in das bestehende Datenmodell integriert werden.

Das Model der Praxisanwendung erhält z.B. einen string mit XML-Struktur von einem

datengetriebenen Service. Die Zeichenkette beinhaltet u.a. alle Aktivitäten, Ressourcen, Be-

ziehungen und Reservierungen des angeforderten Gantt-Projekts (siehe Kapitel 7.1.1). Liegt

ein bekanntes Schema des XML-Dokuments vor, werden daraus dann die einzelnen Entitäten

herausgelesen und, umgewandelt als C#-Objekte, instanziert. Die ProjectSchedulingModel-

Klasse, welche die Gantt-Diagrammdaten verwaltet, kann daraufhin mit den übermittelten

Daten erstellt werden und das Projekt letztendlich den GanttCharts bzw. ChartControls

zur Verfügung stellen.

Abbildung 6.6 zeigt exemplarisch den stark vereinfachten Ablauf der Initialisierung eines

Gantt-Projekts aus einer XML-Datei, welche von einer XML verarbeiteten Komponente gele-

sen bzw. geschrieben wird.

Abb. 6.6: Vereinfachter Ablauf des Projektinitialisierungsprozesses

Ein wichtiges Konzept, ohne das die Realisierung des MVVM mit Silverlight nur schwer umzu-

setzen ist, sind die Commands. In Code-Behind-Dateien werden normalerweise die von den

Elementen der GUI gefeuerten Events behandelt und so auf (Benutzer-)Aktionen reagiert.

Das neue Entwurfsmuster fordert nun dies aufzugeben, um die Trennung der Schichten nach-

zukommen. Da eine einfache Umleitung der Events in den Code-Behind-Dateien an andere

81

6.3 Komponenten der Anwendung

Teile der Anwendung zwar möglich (wie bei o.A. (2010) beschrieben), aber weniger vorteil-

haft wäre, bietet sich das Modell der Commands an. Mit diesen lässt sich Funktionalität

abstrahieren, kapseln und dort unterbringen wo sie benötigt wird. Mit Hilfe der in den In-

teractivity-Namespaces (siehe S. 44) eingeführten EventTriggern können Commands an

beliebige Events und Controls gebunden werden und sind nicht nur an Buttons oder Hyper-

linkButtons angewiesen.

Die Commands, kann man leicht in die Ebene des ViewModel integrieren. Sollen andere

ViewModels für ein Programm eingesetzt werden, sind in der Regel abweichende Aktionen

und Funktionalitäten gewünscht, sodass die Commands nicht isoliert von diesem betrachtet

werden müssen. Ein Command selbst erhält somit auch (indirekt über das ViewModel) Zugri�

auf das genutzte Model und auf die GUI, sodass alle benötigten Informationen erreichbar sind.


Das Praxisbeispiel kann (unabhängig von den Schichten des MVVM) in einzelne Kompo-

nenten aufgeteilt werden, die sich im modellhaften Komponentendiagramm (Abbildung 6.7)

wieder�nden. Diese werden im Folgenden erläutert. Die dort nicht dargestellten Helferklassen

und der ViewModelLocator sind für die Beschreibung der restlichen Komponenten und des

MVVM nicht von groÿer Relevanz. Letztere Klasse wird vom MVVM Light Toolkit (S. 96

erzeugt und kann bei Bedarf mehrere ViewModels verwalten und bindet bzw. wählt das für

die View passendste aus.

Abb. 6.7: Komponentendiagramm der Anwendung

82


Die Komponente, mit der die Anwender direkt in Kontakt kommen, ist die der graphischen

Benutzerober�äche. Sie enthält die visuellen Elemente, welche zum Groÿteil ausschlieÿlich

in XAML de�niert sind und spiegelt die oberste Schicht (die View) des MVVM in der An-

wendung wieder. Die anderen hier beschriebenen Komponenten sind teilweise in ihr integriert

(z.B. die Chart Controls). Die Benutzerober�äche verwendet eine Instanz des ViewModels um

Daten und Funktionalität zu erhalten.

Das Chart Control bzw. die Editor-Komponente ist für die Visualisierung und Editierung

der Gantt-Diagramme bzw. ihrer Daten verantwortlich. Die Darstellung ist entsprechend in

zwei Modi, aktivitätsorientiert und ressourcenorientiert, aufgeteilt. Viele der darin enthalte-

nen Funktionen sind Bestandteil der Bibliotheken von ILOG. Programmatische Anpassungen

an diesen betre�en v.a. die visuellen Aspekte (Spalten, Balkentypen, Styles, etc.) und die Be-

handlung von dort gefeuerten Events. Die Controls werden vom Model instanziert und dort

für die View über das ViewModel bereitgestellt (siehe Kapitel 7.1.2).

Das ViewModel stellt einen der wichtigsten Bereiche der Anwendung dar, denn dort �ndet

die Steuerung und Verwaltung der Daten statt. Wie in Kapitel 6.2 bereits beschrieben, werden

dort die Commands, also die Funktionalität, beherbergt und das Model instanziert. In den

Abbildungen 6.8 und 6.9 wird deutlich, warum das ViewModel eine zentrale Rolle spielt:

nahezu alle Aktionen der Anwendung werden dort dirigiert, weitergereicht oder verwaltet.

Die Command-Komponente, welche im Praxisbeispiel in das ViewModel integriert ist, kap-

selt mehrere Commands für Aktionen und Funktionalitäten der Silverlightanwendung. In ihr

sind einzelne Commands und ihre zugehörigen Methoden de�niert, die von der Steuerungslo-

gik des ViewModels aufgerufen werden können. Die Commands-Klasse registriert sich auch

auf einige Events des Models, sodass etwa bei Abschluss einer Datenanfrage der zugehöri-

ge Command direkt durchgeführt werden kann, ohne einen Umweg über das ViewModel zu

nehmen.

ImModel be�nden sich die eigentlichen Daten der Anwendung, die zur Verwendung durch die

anderen Komponenten über ein Interface bereitgestellt werden. Des Weiteren enthält es Me-

thoden zum Umgang mit dem Datenmodell und den Web Services, um anderen Komponenten

Zugri� auf den Server bzw. dessen Dienste zu ermöglichen. Wie weiter oben beschrieben, be-

sitzen die ö�entlichen Methoden des Models nur indirekt Rückgabewerte. Sie sind mit public

void gekennzeichnet und lösen nach erfolgreichem Abschluss oder bei Fehlern Events aus, die

vom ViewModel abonniert werden. Dort wird dann entsprechend auf aufgetretene Probleme

reagiert oder die über die Event-Argumente übermittelten Rückgabewerte verarbeitet.

Die serverseitigen Web Services werden vom Model aufgerufen. Ihre Antworten werden

empfangen, in verwendbare Objekte umgewandelt und an die anderen Komponenten weiter-

gereicht. Die Dienste selbst erhalten ihre Daten in der Regel aus Datenbanken und sollen hier

83


nicht näher erläutert werden.

Die ILOG-Komponente umfasst die Klassen der Bibliotheken von IBM ILOG Gantt for .NET.

Dies sind z.B. das ProjectSchedulingModel, die Entitäten (SchedulingActivity, Schedu-

lingResource, SchedulingConstraint, SchedulingReservation), die Controls zur Darstel-

lung der Gantt-Diagramme (GanttChart, ScheduleChart) und Teile der zugehörigen Logik

für deren Steuerung durch den Benutzer.

Eine Komponente die ausschlieÿlich das Model (oder ein Web Service) verwendet ist die

der Datei-Ein- und Ausgabe. Mit ihr z.B. können XML-Dokumente eingelesen bzw. ge-

schrieben werden, die Gantt-Projekte beinhalten. Für die Persistierung von Daten ist diese

Komponente neben den Web Services unerlässlich.

Die im Praxisbeispiel nicht implementierte Login-Komponente soll die Logik der Nutzer-

verwaltung (z.B. Login, Logout) bereitstellen. Sie erlaubt das Silverlightprogramm im Mehr-

benutzerbetrieb auszuführen und so den Einsatz der Anwendung im realen Geschäftsalltag,

wo ein Projekt durchaus von verschiedenen Mitarbeitern (evtl. mit verschiedenen Rollen und

Rechten) bearbeitet werden kann. Die Komponente muss dabei sowohl Authenti�zierung, Au-

torisierung und Sicherheitsaspekte, als auch Probleme der Nebenläu�gkeit von Aktionen auf

dem Server berücksichtigen.

Abbildungen 6.8 und 6.9 (S. 86 bzw. 87) verdeutlichen, anhand von zwei Benutzeraktionen,

exemplarisch die Abläufe der einzelnen Prozesse und Methodenaufrufe zwischen den Anwen-

dungsschichten. Nachfolgend werden die Abbildungen schrittweise erläutert. (Da die Comman-

ds Teil des ViewModels sind, fehlt diese Komponente in den Darstellungen. An den unterbro-

chenen Aktivitätsbalken des ViewModels und des Models wird die asynchrone Ausführung

einiger Aktionen deutlich.)

Der Vorgang des Ladens einer Projektdatei vom Server läuft wie folgt ab: Der Benutzer

löst durch einen Mausklick o.ä. auf einen Button (de�niert in der View) das OpenProject-

Kommando des ViewModels aus. Dieser zeigt dem Anwender daraufhin beispielsweise einen

Auswahldialog zur Bestimmung des zu ö�nenden Projektes an. Wurde eine Wahl getro�en,

stellt das ViewModel (bzw. die Commands-Klasse) sicher, dass die nötigen Completed-Events

abonniert sind und fordert vom Model die Projektdaten an. Dieses bestimmt die Quelle der

Daten und wählt in diesem Fall einen serverseitigen Web Service aus. Das Model registriert

sich nun auf den Completed-Event des Web Service um ihn dann asynchron zu starten. Auf

der Ebene des Service Providers startet nun der Dienst zum Ö�nen einer Projektdatei, welcher

diese in ein übertragbares Format (z.B. eine Zeichenkette mit dem XML-Baum als Inhalt) ver-

wandelt und über das Internet an den Konsument (das Model der Anwendung) zurückschickt.

Dort wird der Abschluss des Vorgangs registriert. Enthält der Completed-Event Fehler, kön-

nen diese hier behandelt werden. Anschlieÿend wird die übertragene Zeichenkette (nachdem

84


sie auf Fehler untersucht wurde) in ein verwertbares Objekt umgewandelt und instanziert bzw.

referenziert. Das Model löst bei Abschluss dieser Arbeiten den eigenen Completed-Event aus,

welcher wiederum vom ViewModel (bzw. der Commands-Klasse) bemerkt wird. Die Projekt-

daten werden an das ProjectSchedulingModel weitergereicht und über die View als Gantt-

Diagramm angezeigt.

Während des gesamten asynchronen Vorgangs kann beispielsweise eine Fortschrittsanzeige den

Benutzer über den aktuellen Bearbeitungsstand auf dem laufenden halten.

Ganz ähnlich ist auch der Prozess einer Projekteditierung, bzw. der Speichervorgang an sich

ab. Das bereits geladene Gantt-Diagramm wird vom Benutzer über diverse Commands ver-

ändert, welche (neben den Silverlight-Validatoren) für die Korrektheit der Daten sorgen. Das

ViewModel steuert diese und dirigiert die jeweiligen Akteure um beispielsweise das Model

aktuell zu halten.

Gibt der Anwender den Befehl zum Speichern des Gantt-Diagramms wird erneut ein eigener

Command ausgelöst, der sich auf das Completed-Event des Models registriert und dort die

Methode zum Speichern aufruft. Diese serialisiert die aktuelle Instanz der ProjectSchedu-

lingModel-Klasse in ein XML-Dokument, welches von einemWeb Service des Servers entgegen

genommen werden kann, um dort etwa in einer Datenbank abgelegt zu werden. Die beiden

Completed-Events des Web Services bzw. des Models benachrichtigen wiederum das ViewMo-

del über den Status der Übertragung, sodass ein Hinweis auf (Miss-)Erfolg an den Benutzer

weitergegeben wird.

85


Abb. 6.8: Sequenzdiagramm Projekt ö�nen

86


Abb. 6.9: Sequenzdiagramm Projekteditierung

87

6.4 Entwurf zur Realisierung der Funktionalitäten


Dieses Kapitel vertieft einige Überlegungen aus der Anforderungsanalyse zur Funktionalität

und versucht ein Konzept zu erarbeiten, wie diese umgesetzt werden können.

Zur Bereitstellung allgemeiner (Laden, Speichern, . . . ) und spezieller Funktionalitäten (neue

Aktivität anlegen, . . . ) sind Methoden nötig, die bestimmte Aktionen innerhalb der Anwen-

dung realisieren. Der Benutzer soll die Möglichkeit haben das Programm intuitiv nach be-

währten Vorgehensweisen einer klassischen Desktopanwendung, zu bedienen. Die bereits in

den Anforderungen entwickelten Aspekte zur Bedienbarkeit, sollen daher hier vertieft und

deren Realisierungsmöglichkeiten betrachtet werden.

Die zu erfüllende Funktionalität beinhaltet allgemein folgende Punkte:

• Ein neues, leeres Gantt-Projekt anlegen, das mit Aktivitäten, Ressourcen, etc. gefüllt

werden kann. Dazu ist die Erstellung einer neuen Instanz von ProjectSchedulingModel

nötig.

• Ein bestehendes Projekt ist vom lokalen Anwendungsrechner zu ö�nen. Alternativ kann

auch ein Server mit dahinter stehender Datenbank als Quelle dienen. Die zu ö�nende

Datei liefert in beiden Fällen ein XML-Dokument, welches zu einem Objekt vom Typ

ProjectSchedulingModel konvertiert werden muss.

• Nachdem das Gantt-Diagramm fertig erstellt wurde, sollte es gespeichert werden. Dies

kann wieder entweder lokal oder serverseitig erfolgen.

• Wählt man eine Zeile des Diagramms aus (also eine Ressource oder eine Aktivität), darf

diese nicht nur über Mausaktionen (z.B. durch verschieben oder in die Länge ziehen)

editierbar sein. Eine umfangreicherer Editier-Perspektive kann hier als Lösung dienen,

die detaillierte Optionen zur Anpassung der aktuellen Zeile beinhaltet.

• Um das Gantt-Diagramm mit Inhalten zu füllen, ist eine Funktion zum Hinzufügen von

Aktivitäten, Ressourcen, Reservierungen und Beziehungen erforderlich. Ebenso sollten

bestehende Elemente wieder entfernt werden können, ohne dabei die gesamte Projekt-

struktur aufzulösen.

• Gröÿere Diagramme benötigen unter Umständen viel Platz auf dem Bildschirm. Da-

her muss die Ansicht so bewegt und skaliert werden können, dass der Anwender nicht

den Überblick verliert. Das Projekt sollte auf Knopfdruck in die zur Verfügung stehen-

de Fenstergröÿe eingepasst werden können. Ebenso ist eine Funktion zum Hinein- und

Herauszoomen wichtig. Z.B. auf diese Weise: sobald man das Mausrad dreht, wird das

88


Projekt vertikal gescrollt; drückt und hält man dabei die Strg-Taste fest, wird das Dia-

gramm in der Gröÿe skaliert � der Kalender wird also detaillierter oder übersichtlicher.

IBM ILOG Gantt bietet bereits nativ die Möglichkeit das Projekt durch �Festhalten�

mit der Maus horizontal zu bewegen. Auch Methoden zum Zoomen sind dort integriert.

• Benutzerde�niert Programmeinstellungen erleichtern die individuelle Handhabung der

Anwendung. Zur Anpassung der Optionen kann wieder ein eigenes Fenster bereitgestellt

werden, in dem diese thematisch gruppiert sind.

• Eine Funktion darf nur dann für den Nutzer verfügbar sein, wenn sie auch logisch zu

der aktuellen Programmsituation passt. Dies verhindert unerwartete Fehler in der An-

wendung und vereinfacht den Umgang, indem z.B. nur diejenigen Buttons aktiviert sind,

die gerade benötigt werden. Eine RIA die �mitdenkt�, steigert daher die user-experiance

enorm.

• Sollte dennoch ein Fehler auftreten darf das Programm nicht einfach abstürzen. Excep-

tions müssen daher aufgefangen und ggf. behandelt werden - sei es auch nur durch einen

Hinweis an den Nutzer.

• Da Silverlight die Möglichkeit bietet, die Anwendung auch auÿerhalb des Browsers aus-

zuführen, sollte dies natürlich auch angeboten werden.

• Fallen die Web Services aus bzw. die RIA ist isoliert, sollte eine Art O�ine-Modus

aktiviert werden, der nur eine lokale Speicherung von Daten erlaubt.

Da eine vollständige Analyse zur Realisierung jeder einzelnen oben genannten Funktionalität

den Rahmen der Arbeit sprengen würde, wird im Folgenden eine exemplarisch (aber detail-

liert) beschrieben: das nicht triviale Hinzufügen einer neuen Zeile in das Gantt-Diagramm.

Um Hierarchien zu erzeugen, sind mehrere bedingte Anweisungen nötig. Das Aktivitätsdia-

gramm aus Abbildung 6.10 gibt einen Überblick der dazu notwendigen Schritte.

Zunächst muss überprüft werden, welches Diagramm aktuell sichtbar bzw. ausgewählt ist, um

zu bestimmen, ob einen neue Aktivität oder eine neue Ressource erstellt werden soll. Da die

Möglichkeit besteht beide Entitäten auch in Hierarchien anzuordnen erfolgt anschlieÿend eine

erneute Prüfung. Dazu wird der Wert SelectedIndex des gerade aktiven Diagramms heran-

gezogen, welcher den Index der aktuell selektierten Zeile liefert. Ist dieser kleiner als 0, wird

eine neue Zeile ohne Parent-Attribut erstellt, da der Nutzer keine Aktivität oder Ressource

als Vaterelement gewählt hat. Ansonsten wird der aktuellen Zeile ein neues Kindelement hin-

zugefügt, indem die neu erstellte Entität entsprechend das Parent-Attribut setzt.

Damit ist die Aktion ausgeführt.

Überwiegend sollten (aus zuvor genannten Gründen) Commands die einzelnen Funktionali-

täten innerhalb des Model View ViewModels umsetzen. Besonders die zentrale Aktivierung

89


Abb. 6.10: Aktivitätsdiagramm: Neue Zeile einfügen

bzw. Deaktivierung von Commands erleichtert die Entwicklung der internen Logik. Zu deren

Realisierung ist in Silverlight ein wenig Vorbereitung nötig: das Interface ICommand muss von

einem Command implementiert werden. Abbildung 6.11 zeigt die vom MVVM Light Tool-

kit zur Verfügung gestellten Klassen zur Realisierung von Commands in Silverlight, welche

ICommand implementieren (nicht abgebildet) und so die Entwicklung der Praxisanwendung

unterstützen. Genaueres zur Implementierung auf S. 103.

Abb. 6.11: Die Klassen des RelayCommand und ihre Methoden

Die Klasse ermöglicht sowohl Commands mit (RelayCommand<T>), als auch ohne übergebenen

Parametern (RelayCommand). Solche Parameter werden z.B. beim Erstellen von Beziehungen

(Constraints) zwischen Aktivitäten benötigt, um dem Model die Richtung und Mitglieder der

Beziehung mitzuteilen. Die Attribute FromActivity, ToActivity befänden sich dann u.a. in

diesem Parametern.

Zur Erstellung eines eigenen Commands muss daher nur ein Objekt vom Typ RelayCommand

instanziert werden, anstatt jedes mal erneut ICommand zu implementieren. Dessen Konstruktor

erhält als erstes Argument die beim Auslösen des Commands aufzurufende Methode, sowie

90

6.5 Datenmodell und Datenhaltung

ein optionales boolesches Attribut das angibt, ob der Command verfügbar ist oder nicht. In

der Regel beginnt letzterer Bezeichner mit dem Prä�x �Can� (z.B. CanAddRow). D.h. diese

Attribut steuert die Verwendbarkeit des Commands.

Die Beispielanwendung verwendet im Quelltext für die aufzurufende Methode das Prä�x �Do�

(z.B. DoAddRow()). In ihr wird die eigentliche Funktionalität implementiert, die bei Aufruf

des Commands durchgeführt werden soll.

Im setter der CanExecute-Property ist darauf zu achten, dass neben dem PropertyChanged-

Event, auch der zugehörige Command über die Methode RaiseCanExecuteChanged() bei

Änderungen benachrichtigt wird. Siehe dazu das Beispiel in Listing 7.3 auf S. 103. Wird dies

nicht gemacht, bleibt der Command stets (un- bzw.) ausführbar.

Eine weitere Konvention ist die Benennung von Commands selbst: sie beinhaltet eine Beschrei-

bung der auszulösenden Aktion und zusätzlich die Endung �Command� (z.B. AddRowCommand).

Zusammengefasst sind als zumindest 4 Schritte notwendig um eine Funktionalität in ein

Command-Objekt zu überführen:

1. Das Interface ICommand manuell von jedem neuen Command implementieren oder e�zi-

enter: vorgefertigte Klassen wie RelayCommand verwenden.

2. Neues Objekt vom Typ RelayCommand erzeugen und im dortigen Konstruktor die vom

Command aufzurufende Methode delegieren, sowie das boolesche CanExecute-Attribut

de�nieren.

3. Die Funktionalität des Commands in der DoXYZ()-Methode implementieren.

4. Den setter der CanExecute-Property die Methode RaiseCanExecuteChanged() des Com-

mands (und oft auch den PropertyChanged-Event) aufrufen lassen um Änderungen an

alle mitzuteilen.


Im Folgenden sollen Datenstrukturen gefunden werden, um ein Gantt-Projekt sowohl inner-

halb der Anwendung verwalten zu können, als auch dauerhaft zu speichern. Dabei wird wieder

die serverseitige Ebene der Daten (z.B. in Datenbanken und Tabellen o.ä.) ausgelassen.

ILOG Gantt leistet hier bereits den Groÿteil der internen Datenhaltung der Geschäftslogik und

bietet mit der ProjectSchedulingModel-Klasse ein ausreichendes Datenmodell an (siehe Ka-

pitel 6.1). Darin enthalten sind etwa Collections für Aktivitäten, Ressourcen, Reservierungen

und Beziehungen, um die entsprechenden Entitäten einem Gantt-Projekt entgegen zu nehmen.

91


Für jede dieser Listen müssen also einzelne Objekte instanziert und hinzugefügt werden. Die

ILOG Gantt Klassen SchedulingActivity, SchedulingResource, SchedulingConstraint

und SchedulingReservation bieten sich hier an, da diese alle gewünschten Anforderungen

erfüllen und für das ProjectSchedulingModel konzipiert sind.

Um die Daten nun auch auÿerhalb der Anwendung verfügbar zu machen, d.h. die Projekt-

datei beispielsweise in einem anderen Kontext zu verwenden, ist ein austauschbares Format

erforderlich. Natürlich lassen sich die internen Objekte von .NET in binäre Dateien serialisie-

ren, jedoch bringt dies den Nachteil mit sich, dass diese nicht von allen Anwendungen wieder

in verwertbare Objekte konvertiert werden können. Daher ist ein standardkonformes Format

wie XML hier vorteilhaft. Datengrundlage sollten also Dateien (oder Datenbankinhalte) mit

wohlgeformter XML-Struktur sein. Dazu muss ein Schema existieren, nach welchem die Baum-

struktur des Dokumentes aufgebaut ist. Da im Praxisbeispiel die exemplarischen XML-Gantt-

Projektdateien von IBM (*.sdxl2) verwendet werden (insbesondere zum Testen während der

Erstellung dieser Bachelorarbeit), ist die Anwendung auch auf deren Schema ausgerichtet, so-

dass hier kein völlig neues entworfen werden muss. Die dazugehörige Dokumentation und das

Schema an sich hat IBM allerdings nicht verö�entlicht (obwohl eine Beschreibung in (IBM,

2009b, S. 149) vorgesehen war, jedoch nicht aufgeführt ist). Da dies aber nicht von grundle-

gender Bedeutung für diese Arbeit oder die Beispielanwendung ist, soll hier nicht im Detail

auf das Schema von SDXL-Dateien eingegangen werden. Um dennoch einen Einblick in die

XML-Dateien zu erhalten ist in Listing 6.1 ein kleines Beispielprojekt mit sieben (teils hier-

archischen) Aktivitäten, fünf Ressourcen, vier Reservierungen und einer Beziehung abgebildet.

1 <?xml version="1.0" encoding="utf -8"?>

2 <schedule version="5.5" xmlns:xsi="http: //www.w3.org /2001/ XMLSchema -instance"

xsi:noNamespaceSchemaLocation="sdxl.xsd">

3 <title>Scheduling Data</title>

4 <desc>ILOG Views Scheduling Data Exchange Language </desc>

5 <resources >

6 <resource id="R0" name="Gate 1" quantity="1" />





11 </resources >

12 <activities dateFormat="d-M-yyyy H:m:s">

13 <activity id="A0" name="BA -501" start="13 -11 -2003 8:45:0" end="13 -11 -2003 9:50:0"

/>


/>


/>

16 <activity id="A3" name="BA -22" start="13 -11 -2003 9:0:0" end="13 -11 -2003 11:0:0" />

17 <activity id="A4" name="BA -0X" start="15-1-2004 8:0:0" end="21 -1 -2004 5:0:0" />

2IBM ILOG konstruierte diese Scheduling Data eXchange Language zum Austausch von Gantt-Projekten.Näheres in (IBM, 2009b, S. 146�)

92


18 <activity id="A5" name="BA -01" start="15-1-2004 8:0:0" end="21 -1 -2004 5:0:0" /

>

19 <activity id="A6" name="BA -02" start="21-1-2004 5:0:0" end="21 -1 -2004 5:0:0">

20 <property name="Milestone">true</property >

21 </activity >

22 </activity >

23 </activities >

24 <constraints />

25 <reservations >

26 <reservation resource="R4" activity="A3" />




30 </reservations >

31 <constraints >

32 <constraint from="A2" to="A3" type="End -Start" />

33 </constraints >

34 </schedule >

Listing 6.1: Beispiel einer SDXL-Datei

Ein Schema müsste also als Wurzelelement <schedule> de�nieren, welches (neben Meta-

daten wie Titel und Beschreibung) auch die Kindelemente <activities>, <resources>,

<constraints>, <reservation> enthält. Diese listen einzelne Aktivitäten, Ressourcen etc.

auf welche mit einer eindeutigen ID versehen sind. Um sie beim Erstellen des Project-

SchedulingModels auch in hierarchischen Strukturen anzuordnen, können die <activity>-

Tags auch weitere Elemente des selben Typs als Kinder beinhalten. Ebenso ist ein Markup

<property> vorhanden, welches den Typ einer Aktivität festlegen kann.

Die in den jeweiligen Tags enthaltenen Attribute de�nieren die häu�g gleichnamigen Proper-

ties in den Scheduling-Klassen.

Um nun aus den XML- bzw. SDXL-Dateien die Objekte für die Gantt-Diagramme zu er-

zeugen (oder umgekehrt) ist ein Modul zur Konvertierung nötig. Für Silverlight steht der

GanttModelXmlSerializer von IBM ILOG, welcher genau dies bewerkstelligen kann nicht

zur Verfügung3. Er kann daher nur auf Serverseite, wo die kompletten Bibliotheken vorhan-

den sind, benutzt werden � beispielsweise für einen Web Service. Damit ein solcher Dienst

nun aber z.B. SOAP-konform ein wohlgeformtes XML-Dokument vom Silverlight-Client emp-

fangen kann, muss dieses bereits dort erstellt werden und nicht erst auf Seite des Service

Providers. Daher muss eine eigene Funktion bzw. Klasse (FileIO.cs) zur Konvertierung der

Formate entwickelt werden (genaueres zu dieser Umwandlung auf S. 119 in Kapitel 7.2 und

im Anhang).

Auch der im .NET-Framework enthaltene XmlSerialzier zur Serialisierung von Objekten,

lässt sich hier nicht verwenden, da einige interne Elemente der ProjectSchedulingModel-

Klasse nicht die dazu notwendigen Voraussetzungen erfüllen.

3Wegen der zur WPF-Version reduzierten Menge an Klassen und Funktionen.

93


Abb. 6.12: Mögliche Konvertierungsrichtungen eines Gantt-Projekts

DesWeiteren müssen nicht nur die Projektdateien an sich, sondern auch Benutzereinstellungen

oder -pro�le gespeichert werden können. Bietet eine Anwendung die Option, Funktionen und

Kon�gurationen an der Ansicht für den Benutzer individuell anzupassen, sollten diese auch

beim nächsten Programmaufruf immer noch vorhanden sein. Diese Persistierung lässt sich auf

drei Arten lösen:

• als lokale (binäre) Datei, die der Benutzer manuell über ein Dialog speichern kann,

• als lokale Datei im Local Storage der Silverlightanwendung, also in einem Bereich, wo

der Anwender keinen direkten Zugri� darauf hat oder

• unter Einbeziehung und Kontrolle des Servers und einer Datenbank.

Die ersten beiden Methoden heben den Nachteil auf, den eine Silverlightanwendung mit sich

bringt: unabhängig vom Zugangsort und Zugangssystem erreichbar zu sein. Die individuellen

Einstellungen wären nur auf dem Rechner vorhanden, auf dem die Anwendung aufgerufen

wurde. Zusätzlich lässt sich nicht garantieren, dass der Local Storage oder die Kon�gurations-

datei �verloren� geht, sodass die Einstellungen nicht wiederherstellbar sind.

Bei �einfachen� Anwendungen ohne vorherige Registrierung wäre eine serverseitige Speiche-

rung von Programmeinstellungen schwierig umzusetzen, denn die gemachten Optionen müs-

sen den jeweiligen Benutzern wieder zugeordnet werden können. Daher ist die vorteilhaftere

Variante für ein System, bei dem eine Benutzerauthenti�zierung zum Programmstart gefor-

dert wird, der dritte Weg, da dort schon die nötigen Funktionen für ein Mehrbenutzerbetrieb

(Benutzerpro�le, Authorisierung etc.) gegeben sind.

Die Praxisanwendung versucht daher den dritten Weg einzuschlagen und die Einstellungen

serverseitig zu speichern (obwohl keine Mehrbenutzer-Funktionalität implementiert ist), um

das Vorgehen zu demonstrieren (Kapitel 7.2).

Der Entwurf einer SOA-Anwendung bzw. einer Rich Internet Application sollte (wie jede

andere Anwendung auch) Aspekte zur Performanz und Sicherheit berücksichtigen. Da hier

jedoch ein Groÿteil der rechenintensiven Arbeiten in den Bibliotheken von IBM ILOG Gantt

statt�ndet (z.B. Leveling und Darstellung der Elemente) sind die Möglichkeiten der Verbesse-

rung hier eingeschränkt. Optimierungsmöglichkeiten der Silverlightanwendung sind daher nur

94


an wenigen Punkten möglich � z.B. auf Seiten der Serveranbindung bzw. der Web Services.

Ebenso sind Maÿnahmen zur Absicherung vor bösartigen Angri�en lediglich derart gehalten,

dass keine Fahrlässigkeit vorliegt. Da jedoch solche Verbesserungen sehr detailliert und aus-

führlich beschrieben werden müssten, wird hier darauf verzichtet und in der Implementierung

nur grundlegend auf diese Aspekte eingegangen.

95

Kapitel 7

Implementierung

Anhand des zuvor erarbeiteten Entwurfs wird in den folgen Kapiteln die Realisierung des

Praxisbeispiels einer RIA mit Silverlight demonstriert � der Silverlight-Gantt-Editor. Da hier

nicht auf alle Teile der Quelltexte eingegangen werden kann, ist der Code mit Kommentaren

versehen worden, sodass in diesem Kapitel der Fokus auf den wesentlichen Elementen liegt.

Zunächst erfolgt eine Beschreibung der Klassen und Objekte zur Umsetzung der n-tier Model-

View-ViewModel-Architektur. Anschlieÿend folgen Erläuterungen zur Anbindung an den Ser-

viceprovider und zur Datenspeicherung. Den Abschluss des Kapitels bildet das Deployment der

Silverlightanwendung. Eine Übersicht der Klassen des Praxisbeispiels ist im UML-Klassendiagramm

auf S. xi des Anhangs aufgeführt.

Hinweis

Die Implementierung der Anwendung beinhaltet Klassen des Frameworks MVVM

Light Toolkit V3 SP1, welches u.a. Projektvorlagen für Visual Studio und Expression

Blend enthält sowie Bibliotheken bereitstellt, um eine Anwendung mit Model-View-

ViewModel-Architektur zu erstellen (z.B. ViewModelBase, ViewModelLocator). Da-

neben beinhaltet das Paket Klassen zur grundlegenden Realisierung von Commands

(RelayCommand) in Silverlight. Weitere Informationen zur Funktionalität dieses Pa-

kets können bei (Galasoft, 2010) gefunden werden.

7.1 Umsetzung des Model-View-ViewModel-Musters

Das Model-View-ViewModel wird in der Beispielanwendung hauptsächlich durch die Datei-

en bzw. gleichnamigen Klassen IModel.cs, DataModel.cs, MainViewModel.cs und MainPa-

ge.xaml realisiert. Zusätzlich spielt AppCommands.cs eine wichtige Rolle, da dort die Com-

96


mands und somit einen Groÿteil der dem Benutzer zur Verfügung stehenden Funktionalität

gekapselt werden. Die von Visual Studio erzeugten Klassen zum Zugri� auf die Web Services

be�nden sich im Namespace GanttServiceReference (siehe Kapitel 7.2). Nachfolgende Ta-

belle 7.2 zeigt eine Übersicht der einzelnen Klassen des MVVM-Musters dieser Anwendung.

Eine detaillierte Beschreibung erfolgt in den jeweiligen Kapiteln.

Ebene Repräsentiert durch

Model IModel.cs, DataModel.cs, FileIO.cs, AppSetting.cs, Model-

EventArgs.cs (beinhaltet die Klassen EventArgsBase und Wor-

kingEventArgs)

ViewModel MainViewModel.cs, AppCommands.cs, ViewModelLocator.cs

View MainPage.xaml, MainPage.cs

Tab. 7.2: Kernklassen der MVVM-Realisierung

7.1.1 Model

Das Interface IModel kapselt das zu Grunde liegende Datenmodell und stellt es für das View-

Model bereit. In diesem sind z.B. business objects und Schnittstellen für den Zugri� auf Web

Services enthalten. Die Klasse DataModel implementiert dabei das relativ kompakte Interface.

Zusätzlich werden in DataModel private Methoden de�niert, die intern Verwendung �nden.

Das Klassendiagramm aus Abbildung 7.1 listet alle im DataModel enthaltenen Elemente auf.

Hinweis

Das Symbol eines Vorhängeschlosses kennzeichnet private Attribute im UML-

Klassendiagramm.

Die ö�entlichen Attribute GanttChart und ScheduleChart sind vom gleichnamigen Typ

Gantt- bzw. ScheduleChart aus der ILOG Gantt Bibliothek. Sie spiegeln die Controls der

aktivitäts- und ressourcenorientierten Gantt-Diagramme für die Benutzerober�äche wieder.

Wie in Kapitel 6 beschrieben, werden Darstellung und Interaktion durch diese Klassen ermög-

licht.

Die Property ProjectModel ist eine Instanz des Typs ProjectSchedulingModel und enthält

alle Aktivitäten, Ressourcen, Reservierungen und Beziehungen zur Verwaltung des aktuell

geladenen Projekts. UserProfile nimmt AppSetting-Objekte entgegen (siehe Kapitel 7.2),

die benutzerde�nierte Programmeinstellungen ermöglichen und die Ober�äche visuell und

Funktional anpassen können.

Die im Interface deklarierten Methoden erlauben eine Steuerung und Anpassung des Da-

97


Abb. 7.1: Klassendiagramm: das Interface des Models und dessen Implementierung durch die KlasseDataModel

tenmodells. Beispielsweise übernimmt SetGanttModel(ProjectSchedulingModel newModel)

die Aufgabe, ein neues Projekt durch die Gantt-Diagramme anzeigen zu lassen, welches etwa

aus einer SDXL-Datei geladen (und bereits konvertiert) wurde. Es initialisiert die Controls

GanttChart sowie ScheduleChart und verweist die neuen dort Referenzen an die verantwort-

lichen Attribute der Chart Controls. Listing 7.1 beschreibt die drei notwendigen Verweise.

1 public void SetGanttModel(ProjectSchedulingModel newModel)

2 {

3 StartWorkingEvent("Initializing data ...", "Please wait ...");

4 (...)

5 GanttChart.ItemsSource = newModel.Activities;

6 GanttChart.ConstraintsSource = newModel.Constraints;

7 ScheduleChart.ItemsSource = newModel.Resources;

8 (...)

9 // notify listeners: work completed

10 StopWorkingEvent ();

11 // notify listeners: success! submit no (error) parameter

12 SetModelComplete(this , new GanttEventArgs ());

13 }

Listing 7.1: DataModel.cs: Ausschnitt der Methode zum Setzen eines neuen

ProjectSchedulingModel

Die Property ItemsSource der Chart Controls nimmt aufzählbare Listen entgegen. Hier wer-

98


den an das aktivitätsorientierte GanttChart-Objekt die neuen Aktivitäten referenziert. Die

Liste der Beziehungen zwischen diesen wird von ConstraintSource entgegen genommen. Der

ressourcenbezogene ScheduleChart benötigt hingegen lediglich einen Verweis auf die neuen

Ressourcen � ebenfalls durch die Property ItemsSource.

Bevor jedoch damit begonnen wird die neuen Listen zu Verweisen, feuert das Model den in

IModel de�nierten WorkingEvent mit dem Argument isBusy = true, welches alle registrier-

ten Abonnenten darüber informiert, dass das Model gerade beschäftigt ist. So kann etwa

das ViewModel benachrichtigt werden und der Benutzer erhält beispielsweise einen kleinen

Hinweis oder der Mauszeiger ändert sich zu einer Sanduhr. Ist der Initialisierungsvorgang ab-

geschlossen, feuert das Ereignis erneut. Dieses mal aber mit dem Argument isBusy = false,

sodass der Status des Model wieder auf �nicht beschäftigt� gesetzt werden kann.

Der SetModelComplete-Event löst anschlieÿend ebenfalls aus. Diesem werden bei Erfolg der

Methode SetGanttModel ein leerer EventArgsBase-Parameter übergeben (siehe Kapitel 7.2).

Bei Misserfolg wird der aufgetretene Fehler sowie dessen Beschreibung (z.B. die Exception

mit Stack-Trace) hinzugefügt. Auf diese Weise werden erneut alle listener darauf aufmerksam

gemacht, dass eine Aktion des Models beendet wurde. Anhand der übermittelten Argumen-

te kann entsprechend individuell auf Fehler reagiert, oder das Programm regulär fortgesetzt

werden.

(Vgl. zu diesem Vorgang auch die Sequenzdiagramme auf S. 86 und 87 sowie die Erläuterung

zur Implementierung der Commands auf S. 106)

Eine Komponente, die auf fehlerhafte Ereignisse reagiert und diese zu einem Bericht zusam-

menfasst (logging) wäre hier exemplarisch. In der Praxisanwendung registriert allein das

ViewModel diese Events. Es veranlasst bei Erfolg einen kleinen Hinweis, dass der Vorgang

SetGanttModel() ohne Probleme abgeschlossen wurde und aktiviert daraufhin einige Kom-

ponenten (z.B. Buttons) zur Editierung des neu initialisierten Gantt-Projektes. Anschlieÿend

kann mit der Editierung des Projekts begonnen werden.

Diese lose Kopplung über Ereignisse ist damit neben dem Interface IModel, die einzige Ver-

bindung zwischen den Ebenen Model und ViewModel. Die Events dienen lediglich als gemein-

sames Austauschformat und sind innerhalb der Eventde�nitionen des Interfaces deklariert.

Keine der beiden Schichten hat explizit Kenntnis über Arbeitsweise oder interne Prozesse der

jeweils anderen. Jeglicher Zugri� und Interaktion untereinander erfolgt auf Basis des zuvor

de�nierten Interfaces.

Die hier erläuterte Vorgehensweise der Methode SetGanttModel ist auch auf die anderen

ö�entlichen Funktionen der DataModel-Klasse übertragbar � auch dort werden zu Beginn

StartWorking-Events ausgelöst, am Ende wieder aufgehoben und ein methodenspezi�sches

Completed-Ereignis gefeuert. Daher wird für eine weitere Beschreibung der restlichen Inhalte

dieser Klasse auf den kommentierten Quelltext verwiesen. In Kapitel 7.2 wird, im Rahmen

99


von Web Service-Aufrufen, jedoch erneut auf diese Ebene eingegangen.

Die Klassen WorkingEventArgs und GanttEventArgs nehmen die eigentliche Rolle der Da-

tenübermittlung zwischen den Ebenen des MVVM ein. Das Klassendiagramm aus Abbildung

7.2 zeigt deren Struktur und enthaltene Konstruktoren. Sie können verschiedene Werte ent-

gegennehmen, welche den Abonnenten der zugehörigen Events über ö�entliche Properties

angeboten werden. Im Laufe der nachfolgenden Abschnitte wird häu�g auf Objekte dieser

Klassen zurückgegri�en.

Abb. 7.2: Klassendiagramm der Event-Argumente

7.1.2 ViewModel

Das ViewModel bildet die Brücke zwischen Model und View, indem es als regulierende und

dirigierende Komponente zwischen diesen beiden Ebenen steht. Es beinhaltet die Logik zur

Steuerung und Validierung der Anwendung bzw. der Daten. Hier ö�entlich bereitgestellte

Properties werden von der View genutzt und im XAML-Code der Benutzerober�äche über

Silverlights Data Binding referenziert.

Im Silverlight-Gantt-Editor wird das ViewModel durch die Klasse MainViewModel realisiert,

welche von ViewModelBase abgeleitet ist. ViewModelBase ist Teil des MVVM Light Toolkits

und implementiert u.a. das Interface INotifyPropertyChanged (siehe dazu S. 49). Dazu wird

die Methode RaisePropertyChanged(string propertyName) in jedem setter einer Property

aufgerufen. Sie löst bei Änderungen den PropertyChanged-Event aus, um diese zu verkünden.

Wie im nächsten Kapitel beschrieben, instanziert die View bei Programmstart ein MainView-

Model-Objekt und setzt es als DataContext (S. 48) des Wurzelements. Mittels Data Binding

100


haben Kindelemente anschlieÿend Zugri� auf die ö�entlichen Properties des ViewModels. Da-

her müssen in der MainViewModel-Klasse jene Attribute als public gekennzeichnet werden,

die für die Ober�äche relevant sind.

Dies sind beispielsweise die Properties Gantt- bzw. ScheduleChartControl. Sie de�nieren

setter für die im Model instanzierten Chart Controls und werden von dort an die View wei-

tergeleitet.

Der Wert des HierarchyChart-Objektes1 ActiveChart liefert das aktuell angezeigte Gantt-

Diagramm (ressourcenorientierte oder aktivitätsorienterte Darstellung) der Ober�äche. Der

Wert von ActiveChart wird zentral beim Ändern der Ansicht gesetzt. Auf diese Weise lässt

sich verhindern, dass etwa nach einem Command-Aufruf ständig überprüft werden muss, wel-

ches Diagramm gerade aktiv und vom Benutzer ausgewählt ist.

Um kurze Hinweistexte in der Anwendung anzuzeigen (unten links), wurde die Property In-

foText (Typ string) de�niert. Ein TextBlock-Element der Ober�äche bindet deren Wert

und zeigt so die Zeichenkette an.

Das Attribut IsBusy leitet den im Interface de�nierten WorkingEvent weiter und teil der GUI

mit, dass eine Komponente der RIA gerade (un)beschäftigt ist. Löst das Model dieses Ereig-

nis aus, startet die Methode Model_WorkingEvent() im ViewModel, da sie im Konstruktor

darauf abonniert wurde. (Erläuterungen zum Konstruktor be�nden sich weiter unten.)

Die vom WorkingEvent übermittelten Parameter enthalten u.a. einen booleschen Wert: IsBu-

sy. Ist dieser true, wird in der Benutzerober�äche ein sog. BusyIndicator-Control gestartet.

Wenn es aktiv ist, zeigt die Anwendung einen Fortschritssbalken sowie eine dazu passende

textuelle Information, die an die Zeichenkette von BusyContent gebunden wurde (ebenfalls

als Parameter des Events vorhanden). Gleichzeitig wird die Anwendung für weitere Benut-

zerinteraktionen gesperrt. Wird der Wert von IsBusy dann durch das Model wieder false

gesetzt, ist die RIA wieder einsatzbereit.

Im Standardkonstruktor MainViewModel() wird ein überladener Konstruktor aufgerufen, der

das Interface IModel als Parameter entgegen nimmt. Listing 7.2 zeigt dazu den Ausschnitt

der Klasse MainViewModel.cs

1 public MainViewModel () : this(new DataModel ()) // create an instance of IModel

2 {

3 // further proceedings i.e. instanciate commands etc.

4 }

5 public MainViewModel(IModel model)

6 {

7 Model = model;

8 }

Listing 7.2: MainViewModel.cs: Ausschnitt der beiden Konstruktoren der Klasse

1HierarchyChart ist die Vaterklasse der Klassen GanttChart und ScheduleChart. Siehe Klassendiagrammaus Abbildung 6.1

101


Indem ein grundlegender Konstruktor (welcher nur das Interface IModel entgegen nimmt)

bereitgestellt wird, sind z.B. Unit-Tests zu diesem ViewModel möglich. Weiterhin erstellt der

Standardkonstruktor (ohne Parameter) zunächst über den oben genannten alternativen Kon-

struktor eine Instanz des verwendeten Models. Anschlieÿend werden darin die wichtigsten

Objekte erzeugt und auf default-Werte gesetzt. Grundlegende Daten können bereits über das

instanzierte DataModel-Objekt aus dem Model bezogen werden. Damit das VievModel auf

Events der Gantt-Diagramme reagieren kann, registriert es sich auf einige dort angebotene

Ereignisse � z.B. SelectionChanged. Dieses löst aus, sobald in der gerade ausgewählten An-

sicht eine Zeile des Diagramms selektiert wird.

Ebenso existiert ein Event, der bei einem Mausklick des Benutzers in einen leeren Bereich der

linken Seite der Chart Controls feuert. Im Zusammenspiel beider Ereignisse ermöglichen die

beiden den Events zugeordneten Methoden Chart_SelectionChanged und Chart_MouseLeft-

ButtonDown, ein interaktives User Interface, welches situationsbedingt (Zeile ausgewählt oder

nicht) Buttons (de-)aktiviert und Funktionen freischaltet. Beispielsweise wird auf Basis der

ausgewählten Zeile entschieden, ob eine neue Aktivität als direktes Kindelement einer anderen

Aktivität eingefügt werden soll. Auf diese Weise lassen sich hierarchische Bäume innerhalb

des Projekts erstellen.

Weiterhin sind hier Events für das Scrollen des Mausrades registriert. Damit die umliegende

Internetseite der Silverlightanwendung auch vertikal geblättert werden kann, darf das OnMou-

seWheelTurned-Ereignis nicht fest an das Silverlight-Control gebunden sein, sondern muss

auch vom Browser registriert werden können.

In der Beispielanwendung wurde daher so vorgegangen, dass wenn der Mauszeiger die Sil-

verlightanwendung verlässt, der Mausrad-Event an den Browser geleitet wird. Be�ndet sich

der Zeiger innerhalb der RIA, übernimmt Silverlight die Behandlung des Ereignisses, so-

dass im Gantt-Diagramm geblättert werden kann. Im Quelltext sind dafür die Methoden

Chart_MouseEnter() bzw. Chart_MouseLeave() verantwortlich, indem dort der umliegenden

Internetseite JavaScript-Routinen hinzugefügt werden. Dies übernehmen Klassen des .NET-

Frameworks.

Ein weiteres ö�entliches Property des ViewModels ist ActualProfile, welches eine Instanz

von AppSetting entgegen nimmt oder setzt. In dieser Klasse stecken die aktuell geladenen,

individuellen Benutzereinstellungen. Sie werden hier vom bzw. zum Model weitergeleitet (wie

bei den ebenfalls im Model de�nierten Chart Controls). Die Ebene des ViewModel agiert

erneut als Steuerungs- und Verwaltungslogik der Anwendung, indem sie Anfragen an die

verantwortlichen Stellen dirigiert.

102


Abb. 7.4: Die AppComman-ds-Klasse

Daneben beinhaltet das ViewModel eine Menge von Commands, die

gewisse Funktionalitäten erfüllen. Diese be�nden sich in der App-

Commands-Klasse, welche im Standardkonstruktor des ViewModels

instanziert wird. Über dieses Objekt kann die View dann auf die

Commands zugreifen und sie referenzieren bzw. bei Bedarf auslö-

sen (siehe Kapitel 7.1.3). Nachfolgend soll anhand zweier Beispiele

die genaue Implementierung von Commands mit Hilfe des MVVM

Light Toolkits erläutert werden.

Zur Umsetzung der Funktionalität des Hinzufügens einer neuen Zei-

le im Gantt-Diagramm, wird ein RelayCommand mit der Bezeich-

nung AddRowCommand erstellt. Im Objekt-Konstruktor wird auf die

Methode DoAddRow() und die CanAddRow-Property verwiesen. DoAd-

dRow() startet, sobald der Command ausgelöst wird. Wie schon auf

S. 44 beschrieben, bestimmt das zweite Argument CanAddRow, wann

die Funktionalität bzw. der Command ausgeführt werden kann und

darf.

Ein RelayCommand verlangt im Konstruktor als zweites Argument

ein Func<bool>-Objekt, welches am komfortabelstem durch einen

einfachen C#-Lambda-Ausdruck geliefert wird:

() => CanAddRow. Die linke Seite des Ausdrucks ist leer, sodass

das Argument der rechten Seite direkt ausgewertet wird. Der zur

booleschen Property gehörende getter bzw. setter löst, nachdem er

die Werte neu referenziert hat zum Einen den PropertyChanged-

Event des Interfaces INotifyPropertyChanged aus, um etwa alle

an den Wert gebundenen Controls der View über ein Update der

Daten zu informieren. Zum Anderen wird RaiseCanExecuteChan-

ged() des AddRowCommands aufgerufen, damit auch der Command

auf die Änderung aufmerksam wird und ggf. eine Schalt�äche deaktiviert.

Listing 7.3 fasst die Vorgehensweise zusammen und instanziert einen von auÿen nutzbaren

Command, der eine neue Zeile in das Gantt-Diagramm einfügt.

1 // define command

2 public RelayCommand AddRowCommand = new RelayCommand(DoAddRow , () => CanAddRow);

3

4 void DoAddRow ()

5 {

6 if (_viewModel.ActiveChart is GanttChart) // create new activity

7 {

8 SchedulingActivity newActivity = new SchedulingActivity ();

9 newActivity.Name = "Activity " + (_viewModel.Model.ProjectModel.Activities.Count +

103


1).ToString ();

10 // check for parents

11 if ((int)_viewModel.ActiveChart.SelectedIndex >= 0)

12 {

13 // set selected activity as parent activity

14 newActivity.Parent = (SchedulingActivity)_viewModel.ActiveChart.SelectedItem;

15 }

16 // add activity to project model

17 _viewModel.Model.ProjectModel.Activities.Add(newActivity);

18 // move selected index to new activity

19 _viewModel.ActiveChart.SelectedIndex = _viewModel.ActiveChart.Table.IndexOfRow(

newActivity);

20 (...)

21 }

22 else // create new resource

23 {

24 // nearly same as above

25 (...)

26 }

27 }

28

29 // getter & setter

30 public bool CanAddRow

31 {

32 get { return _canAddRow; }

33 set

34 {

35 _canAddRow = value;

36 // Update bindings , no broadcast

37 RaisePropertyChanged("CanAddRow");

38 // Notify

39 AddRowCommand.RaiseCanExecuteChanged ();

40 }

41 }

Listing 7.3: AppCommands.cs: Vollständiger Code zum AddRowCommand

Um nun auch Parameter an Commands zu übergeben, muss das obige Vorgehen leicht modi-

�ziert werden. Exemplarisch wird die Funktion zur Erstellung einer Beziehung zwischen zwei

Aktivitäten herangezogen.

Der Event, welcher vom GanttChart-Control ausgelöst wird, nachdem der Benutzer durch Zie-

hen mit der Maus einen neuen constraint erstellt, heiÿt CreateConstraint. Der Command

reagiert daher nicht wie üblich durch Betätigen eines Buttons, wo er normalerweise durch

Silverlight automatisch ausgelöst wird. Stattdessen muss er dann starten, sobald das Crea-

teConstraint-Ereignis des GanttChart-Controls feuert. Wie dies im XAML-Code der View

de�niert ist, wird im Detail in Kapitel 7.1.3 erläutert.

Der momentane Fokus liegt jedoch zunächst auf dem ViewModel, bzw. der Klasse AppCom-

mands. Wie auf S. 90 bereits erwähnt, liefert der vom Diagramm geworfene Event Parameter

mit, die Ursprungs- und Ziel-Aktivität des constraints beschreiben. Auf die Properties From-

104


Activity und ToActivity muss also im Command zugegri�en werden können, indem dort

der zugehörige Ereignis-Parameter (CreateConstraintEventArgs) weitergereicht wird. Dazu

lässt sich die RelayCommand<T>-Klasse für den zu erstellenden CreateConstraintCommand ver-

wenden. Listing 7.4 zeigt dessen De�nition und die beim Ausführen aufzurufende Methode

DoCreateConstraint(), welche die genannten Parameter als Argumente erhält.

1 CreateConstraintCommand =

2 new RelayCommand <CreateConstraintEventArgs >(( param) => DoCreateConstraint(param));

3

4 void DoCreateConstraint(CreateConstraintEventArgs param)

5 {

6 _viewModel.InfoText = "New constraint received";

7 // set constraint properties

8 SchedulingConstraint newConstraint = new SchedulingConstraint ();

9 newConstraint.FromActivity = (SchedulingActivity)param.FromItem;

10 newConstraint.ToActivity = (SchedulingActivity)param.ToItem;

11 try

12 {

13 _viewModel.Model.ProjectModel.Constraints.Add(newConstraint);

14 }

15 catch (Exception e) // often cyclic -constraint -path error

16 {

17 _viewModel.Model.ProjectModel.Constraints.Remove(newConstraint);

18 ShowError("The constraint could not be created! " + e.Message , e.StackTrace);

19 }

20 }

Listing 7.4: AppCommands.cs: De�nition des CreateConstraintCommand und der zugehörigen

Funktionalität

Der vom MVVM Light Toolkit bereitgestellte Konstruktor der generischen RelayCommand<T>-

Klasse erhält als ersten Parameter (siehe Klassendiagramm aus Abbildung 6.11, S. 90) wieder

einen Verweis auf die vom Command auszuführende Methode. Der optionale zweite Parameter

gibt die boolesche Variable zu CanExecute an. Dieser wird hier allerdings nicht benötigt, denn

der CreateConstraint-Event wird nur dann vom GanttChart-Control ausgelöst, wenn auch

vom Benutzer ein solcher constraint erstellt wurde. Da die ILOG-Controls diese Aufgaben der

Interaktion übernehmen und regulieren, hat man als Entwickler nur eingeschränkten Zugri�

auf dortige Steuerungslogik.

Die CreateConstraintEventArgs werden innerhalb der generischen Typparemeter (<T>) des

RelayCommand de�niert. Im Konstruktor verwendet man üblicherweise erneut einen Lambda-

Ausdruck, um auf die aufzurufende Methode mit den Parametern zu verweisen: (param) => Do-

CreateConstraint(param). Die linke Seite referenziert das CreateConstraintEventArgs-

Objekt, welches rechts als Argument der DoCreateConstraint-Methode eingesetzt wird. Da-

mit ist eine Verknüpfung hergestellt und die Funktionalität kann in der Methode implementiert

werden. Dort fügt man der das Projekt verwaltenden ProjectSchedulingModel-Instanz den

neuen constraint hinzu und prüft auf dabei möglicherweise entstandene Fehler. Beispielsweise

105


treten häu�g Exceptions auf, die vor einem nicht erlaubten, zyklischen Pfad von Beziehungen

warnen.

Anhand dieser beiden Beispiele wurde die Verwendung und Implementierung der Commands

des Silverlight-Gantt-Editors erläutert. Ein weiterer Bestandteil der AppCommands-Klasse ist

die Logik zur Bereitstellung zusätzlicher Funktionalität. Diese wird im Folgenden betrachtet.

Die Commands können als Teil des ViewModels verstanden werden. Sie enthalten daher auch

eine gewisse Steuerungslogik.

Beispielsweise ruft der TestServerCommand über das Model einen Web Service auf, der Aus-

kunft über die Verfügbarkeit der serverseitigen Datengrundlage gibt. Das Interface des Mo-

dels de�niert zum Abschluss dieser Auskunft den TestServerCompleted-Event, welcher nach

(k)einer Antwort des Servers ausgelöst wird. Das ViewModel bzw. die Klasse der Commands

muss dieses Ereignis registrieren und darauf reagieren, um z.B. den Anwendungsmodus auf

o�ine zu setzen, falls der Serviceprovider ausfällt.

Dazu werden im Konstruktor der AppCommands die verschiedenen Events des Models abonniert

(Listing 7.5 zeigt exemplarisch den für den Abschluss des Server-Tests zuständigen Programm-

teil).

1 _viewModel.Model.TestServerComplete +=

2 new EventHandler <EventArgsBase >( Model_TestServerComplete);

3

4 void Model_TestServerComplete(object sender , EventArgsBase e)

5 {

6 if (e.Error != null) // exception thrown: offline mode

7 {

8 ShowError("Server didn't respond. Switching to offline mode", e.Error.StackTrace);

9 _viewModel.InfoText = "Test server failed. Using offline mode.";

10 // switch to offline mode

11 SwitchToOfflineModeCommand.Execute(null); // --> _viewModel.IsOfflineMode = true;

12 }

13 else // server ok -> online mode

14 {

15 _viewModel.IsOfflineMode = false;

16 OpenUserProfileCommand.Execute(null);

17 _viewModel.InfoText = "Server responded successfully." + e.StringResult + " Using

online mode.";

18 }

19 }

Listing 7.5: AppCommands.cs: Die AppCommands-Klasse agiert als listener der Events des Models

Der jeweilige Eventhandler erweckt nach dem Auslösen des Events eine Methode, um ent-

sprechend darauf zu reagieren. Im Falle von TestServerCompleted wird beispielsweise Mo-

del_TestServerComplete(object sender, EventArgsBase e) aufgerufen. In ihr wird an-

hand der übermittelten Argumente geprüft, ob der Serviceprovider bzw. die Dienste verfügbar

sind und ggf. die Anwendung in einen O�ine-Modus versetzt. Es ist hier ersichtlich dass eine

106

gewisse Validierung bzw. Steuerung statt�ndet, indem auf Fehler reagiert und entsprechend

gehandelt wird.

Andere Events des Models sind auf gleiche Weise behandelt oder es werden spezi�sche Aktio-

nen ausgelöst. Die Dokumentation im Quelltext der Praxisanwendung geben darüber detail-

liert Auskunft.

7.1.3 View

Die View enthält alle De�nitionen und Angaben zur Erstellung der graphische Benutzerober�ä-

che (siehe Bildschirmfoto auf S. 116). Dazu gehören hauptsächlich die Klassen MainPage.xaml

mit der Code-Behind-Datei MainPage.xaml.cs sowie das resource dictionary MainSkin.xaml.

Weitere untergeordnete Fenster der Anwendung sind in Kapitel 7.3 erläutert.

Da nicht jede Einzelheit auf diesen Seiten beschrieben werden kann, sollen erneut ausgewählte

Komponenten exemplarisch erklärt werden.

Das Hauptfenster ist durch die Datei MainPage.xaml de�niert. Darin enthalten sind zahlrei-

che Buttons, Grids, Panels, Images usw., welche in ihrer Gesamtheit die Benutzerober�äche

bilden.

Grundsätzlich muss jedoch zunächst die View an ein ViewModel gebunden werden um der

Ober�äche Steuerungslogik, Funktionalität und eine Datengrundlage zu bieten. Das MVVM

Light Toolkit und das Praxisbeispiel verwenden hierzu den ViewModelLocator, der stets eine

Instanz des MainViewModels erstellt. Ein Verweis darauf ist im resource dictionary dekla-

riert. Der ViewModelLocator kann so als DataContext eines beliebigen Elements in XAML

referenziert werden. Dies übernimmt im Silverlight-Gantt-Editor das übergeordnete User-

Control des Hauptfensters, damit dessen Kindelemente auf das ViewModel zugreifen können.

Listing 7.6 zeigt das Vorgehen exemplarisch.

1 

2 <vm:ViewModelLocator x:Key="Locator" d:IsDataSource="True" />

3

4 

5 <UserControl.DataContext >

6 <Binding Path="Main" Source="{StaticResource Locator}"/>

7 </UserControl.DataContext >

Listing 7.6: MainSkin.xaml und MainPage.xaml: Der ViewModeLocator wird im resource

dictionary als DataContext deklariert und für die Benutzerober�äche referenziert

Wie im vorigen Kapitel bereits erläutert, kann so von allen Elementen innerhalb der Haupt-

anwendung auf ö�entliche Properties des ViewModels zugegri�en werden. Die Benutzerober-

�äche ist nun lose an die Steuerungslogik gebunden und kann deren bereitgestellte Werte und

Funktionalität verwenden.

107

Exemplarisch demonstriert Listing 7.7 das Vorgehen zur Erzeugung einer Schalt�äche, welche

dem Gantt-Diagramm eine neue Zeile hinzufügt. Der Button enthält anstatt Text, ein Bild

(Image) als Content. Der im resource dictionary de�nierte Style IconBtnStyle des Buttons

regelt einheitlich Gröÿe und Layout, sodass weitere Buttons dieser Art (vergröÿern, verklei-

nern, Projekt speichern, etc.) mit gleichem Aussehen verwendet werden können. Das Bild

verweist seinen Stil ebenfalls auf eine externe De�nition IconImageStyle. Die Kombination

beider Styles normiert also auf globaler Programmebene das Erscheinungsbild dieser Art von

Schalt�ächen.

Ein Command vermittelt die vom Button zu erbringende Funktionalität. Dieser wird an eine

Instanz der AppCommands-Klasse (der Einfachheit halber Commands genannt) bzw. dem darin

enthaltenen AddRowCommand aus Listing 7.3 gebunden. Commands wurde im Konstruktor des

ViewModel erstellt und durch eine ö�entliche Property zugänglich.

1 <Button x:Name="newRow" Command="{Binding Commands.AddRowCommand}"

2 Style="{StaticResource IconBtnStyle}" HorizontalAlignment="Left" VerticalAlignment="

Top"

3 ToolTipService.ToolTip="Add new task or ressource" >

4 <Image Source="/SilverlightGanttEditor;component/Ressources/Icons/AddRow.png"

5 Style="{StaticResource IconImageStyle}"/>

6 </Button >

7

8 

9 <Style x:Key="IconBtnStyle" TargetType="Button">

10 <Setter Property="Width" Value="28" />

11 <Setter Property="Height" Value="25" />

12 <Setter Property="Margin" Value="0,0,4,0"/>

13 <Setter Property="HorizontalAlignment" Value="Stretch" />

14 <Setter Property="VerticalAlignment" Value="Stretch" />

15 </Style>

16

17 

18 <Style x:Key="IconImageStyle" TargetType="Image">

19 <Setter Property="Width" Value="20" />

20 <Setter Property="Height" Value="20" />

21 </Style>

Listing 7.7: MainPage.xaml und MainSkin.xaml: Ein Button wird mit einem Command referenziert

und enthält eine Image-Komponente

Auf ähnliche Weise wurden nahezu alle Buttons der Benutzerober�äche de�niert und mit

Funktionalität versehen.

Eine weitere Anweisung in MainPage.xaml betri�t die Gantt-Diagramme selbst. Normaler-

weise werden die ILOG Chart Controls direkt in XAML de�niert und dort mit den jeweils

notwendigen Attributen versehen. Listing 7.8 zeigt dies beispielhaft, indem ein GanttChart-

Control direkt im XAML-Code eingefügt wird. Die Verwendung eines ScheduleCharts verläuft

analog.

108

1 <ilog:GanttChart (...) >

2 (...)

3 </ilog:GanttChart >

Listing 7.8: Ein ILOG Chart Control wird in XAML verwendet

Da die Steuerungslogik nichts über die View bzw. die darin de�nierten Elemente der gra-

phischen Benutzerober�äche wissen darf, muss das gesamte Binding an alle Properties die

das ViewModel für das Gantt- bzw. ScheduleChart-Control bereitstellt, in XAML gesche-

hen. Dies führt (für den Designer recht unhandlich) zu sehr vielen Binding-De�nitionen. Man

müsste in einer Anwendung wie der des Praxisbeispiels (auch um z.B. die AppSettings zu

unterstützen), nahezu alle Attribute und Einstellungen die ein Chart haben könnte in XAML

aufnehmen und an die jeweiligen ViewModel-Attribute binden (siehe Beispiel aus Listing 7.9).

Zudem bieten die ILOG Gantt- bzw. ScheduleChart-Controls kein Attribut um komplette

Datensätze oder Kon�gurationspro�le anzuhängen � stets nur jeweils einzelne Properties.

1 <ilog:GanttChart BorderBrush="Black" Grid.Column="1" Grid.Row="1"

2 ItemsSource="{Binding GanttChartControl.ItemsSource}"

3 ConstraintsSource="{Binding GanttChartControl.ConstraintsSource}"

4 ParentBinding="{Binding Parent}"

5 IsEnabled="{Binding GanttChartControl.IsEnabled}"

6 Visibility="{Binding GanttChartControl.Visibility}"

7 SplitterPosition="{Binding GanttChartControl.SplitterPosition , Mode=TwoWay}"

8 ZoomFactor="{Binding GanttChartControl.ZoomFactor}"

9 FirstVisibleTime="{Binding GanttChartControl.FirstVisibleTime}"

10 ConstraintLinkStyle="{Binding GanttChartControl.ConstraintLinkStyle}"

11 ConstraintOriginPropertyName="FromActivity"

12 ConstraintTypeBinding="{Binding ConstraintType}"

13 ConstraintDestinationPropertyName="ToActivity"

14 >

15 


Listing 7.9: Viele unhandliche Bindingde�nitionen bei der Verwendung von ILOG Controls

Da zusätzlich nicht alle Properties (z.B. Columns) einen ö�entlichen setter für XAML anbieten

erfordert es viel Aufwand diese Einschränkungen zu umgehen oder aufzulösen.

Das Chart Control der View würde zudem stets nur als �Klon� die Werte des im ViewModel

verwendeten Charts widerspiegeln. Auf Dauer und für groÿe Projektdateien beein�usst dies

die Leistungsfähigkeit der Anwendung negativ, da ja nicht nur ein Diagramm innerhalb der

Anwendung zum Einsatz kommt, sondern dann insgesamt vier (zwei Chart Controls-Klone

für die View und intern zwei weitere zur Aufrechterhaltung des MVVM und prozeduralen

Steuerung der Diagramme).

Im Silverlight-Gantt-Editor werden die Diagramme daher nicht direkt im XAML-Code angege-

ben, sondern innerhalb des allgemeinen UserControls (Stammklasse der meisten Silverlight-

109

Controls) als Content gebunden. Es wurde als keine Referenz auf die ILOG Gantt-Namespaces

und deren Gantt- bzw. ScheduleChart-Controls verwendet, sondern nur ein einfacher Contai-

ner Silverlights der die ILOG-Diagramme aus der internen Logik des ViewModels bindet.

Listing 7.10 zeigt die De�nition des Ersten der beiden Diagramme (aktivitätsorientiert). Der

ScheduleChart wird auf gleiche Weise direkt dahinter im Code an das ViewModel gebunden

(nicht abgebildet).

1 <UserControl x:Name="ganttChartUserControl" Content="{Binding GanttChartControl}" >

2 <i:Interaction.Triggers >

3 

4 <i:EventTrigger EventName="MouseWheel">

5 <galasoft:EventToCommand Command="{Binding Commands.MouseWheelTurnedCommand}"

PassEventArgsToCommand="True" />

6 </i:EventTrigger >

7 

8 <i:EventTrigger EventName="CreateConstraint" SourceObject="{Binding

GanttChartControl}">

9 <galasoft:EventToCommand Command="{Binding Commands.CreateConstraintCommand}"

PassEventArgsToCommand="True" />

10 </i:EventTrigger >

11 </i:Interaction.Triggers >

12 </UserControl >

Listing 7.10: MainPage.xaml: De�nition des den GanttChart des ViewModels beinhaltenden

UserControls mit zugehörigen event-to-command -Bindings

Der hier realisierte Weg mit Silverlight-UserControls ist für die konkrete Anwendung als opti-

mal angesehen worden. Diese Designentscheidung ist jeweils spezi�sch, anhand der gegebenen

Anforderungen, zu tre�en. Das MVVM ist keine strenge Regel an die man sich immer halten

muss. Wird es eingehalten, bringt es gewisse Vorteile mit sich. Bricht man dessen Grenzen

auf, muss man mit den daraus resultierenden Konsequenzen zurechtkommen.

Wie bereits erwähnt, wird als Content des UserControls das Gantt-Diagramm aus dem View-

Models referenziert. Zudem kommen die EventTrigger des Interactivity Namespaces (sie-

he S. 44) und die EventToCommand-Anweisungen des MVVM Light Toolkits zum Einsatz. Sie

verweisen das angegebene Ereignis an einen Command, statt in die Code-Behind-Datei Main-

Page.xaml.cs. Auf diese Weise bleibt die Trennung der Schichten des MVVM erhalten und

Funktionalität lässt sich abstrahieren.

Im Listing wird der MouseWheel-Event an den Command MouseWheelTurnedCommand weiter-

gereicht, welcher auf eine Bewegung des Mausrades reagiert. Dabei ist wichtig, dass die Argu-

mente des Ereignisses mit übergeben werden (PassEventArgsToCommand="True"), sodass die

Anzahl der gescrollten Zeilen im Diagramm berechnet werden kann. Die MouseWheelEven-

tArgs enthalten einen Wert (Delta), welcher darüber Angaben macht. Der Command wird

im ViewModel bzw. vom MouseWheelTurnedCommand behandelt. Er übernimmt die Parameter

110

(vgl. S. 104), verarbeitet sie und bewegt letztendlich den internen (und somit auch externen)

GanttChart entsprechend vertikal.

Zusätzlich wird (im Listing ab Zeile 8) das Ereignis weitergereicht, welches beim Erstellen

einer Beziehung zwischen zwei Aktivitäten gefeuert wird. Der dazugehörige Command wurde

ebenfalls schon erläutert (S. 104). Er erhält auch die Parameter des Events, sodass ein neues

SchedulingConstraint-Objekt erzeugt werden kann.

Zuletzt wird der BusyIndicator in XAML (Listing 7.11 ) de�niert, der die Property IsBusy

des ViewModels zur Steuerung seiner Aktivität bindet. Er wird erst nach einem Timeout von

50ms aktiv um schnell wieder beendete Aktionen nicht unnötig zu kennzeichnen. Wichtig ist,

dass dieses Control oberstes Element der GUI ist. Auf diese Weise wird es von keinem anderen

Control verdeckt.

1 <toolkit:BusyIndicator IsBusy="{Binding IsBusy}"

2 BusyContent="{Binding BusyContent}" DisplayAfter="0:0:0 .05"/>

Listing 7.11: MainPage.xaml: BusyIndicator

Der Nachteil der Variante mit den UserControls, ist die schwierigere Verwendung individuel-

ler Visualisierungsoptionen der Gantt-Diagramm durch die von ILOG möglichen Stylede�ni-

tionen. Wie bereits erwähnt, lassen sich die Chart Controls allgemein, die darin enthaltenen

Balken, Linien, Pfeile, Zeilen und Spalten stark in ihrem Aussehen beein�ussen. Die Methode

InitializeFrom() (enthalten in der GanttChart-Klasse) konstruiert dazu ein grundlegendes

Erscheinungsbild der Diagramme, indem Aktivitäts- und Reservierungsbalken, sowie Meilen-

steine, constraints und mehrere Spaltende�nitionen nach einem Standardmuster erstellt wer-

den. Möchte man das Aussehen nach eigenen Vorstellungen anpassen, sollte man explizit für

jedes Element eigene Stile bestimmen und die von dieser Methode erstellten Eigenschaften

überschreiben bzw. auf deren Verwendung verzichten.

Beispielsweise steht die BarDefinition-Klasse für die Darstellung eines Zeitobjekts auf der

rechten Zeitachse (z.B. ein Aktivitätsbalken). Sie benötigt zum Zeichnen des Balkens zumin-

dest zwei Bindings auf Angaben zum Start- bzw. Endzeitpunkt des Zeitobjekts (z.B. Start-

Time und Finish einer SchedulingActivity). Verwendet man in XAML die Chart Controls

von ILOG, kann solch eine Style-De�nition als Kindelement des Diagramms deklariert (Listing

7.12), und so angewendet werden.

1 <ilog:GanttChart (...) >

2 <ilog:GanttChart.BarDefinitions >

3 <ilog:BarDefinition

4 StartBinding="{Binding StartTime}"

5 FinishBinding="{Binding Finish}" (...) >

6 <ilog:BarDefinition.BarTemplate >

7 <DataTemplate >

8 

111

9 </DataTemplate >

10 </ilog:BarDefinition.BarTemplate >

11 <ilog:GanttChart.BarDefinitions >


Listing 7.12: De�nition eines individuellen Aussehens für das Diagramm als Kindelement des Chart

Controls

Da ein allgemeines UserControl-Element von Silverlight mit einer von ILOG bereitgestellten

BarDefinition als Kind allerdings nichts anfangen kann, ist hier ein abweichendes Vorgehen

nötig: Die Angaben zum Aussehen der Diagramme werden als Ressourcen ausgelagert.

Im resource dictionary des Silverlight-Gantt-Editors sind alle Styleangaben und sonstige ver-

wendeten Element als XAML-Ressource de�ninert. Darunter z.B. der oben verwendete Ico-

nImageStyle. Weiterhin �nden sich hier Angaben zum Aussehen einzelner Elemente der Dia-

gramme, wie Balken oder Meilensteine. Silverlight verlangt für jede der dortigen Ressourcen

einen eindeutigen x:Key mit dem diese für andere Elemente referenzierbar ist. Das resource

dictionary enthält z.B. die in Listing 7.13 angegebene De�nition für die Darstellung eines

Meilensteins im Diagramm. Dessen Start- bzw. FinishBinding-Attribute sind dabei auf den

Selben Wert (StartTime) gebunden, da es sich hierbei ja um einen Zeitpunkt und nicht um

ein Intervall handelt.

1 

2 <ilog:BarDefinition x:Key="barDefinitionMilestone"

3 BarMovingMode="ChangeStartOnly"

4 CanResizeBar="False"

5 HorizontalAlignment="Start"

6 StartBinding="{Binding StartTime}"

7 FinishBinding="{Binding StartTime}">

8

9 

10 <ilog:BarDefinition.Conditions >

11 <ilog:Condition Property="IsMilestone" Value="true" />

12 </ilog:BarDefinition.Conditions >

13

14 

15 <ilog:BarDefinition.RightTemplate >

16 <DataTemplate >

17 

18 <TextBlock HorizontalAlignment="Left" Text="{Binding StartTime , Converter ={

StaticResource DateTimeConverter}, ConverterParameter=m}" FontSize="9"

FontWeight="Bold" />

19 </DataTemplate >

20 </ilog:BarDefinition.RightTemplate >

21 

22 <ilog:BarDefinition.BarTemplate >

23 <DataTemplate >

24 

25 <ed:RegularPolygon Fill="#FFFFFA18" HorizontalAlignment="Left" Height="18" Width

="18" InnerRadius="0.47211" PointCount="5" Stretch="Fill" Stroke="Black"

112

UseLayoutRounding="False">

26 

27 <ToolTipService.ToolTip >

28 <Border >

29 <StackPanel Orientation="Vertical">

30 <TextBlock FontSize="10" FontWeight="Bold" HorizontalAlignment="Center"

Text="Milestone" />

31 <TextBlock FontSize="10" Text="{Binding Name}" />

32 <StackPanel Orientation="Horizontal">

33 <TextBlock Text="Start:" />

34 <TextBlock Text="{Binding StartTime , Converter ={ StaticResource

DateTimeConverter}, ConverterParameter=d}" />

35 </StackPanel >

36 </StackPanel >

37 </Border >

38 </ToolTipService.ToolTip >

39 </ed:RegularPolygon >

40 </DataTemplate >

41 </ilog:BarDefinition.BarTemplate >

42 </ilog:BarDefinition >

Listing 7.13: MainSkin.xaml: BarDefinition für ein als Meilenstein gesetztes

SchedulingActivity-Element des Diagrammes

Da eine BarDefintion sowohl Meilensteine, als auch Aktivitäten oder zusammengefasste, hier-

archische Aktivitäten beschreiben kann, existiert das optionale Element Condition. Es stellt

sicher, dass die BarDefinition im Beispiellisting nur für Aktivitäten gilt, die als Meilensteine

(IsMilestone liefert true) gekennzeichnet sind.

Das eigentliche Aussehen des Zeitobjekts wird durch das DataTemplate beschrieben: ein stern-

förmiges Polygon, welches einen Tooltip anzeigt, sobald sich die Maus darüber bewegt. Au-

ÿerdem sagt RightTemplate aus, dass auf der rechten Seite dieses Elementes das formatierte

Datum des Meilensteins angezeigt wird.

Auf diese Weise wird im resource dictionary für jedes Element der Chart Controls ein Aus-

sehen de�niert. Um jetzt diese Ressourcen mit den eigentlichen Gantt- bzw. ScheduleChart-

Instanzen bekannt zu machen, wird die Code-Behind-Datei des Silverlight-Hauptfensters, also

MainPage.xaml.cs, verwendet. Dies ist legititm, denn es werden dort nur ansichtsspezi�sche

Angaben gemacht � nämlich die Referenzierung der Stile mit den Diagrammen. Dazu zeigt

Listing 7.14 das Vorgehen.

1 // find GanttChart (without knowing the ViewModel !)

2 GanttChart ganttChart = (GanttChart)ganttChartUserControl.Content;

3 // find ScheduleChart (without knowing the ViewModel !)

4 ScheduleChart scheduleChart = (ScheduleChart)scheduleChartUserControl.Content;

Listing 7.14: MainPage.xaml.cs: Die Diagramme werden aus dem Content gelesen und für die

View referenziert

Zunächst müssen die Chart Controls, welche vom ViewModel an die UserControls bereitge-

113


stellt wurden, in der Code-Behind-Datei ansprechbar gemacht werden. Es ist dem Entwickler

bekannt, dass das UserControl ein Gantt- bzw. ScheduleChart-Objekt als Content über Da-

ta Binding referenziert. Dabei ist keine Information zum ViewModel nötig, auÿer dem Wissen

dass diese Diagramme darin existieren. Die lose Kopplung bleibt also erhalten, da der View

keine internen Strukturen des ViewModels bekannt sind.

Sind die Chart Controls in der View dann referenziert, können sie mit den als Ressourcen

de�nierten Style-Angaben verknüpft werden. Dazu zeigt Listing 7.15, wie über die Collection

this.Resources und dem x:Key als eindeutigem Identi�er, auf alle Ressourcen zugegri�en

werden kann.

1 // fetch BarDefinitions from resource dictionary

2 BarDefinition normalActivityBarDef =

3 (BarDefinition)this.Resources["barDefinitionNormalActivity"];

4 BarDefinition completedBarDef =

5 (BarDefinition)this.Resources["barDefinitionCompletedBar"];

6 BarDefinition summaryBarDef =

7 (BarDefinition)this.Resources["barDefinitionSummary"];

8 BarDefinition milestoneDef =

9 (BarDefinition)this.Resources["barDefinitionMilestone"];

10 BarDefinition criticalBarDef =

11 (BarDefinition)this.Resources["barDefinitionCriticalActivity"];

12

13 // add definitions to render to GanttChart

14 ganttChart.BarDefinitions.Add(normalActivityBarDef);

15 ganttChart.BarDefinitions.Add(completedBarDef);

16 ganttChart.BarDefinitions.Add(summaryBarDef);

17 ganttChart.BarDefinitions.Add(milestoneDef);

18 ganttChart.BarDefinitions.Add(criticalBarDef);

Listing 7.15: MainPage.xaml.cs: Die De�nitionen werden aus dem resource dictionary gelesen und

an die Diagramme zugewiesen

Die diversen BarDefinitions werden aus dem resource dictionary geladen und an die Chart

Controls verwiesen, welche dann mit diesen Angaben gezeichnet werden. Der Codeausschnitt

zeigt das Vorgehen exemplarisch für Elemente vom Typ BarDefinition. Andere Zuweisungen

laufen ähnlich ab, indem zuerst die Ressource geladen und dann an das Diagramm verwiesen

wird. Auf diese Weise werden also Zeitobjekte, Linien und Pfeile, Spalten und Zeilen usw.

mit einem individuellem Aussehen konstruiert. Detailliertere Erklärungen �nden sich in den

Quelltext-Kommentaren der einzelnen Programmdateien.

114


Abb. 7.3: Die MainViewModel-Klasse

115


Abb. 7.5: Screenshot des Silverlight-Gantt-Editors

116

7.2 Serveranbindung und Datenspeicherung


Dieser Abschnitt beschreibt anhand verschiedener Beispiele aus dem Silverlight-Gantt-Editor,

den Aufruf von Web Services sowie die Verarbeitung der empfangenen Antworten. (Vgl. hierzu

auch die Sequenzdiagramme von S. 86 und 87.)

7.2.1 Kommunikation mit dem Server

Microsoft Visual Studio unterstützt die Entwickler beim Verwenden von extern bereitgestell-

ten Web Services in einem Projekt. Mit Hilfe eines Dialogfensters wird die Serviceadresse,

sowie der Name einer daraus zu erstellenden Referenzierungsklasse angegeben. Die IDE er-

zeugt aus diesen Angaben und der WSDL-Datei des Dienstes, automatisch alle notwendigen

Objekte um die Funktionen des Service zu nutzen. Diese stehen den Entwicklern dann direkt

zur Verfügung.

Im Silverlight-Gantt-Editor ist dies die Klasse GanttWebServiceSoapClient (siehe Klassen-

diagramm auf S. vi im Anhang). Sie stellt die zur Verwendung des GanttWebService genannten

Dienstes benötigten Methoden und Funktionen bereit. Eine davon wird in der Datei DataMo-

del.cs verwendet und so für die anderen Schichten ö�entlich verfügbar gemacht. Exempla-

risch wird im Folgenden die public void ReadTestFile()-Methode des Models betrachtet,

welche in Listing 7.16 de�niert ist. Sie fordert vom Web Service ein exemplarisches Gantt-

Projekt an

1 // the web service

2 GanttWebServiceSoapClient _service;

3

4 public void ReadTestFile ()

5 {

6 _service = new GanttWebServiceSoapClient ();

7 _service.ReadTestFileCompleted += new EventHandler <ReadTestFileCompletedEventArgs >(

_service_ReadTestFileCompleted);

8 _service.ReadTestFileAsync ();

9

10 // notify listeners: work in process ...

11 StartWorkingEvent("Opening test file ...", "Expecting answer ...");

12 }

Listing 7.16: DataModel.cs: ReadTestFile() fordert vom Web Service eine Projektdatei an

Das Model registriert sich auf den Completed-Event des Dienstes (da er asynchron abläuft)

und startet diesen daraufhin unter Verwendung der von Visual Studio erzeugten Service-

Klasse. Anschlieÿen feuert die Methode noch den WorkingEvent um allen Abonnenten mitzu-

teilen, dass das Model beschäftigt ist. Dieser wurde im Interface des Models de�niert, sodass

andere Programmkomponenten ihn abonnieren können. Der Web Service beginnt nun ser-

verseitig seine Arbeit und lädt eine Projektdatei � etwa aus einer Datei oder Datenbank.

117


Nachdem das Ergebnis daraufhin wieder zum Client übertragen wurde, wird dort _ser-

vice_ReadTestFileCompleted() aufgerufen, da das Model sich als listener in Listing 7.16

registriert hatte.

1 void _service_ReadTestFileCompleted(object sender , ReadTestFileCompletedEventArgs e)

2 {

3 // notify listeners: process stopped

4 StopWorkingEvent ();

5

6 if (e.Error == null)

7 {

8 // submit result

9 ProjectSchedulingModel model = FileIO.ReadFromXML(e.Result);

10 ReadTestFileComplete(this , new GanttEventArgs(model));

11 }

12 else

13 {

14 // submit error

15 ReadTestFileComplete(this , new EventArgsBase(e.Error));

16 }

17 }

Listing 7.17: DataModel.cs: _service_ReadTestFileCompleted() wird nach Abschluss des

serverseitigen Dienstes gestartet

In dieser Methode wird zunächst durch StopWorkingEvent() bekannt gegeben, dass das Mo-

del nun wieder weitgehend unbeschäftigt ist. Anschlieÿend werden die übermittelten Argu-

mente auf enthaltene Fehler überprüft und das ReadTestFileCompleted-Ereignis ausgelöst,

welches allen listenern die Antwort des Web Services mitteilt und ebenfalls Teil der Interfacede-

�nition ist. Trat ein schwerwiegender Fehler auf, übernimmt der Konstruktor der GanttEven-

tArgs-Klasse (S. 100) die Fehlerbeschreibung. Ansonsten erhält er das empfangene Ergebnis.

Ähnlich wie in Listing 7.5 beschrieben, kann dann beispielsweise im ViewModel mit der Ant-

wort fortgefahren werden.

Sollen andererseits nicht Werte vom Server abgerufen, sondern dorthin übertragen werden,

geschieht dies auf gleiche Weise. Eine Methode des Models bietet dazu wie gewohnt im

Methodenkopf an, Parameter an sie zu übergeben. Im Silverlight-Gantt-Editor ist es bei-

spielsweise möglich, ein erstelltes Gantt-Projekt dauerhaft auf dem Server zu speichern (siehe

nächstes Kapitel). Die dazu im Model vorhandene ö�entliche Methode public void SavePro-

ject(ProjectSchedulingModel project) nimmt dazu eine Instanz vom Typ ProjectSche-

dulingModel entgegen. Dieses Objekt muss zur Übertragung an den Server mittels eines Web

Services in eine Zeichenkette serialisiert werden, um eine SOAP-konforme Nachricht zu gene-

rieren. Mittels der von Visual Studio erzeugten Service-Klasse GanttWebServiceSoapClient

wird der string an den Dienst bzw. Server übermittelt und dort persistiert.

118


7.2.2 Datenspeicherung

Abb. 7.6: Klasse FileIO.cs

Laut Anforderung ist ein Gantt-Projekt dauerhaft zu

speichern, indem es in ein XML-Format konvertiert wird.

Diese Umwandlung hat zusätzlich den Vorteil, dass die

so entstandene Zeichenkette an einen Web Service über-

mittelt werden kann, um das Projekt auf dem Server,

oder wahlweise als XML-Datei lokal beim Client, ab-

zulegen. Umgekehrt kann daraus wieder eine Project-

SchedulingModel-Objekt erzeugt werden, welches das

Projekt in der internen Programmlogik repräsentiert.

Im Silverlight-Gantt-Editor übernimmt die statische Klas-

se FileIO.cs die Aufgabe der Konvertierung in beide Richtungen. Auÿerdem sind darin Funk-

tionen zum Auslesen einer lokalen SDXL-Datei de�niert, oder um Benutzereinstellungen der

AppSettings-Klasse (S. 120) in bzw. aus XML zu (de-)serialisieren. Abbildung 7.6 zeigt die

statische FileIO-Klasse.

Listing A.2 im Anhang enthält eine private Methode, welche innerhalb der ö�entlichen Con-

vertProjectSchedulingModelToXml() aufgerufen wird (beide be�nden sich in der Datei

FileIO.cs). Da das Model für die Datenhaltung verantwortlich ist, sollten diese Umwandlun-

gen auch stets von dort aus vorgenommen werden. Die oben genannte Methode konvertiert

eine SDXL-Datei in ein ProjectSchedulingModel-Objekt. Dazu werden die XML-Elemente,

mittels .NET-Klassen (wie XDocument und XElement), ausgelesen und in Datenobjekte kon-

vertiert. Nacheinander werden Aktivitäten, Beziehungen, Ressourcen und Reservierungen ex-

trahiert und einander in einem ProjectSchedulingModel zugeordnet. Detaillierte Angaben

zur Vorgehensweise sind im dortigen Quelltext dokumentiert. Angelehnt an ein von IBM be-

reitgestelltes Beispiel, unterstützen drei Helfermethoden diese Prozesse, indem z.B. strings

in einen ConstraintType-Datentyp umgewandelt werden.

Liegt die ProjectSchedulingModel-Instanz dann als Zeichenkette im XML-Format vor, kann

diese über den Web Service zwecks Persistierung an den Server übertragen werden. Den gesam-

ten Vorgang der Entgegennahme, Konvertierung und Aufruf des Dienstes erledigt die ö�ent-

liche Methode SaveProject(ProjectSchedulingModel project) (Listing 7.18), welche im

Model de�niert ist. Sie ist ebenfalls durch das Interface IModel für andere Programmebenen

zugänglich.

1 public void SaveProject(ProjectSchedulingModel project , int id)

2 {

3 _service = new GanttWebServiceSoapClient ();

4 _service.SaveProjectCompleted +=

5 new EventHandler <SaveProjectCompletedEventArgs >( _service_SaveProjectCompleted);

6

7 string xmlProject = FileIO.ConvertProjectSchedulingModelToXml(project);

119


8

9 _service.SaveProjectAsync(xmlProject , id);

10

11 // notify listeners ...

12 StartWorkingEvent("Saving project. Please Wait ...", "Saving project ...");

13 }

Listing 7.18: DataModel.cs: Methode zum serverseitigen Speichern eines Gantt-Projekts

Die umgekehrte Konvertierung eines ProjectSchedulingModel-Objekts in eine Zeichenket-

te mit XML-Format übernimmt static public string ConvertProjectSchedulingModel-

ToXml(ProjectSchedulingModel model). Sie liest wiederum Aktivitäten, Beziehungen, Res-

sourcen und Reservierungen aus dem übergebenen Projekt und verwandelt sie mittels verschie-

dener .NET Klassen zur Erstellung von XML-Dokumenten (z.B. XmlWriter) in entsprechende

Zeichenketten. Da die hierarchischen Aktivitäten auch wieder nach gewohntem Schema aus-

gegeben werden sollen, wurde ein rekursiver Algorithmus implementiert, der diese Aufgabe

übernimmt. Näheres dazu auch im Quelltext der Datei FileIO.cs.

Abb. 7.7: Die AppSettings-Klasse

Neben der Memorierung von Projekten, war auch die Spei-

cherung von individuellen Benutzereinstellungen gefordert.

Mit Hilfe eines Dialogfensters (siehe nächstes Kapitel)

kon�guriert der Nutzer seine persönlichen Vorlieben zu

Aussehen und Funktionalität der Anwendung. Diese wer-

den durch die Klasse AppSetting.cs vermerkt, welche

Properties für jede Option des Nutzers beinhaltet. Das

Klassendiagramm aus Abbildung 7.7 gibt einen Überblick

der dort vorhandenen Attribute. Auch hier wird das In-

terface INotifyPropertyChanged implementiert, um ge-

bunden Controls der View auf Änderungen aufmerksam

zu machen. So bindet z.B. der GanttChart seine Property

TimeGridVisible (boolescher Typ der angibt, ob Hilfslini-

en der Zeitachse im Diagramm dargestellt werden sollen)

an den Wert von TimeGridGanttVisible aus der App-

Setting-Klasse. Ähnlich werden die anderen Properties

des Klassendiagramms verwendet und teilweise durch den Programmcode gesetzt.

Wie in den Anforderungen beschrieben, sollten diese Einstellungen nicht lokal, sondern zen-

tral auf dem Server abgelegt werden. Die zur Übermittlung durch den Web Service nötige

Konvertierung in eine XML-Zeichenkette übernimmt erneut die Klasse FileIO.cs. Darin

enthalten ist die statische und ö�entliche Methode static public string ConvertUser-

ProfileToXml(AppSetting profile), welche den von .NET bereitgestellten XmlSerializer

verwendet, um die AppSetting-Klasse in eine Zeichenkette umzuwandeln. Der entstandene

120

7.3 Erläuterungen zu sonstigen Klassen

string kann ähnlich wie bei der Methode des Speicherns einer Projektdatei auf dem Ser-

ver an einen Web Service übergeben werden. Analog verhält sich der Vorgang des Ladens

von Benutzereinstellungen vom Server. Das empfangene XML-Dokument enthält die textuel-

le Repräsentation einer AppSettings-Instanz, welche mit dem XmlSerializer in ein solches

Objekt deserialisiert wird. Das ViewModel ist anschlieÿend für das Setzen der individuellen

Einstellungen an der Ober�äche verantwortlich.

Da im Silverlight-Gantt-Editor auf die Implementierung eines Mehrbenutzersystems verzich-

tet wurde, lassen sich in der Beispielanwendung zwar Einstellungen serverseitig speichern,

jedoch können diese keinem spezi�schen Benutzer zugeordnet werden. Die hier beschriebene

Realisierung lädt also stets die individuelle Kon�guration desjenigen Anwenders, der zuletzt

die Einstellungen gespeichert hat.


7.3.1 UserControls der Anwendung

Neben dem Hauptfenster des Silverlight-Gantt-Editors, existieren noch andere Dialogfenster

und Controls, die hier kurz beschrieben werden sollen. Diese wurden im Rahmen der Arbeit

nicht nach dem MVVM entworfen, sondern sind klassisch über deren Code-Behind-Datei mit

der nötigen Applikationslogik versorgt worden, da sie auch isoliert von der Anwendung beste-

hen könnten. Solche Komponenten von geringem Umfang sind weniger Wartungsintensiv und

würden durch Anwendung des MVVM unnötig komplex und Arbeitsaufwendig. Die Aufgaben

dieser UserControls bestehen z.B. darin, eine Aktivität innerhalb eines eigenen Dialogfensters,

oder allgemeine Programmeinstellungen zu bearbeiten. Das Menü, welches durch die rechte

Maustaste geö�net wird, gehört genauso dazu, wie die Informations- oder Fehlermeldungen

der Anwendung. Detaillierte Angaben zur Realisierung �nden sich erneut im Quelltext der

Dateien.

Aktivitäts-Editor: TaskEditor.xaml und TaskEditor.xaml.cs erstellen ein Dialogfenster,

in dem eine Aktivität bearbeitet werden kann (Abbildung 7.8).

Dem Editor wird beim Aufruf die Instanz der gerade gewählten Zeile2 (also einer

SchedulingActivity) sowie das zugehörige ProjectSchedulingModel übergeben. Der

XAML-Code des Controls bindet daraufhin die Eingabefelder an die entsprechenden

Attribute der Aktivität. Der Modus ist hier in der Regel TwoWay, sodass jede Änderung

sofort im Diagramm angezeigt wird. Während der Bearbeitung ist das automatische

2Das ViewModel bzw. die Commands stellen sicher, dass immer der richtige Editor (also Ressourcen- oderAktiväten-Editor) geö�net wird, bzw. der zugehörige Button (in)aktiv ist.

121


Leveling von ILOG Gantt unterbrochen.

Die Listen der Reservierungen und Ressourcen entstammen der Instanz des Project-

SchedulingModel und werden ebenfalls direkt dort geändert.

Ressourcen-Editor: ResourceEditor.xaml und ResourceEditor.xaml.cs erstellen ein Dia-

logfenster, in dem eine Ressource bearbeitet werden kann (Abbildung 7.9).

Beim Aufruf wird dem Editor die gerade ausgewählte Zeile (also eine SchedulingRe-

source) übergeben. Die Bindings erfolgen analog zum Aktivitäten-Editor in XAML.

Einstellungsfenster: SettingsEditor.xaml und SettingsEditor.xaml.cs erstellen ein Dia-

logfenster, in dem individuelle Programmeinstellungen vorgenommen werden können

(Abbildung 7.10).

Dem Editor wird beim Aufruf die aktuell verwendete AppSettings-Instanz (aus der

Property UserProfile des ViewModels) übergeben. Auch hier werden die jeweiligen

Attribute an die Werte der CheckBoxes gebunden.

Menü der rechten Maustaste: GanttContextMenu.cs erstellt ein kleines Kontextmenü,

welches nach einem Klick mit der rechten Maustaste im Chart Control erscheint (Abbil-

dung 7.11).

Das Rechtsklick-Menü basiert auf einer Beispieldatei, bereitgestellt in Microsofts Tuto-

rials zu Silverlight3. In der Klasse GanttContextMenu wird programmatisch ein kleines

Fenster mit den drei Kontextmenüeinträgen erzeugt. Jede Zeile erhält einen einfachen

Eventhandler auf das Click-Ereignis, der die jeweilige Option ausführt. Dazu wird beim

Aufruf des Menüs die Instanz des MainViewModel übergeben. (Das MainViewModel in-

stanziert dieses Menü und übergibt die eigene Instanz.) Weiterhin muss darauf geachtet

werden, dass Silverlight stets versucht das eigene Rechtsklickmenü des Plugins zu ö�nen.

Man kann dies durch die Angabe des Attribut e.Handled = true unterbinden, welches

aus den EventArgs e des Ereignisses stammt.

Kurze Mitteilungen: ControlLibrary-Bibliothek beinhaltet Fehler- bzw. Informationsmel-

dungen (Abbildung 7.12).

Die Bibliothek wurde eigens für diese Anwendung erstellt und enthält allgemein für

Silverlightanwendungen wiederverwendbare Controls, wie beispielsweise einfache Fehler-

oder Informationsmeldungen. Diese Komponenten können in anderen Anwendungen wie-

derverwendet werden, da sie recht simpel aufgebaut sind und nur wenig interne Logik

mitbringen. Bei ihrem Aufruf wird lediglich der Titel des Fensters, sowie der Nachrich-

tentext und der Typ der Mitteilung (Info, Fehler, . . . ) angegeben.

Alle in diesem Abschnitt behandelten Klassen (auÿer GanttContextMenu) erben von der .NET-

Klasse ChildWindow, welche das Grundgerüst eines Unterfensters zu einer Silverlightanwen-

3http://www.silverlight.net/learn/videos/all/right-click-mouse-events/

122


dung bildet. Es ist ein Control mit Titelleiste und erinnert an ein Windows-Dialog. Zusätzlich

sperrt es bei seinem Erscheinen die dahinter liegende Silverlightanwendung, sodass der Be-

nutzer die Meldung bestätigen bzw. schlieÿen muss, bevor das Programm wieder freigegeben

wird.

Abb. 7.8: Aktivitäts-Editor

Abb. 7.9: Ressourcen-Editor

123


Abb. 7.10: Programmeinstellungen

Abb. 7.11: Rechtsklick-Menü

Abb. 7.12: Fehlermeldung

124

7.4 Deployment

7.3.2 Die Hauptanwendung App.xaml

Den initialen Einstiegspunkt der Anwendung bilden App.xaml bzw. App.xaml.cs. Sie wird

vom Silverlightplugin aufgerufen, sobald die XAP-Datei vollständig geladen wurde. Die (in

der Regel) von Visual Studio generierten Dateien enthalten beispielsweise Code, der eine

Instanz des Hauptfensters MainPage.xaml erzeugt und somit View, ViewModel und Model

instanziert. Des Weiteren be�ndet sich darin eine Methode, die nicht behandelte Exceptions

der Anwendung an die Fehlerkonsole des Browsers weiterleitet4. Im Rahmen dieser Arbeit

wird dort zusätzlich eine benutzerde�nierte Fehlermeldung (Abbildung 7.12) angezeigt, sodass

auftretende Exceptions nicht übersehen werden. Das MVVM Light Toolkit fügt weiterhin

einige Zeilen ein, die beim Beenden der Anwendung die geladene Instanz des MainViewModel

auf null setzen und dadurch Speicher wieder freigegeben.

7.4 Deployment

Die fertig kompilierte Silverlightanwendung steht (als XAP-Datei gepackt) zur Integration in

eine Internetseite zur Verfügung.

Wie in Listing 3.1 (S. 25) beschrieben wurde, dient das <object>-Tag als Container der RIA.

Listing 7.19 zeigt die Einbettung des Silverlight-Gantt-Editors. Die enthaltenen Parameter

sind von Visual Studio erzeugt und standardmäÿig bei jeder Silverlightanwendung gleich �

lediglich die Angabe zur Quelle der XAP-Datei unterscheidet sich und verweist hier auf den

Ordner ClientBin und die darin enthaltene Datei SilverlightGanttEditor.xap.

1 <object data="data:application/x-silverlight -2,"

2 type="application/x-silverlight -2" width="100%" height="100%">

3 <param name="source" value="ClientBin/SilverlightGanttEditor.xap"/>

4 <param name="onError" value="onSilverlightError" />

5 <param name="background" value="white" />

6 <param name="minRuntimeVersion" value="4.0.50401.0" />

7 <param name="autoUpgrade" value="true" />

8 <param name="EnableGPUAcceleration" value="true" />

9 <a href="http ://go.microsoft.com/fwlink /? LinkID =149156&v=4.0.50401.0"

10 style="text -decoration:none">

11 <img src="http ://go.microsoft.com/fwlink /? LinkId =161376"

12 alt="Get Microsoft Silverlight" style="border -style:none"/>

13 </a>

14 </object >

Listing 7.19: SilverlightGanttEditorTestPage.html: Das HTML-<object> referenziert die

Anwendung

4Nach dem Prinzip des Event-Bubbling, �blubbern� alle Ereignisse und Exceptions im visual tree nach oben.Werden sie in keinem Element behandelt, kommen sie letztendlich auf der höchsten Ebene des hierarchischenBaumes (App.xaml.cs) an und sollten dort stets wahrgenommen werden.

125

7.4 Deployment

Zusätzlich wurde durch den Paramater EnableGPUAcceleration versucht, die Leistungsfähig-

keit der Anwendung zu erhöhen, indem die Gra�kkarte das Zeichnen von Gra�ken optimiert.

Auf diese Weise müssen nicht alle Berechnungen vom Prozessor durchgeführt werden.

In der Beispielanwendung be�nden sich Server und Web Services auf dem gleichen Rech-

ner, welcher als Host für die Internetseite der RIA dient. Kompiliert und startet man den

Silverlight-Gantt-Editor mit Visual Studio, wird ein lokaler Server gestartet, welcher sowohl

die Silverlightanwendung, als auch den Web Service (GanttWebService) beherbergt. Die cli-

entaccesspolicy.xml erlaubt dabei Service-Anfragen von allen Quellen, sodass Programm

und Datendienste hier umfassend getestet werden können.

126

Kapitel 8

Evaluation

Diese Bachelorarbeit hatte den Entwurf und die Realisierung einer mehrschichtigen, Service-

orientierten, sowie interaktiven Silverlightanwendung zum Ziel. Dazu sollten die verschiedenen

grundlegenden Technologien und Standards zur Realisierung einer solchen zunächst untersucht

und beschrieben werden. Der praktische Teil der Arbeit umfasste die Realisierung eines einfa-

chen Szenarios auf Basis von Microsoft Silverlight 4.0 und IBM ILOG Gantt for .NET.

8.1 Umsetzung der Anforderungen

Nach einer Einführung in die Grundlagen von Rich Internet Applications, umfasst die Ba-

chelorarbeit Erläuterungen zu den verwendeten Basistechnologien. Dazu zählen sowohl Web

Services und Service-orientierte Architekturen, welche das Fundament datengetriebener RIAs

bilden, als auch Microsoft Silverlight als Plugin zur Entwicklung interaktiver Webanwendun-

gen. Weiterhin beinhaltet diese Arbeit positive wie negative Aspekte, Entwicklungstendenzen

und Einblicke in die Marktverbreitung gängiger Rich Internet Applications.

Zur Demonstration der Funktionsweise einer RIA wurde anhand einer Projektverwaltung mit-

tels Gantt-Diagrammen das Praxisbeispiel Silverlight-Gantt-Editor realisiert. Dabei wurden

alle gängigen Technologien im Silverlight-Umfeld eingeführt und benutzt. Die aus den Elemen-

ten und Möglichkeiten eines Gantt-Diagramms entstandenen Anforderungen sind während des

Entwurfs der Anwendung berücksichtigt worden. Sie dienten als Leitfaden zur Entwicklung

der verschiedenen UML-Diagramme und Abbildungen, welche die RIA grundlegend model-

lierten. Anhand des Model-View-ViewModel-Entwurfmusters wurden die Schichten des Pra-

xisbeispiels abgeleitet und implementiert. Das .NET-Framework, Silverlight und das MVVM

Light Toolkit stellten dabei die benötigte Funktionalität und Schnittstellen zum verwendeten

Web Service bereit. Mit Hilfe von Visual Studio und Expression Blend, wurde die Software

127

8.2 Zusammenfassung und Fazit

zur Projektverwaltung aus den zuvor geplanten Modellen realisiert.

8.2 Zusammenfassung und Fazit

Das Thema Silverlight ist ein sehr vielschichtiges und komplexes Thema, welches hier, auf

kleinem Raum und innerhalb einer fokussierten Sichtweise, abgebildet wurde.

Ein Ziel dieser Bachelorarbeit war zunächst die Einführung in Grundlagen zu Rich Inter-

net Applications, zu Web Services und allgemein der SOA-Technologie. Anschlieÿend wurde

Silverlight vorgestellt und die wichtigsten technischen Aspekte erläutert. Neben dem Plugin

selbst und der Beschreibungssprache für Silverlight-Ober�ächen (XAML), stand hier auch die

dahinter liegende logische Schicht im Vordergrund.

Der zweite Teil entwickelte anhand der vorgestellten Techniken ein Praxisbeispiel zur Bearbei-

tung von Gantt-Projekten. Dazu wurde zunächst das Model-View-ViewModel-Entwurfsmuster

vorgestellt, um es dann zur Realisierung des Silverlight-Gantt-Editors einzusetzen. Weiterhin

wurden dort Anforderungen erhoben und Konzepte entwickelt, die für die Implementierung

des Praxisbeispiels nötig waren. Anschlieÿend richtete sich der Fokus auf die spezi�sche Um-

setzung des Silverlight-Projekts.

Die Realisierung einer Silverlightanwendung orientiert sich an vielen Bereichen der Software-

entwicklung. Die Technologie der RIAs als Schnittmenge zwischen klassischen Desktopapplika-

tionen und Internetseiten erfordert die Nutzung von Konzepten und Entwicklungsmustern aus

beiden Paradigmen. Die relativ neuen Technologien der Rich Internet Applications (speziell

Silverlight), sind für viele Webanwendungen interessant. Aufgrund der geringen Einschrän-

kungen bei System- und Plattformunabhängigkeiten haben sie das Potential die Landschaft

der Internet-Technologien neu zu gestalten. Die schnelle Folge von Verö�entlichungen neuer

Silverlightversionen durch Microsoft beweist die Relevanz von Rich Internet Applications und

ihren Entwicklungs-Frameworks für moderne Webanwendungen.

Das relativ junge RIA-Framework von Microsoft, bietet alle notwendigen Komponenten zur

Entwicklung von hoch-interaktiven RIAs. Mit Unterstützung der (reduzierten, aber dennoch)

mächtigen .NET-Bibliotheken stellt Silverlight vielfältige Entwicklungsmöglichkeiten für mo-

derneWebanwendungen zur Verfügung. Im Zuge der Entwicklung des Silverlight-Gantt-Editors

hat sich Silverlight als geeignetes Werkzeug erwiesen, denn es bot ausreichend Möglichkeiten

zur Umsetzung der erarbeiteten Konzepte. Vom Plugin nicht unterstütze Funktionalität kann

mit Hilfe der darin enthaltenen Komponenten von den Entwicklern individuell realisiert, oder

durch Frameworks von Drittherstellern ergänzt werden. IBM ILOG bestach durch umfang-

reiche Möglichkeiten an Funktionalität und Gestaltung der Gantt-Diagramme. Lediglich die

Performanz lieÿ bei gröÿeren Projekten zeitweise nach.

128

Teil III

Anhang

129

Anhang A

Zusätzliche Abbildungen und Listings

A.1 WSDL-Datei des verwendeten Web Service

1 <?xml version="1.0" encoding="UTF -8"?>

2 <wsdl:definitions xmlns:soap="http: // schemas.xmlsoap.org/wsdl/soap/" xmlns:tm="http://

microsoft.com/wsdl/mime/textMatching/" xmlns:soapenc="http:// schemas.xmlsoap.org/

soap/encoding/" xmlns:mime="http:// schemas.xmlsoap.org/wsdl/mime/" xmlns:tns="

http:// tempuri.org/" xmlns:s="http://www.w3.org /2001/ XMLSchema" xmlns:soap12="

http:// schemas.xmlsoap.org/wsdl/soap12/" xmlns:http="http:// schemas.xmlsoap.org/

wsdl/http/" targetNamespace="http:// tempuri.org/" xmlns:wsdl="http: // schemas.

xmlsoap.org/wsdl/">

3 <wsdl:types >

4 <s:schema elementFormDefault="qualified" targetNamespace="http:// tempuri.org/">

5 <s:element name="TestServer">

6 <s:complexType/>

7 </s:element >

8 <s:element name="TestServerResponse">

9 <s:complexType >

10 <s:sequence >

11 <s:element minOccurs="0" maxOccurs="1" name="TestServerResult" type="

s:string"/>

12 </s:sequence >

13 </s:complexType >

14 </s:element >

15 <s:element name="ReadTestFile">

16 <s:complexType/>

17 </s:element >

18 <s:element name="ReadTestFileResponse">

19 <s:complexType >

20 <s:sequence >

21 <s:element minOccurs="0" maxOccurs="1" name="ReadTestFileResult" type="

s:string"/>

22 </s:sequence >


24 </s:element >

25 <s:element name="SaveProject">

i


26 <s:complexType >

27 <s:sequence >

28 <s:element minOccurs="0" maxOccurs="1" name="xmlProject" type="s:string"/>

29 <s:element minOccurs="1" maxOccurs="1" name="projectId" type="s:int"/>

30 </s:sequence >


32 </s:element >

33 <s:element name="SaveProjectResponse">

34 <s:complexType >

35 <s:sequence >

36 <s:element minOccurs="1" maxOccurs="1" name="SaveProjectResult" type="

s:boolean"/>

37 </s:sequence >


39 </s:element >

40 <s:element name="SaveUserProfile">

41 <s:complexType >

42 <s:sequence >

43 <s:element minOccurs="0" maxOccurs="1" name="xmlAppSetting" type="s:string

"/>

44 <s:element minOccurs="1" maxOccurs="1" name="userId" type="s:int"/>

45 </s:sequence >


47 </s:element >

48 <s:element name="SaveUserProfileResponse">

49 <s:complexType >

50 <s:sequence >

51 <s:element minOccurs="1" maxOccurs="1" name="SaveUserProfileResult" type="

s:boolean"/>

52 </s:sequence >


54 </s:element >

55 <s:element name="OpenUserProfile">

56 <s:complexType >

57 <s:sequence >

58 <s:element minOccurs="1" maxOccurs="1" name="userID" type="s:int"/>

59 </s:sequence >


61 </s:element >

62 <s:element name="OpenUserProfileResponse">

63 <s:complexType >

64 <s:sequence >

65 <s:element minOccurs="0" maxOccurs="1" name="OpenUserProfileResult" type="

s:string"/>

66 </s:sequence >


68 </s:element >

69 </s:schema >

70 </wsdl:types >

71 <wsdl:message name="TestServerSoapIn">

72 <wsdl:part name="parameters" element="tns:TestServer"/>

73 </wsdl:message >

74 <wsdl:message name="TestServerSoapOut">

75 <wsdl:part name="parameters" element="tns:TestServerResponse"/>

76 </wsdl:message >

77 <wsdl:message name="ReadTestFileSoapIn">

ii


78 <wsdl:part name="parameters" element="tns:ReadTestFile"/>

79 </wsdl:message >

80 <wsdl:message name="ReadTestFileSoapOut">

81 <wsdl:part name="parameters" element="tns:ReadTestFileResponse"/>

82 </wsdl:message >

83 <wsdl:message name="SaveProjectSoapIn">

84 <wsdl:part name="parameters" element="tns:SaveProject"/>

85 </wsdl:message >

86 <wsdl:message name="SaveProjectSoapOut">

87 <wsdl:part name="parameters" element="tns:SaveProjectResponse"/>

88 </wsdl:message >

89 <wsdl:message name="SaveUserProfileSoapIn">

90 <wsdl:part name="parameters" element="tns:SaveUserProfile"/>

91 </wsdl:message >

92 <wsdl:message name="SaveUserProfileSoapOut">

93 <wsdl:part name="parameters" element="tns:SaveUserProfileResponse"/>

94 </wsdl:message >

95 <wsdl:message name="OpenUserProfileSoapIn">

96 <wsdl:part name="parameters" element="tns:OpenUserProfile"/>

97 </wsdl:message >

98 <wsdl:message name="OpenUserProfileSoapOut">

99 <wsdl:part name="parameters" element="tns:OpenUserProfileResponse"/>

100 </wsdl:message >

101 <wsdl:portType name="GanttWebServiceSoap">

102 <wsdl:operation name="TestServer">

103 <wsdl:input message="tns:TestServerSoapIn"/>

104 <wsdl:output message="tns:TestServerSoapOut"/>

105 </wsdl:operation >

106 <wsdl:operation name="ReadTestFile">

107 <wsdl:input message="tns:ReadTestFileSoapIn"/>

108 <wsdl:output message="tns:ReadTestFileSoapOut"/>


110 <wsdl:operation name="SaveProject">

111 <wsdl:input message="tns:SaveProjectSoapIn"/>

112 <wsdl:output message="tns:SaveProjectSoapOut"/>


114 <wsdl:operation name="SaveUserProfile">

115 <wsdl:input message="tns:SaveUserProfileSoapIn"/>

116 <wsdl:output message="tns:SaveUserProfileSoapOut"/>


118 <wsdl:operation name="OpenUserProfile">

119 <wsdl:input message="tns:OpenUserProfileSoapIn"/>

120 <wsdl:output message="tns:OpenUserProfileSoapOut"/>


122 </wsdl:portType >

123 <wsdl:binding name="GanttWebServiceSoap" type="tns:GanttWebServiceSoap">

124 <soap:binding transport="http: // schemas.xmlsoap.org/soap/http"/>


126 <soap:operation soapAction="http:// tempuri.org/TestServer" style="document"/>

127 <wsdl:input >

128 <soap:body use="literal"/>

129 </wsdl:input >

130 <wsdl:output >


132 </wsdl:output >


iii



135 <soap:operation soapAction="http:// tempuri.org/ReadTestFile" style="document"/>

136 <wsdl:input >


138 </wsdl:input >

139 <wsdl:output >


141 </wsdl:output >



144 <soap:operation soapAction="http:// tempuri.org/SaveProject" style="document"/>

145 <wsdl:input >


147 </wsdl:input >

148 <wsdl:output >


150 </wsdl:output >



153 <soap:operation soapAction="http:// tempuri.org/SaveUserProfile" style="document"

/>

154 <wsdl:input >


156 </wsdl:input >

157 <wsdl:output >


159 </wsdl:output >



162 <soap:operation soapAction="http:// tempuri.org/OpenUserProfile" style="document"

/>

163 <wsdl:input >


165 </wsdl:input >

166 <wsdl:output >


168 </wsdl:output >


170 </wsdl:binding >

171 <wsdl:binding name="GanttWebServiceSoap12" type="tns:GanttWebServiceSoap">

172 <soap12:binding transport="http:// schemas.xmlsoap.org/soap/http"/>


174 <soap12:operation soapAction="http: // tempuri.org/TestServer" style="document"/>

175 <wsdl:input >

176 <soap12:body use="literal"/>

177 </wsdl:input >

178 <wsdl:output >


180 </wsdl:output >



183 <soap12:operation soapAction="http: // tempuri.org/ReadTestFile" style="document"/

>

184 <wsdl:input >


186 </wsdl:input >

iv


187 <wsdl:output >


189 </wsdl:output >



192 <soap12:operation soapAction="http: // tempuri.org/SaveProject" style="document"/>

193 <wsdl:input >


195 </wsdl:input >

196 <wsdl:output >


198 </wsdl:output >



201 <soap12:operation soapAction="http: // tempuri.org/SaveUserProfile" style="

document"/>

202 <wsdl:input >


204 </wsdl:input >

205 <wsdl:output >


207 </wsdl:output >



210 <soap12:operation soapAction="http: // tempuri.org/OpenUserProfile" style="

document"/>

211 <wsdl:input >


213 </wsdl:input >

214 <wsdl:output >


216 </wsdl:output >


218 </wsdl:binding >

219 <wsdl:service name="GanttWebService">

220 <wsdl:port name="GanttWebServiceSoap" binding="tns:GanttWebServiceSoap">

221 <soap:address location="http:// localhost:2410/SilverlighGanttEditor.WebHost/

GanttWebService.asmx"/>

222 </wsdl:port >

223 <wsdl:port name="GanttWebServiceSoap12" binding="tns:GanttWebServiceSoap12">

224 <soap12:address location="http:// localhost:2410/SilverlighGanttEditor.WebHost/

GanttWebService.asmx"/>

225 </wsdl:port >

226 </wsdl:service >

227 </wsdl:definitions >

Listing A.1: WSDL-Datei des GanttWebService

v

A.2 Klassendiagramm GanttWebServiceSoapClient

A.2 Klassendiagramm GanttWebServiceSoapClient

Ausschnitt der von Visual Studio erzeugten Serviceklasse zur programmatischen Verwendung

des GanttWebService.

Abb. A.1: Klasse GanttWebServiceSoapClient

A.3 Funktion zum Auslesen einer Gantt-Projekt-Datei

Ausschnitt aus der Datei FileIO.cs: ReadProjectModel(XDocument xml) liest ein XML-

Dokument und erzeugt daraus ein Gantt-Projekt.

1 /// <summary >

2 /// Extracts a Gantt project model from xml

3 /// </summary >

4 /// <param name=" xmlContent">A string containing well formed xml content , describing a

Gantt project </param >

5 /// <returns >Full referenced and scheduled project model </returns >

6 static private ProjectSchedulingModel ReadProjectModel(XDocument xml)

7 {

8 ProjectSchedulingModel model = new ProjectSchedulingModel ();

9

vi


10 #region schedule meta -data

11 // title

12 DateTime projectStart = DateTime.MaxValue;

13 #endregion

14

15 #region activities

16 // create new dictionary to store activities

17 Dictionary <string , SchedulingActivity > activities = new Dictionary <string ,

SchedulingActivity >();

18 XElement activitiesElement = xml.Descendants("activities").FirstOrDefault ();

19

20 // group several modifications so that only one single schedule will be computed

21 model.BeginScheduleSession ();

22

23 if (activitiesElement == null)

24 throw new XmlException("Found no activities.");

25

26 // dateTime format

27 string format = (string)activitiesElement.Attribute("dateFormat");

28

29 // collect activities

30 foreach (XElement element in xml.Descendants("activity"))

31 {

32 // try to find parent activity in direct predecessor or in set of already existing

activities

33 SchedulingActivity parent;

34 string parentID = (string)element.Parent.Attribute("id");

35

36 if (parentID == null || !activities.TryGetValue(parentID , out parent))

37 {

38 parent = null;

39 }

40

41 // create new activity

42 SchedulingActivity activity = new SchedulingActivity ()

43 {

44 Name = (string)element.Attribute("name"),

45 StartTime = XmlConvert.ToDateTime (( string)element.Attribute("start"), format),

46 EndTime = XmlConvert.ToDateTime (( string)element.Attribute("end"), format),

47 IsMilestone = XmlConvert.ToBoolean (( string)ConvertSDXLProperty(element , "

milestone", "false")), // might be undetermined

48 Info = (string)element.Attribute("info"), // might be undetermined

49 WorkComplete = (float)ConvertSDXLProperty(element , "complete", 0f), // might be

undetermined

50 Parent = parent // could be null

51 };

52

53 // check new project start time

54 if (activity.StartTime < projectStart)

55 projectStart = activity.StartTime;

56

57 // set activity duration - might be undetermined and definied by StartTime/EndTime

58 XElement duration = element.Element("Duration");

59 if (duration != null)

60 activity.Duration = XmlConvert.ToTimeSpan(duration.Value); // duration set

61 else if (! activity.IsMilestone && !activity.IsSummary) // milestones and summaries

vii


don't have a duration

62 activity.Duration = WorkCalendar.Standard.WorkBetween(activity.StartTime ,

activity.EndTime); // calculate duration based on start/end time

63

64 // store in dictionary for further usage

65 activities [( string)element.Attribute("id")] = activity;

66 model.Activities.Add(activity);

67 }

68

69 model.StartDate = projectStart;

70 #endregion

71

72 #region constraints

73 // LINQ and the dictionary simplifies further parsing ...

74 var constraints = from constraint in xml.Descendants("constraint")

75 select new SchedulingConstraint ()

76 {

77 FromActivity = activities [( string)constraint.Attribute("from")], // get

activity object

78 ToActivity = activities [( string)constraint.Attribute("to")], // get

activity object

79 Type = ConvertToConstraintType (( string)constraint.Attribute("type")), //

get constraint type

80 Info = (string)constraint.Attribute("info") // could be empty string

81 };

82 foreach (var constraint in constraints)

83 model.Constraints.Add(constraint as SchedulingConstraint);

84 #endregion

85

86 #region resources

87 // create new dictionary to store resources

88 Dictionary <string , SchedulingResource > resources = new Dictionary <string ,

SchedulingResource >();

89 // collect resources

90 foreach (XElement element in xml.Descendants("resource"))

91 {

92 // same approach as above

93 string parentID = (string)element.Parent.Attribute("id");

94 SchedulingResource parent;

95 if (parentID == null || !resources.TryGetValue(parentID , out parent))

96 parent = null;

97 SchedulingResource resource = new SchedulingResource ()

98 {

99 Name = (string)element.Attribute("name"),

100 Info = (string)element.Attribute("info"),

101 MaxUnits = ConvertToUnits(element.Attribute("quantity"), 1f),

102 Parent = parent

103 };

104 resources [( string)element.Attribute("id")] = resource;

105 }

106 foreach (var resource in resources.Values)

107 model.Resources.Add(resource as SchedulingResource);

108 #endregion

109

110 #region reservations

111 var reservations = from reservation in xml.Descendants("reservation")

viii


112 select new SchedulingReservation ()

113 {

114 Activity = activities [( string)reservation.Attribute("activity")],

115 Resource = resources [( string)reservation.Attribute("resource")],

116 Info = (string)reservation.Attribute("info"),

117 Units = ConvertToUnits(reservation.Attribute("units"), 1f)

118 };

119 foreach (var reservation in reservations)

120 model.Reservations.Add(reservation as SchedulingReservation);

121 #endregion

122

123 // complete initialisation process

124 model.EndScheduleSession ();

125

126 return model;

127 }

128

129 #region Helpers

130

131 /*

132 * The following methods are helper methodes for .NET features like LINQ and object

initializer.

133 * Modified after original source from the IBM ILOG Gantt Samples.

134 */

135

136 /// <summary >

137 /// Converts a xml property (string) into a more useful object.

138 /// </summary >

139 /// <param name=" element">xml element </param >

140 /// <param name=" property">expected property name </param >

141 /// <param name=" defaultValue">default value instead of null </param >

142 /// <returns ></returns >

143 static private object ConvertSDXLProperty(XElement element , string property , object

defaultValue)

144 {

145 // get value from first (child) property of an element , where name = property

146 XElement propertyElement = element.Elements("property").FirstOrDefault(e => (e.

Attribute(property) != null));

147 if (propertyElement == null)

148 return defaultValue;

149 return propertyElement.Value;

150 }

151

152 /// <summary >

153 /// Converts a xml attribute into a more useful float value

154 /// </summary >

155 /// <param name="a">An attribute from xml </param >

156 /// <param name=" defaultValue">default value instead of null </param >


158 static private float ConvertToUnits(XAttribute a, float defaultValue)

159 {

160 if (a == null)

161 return defaultValue;

162 else return (float)a;

163 }

164

ix


165 /// <summary >

166 /// Converts a string into a more useful ConstraintType enum

167 /// </summary >

168 /// <param name="p"></param >


170 static private ConstraintType ConvertToConstraintType(string p)

171 {

172 switch (p)

173 {

174 case "End -Start": return ConstraintType.EndToStart;

175 case "End -End": return ConstraintType.EndToEnd;

176 case "Start -Start": return ConstraintType.StartToStart;

177 case "Start -End": return ConstraintType.StartToEnd;

178 default:

179 throw new NotSupportedException("Bad Constraint Type");

180 }

181 }

Listing A.2: FileIO.cs: Funktion ReadProjectModel(XDocument xml) und Helfermethoden

x

A.4 Klassendiagramm der Praxisanwendung

A.4 Klassendiagramm der Praxisanwendung

Abb. A.2: Klassendiagramm des Silverlight-Gantt-Editors (um Attribute und Funktionen reduzierteÜbersicht)

xi

Anhang B

Verzeichnisse

xii

Literaturverzeichnis

Adobe (2010): Adobe Corporate Fact Sheet. URL: http://www.adobe.com/aboutadobe/

pressroom/pdfs/fastfacts.pdf (Stand: 27.07.2010).

Allaire, J. (2002): Macromedia Flash MX-A next generation rich client. URL: http://www.

adobe.com/devnet/flash/whitepapers/richclient.pdf (Stand: 27.07.2010).

can/AP/apn (2010): O�ener Brief. Steve Jobs prophezeit das Ende von Adobes Flash-Player.

Spiegel Online, -: 1.

Collins, J. (2009): Security Guidance for Writing and Deploying Silver-

light Applications. URL: http://download.microsoft.com/download/4/9/C/

49C9AF94-03A1-4600-A334-D0AEEEAB35D2/Security%20Guidance%20for%20Writing%

20and%20Deploying%20Silverlight%20Applications.docx (Stand: 27.07.2010).

Czernicki, B. (2008a): Silverlight MultiThreading with a Computational Pro-

cess (Counting Primes). URL: http://silverlighthack.com/post/2008/09/07/

Silverlight-MultiThreading-with-a-Computational-Process-%28Counting-Primes%

29.aspx (Stand: 27.07.2010).

Czernicki, B. (2008b): Sliverlight Multithreading with Controls (Sli-

der example). URL: http://silverlighthack.com/post/2008/09/01/

Sliverlight-Multithreading-with-Control-by-Example.aspx (Stand: 27.07.2010).

Esposito, D. (2008): The Silverlight 2.0 Security Model. URL: http://www.drdobbs.com/

security/206902613 (Stand: 27.07.2010).

Foley, M. J. (2010): Could Silverlight be Microsoft's next app

for Android? URL: http://www.zdnet.com/blog/microsoft/

could-silverlight-be-microsofts-next-app-for-android/5477 (Stand: 27.07.2010).

Fowler, M. (2004): Presentation Model. URL: http://martinfowler.com/eaaDev/

PresentationModel.html (Stand: 27.07.2010).

Galasoft (2010): MVVM Light Toolkit - Get Started. URL: http://www.galasoft.ch/

mvvm/getstarted/ (Stand: 27.07.2010).

xiii

http://www.adobe.com/aboutadobe/pressroom/pdfs/fastfacts.pdf

http://www.adobe.com/aboutadobe/pressroom/pdfs/fastfacts.pdf

http://www.adobe.com/devnet/flash/whitepapers/richclient.pdf

http://www.adobe.com/devnet/flash/whitepapers/richclient.pdf

http://download.microsoft.com/download/4/9/C/49C9AF94-03A1-4600-A334-D0AEEEAB35D2/Security%20Guidance%20for%20Writing%20and%20Deploying%20Silverlight%20Applications.docx



http://silverlighthack.com/post/2008/09/07/Silverlight-MultiThreading-with-a-Computational-Process-%28Counting-Primes%29.aspx



http://silverlighthack.com/post/2008/09/01/Sliverlight-Multithreading-with-Control-by-Example.aspx

http://silverlighthack.com/post/2008/09/01/Sliverlight-Multithreading-with-Control-by-Example.aspx

http://www.drdobbs.com/security/206902613

http://www.drdobbs.com/security/206902613

http://www.zdnet.com/blog/microsoft/could-silverlight-be-microsofts-next-app-for-android/5477

http://www.zdnet.com/blog/microsoft/could-silverlight-be-microsofts-next-app-for-android/5477

http://martinfowler.com/eaaDev/PresentationModel.html

http://martinfowler.com/eaaDev/PresentationModel.html

http://www.galasoft.ch/mvvm/getstarted/

http://www.galasoft.ch/mvvm/getstarted/

LITERATURVERZEICHNIS

Huber, T. C. (2008): Windows Presentation Foundation. Das umfassende Handbuch. Galileo

Computing, 1 Au�age.

IBM (2009a): IBM ILOG Gantt for .NET V4.0: Programming with IBM ILOG Gantt for

.NET - Silverlight Controls.

IBM (2009b): IBM ILOG Gantt for .NET V4.0 Programming with IBM ILOG Gantt for

.NET Windows Forms and Web Forms Controls.

IBM (2009c): IBM ILOG Gantt for .NET V4.0: Tutorials.

Janowicz, K. (2006): Sicherheit im Internet. O'Reilly, 2 Au�age.

Kramer, N. (2010): Silverlight Security Overview. URL: http://download.microsoft.com/

download/A/1/A/A1A80A28-907C-4C6A-8036-782E3792A408/Silverlight%20Security%

20Overview.docx (Stand: 27.07.2010).

MacDonald, M. (2009): Pro Silverlight 3 in C-Sharp. Apress.

Martin, L. (2009): Vorlesungsskript: Client- und serverseitige Webanwendungen SS2009, Kap.

3, Folie 32.

Masak, D. (2007): SOA?: Serviceorientierung in Business und Software. Springer.

Microsoft (2010a): MSDN Library: Events Overview for Silverlight. URL: http://msdn.

microsoft.com/en-us/library/cc189018%28VS.95%29.aspx (Stand: 27.07.2010).

Microsoft (2010b): MSDN Library: Silverlight Architecture. URL: http://msdn.

microsoft.com/en-us/library/bb404713%28VS.95%29.aspx (Stand: 27.07.2010).

Microsoft (2010c): MSDN Library: WCF RIA SERVICES. URL: http://msdn.microsoft.

com/de-de/library/ee707344%28vs.91%29.aspx (Stand: 27.07.2010).

Microsoft (2010d): Network Security Access Restrictions in Silverlight. URL: http://msdn.

microsoft.com/en-us/library/cc645032%28v=VS.95%29.aspx (Stand: 27.07.2010).

Noda, T. & Helwig, S. (2005): Rich Internet Applications: Technical Comparison and Case

Studies of AJAX, Flash, and Java based RIA. Best Practice Reports.

o.A. (2007): RIA: Rich INTERNET or INTERACTIVE Application? URL: http:

//www.wiredprairie.us/journal/2007/10/ria_rich_internet_or_interacti.html

(Stand: 27.07.2010).

o.A. (2010): Events Handling in MVVM. URL: http://goldytech.wordpress.com/2010/

02/14/events-handling-in-mvvm/ (Stand: 27.07.2010).

xiv

http://download.microsoft.com/download/A/1/A/A1A80A28-907C-4C6A-8036-782E3792A408/Silverlight%20Security%20Overview.docx



http://msdn.microsoft.com/en-us/library/cc189018%28VS.95%29.aspx

http://msdn.microsoft.com/en-us/library/cc189018%28VS.95%29.aspx

http://msdn.microsoft.com/en-us/library/bb404713%28VS.95%29.aspx

http://msdn.microsoft.com/en-us/library/bb404713%28VS.95%29.aspx

http://msdn.microsoft.com/de-de/library/ee707344%28vs.91%29.aspx

http://msdn.microsoft.com/de-de/library/ee707344%28vs.91%29.aspx

http://msdn.microsoft.com/en-us/library/cc645032%28v=VS.95%29.aspx

http://msdn.microsoft.com/en-us/library/cc645032%28v=VS.95%29.aspx

http://www.wiredprairie.us/journal/2007/10/ria_rich_internet_or_interacti.html

http://www.wiredprairie.us/journal/2007/10/ria_rich_internet_or_interacti.html

http://goldytech.wordpress.com/2010/02/14/events-handling-in-mvvm/

http://goldytech.wordpress.com/2010/02/14/events-handling-in-mvvm/


Papazoglou, M. P. (2007): Web Services: Principles and Technology. Pearson Education

Limited.

Pfeil, C. (2009): Adobe AIR: RIAs für den Destop entwickeln Know-how für HTML/Ajax-

und Flash/Flex-Entwickler. Addison-Wesley, 1 Au�age.

Riastats (2010): Rich Internet Application Statistics. URL: http://riastats.com/# (Stand:

27.07.2010).

Schibrowski, E. (2007): Web 3.0: das Ende von Google. URL: http://www.inf.

uni-konstanz.de/dbis/teaching/ws0708/web/essays/paper_schibrowski.pdf (Stand:

27.07.2010).

Scribner, K. & Seely, S. (2009): E�ective REST Services Via .NET: For .NET Framework

3.5. FT Press.

Shetty, A. (2009): Whitepaper: Search Engine Optimization for Silverlight applicati-

ons. URL: http://www.silverlight.net/learn/whitepapers/seo-for-silverlight/

(Stand: 27.07.2010).

StatOwl (2010): Rich Internet Application Market Share: RIA Market Penetration and

Global Usage. URL: http://www.statowl.com/custom_ria_market_penetration.php?

1=1&timeframe=last_12&interval=month&chart_id=16&fltr_br=&fltr_os=&fltr_se=

&fltr_cn=&chart_id=11 (Stand: 27.07.2010).

Tesar, D. (2009): Whitepaper: Silverlight Deployment Guide v2. URL: http://

download.microsoft.com/download/C/D/5/CD5AAAE3-21F7-47A8-B7D5-39E36BAF9AC8/

Silverlight%20Deployment%20Guide%20v2.docx (Stand: 27.07.2010).

Thomas Claudius Huber, C. P. (2007): Das Model View ViewModel-Pattern für WPF-

Anwendungen. dot.Net-Magazin, 50 (7): 2�10.

Virki, T. (2008): Nokia to use Microsoft Silverlight. The Australian, -: 1.

Wahlin, D. (2010): What's NewWith Silverlight. URL: http://www.drdobbs.com/windows/

222301472 (Stand: 27.07.2010).

Wegmann, C. & Winkelbauer, H. (2006): Projektmanagement für Unternehmensberatun-

gen. Gabler.

Wikipedia.org (2010): Microsoft Silverlight. URL: http://en.wikipedia.org/w/index.

php?title=Microsoft_Silverlight&oldid=371339162 (Stand: 27.07.2010).

Wildermuth, S. (2007): Getting Started with Silverlight. O'Reilly Media.

xv

http://riastats.com/#

http://www.inf.uni-konstanz.de/dbis/teaching/ws0708/web/essays/paper_schibrowski.pdf

http://www.inf.uni-konstanz.de/dbis/teaching/ws0708/web/essays/paper_schibrowski.pdf

http://www.silverlight.net/learn/whitepapers/seo-for-silverlight/

http://www.statowl.com/custom_ria_market_penetration.php?1=1&timeframe=last_12&interval=month&chart_id=16&fltr_br=&fltr_os=&fltr_se=&fltr_cn=&chart_id=11



http://download.microsoft.com/download/C/D/5/CD5AAAE3-21F7-47A8-B7D5-39E36BAF9AC8/Silverlight%20Deployment%20Guide%20v2.docx



http://www.drdobbs.com/windows/222301472

http://www.drdobbs.com/windows/222301472

http://en.wikipedia.org/w/index.php?title=Microsoft_Silverlight&oldid=371339162

http://en.wikipedia.org/w/index.php?title=Microsoft_Silverlight&oldid=371339162


Wildermuth, S. (2009): Model-View-ViewModel in Silverlight 2-Anwendungen. MSDN Ma-

gazin, 24/3: 1.

Wintellect (2009): Whitepaper: Programmatic Di�erences Between Silverlight and WPF.

URL: http://wpfslguidance.codeplex.com/releases/view/30311 (Stand: 27.07.2010).

Version 1.1.

xvi

http://wpfslguidance.codeplex.com/releases/view/30311

Abbildungsverzeichnis

2.1 Einordnung der RIA-Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Allgemeine Übersicht der Integration einer RIA . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Das Prinzip der Web Services (Quelle: nach Martin, 2009) . . . . . . . . . . . . . . . . 14

3.1 Silverlight Kompatibilitätsmatrix (Quelle nach: (Tesar, 2009, S. 8) und (Wikipedia.org,

2010)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Vereinfachte Silverlight-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Übersicht der Silverlight Architektur (Quelle: Microsoft, 2010b)) . . . . . . . . . . . . 24

3.4 Übersicht zum Deployment einer Silverlightanwendung . . . . . . . . . . . . . . . . . . 25

3.5 Übersicht der wichtigsten Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.6 Die von Listing 3.2 erzeugten Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.7 Durch Styles veränderte Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.8 Ein Button mit einfachem (A) und verbessertem (B) Template . . . . . . . . . . . . . 37

3.9 Vereinfachtes Konzept der Routed Events . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.10 Silverlights Data Binding und Bindingsmodi (Quelle: nach Huber, 2008, S. 627)) . . . 47

3.11 Geglückte und fehlgeschlagene Validierung . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.12 Web Service-Anbindung in Silverlight (Quelle: nach MacDonald, 2009, S. 681) . . . . . 51

3.13 Verfügbarkeit von RIA-Plugins (Statistik: nach StatOwl, 2010, Stand: Juni/Juli 2010) 57

3.14 Versionsverbreitung einzelner Frameworks (Statistik: nach Riastats, 2010, Stand: Ju-

ni/Juli 2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

xvii

ABBILDUNGSVERZEICHNIS

4.1 Ein einfaches Gantt-Diagramm mit kritischen Vorgängen. (Quelle: Wegmann & Win-

kelbauer, 2006, S. 108) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2 Personenspezi�sches Gantt-Diagramm für Wegmann. (Quelle: Wegmann & Winkelbau-

er, 2006, S. 117) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1 Vereinfachtes Use Case Diagramm der wichtigsten Programmfunktionen . . . . . . . . 68

6.1 Die Klassen der ChartControls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2 Übersicht der Scheduling Klassen von ILOG Gantt . . . . . . . . . . . . . . . . . . . . 74

6.3 Die ProjectSchedulingModel-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.4 Das Model-View-ViewModel für Silverlight . . . . . . . . . . . . . . . . . . . . . . . . 79

6.5 MVVM-Schichten der Beispielanwendung . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.6 Vereinfachter Ablauf des Projektinitialisierungsprozesses . . . . . . . . . . . . . . . . . 81

6.7 Komponentendiagramm der Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.8 Sequenzdiagramm Projekt ö�nen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.9 Sequenzdiagramm Projekteditierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.10 Aktivitätsdiagramm: Neue Zeile einfügen . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.11 Die Klassen des RelayCommand und ihre Methoden . . . . . . . . . . . . . . . . . . . . 90

6.12 Mögliche Konvertierungsrichtungen eines Gantt-Projekts . . . . . . . . . . . . . . . . . 94

7.1 Klassendiagramm: das Interface des Models und dessen Implementierung durch die

Klasse DataModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

7.2 Klassendiagramm der Event-Argumente . . . . . . . . . . . . . . . . . . . . . . . . . . 100

7.4 Die AppCommands-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7.3 Die MainViewModel-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

7.5 Screenshot des Silverlight-Gantt-Editors . . . . . . . . . . . . . . . . . . . . . . . . . . 116

7.6 Klasse FileIO.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

7.7 Die AppSettings-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

7.8 Aktivitäts-Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

xviii

ABBILDUNGSVERZEICHNIS

7.9 Ressourcen-Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

7.10 Programmeinstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

7.11 Rechtsklick-Menü . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

7.12 Fehlermeldung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

A.1 Klasse GanttWebServiceSoapClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

A.2 Klassendiagramm des Silverlight-Gantt-Editors (um Attribute und Funktionen redu-

zierte Übersicht) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

xix

Tabellenverzeichnis

2.1 Vergleich von Web- und Desktopanwendungen . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Vergleich von Silverlight und WPF (Nach: Wildermuth, 2007, S. 19)) . . . . . . . . . . 20

3.2 Kernkomponenten der Silverlight Plattform (Quelle: Microsoft, 2010b) . . . . . . . . . 23

4.1 Hauptkomponenten eines Gantt-Diagramms . . . . . . . . . . . . . . . . . . . . . . . . 64

7.2 Kernklassen der MVVM-Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

xx

Listings

3.1 Deployment einer Silverlightanwendung in einer HTML-Internetseite . . . . . . . . . . 25

3.2 Ein gültiges XAML-Dokument für Silverlight . . . . . . . . . . . . . . . . . . . . . . . 30

3.3 Ressourcende�nition und Referenzierung . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 Verwendung von Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.5 Ein einfaches Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.6 Das verbesserte Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.7 XAML einer leeren Silverlight-Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.8 Code-Behind Datei einer leeren Silverlight-Anwendung . . . . . . . . . . . . . . . . . . 40

3.9 CheckBox in XAML mit eindeutigem Identi�er . . . . . . . . . . . . . . . . . . . . . . 40

3.10 Code-Das IsChecked-Attribut wird gesetzt . . . . . . . . . . . . . . . . . . . . . . . . 41

3.11 Dem Click-Event eines Buttons wird eine Methode zugewiesen . . . . . . . . . . . . . 43

3.12 Code-Behind Datei mit aufzurufender Methode . . . . . . . . . . . . . . . . . . . . . . 43

3.13 ICommand wird von MyWorkCommand implementiert . . . . . . . . . . . . . . . . . . . . 44

3.14 Der Command wird in der Code-Behind-Datei instanziert . . . . . . . . . . . . . . . . 45

3.15 Dem Button wird ein MyWorkerCommand zugewiesen . . . . . . . . . . . . . . . . . . . 45

3.16 Data Binding zweier Elemente in XAML . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.17 Klassende�nition eines Adressbucheintrages . . . . . . . . . . . . . . . . . . . . . . . . 47

3.18 Instanziierung und Verö�entlichung eines Objekts in der Code-Behind-Datei . . . . . . 48

3.19 XAML für ein Object-Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

xxi

LISTINGS

3.20 Eine simple clientaccesspolicy.xml (Quelle: nach Microsoft, 2010d) . . . . . . . . . . . 50

3.21 Sicherheitsrisiken durch Silverlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.1 Beispiel einer SDXL-Datei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.1 DataModel.cs: Ausschnitt der Methode zum Setzen eines neuen ProjectScheduling-

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

7.2 MainViewModel.cs: Ausschnitt der beiden Konstruktoren der Klasse . . . . . . . . . . 101

7.3 AppCommands.cs: Vollständiger Code zum AddRowCommand . . . . . . . . . . . . . . . . 103

7.4 AppCommands.cs: De�nition des CreateConstraintCommand und der zugehörigen Funk-

tionalität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

7.5 AppCommands.cs: Die AppCommands-Klasse agiert als listener der Events des Models . 106

7.6 MainSkin.xaml und MainPage.xaml: Der ViewModeLocator wird im resource dictiona-

ry als DataContext deklariert und für die Benutzerober�äche referenziert . . . . . . . 107

7.7 MainPage.xaml und MainSkin.xaml: Ein Button wird mit einem Command referenziert

und enthält eine Image-Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

7.8 Ein ILOG Chart Control wird in XAML verwendet . . . . . . . . . . . . . . . . . . . . 109

7.9 Viele unhandliche Bindingde�nitionen bei der Verwendung von ILOG Controls . . . . 109

7.10 MainPage.xaml: De�nition des den GanttChart des ViewModels beinhaltenden User-

Controls mit zugehörigen event-to-command -Bindings . . . . . . . . . . . . . . . . . . 110

7.11 MainPage.xaml: BusyIndicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.12 De�nition eines individuellen Aussehens für das Diagramm als Kindelement des Chart

Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.13 MainSkin.xaml: BarDefinition für ein als Meilenstein gesetztes SchedulingActivity-

Element des Diagrammes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7.14 MainPage.xaml.cs: Die Diagramme werden aus dem Content gelesen und für die View

referenziert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

7.15 MainPage.xaml.cs: Die De�nitionen werden aus dem resource dictionary gelesen und

an die Diagramme zugewiesen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.16 DataModel.cs: ReadTestFile() fordert vom Web Service eine Projektdatei an . . . . 117

7.17 DataModel.cs: _service_ReadTestFileCompleted() wird nach Abschluss des server-

seitigen Dienstes gestartet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

xxii

LISTINGS

7.18 DataModel.cs: Methode zum serverseitigen Speichern eines Gantt-Projekts . . . . . . 119

7.19 SilverlightGanttEditorTestPage.html: Das HTML-<object> referenziert die An-

wendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

A.1 WSDL-Datei des GanttWebService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

A.2 FileIO.cs: Funktion ReadProjectModel(XDocument xml) und Helfermethoden . . . vi

xxiii

Anhang C

Abkürzungen und Begri�e

API Application Programming Interface

ASP.NET Active Server Pages (for) .NET

CLR Common Language Runtime

CSS Cascading Style Sheets

DOM Document Object Model

DRM Digital Rights Management

GUI Graphical User Interface

HTML HyperText Markup Language

IDE Integrated Development Environment

JSON JavaScript Object Notation

MVC Model-View-Controller

MVP Model-View-Presenter

MVVM Model-View-ViewModel

PHP Hypertext Preprocessor

REST Representational State Transfer

RIA Rich Internet Applications

SDK Software Development Kit

SDXL Scheduling Data eXchange Language

SOA Service-oriented architecture

SOAP Simple Object Access Protocol

UDDI Universal Description, Discovery and Integration

xxiv

UML Uni�ed Modeling Language

URL Uniform Resource Locator

W3C World Wide Web Consortium

WCF Windows Communication Foundation

WPF Windows Presentation Foundation

WS Web Service

WSDL Web Service Description Language

XAML eXtensible Application Markup Language

XML eXtensible Markup Language

XML-RPC eXtensible Markup Language Remote Procedure Call

XSS Cross-Site-Scripting

xxv

Anhang D

CD-Inhalt

Die beiliegende CD enthält, neben dem vollständigen Quellcode der Implementierung, auch die

Bachelorarbeit als PDF-Datei. Auÿerdem sind die erstellten Diagramme als Gra�k beigelegt.

Alle in der Bachelorarbeit verwendeten Gra�ken sind zudem noch einmal aufgeführt. Die im

Literaturverzeichnis beschriebenen Internetquellen sind als PDF-Datei gespeichert.

Verzeichnis Bemerkung

/Bachelorarbeit Vollständige Bachelorarbeit als PDF-Datei.

/Gra�ken/Diagramme Diagramme als Gra�k.

/Gra�ken/Abbildungen Sonstige verwendete Abbildungen.

/Quellcode/SilverlightGanttEditor Die Silverlightanwendung des Praxisbeispiels.

/Quellcode/ SilverlightGanttEdi-

tor.Webhost

Web Service, Datenbank und Internetseite der

Anwendung.

/Quellcode/SilverlightControlLibrary Projektdateien der ControlLibrary-Bibliothek.

/Quellen Verwendete Internet- und Literaturquellen als

PDF-Datei (soweit vorhanden).

xxvi

Anhang E

Quellcode Übersicht

Im Folgenden wird eine kurze Übersicht über den Quellcode und die einzelnen Projekte der im-

plementierten Anwendung gegeben. Diese liegen im Quellcode-Verzeichnis auf der beigefügten

CD.

Der Ordner SilverlightGanttEditor.WebHost enthält die folgenden (serverseitigen) Verzeichnis-

se:


/App_Code Quellcode des GanttWebService, DataSet-Klassen zur Nutzung

der Datenbank.

/App_Data MS SQL-Datenbankdateien.

/Bin Von Visual Studio erzeugte Dateien.

/ClientBin Beinhaltet die kompilierte XAP-Datei.

/Resources Von der Test-Internetseite verwendete Gra�ken.

/ SDXL-Beispieldateien, clientaccesspolicy.xml, Test-Internetseiten

für die Anwendung und das dazugehörige von Visual Studio er-

zeugtes JavaScript zum Laden des Plugins.

Der Ordner SilverlightGanttEditor enthält die (clientseitigen) Quelldateien zum Silverlight-

Gantt-Editor:


/Bin Von Visual Studio erzeugte Dateien.

/Controls Erstellte UserControls.

/Diagrams Klassendiagramme.

/Model Die Quelldateien zur Model-Ebene.

/ViewModel Die Quelldateien zur ViewModel-Ebene.

xxvii


/Ressources Verwendete Gra�ken und Icons der Anwendung.

/ServiceReferences Referenzdateien für den GanttWebService.

/Skins Enthält das resource dictionary.

/ Die View-Ebene: MainPage.xaml, MainPage.xaml.cs, App.xaml

und App.xaml.cs

Zum Testen der Anwendung wurde der Silverlight-Gantt-Editor unter folgender Adresse be-

reitgestellt. Hierbei ist zu beachten, dass der zugehörige Web Service nicht Bestandteil der

Verö�entlichung ist, sodass nach Programmstart ein Fehler erscheint. Dieser weist darauf hin,

dass die Anwendung im O�ine-Modus ausgeführt wird, d.h. das Speichern bzw. Laden von

serverseitigen Daten (Benutzereinstellungen, Projektdateien) ist nicht möglich.

http://atlanta.informatik.uni-mainz.de/~congiua/BA/

Hinweis zu bekannten Problemen der Beispielanwendung

Die Implementierung der Anwendung basiert auf den deutschen Einstellungen zur

Kultur. .NET passt für verschiedene Kulturbereiche z.B. Datumsformatierung, Zei-

chensatz oder die Richtung der Schrift an. Da die SDXL-Dateien auf einem US-

amerikanischen Datumsformat beruhen und die Anwendung (i.d.R.) in einer deut-

schen Systemumgebung gestartet wird, kommt es zu leichten Verschiebungen der

Zeitdaten bei der Konvertierung in das jeweils andere Format. Zur Behebung dieses

Problems ist eine Einarbeitung in die Lokalisierungsmöglichkeiten von .NET nötig,

die im Rahmen der zur Verfügung stehenden Zeit, nicht ausreichend gegeben war.

Daneben sind einige Funktionen der Anwendung nicht vollständig ausimplementiert

worden, sodass der Silverlight-Gantt-Editor zum Teil einen prototypischen Charakter

aufweist. Der Fokus dieser Arbeit lag auf den Konzepten, theoretischen Grundlagen

und Möglichkeiten der Realisierung einer modernen Silverlightanwendung und nicht

auf einzelnen Funktionalitäten der spezi�schen Anwendung.

xxviii

Anhang F

CD

xxix

Konzeption und Realisierung von hoch-interaktiven Rich ... · Als Programmiersprache wird C#...

Documents

Transcript of Konzeption und Realisierung von hoch-interaktiven Rich ... · Als Programmiersprache wird C#...