Entwurf und Umsetzung einer webbasierten Diagnoseplattform zur Erhebung von deklarativem und prozeduralem Interaktionswissen

Transkript

1 Entwurf und Umsetzung einer webbasierten Diagnoseplattform zur Erhebung von deklarativem und prozeduralem Interaktionswissen Diplomarbeit zur Erlangung des akademischen Grades eines Diplom-Informatikers (Dipl.-Inf.) an der Humboldt Universität zu Berlin Mathematisch-Naturwissenschaftliche Fakultät II Institut für Informatik Vorgelegt von: Nico Zeißig Gutachter: Prof. Dr. Klaus Bothe Prof. Dr. Hartmut Wandke Betreuer: Dipl.-Psych. Michael Sengpiel Berlin, 09. Juni 2009

2 Danksagung Bei Herrn Prof. Dr. Klaus Bothe bedanke ich mich für die Vergabe und Betreuung der Diplomarbeit. Ebenso möchte ich mich bei Prof. Dr. Hartmut Wandke für die Betreuung der Arbeit, die Aufnahme in die ALISA Projektgruppe sowie die Möglichkeit zur Teilnahme an psychologischen Forschungskolloquien und internationalen Workshops bedanken. Besonderen Dank schulde ich Dipl.-Psych. Michael Sengpiel, der mich durch seine engagierte Betreuung und stete Diskussionsbereitschaft mit vielseitigen Denkanstößen bereicherte und bei der Erstellung dieser Arbeit unterstützte. Des Weiteren danke ich Dipl.-Ing. Joachim Warning für die technische Unterstützung im Produktivbetrieb der entwickelten webbasierten Diagnoseplattform. Dank gebührt auch allen anderen Mitarbeitern des psychologischen Lehrstuhls der Humboldt Universität zu Berlin für die zahlreichen Ratschläge und die angenehme Zusammenarbeit. Ich danke meiner Freundin Karoline Pannicke für ihre große Geduld und ihr Interesse beim Entstehen dieser Arbeit. Meinen Freunden Stef und Karsten danke ich für die Korrektur der Arbeit. Bei meinem Freund und Arbeitgeber Philipp von Criegern bedanke ich mich für die langjährige gute Zusammenarbeit sowie die Freistellung während der Erstellung der Diplomarbeit. Nicht zuletzt möchte ich meinen Eltern Renate Zeißig und Dr. Dieter Zeißig danken, die mir stets Vorbild waren und die diese Arbeit mit Anteilnahme verfolgt haben.

3 Inhaltsverzeichnis 1. Einleitung Motivation Ziel der Arbeit Aufbau der Arbeit Theoretische Vorbetrachtungen Wissen in der Mensch-Technik-Interaktion Deklaratives Wissen Prozedurales Wissen Interaktionswissen Mentale Modelle Computer Literacy Erfassung von Computer Literacy Cassel Computer Literacy Test (CMLRTC) Standardized Test of Computer Literacy (STCL) Computer Interface Literacy Measure (CILM) Inventar zur Computerbildung (INCOBI) Computer Literacy Scale (CLS) Prozessmodelle der Software-Entwicklung Sequentielle Modelle Das inkrementelle Modell Das evolutionäre Modell Das komponentenbasierte Modell Das Prototypenmodell Gewähltes Vorgehen Phasen der Software-Entwicklung Die Planungsphase Die Definitionsphase Die Entwurfsphase Kategorie und Netzverteilung Datenhaltung GUI - Grafische Benutzeroberfläche Wahl der Programmiersprache ICEfaces jboss Seam Apache POI Krysalis jcharts Die Implementierungsphase Mehrsprachigkeit Authentifizierung Persistente Datenhaltung Verwendete Werkzeuge Die Abnahme- und Einführungsphase Die Wartungs- und Pflegephase... 51

4 5. Anwendung der webbasierten Diagnoseplattform für die CLS mit interaktiven Szenarien (CLS-IA) Interaktionsformen Deskriptive Interaktionsformen Deiktische Interaktionsformen Hybride Interaktionsformen Interaktionselemente (Widgets) Select Checkbox Textbox Range Menüelement (MenuItem) Hybride Widgets Aggregation von Interaktionsaufgaben in Szenarien Szenario 1 - Selektion von Objekten und Objektmengen Szenario 2 - Kopieren, Einfügen, Löschen Szenario 3 - Eine Flugbuchung Szenario 4 - Farbeneinkauf Entwurf und Implementierung der Szenarien Allgemeines Vorgehen Exkurs - jquery Kommunikation mit der Diagnoseplattform Notwendige Modelländerungen Neuer Loginprozess Verwendete Werkzeuge Testdurchläufe und empirische Phase Diskussion und Ausblick Bewertung des Vorgehens und der verwendeten Modelle Erweiterungsmöglichkeiten Weitere Interaktionsformen und erweiterte Hardware Neue Zielplattformen Grafischer Fragebogendesigner /-administrator Fazit 88 Literaturverzeichnis 89 Abbildungsnachweis 93 Tabellen 96 Listings 97 Glossar 98 Screenshots 100 Artefakte 103 Selbständigkeitserklärung 124 Einverständniserklärung 124

5 Einleitung Motivation 5 1 Einleitung Diese Arbeit ist eingebettet in das Projekt ALISA 1, welches derzeit am psychologischen Lehrstuhl der Humboldt-Universität zu Berlin durchgeführt wird. Ziel dieses von der DFG geförderten Projekts ist es zu ermitteln, durch welche Gestaltungs- und Trainingsmethoden vor allem älteren Benutzern geholfen werden kann, technische Systeme besser zu verstehen, zu nutzen und mit ihnen zu interagieren (Struve, D., Sengpiel, M. und Wandke, H., 2006). Die durchgeführte Diplomarbeit beschreibt, wie in enger Zusammenarbeit mit der ALISA Projektgruppe das Softwareprojekt webbasierte Diagnoseplattform in mehreren Phasen umgesetzt wurde. Die Arbeit dokumentiert die Entstehung eines Softwareprodukts im Rahmen einer Software-Entwicklung. Die Phasen, in denen eine solche Entwicklung abläuft, werden vorgestellt und an beispielhaften Ausschnitten des Softwareprodukts hinterlegt. Dabei werden die Modellierung des Projekts, die Auswahl geeigneter Technologien und Hilfsmittel, die Implementierung sowie das Testen beschrieben. Darüber hinaus wird im Detail erörtert, wie die Erfassung prozeduralen Wissens realisiert wurde und wie sich die erhobenen Daten in der webbasierten Diagnoseplattform speichern und zur weiteren Verarbeitung exportieren lassen. 1.1 Motivation Eine Annahme besagt, dass Menschen mit einer hohen Computer Literacy (CL) der Umgang mit beliebigen Automaten leichter fällt. Darüber hinaus gestaltet sich das Erlernen bzw. der Umstieg auf neue Umgebungen für diese Gruppe leichter. Um die Computer Literacy eines Probanden zu ermitteln, bedarf es adäquater Methoden, das deklarative sowie das prozedurale Computerwissen zu erfassen. Es gibt viele Tests, die vorgeben, die Computer Literacy zu ermitteln. Beispielsweise wurde im Jahre 1999 an der Universität zu Köln das Inventar zur Computerbildung INCOBI (Richter, T., Naumann, J. & Groeben, N., 2001) entwickelt, welches sechs verschiedene Fragebögen zu Aspekten der Computer Literacy vereint. Im selben Jahr wurde zudem die Äquivalenz von Online- und Paper-Pencil-Erhebungen bestätigt (vgl. Richter, T., Naumann, J. & Noller, S., 1999). Auch im Rahmen des ALISA Projekts wurde in vorgelagerten Diplomarbeiten ein neues Instrument zur Erhebung der Computer Literacy entworfen. Diana Dittberner und Michael Sengpiel gestalteten die Computer Literacy Scale (CLS), welche in Kapitel genauer vorgestellt wird. Eine online Umsetzung der CLS wurde in einer vorangegangenen Studienarbeit (Zeißig, 2008) realisiert. Allen bisher erschienenen Umfragen und Tests ist gemein, dass prozedurales Wissen (vgl. Kapitel 2.1.2) ausschließlich in Form von konstruierten Szenarien mit vorgegebenen Antwortmöglichkeiten abgefragt wird. 1 Akronym: Adaptive Lernunterstützung zur Interaktiven Systemnutzung Älterer

6 Einleitung Ziel der Arbeit Ziel der Arbeit Im Rahmen dieser interdisziplinären Arbeit soll eine webbasierte Diagnoseplattform (WDP) entworfen und implementiert werden, welche es Versuchsleitern (VL) ermöglicht, generische Umfragen und Tests durchzuführen und zu verwalten. Es handelt sich hierbei um eine Weiterentwicklung der in der Studienarbeit (Zeißig, 2008) programmierten Umfrage. Ziel ist es, als ersten Anwendungsfall der WDP, die CLS um einen interaktiven Teil zur Erhebung prozeduralen Interaktionswissens zu erweitern. Neuartig in dieser Arbeit ist das Abprüfen des prozeduralen Wissens einer Versuchsperson (VP) im Umgang mit einem System mittels interaktiver Arbeitsproben. Ein solches System wird durch fiktive zusammengesetzte Szenarien simuliert. Die Beschreibung, wie solche Arbeitsproben realisiert werden, findet ab Kapitel 5.3 statt. Diese Neuerung macht es möglich, das implizit vorgehaltene prozedurale Interaktionswissen zu ermitteln und somit Aussagen von Versuchspersonen wie: Ich weiß zwar nicht wie es heißt, ich kann es aber bedienen. zu überprüfen. Des Weiteren wird gezeigt, durch welche Technologien die Erfassung prozeduralen Wissens in einem Onlinetest möglich ist. Durch die Umsetzung als datenbankgestützte Webanwendung ergeben sich viele positive Nebeneffekte. So ist es beispielsweise möglich, kostengünstig und mit relativ geringem Aufwand eine hinreichend große Stichprobe zu erheben. Gleichzeitig können Daten, wie die benötigte Zeit sowie die Reihenfolge der Beantwortung, transparent erfasst werden. 1.3 Aufbau der Arbeit Im Rahmen dieser fachübergreifenden Arbeit wurde sowohl nach informationstechnischen Gesichtspunkten ein Softwareprojekt umgesetzt, als auch methodisch unter psychologischen Maßgaben ein Onlinetestverfahren für prozedurales Interaktionswissen entwickelt. Vertreter beider Teildisziplinen sollen die Möglichkeit haben, den theoretischen Vorüberlegungen sowie den konkreten technischen Umsetzungen folgen zu können. Zu diesem Zweck werden in Kapitel 2 die wichtigsten theoretischen Grundlagen gelegt. Bevor mit der Entwicklung einer Softwareanwendung begonnen werden kann, ist es zwingend notwendig, eine geeignete Vorgehensweise festzulegen. Prozessmodelle beschreiben eine solche Vorgehensweise. In Kapitel 3 werden einige der wichtigsten Vorgehensmodelle beschrieben und anschließend das eigene Vorgehen begründet. Die Entwicklung des Softwareprodukts webbasierte Diagnoseplattform gliedert sich in mehrere Ausbaustufen. In Ausbaustufe eins, der Basisversion, wurde ein generisches Java EE 2 Backend für die Ablage und Durchführung von Onlineumfragen und -tests geschaffen (vgl. Zeißig, 2008). Diese Entwicklung wird im Rahmen der Phasen einer 2 Java Enterprise Edition (ehemals J2EE)

7 Einleitung Aufbau der Arbeit 7 Software-Entwicklung in Kapitel 4 noch einmal aufgegriffen. Alle Phasen und die damit verbundenen Aktivitäten sowie die beteiligten Akteure werden theoretisch beschrieben und praktisch an Beispielen hinterlegt. In Kapitel 5 erfolgt die Beschreibung der Weiterentwicklung des Softwareprodukts zur Erhebung von prozeduralem Interaktionswissen. Im Speziellen wird ein Überblick über vorhandene Interaktionsformen und Widgets 3 gegeben und anschließend gezeigt, wie diese in Arbeitsproben (Szenarien) arrangiert wurden. Im Kapitel 6, dem Diskussions- und Ausblickteil, werden das gewählte Vorgehen, die getroffenen Entscheidungen sowie die verwendeten Modelle bewertet. Des Weiteren werden Möglichkeiten aufgezeigt, die webbasierte Diagnoseplattform aus psychologischer und technischer Sicht zu erweitern. 3 Interaktionselemente zur Ein- und Ausgabe von Informationen

8 Theoretische Vorbetrachtungen Wissen in der Mensch-Technik-Interaktion 8 2 Theoretische Vorbetrachtungen Da es sich um eine interdisziplinäre Arbeit handelt, sollen im Folgenden Begriffe und Definitionen eingeführt werden, die zum Verständnis dieser Arbeit notwendig sind. Primär geht es darum, den Vertretern der Informatik sowie Fachfremden die psychologischen Grundlagen zu vermitteln. Speziell im Bereich der Softwaretechnik und den damit verbundenen Technologien folgen zusätzliche Ausführungen in den entsprechenden Kapiteln dieser Arbeit. Einführend werden verschiedene Arten von Wissen vorgestellt. Anschließend wird ein zweiter wichtiger Aspekt beschrieben, die Repräsentation von Wissen in Form von Modellen. Abschließend werden der Begriff Computer Literacy im Rahmen dieser Arbeit definiert sowie bereits vorhandene Erhebungsmethoden vorgestellt. 2.1 Wissen in der Mensch-Technik-Interaktion Für beide Teildisziplinen dieser Arbeit ist es von Vorteil, über die Beschaffenheit von Wissen im Umfeld der Mensch-Technik-Interaktion (MTI) zu reflektieren. Grundsätzlich kann per Definition Wissen in zwei Kategorien klassifiziert werden: In explizites und implizites Wissen (Polanyi, 1966). Explizites Wissen lässt sich formal beschreiben und ist dem Subjekt, welches es besitzt, bewusst. Die dem Wissen zugrundeliegenden Informationen können in beliebiger Form, wie Datenbanken, Büchern oder Textdokumenten, vorgehalten werden. Nicht formal artikulieren lässt sich hingegen implizites Wissen. Dieses ist geprägt durch persönliche Wertvorstellungen und beruht auf Überzeugungen, Erinnerungen und vor allem auf Erfahrungen. Nach Anderson (1976) kann in der Psychologie in Anlehnung an Klassifikationen, welche ihren Ursprung in der Gedächtnisforschung haben, Wissen ebenfalls in verschiedene Typen untergliedert werden. Dies geschieht anhand ihrer zeitlichen Klassifikation in verschiedenen Gedächtnissystemen: Sensorisches, Kurzzeit- bzw. Arbeits- sowie Langzeitgedächtnis. Innerhalb des Langzeitwissens, welches im Langzeitgedächtnis vorgehalten wird, lässt sich zwischen deklarativem und prozeduralem Wissen differenzieren. Die webbasierte Diagnoseplattform hat zum Ziel, sowohl das deklarative als auch das prozedurale Interaktionswissen zu erfassen. Zu diesem Zweck werden diese Wissensarten in den folgenden Abschnitten genauer erörtert Deklaratives Wissen Unter deklarativem Wissen wird statisches Wissen quasi eine Art Faktenwissen verstanden. Es handelt sich um mitteilbares Wissen, welches die Kenntnisse eines Menschen über die Realität, Personen, Sachverhalte, Ereignisse, Prozesse und Handlungen umfasst. Nach Schacter, Wagner & Buckner (2000) lässt sich das deklarative Wissen

9 Theoretische Vorbetrachtungen Mentale Modelle 9 weiterhin in episodisches und semantisches Wissen untergliedern. Ersteres umfasst Wissen über Ereignisse; zum Beispiel die Erinnerung eines Computerbenutzers daran, dass er vor einer Woche eine bereits in den Papierkorb verschobene Datei wieder herstellte. Semantisches Wissen hingegen umfasst abstraktes, begriffliches Wissen über die Realität. Ein Beispiel in der MTI ist das Wissen über den Aufbau und die Funktionsweise eines Computers Prozedurales Wissen Beim prozeduralen Wissen handelt es sich im Gegensatz zum vorher beschriebenen Faktenwissen um dynamisches Wissen. Es umfasst Wissen, wie mit einer bestimmten Prozedur beziehungsweise einem bestimmten Verarbeitungsprozess ein gewünschtes Ergebnis erreicht werden kann. Es bezieht sich auf Handlungsabläufe und ist oftmals sprachlich nicht formulierbar. Prozedurales Wissen umfasst Wissensbestände, die vor allem auf assoziativem Lernen basieren. Ein Beispiel für prozedurales Wissen im Umfeld der MTI ist Wissen in Form von gespeicherten Routinen oder Prozessen für den Umgang mit einem fensterbasierten Betriebssystem. Dies umfasst beispielsweise, das Anlegen, Löschen und Verschieben von Ordnern und Dateien, das Abspielen eines Videos, das Starten einer Anwendung oder das Herunterfahren des Computers. Das Wissen wird im Umgang mit dem System erworben. Durch Analogien und Metaphern, wie zum Beispiel dem Papierkorb, kann der Lernprozess unterstützt werden Interaktionswissen Alle Aktionen, die beim Umgang mit einer Anwendung durch einen Nutzer immer wieder in gleicher oder ähnlicher Form auftreten, werden als Interaktionsaufgaben bezeichnet (vgl. Preim, 1999). Interaktionsaufgaben geben an, was der Nutzer tun kann. Solche Aufgaben können auf verschiedene Art und Weise erledigt werden. Die unterschiedlichen Wege zum Erreichen des Ziels werden als Interaktionsform bzw. Interaktionstechnik bezeichnet. Allgemein drücken diese aus, wie der Benutzer etwas tun kann. Das Wissen über entsprechende Interaktionstechniken wird als Interaktionswissen bezeichnet. 2.2 Mentale Modelle Mentale Modelle sind Repräsentationen realer, hypothetischer oder imaginärer Situationen, welche Menschen nutzen, um bestimmte Phänomene zu verstehen. Kenneth Craik (1943) schreibt, dass gedanklich small-scale models der Realität gebildet und anschließend zum Schlussfolgern sowie zum Antizipieren von Geschehnissen genutzt werden. Norman und Donald (1983) beschreiben diese mentalen Modelle folgendermaßen: In interacting with the environment, with others, and with the artifacts of

10 Theoretische Vorbetrachtungen Mentale Modelle 10 technology, people form internal, mental models of themselves and of the things with which they are interacting. These models provide predictive and explanatory power for understanding the interaction. (Norman, Donald A. in Gentner & Stevens, 1983, S. 7). In Mental Models schlägt Johnson-Laird (1983) mentale Modelle als die Basis der Kognition vor: It is now plausible to suppose that mental models play a central and unifying role in representing objects, states of affairs, sequences of events, the way the world is, and the social and psychological actions of daily life. (Johnson-Laird, 1983, S. 397). Holland, Holyoak, Nisbett und Thagard (1986) deuten darauf hin, dass mentale Modelle die Basis für alle Prozesse des logischen Denkens bilden: Models are best understood as assemblages of synchronic and diachronic rules organized into default hierarchies and clustered into categories. The rules comprising the model act in accord with the principle of limited parallelism, both competing and supporting one another. (Holland et al., 1986, S. 343). In der gesichteten Literatur findet sich keine eindeutige Definition für mentale Modelle. Daher seien hier einige Charakteristika mentaler Modelle genannt, in denen sich die gefundenen Definitionen decken: Mentale Modelle sind unvollständig und entwickeln sich kontinuierlich weiter. Es handelt sich in der Regel nicht um eine präzise Darstellung von Phänomen, stattdessen enthalten mentale Modelle typischerweise Fehler und Widersprüche. Mentale Modelle sind sparsam und bieten vereinfachte Erläuterungen komplexer Phänomene. Häufig enthalten mentale Modelle Informationen über den Grad der Ungewissheit, weswegen sie selbst zum Einsatz kommen können, wenn sie falsch sind. Die Repräsentation von mentalen Modellen kann in Form von Wenn-Dann - Regeln geschehen. Das Verhalten von Computersystemen sollte sich stets mit dem mentalen Modell des Nutzers decken. Eine Übereinstimmung kann durch Anpassungen auf beiden Seiten erreicht werden, wie Abbildung 1 zeigt. Ein System kann bereits so gestaltet werden, dass es sich möglichst gut mit dem mentalen Modell des Nutzers deckt. Anderenfalls durchläuft der Nutzer einen Lernprozess und passt sein mentales Modell an das Verhalten des Systems an. Zusätzlich sollte die Technik den Nutzer beim Lernen unterstützen. Mensch lernen gestalten Technik Abbildung 1: Bezug mentaler Modelle zur Usability von technischen Systemen (Sengpiel & Wandke, 2009)

11 Theoretische Vorbetrachtungen Computer Literacy Computer Literacy Der Begriff Computer Literacy ist in der Literatur sehr weit verbreitet. Dennoch gibt es keine einheitliche, präzise Definition. Dazu kommt, dass sich die Auslegung des Begriffes aufgrund der schnellen Computerentwicklung über die letzten drei Jahrzehnte verändert hat. In dieser Arbeit wird als Grundlage folgender Definitionsansatz von Richter, Naumann und Groeben (2001, S. 1) verwendet: Unter Computer Literacy wird hier das umgangsrelevante deklarative und prozedurale Computerwissen sowie die subjektiv wahrgenommene Sicherheit im Umgang mit dem Computer (als positivem Gegenpol zu Computerängstlichkeit) verstanden. Nach Turner, Sweany und Husman (2000) können sechs Level der Computer Literacy unterschieden werden: Bewusstheit (engl. awareness) der Geschichte, Trends und Fähigkeiten von Computern Fertigkeit der Benutzung von Eingabegeräten wie Maus und Tastatur Fertigkeit passive Anwendungen wie Spiele zu bedienen Fertigkeit der Bedienung wertschöpfender Anwendungen wie Textverarbeitung und Tabellenkalkulation Qualifikation im Umgang mit Betriebssystemen, z.b. Softwareinstallationen Programmiererfahrung sowie Erfahrung im Umgang mit dem Einbau von Computerhardware und deren Reparatur Winter, Chudoba und Gutek (1997) untergliedern weiterhin nach funktionaler und allgemeiner Computer Literacy. Funktionale CL beinhaltet das Wissen über konkrete Fakten sowie abstrakte Konzepte: Functional literacy is considered to be the ability to read and write well enough to function in society (e.g. read a newspaper or write a note to one s supervisor) (Winter et al., 1997, S. 2). In Abgrenzung dazu beschreibt die allgemeine Computer Literacy eine wesentlich höhere Ebene von Fertigkeiten auf dieselbe Analogie bezogen etwa das Schreiben kritischer Abhandlungen. Funktionale Computer Literacy umfasst das Grundwissen, welches für die meisten Büroangestellten in deren täglicher Arbeitsumgebung notwendig ist. Nach Winter et al. (1997) bilden Anwender mentale Modelle (vgl. Kapitel 2.2) des Verständnisses davon, wie das System, mit dem sie arbeiten, funktioniert: Research in systems has found that users form mental models (often analogies) of their understanding of how their systems work. (Winter et al., 1997, S. 2). Weitere Untersuchungen haben gezeigt, dass ein ausführlicheres und korrekteres Modell durchgängig zu besserer Effektivität und Effizienz führt.

12 Theoretische Vorbetrachtungen Erfassung von Computer Literacy 12 Um beispielsweise bei der Personalauswahl Entscheidungen zu treffen, ist es notwendig Computer Literacy bestmöglich zu messen. Darüber hinaus ist die Erfassung der CL in der Projektgruppe ALISA erforderlich, um Trainings sowie das Neudesign von Automaten optimal zu unterstützen. Vor allem bei onlinebasierten Lernangeboten stellt sich das diagnostische Problem, diejenigen Teilnehmer zu ermitteln, deren Computer Literacy nicht hinreichend ausgebildet ist. 2.4 Erfassung von Computer Literacy Wie im vorhergehenden Abschnitt beschrieben, ist es wichtig, ein geeignetes und vor allem aussagekräftiges Maß für Computer Literacy zu haben. In diesem Abschnitt wird aufgezeigt, welche häufig in der Literatur zu findenden Methoden es bereits zur Erfassung von Computer Literacy gibt Cassel Computer Literacy Test (CMLRTC) Bei diesem Test von Cassel & Cassel aus dem Jahre 1984 handelt es sich um eine frühe und ausführliche Erfassungsmethode allgemeiner CL. Der Test besteht aus 120 Multiple Choice Aufgaben, welche über sechs Kategorien verteilt sind. Diese sind: Computerentwicklung (engl. computer development) technisches Verständnis (engl. technical understanding) Computeraufbau (engl. computer structure) Informationsverarbeitung (engl. information processing) Informationssuche (engl. information retrieval) Kommunikationssysteme (engl. communication systems) Es wird versucht, das Verständnis der Versuchsperson über die Funktionsweise eines Computers zu erfassen. Miller, Stanney und Wooten (1997) kritisieren jedoch, dass keine Daten zur Validität und Reliabilität 4 vorhanden sind. Weiterhin sind keine Werte bekannt, wie lange eine Teilnahme am Test dauert. Miller et al. (1997) schätzen, dass das vollständige Beantworten etwa dreißig Minuten dauert Standardized Test of Computer Literacy (STCL) Dieser Test wurde im Jahre 1984 von Montag, Simonson und Maurer entwickelt. Ähnlich wie beim Cassel Computer Literacy Test werden in 80 Multiple Choice Aufgaben drei Themengebiete zur allgemeinen Computer Literacy abgedeckt. Diese sind: Computeranwendungen (engl. computer applications) Computersysteme (engl. computer systems) 4 Gütekriterium eines Tests oder Fragebogens, welches angibt, wie zuverlässig dieser ein bestimmtes Merkmal misst. Es gibt vier verschiedene Methoden die Reliabilität empirisch abzuschätzen: Testwiederholung, Parallelitätstests, Testhalbierung und interne Konsistenzbestimmung.

13 Theoretische Vorbetrachtungen Erfassung von Computer Literacy 13 Computerprogrammierung (engl. computer programming) Die Beantwortung jeder Kategorie dauert in etwa dreißig Minuten. Die angegebene Reliabilität (Cronbach α) liegt bei α = Der STCL sowie der CMLRTC möchten die Literacy einer Versuchsperson messen. Beide Tests beziehen sich allerdings ausschließlich auf technische Aspekte. Wie die verwendete Definition von Computer Literacy (vgl. Kapitel 2.3) jedoch zeigt, setzt sich diese aus wesentlich mehr Komponenten zusammen. Diese Diskrepanz ergibt sich daraus, dass die Nutzung von Computern in den 1980er-Jahren noch relativ wenigen Personen vorbehalten war. Erst im Laufe der 80er-Jahre fanden Heimcomputer Einzug in viele Haushalte. Diese wurden allerdings vorerst hauptsächlich für Unterhaltungszwecke verwendet. Die deutlich teureren Personal-Computer (PC) blieben nur professionellen Anwendern und somit einem eingeschränkten Nutzerkreis vorbehalten. Heutzutage ist beinahe jeder Büroschreibtisch mit einem PC und einem fensterbasiertem Betriebssystem ausgestattet. Daher ist es notwendig, Erhebungsmethoden zu finden, welche die funktionale Computer Literacy stärker einbeziehen Computer Interface Literacy Measure (CILM) Turner et al. (2000) haben eine neue Messskala entwickelt, um den im vorherigen Abschnitt beschriebenen Problemen entgegen zu wirken: The definitions and scales that do exist are specific to the prevailing technology at the time of their development. (Turner et al., 2000, S. 37). Ziel des CILM ist es, auch Fertigkeiten, wie den Umgang mit GUI (graphical user interface) basierten Betriebssystemen, hypermedialen 5 Anwendungen und dem Internet zu erfassen. Der CILM setzt sich aus zwei Subskalen zusammen, der CILM-SR 6 mit 26 Items und der CILM-KA 7 mit 42 Items. Die Reliabilität liegt nach Turner et al. (2000) bei α = Der Test wurde an 498 Studenten im Grundstudium validiert. In Listing 1 sind fünf der 26 CILM-SR Items aufgeführt. Jedes Item ist mit einem Wert 1 (trifft überhaupt nicht auf mich zu) bis 5 (trifft genau auf mich zu) zu bewerten I feel confident opening an application on a Macintosh based computer. 2. I copy files to a 3.5 (floppy) disk on a regular basis using Windows based computer. 3. I do not feel confident moving files from one folder to another using a Macintosh computer. 4. I have never copied files to a floppy disk on a Macintosh based computer. 5. I have never used a Macintosh based computer. Listing 1: Auszug CILM-SR (Turner et al., 2000) 5 Zusammengesetztes Wort aus Hypertext und Multimedia 6 SR steht für self report und basiert auf einer Selbsteinschätzung 7 KA steht für knowledge application und beschreibt die Anwendung des Wissens

14 Theoretische Vorbetrachtungen Erfassung von Computer Literacy 14 Das Listing 2 zeigt drei der 42 CILM-KA Items, welche jeweils mit Wahr oder Falsch zu beantworten sind One way to run an application in Windows 95 is to select the programm from the APPLICATIONS menu. (True or False) 2. Hypermedia programs can contain pictures, video clips, and/or audio clips in addition to text. (True or False) 3. It is possible to get a computer virus from simply reading a text-based message (True or False) Listing 2: Auszug CILM-KA (Turner et al., 2000) Inventar zur Computerbildung (INCOBI) Das von Richter, Naumann und Groeben (1999) entwickelte Inventar zur Computerbildung beinhaltet folgende vier Skalen: 1. Einen Fragebogen, der sich auf die Sicherheit im Umgang mit Computern und Computeranwendungen bezieht (SUCA). Der Fragebogen besteht aus 12 Aussagen und bittet die Versuchsperson, eine Einschätzung darüber zu treffen, inwieweit diese für sie zutreffend sind. Ein Beispiel einer solchen Aussage ist in Abbildung 2 zu sehen. Abbildung 2: Beispiel Inventar zur Computerbildung - SUCA 2. Einen Fragebogen zur Vertrautheit mit verschiedenen Computeranwendungen (VECA). Dieser Fragebogen listet 12 Computeranwendungen auf und bittet die Versuchsperson um eine Selbsteinschätzung bzgl. der Vertrautheit im Umgang mit diesen. Ein Beispiel hierzu zeigt Abbildung 3. Abbildung 3: Beispiel Inventar zur Computerbildung - VECA

15 Theoretische Vorbetrachtungen Erfassung von Computer Literacy Einen Fragebogen zu theoretischem Computerwissen (TECOWI), welcher 13 Begriffe oder Abkürzungen im Computerumfeld abfragt. Ein Beispielbegriff ist in Abbildung 4 zu sehen. Abbildung 4: Beispiel Inventar zur Computerbildung - TECOWI 4. Einen Fragebogen zu praktischem Computerwissen (PRACOWI), welcher 13 Problemsituationen beschreibt, wie sie im täglichen Arbeitsleben auftreten können. Die Versuchsperson kann den für sie am besten geeigneten Lösungsvorschlag auswählen. Abbildung 5 zeigt eine solche Problemsituation. Abbildung 5: Beispiel Inventar der Computerbildung - PRACOWI Zusätzlich beinhaltet INCOBI acht Skalen eines Fragebogens zur inhaltlich differenzierten Erfassung von computerbezogenen Einstellungen (abgekürzt FIDEC). Ein Beispiel zeigt Abbildung 6. Abbildung 6: Beispiel Inventar der Computerbildung - FIDEC INCOBI ist als Paper-Pencil Version sowie als Onlineversion verfügbar und ermöglicht die Erfassung deklarativen und prozeduralen Computerwissens, Computerängstlichkeit sowie die Vertrautheit mit Computeranwendungen.

16 Theoretische Vorbetrachtungen Erfassung von Computer Literacy Computer Literacy Scale (CLS) Die Computer Literacy Scale wurde von Michael Sengpiel und Diana Dittberner speziell für die Erhebung der Computer Literacy älterer Versuchspersonen mit geringem Vorwissen entworfen. Wie bereits in den vorangehenden Kapiteln beschrieben, stellen auch die beiden Psychologen der Humboldt Universität zu Berlin fest, dass ein Mangel an adäquaten Erfassungsmethoden für Computer Literacy besteht: Even though there are a variety of computer literacy and related measures available (Beckers & Schmidt, 2003; Bozionelos, 2001; Garland & Noyes, 2004; Potosky & Bobko, 1998; Schumacher & Morahan-Martin, 2001; Smith et al., 2000; Smith et al., 2007; Turner et al., 2000; Wagener, 2003; Winter et al., 1997; Miller et al., 1997; Pyrczak, 1990; Potosky, 2007), none of them is short, objective and age specific for older adults, which led to the development of the CLS. (Sengpiel, M. & Dittberner, D., 2008, S. 1). Nach Sengpiel und Dittberner (2008) fokussiert die CLS auf einen kleinen aber sehr wichtigen Aspekt der Computer Literacy, der für den Umgang mit Computern zwingend notwendig ist. Primär wird das Verständnis von gebräuchlichen Symbolen und Begriffen, wie sie in gängigen Mensch-Maschine-Schnittstellen vorkommen, überprüft. Die CLS besteht aus zwei Teilen. Teil A (CLS-Exp), welcher in Abbildung 7 zu sehen ist, erfasst in 15 Items die bisherige Erfahrung mit Computern. Diese Items wurden zu großen Teilen aus bereits vorhandenen Fragebögen, wie INCOBI (vgl. Kapitel 2.4.4), ausgewählt. Die entsprechende Umsetzung in der Onlineversion zeigt Abbildung 68 im Anhang. Abbildung 7: Teil A (CLS-Exp) der Computer Literacy Scale Teil B (CLS-ST) bewertet die Computer Literacy im Sinne des Verständnisses von Symbolen und Begriffen aus dem Computerumfeld sowie anderer technischer Geräte.

17 Theoretische Vorbetrachtungen Erfassung von Computer Literacy 17 Insgesamt beinhaltet dieser Teil 26 Items sowie vier Distraktoren. Die Versuchspersonen werden gebeten, den dargebotenen Symbolen und Begriffen deren jeweilige Bedeutung zuzuordnen. Den Aufbau des CLS-ST zeigt Abbildung 8, die entsprechende Onlineumsetzung illustriert Abbildung 69 im Anhang. Die in Teil B erreichte Punktzahl, wird als CLS-Score bezeichnet. Abbildung 8: Teil B (CLS-ST) der Computer Literacy Scale Für das Ausfüllen des Tests werden etwa 10 bis 20 Minuten benötigt. In einer ersten Erhebung mit der CLS wurden 120 Erwachsene im Alter von 21 bis 75 Jahren befragt. Die Teilnehmer wurden einer jungen und einer alten Versuchsgruppe zugeordnet. Die Güte der CLS-ST wurde mit einer internen Konsistenz (Cronbach alpha) von α=0.96, mit einer Trennschärfe der Items zwischen r=0.22 und r=0.84 sowie einer Itemschwierigkeit von P=0.13 bis P=0.87 bewertet. Die starken Variationen in Trennschärfe und Itemschwierigkeit ergeben sich durch die Altersunterschiede der Versuchspersonen. Die CLS befindet sich in einer kontinuierlichen Weiterentwicklung, um zum einen die Erkenntnisse bisheriger Erhebungen einzubringen und zum anderen die Zielgruppe auf alle Alters- und Vorkenntnisklassen zu erweitern. Um dieses evolutionäre Vorgehen zu unterstützen, wurde die CLS online verfügbar gemacht. Dadurch ist es möglich, schnell und kostengünstig Umfragen zu erheben (vgl. Zeißig, 2008). Zusätzlich wird die CLS um einen interaktiven Teil (CLS-IA) erweitert. Die technischen Grundlagen sowie eine erste Implementation sind Bestandteil dieser Arbeit.

18 Prozessmodelle der Software-Entwicklung Sequentielle Modelle 18 3 Prozessmodelle der Software-Entwicklung Elementarer Bestandteil dieser Arbeit ist die Planung, Entwicklung und Einführung einer webbasierten Diagnoseplattform. Mit diesem Softwareprodukt soll aktiv am Institut für Psychologie der Humboldt Universität zu Berlin geforscht werden. Die damit erhobenen Daten werden unmittelbar für weitere Forschungen im Rahmen des ALISA Projekts benötigt. Daher ist es unabdingbar, dass sich während aller Phasen der Software-Entwicklung an etablierten Vorgehensweisen (Best Practice) orientiert wird. Nach Balzert (2000) soll jede Software-Entwicklung in einem organisatorischen Rahmen erfolgen. Einen solchen Rahmen beschreiben Prozess- oder auch Vorgehensmodelle. Einige der bekanntesten klassischen Basismodelle werden in den folgenden Kapiteln vorgestellt, ihre Stärken und Schwächen erörtert sowie die Wahl des eigenen Vorgehens begründet. 3.1 Sequentielle Modelle Die einfachsten Prozessmodelle gliedern die Entwicklung eines Softwareprojekts in Phasen, welche nacheinander ausgeführt werden. Dabei beginnt jede neue Phase erst, sobald die vorangegangene vollständig abgeschlossen ist. Der bekannteste und am weitesten verbreitete Vertreter dieser Klasse ist das Wasserfall-Modell (vgl. Royce, 1970). Eine schematische Abbildung des um Rückkopplungsschleifen (engl. feedback) erweiterten Modells ist in Abbildung 9 zu sehen. Abbildung 9: Schematische Darstellung des Wasserfall-Modells (nach Royce, 1970) Obwohl es sich um ein leicht verständliches Modell mit relativ geringem Managementaufwand handelt, gibt es einige Faktoren, die gegen die Verwendung in dieser Arbeit sprechen. Eines der größten Probleme besteht darin, dass der Auftraggeber in der

19 Prozessmodelle der Software-Entwicklung Das inkrementelle Modell 19 Lage sein muss, alle Vorgaben an das Produkt im Vorfeld vollständig und endgültig anzugeben. Andere Nachteile wie die Entwicklungszeit, welche sich aus der Summe aller Einzelphasen ergibt, können aufgrund der Größe des Entwicklungsteams vernachlässigt werden. Neben den sequentiellen Modellen gibt es nebenläufige Modelle, welche versuchen, die gesamte Entwicklungszeit zu verkürzen, indem sie die einzelnen Phasen teilweise parallelisieren. Aufgrund der bereits erwähnten Größe des Entwicklungsteams wird hier auf weitere Ausführungen verzichtet. Beiden Modellarten ist gemein, dass von vornherein versucht wird, ein vollständiges Produkt auszuliefern. Dies impliziert, dass spätestens in der Definitionsphase (vgl. Kapitel 4.2) alle Anforderungen des Auftraggebers ermittelt werden. Da diese oftmals in den frühen Phase der Software-Entwicklung noch nicht bekannt sind oder nicht explizit formuliert werden können, bietet sich die alleinige Verwendung dieses Modells nicht an. 3.2 Das inkrementelle Modell Modelle der im Kapitel 3.1 beschrieben Klasse haben das Problem, dass alle Produktanforderungen in vollständiger Form bereits in sehr frühen Phasen der Software- Entwicklung bekannt und formuliert sein müssen. Dies ist nicht immer möglich und darüber hinaus ist es nicht selten, dass sich einige Wünsche erst während des konkreten Einsatzes des Produkts ergeben. Der inkrementelle Ansatz geht davon aus, dass sich Softwareprodukte auf zwei Arten auseinander nehmen und assemblieren lassen. Balzert (2008, S. 526) beschreibt und bebildert diese beiden Möglichkeiten wie folgt: Aufbau aus Teilprodukten, die analog wie Legobausteine oder Puzzleteile schrittweise ein Gesamtprodukt ergeben (Abbildung 10 links) Schalenförmiger Aufbau, bei dem analog zu Zwiebelschalen um einen Kern herum schalenförmig neue Funktionalitäten hingefügt werden, bis das Gesamtprodukt fertiggestellt ist (Abbildung 10 rechts) Abbildung 10: Ausbaustufen eines Softwareprodukts (Balzert, 2008)

20 Prozessmodelle der Software-Entwicklung Das inkrementelle Modell 20 Bevor festgestellt wird, wie sich das Softwareprodukt in Teilprodukte oder Schalen zerlegen lässt, werden die Anforderungen an das Endprodukt möglichst vollständig erfasst. Spätestens in der Definitionsphase (vgl. Kapitel 4.2) muss feststehen, welche Art der Zergliederung sich anbietet. Durch die weitgehend vollständige Sammlung der Anforderungen und deren anschießende Modellierung wird garantiert, dass zu späteren Zeitpunkten entwickelte Ausbaustufen (inkrementelle Erweiterungen) zu den bereits vorliegenden Teilen kompatibel sind. Nachdem in der bereits angesprochenen Definitionsphase Teilprodukte bzw. Schalen definiert werden, beginnt die Umsetzung des Kerns bzw. des ersten Teilprodukts. Durch dieses inkrementelle Vorgehen verkürzt sich die Entwicklungszeit bis zum ersten einsatzfähigen Teilprodukt im Gegensatz zu einem sequentiellen Vorgehen enorm. Zusätzlich können die bereits im Einsatz gewonnenen Erfahrungen mit der Version X bei der Entwicklung der Version X+1 positiv einfließen. Abbildung 11 zeigt den Ablauf der Entwicklung eines Softwareprodukts unter Nutzung des inkrementellen Modells schematisch. Abbildung 11: Schematische Darstellung d. inkrementellen Modells (Balzert, 2000) Da bereits zu Beginn des Projekts feststand, dass sich die Entwicklung des Gesamtprodukts zur Erfassung von deklarativem und prozeduralem Interaktionswissen in mindestens drei Ausbaustufen zergliedern wird, ist die Nutzung dieses Modellansatzes vielversprechend. Die drei Ausbaustufen sind: Kern (Basisversion): Onlineumsetzung der CLS (Studienarbeit, Zeißig, 2008) Ausbau 1: szenariobasierte Erfassung prozeduralen Wissens (Diplomarbeit) Ausbau 2: grafischer Umfrage-/ Testdesigner (zukünftige Arbeiten) Die Vor- und Nachteile dieses Modellansatzes werden von Balzert (2008) ausführlich beschrieben und sind in Tabelle 1 zusammengefasst.

21 Prozessmodelle der Software-Entwicklung Das evolutionäre Modell 21 Vorteile Größtenteils vollständige Anforderungsdefinition erlaubt Zerlegung in Teilprodukte und die Wahl einer geeigneten Systemarchitektur. Nichtfunktionale Anforderungen werden von Anfang an berücksichtigt. Nach Definitionsphase Auslieferung einsatzfähiger Produkte in kurzen Zeitabständen. Risikominimierung bzgl. Architekturentscheidungen durch weitestgehend vollständige Anforderungsdefinition. Nachteile Nicht geeignet, wenn nicht alle Anforderungen zu Projektstart fest stehen, bzw. nicht bekannt ist, wie man das Problem lösen soll. Großer zeitlicher Aufwand in der Anfangsphase. Tabelle 1: Vor- und Nachteile des inkrementellen Modells (nach Balzert, 2008) Der erste Nachteil kann durch die Nutzung weiterer Modellansätze, wie Prototyping (vgl. Kapitel 3.5), kompensiert werden. Auch durch ein evolutionäres Vorgehen (vgl. Kapitel 3.3) innerhalb der einzelnen Ausbaustufen kann man diesem Nachteil entgegenwirken. Der Nachteil des hohen zeitlichen Aufwands in den frühen Phasen kann als gerechtfertig angesehen werden. Nach McConnell (1996) macht das Korrigieren von Fehlern, die bereits in früheren Phasen hätten vermieden werden können, heutzutage etwa 40-80% der Gesamtkosten eines Softwareprojekts aus. 3.3 Das evolutionäre Modell Dieser Ansatz beschreibt die Umsetzung der Mussanforderungen des Auftraggebers in einem Produktkern oder einem Teilprodukt. Es wird ausschließlich der Produktkern in einer sogenannten Nullversion implementiert. Diese wird an den Auftraggeber ausgeliefert, sodass er damit Erfahrungen sammeln und weitere Produktanforderungen definieren kann. Durch diese codegetriebene Entwicklung wird der Auftraggeber in regelmäßigen Abständen mit neuen Produktversionen beliefert. Die gesammelten Erfahrungen können direkt in die Weiterentwicklung einfließen. Darüber hinaus wird das Risiko minimiert, da durch die kleineren Arbeitsschritte auch die Richtung der Gesamtentwicklung stufenweise kontrolliert und gesteuert werden kann. Abbildung 12 zeigt ein Vorgehen nach dem evolutionären Ansatz in schematischer Form.

22 Prozessmodelle der Software-Entwicklung Das komponentenbasierte Modell 22 Abbildung 12: Vorgehen nach dem evolutionärem Modell (Balzert, 2008) 3.4 Das komponentenbasierte Modell Dieses Modell zielt vorrangig auf Aspekte der Wirtschaftlichkeit ab. Der Fokus liegt auf der Wiederverwendbarkeit sogenannter Halbfabrikate (Komponenten). Dadurch sollen Softwareprodukte schneller und preiswerter erstellt werden. Neben diesen Halbfabrikaten kommen bei objektorientierten Entwicklungen, wie in dieser Arbeit, häufig Frameworks zum Einsatz: Ein Rahmenwerk (framework) ist ein durch den Software- Entwickler anpassbares oder erweiterbares System kooperierender Klassen, die einen wiederverwendbaren Entwurf für einen bestimmten Anwendungsbereich implementieren. (Balzert, 2000, S. 834). Durch den Einsatz von fertigen Komponenten ergeben sich folgende Vorteile: Zeitersparnis bei der Entwicklung Verbesserung der Produktivität und Qualität, da die Komponenten von einem großen Nutzerkreis verwendet werden und deswegen sehr ausgereift sind Konzentration auf die Kernelemente der Eigenentwicklung möglich Den Vorteilen stehen einige Nachteile, Probleme und Risiken gegenüber, die im Folgenden genannt und anschließend in Bezug auf diese Arbeit analysiert werden. Nachteile, die durch den Einsatz des komponentenbasierten Ansatzes entstehen können sind: Komponenten und Frameworks lassen sich schwer anpassen und erweitern Aufwendiger Glue Code 8 notwendig, um die Komponenten zu verknüpfen Abhängigkeiten von Komponentenherstellern Inkompatibilitäten von Klassenbibliotheken 8 Notwendiger Code, der keinen Beitrag zur Erfüllung der Programmspezifikation leistet

23 Prozessmodelle der Software-Entwicklung Das Prototypenmodell 23 Schwergewichtige Frameworks lassen sich schwierig erweitern und anpassen, da diese einen komplexen Aufbau haben. Es ist notwendig, bereits in frühen Phasen des Projekts genaue Nachforschungen anzustrengen, welche Frameworks die Anforderungen am besten erfüllen. In den seltensten Fällen wird ein auf dem Markt verfügbares Framework alle Anforderungen zu 100% erfüllen. Daher ist es neben dem angebotenen Leistungsumfang unerlässlich, auf die Kompatibilität und Integrierbarkeit mit anderen Frameworks zu achten. Ein neuerer Ansatz, um die Erweiterung von Frameworks zu erleichtern, sind sogenannte lightweight Bibliotheken oder Frameworks. Der Trend geht hier zur Beschränkung auf einige wichtige Basisfunktionalitäten. Zusatzfunktionen, Erweiterungen oder Anpassungen können daher relativ leicht vorgenommen werden. Ein Vertreter dieser Klasse ist jquery. Derzeit sind bereits viele freie und kommerzielle Erweiterungen (Komponenten) in Form von Plugins verfügbar. Ein kurzer Exkurs zu jquery und dessen Verwendung in dieser Arbeit sind in Kapitel zu finden. Unter Glue Code versteht man Programmcode, welcher keinen Beitrag in Hinsicht auf die Erfüllung der Programmspezifikation leistet. Vielmehr ist er notwendig, damit Komponenten zusammen geklebt werden (miteinander agieren) können, die anderenfalls inkompatibel wären. Auch zur persistenten Ablage von Objekten in einer relationalen Datenbank ist Glue Code für die Abbildung der Objektattribute auf Tabellen notwendig. Mit der Einführung des EJB 9 3 Standards (vgl. Kapitel 4.3.4) wurde die Notwendigkeit von Glue Code stark reduziert. Durch den Einsatz weiterer Frameworks wie jboss seam (vgl. Kapitel 4.3.6) kann Glue Code größtenteils vermieden werden. 3.5 Das Prototypenmodell Das Prototypenmodell kann ähnlich wie das komponentenbasierte Modell als Ergänzung zu anderen Modellen gesehen werden. Es soll vor allem bei folgenden in Software-Entwicklungsprojekten verbreiteten Problemen unterstützen: Anwender und Benutzer können ihre Anforderungen nicht adäquat formulieren, die meisten Prozessmodelle erfordern jedoch eine vollständige Spezifikation Spezielle Anforderungen erfordern die Diskussion unterschiedlicher Strategien Kooperation zwischen Anwendern und Entwicklern ist gewünscht, wird aber von den meisten Modellen nach dem Zusammenstellen der Anforderungen beendet Entwickler wissen zu wenig über das Abwendungsgebiet Anwender wissen zu wenig darüber, was Computer leisten können und was nicht Es existiert keine gemeinsame Projektsprache 9 Enterprise Java Beans, Sammlung standardisierter Komponenten für Java

24 Prozessmodelle der Software-Entwicklung Gewähltes Vorgehen 24 Ziel des Prototyping ist es, möglichst früh ablauffähige Versionen des Softwareprodukts bereitzustellen, um damit Erfahrungen zu sammeln sowie eine Diskussions- und Entscheidungsgrundlage zu schaffen. Floyd (1984) unterscheidet drei Arten von Prototyping: Exploratives Prototyping dient der Anforderungsklärung sowie der Diskussion verschiedener Möglichkeiten von Softwarelösungen. Grundlegende Kommunikationsprobleme zwischen Anwender, Auftraggeber und Entwickler sollen durch die Schaffung einer gemeinsamen Projektsprache sowie die Herausbildung eines gesicherten Verständnisses der gewünschten Funktionalität kompensiert werden. Die Demonstration eines Prototypen kann hierbei eine katalysierende Wirkung haben. Experimentelles Prototyping entspricht dem klassischen Verständnis eines Prototypen. Ziel ist es, einen Prototypen zu schaffen, der von allen Beteiligten akzeptiert ist, bevor mit der eigentlichen Implementierung begonnen wird. Alternative Lösungsvorschläge werden im Experiment bewertet und diskutiert. Evolutionäres Prototyping unterstützt bei der kontinuierlichen Anpassung eines bestehenden Softwareprodukts an sich ändernde Anforderungen. 3.6 Gewähltes Vorgehen Keines der vorgestellten Vorgehensmodelle kann ohne weiteres alleinstehend verwendet werden. Gründe dafür sind zum Beispiel die Anzahl der Beteiligten sowie die Projektgröße im Allgemeinen. Darüber hinaus ist es sehr wichtig, dass ein Prozess nicht nur existiert, sondern dass dieser auch von allen Mitwirkenden gelebt wird. Sogenannte Metamodelle wie das Spiralmodell (Boehm, 1988) helfen dabei, flexible Vorgehensweisen für jeden Schritt der Entwicklung unter Gesichtspunkten der Risikominimierung zu ermitteln. Durch den hohen Managementaufwand ist dieses Vorgehen für Projekte dieser Größenordnung allerdings weniger gut geeignet. Daher wurde in dieser Arbeit ein Vorgehen gewählt, welches sich aus den in den vorherigen Abschnitten beschriebenen Verfahren zusammensetzt. Gemeinsame Vorüberlegungen und Diskussionen zwischen Auftraggeber und Entwickler haben ergeben, dass das fertige Endprodukt in mehreren Stufen entwickelt werden soll. Diese Überlegung begründet sich daraus, dass die Endausbaustufe sehr umfangreich ist, jedoch nicht sofort alle Funktionen benötigt werden. Dieses Vorgehen spiegelt den inkrementellen Ansatz (vgl. Kapitel 3.2) wider. Zu den größten Problemen der Software-Entwicklung gehören nicht bekannte oder nicht formulierbare Anforderungen. Eine in der Literatur oft zitierte Aussage beschreibt diesen Sachverhalt: I can t tell you what I want, but I ll know it when I see it. (Boehm,

25 Prozessmodelle der Software-Entwicklung Gewähltes Vorgehen , S. 63). Um den daraus resultierenden Problemen entgegenzusteuern, wurde für die einzelnen inkrementellen Schritte der evolutionärer Ansatz verwendet. Der Schwerpunkt während der Entwicklung lag auf lauffähigen Teilprodukten, mit denen Erfahrungen gesammelt wurden. Ergänzend dazu kamen Prototypen in mehreren Stadien der Software-Entwicklung zum Einsatz. Prototypen helfen nicht nur dem Entwickler bei der Evaluierung geeigneter Technologien, sondern gewähren dem Auftraggeber bereits in frühen Phasen einen Eindruck über das Aussehen und die Funktionsweise des Produkts. Besonders für die Gestaltung der Benutzeroberfläche, die vor allem bei der Entwicklung der in Kapitel 5 beschriebenen interaktiven Szenarien im Vordergrund stand, bietet sich dieses Vorgehen an. Es minimiert nicht nur das Projektrisiko, sondern fördert gleichzeitig die Kreativität. Um Zeit und Aufwand zu sparen, wurde für alle Produktphasen und Ausbaustufen der komponentenbasierte Ansatz verwendet. Durch das Zurückgreifen auf bereits fertige, in vielen Projekten eingesetzte Komponenten, Konzepte und Frameworks kann darüber hinaus eine deutliche Steigerung der Qualität erwartet werden. Das gewählte Vorgehen greift in Ansätzen die Ideen auf, welche im Agilen Manifest (Manifesto, 2001) durch die Befürworter agiler Prozessmodelle im Jahre 2001 veröffentlicht wurden. Agile Prozessmodelle haben sich als Gegenbewegung zu den monumentalen Prozessmodellen entwickelt. Die Ideen im Manifest sind nach Balzert (2008) wie folgt sinngemäß übersetzt: Einzelpersonen und Interaktionen wichtiger als Prozesse und Werkzeuge. Laufende Systeme wichtiger als umfassende Dokumente. Zusammenarbeit mit dem Kunden wichtiger als Vertragsverhandlungen. Reaktion auf Änderungen wichtiger als das Verfolgen eines Plans. Im folgenden Kapitel wird die Software-Entwicklung der Basisversion zusammengefasst. Exemplarisch werden einige etablierte Methoden und Pattern angesprochen sowie deren Anwendung auf die Entwicklung der Basisversion aufgegriffen. Besonders die Entwurfsphase mit den in ihr getroffenen Grundsatzentscheidungen wird ausführlicher dargestellt.

26 Phasen der Software-Entwicklung Die Planungsphase 26 4 Phasen der Software-Entwicklung Die zuvor beschriebene Wahl des Prozessmodells bestimmt maßgeblich, welche Aktivitäten zu welcher Zeit in welcher Reihenfolge durch welche Personen durchzuführen sind. Weiterhin definiert es die Ergebnisse und deren Überprüfung. Die im Modell beschriebenen Aktivitäten werden zu Phasen zusammengefasst. Balzert (2000) unterscheidet in seinem Lehrbuch der Software-Technik sechs Phasen: Planungsphase Definitionsphase Entwurfsphase Implementierungsphase Abnahme- und Einführungsphase Wartungs- und Pflegephase Diese Phasen werden in den folgenden Kapiteln theoretisch beschrieben. Die dazugehörigen Aktivitäten und Artefakte werden im Rahmen der Basisversion des Softwareprojekts webbasierte Diagnoseplattform (WDP) vorgestellt. Hierbei werden nicht alle Einzelschritte im Detail erörtert, sondern nur die wichtigsten Aspekte oder Spezialfälle genauer betrachtet. 4.1 Die Planungsphase Hauptziel der Planungsphase, wie in Abbildung 13 schematisch dargestellt, ist es, eine Durchführbarkeitsuntersuchung (engl. feasibility study) vorzunehmen. In dieser Voruntersuchung muss unter anderem gezeigt werden, ob die Umsetzung aus fachlicher Sicht möglich ist. Des Weiteren muss überprüft werden, ob die personelle Durchführbarkeit gegeben sowie die Umsetzung aus ökonomischer Sicht sinnvoll ist. Abbildung 13: Schematischer Überblick Planungsphase (Balzert, 2000)

27 Phasen der Software-Entwicklung Die Planungsphase 27 Die wichtigsten Festlegungen, welche für jede einzelne der in Kapitel 4 beschriebenen Phasen fixiert werden sollten, sind in Tabelle 2 für die Planungsphase abgebildet. Name Ziel Aktivitäten Planungsphase Soll das Produkt entwickelt werden oder nicht? Planen des Produkts Auswählen des Produkts Voruntersuchung des Produkts Artefakte & Rollenverteilung Durchführbarkeitsuntersuchung Lastenheft (Anwendungsspezialist) Glossar (Anwendungsspezialist) Projektplan (Projektleiter) Projektkalkulation (Projektleiter) Tabelle 2: Tabellarische Übersicht der Planungsphase Zusätzlich zu den in der Rollenverteilung erwähnten Hauptverantwortlichen ist der Auftraggeber bei der Erstellung jedes einzelnen Artefakts eingebunden. Dieser ist maßgeblich für die Vorgabe der Anforderungen sowie die Abnahme der entstandenen Artefakte zuständig. Die Rollenverteilung in dieser Phase erfolgte aufgrund des kleinen Projektteams wie folgt: Auftraggeber ist der Lehrstuhl für Ingenieurspsychologie der Humboldt Universität zu Berlin, vertreten durch Michael Sengpiel. Die beiden anderen Rollen sind in einer Person vereinigt. Eines der wichtigsten Ergebnisse der Planungsphase ist das Lastenheft. In ihm sind alle, aus Sicht des Auftraggebers, fachlichen Basisanforderungen festgehalten. Alle im Lastenheft fixierten Eckdaten haben in dieser frühen Phase der Software-Entwicklung ein sehr hohes Abstraktionsniveau. Es wird ausschließlich festgehalten WAS realisiert werden soll. Bei der Erstellung eines solchen Artefakts ist es besonders wichtig, darauf zu achten, dass es in einer Sprache formuliert ist, die für alle Beteiligten verständlich ist. In UML 10 modellierte Anwendungsfälle (engl. use cases) haben sich als wichtige Kommunikationsgrundlage im Softwareentstehungsprozess etabliert, da sie sowohl von Entwicklern als auch von Kunden gelesen und interpretiert werden können. Ein Lastenheft sollte nach einem festen Gliederungsschema aufgebaut sein, wie es in der Fachliteratur zu finden ist. Balzert (2000) schlägt eine Gliederung vor, wie sie in Listing 3 zu sehen ist. Das vollständige Lastenheft der Basisversion der WDP befindet sich im Anhang (Kapitel A.3.1). 10 Unified Modeling Language, standardisierte Sprache für die Modellierung von Software

28 Phasen der Software-Entwicklung Die Planungsphase 28 Lastenheft 1. Zielbestimmung Welche Ziele sollen durch das Produkt erreicht werden? 2. Produkteinsatz Für welche Anwendungsbereiche und welche Zielgruppe ist das Produkt vorgesehen? 3. Produktübersicht Überblick über die Produktumgebung, meist in Form eines Umweltdiagramms. 4. Produktfunktionen Beschreibung der Hauptfunktionen (der typischen Arbeitsabläufe) des zu entwickelnden Produkts aus Sicht des Auftraggebers. Jede Funktionsanforderung ist wie in folgendem Beispiel zu markieren: /LF30/ (Lastenheft Funktion sowie eine laufende Nummer) Die Funktionalität kann mit Hilfe von Akteuren und Geschäftsprozessen ermittelt werden, wie es im Folgenden beschrieben wird. 5. Produktdaten Die langfristig zu speichernden Hauptdaten sowie deren voraussichtlicher Umfang. 6. Produktleistungen Sollten an Hauptfunktionen (aus 4) oder Hauptdaten (aus 5) spezielle Anforderungen bzgl. Zeit oder Genauigkeit bestehen, werden diese hier wie folgt vermerkt: /LLnn/ (Lastenheft Leistung sowie eine laufende Nummer) 7. Qualitätsanforderungen Was sind die wichtigsten Qualitätsanforderungen und deren jeweilige Qualitätsstufe? 8. Ergänzungen Ergänzungen und spezielle Anforderungen. Listing 3: Muster eines Lastenhefts (Balzert, 2000)

29 Phasen der Software-Entwicklung Die Planungsphase 29 Grundsätzlich gibt es für die Aufnahme der Anforderungen und die daraus resultierende Analyse und Modellierung eines Systems zweierlei Ansätze, die sich etabliert haben. Die in dieser Arbeit verwendete outside-in-methode modelliert zuerst die Umwelt des zu entwickelnden Produkts. Aus diesem Modell lassen sich anschließend die Produktinterna ableiten. Der zweite Ansatz, welcher sich vor allem für technische Systeme eignet, modelliert zuerst die Produktinterna und anschließend die Schnittstellen zur Umwelt. In der Literatur wird diese Vorgehensweise als inside-out-methode bezeichnet. Für eine objektorientierte Entwicklung von Software hat sich die Modellierung durch Akteure (engl. actors) und Geschäftsprozesse (engl. use cases) durchgesetzt. Ein Akteur ist jemand, der an einem Geschehen aktiv und unmittelbar beteiligt ist. Für die webbasierte Diagnoseplattform lassen sich folgende zwei Arten von Akteuren ermitteln. Versuchsleiter: Regelt den administrativen Teil psychologischer Untersuchungen. Versuchsperson: Teilnehmer an einer Befragung, einem Test. Tabelle 3: Ermittelte Akteure der WDP Das zu erzeugende Produkt sowie seine ermittelten Akteure lassen sich in einem sogenannten Umweltdiagramm darstellen. Ein Umweltdiagramm für die Basisversion der WDP ist in Abbildung 14 zu sehen. Zusätzlich sind die Datenflüsse zwischen den Akteuren und dem System in blau ergänzt. Anhand des Pfeils kann die Richtung des Datenstroms abgelesen werden. Umfragen, Tests, Nutzer und Nutzerreihen Umfragen, Tests und Feedback WDP Nutzerdaten, Erhebungsdaten Nutzerdaten, Antworten Versuchsleiter Versuchsperson Abbildung 14: UML Umweltdiagramm Basisversion der WDP Geschäftsprozesse bestehen aus mehreren zusammenhängenden Aufgaben, die von einem Akteur durchgeführt werden, um ein Ziel zu erreichen bzw. ein gewünschtes Ergebnis zu erstellen. Einen solchen Geschäftsvorgang kann man beispielsweise wie folgt durch einen kurzen Text beschreiben: Prozess Akteure Beschreibung Umfrage/Test auswerten Versuchsleiter Versuchsleiter können erhobene Daten für weitere Auswertungen exportieren. Tabelle 4: Beschreibung eines Geschäftsprozesses

30 Phasen der Software-Entwicklung Die Definitionsphase 30 Alle erfassten Geschäftsprozesse befinden sich im Lastenheft, welches im Anhang (Kapitel A.3.1) zu finden ist. Die analysierten Geschäftsprozesse lassen sich in einem Umweltdiagramm darstellen, wie es in Abbildung 15 zu sehen ist. Abbildung 15: Durch Akteure und Geschäftsprozesse modellierte Umwelt der WDP Während der Planungsphase sind die groben Anforderungen des Auftraggebers erfasst und niedergeschrieben worden. Diese sind erfahrungsgemäß relativ vage, unpräzise, nicht zusammenhängend oder sogar widersprüchlich. Ziel der nächsten Phase der Definitionsphase ist es, diese Anforderungen in ein vollständiges, konsistentes und eindeutiges Produktmodell zu überführen. 4.2 Die Definitionsphase In dieser Phase der Software-Entwicklung werden die bisher erstellten Artefakte durch intensive Interviews mit dem Auftraggeber und den Endnutzern weiter verfeinert. Hierbei liegt der Fokus immer noch auf dem WAS, nicht auf dem WIE der Produktrealisierung. Ziel ist es also, eine fachliche Problemlösung aus Auftraggebersicht zu erarbeiten, welche in einer Produktdefinition mündet. Abbildung 16 zeigt die wichtigsten Sachverhalte dieser Phase. Abbildung 16: Überblick Definitionsphase (Balzert, 2000)

31 Phasen der Software-Entwicklung Die Definitionsphase 31 Um eine Produktdefinition erstellen zu können, ist es notwendig, die Anforderungen (engl. requirements) aus Sicht des Auftraggebers zu erfassen: Die systematische Ermittlung, Beschreibung, Modellierung und Analyse der Anforderungen unter Einsatz geeigneter Methoden und Werkzeuge bezeichnet man als Systemanalyse (engl. requirements engineering). (Balzert, 2000, S. 118). Für die Beschreibung eines Produktmodells gibt es diverse Basiskonzepte. Da die meisten Basiskonzepte relativ alt sind, gehen neuere Entwicklungen dazu über, verschiedene Basiskonzepte zu kombinierten Konzepten für die Systemanalyse zusammenzusetzen. Einige der wichtigsten Basiskonzepte (nach Balzert, 2000) seien hier stichpunktartig genannt. Die Basiskonzepte sind zusätzlich in Sichten gruppiert, die sie hauptsächlich abdecken: Funktionale Sicht Funktionsbaum Geschäftsprozess (1987) Datenflussdiagramm (1966) Datenorientierte Sicht Data Dictionary (1979) Entity Relationship (1976) Objektorientierte Sicht Klassendiagramm (1980/90) Algorithmische Sicht Pseudocode Regelbasierte Sicht Zustandsorientierte Sicht Zustandsautomat (1954) Petrinetze (1962) Szenariobasierte Sicht Sequenzdiagramm (1987) Eine Analysemethode, welche sich vor allem im Zusammenhang mit der objektorientierten Software-Entwicklung durchgesetzt hat, ist die objektorientierte Analyse (OOA, object orientated analysis). Die OOA ist ein Konglomerat (Abbildung 17) vieler Basiskonzepte der Software-Entwicklung und erlaubt dem Systemanalytiker, die Modellierung der in dieser Phase gefragten fachlichen Lösung.

32 Phasen der Software-Entwicklung Die Entwurfsphase 32 Abbildung 17: Komponenten der OOA Ziel der OOA muss es sein, alle Informationen zur Problemlösung, Strukturen und Beziehungen zu erkennen. Diese können in einem anschließenden Schritt, dem objektorientierten Design, in ein komplettes Modell umgesetzt werden. In diesem zweiten Schritt wird das OOA-Modell modifiziert, optimiert und in erster Linie an die entsprechend vorhandene oder gewählte Architektur angepasst. Der Übergang von der erarbeiteten Produktdefinition zum Produktentwurf geschieht in der Entwurfsphase, welche im Kapitel 4.3 beschrieben wird. Eines der größten Probleme der Definitionsphase besteht darin, dass der Auftraggeber kein vollständiges Modell des zu entwickelnden Systems im Kopf hat, weshalb er zwischen abstrakten Angaben und konkreten Wünschen hin- und herspringt. Ein Blick auf die Eigenschaften mentaler Modelle (Kapitel 2.2) verdeutlicht diesen Sachverhalt. Prototypen (Kapitel 3.5) können dem Systemanalytiker beim Erstellen eines Produktmodells helfen und wurden daher sowohl im Kolloquium 11, als auch in verschiedenen Workshops eingesetzt. Ein weiteres Problem besteht darin, dass es bei einer objektorientierten Entwicklung oftmals schwer fällt, die einzelnen Phasen einer Software-Entwicklung gegeneinander abzugrenzen. Häufig ist es nicht möglich, ein Produktmodell zu erzeugen, ohne dabei technische Aspekte zu berücksichtigen, welche eigentlich erst in der Entwurfsphase zum Tragen kommen sollten. Da es sich bei der Definitionsphase um eine der aufwendigsten und schwierigsten Phasen handelt, wurden hier nur die theoretischen Ansätze vorgestellt. Weiterführende Informationen finden sich in der Studienarbeit (Zeißig, 2008). 4.3 Die Entwurfsphase Ziel dieser Phase ist es, die in der vorangegangenen Phase erarbeitete Produktdefinition in einen Produktentwurf umzusetzen. In Abgrenzung zur Definitionsphase wird erstmals in Betracht gezogen, WIE die Umsetzung zu realisieren ist. Abbildung 18 zeigt die Entwurfsphase in schematischer Form. Hauptakteur dieser Phase ist der Entwerfer (engl. designer). Zusätzlich wird eine geeignete Person hinzugezogen, welche die Rolle des Implementierers übernimmt. Oftmals findet, wie im Rahmen dieser Arbeit, ein Zusammenzug dieser beiden Rollen zur Rolle des Konstrukteurs statt. 11 Forschungskolloquium des Lehrstuhls Arbeits- und Ingenieurpsychologie

33 Phasen der Software-Entwicklung Die Entwurfsphase 33 Abbildung 18: Überblick Entwurfsphase (Balzert, 2000) Neben den funktionalen Produktanforderungen gibt es weitere Einflussfaktoren, welche die Entwurfsphase und die in ihr zu treffenden Grundsatzentscheidungen maßgeblich mitbestimmen. Als einleitender Schritt ist es daher notwendig, die Einsatz-, Umgebungs- und Randbedingungen sowie die nichtfunktionalen Anforderungen an das Produkt festzustellen. Diese sind für die WDP wie folgt stichpunktartig festgehalten: Einsatzbedingungen Nicht sequentiell (verteilt, nebenläufig) Für mehrere Benutzer Umgebungs- und Randbedingungen Vorhandene Hard- und Software beachten Nichtfunktionale Produkt- und Qualitätsanforderungen Kosten Skalierbarkeit Internationalisierbarkeit Zuverlässigkeit Aus den funktionalen Anforderungen sowie den hier genannten Faktoren leiten sich einige Grundsatzentscheidungen ab, die es zu treffen gilt. Abbildung 19 zeigt schematisch den Weg vom Fachkonzept bis zur fertigen Softwarelösung sowie die notwendigen Entscheidungen.

34 Phasen der Software-Entwicklung Die Entwurfsphase 34 Abbildung 19: Vom Fachkonzept zur Anwendung (nach Balzert, 2000) Nicht alle Entscheidungen sind für jedes zu entwickelnde Softwareprodukt zu treffen. Die wichtigsten Grundsatzentscheidungen für die Erstellung der Basisversion werden in den folgenden Abschnitten genannt und begründet Kategorie und Netzverteilung Grundsätzlich gilt es für jedes Softwareprodukt abzuwägen, auf welche Art und Weise die Anwendung zu konzipieren und zu verteilen ist. Die aus Sicht der Verteilung einfachste Art ist die Entwicklung einer Desktopanwendung. Da Anwendungen der Desktopkategorie auf einem einzelnen Rechner betrieben und größtenteils durch einen Anwender genutzt werden, erlauben sie eine relativ einfache Systemarchitektur. Als besonders sinnvoll hat sich, unabhängig von der Anwendungskategorie, die Zuordnung der zu entwickelnden Komponenten anhand ihres Abstraktionsniveaus in Schichten herausgestellt. Balzert (2000) empfiehlt die Verwendung der sogenannten Drei-Schichten-Anwendungsarchitektur. Sie beschreibt eine Strukturierung in Präsentationsschicht (engl. client tier), Logikschicht (engl. application server tier oder enterprise tier) und Datenhaltungsschicht (engl. data server tier) in linearer Ordnung. Linear bedeutet in diesem Zusammenhang, dass von einer Schicht nur auf die angrenzende Schicht niedrigeren Abstraktionsniveaus zugegriffen werden kann. Durch die Verwendung einer Schichtenarchitektur werden nicht nur die Wartbarkeit und Portabilität erhöht, es wird auch die Skalierbarkeit deutlich verbessert. Aus den gesammelten Anforderungen an das Produkt ergibt sich, dass eine Umsetzung als Desktoplösung nicht zweckmäßig ist. Ziel ist es, eine Anwendung zu gestalten, die eine weltweit verteilte Benutzung zulässt, sogleich aber eine zentrale Datenhaltung ermöglicht. Um eine Anwendung zu verteilen, ist eine Zerlegung in Schichten unumgänglich. Es ergeben sich zwei alternative Lösungsansätze. Zum einen ist eine klassische

35 Phasen der Software-Entwicklung Die Entwurfsphase 35 Client/Server- zum anderen eine Web-Anwendung denkbar. Die zwei Lösungsansätze sind unter Verwendung der beschriebenen Schichtenarchitektur in Abbildung 20 dargestellt. Im Folgenden werden beide Ansätze detaillierter vorgestellt und miteinander verglichen. Abbildung 20: Client/Server- sowie Web-Architektur bei Java EE (Sun, 2009) Client/Server-Architekturen besitzen nach Balzert (2000) folgende Charakteristika: Permanente Verbindung zwischen Server und Client Maximale Anzahl der konkurrierenden Nutzer bekannt Umgebung in der Regel bekannt, z.b. Betriebssystem, Datenbanken usw. Entwickler für Client- und Serverteil verantwortlich Hingegen besitzen Web-Anwendungen folgende Charakteristika, aus denen sich die anschließend beschriebenen Vor- und Nachteile im Vergleich zu Client/Server-Lösungen ergeben: Zustandsloses Protokoll HTTP (Hypertext Transfer Protokoll) Potentiell unbegrenzte Anzahl von Nutzern Entwickler haben keinen Einfluss auf die Laufzeitumgebung des (Web-)Clients Die permanente Verbindung zwischen Client und Server bei klassischen Client/Server-Lösungen ermöglicht eine leichte Verfolgung der Nutzersession. Aufgrund des zustandslosen Protokolls HTTP, wie es bei Web-Anwendungen für die Kommunikation zwischen Web-Server und Web-Client verwendet wird, ist dies nicht nativ möglich. Das Mitführen spezieller Sitzungsdaten kann jedoch nachträglich auf der Anwendungsebene unter Verwendung sogenannter Cookies 12 implementiert werden. Bei der Verfolgung der Nutzersession (selbst über mehrere Browserfenster hinweg) helfen heutzutage Frameworks, wie sie im Kapitel 4.3 beschrieben sind. Der Vorteil der zustandsbehafteten Verbindung einer klassischen Client/Server-Umsetzung kann demnach, durch relativ 12 Clientseitig gespeicherte Informationen

36 Phasen der Software-Entwicklung Die Entwurfsphase 36 geringen Zusatzaufwand, bei Web-Anwendungen ebenfalls erreicht werden. Da die Entwickler einer Client/Server-Lösung Einfluss auf deren Laufzeitumgebung haben, kann die Systemkomplexität reduziert werden. Im Gegensatz dazu kann die Laufzeitumgebung des Web-Clients nicht manipuliert werden. In der Regel müssen sogar mehrere verschiedene Webbrowser unterstützt werden. Diese Nachteile von Webarchitekturen kann man durch die Benutzung von Frameworks und Hilfsmitteln zur Gestaltung der Benutzeroberfläche, wie sie im Abschnitt GUI-Systeme (Kapitel 4.3.3) beschrieben sind, minimieren. Zusätzlich kann der Zugriff auf bestimmte Abschnitte (Seiten) einer Webanwendung durch minimalen programmatischen Aufwand auf wenige Webbrowser eingeschränkt werden. Da sich unterschiedliche Webbrowser bei der Interpretation von HTML und dem ergänzenden CSS teilweise sehr unterschiedlich verhalten, wurde der Zugriff auf die Kernanwendung vorerst auf Mozilla Firefox eingeschränkt. Im Februar 2009 hatte Mozilla Firefox weltweit einen Marktanteil von etwa 22% (vgl. Net Applications, 2009). Darüber hinaus gibt es für diesen Browser mächtige Tools, die bei der Entwicklung von Webanwendungen unterstützen. Ein solches Tool ist Firebug von Joe Hewitt, Justin Dolske und Rob Campbell, welches in Kapitel vorgestellt wird. Die Beschränkung auf Versuchspersonen, die Mozilla Firefox benutzen, geschieht während der Authentifizierung (vgl. Kapitel 4.4.2). Balzert (2000) hebt als positiven Aspekt von Webanwendungen deren gute Skalierbarkeit und Wartbarkeit hervor, wohingegen klassische Client/Server-Architekturen kaum skalierbar sind. Eine weitere Überlegenheit der Web-Architektur leitet sich aus der Verteilung der Clientsoftware ab. Diese ist bereits als Webbrowser in einigen Betriebssystemen enthalten bzw. als zusätzlich installierte Software vorhanden. Klassische Client/Server-Architekturen verlangen eine Verteilung sowie die Installation auf jedem einzelnen Client. Besonders der letzte Aspekt war ausschlaggebend für die Umsetzung als Web-Architektur. Die Hemmschwelle, an einem Test oder einer Umfrage teilzunehmen, sollte so gering wie möglich gehalten werden. Zusätzliche Installationen schrecken potentielle Teilnehmer unnötig ab bzw. sind aufgrund eingeschränkter Zugriffsrechte nicht möglich. Die Verwendung eines Webbrowsers ist den meisten Computernutzern geläufig, bzw. kann das zur Benutzung notwendige Wissen nach einmaligem Erlernen universell verwendet werden. Die Teilnahme an einer Umfrage oder einem Test kann in der Regel somit direkt nach dem Anklicken eines per Mail versendeten oder auf einer Webseite angegebenen Hyperlinks beginnen Datenhaltung Generell sind alle von einer Anwendung erzeugten Daten nur während der Laufzeit des

37 Phasen der Software-Entwicklung Die Entwurfsphase 37 Programms vorhanden. Die Umsetzung dieses Softwareprodukts erfordert daher eine persistente Datenhaltung in geeigneter Form. Grundsätzlich gibt es drei Formen der Datenhaltung: In Dateien auf Betriebssystemebene In relationalen Datenbanken (RDBMS) In objektorientierten Datenbanken (ODBMS) Abhängig von den erwarteten Datenmengen, von der gewählten Netzverteilung (vgl. Kapitel 4.3.1) sowie von der verwendeten Programmiersprache (vgl. Kapitel 4.3.4) galt es, eine Entscheidung über die Ablage der Daten zu treffen. Datenbanksysteme bieten die Möglichkeit einer persistenten Speicherung unabhängig vom Betriebssystem und der gewählten Programmiersprache. Darüber hinaus verfügen sie über leistungsfähige Auswahlmechanismen, standardisierte Suchverfahren sowie effiziente Speicherungsstrategien für große Datenmengen. Da es sich bei der entwickelten Softwarelösung um eine objektorientierte Anwendung handelt, wäre der Einsatz einer objektorientierten Datenbank naheliegend. Dies hätte eine Arbeit ohne Strukturbruch von der Analyse (OOA) über das Design (OOD) und der Programmierung (OOP) bedeutet. Dem entgegen spricht jedoch die bis heute nur schwache Verbreitung von objektorientierten Datenbanken. Vor allem unter Beachtung der nichtfunktionalen Anforderungen, insbesondere der Kosten und bereits vorhandenen Lösungen im Haus, ist die Entscheidung zugunsten einer freien relationalen Datenbank gefallen. Die Anbindung objektorientierter Anwendungen an relationale Datenbanken hat sich in den letzten Jahren durch die Einführung neuer Standards wie EJB 3 (vgl. Kapitel 4.3.4) und Hibernate stark vereinfacht. Hibernate sorgt für eine objektrelationale Abbildung (engl. object-relational mapping, ORM), welche es dem Programmierer erlaubt, die angebundene Datenbank wie eine objektorientierte Datenbank zu verwenden. Zusätzlich werden die benötigten Datenbankschemata automatisch generiert GUI - Grafische Benutzeroberfläche Eine weitere wichtige Grundsatzentscheidung betrifft die grafische Benutzungsoberfläche (engl. graphical user interface, GUI). Hierbei handelt es sich um die Mensch-Maschine-Schnittstelle des Systems, welche nach software-ergonomischen Gesichtspunkten zu gestalten ist. Es gibt verschiedene GUI-Systeme, die eine Menge an Grundfunktionalitäten für eine grafische Benutzeroberfläche zur Verfügung stellen. Dazu zählen unter anderem: Windows-GUI-System

38 Phasen der Software-Entwicklung Die Entwurfsphase 38 Java Foundation Classes (AWT 13, SWING 14, Java2D, u.a.) HTML Durch die gewählte Form der Kategorie und Netzverteilung (vgl. Kapitel 4.3.1) stand die endgültige Form der Präsentation bereits fest. Als Client beim Anwender kommt ein Webbrowser zum Einsatz. Webbrowser können nur eine begrenzte Anzahl von Script- oder Beschreibungssprachen interpretieren. Die vom Web-Server ausgelieferten Informationen werden als HTML-Seiten an den Webbrowser übermittelt. Die HTML Ansichten werden auf dem Web-Server dynamisch generiert. Darüber hinaus gibt es diverse Frameworks für Webanwendungen, welche den komponentenbasierten Ansatz verfolgen und viele fertige UI-Komponenten 15 mitbringen. Solche Frameworks vereinfachen die Entwicklung von Nutzeroberflächen erheblich und ermöglichen darüber hinaus die Portabilität auf andere Systeme oder Ausgabemedien. Im Rahmen dieser Arbeit wurden Java Server Faces (JSF) verwendet, welche Bestandteil des Java EE Frameworks sind und in Kapitel genauer beschrieben werden. Dieses oder andere Frameworks bieten den Vorteil, dass die mitgebrachten UI-Komponenten unter Zuhilfenahme unterschiedlicher Renderer 16 auf verschiedenartigen Ausgabesystemen dargestellt werden können. Weiterhin ist die Verwendung eines UI-Designers möglich. Alle Elemente der Benutzeroberfläche werden hier interaktiv mit Hilfe eines Grafikeditors zusammengestellt. Es gibt bereits Plugins für Eclipse und andere Entwicklungsumgebungen, die einen solchen UI-Designer realiseren. Zu Beginn der Implementierung der Basisversion stand allerdings noch kein UI-Designer zur Verfügung, der alle Komponenten unterstützte und stabil in einer Eclipse Entwicklungsumgebung lief. Deshalb wurde auf dessen Benutzung verzichtet und die Ausgabetemplates von Hand geschrieben. Abbildung 21 zeigt, wie ein solcher Designer aussehen kann. Abbildung 21: Beispiel eines UI-Designers 13 Abstract Window Toolkit 14 Programmierschnittstelle und Grafikbibliothek zum Programmieren von grafischen Benutzeroberflächen 15 User Interface Komponenten 16 Werkzeug zur Darstellung/Berechnung von grafischen Inhalten

39 Phasen der Software-Entwicklung Die Entwurfsphase 39 Die grafische Oberfläche der webbasierten Diagnoseplattform wird in der Studienarbeit beschrieben und ist auszugsweise im Anhang als Screenshot (Kapitel A.2) zu sehen Wahl der Programmiersprache Die Wahl der Programmiersprache ist eine weitere Grundsatzentscheidung: Aus heutiger Sicht sollte immer eine objektorientierte Programmiersprache wie Java oder C++ gewählt werden (Balzert, 2000, S. 987). Bei Verwendung einer objektorientierten Sprache kann ohne Strukturbrüche gearbeitet werden. Die Festlegung auf eine Programmiersprache beeinflusst außerdem die Auswahl der möglichen Komponentenmodelle. Die Wahl der Entwicklungsplattform, und damit auch die Wahl der Sprache, fiel aus diversen Gründen auf Java EE. Die wichtigsten sind: Ein wichtiger Bestandteil jeder Softwareentwicklung ist eine Dokumentation. Für die automatische Erstellung einer Entwicklerdokumentation gibt es Werkzeuge wie Javadoc (Kapitel 4.4.4). Objektorientierte Sprache Java Frei von Lizenzkosten Viele vorhandene Frameworks Java wird an der Humboldt Universität zu Berlin bereits im Grundstudium gelehrt, was eine Weiterentwicklung in folgenden Diplomarbeiten begünstigt. Des Weiteren bringt Java EE einige Komponenten, Konzepte und Frameworks mit, welche die Umsetzung der getroffenen Entwurfsentscheidungen in geeigneter Weise unterstützen. Zwei der wichtigsten Technologien werden im Folgenden kurz vorgestellt. EJB 3 Bei Enterprise Java Beans handelt es sich um ein serverseitiges Komponentenmodell, welches dafür eingesetzt werden kann, die gesamte Geschäftslogik zu kapseln sowie zu standardisieren. Einige wichtige Aspekte der EJB 3 (JSR-220) Spezifikation sind: Persistenz. Im Entwurf von EJB 3 wird beschrieben, wie Java Klassen standardisiert persistiert werden können. Hierbei wird eine objektrelationale Abbildung realisiert (vgl. Kapitel 4.3.2). Neu bei EJB 3 ist, dass sogenannte Annotations genutzt werden. Diese wurden zusammen mit Java 5 eingeführt. Dadurch ist eine Implementierung als reines POJO 17 möglich. Alle spezifischen Implementierungsdetails werden ausschließlich über Annotations gelöst. Der Einsatz von Annotations sowie die Persistierung von Daten werden in Kapitel beschrieben. Transaktionskontrolle. Eine Transaktion fasst eine Reihe von Operationen zusammen, welche als Einheit abgearbeitet werden müssen. Erst wenn alle Operati- 17 Plain Old Java Object

40 Phasen der Software-Entwicklung Die Entwurfsphase 40 onen unter Einhaltung aller Randbedingungen komplett abgeschlossen sind, gilt die Transaktion als erfolgreich. Anderenfalls müssen alle bisher stattgefundenen Operationen der Transaktion rückgängig gemacht werden. EJB 3 kümmert sich um die Verwaltung aller anfallenden Transaktionen, sodass der Entwickler bei dieser kritischen Aufgabe entlastet wird. Komponenten. Die EJB 3 Spezifikation stellt mehrere Klassen von Java Beans zur Verfügung. Neben den Entity Beans (Kapitel A.3.5) und den Session Beans (Kapitel A.3.6) gibt es Message Driven Beans und Web Services. Message Driven Beans erweitern die Kommunikationsmöglichkeiten zwischen Server und Client um einen asynchronen Datenaustausch. Dies kann beispielsweise über s geschehen. Die Web Services Komponente erlaubt die Abbildung der Schnittstelle einer Stateless Session Bean als Schnittstelle eines Web Services. Der Einsatz von Web Services wird als Möglichkeit, das Softwareprodukt auf unterschiedlichen Zielplattformen verfügbar zu machen, im Kapitel vorgestellt. Java Server Faces Bei Java Server Faces (JSF) handelt es sich um ein Framework für Webanwendungen. Mit JSF lassen sich aus den mitgelieferten Komponenten HTML Formulare generieren, ihre Werte validieren, die entsprechende hinterlegte Businesslogik auslösen sowie die zurückgelieferten Werte wieder anzeigen. Der komplette JSF Lifecycle ist in Abbildung 22 zu sehen. JSF unterstützt den Entwickler bei der Erstellung einer GUI (vgl. Kapitel 4.3.3). Abbildung 22: JSF Lifecycle (Sun, 2008) Da es sich um eine Webarchitektur handelt, kommen weitere Skriptsprachen sowie Frameworks zu deren besseren Handhabung zum Einsatz. Diese werden in den folgenden Abschnitten vorgestellt.

41 Phasen der Software-Entwicklung Die Entwurfsphase ICEfaces Bei ICEfaces der Firma ICEsoft 18 handelt es sich um ein Open Source Enterprise Ajax 19 Framework, welches vor allem die User Experience verbessern soll. Es erweitert die von JSF gelieferten Komponenten im Funktionsumfang und bringt darüber hinaus eigene, neue Komponenten für die Frontendentwicklung mit. Alternativen zu ICEfaces wären: RichFaces der Firma Red Hat Ajax4jsf der Firma Red Hat Trinidad von der Apache Software Foundation Die Entscheidung für ICEfaces wurde größtenteils auf subjektiver Basis getroffen, da jeder Anbieter eine ähnliche Basisfunktionalität verspricht, jedoch unterschiedliche Spezialkomponenten mitbringt. Bei der Entscheidungsfindung haben Prototypen (vgl. Kapitel 3.5) einen entscheidenden Beitrag geleistet. Jede Produktalternative wurde mittels explorativem Prototyping auf ihre Vor- und Nachteile untersucht. Keine der Alternativen brachte alle benötigten Komponenten für die Umsetzung im Frotend mit. Das JSF Framework lässt sich jedoch um eigene Komponenten erweitern. ICEfaces lassen sich relativ einfach in ein Java Enterprise Projekt integrieren, indem eine entsprechende Bibliothek eingebunden wird. Beim Aufsetzen eines solchen Projekts unterstützt das Framework jboss Seam, welches im folgenden Abschnitt vorgestellt wird jboss Seam Bei jboss Seam handelt es sich um ein Web-Framework für die Entwicklung von Java EE Projekten, welches die beiden in Kapitel vorgestellten Frameworks EJB und JSF vereinigt. Dieses wurde von jboss (Red Hat) entwickelt, um eine vereinfachte Vermittlung zwischen der gekapselten Businesslogik und der dazugehörigen Präsentation zu ermöglichen. Durch den Einsatz von Annotations und die Registrierung aller Komponenten im Seam-Kontext soll vor allem der so genannte Glue Code sowie die aufwendige Konfiguration in XML Dateien abgelöst werden. Durch Seam wird es möglich, EJB Komponenten direkt aus der Präsentationsschicht, welche durch JSF (Kapitel und Kapitel 4.3.5) realisiert ist, zu referenzieren. Abbildung 23 zeigt die Vermittlerposition von jboss Seam zwischen der Präsentation und der Anwendungslogik Asynchronous JavaScript and XML

42 Phasen der Software-Entwicklung Die Entwurfsphase 42 Abbildung 23: Einordnung von jboss Seam Zum Seam Framework gehört des Weiteren das Tool seam-gen, welches in Kapitel gesondert vorgestellt wird Apache POI Apache POI 20 ist ein Open Source Projekt, welches sich hauptsächlich der Bereitstellung von Java Schnittstellen für Microsoft Office Produkte gewidmet hat. Im Rahmen des komponentenbasierten Ansatzes (vgl. Kapitel 3.4) wird das HSSF 21 Paket verwendet, welches es ermöglicht, Exceltabellen zu lesen, anzulegen und zu modifizieren. Diese Funktionalität wird dazu genutzt, Daten in eine Exceltabelle zu schreiben, die später nach SPSS importiert werden kann. Obwohl es fertige Schnittstellenbibliotheken für das direkte Erzeugen von SPSS Dateien gibt, wurde aufgrund der nichtfunktionalen Anforderungen, respektive in Anbetracht der Kosten, gegen die Verwendung einer solchen Spezialbibliothek entschieden. Beispielsweise kostet eine Campuslizenz der Firma pmstation für die Bibliothek SPSS Writer derzeit etwa 500$, für die kommerzielle Nutzung etwa 2000$ (Stand März 2009). Da die HSSF Bibliothek auch zum Exportieren von Nutzerserien mit den entsprechenden Logininformationen (vgl. Kapitel A.3.6.2) genutzt wird, ist es aus Gründen der Wirtschaftlichkeit und Wiederverwendung sinnvoll, dieses freie Paket für den Export aller Daten zu nutzen. Sollte eine spätere, direkte Integration von SPSS gewünscht sein, ist dies durch die zweckmäßige Umsetzung der modellierten Geschäftsprozesse (siehe Abbildung 15) in korrespondierende Klassen (vgl. Kapitel A.3.6) nachträglich mit vertretbarem Aufwand realisierbar Krysalis jcharts Krysalis jcharts ist ein Java Paket, welches erstmalig im Dezember 2000 veröffentlicht wurde. Es ermöglicht die Darstellung einer Reihe von Diagrammtypen als Servlet in JSPs oder JSFs. Die auszuwertenden Daten werden an die Klasse übergeben, welche daraus auf dem Server ein Bild mit dem entsprechenden Diagramm generiert und dieses zurück gibt. Einen Überblick über alle Paket- und Klassendiagramme befindet sich im Anhang (Kapitel A.3.4). 20 ursprünglich Akronym für Poor Obfuscation Implementation 21 Akronym für Horrible Spreadsheet Format

43 Phasen der Software-Entwicklung Die Implementierungsphase Die Implementierungsphase Während dieser Phase werden alle vorher spezifizierten Systemkomponenten implementiert. Abbildung 24 zeigt den Ablauf der Implementierungsphase in schematischer Form. Abbildung 24: Übersicht Implementierungsphase (Balzert, 2000) Der Großteil dieser Phase der Entwicklung der Basisversion fand während der vorgelagerten Studienarbeit (Zeißig, 2008) statt. An dieser Stelle werden primär die Besonderheiten bei der Umsetzung der Basisversion aufgegriffen, die für die spätere Bewertung des Gesamtvorgehens (siehe Kapitel 6.1) sowie für die Weiterentwicklung des Softwareprojekts (vgl. Kapitel 5) relevant sind Mehrsprachigkeit Eine der wichtigsten nichtfunktionalen Anforderungen war die Internationalisierung (engl. internationalization) der Softwarelösung, da die Papierversion des CLS bereits in mehreren Länderversionen vorlag. Oft wird für Internationalisierung auch der Begriff L18N verwendet, da sich im Englischen 18 Buchstaben zwischen L und N befinden. Für den Programmierer gilt es, im Sinne der L18N einige Aspekte zu beachten. Beispielsweise dürfen Beschreibungstexte nicht im Quelltext verankert sein. Stattdessen müssen sie durch Platzhalter (Variablen), welche erst zur Laufzeit durch die entsprechenden Übersetzungen ausgetauscht werden, realisiert sein. Weiterhin ist darauf zu achten, dass verschiedene Sprachen unterschiedlich viel Platz für die Darstellung der selben Information benötigen. Bei Nichtbeachtung der L18N in frühen Phasen der Softwarentwicklung, kann eine spätere Anpassung sehr teuer und aufwendig werden (vgl. McConnel, 1996).

44 Phasen der Software-Entwicklung Die Implementierungsphase 44 In einem zweiten Schritt erfolgt die Lokalisierung (engl. localization, L10N) der Softwarelösung. Idealerweise ist die Software so gestaltet, dass dieser Schritt vom Anwender selbst vorgenommen werden kann. Ausgehend von den in der Entwurfsphase (Kapitel 4.3) getroffenen Grundsatzentscheidungen, respektive der gewählten Programmiersprache (Kapitel 4.3.4), wurden die I18N sowie die L10N wie folgt realisiert. Politische, geografische oder kulturelle Regionen werden in Java durch Objekte der Klasse java.utils.locale repräsentiert. Diese haben eine Kennung aus Sprache und Land. Beispiele hierfür sind: de_de deutsch / Deutschland en_gb englisch / Großbritannien zh_cn chinesisch / China es_es spanisch / Spanien Die Internationalisierung sowie die Lokalisierung erfolgen unter Zuhilfenahme sogenannter Ressourcenbündel (engl. resource bundels) der Klasse java.util.resourcebundle. Hierbei handelt es sich um Textdateien, welche im /resources Ordner der Webanwendung liegen. Diese externen Quellen haben stets eine Form, wie sie in Listing 4 auszugsweise für die chinesische Version zu sehen ist. 1 menu_home= 主 页 menu_notloggedin = 仍 未 登 陆 3 menu_login = 登 陆 Listing 4: Ausschnitt der Datei messages_custom_zh.native Für jede Sprachversion gibt es mehrere Ressourcenbündel, die jeweils durch einen Basisnamen (eng. basename) und ihr Sprachkürzel gekennzeichnet sind. In JSF (Kapitel 4.3.4) kann eine solche Datei, wie in Listing 5 gezeigt, geladen werden. Die entsprechende locale wird in der User Session (Kapitel A.3.6.5) vorgehalten. 1 <f:view locale= #{UserSession.locale} > <f:loadbundle basename= messages_custom var= messages /> Listing 5: Laden eines Ressourcenbündels in JSF Anschließend kann direkt auf die enthaltenen Werte zugegriffen werden. 1 <s:link id= menuhomeid view= /home.xhtml value= #{messages.menu_home} /> Listing 6: Zugriff auf eine externe Ressource in JSF Die daraus resultierende Darstellung im Frontend zeigt Abbildung 25.

45 Phasen der Software-Entwicklung Die Implementierungsphase 45 Abbildung 25: Resultierende Ausgabe der Spracheinstellung Für die Realisierung der Mehrsprachigkeit im Backend wurde im Paket de.nzberlin. (vgl. Kapitel A.3.7) die Klasse MultiLanguage implementiert, welche die Methode getdisplaystring zur Verfügung stellt. Diese Methode kann, wie in Listing 7 gezeigt, verwendet werden. 1 MultiLanguage.getDisplayString( basename, key, new Object []{}, locale); Listing 7: Verwendung der Methode getdisplaystring Die Methode ist, wie in Listing 8 gezeigt, implementiert. 1 public static String getdisplaystring(string bundlename, String key, Object params[], Locale locale) { 3 String text = ; ResourceBundle bundle = ResourceBundle.getBundle(bundleName, locale, 5 getcurrentclassloader(params)); try{ 7 text = bundle.getstring(key); } catch (MissingResourceException e){ 9 text = Key + key + not found! ; } 11 if (text.trim().equals( #na# )) return ; 13 } return text; Listing 8: Implementierung der Methode getdisplaystring Der Nutzer der Anwendung hat die Möglichkeit, jederzeit die Sprache zu wechseln. Jedes der kleinen Fahnenicons in Abbildung 25 ist mit einer Aktion hinterlegt, wie sie in Listing 9 für die Deutschlandflagge zu sehen ist. Beim Klicken eines Links wird der JSF Lifecycle (vgl. Abbildung 22) durchlaufen. Es ändert sich die locale und das komplette Frontend wird in der gewählten Sprache ausgegeben. 1 <s:link id= Language_de value= Deutsch action= #{UserSession.setLocale( de )} style= padding:0px /> Listing 9: Actionlink in JSF zum Wechseln der Sprache

46 Phasen der Software-Entwicklung Die Implementierungsphase 46 Eine Beschränkung von Java ResourceBundles in Version 5 ist, dass nur Dateien im ISO Format gelesen werden können. Daher ist es notwendig, dass die in Landessprache geschriebenen Dateien (vgl. Listing 4) vor der Benutzung in das ISO Format übersetzt werden. Listing 10 zeigt, wie das Beispiel aus Listing 4 nach dieser Transformation aussieht. Die Aufgabe des Umschreibens übernimmt ein Apache Ant Task, wie er in Kapitel beschrieben ist. 1 menu_home= \u4e3b\u9875 menu_notloggedin = \u4ecd\u672a\u767b\u menu_login = \u767b\u9646 Listing 10: Ausschnitt der Datei messages_custom_zh.properties Authentifizierung Um die eindeutige Identität eines Nutzers festzustellen, ist es notwendig, dass sich dieser für die Verwendung am System anmeldet. Anhand der Anmeldung kann das System ermitteln, welche weiteren Informationen dem Nutzer zur Verfügung zu stellen sind. Der englische Begriff authentication umfasst zwei Schritte, die im Deutschen als Authentifizierung und Authentisierung bekannt sind. Im ersten Schritt authentisiert sich der Nutzer gegenüber dem System durch Eingabe seines Nutzernamens und eines Passwortes. Im zweiten Schritt identifiziert und authentifiziert das System den Nutzer anhand dieser Daten. Dieser Vorgang sowie der ermittelte weitere Systemablauf sind in Abbildung 26 zu sehen. Abbildung 26: Authentisierung am und Authentifizierung durch das System Wie in Kapitel beschrieben, wird während der Authentifizierung geprüft, ob der Nutzer Mozilla Firefox als Browser benutzt. Der Authentifizierungsvorgang wird durch die Session Bean Authenticator (Kapitel A.3.6.1) realisiert. Die in Java implementierte Methode zur Authentifizierung ist in Listing 25 zu sehen, welche sich im Anhang (Kapitel A.3.6.1) befindet.

47 Phasen der Software-Entwicklung Die Implementierungsphase Persistente Datenhaltung Wie in Kapitel beschrieben, ist es notwendig Daten zu persistieren, da sie sonst mit dem Ende der Laufzeit des Programms verloren gehen. Die Umsetzung der persistenten Datenhaltung geschieht in Abhängigkeit aller getroffener Entscheidungen während der Entwurfsphase (Kapitel 4.3) wie folgt: Zuerst muss der Persistenzkontext (engl. persistence context) für das Projekt konfiguriert werden. Diese Konfiguration wird in der/resources/meta-inf/persistence.xml (Listing 26, im Anhang Kapitel A.3.3.2) abgelegt und kann unter Zuhilfenahme von seam-gen (Kapitel 4.4.4) erzeugt werden. Sobald die Schnittstelle konfiguriert ist, kümmert sich ein sogenannter Entity Manager um die Datenverwaltung im Persistenzkontext. Einige der wichtigsten Methoden eines Entity Managers zeigt Listing 11. EntityManager em; 3 // Laden eines Objekts im Persistenzkontext 5 Questionnaire quest = (Questionnaire) em.createquery( select q from Questionnaire q where q.questid = questid ) 7.setParameter( questid, 1 ) 9.getSingleResult(); //Abspeichern eines Objekts im Persistenzkontext 11 em.persist(itemreply); 13 //Zusammenfügen (engl. merge) von Daten im Persistenzkontext em.merge(itemreply); 15 // Entfernen eines Objekts im Persistenzkontext 17 em.remove(itemreply) Listing 11: Interaktionen im Persistenzkontext mittels eines EntityManagers Verwendete Werkzeuge Neben den bereits in der Entwurfsphase verwendeten Werkzeugen, wie der Eclipse Entwicklungsumgebung inklusive Erweiterungen zur UML Modellierung, kamen in der Implementierung weitere Hilfsmittel zum Einsatz. Javadoc Javadoc ist ein Werkzeug zur automatischen HTML-Dokumentationserstellung aus

48 Phasen der Software-Entwicklung Die Implementierungsphase 48 Java Quelltexten. Diese müssen dafür mit speziellen Kommentaren versehen werden. Sobald Javadoc gestartet wird, parst es die angegebenen Quelltexte nach Javadoc Kommentaren. Innerhalb dieser Kommentare befinden sich sogenannte Javadoc Tags. Einige Beispiele für solche Tags sind in Tabelle 5 dargestellt. Tag und @return Ausgabe Name des Autors Versionsnummer Querverweis aus anderen Eintrag in der Dokumentation Beschreibung der erwarteten Parameter einer Methode Beschreibung des Rückgabewertes einer Methode Tabelle 5: Beispiele für Javadoc Tags Die Verwendung solcher Tags zeigt Listing 12 am Beispiel einer Methode. 1 /** * This is a very small helper function to test whether an Item handed to this function is 3 * of a specific type. The <i>item</i> that should be tested 5 Returns true if the <i>item</i> is a MetricItem, else returns false */ 7 public boolean ismetricitem(item item){ 9 return item instanceof MetricItem ; } Listing 12: Verwendung von Javadoc Tags im Quelltext Javadoc generiert aus dem in Listing 12 dargestellten Quelltext die in Abbildung 27 zu sehende HTML Ausgabe. Abbildung 27: Von Javadoc generiertes HTML seam-gen Die Distribution von jboss Seam (vgl. Kapitel 4.3.6) beinhaltet ein Kommandozeilenwerkzeug, welches beim Einrichten eines Projekts für die Eclipse oder NetBeans Ent-

49 Phasen der Software-Entwicklung Die Implementierungsphase 49 wicklungsumgebung unterstützt. Dies umfasst unter anderem folgende Operationen: Erfassen aller notwendigen Informationen Zusammenstellen der benötigten Bibliotheken Anlegen der benötigten Konfigurationsdateien Anlegen einer Verzeichnisstruktur für ein Java EE Projekt Die Verwendung des Werkzeugs geschieht in zwei Schritten. Im ersten Schritt werden alle benötigten Informationen vom Nutzer abgefragt und in einer Konfigurationsdatei (seam-gen/build.properties) abgelegt. Die für diese Arbeit vorgenommene Konfiguration zeigt Listing 27 (im Anhang Kapitel A.3.3.3). Im zweiten Schritt werden alle in der Konfigurationsdatei festgehaltenen Informationen genutzt, um daraus das gewünschte Projekt zu generieren. Dazu wird in der Kommandozeile das Programm seam mit dem Parameter create-project gestartet. Listing 28 im Anhang (Kapitel A.3.3.3) zeigt die Ausgabe des Programms. Anschließend kann das erzeugte Projekt in Eclipse importiert werden und die eigentliche Softwareimplementierung beginnen. Zu den generierten Konfigurationsdateien gehört eine build.xml für das Werkzeug Apache Ant, welches es im nächsten Abschnitt beschrieben ist. Apache Ant Bei Apache Ant 22 handelt es sich um ein javabasiertes Build-Tool. Es unterstützt beim Zusammenstellen aller Quelltexte, benötigter Bibliotheken und anderer Daten (wie z.b. Bildern) zu einem installierbaren Softwarepaket. Konfiguriert und gesteuert wird Ant durch eine XML Datei (build.xml), welche sogenannte Ziele (engl. targets) definiert. Targets können Abhängigkeiten untereinander besitzen, welche beim Ausführen zuerst automatisch aufgelöst werden. Ein Target beinhaltet den Aufruf von ein oder mehreren Aufgaben (engl. tasks). Ein Beispiel eines solchen Targets und den dazugehörigen Tasks zeigt Listing <target name= deploy depends= archive,datasource description= Deploy to JBoss AS > 3 <fail unless= jboss.home >jboss.home not set</fail> 5 </target> <copy todir= ${deploy.dir} file= ${dist.dir}/${project.name}.ear /> Listing 13: Beispiel eines Ant Targets Das Target deploy hat Abhängigkeiten zu den Targets archive und datasource. Im 22 Akronym für Another neat Tool (zu Deutsch: Ein weiteres nettes Werkzeug)

50 Phasen der Software-Entwicklung Die Abnahme- und Einführungsphase 50 ersten Task wird überprüft, ob das Verzeichnis, in dem der jboss Applikationsserver installiert ist, gesetzt wurde. Sollte es nicht gesetzt sein, bricht der Task mit einer Fehlermeldung ab. Im zweiten Task wird das im Target archive gebaute Enterprise Archive (EAR) in das definierte Deployverzeichnis auf dem jboss kopiert. Im Rahmen dieser Arbeit wurde die build.xml unter anderem für das Überführen von landesspezifischen Sprachdateien ins ASCII Format erweitert (vgl. Kapitel Listing 14). 1 <native2ascii encoding= UTF-8 src= resources dest= resources includes= **/*.native ext=.properties /> Listing 14: Ant Task zum Überführen von UTF Dateien ins ASCII Format Die vollständige Realisierung der Mehrsprachigkeit ist in Kapitel beschrieben. 4.5 Die Abnahme- und Einführungsphase Ziel der Abnahme- und Einführungsphase ist es, dass das fertige Softwareprodukt vom Kunden abgenommen und in Betrieb genommen wird. Der Verlauf sowie die beteiligten Personen dieser Phase sind in Abbildung 28 schematisch dargestellt. Abbildung 28: Abnahme- und Einführungsprozess (Balzert, 2000) Ein Installationsentwickler, wie er in der Abbildung zu sehen ist, kommt vor allem bei sehr umfangreichen Entwicklungen zum Einsatz. Die Übergabe der Basisversion, welche die Onlineumsetzung der CLS (Kapitel 2.4.5) umfasst, erfolgte nach der Durchführung eines Abnahmetests. Ein solcher Abnahmetest wird vom Auftraggeber ausgearbeitet und bietet die Möglichkeit zu überprüfen, ob alle festgehaltenen Anforderungen nach seinen Wünschen umgesetzt wurden. Das Ergebnis der Abnahmephase ist ein Abnahmeprotokoll sowie die formale Abnahme des Produkts durch den Auftraggeber.

51 Phasen der Software-Entwicklung Die Wartungs- und Pflegephase Die Wartungs- und Pflegephase Nach der Produkteinführung beginnt die Wartungs- und Pflegephase. Im produktiven Einsatz der Softwarelösung können Fehler auftreten, die von keinem Testszenario aufgedeckt wurden. Nach Grady (1992) kommt pro zehn während Tests gefundener Fehler ein Fehler hinzu, der erst nach der Freigabe entdeckt wird. Darüber hinaus können sich neue Wünsche oder Anforderungen ergeben, die sich im Betrieb der Software herausgestellt haben: Im Fall der entwickelten Basisversion etwa der Umgang mit der Authentifizierung am System (vgl. Kapitel 5.4.5). Nach Balzert (2000) lassen sich 4 Kategorien der Wartung und Pflege unterscheiden, welche nach korrektiven und progressiven Tätigkeiten unterteilt sind: Korrektive Tätigkeiten Stabilisierung / Korrektur Optimierung / Leistungsverbesserung Progressive Tätigkeiten Anpassung / Änderung Erweiterung. Abbildung 29 zeigt die prozentuale Verteilung dieser Aktivitäten. Abbildung 29: Aufwandsverteilung von Wartung und Pflege (Balzert, 2000) Die 62% Erweiterungen und Anpassungen (Abbildung 29) beziehen sich nicht auf die von vornherein geplanten inkrementellen Ausbaustufen, sondern ausschließlich auf Änderungsarbeiten an der Basisversion.

52 Anwendung der WDP für die CLS-IA Interaktionsformen 52 5 Anwendung der webbasierten Diagnoseplattform für die CLS mit interaktiven Szenarien (CLS-IA) Nach der Einführung der Basisversion wurde eine Onlineerhebung der CLS mit ca. 140 Teilnehmern durchgeführt. Die Versuchspersonen wurden über den institutseigenen Psychologischen Experimental-Server Adlershof (PESA) rekrutiert. Die mit der Webanwendung gewonnenen Ergebnisse decken sich mit den von Sengpiel und Dittberner (2008) beschriebenen Resultaten (vgl. Kapitel 2.4.5). Die CLS wurde ursprünglich für die Erfassung der Computer Literacy älterer Versuchspersonen entworfen. Da die über PESA rekrutierten Versuchspersonen mittleren Alters waren, schnitten fast alle Teilnehmer mit einem hohen bis sehr hohen CLS-Score ab. Um den Anwendungsbereich der CLS auf alle Altersgruppen zu erweitern, planen Sengpiel und Dittberner (2008) die Erweiterung der CLS-ST um schwerere Items. Bereits die in der Basisversion verwendete Softwarelösung beschleunigt diese Weiterentwicklung in hohem Maße. Neue Items können online in hoher Frequenz und ausreichend großer Stichprobe getestet werden. Sengpiel und Dittberner (2008) beschreiben weiterhin eine Beschränkung der CLS auf deklaratives Wissen: As of now, the CLS tests only declarative knowledge of symbols and terms, while the procedural knowledge of interaction patterns may have an equally important influence on participants performance. (Sengpiel, M. & Dittberner, D., 2008, S. 9). Dieser Teil der Arbeit beschreibt daher die Erweiterung der CLS um einen interaktiven Teil (CLS- IA) in Szenarioform. Bevor entsprechende Szenarien entwickelt werden können, ist es notwendig, einen Überblick über vorhandene Interaktionsformen und Interaktionselemente (Widgets) zu erarbeiten. In den Kapiteln 5.1 und 5.2 werden zu diesem Zweck die benötigten Grundlagen erläutert. Anschließend wird in Kapitel 5.3 die Aggregation von Interaktionsaufgaben in Szenarien beschrieben, bevor in Kapitel 5.4 auf den Entwurf und die Implementierung dieser eingegangen wird. Abschließend werden in Kapitel 5.5 auf das Testen sowie eine erste empirische Phase im Umgang mit der neu entwickelten CLS-IA eingegangen. 5.1 Interaktionsformen Interaktionsformen beschreiben Wege zum Lösen einer Interaktionsaufgabe (vgl. Kapitel 2.1.3). Im folgenden Abschnitt werden die wichtigsten Interaktionsformen genannt. Als Basis dient folgende Definition: Interaktionsformen sind stereotype Abläufe zur Ein- und Ausgabe von Informationen, die Eingabe- mit Ausgabetechniken in definierten Abfolgebedingungen verknüpfen. (Herczeg, 2006, S. 101).

53 Anwendung der WDP für die CLS-IA Interaktionsformen 53 Nach Herczeg (2006) lassen sich grundsätzlich zwei Arten von Interaktionen unterscheiden, deskriptive und deiktische. Darüber hinaus sind hybride Formen möglich. Die zwei Hauptarten lassen sich wie folgt kategorisieren (Abbildung 30). Abbildung 30: Klassifizierung von Interaktionsformen (nach Herczeg, 2006) Deskriptive Interaktionsformen Grundlage dieser Form der Interaktion sind sprachliche Beschreibungen. Hierfür können sowohl Symbole, natürliche als auch formale Sprachen zum Einsatz kommen. Allen deskriptiven Interaktionsformen ist gemein, dass sie eine erhöhte Gedächtnisleistung bei der Eingabe erfordern: Benötigt wird hier vor allem das sogenannte Recall-Memory, das freie Erinnern. Dieses Problem kann durch diverse Unterstützungsfunktionen gemildert, jedoch nie völlig beseitigt werden. (Herczeg, 2006, S. 102). Symbole Symbole repräsentieren beliebige Objekte, Operatoren (Funktionen) oder auch ganze Operationen (Kommandos, Befehle). (Herczeg, 2006, S. 103). Symbole lassen keine Rückschlüsse auf die Komplexität der hinterlegten Funktion zu. Bei Eingaben mit einer Tastatur können beliebige Tasten oder Tastenkombinationen als Symbole verwendet werden. Häufig zum Einsatz kommen neutral beschriftete Funktionstasten (F1 bis F12), welche im Gegensatz zu den symbolisch beschrifteten Funktionstasten (vgl. Kapitel 5.1.2) stehen. Formale Sprachen Formale Sprachen erweitern die Verwendung von Symbolen zu Sprachen. (Herczeg, 2006, S. 104). Über einer Menge von Symbolen wird mittels einer kontextfreien Grammatik eine Sprache definiert. Die Kommandosprachen gehören zu den ersten Interaktionsformen (vgl. Hix & Hartson, 1993). Formale Sprachen müssen vom Nutzer erlernt werden und stellen bei Beherrschung eine sehr effiziente Methode dar, mit einem System zu kommunizieren. Nach Herczeg (2006) sind die wichtigsten formalen Sprachen die Programmiersprachen: Programmiersprachen erlauben die Beschreibung komplexer sequentieller, iterativer, bedingter und paralleler Abfolgen von Aktionen und sind dadurch sehr mächtige Interaktionsformen für praktisch alle Problemstellungen, die

54 Anwendung der WDP für die CLS-IA Interaktionsformen 54 heute mit Computern zu lösen sind. (Herczeg, 2006, S. 104). Der sehr hohe Lernaufwand sowie die konsequente Ausrichtung auf Effizienz prädestiniert diese Interaktionsform für Benutzer mit einer sehr hohen CL, sogenannte Experten. Natürliche Sprachen Seit Beginn der Computerentwicklung versucht man Systeme zu entwickeln, mit denen sich Benutzer in ihrer gewohnten Umgangs- oder Fachsprache unterhalten können. (Herczeg, 2006, S. 105). Da diese Form der Interaktion von der gewohnten Sprache des Menschen ausgeht, erfordert sie keinen zusätzlichen Lernaufwand. Besonders für Nutzer mit einer geringen CL, sogenannte Gelegenheitsnutzer oder Anfänger, sind natürliche Sprachen geeignet. Interessante Anwendungsgebiete sind: Hilfe- und Auskunftssysteme sowie Spracheingabe für Autonavigation und Telefonie Deiktische Interaktionsformen Interaktionsformen, die auf der Grundlage von Selektionen mittels Zeigehandlungen entstehen, werden als deiktische Interaktionsformen bezeichnet. Im Gegensatz zu den deskriptiven Interaktionsformen wird bei den deiktischen das Wiedererkennungsgedächtnis (Recognition-Memory) gefordert. Durch die angebotene Auswahl wird die kognitve Last des Nutzers deutlich gesenkt. Beispiele für deiktische Interaktiosformen sind: Icons, Menüs, beschriftete Funktionstasten, metaphorische Interaktionsformen. Icons Nach ISO (2000) wird ein Icon wie folgt definiert: Graphic displayed on the screen of a visual display that represents a function of the computer system. (ISO , 2000, S. 2). Im Sprachgebrauch werden Icons oft mit Piktogrammen gleichgesetzt. Icons zählen zu den aktiven Interaktionsformen mit Interaktionsverhalten, wohingegen es sich bei Piktogrammen um passive abstrakte Bilder/ Darstellungen handelt. Icons werden häufig in Menüs oder für Schalter benutzt. Menüs Menüs bieten dem Anwender die Möglichkeit, mittels Auswahl- oder Zeigehandlung aus einer vordefinierten Menge an Optionen zu wählen. Durch die bereits vorgegebenen Möglichkeiten ist das Auftreten von Syntaxfehlern ausgeschlossen, was sie auch für Nutzer mit einer geringen bis sehr geringen CL zugänglich macht: Menüs stellen eine natürliche und intuitive Form der Interaktion dar, die schnell verstanden und automatisiert wird und daher vor allem gut für unerfahrene Benutzer oder Gelegenheitsbenutzer verwendbar ist (Herczeg, 2006, S.109). Problematisch ist die Strukturierung von Menüs, welche maßgeblich dazu beiträgt, wie schnell ein Menüeintrag gefunden wird.

55 Anwendung der WDP für die CLS-IA Interaktionsformen 55 Sehr oft genutze Menüeinträge können darüber hinaus in sogenannten Werkzeugleisten (Toolbars) zusammengefaßt werden, wo sie als Icons dargestellt werden. Diese Leisten sind oft durch den Nutzer anpassbar. Nachteilig an Menüs ist, dass sie viel Platz auf dem Bildschirm benötigen und die Auswahl zeitaufwendiger als z.b. die Verwendung von Funktionstasten ist. Die Auswahl in Menüs kann für Nutzer mit höherer CL durch die Verwendung von Mnemoniks beschleunigt werden. Mnemoniks werden durch Unterstreichung gekennzeichnet und erlauben die Auswahl des Menüeintrags durch Tastatureingabe, z.b. Datei. Beschriftete Funktionstasten Beschriftete Funktionstasten zeichnen sich dadurch aus, dass sie eindeutig und anwendungsbezogen beschriftet sind. Im Gegensatz zu den symbolisch beschrifteten Funktionstasten wird ein klassisches Menü abgebildet. Einige Anwendungen, wie z.b. Final Cut 23, haben einen so großen Funktionsumfang, dass es Tastaturen mit beschrifteten Funktionstasten gibt. Ein solches Beispiel zeigt Abbildung 31. Abbildung 31: Bella Pro Series Video Editing Keyboard 3.0 FCP (Bella, 2008) Ähnlich wie bei den Menüs besteht praktisch keine Gefahr der syntaktisch falschen Eingabe. Dafür ist eine Auswahl weit schneller möglich sowie unabhängig vom aktuellen Dialog- und Bildschirmzustand. Metaphorische Interaktionsformen Mit sogenannten metaphorischen Interaktionsformen wird auf dem Bildschirm die physikalische Arbeitsumgebung eines Anwendungsbereichs nachgebildet, man könnte auch sagen, verbildlicht (Herczeg, 2006, S. 112). Diese Form der Interaktion ist sehr eng an das Dialogprinzip der direkten Manipulation geknüpft, welches wie folgt definiert werden kann: A dialogue technique by which the user has the impression of acting directly on objects on the screen; e.g., by pointing at them, moving them and/or changing their physical characteristics (or values) via the use of an input device. (ISO , 2000, S. 2). Dazu gehört, dass die Auswirkungen dieser Manipulation sofort sichtbar sind. Diese ständige Rückmeldung über den Systemzustand und alle Arbeitsobjekte wird auch als WYSIWYG-Prinzip (What You See Is What You Get) bezeichnet. Grundlage 23 kommerzielles Video- und Filmschnittprogramm der Firma Apple

56 Anwendung der WDP für die CLS-IA Interaktionselemente (Widgets) 56 direkt manipulierbarer Systeme sind nach Herczeg (2006) folgende Basisinteraktionsformen: Selektieren von Objekten und Objektmengen Verschieben von Selektionen (Drag&Drop) Verschieben von Selektionen in den Abfalleimer (Löschen) Ausschneiden und Einfügen von Selektionen (Cut&Paste) sowie Kopieren und Einfügen von Selektionen (Copy&Paste) Hybride Interaktionsformen Um die Vorzüge deskriptiver und deiktischer Interaktionsformen zu nutzen, werden oftmals Mischformen verwendet. Diese Mischformen entstehen durch hierarchisches Zusammensetzen. Beispiele nach Herczeg (2006) sind Formulare und Propertiesheets. 5.2 Interaktionselemente (Widgets) Nach Brad Myers (1990) handelt es sich bei Widgets allgemein um low-level Techniken zur Bedienung von Eingabegeräten zur Steuerung von Computern. Myers bezeichnet diese auch als Interaktionstechnik oder -gerät. In der Informatik werden unter Widgets kleine Interaktionsobjekte verstanden, welche Bearbeitungs- oder Eingabeaufgaben erfüllen. Klassische Beispiele für Widgets sind Buttons, Menüs, Scrollbars, Text- oder- Zahleneingabefelder sowie Listenauswahlelemente. Alternative technische Begriffe für Widgets sind beispielsweise Objects oder Controls. Essentiell für eine umfassende und ausgeglichene Erhebung ist ein allgemeiner, möglichst vollständiger Überblick über die verfügbaren Interaktionselemente der Human Computer Interaction (HCI). Ausgiebige Untersuchungen auf diesem Gebiet wurden bereits im Jahre 1990 durch Brad Myers durchgeführt. In einer Videodokumentation wird chronologisch festgehalten, welche verschiedenen Tastatur- und Mauseingabeoperationen existieren und wie sich diese historisch entwickelt haben. Myers untersuchte 30 verschiedene Systeme, die sich an 16 Universitäten und Unternehmen im Einsatz befanden. Seit Myers Arbeit haben sich sowohl die Computer, als auch die Möglichkeiten der Informationsein und -ausgabe weiterentwickelt. Grundlage dieser Arbeit ist daher eine neuere Veröffentlichung des World Wide Web Consortium (W3C). Aus dem Klassendiagramm für Accessible Rich Internet Applications (ARIA) wurde in dieser Arbeit eine Taxonomie von Widgets abgeleitet. ARIA wird von der Web Accessibility Initiative (WAI) vorangetrieben. Die technische Spezifikation WAI-ARIA befindet sich derzeit im Entwurfsstadium und wird voraussichtlich noch im Laufe dieses Jahres ein empfohlener Webstandard des W3C. Es handelt sich hierbei um eine rein semantische Erweiterung des HTML 5 Standards.

57 Anwendung der WDP für die CLS-IA Interaktionselemente (Widgets) 57 Widgets repräsentieren eine Position im Rollenkonzept dieses Standards. Eine schematische Darstellung der erarbeiteten Taxonomie findet sich in Abbildung 32. Widget Composite Progressbar Input Link Button Gridcell Tab Checkbox MenuItem Textbox Range Option Select Menu Listbox Combobox Tree Radiogroup Slider Spinbutton Radio Legende MenuItem Radio MenuItem Checkbox TreeItem A B B implementiert Rolle A A B B ist Kindelement von A Abbildung 32: Abgeleitete Taxonomie von Widgets Darüber hinaus existieren komplexere Widgets, die entweder durch Komposition oder Abwandlung der Standardwidgets entstanden sind. Vor allem das Web 2.0 Umfeld brachte viele neue Widgets hervor. Die meisten zur Erhebung der Computer Literacy einer Versuchsperson (VP) relevanten Widgets lassen sich unter der Klasse Input gruppieren. Solche Widgets bieten der VP die Möglichkeit der Eingabe und somit zur Interaktion mit dem System. Die wichtigsten Elemente dieser Klasse werden im Folgenden genannt, beschrieben und bildlich dargestellt Select Alle zur Klasse Select gehörigen Widgets bieten dem Nutzer die Möglichkeit, eine oder mehrere Selektionen aus einer Reihe von Auswahlmöglichkeiten zu treffen. Jedes Selectwidget muss daher mindestens ein Optionelement oder Kinder, die ein solches beinhalten, umschließen. Kinder dieser Art sind: Listbox, Combobox, Radiogroup, Menu und Tree. Listbox Eine Listbox implementiert ein Widget, welches der VP erlaubt, eines oder mehrere Items aus einer Auswahlliste zu selektieren. Die Items in einer Liste sind statisch und können Bilder beinhalten.

58 Anwendung der WDP für die CLS-IA Interaktionselemente (Widgets) 58 Abbildung 33: Beispielhafte Präsentation einer Listbox (MSDN, 2008) Combobox Die Umsetzung als Combobox erlaubt es der VP zusätzlich, die gewünschte Auswahl per Tastatur einzugeben. Eine Combobox ist eine Kombination aus einer einzeiligen Textbox und einem Drop-Down Selectwidget. Darüber hinaus kann eine Combobox editierbar sein. Diese Eigenschaft wird typischerweise genutzt, wenn ein autocomplete Verhalten gewünscht ist. Autocomplete bedeutet, dass Eingaben der VP automatisch vervollständigt werden. Alle möglichen Alternativen werden aufgrund der bisher eingegebenen Anfangsbuchstaben vorhergesagt. Abbildung 34: Beispielhafte Präsentation einer Combobox (MSDN, 2008) Radiogroup Hierbei handelt es sich um eine Gruppe von Radiobuttons. Die Besonderheit dieser Präsentationsform besteht darin, dass immer nur eine Auswahl zur gleichen Zeit aktiv sein kann. Bei Selektion eines weiteren Items, wird die vorherige Auswahl gelöscht. Der Name Radiobutton leitet sich vom Verhalten ab. Ähnlich den Stationstasten zur Senderwahl an älteren Radiogeräten, springt die Taste des bisher gewählten Senders heraus, sobald eine neue Taste gedrückt wird. Abbildung 35: Beispielhafte Präsentation einer Radiogroup (Java2s, 2008)

59 Anwendung der WDP für die CLS-IA Interaktionselemente (Widgets) 59 Menü Menüpräsentationen bieten der VP eine Liste von Möglichkeiten. In Webanwendungen beinhalten Menüs Links zu wichtigen Sektionen einer Seite oder zu anderen Dokumenten. Abbildung 36: Beispielhafte Präsentation eines Menüs (gtkmm, 2008) Tree Diese Präsentationsform stellt eine Liste mit Auswahlmöglichkeiten zur Verfügung, die eine hierarchische Struktur erlaubt. Die wörtliche Übersetzung Baum deutet bereits auf die Beschaffenheit dieser Darstellungsmöglichkeit hin. Teilbäume in der Liste können aus Gründen der Übersichtlichkeit minimiert und maximiert, d.h. ausgeblendet und wieder sichtbar gemacht werden. Abbildung 37: Beispielhafte Präsentation eines Trees (dhtmlx, 2008) Checkbox Checkboxwidgets unterstützen prinzipiell 3 Zustände: true, false oder mixed. Der mixed Wert wurde eingeführt, um Anwendungen wie z.b. Installationsprogramme zu unterstützen, bei denen ein Teil einer gewählten Option installiert werden soll. In den meisten Fällen wird eine Checkbox jedoch als Widget mit booleschem Wert gebraucht. Abbildung 38: Beispielhafte Präsentation von Checkboxen (Java2s, 2008)

60 Anwendung der WDP für die CLS-IA Interaktionselemente (Widgets) Textbox Textboxen sind Inputwidgets, welche der VP die Eingabe von Freitext erlauben. Sie können ein- sowie auch mehrzeilig sein. Mehrzeilige Textboxen werden als Textareas bezeichnet. Textboxen sind in der Realität oft mit sogenannten Callouts hinterlegt. Ein Callout startet einen externen Vorgang, der zum Befüllen der Textbox mit Inhalt dient. Hierbei kann es sich um eine einfache Eingabemaske oder eine beliebig komplexe Anwendung handeln. Nachdem der Eingabewert im externen Kontext ausgewählt wurde, wird der Wert zurück in die Textbox geschrieben. In einem der entwickelten Szenarien (Kapitel 5.3.3) wird eine Textbox verwendet, welche mit einem Kalender-Callout (Abbildung 52) hinterlegt ist. Abbildung 39: Beispielhafte Präsentation einer Textbox (codeproject, 2008) Range Widgets dieser Klasse bilden einen Bereich von Werten ab. Sie verfügen über einen minimalen, maximalen sowie einen aktuellen Wert. Zwei Repräsentationsformen zum Einstellen eines Bereichs sind Slider und Spinbuttons. Ein Slider ist eine meist grafische Darstellung eines Bereichs (Abbildung 40). Anhand der Größe des Sliders lässt sich der einstellbare Bereich mit seinem Maximal- und Minimalwert ablesen. Der Zeiger auf dem Slider gibt den aktuell eingestellten Wert an. Oft gehört zur grafischen Umsetzung eine Textbox, in welcher der aktuelle Wert abgetragen wird. Abbildung 40: Beispielhafte Präsentation eines Range als Slider (dhtmlx, 2008) Die Umsetzung als Spinbutton ermöglicht die Auswahl aus einer Menge diskreter Werte. Die VP hat die Möglichkeit, über Hoch- und Runterbuttons den gewünschten Wert einzustellen. In barrierefreien Anwendungen wird zusätzlich die Eingabe über die Cursortasten der Tastatur unterstützt. Abbildung 41: Beispielhafte Präsentation eines Range als Spinbutton (laas02, 2008)

61 Anwendung der WDP für die CLS-IA Aggregation von Interaktionsaufgaben Menüelement (MenuItem) Diese Art von Inputwidgets repräsentieren das Optionelement in Menüs und können kontextabhängig ausgegraut sein. Jedes Menüitem kann ein neues Submenü verkörpern. Menüitems kommen sowohl mit Checkbox- wie auch mit Radioverhalten vor. Hierbei ist entweder eine Mehrfachauswahl möglich oder eine Einfachauswahl zwingend notwendig. Das Verhalten ergibt sich aus der Rollenverwandtheit zu Checkboxen oder Radios, wie aus der Taxonomie (Abbildung 32) ableitbar ist. Abbildung 42: Beispielhafte Präsentation von Menuitems (Java2s, 2008) Hybride Widgets Aus den genannten Basiswidgets lassen sich nahezu beliebig viele neue Widgets zusammensetzen. In den letzten Jahren wurden für das Internet konzipierte Applikationen regulären Desktopanwendungen immer ähnlicher. Viele Konzepte, die vorerst nur lokalen Fat oder Rich Clients 24 vorbehalten waren, wurden auf Webanwendungen ausgeweitet. Auch aus Programmierersicht haben viele Entwicklungen stattgefunden, die eine schnelle und komfortable Entwicklung neuer Widgets ermöglichen. 5.3 Aggregation von Interaktionsaufgaben in Szenarien Die zusammengetragenen Interaktionsformen und Widgets werden in interaktiven Arbeitsproben (Szenarien) getestet. Die bewusste Entscheidung dafür hatte mehrere Gründe. Durch Arbeitsproben, die bezüglich ihrer Aufgabeninhalte sowie der Testsituation den Aufgaben im Alltag der Versuchsperson sehr nahe kommen, ergibt sich eine hohe Augenscheinvalidität. Die in den Szenarien arrangierten Interaktionsaufgaben sind direkter Bestandteil funktionaler Computer Literacy (vgl. Kapitel 2.3). Darüber hinaus wird ein exploratives Verhalten der Versuchsperson gefördert sowie die Motivation zum vollständigen Abschließen des Test erhöht. Der Prozess der Planung und Aggregation solcher Szenarien wird in den folgenden Kapiteln aus fachlicher Sicht beschrieben. In Bezug zu den Phasen einer Software-Entwicklung handelt es sich um die Planungs- und Definitionsphase (vgl. Kapitel 4.1 und 4.2). Vorerst werden vor allem Interaktionsformen deiktischer Natur getestet, da sie durch meist eingeschränkte Auswahlmöglichkeiten eine geringere Computer Literacy erfordern und technisch leichter umzusetzen sind. 24 Lokal ausgeführtes Computerprogramm, welches zumeist auch die grafische Benutzeroberfläche bereitstellt

62 Anwendung der WDP für die CLS-IA Aggregation von Interaktionsaufgaben Szenario 1 - Selektion von Objekten und Objektmengen In diesem Szenario werden einige der deiktischen Basisinteraktionen (vgl. Kapitel 5.1.2) getestet, welche nach Herczeg (2006) im Umgang mit direkt manipulierbaren Systemen notwendig sind. Im Speziellen werden metaphorische Interaktionen untersucht, die sich auf das Selektieren von Objekten und Objektmengen beziehen. Diese sind: Selektion eines einzelnen Objekts Durch Anklicken des Objekts Durch Ziehen einer Selektionsmaske mit der Maus Selektion einer Objektmenge Durch Anklicken und gleichzeitiges Drücken der SHIFT Taste Durch Anklicken und gleichzeitiges Drücken der CTRL Taste Durch Ziehen einer Selektionsmaske mit der Maus Auswahl aller Objekte Durch Drücken von CTRL-A oder A Über den Menüeintrag Select All Der Testperson wird zu diesem Zweck eine generische Arbeitsumgebung dargeboten, wie sie in Abbildung 43 dargestellt ist. Abbildung 43: Abbildung Szenario 1 zur Erfassung deiktischer Interaktionen Die Abbildung zeigt das Szenario in einem Zustand, in dem bereits alle Interaktionsaufgaben erfolgreich gelöst wurden. Zu sehen ist ein Betriebssystemfenster. Dieses enthält

63 Anwendung der WDP für die CLS-IA Aggregation von Interaktionsaufgaben 63 neun Ordner, die in einer Matrix von A1 bis C3 angeordnet sind. Auf der linken Seite des Arbeitsbereichs befinden sich die Instruktionen zur jeweiligen Teilaufgabe. Auf der rechten Seite wird sofortiges Feedback über jede erkannte Interaktion gegeben. Der Button mit der Beschriftung Alternative sorgt dafür, dass die aktuell vorgenommene Selektion aufgehoben und das System damit in seinen ursprünglichen Zustand zurück versetzt wird. Der Button Weiter gibt der Versuchsperson die Möglichkeit zur nächsten Teilaufgabe zu springen, sobald keine alternativen Lösungswege mehr bekannt sind. Der mit Fertig beschriftete Button kann jederzeit betätigt und somit das komplette Szenario beendet werden. Durch die Auslösung dieser Aktion werden die Daten aller bisher erfassten Items an die Diagnoseplattform gesendet. Das Szenario besteht aus vier Teilaufgaben, die nachfolgend beschrieben sind. Aufgabe 1 Zunächst wird die Versuchsperson aufgefordert, nur den Ordner B2 auszuwählen zu selektieren. Im Szenario sind zwei mögliche Lösungswege implementiert. Zum Einen kann der Ordner durch Anklicken selektiert werden und zum Anderen ist es möglich, eine Selektion durch Ziehen einer Auswahlmaske mit der Maus zu erreichen. In Abbildung 44 sind beide Lösungsmöglichkeiten bildlich dargestellt. Abbildung 44: Alternative Möglichkeiten zur Selektion eines Objekts Aufgabe 2 In der zweiten Aufgabe wird der Nutzer instruiert, alle Ordner der zweiten Reihe zu selektieren B1, B2 und Ordner B3. Zum Erreichen dieses Ziels sind folgende Möglichkeiten hinterlegt. Die erste Möglichkeit ist die bereits aus Aufgabe 1 bekannte Lösung durch Ziehen einer Selektionsmaske. Diese Interaktion wird in dieser Aufgabe ein weiteres mal geprüft, da sie im Kontext der Mehrfachauswahl geläufiger ist. Die zweite Lösungsmöglichkeit beinhaltet das Nutzen der SHIFT Taste. Hierzu wählt die Versuchsperson zuerst Ordner B1 aus. Anschließend wird bei gehaltener SHIFT Taste Ordner B3 angeklickt. Alternativ kann auch erst Ordner B3 und dann B1 unter zusätzlicher Nutzung der SHIFT Taste selektiert werden. Die letzte hinterlegte Möglichkeit ist die Mehrfachauswahl unter Zuhilfenahme der CTRL-Taste. Aufgabe 3 Da die Verwendung der CTRL-Taste für die Selektion benachbarter Objekte nicht

64 Anwendung der WDP für die CLS-IA Aggregation von Interaktionsaufgaben 64 zwingend notwendig ist, wird in dieser Aufgabe die Verwendung dieser Funktion forciert. Ohne den Einsatz der CTRL-Taste ist die Aufgabe nicht lösbar. In der Instruktion wird der Nutzer gebeten, die Ordner A1, B2 sowie C3 zu selektieren. Durch die speziell gestellte Instruktion wird ein exploratives Verhalten der Versuchsperson zusätzlich gefördert. Auch den Teilnehmern, denen die Verwendung der CTRL-Taste in Aufgabe 2 nicht einfiel oder denen es nicht zweckmäßig erschien, werden hier explizit danach gefragt. Aufgabe 4 In der letzten Aufgabe werden Mechanismen abgefragt, mit denen alle dargebotenen Objekte selektiert werden können. Hierzu sind zwei Lösungswege hinterlegt, die in den anderen drei Aufgagen nicht überprüft wurden. Eine Möglichkeit ist die Tastenkombination CTRL-A. Alternativ wird auf Macintosh-Systemen die Tastenkombination A (Command Key + A) unterstützt. Die zweite Möglichkeit ist wiederum das Ziehen einer Auswahl mit der Maus Szenario 2 - Kopieren, Einfügen, Löschen Im zweiten Szenario werden weitere deiktische Interaktionsformen nach Herczeg (2006) erfasst. Diese sind: Verschieben von Selektionen (Drag & Drop) Verschieben von Selektionen in den Abfalleimer (Löschen) Kopieren und Einfügen von Selektionen (Copy &Paste) Die von Herczeg beschriebene Interaktion, Ausschneiden und Einfügen von Selektionen (Cut & Paste), wird hier nicht geprüft. Sie ist aus technischer wie psychologischer Sicht sehr eng verwandt mit Copy & Paste. Die abprüfbaren Interaktionen sind im Detail mit folgenden Handlungsabläufen im Szenario hinterlegt: Löschen eines selektierten Objekts oder einer selektierten Objektmenge Durch Rechtsklick auf die Auswahl und Delete im Kontextmenü Über den Menüeintrag Delete Durch Ziehen der Auswahl auf das Mülleimersymbol Durch Selektion von Objekten und Drücken der DEL-Taste Durch X oder CTRL-X (ohne Paste) Kopieren einer Selektion in die Zwischenablage Über den Menüeintrag Copy Durch Rechtsklick auf die Auswahl und Copy im Kontextmenü

65 Anwendung der WDP für die CLS-IA Aggregation von Interaktionsaufgaben 65 Durch Tastenkombination CTRL-C oder C bei getätigter Selektion Einfügen einer Selektion aus der Zwischenablage Über den Menüeintrag Paste Durch Rechtsklick auf die Auswahl und Paste im Kontextmenü Durch Tastenkombination CTRL-V oder V und getätigter Selektion Kopieren einer Auswahl durch Drag & Drop Analog zu Szenario 1 erfolgt die Bearbeitung der instruierten Aufgaben in einer generischen Arbeitsumgebung (Abbildung 45). Zu sehen sind in diesem Szenario zwei Fenster, eine Menüleiste sowie ein Dock, welches an das Betriebssystem Mac OS X angelehnt ist. Ein Dock ist der zentrale Zugriffspunkt auf häufig genutzte Programme. In diesem Szenario ist im Dock ausschließlich der Mülleimer mit einer speziellen Funktion hinterlegt, alle anderen Einträge dienen als Distraktoren. Die Menüleiste beinhaltet ein File und ein Edit Menü, welche in Abbildung 46 aufgeklappt dargestellt sind. Am Anfang des Szenarios befindet sich im linken Fenster die Matrix mit neun Ordnern, wie sie bereits aus Szenario 1 bekannt ist. Im Ausgangszustand sind das rechte Fenster sowie der Mülleimer leer. Abbildung 45: Abbildung Szenario 2 zur Erfassung metaphorischer Interaktionen Links neben dem Arbeitsbereich stehen die für den Nutzer aktuell gültigen Aufgabenbeschreibungen. Auf der rechten Seite sind alle bisher richtig verwendeten Handlungsstrategien verzeichnet. Der Versuchsperson stehen während der Benutzung zusätzlich folgende Aktionsbuttons zur Verfügung: Reset, Weiter und Fertig. Die beiden zuletzt genannten Buttons bieten die Möglichkeit, zur nächsten Aufgabe zu springen bzw. das Szenario zu beenden. Der Reset Button versetzt die Arbeitsumgebung in den Zustand

66 Anwendung der WDP für die CLS-IA Aggregation von Interaktionsaufgaben 66 zurück, der zum Startzeitpunkt vorherrschte. Bei der Betätigung dieses Buttons werden alle bisher gelöschten bzw. kopierten Ordner wieder hergestellt bzw. gelöscht. Abbildung 46: File und Edit Menü in aufgeklappter Form Nach dem Start des Szenarios wird der Nutzer durch zwei Aufgaben geführt. Die Umgebung bietet zu jedem Zeitpunkt alle Interaktionsmöglichkeiten. Eine Interaktion wird jedoch nur als richtig anerkannt, wenn sie im richtigen Kontext ausgeführt wird. Sollte ein Benutzer durch exploratives Verhalten oder Zufall beispielsweise im ersten Teil des Szenarios einen Ordner kopieren, so wird weder Feedback über den Erfolg gemeldet, noch gilt die Interaktion als erkannt. Aufgabe 1 Im ersten Teil dieses Szenarios wird der Nutzer gebeten, Ordner aus dem linken Fenster zu löschen. Da in Szenario 1 bereits die Kenntnisse zu Selektionsmöglichkeiten abgefragt wurden, ist es in allen Aufgaben dieses Szenarios unerheblich, ob ein einzelner, mehrere oder alle Ordner gleichzeitig gelöscht werden. Entscheidend ist einzig, ob die hinterlegten Aktionsmöglichkeiten erkannt werden. Es gibt vier unterschiedliche Wege, Selektionen zu löschen. Die erste Möglichkeit besteht darin, einen Ordner oder eine getätigte Selektion mit der rechten Maustaste anzuklicken. Es öffnet sich ein Kontextmenü, wie es in Abbildung 47 dargestellt ist. Abbildung 47: Aufgeklapptes Kontextmenü Durch die Auswahl des Eintrags Delete aus diesem Menü werden die selektierten Objekte gelöscht. Neben dem sofortigen Feedback auf der rechten Seite im Feedbackteil, wechselt zusätzlich der Mülleimer im Dock das Aussehen. Im Ausgangszustand ist der Mülleimer leer. Sobald eine Löschung vorgenommen wird, befinden sich, analog zur Metapher eines realen Papierkorbs, Dokumente im Mülleimer. Die zwei möglichen Zustände des Papierkorbs sind in Abbildung 48 zu erkennen.

67 Anwendung der WDP für die CLS-IA Aggregation von Interaktionsaufgaben 67 Abbildung 48: Papierkorbmetapher mit 2 Zuständen Die zweite Möglichkeit besteht darin, aus dem Edit Menü (Abbildung 46) den Eintrag Delete auszuwählen. Die Interaktion gilt nur als richtig erkannt, wenn vor der Auswahl des Menüeintrags eine Selektion im linken Arbeitsfenster vorgenommen wurde. Eine weitere Option zum Löschen besteht darin, durch Drag & Drop die Auswahl oder den einzelnen Ordner auf das Papierkorbsymbol zu ziehen. Abbildung 49 zeigt das Verschieben von Ordner B2 in den Mülleimer. Abbildung 49: Drag & Drop von Ordner B2 auf den Papierkorb Die letzte Löschvariante erfordert es, eine Selektion im linken Arbeitsfenster vorzunehmen und anschließend die ENTF-Taste zu drücken. Auf Macintosh-Systemen wird zusätzlich die Tastenkombination unterstützt. Aufgabe 2 Im zweiten Teil des Szenarios werden die Interaktionskonzepte Kopieren und Einfügen abgetestet. Die erste Möglichkeit, einen Ordner oder eine Auswahl zu kopieren, besteht darin, diese durch Drag & Drop auf das rechte Fenster zu ziehen. Bei allen anderen Lösungswegen kommt es zusätzlich darauf an, dass der Fokus auf dem richtigen Arbeitsfenster liegt. Das System gibt Rückmeldung über den aktuellen Fokus. Das Fenster, auf dem der Fokus liegt, wird dunkler dargestellt, als das andere. Einfügen in die Zwischenablage ist nur möglich, wenn im linken Fenster eine Auswahl getroffen ist. Einfügen aus der Zwischenablage ist nur möglich, wenn der Fokus auf dem rechten Fenster liegt oder das Kontextmenü durch Rechtsklick in dieses aufgerufen wird. Eine Variante zum Einfügen in die Zwischenablage ist das Selektieren von Ordnern und Auswählen des Punktes Copy aus dem Edit Menü. Des Weiteren ist es möglich, aus dem Kontextmenü, welches durch Rechtsklick aufgerufen wird, den Menüpunkt Copy zu wählen. Die letzte Option des Einfügens in die Zwischenablage ist die Benutzung der Tastenkombination CTRL-C oder alternativ C auf Macintosh-Systemen. Das Einfügen aus der Zwischenablage in das rechte Fenster erfolgt analog dem Einfügen in die Zwischenablage. Der korrespondierende Menüeintrag im Edit sowie im Kontextmenü heisst Paste. Die entsprechende Tastenkombination ist CTRL-V oder alternativ V.

68 Anwendung der WDP für die CLS-IA Aggregation von Interaktionsaufgaben Szenario 3 - Eine Flugbuchung In den ersten beiden Szenarien werden deiktische Interaktionsformen im Umgang mit direkt manipulierbaren Systemen getestet. In den zwei folgenden Szenarien wird das Interaktionswissen zu speziellen Widgets überprüft, welche nach dem in Kapitel 5.2 beschriebenen Verfahren ausgewählt wurden. In diesem Szenario werden Versuchspersonen instruiert, über eine Onlineflugbuchung Tickets zu buchen. Zur Überprüfung stehen fünf Widgets: Listbox zur Auswahl des Zielorts (vgl. Kapitel 5.2.1) Textbox mit Kalendercallout zur Eingabe des Flugdatums (vgl. Kapitel 5.2.3) Textbox zur Namenseingabe Radiogroup zur Festlegung der Flugklasse (vgl. Kapitel 5.2.1) Range für die Anzahl der Mitreisenden (vgl. Kapitel 5.2.4) Zusätzlich ist eine Zeitbeschränkung vorgesehen, welche das Szenario automatisch nach einer voreingestellten Zeit beendet. Alle bis zu diesem Zeitpunkt getätigten Eingaben werden ausgewertet und an die Diagnoseplattform übermittelt. Abbildung 50 zeigt das dritte Szenario im Ausgangszustand. Abbildung 50: Szenario 3 - eine Flugbuchung In Anlehnung an Herczegs Definition: Interaktionsformen sind stereotype Abläufe zur Ein- und Ausgabe von Informationen... (2006, S. 101), wird im dritten und vierten Szenario getestet, ob die Versuchsperson in der Lage ist, mit unterschiedlichen Widgets zu interagieren. Darüber hinaus wird überprüft, ob die Informationsein- und -ausgabe

69 Anwendung der WDP für die CLS-IA Aggregation von Interaktionsaufgaben 69 richtig ist. Zu diesem Zweck sind in der Aufgabenbeschreibung (Instruktion) Hinweise über die gewünschten Eingaben des Teilnehmers verankert. Die erwarteten Eingaben sehen wie folgt aus: Flugziel: Wien max. 2 Punkte Datum: 01/08/2010 max. 4 Punkte Class: Auswahl auf Business max. 1 Punkte Hauptreisender: beliebige alphanumerische Zeichenfolge max. 1 Punkt Mitreisende: zwei Personenicons farblich markiert max. 2 Punkte Die Höhe der erreichbaren Punktzahl wurde vorerst abhängig von der Anzahl der Interaktionsschritte, die mit einem Widget notwendig sind, um das erwartete Resultat zu erreichen, festgelegt. In anschließenden Untersuchungen müssen empirische Daten zeigen, ob die Vergabe der Punkte anders geregelt werden sollte (vgl. Kapitel 5.5). Die Auswahl des Flugziels erfolgt über eine Dropdownlistbox. Nach Anklicken öffnet sich diese und bietet fünf Destinationen Berlin, Wien, Barcelona, Peking und Amsterdam zur Auswahl. Abbildung 51 zeigt die Auswahl des richtigen Flugziels. Abbildung 51: Auswahl des korrekten Flugziels Rechts neben der Auswahl für das Flugziel befindet sich ein Texteingabefeld zur Eingabe des gewünschten Flugdatums. Hierbei handelt es sich um eine Textarea, welche zusätzlich mit einem Kalenderwidget verknüpft ist. Sobald die Maus auf das Eingabefeld bewegt und mit der linken Taste ein Mausklick ausgeführt wird, öffnet sich ein Kalender, wie er in Abbildung 52 zu sehen ist. In der gleichen Abbildung sind die Bedienelemente des Kalenders beschrieben. Abbildung 52: Kalender zur Auswahl des Flugdatums

70 Anwendung der WDP für die CLS-IA Aggregation von Interaktionsaufgaben 70 Um die richtige Datumsauswahl zu treffen, sind mehrere Schritte notwendig. Darüber hinaus gibt es alterative Lösungsmöglichkeiten. Monat und Jahr können über Dropdownboxen gewählt werden. Alternativ kann der Januar des Jahres 2010 auch über mehrmaliges Klicken der Auswahltaste für den nächsten Monat erreicht werden. Bei Anklicken eines konkreten Tages schließt sich der Kalender automatisch und das ausgewählte Datum ist in der Textarea zu lesen. Die Festlegung der Flugklasse erfolgt über reguläre Radiobuttons, die alle zur gleichen Radiogroup gehören. Beim erneuten Auswählen einer alternativen Klasse, wird die vorher getätige Selektion aufgehoben. Das Eingabefeld für den Namen des Reisenden ist eine klassische Textbox, welche die Eingabe von Freitext erlaubt. Eine tiefergehende Überprüfung der hier getätigten Angaben findet vorerst nicht statt. Über das letzte Widget dieses Szenarios, hat die VP die Möglichkeit, die Anzahl der gewünschten Begleitpersonen einzugeben. In den Instruktionen wird die VP aufgefordert für zwei weitere Mitreisende ein Ticket zu buchen. Das Widget bildet einen Range (vgl. Kapitel 5.2.4) von null bis fünf Personen ab. Die Anzahl der Personen wird durch kleine Icons widergespiegelt, wie sie in Abbildung 53 zu sehen sind. Im Ausgangszustand sind alle Icons grau. Durch das Bewegen des Mauszeigers über ein Icon, wird dieses sowie die links davon befindlichen mit Farbe gefüllt. Beim Verlassen des Icons mit der Maus verschwindet die farbliche Markierung wieder. Durch Anklicken eines Icons wird die Auswahl permanent vorgenommen. Abbildung 53: Auswahl der Mitreisenden Zum Abschließen der Buchung (des Szenarios) befindet sich ein Button mit der Aufschrift Bestätigen ganz unten im Arbeitsbereich der VP. Nachdem der Knopf durch einen Mausklick gedrückt wurde, schließt sich das Szenario und die Werte werden an die Diagnoseplattform zurückgesendet Szenario 4 - Farbeneinkauf Das letzte der vier interaktiven Szenarien simuliert einen Onlineeinkauf von Farbe. Um dieses Szenario vollständig zu lösen, muss der VP das Konzept von Karteikartenreitern (engl. Tabs) bekannt sein. Die notwendigen Widgets zur Eingabe der geforderten Werte sind über drei Reiter verteilt. Den Grundaufbau des Szenarios zeigt Abbildung 54.

71 Anwendung der WDP für die CLS-IA Aggregation von Interaktionsaufgaben 71 Abbildung 54: Übersicht Szenario 4 - Farbeneinkauf In Abbildung 54 ist der Reiter Produkt ausgewählt. Die zwei anderen Reiter sind mit Farbe & Menge sowie Anbieter und Versand beschriftet. Durch Anklicken der Reiter gelangt man jeweils zu den Oberflächen, welche in Abbildung 56 und Abbildung 57 dargestellt sind. In der Oberfläche Produkt sind sechs symbolische Farbdosen zu sehen, welche sich im Kreis drehen. Die Drehrichtung sowie die Geschwindigkeit des Karussells können durch den Nutzer mittels Mausbewegungen auf der Arbeitsfläche variiert werden. Von der VP wird nun erwartet, dass sie die richtige Farbsorte auswählt. Da die Dosen lediglich nummeriert sind, kann der Nutzer keinerlei Rückschlüsse über den Inhalt der mit 1 bis 6 beschrifteten Objekte ziehen. Es gibt zwei Möglichkeiten Informationen über den Inhalt zu erlangen. Eine Variante ist das Anklicken einer Dose. Der Inhalt wird dann in dem Textfenster Produkt ausgegeben. Die zweite Lösung besteht darin, mit dem Mauszeiger einige Sekunden über einem Objekt zu verweilen. In einem Tooltip 25, wie er in Abbildung 55 zu sehen ist, wird dann die Produktinformation ausgegeben. Abbildung 55: Beispiel für Tooltip 25 Auch Kurzinfo. Ein kleines Fenster öffnet sich, in dem zusätzliche Informationen angezeigt werden.

72 Anwendung der WDP für die CLS-IA Aggregation von Interaktionsaufgaben 72 In der Ansicht Farbe & Menge (Abbildung 56) gibt es zwei Widgets. Beide realisieren einen Range (vgl. Kapitel 5.2.4) in unterschiedlicher Art und Weise. Das linke Widget ermöglicht die Festlegung einer Farbe sowie des Farbtons. Das rechte ist eine klassische Umsetzung eines Wertebereichs und gestattet die Festlegung der gewünschten Farbmenge. Beide Elemente sind durch Gedrückthalten der linken Maustaste und Bewegung der Maus zu manipulieren. Die Textfelder in dieser Ansicht dienen ausschließlich zur Ausgabe der ausgewählten Werte und sind gegen manuelle Eingaben schreibgeschützt. Die Hintergrundfarbe des linken Textfeldes entspricht zusätzlich dem gewählten Farbton. Abbildung 56: Reiter Farbe & Menge Szenario 4 Die letzte Ansicht zeigt der VP verschiedene Anbieter in tabellarischer Form. Insgesamt stehen acht Versender zur Auswahl, die unterschiedliche Preise erheben. Die Aufgabe besteht darin, den günstigsten Anbieter auszuwählen. In der Standardansicht werden nicht alle Anbieter angezeigt, sondern nur die ersten drei. Der gewünschte Anbieter ist in dieser Ansicht nicht dabei. Abbildung 57: Reiter Anbieter und Versand Szenario 4 Sind der Versuchsperson keine der hier überprüften Konzepte bekannt, wird sie nicht den günstigsten Anbieter auswählen. Die Möglichkeiten zum Finden des besten Anbieters sind, der Effizienz nach geordnet, folgende:

73 Anwendung der WDP für die CLS-IA Entwurf & Implementierung d. Szenarien 73 Sortieren der Preisspalte Abbildung 58: Sortieren einer Tabellenspalte Tabellengröße erhöhen Abbildung 59: Ändern der Menge angezeigter Objekte Durch scrollen/ pagen der Tabelle Abbildung 60: Darstellung eines Pagers Die endgültige Auswahl eines Anbieters wird durch das Anklicken der Tabellenzelle erreicht. Zum Abschließen des Szenarios muss der Button mit der Beschriftung Fertig betätigt werden. 5.4 Entwurf und Implementierung der Szenarien In diesem Abschnitt erfolgen die Vorstellung des Entwurfs sowie der konkreten technischen Umsetzung der CLS-IA. Darüber hinaus wird beschrieben, welche Änderungen am Modell der Basisversion vorgenommen werden mussten, bzw. welche neuen Anforderungen sich an die Softwarelösung im Betrieb ergeben haben Allgemeines Vorgehen Die rapide Entwicklung im Webumfeld hat viele konkurrierende Entwicklungsumgebungen und Technologien hervorgebracht. Dazu zählen z.b. Java EE,.Net 26, LAMP 27 sowie darauf aufbauende oder eigenständige Frameworks. Für die kommenden Jahre ist dabei noch kein Industriestandard abzusehen. Weiterhin sind, wie in Kapitel beschrieben, annähernd beliebig viele hybride Widgets denkbar. Einige Widgets sind in der einen oder anderen Entwicklungsumgebung bereits als Standard vorhanden oder lassen sich bei Bedarf unterschiedlich schnell generieren. Dazu kommen persönliche Vorlieben und Affinitäten der Entwickler. Um all diesen Gesichtspunkten Aufmerksamkeit zu schenken, wurden alle Szenarien als stand-alone Plugins realisiert. Somit ist es möglich, jedes Szenario als eigenständige Applikation zu betrachten, die unabhängig entworfen, entwickelt und getestet werden kann. Die Erweiterung der CLS-IA ist dadurch in mehreren Ausbaustufen möglich, wie es der inkrementelle Ansatz (vgl. 26 Softwareplattform von Microsoft 27 Akronym: Linux, Apache, MySql, PHP

74 Anwendung der WDP für die CLS-IA Entwurf & Implementierung d. Szenarien 74 Kapitel 3.2) beschreibt. Darüber hinaus ist es nicht ausschlaggebend, in welcher Entwicklungsumgebung ein Szenario implementiert wird und auf welchem Webserver es läuft. Dadurch ist ein Höchstmaß an Flexibilität und Wiederverwendbarkeit gegeben. Szenarien können einfache HTML Formulare, Flashanwendungen bis hin zu komplexen Webapplikationen sein und als Halbfabrikate betrachtet werden, wie sie der komponentenbasierte Ansatz (vgl. Kapitel 3.4) beschreibt. Zwischen der Diagnoseplattform und den einzelnen Szenarien ist ein Datenaustausch notwendig. Szenarien werden aus der Diagnoseplattform über eine URL aufgerufen, die adäquat parametrisiert ist. Nachdem die Ergebnisse innerhalb eines Szenarios erfasst und bewertet sind, werden sie nach einer speziellen Vorschrift serialisiert und an die Diagnoseplattform zurückgegeben (vgl. Kapitel 5.4.3). Alle in dieser Arbeit umgesetzen Szenarien sind in HTML, jquery (vgl. Kapitel 5.4.2) und JavaScript implementiert und können daher direkt vom jboss Applikationsserver, auf dem auch die Diagnoseplattform läuft, mit ausgeliefert werden Exkurs - jquery Scott Guthrie, Corporate Vice President der.net Developer Division, beschreibt jquery wie folgt: jquery is a lightweight open source JavaScript library (only 15kb in size) that in a relatively short span of time has become one of the most popular libraries on the web. (Guthrie, S., 2008) Eine der größten Stärken ist der direkte Zugriff auf DOM 28 Elemente über komfortable Funktionen, welche eine DOM-Navigation und Manipulation vereinfachen. Des Weiteren bietet jquery sehr gute Ajax-Unterstützung, diverse animierte Effekte sowie ein vereinfachtes Eventhandling. Im Juli 2007 wurde die Entwicklung eines UI Moduls angekündigt, welches seit September des selben Jahres öffentlich verfügbar ist: jquery UI is a fully themed interaction and widget library built on top of jquery. (Reisig, J., 2007). In den letzten Jahren sind viele Erweiterungen und Plugins entstanden. Ende September 2008 kündigten Nokia und Microsoft die Aufnahme von jquery in ihre Entwicklungsplattformen an: Both Microsoft and Nokia are taking the major step of adopting jquery as part of their official application development platform. Not only will they be using it for their corporate development but they will be providing it as a core piece of their platform for developers to build with. (Reisig, J., 2008). Die Entwicklung von Webprojekten mit jquery steht unter dem Motto Write less, do more. Sobald das Framework durch die in Listing 15 dargestellte Zeile Code im HTML <head> eingebunden ist, kann auf den Funktionsumfang von jquery zugegriffen werden. 28 Document Object Model

75 Anwendung der WDP für die CLS-IA Entwurf & Implementierung d. Szenarien 75 1 <script type= text/javascript src= jquery.js ></script> Listing 15: Einbindung von jquery in eine HTML Seite Sämtlicher jquery Code darf erst ausgeführt werden, nachdem das HTML Dokument fertig geladen ist. Dieser Zeitpunkt kann programmatisch ermittelt werden (Listing 16). 1 $(document).ready(function(){ // Quellcode hier 3 }); Listing 16: Beispiel jquery $(document).ready(function) Die Selektion von Objekten in jquery erfolgt durch Selektoren, wie sie in Tabelle 6 gezeigt sind. Selektor $(this) $(document) $( a ) $(.test ) $( #myid ) Auswahl Objekt im aktuellen Kontext HTML Document Objekt alle Link Elemente im Dokument alle Elemente mit der CSS Klasse test Objekt mit der ID myid Tabelle 6: Auswahl möglicher Selektoren in jquery Jede Methode in jquery gibt als Rückgabewert das Anfrageobjekt selbst zurück. Damit wird das objektorientierte Builder pattern (dt. Erbauer Entwurfsmuster) implementiert. Dadurch ist es möglich, direkt auf den Ergebnissen einer Anfrage zu operieren. Dieses Konzept soll an folgendem Stück Quelltext (Listing 17) deutlich gemacht werden. 1 $( a ).filter(.verlassen ) 3.click(function(){ alert( Sie verlassen jetzt die Seite. ); 5 }).end() 7.filter(.verstecken ).click(function(){ 9 $(this).hide(); return false; 11 }).end(); Listing 17: Beispiel Builder Pattern in jquery

76 Anwendung der WDP für die CLS-IA Entwurf & Implementierung d. Szenarien 76 Es werden zunächst alle Link Elemente selektiert. Diese werden anschließend so gefiltert, dass in der Auswahl nur die Links enthalten bleiben, denen zusätzlich die CSS Klasse verlassen zugewiesen ist. Auf dieser Auswahl wird danach für ein Clickevent die Ausgabe einer Warnung registriert. Durch.end() kann die Auswahl rückgängig gemacht werden. Im zweiten Teil wird auf der ursprünglichen Selektion aller Links erneut gefiltert, sodass in der Auswahl diesmal nur die Elemente verbleiben, welche die CSS Klasse verstecken tragen. Anschließend wird abermals ein Clickevent registriert, welches bewirkt, dass alle selektierten Links ausgeblendet werden. 1 <a href= class= verlassen > Benachrichtung beim Verlassen der Seite 3 </a> <a href= class= verstecken > 5 Hier klicken um den Link auszublenden! </a> 7 <a href= > Normaler Link 9 </a> Listing 18: Beispiel jquery HTML Links Die Anwendung der in Listing 17 vorgestellten Methode auf den in Listing 18 gezeigten Quelltext erzeugt folgendes Verhalten. Beim Klicken auf den ersten Link erscheint eine Warnmeldung mit der Nachricht: Sie verlassen jetzt die Seite. Nach Bestätigen der Warnung öffnet sich die Google Startseite. Der zweite Link wird beim Anklicken ausgeblendet (unsichtbar). Die Startseite von Yahoo wird in diesem Fall nicht geöffnet, da der Rückgabewert der Funktion auf dem Clickevent false ist. Der dritte Link verhält sich wie ein normaler Link, da für das Clickevent auf der ersten Selektion (alle Links) keine spezielle Aktion registriert ist. Eine häufige Anwendung ist das Hinzufügen oder Entfernen von CSS Klassen. Folgende Zeile Code (Listing 19) fügt allen Elementen, welche die CSS Klasse drag zugewiesen haben, zusätzlich die Klasse ui-selected hinzu: 1 $(.drag ).addclass( ui-selected ); Listing 19: Zuweisen einer CSS Klasse mit jquery In einem der implementierten Szenarien wird dies dazu genutzt, um alle per Maus verschiebbaren Objekte als ausgewählt zu markieren. Genauso kann eine CSS Klasse von einem Objekt entfernt werden (Listing 20).

77 Anwendung der WDP für die CLS-IA Entwurf & Implementierung d. Szenarien 77 1 $( #dragee-xy ).removeclass( ui-selected ) Listing 20: Entfernen einer CSS Klasse mit jquery Der Entwickler von jquery John Reisig ist zudem Mozilla Technologie-Evangelist, was die sehr gute Integration von jquery mit Mozilla Firebug (Kapitel 5.4.6) erklärt Kommunikation mit der Diagnoseplattform Da die Szenarien als stand-alone Plugins konzipiert sind, ist es notwendig, Schnittstellen zur Integration in die webbasierte Diagnoseplattform zu definieren. Eine Übersicht des Aufbaus zeigt Abbildung 61. Im Folgenden sind alle Kommunikationsschritte beschrieben. File Edit Window 2 1 Browser 4 5 Highslide iframe LEGENDE HTTP Request <=> Response zusätzlich Ajax Bridge Internet 6 3 Web Container EJB Container Web Container beliebiger Webserver oder lokales Filesystem Datenbank Webbasierte Diagnoseplattform Abbildung 61: Anbindung interaktiver Szenarien an die WDP Schritt 1: Ausliefern des CLS Fragebogens Schritt 2: Im interaktiven Teil des Fragebogens startet die Versuchsperson ein interaktives Szenario. Dadurch wird ein Highslide iframe geöffnet. Dieser Schritt wird anschließend genauer erörtert. Schritt 3 Innerhalb des iframes wird das Szenario vom Webserver, der dieses hostet, abgefragt und und 4: geladen.

78 Anwendung der WDP für die CLS-IA Entwurf & Implementierung d. Szenarien 78 Schritt 5: Nachdem die Versuchsperson ein Szenario beendet, werden per Java- Script die gesammelten Daten auf die interaktiven Items im Fragebogen zurückgeschrieben. Schritt 6: Das Zurückschreiben der Daten auf die interaktiven Items löst ein Event aus, welches die erfassten Daten aufbereitet und in der WDP persistiert. Technisch interessante Punkte sind 2, 5 und 6, die dabei helfen, die stand-alone Szenarien transparent in einen Fragebogen der Diagnoseplattform zu integrieren. Für die Umsetzung von Punkt 2 kam das JavaScript Framework Highslide 29, im Rahmen des komponentenbasierten Ansatzes (vgl. Kapitel 3.4), zum Einsatz. Highslight ist ein konfigurierbarer Open Source Medien- und Bildbetrachter, welcher keine weiteren Plugins wie Java oder Flash benötigt. Auch sogenannte Popupblocker sind kein Problem, da sich der Inhalt immer im aktiven Browserfenster öffnet. Beide Faktoren waren wichtige Entscheidungskriterien, da anderenfalls die Hemmschwelle einiger Versuchspersonen nicht überwunden würde. Highslide wurde in dieser Arbeit so konfiguriert, dass beim Starten einer interaktiven Aufgabe das entsprechende Szenario geladen und dargeboten wird (vgl. Abbildung 62). Der Fragebogenkontext wird ausgegraut und der Fokus liegt auf dem interaktivem Szenario. Abbildung 62: Einbindung von Szenarien mit Hilfe von Highslide Um eine nahtlose Integration zu realisieren und die Kommunikation mit dem Backend zu ermöglichen, sind mehrere Schritte notwendig. Ein Highslide iframe wird standardmäßig, wie in Listing 21 gezeigt, eingebunden. 29

79 Anwendung der WDP für die CLS-IA Entwurf & Implementierung d. Szenarien 79 1 <a href= iframe.htm onclick= return hs.htmlexpand(this, {objecttype: iframe } ) > Content in iframe 2 </a> Listing 21: Einbindung des Highslide Frameworks in eine HTML Seite Um die im Szenario gesammelten Daten an die Diagnoseplattform zurück senden zu können, müssen alle Items im Szenario bekannt sein. Die Items sind als versteckte Eingabefelder auf dem Fragebogen hinterlegt. Jedes Element einer HTML Seite hat eine eindeutige ID, welche benutzt werden kann, um dieses in einer Skriptsprache wie jquery zu referenzieren. Die entwickelte Komponente SurveyManager (Kapitel A.3.6.4) berechnet einen parametrisierten Link für den Aufruf jedes Szenarios, inkl. aller benötigten IDs. Beim Starten eines Szenarios werden die IDs der Itemeingabefelder als zusätzliche Parameter an das Highslide iframe übergeben. Abbildung 63 zeigt den gesamten Aufbau sowie die Kommunikation der Komponenten untereinander. SurveyManger Question question; String link; public String gethsitemclientids(); item1 item2 item3 item4 item5 item6 item7 item8 item9 parametrisierter Link LEGENDE HTTP Request JavaScript Zugriff JSF Value Binding <a id="surveyform:topics:3:segments:0:questions:3:actionlink" style="color: blue;" onclick="return hs.htmlexpand(this, { objecttype: 'iframe',height: 600, width : 800, captionoverlay: { position: 'leftpanel'}}, {item0:'surveyform:topics:3:segments:0:questions:3:item:0:replyinteractive', item1:'surveyform:topics:3:segments:0:questions:3:item:1:replyinteractive', item2:'surveyform:topics:3:segments:0:questions:3:item:2:replyinteractive', item3:'surveyform:topics:3:segments:0:questions:3:item:3:replyinteractive', item4:'surveyform:topics:3:segments:0:questions:3:item:4:replyinteractive', item5:'surveyform:topics:3:segments:0:questions:3:item:5:replyinteractive', item6:'surveyform:topics:3:segments:0:questions:3:item:6:replyinteractive', item7:'surveyform:topics:3:segments:0:questions:3:item:7:replyinteractive', item8:'surveyform:topics:3:segments:0:questions:3:item:8:replyinteractive'})" href="/alisa/interactive_items/colors/color.htm"> Abbildung 63: Kommunikation zwischen WDP und einem Szenario Innerhalb eines Szenarios kann nun auf die Itemeingabefelder im Fragebogen zugegriffen werden (vgl. Listing 22).

80 Anwendung der WDP für die CLS-IA Entwurf & Implementierung d. Szenarien 80 1 function callback (target, value){ target.value = value; 3 target.style.visibility= visible ; target.focus(); 5 target.blur(); target.style.visibility= hidden ; 7 } 9 callback(parent.document.getelementbyid(parent.hs.getexpander().custom.item0), task_1a_result); Listing 22: Zurückschreiben von Ergebnissen per JavaScript Um die Persistierung auf dem Fragebogen auszulösen, muss auf dem Itemeingabefeld, in das die Daten geschrieben wurden, ein onchangeevent ausgelöst werden. Dies übernimmt die entwickelte Methode callback(target,value), indem sie den Fokus kurz auf das Feld setzt und danach wieder entfernt. Da per Definition ein Fokus nur auf sichtbare Felder gesetzt werden kann, wird das Feld sichtbar und nach dem Entfernen des Fokus wieder unsichtbar gemacht. Die Itemeingabefelder sind an Objekte der Klasse InteractiveItem (vgl. Kapitel 5.4.4) gebunden. Im Attribut useranswer jedes Objekts dieser Klasse steht nach dem Callback ein serialisiertes Ergebnis aus dem Szenario, welches die in Listing 23 gezeigte Form hat. Dieses Ergebnis wird vom SurveyManager deserialisiert, den entsprechenden Attributen des Objekts zugewiesen und anschließend persistiert. 1 Punktzahl###Ergebnis###Clicks###Zeitstempel Listing 23: Format eines serialisierten Ergebnisses Notwendige Modelländerungen Als ein Maß der Güte aller während der Entwicklung der Basisversion getroffenen Entscheidungen (Kapitel 4.3) sowie der angefertigten Modelle kann der Aufwand angesehen werden, welcher notwendig war, die CLS-IA umzusetzen. Im Modell der Diagnoseplattform wurde für die stand-alone Plugins (Szenarien) eine neue Entität angelegt, eine Entity Bean namens IteractiveItem. Diese implementiert wie alle anderen Entity Beans (vgl. Kapitel A.3.5) die Klasse Serializable, um in der angebundenen Datenbank persistiert werden zu können. Darüber hinaus erweitert sie die Klasse Item (Kapitel A.3.5.6) um folgende Attribute und Methoden (Abbildung 64).

81 Anwendung der WDP für die CLS-IA Entwurf & Implementierung d. Szenarien 81 Abbildung 64: Neu eingeführte Entität InteractiveItem In der actionurl kann eine Adresse für einen externen Test hinterlegt werden. Für die interaktiven Szenarien, welche mehrere interaktive Items vereinen, wird die URL für das gesamte Szenario jedoch auf dem übergeordnetem Questionobjekt (vgl. Kapitel A.3.5.5) hinterlegt. Unter points und maxpoints werden die maximal erreichbaren sowie die vom Nutzer erzielten Punkte abgespeichert. UserAnswer beinhaltet ein serialisiertes, aus mehreren Werten zusammengesetztes Ergebnis (Listing 23) des bearbeiteten Items. Im Attribut time kann die Zeit abgespeichert werden, welche zur Bearbeitung eines Items benötigt wurde. Die Einführung der neuen Itemklasse war durch die Konzepte der Vererbung sehr leicht. Die notwendigen Änderungen in der Datenbank geschahen durch die objektrelationale Abbildung (vgl. Kapitel 4.3.2) automatisch. Aufgrund der neuen Itemklasse musste der Evaluator (Kapitel A.3.6.3) erweitert werden, um die neuen Attribute in den Excelexport aufzunehmen. Darüber hinaus wird für die Bearbeitung des interaktiven Teils ein zusätzliches Nutzerfeedback als Diagramm angeboten. Die Daten dafür werden ebenfalls vom Evaluator aufbereitet. Die Klasse SurveyManager wurde um eine Methode erweitert, welche die Kommunikation (vgl. Kapitel ) der interaktiven Items im Szenario mit dem Backend der Diagnoseplattform ermöglicht. Dadurch, dass die Erweiterung des Softwareprodukts um einen interaktiven Teil von vornherein geplant und das gewählte Vorgehensmodell (vgl. Kapitel 3.6) darauf ausgelegt war, hielt sich der Aufwand für die notwendigen Änderungen in Grenzen. Eine genaue Analyse des entstandenen Entwicklungsaufwands unter Beachtung des gewählten Vorgehens findet in Kapitel 6.1 statt.

82 Anwendung der WDP für die CLS-IA Entwurf & Implementierung d. Szenarien Neuer Loginprozess Der in der Basisversion implementierte Loginprozess (4.4.2) war für einige Nutzer eine zu große Hemmschwelle. Während der Entwicklung der CLS-IA wurde dieser Prozess daher so angepasst, dass eine explizite Authentisierung für eine Teilnahme nicht mehr notwendig ist. Die Zugangsdaten werden automatisch generiert und die Authentifizierung transparent vollzogen. Am Ende eines Versuchs werden die generierten Zugangsdaten zur Verfügung gestellt, um zu einem späteren Zeitpunkt die eigenen Ergebnisse noch einmal einzusehen. Abbildung 65 zeigt den neuen Loginprozess. Abbildung 65: Neuer Authentisierungs- und Authentifizierungsablauf Verwendete Werkzeuge Ein Tool, welches bei der Entwicklung der interaktiven Szenarien sehr hilfreich war, ist Mozilla Firebug. Bei Firebug handelt es sich um ein Firefox Browser Add-on, welches zahlreiche Entwicklungswerkzeuge in sich vereinigt. Es erlaubt die Änderung von HTML, CSS und JavaScript direkt im Browser. Darüber hinaus besitzt Firebug eine Konsole, die aus JavaScript, wie in Listing 24 gezeigt, angesprochen werden kann. 1 console.log(object[, object,...]) Listing 24: Aufruf der Firebug Console Dies kann sehr hilfreich für das Debuggen komplexer Programme sein, da Zwischenergebnisse auf der Konsole ausgegeben werden können. Weiterhin stehen Werzeuge zum Messen von Seitenladezeiten zur Verfügung. Abbildung 66 zeigt die Arbeitsfläche von Firebug im Firefox.

83 Anwendung der WDP für die CLS-IA Testdurchläufe und empirische Phase 83 Abbildung 66: Mozilla Firebug im Firefox 5.5 Testdurchläufe und empirische Phase Im Rahmen der Abnahme und vor Beginn der ersten Untersuchungen mit der CLS- IA wurde institutsintern eine minimale Versuchsreihe gestartet. Diese diente in erster Linie dem Testen der Software. Darüber hinaus konnten bereits erste empirische Daten im Umgang mit den neu entworfenen Szenarien gewonnen werden. Diese Informationen werden benötigt, um die Punktevergabe für das Lösen der einzelnen Interaktionsaufgaben zu überprüfen. Im ersten Schritt wurden in Szenario 1 (Kapitel 5.3.1) und Szenario 2 (Kapitel 5.3.2) das Erkennen jeder Interaktionstechnik gleichwertig mit einem Punkt bewertet. In Szenario 3 (Kapitel 5.3.3) und Szenario 4 (Kapitel 5.3.4) wurde die Punktzahl danach festgelegt, ob das gewünschte Resultat erreicht wurde und ob bestimmte Interaktionstechniken verwendet wurden. Um ein validiertes Werkzeug und ein aussagekräftiges Maß des vorhandenen prozeduralen Wissens zu erhalten, sind noch weitere Iterationsstufen mit größeren Stichproben notwendig. Der softwaretechnische Aspekt dieses ersten internen Testdurchlaufs war das Auffinden von Fehlern, die in vorhergehenden Tests nicht gefunden wurden. Auch beim Testen gibt es Werkzeuge, die ein Entwicklungsteam beim Arbeiten unterstützen. Ein solches Werkzeug kann ein Bugtracker (dt. Fehler-Verfolger ) sein, wie es im Folgenden vorgestellt wird. Wichtig beim Testen ist es, Fehler nicht nur zu finden, sondern diese auch in geeigneter Weise festzuhalten, zu dokumentieren, zu klassifizieren/ kategorisieren und zu verfol-

84 Anwendung der WDP für die CLS-IA Testdurchläufe und empirische Phase 84 gen. Bei diesen Arbeiten können Bugtracker in geeigneter Weise unterstützen sowie die Kommunikation zwischen Entwicklern, Auftraggeber und Anwendern deutlich verbessern. Ein weiterer Vorteil besteht in der zentralen Erfassung aller aufgetretenen Fehler. Zu einem späteren Zeitpunkt ist es beim Auftreten eines ähnlichen Fehlers einfacher, im Bugtracker zu recherchieren, als geschriebene s zu durchsuchen. Telefonisch oder persönlich mitgeteilte Fehler können für die Recherche nicht mit einbezogen werden. Weiterhin können Bugtracker Übersichten und Berichte zu allen im System erfassten Fehlern generieren. Eine solche Ansicht in der Weboberfläche des Mantis Bugtrackers zeigt Abbildung 67. Bekannte freie Bugtracker sind Bugzilla 30, Mantis 31, GNATS 32, Trac 33, Roundup 34, Flyspray 35 und viele andere mehr. Ähnlich wie bei der Auswahl geeigneter Frameworks für die Umsetzung des Frontends (vgl. Kapitel 4.3.5) wurde die Wahl des verwendeten Bugtrackers größtenteils auf Basis subjektiver Einschätzungen getroffen. Jeder Anbieter hat seine eigenen Vorzüge und Besonderheiten. Alle aufgezählten Bugtracker sind vom Leistungsumfang sehr gut. Abbildung 67: Automatisch generierte Übersichtsseite in Mantis

85 Diskussion und Ausblick Bewertung d. Vorgehens und d. verwendeten Modelle 85 6 Diskussion und Ausblick In diesem Kapitel werden die während der Umsetzung des Softwareprodukts gesammelten Erfahrungen beschrieben und die gewählte Vorgehensweise sowie die getroffenen Entscheidungen bewertet. Anschließend wird ein Ausblick über mögliche Erweiterungen aus technischer und aus psychologischer Sicht gegeben. 6.1 Bewertung des Vorgehens und der verwendeten Modelle Als zweckmäßig hat sich die Unterteilung der Entwicklungsarbeit in mehrere Phasen erwiesen. So konnte eine schnelle Bereitstellung einer ersten produktiv einsetzbaren Version realisiert werden. Diese Basisversion konnte bereits vor Fertigstellung des Gesamtprodukts genutzt werden, Umfragen durchzuführen und auszuwerten sowie Verbesserungspotentiale aufzudecken. Ein striktes Festhalten an klassischen Vorgehensweisen kann unter Umständen dazu führen, dass ein Softwareprodukt entwickelt wird, welches zwar den spezifizierten Anforderungen genügt, den Wünschen des Auftraggebers allerdings nur in Teilen entspricht. Die Wünsche des Auftraggebers sowie die Vorstellung der fertigen Softwarelösung des Entwicklers werden durch mentale Modelle repräsentiert. Ein Blick auf die Charakteristika dieser Modelle (Kapitel 2.2) macht deutlich, dass es nur sehr schwer möglich ist, alle Anforderungen von Anfang an zu erfassen. Das evolutionäre Vorgehen (Kapitel 3.3) sowie die Orientierung am Agilen Manifest (vgl. Kapitel 3.6) über alle Phasen der Entwicklung haben dabei geholfen, das Produkt so umzusetzen, dass es den Vorstellungen des Auftraggebers entspricht. Durch den zweckmäßigen Einsatz von Prototypen (Kapitel 3.5) konnten viele Entscheidungen und Diskussionen erheblich beschleunigt werden. Dennoch ist zu erwähnen, dass durch das häufige Reagieren auf Änderungswünsche ein erhöhtes Risiko besteht, den vorab geplanten zeitlichen Rahmen zu überschreiten. Ähnlich kritisch ist der Einsatz von Halbfabrikaten, wie sie im komponentenbasierten Modellansatz (Kapitel 3.4) beschrieben sind, zu bewerten. Sie entlasten einerseits den Entwickler deutlich bei der Realisierung von technischen Details, können aber auf der anderen Seite einen nicht unerheblichen Mehraufwand verursachen. Dieser lässt sich vor allem durch den anfänglichen Lernaufwand begründen. Zusätzlicher Aufwand entsteht, wenn es Unverträglichkeiten (Inkompatibilitäten) der Halbfabrikate untereinander gibt oder wenn diese im Leistungsumfang erweiteret werden müssen. Erst während der Arbeit stellte sich heraus, dass die meisten Dokumentationen und Tutorials von Frameworks oder Halbfabrikaten auf einen Standardanwendungsfall beschränkt sind. Sobald es Abweichungen von diesem meist sehr einfachem Szenario gibt, kann es zu

86 Diskussion und Ausblick Erweiterungsmöglichkeiten 86 erheblichem Mehraufwand kommen. 6.2 Erweiterungsmöglichkeiten Softwareprojekte sollten einer ständigen Verbesserung und Weiterentwicklung unterliegen. Nach Sneed (1983) veraltet Software in dem Maße, wie sie mit der Wirklichkeit nicht Schritt hält. Diese mehr als 25 Jahre alte Aussage hat bis heute nicht an Gültigkeit verloren. Daher sollen im Folgenden Erweiterungsmöglichkeiten aufgezeigt werden, die für die zukünftige Verwendung, der innerhalb der webbasierten Diagnoseplattform umgesezten CLS, aus technischer und aus psychologischer Sicht interessant sind Weitere Interaktionsformen und erweiterte Hardware Bisher ist die Überprüfung des prozeduralen Interaktionswissens auf metaphorische Interaktionsformen (Kapitel 5.1.2) sowie einige heute verfügbare Interaktionselemente (Kapitel 5.2) beschränkt. Durch die Entwicklung neuer Szenarien, ähnlich der in Kapitel 5.3 aufgeführten, ließen sich weitere Interaktionsformen, wie z.b. die von Herczeg (2006) beschriebenen formalen Sprachen, überprüfen. Denkbar wäre unter anderem die Realisierung einer Shell 36, mit Hilfe derer die Versuchsperson Aufgaben zu lösen hat. Auch durch den Einsatz erweiterter Hardware in Kombination mit anderen Zielplattformen (vgl. Kapitel 6.2.2) wären weitere Tests möglich. Beispielsweise könnte in einem Szenario die Interaktion mit einem System unter Verwendung natürlicher Sprache in Form von Spracheingaben umgesetzt werden Neue Zielplattformen Die für die Umsetzung der ersten Version zweckmäßigste Umsetzung war die Realisierung als Webanwendung (vgl. Kapitel 4.3.1). In weiteren Ausbaustufen ist es denkbar, weitere Zielplattformen und Endgeräte zu unterstützen. Die Nutzung des Internets findet bereits heutzutage in zunehmendem Maße auf mobilen Endgeräten statt. Die Darstellung von Webseiten auf diesen Geräten ist derzeit noch mit Einschränkungen, wie z.b. kleineren Bildschirmen, verbunden. Auch bei der Informationseingabe greifen mobile Geräte auf anderen Techniken, wie beispielsweise Touchscreens, zurück. Für mobile Endgeräte könnte unter Beachtung dieser speziellen Einschränkungen eine neue Benutzeroberfläche entwickelt werden. Weiterhin könnten sogenannte Rich Clients für verschiedene Plattformen implementiert werden. Solche Clients können lokal vorhandene Hardware, wie Mikrofone oder Kameras ansprechen und somit weitere Interaktionsformen für eine Überprüfung zugänglich machen. Ein Vorteil ist, dass solche Clients auch ohne Verbindung zum Internet funktionieren und sich synchronisieren können, sobald eine Internetverbindung vorhanden 36 Benutzerschnittstelle in Form eines Kommandozeileninterpreters

87 Diskussion und Ausblick Erweiterungsmöglichkeiten 87 ist. Die Kommunikation zwischen dem Client und der webbasierten Diagnoseplattform kann beispielsweise über WebServices geschehen Grafischer Fragebogendesigner /-administrator Um die schnellere Umsetzung neuer Tests und Umfragen oder die Änderung bestehender zu gewährleisten, ist es wünschenswert, einen grafisch basierten Designer/Administrator für die Diagnoseplattform zu entwickeln. Dieser sollte es einem Versuchleiter ohne Programmier- und Datenbankkenntnisse ermöglichen, neue Items anzulegen und diese in geeigneter Form in Tests und Fragebögen einzubinden. Darüber hinaus können Anpassungen der verwendeten Beschreibungen und Instruktionen sowie die Lokalisierung der Softwarelösung (vgl. Kapitel 4.4.1) vorgenommen werden. Die Entwicklung eines solchen Tools war von Anfang an in weiteren Arbeiten vorgesehen, weshalb die während dieser Arbeit getroffenen Designentscheidungen (vgl. Kapitel 4.3) darauf ausgelegt sind.

88 Fazit 88 7 Fazit Computer Literacy ist ein wichtiger Aspekt der Mensch-Technik-Interaktion. Obwohl es keine einheitliche Definition für Computer Literacy (vgl. Kapitel 2.3) gibt, wird übereinstimmend festgestellt, dass diese großen Einfluss auf die Interaktionsfertigkeiten im Umgang mit Computern hat. Es gibt verschiedene Ansätze, die Computer Literacy von Versuchspersonen zu erfassen (vgl. Kapitel 2.4). Der Mangel an objektiven und schnell durchführbaren Tests führte zur Entwicklung der Computer Literacy Scale (Kapitel 2.4.5). Im Rahmen dieser lehrstuhlübergreifenden Arbeit wurde die CLS innerhalb der webbasierten Diagnoseplattform online verfügbar gemacht. Es ist dadurch möglich, schnell und kostengünstig Erhebungen durchzuführen und somit die Entwicklungszyklen der CLS oder beliebiger Fragebögen zu verkürzen. In parallelen Arbeiten wird die WDP bereits genutzt, um neue, schwerere Items innerhalb der CLS zu evaluieren. Die von Sengpiel und Dittberner (2008) angestrebte Erweiterung der CLS auf alle Altersgruppen, kann durch die Verwendung der WDP deutlich schneller realisiert werden. Darüber hinaus wurde im zweiten Teil dieser Arbeit eine technische Lösungsmöglichkeit erarbeitet, die es erlaubt, das prozedurale Wissen einer Versuchsperson anhand von konkreten Arbeitsproben zu ermitteln. Zu diesem Zweck wurden vier interaktive Szenarien implementiert, welche die Ergebnisse in der webbasierten Diagnoseplattform speichern. Diese Umsetzung hebt die zweite von Sengpiel und Dittberner (2008) beschriebene Limitation der CLS auf und ergänzt diese um einen interaktiven Teil (CLS-IA) zur Erfassung prozeduralen Wissens. Gleichsam stellt diese Art der Umsetzung eine Innovation gegenüber den gesichteten Erhebungsmethoden dar, die den prozeduralen Anteil ausschließlich in Form von Szenarien mit vorgefertigten Antwortmöglichkeiten abprüfen. Die CLS-IA wurde in Forschungskolloquien sowie internationalen Workshops vorgestellt und rief großes Interesse hervor. Ph.D. Sarah Czaja, Professor und Co-Direktor am Altersforschungszentrum der Universität von Miami, lobte die Entwicklungsarbeit und erwartet, durch die interaktive Umsetzung mit sofortigem Feedback, eine erhöhte Motivation der Probanden. Durch die Umsetzung der CLS-IA wurde eine neue, realitätsnahe Möglichkeit geschaffen, auch den Anteil von Computer Literacy zu evaluieren, der einen erheblichen Einfluss auf den Umgang mit Computern im täglichen Leben hat. Insbesondere kann mit diesem Werkzeug die Aussage vieler Probanden: Ich weiß zwar nicht, wie es heißt, ich kann es aber benutzen. überprüft werden.

89 Literaturverzeichnis 89 Literaturverzeichnis Anderson, J. R. (1976). Language, Memory, and Thought (p. 546). Lawrence Erlbaum Associates Inc,US. Balzert, H. (2000). Lehrbuch der Software-Technik - Software-Entwicklung - mit 2 CD- ROM (2nd ed.). Spektrum-Akademischer Verlag. Balzert, H. (2008). Lehrbuch der Softwaretechnik: Softwaremanagement: Lehrbuch der Softwaretechnik (2nd ed.). Spektrum Akademischer Verlag. Beckers, J. J., & Schmidt, H. G. (2003). Computer experience and computer anxiety. Computers in Human Behavior, 19(6), Bella (2008). The Ultimate Video Editing Keyboard. Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer, 21(5), doi: /2.59. Bozionelos, N. (2001). Computer anxiety: relationship with computer experience and prevalence. Computers in Human Behavior, 17(2), Cassel, R. N., & Cassel, S. L. (1984). Cassel computer literacy test (CMLRTC). Journal of Instructional Psychology, 11, 3-9. codeproject (2008). Textbox with rounded corners. Craik, K. J. (1943). Nature of Explanation. Cambridge University Press. dhtmlx (2008) DHTML extensions - professional AJAX components for advanced Web UI. Floyd, C. (1984). A Systematic Look at Prototyping. In: Budde, R., Kuhlenkamp, K., Mathiassen, Lars and Zullighoven, H., Approaches to Prototyping. Springer Verlag (S. 1-17). Garland, K. J., & Noyes, J. M. (2004). Computer experience: a poor predictor of computer attitudes. Computers in Human Behavior, 20(6), Grady, R. B. (1992). Practical Software Metrics for Project Management and Process Improvement (0002nd ed.). Prentice Hall. gtkmm (2008). Examples Chapter 11. Menus and Toolbars. docs/gtkmm-2.4/docs/tutorial/html/sec-menus-examples.html Guthrie, S. (2008). jquery and Microsoft ScottGu s Blog. Herczeg, M. (2006). Interaktionsdesign. Gestaltung interaktiver und multimedialer Systeme (S. 231). Oldenbourg. Hix, D., & Hartson, H. R. (1993). Developing User Interfaces: Ensuring Usability Through Product & Process. Wiley. Holland, J.H., Holyoak, K.J., Nisbett, R.E., Thagard, P.R. (1986). Induction: Processes of Inference, Learning and Discovery. Cambridge, MA: MIT Press.

90 Literaturverzeichnis 90 ICEfaces (2008). Getting Started Guide Version ISO/IEC (2000). Information technology -- User system interfaces and symbols -- Icon symbols and functions -- Part 1: Icons -- General. International Organisation for Standardisation ISO 9241 (1999). Ergonomic requirements for office work with visual display terminals (VDTs) - Part 16 - Direct-manipulation dialogues. International Organisation for Standardisation Java2s (2008). Building menus and menu items. Swing-JFC/BuildingmenusandmenuitemsAcceleratorsandmnemonics.htm Java2s (2008). CheckBox with three states. GUI/CheckBoxwiththreestates.htm Java2s (2008). RadioButton Click Event. h t t p : / / w w w. j a v a 2 s. c o m / Tu t o r i a l / CSharp/0460 GUI-Windows-Forms/RadioButtonClickEvent.htm Johnson-Laird, P. (1983). Mental Models. Cambridge, MA: Harvard University Press. laas02 (2008). Spinbutton. Manifesto (2001). Manifesto for Agile Software Development. McConnell, S. (1996). Rapid Development: Taming Wild Software Schedules (1st ed.). Microsoft Press. Miller, L. A., Stanney, K. M., & Wooten, W. (1997). Development and evaluation of the Windows-computer-experience-questionnaire (WCEQ). International Journal of Human-Computer Interaction, 9(3). Montag, M., Simonson, M. R., & Maurer, M. M. (1984). Standardized Test of Computer Literacy (STCL). Amers: Iowa State University Research Foundation. MSDN (2008). Visual Basic Developer Center. Myers, B.A. (1990). All the Widgets. SIGGRAPH Video Review Net Applications (2009). Market Share. Norman, Donald A. (1983). Some Observations on Mental Models. In: Gentner, Dedre and Stevens, Albert L., Mental Models. Hillsdale, NJ: Lawrence Erlbaum Associates Polanyi, M. (1966). Tacit Dimension 1ST Edition. DOUBLEDAY & CO INC. Potosky, D. (2007). The Internet knowledge (iknow) measure. Computers in Human Behavior, 23(6), Preim, B. (1999). Entwicklung interaktiver Systeme (1. Aufl., S. 557). Springer, Berlin. Pyrczak, F. (1990). Development of diagnostic tests for computer literacy. Computers & Education, 14(3),

91 Literaturverzeichnis 91 Reisig, J. (2007). Blog» jquery UI: Interactions and Widgets. Reisig, J. (2008). Blog» jquery, Microsoft, and Nokia. Richter, T., Naumann, J. & Groeben, N. (2001). Das Inventar zur Computerbildung (INCOBI): Ein Instrument zur Erfassung von Computer Literacy und computerbezogenen Einstellungen bei Studierenden der Geistes- und Sozialwissenschaften. Psychologie in Erziehung und Unterricht, 48, Richter, T., Naumann, J. & Noller, S. (1999). Computer Literacy und computerbezogene Einstellungen: Zur Vergleichbarkeit von Online- und Paper-Pencil-Erhebungen. In U.-D. Reips, B. Batinic, W. Bandilla, M. Bosnjak, L. Gräf, K. Moser & A. Werner (Eds./Hrsg.). Royce, W. (1970). Managing the Development of Large Software Systems. In Proc. IEEE Wescon (pp. 9, 1). Schacter, D., Wagner, A. & Buckner, R. (2000). Memory systems of In E. Tulving & F. Craik (Eds.), The Oxford handbook of memory (pp ). New York: Oxford University Press. Schumacher, P., & Morahan-Martin, J. (2001). Gender, Internet and computer attitudes and experiences. Computers in Human Behavior, 17(1), Sengpiel, M. & Dittberner, D. (2008). The computer literacy scale (CLS) for older adults- development and validation. In M. Herczeg & M. C. Kindsmüller (Hrsg.): Mensch & Computer 2008: Viel Mehr Interaktion. München: Oldenbourg Verlag, S Sengpiel, M. & Wandke, H. (accepted for publication). Compensating the effects of age differences in computer literacy on the use of ticket vending machines through minimal video instruction. Occupational Ergonomics. Smith, B., Caputi, P., & Rawstorne, P. (2000). Differentiating computer experience and attitudes toward computers: an empirical investigation. Computers in Human Behavior, 16(1), Smith, B., Caputi, P., & Rawstorne, P. (2007). The development of a measure of subjective computer experience. Computers in Human Behavior, 23. Sneed, H. (1983). Software-Wartungsorganisation, in: Tagungsband des Struktur-Kongresses 83, CDi, Frankfurt, Nov Struve, D., Sengpiel, M. und Wandke, H. (2006). Adaptive Lernunterstützung zur interaktiven Systemnutzung für ältere Benutzer (ALISA). Zeitschrift für Arbeitswissenschaft 3/2006, Sun (2008). Java EE Server and Container. Sun (2008). JSF LifeCycle.

92 Literaturverzeichnis 92 Turner, G. M., Sweany, N. W., & Husman, J. (2000). Development of the Computer Interface Literacy Measure. Journal of Educational Computing Research, 22(1), W3C (2008). Accessible Rich Internet Applications (WAI-ARIA) Version Wagener, D. (2003). Der Computerwissenstest CWIS-4: Befunde zur Reliabilität und Validität. Zeitschrift für Personalpsychologie, 2(4), Winter, S. J., Chudoba, K. M., & Gutek, B. A. (1997). Misplaced resources? Factors associated with computer literacy among end-users. Information & Management, 32(1), doi: /S (96) Zeißig, N. (2008) Online Fragebogen zur Erfassung der Computer Literacy bei älteren Menschen, Studienarbeit Alle im Text aufgeführten URLs wurden zuletzt am 8. Juni 2009 auf deren Erreichbarkeit und den verfügbaren Inhalt in Bezug auf diese Arbeit überprüft.

93 Abbildungsnachweis 93 Abbildungsnachweis Abbildung 1: Bezug mentaler Modelle zur Usability von technischen Systemen (Sengpiel & Wandke, 2009) 10 Abbildung 2: Beispiel Inventar zur Computerbildung - SUCA 14 Abbildung 3: Beispiel Inventar zur Computerbildung - VECA 14 Abbildung 4: Beispiel Inventar zur Computerbildung - TECOWI 15 Abbildung 5: Beispiel Inventar der Computerbildung - PRACOWI 15 Abbildung 6: Beispiel Inventar der Computerbildung - FIDEC 15 Abbildung 7: Teil A (CLS-Exp) der Computer Literacy Scale 16 Abbildung 8: Teil B (CLS-ST) der Computer Literacy Scale 17 Abbildung 9: Schematische Darstellung des Wasserfall-Modells (nach Royce, 1970) 18 Abbildung 10: Ausbaustufen eines Softwareprodukts (Balzert, 2008) 19 Abbildung 11: Schematische Darstellung d. inkrementellen Modells (Balzert, 2000) 20 Abbildung 12: Vorgehen nach dem evolutionärem Modell (Balzert, 2008) 22 Abbildung 13: Schematischer Überblick Planungsphase (Balzert, 2000) 26 Abbildung 14: UML Umweltdiagramm Basisversion der WDP 29 Abbildung 15: Durch Akteure und Geschäftsprozesse modellierte Umwelt der WDP 30 Abbildung 16: Überblick Definitionsphase (Balzert, 2000) 30 Abbildung 17: Komponenten der OOA 32 Abbildung 18: Überblick Entwurfsphase (Balzert, 2000) 33 Abbildung 19: Vom Fachkonzept zur Anwendung (nach Balzert, 2000) 34 Abbildung 20: Client/Server- sowie Web-Architektur bei Java EE (Sun, 2009) 35 Abbildung 21: Beispiel eines UI-Designers 38 Abbildung 22: JSF Lifecycle (Sun, 2008) 40 Abbildung 23: Einordnung von jboss Seam 42 Abbildung 24: Übersicht Implementierungsphase (Balzert, 2000) 43 Abbildung 25: Resultierende Ausgabe der Spracheinstellung 45 Abbildung 26: Authentisierung am und Authentifizierung durch das System 46 Abbildung 27: Von Javadoc generiertes HTML 48 Abbildung 28: Abnahme- und Einführungsprozess (Balzert, 2000) 50 Abbildung 29: Aufwandsverteilung von Wartung und Pflege (Balzert, 2000) 51 Abbildung 30: Klassifizierung von Interaktionsformen (nach Herczeg, 2006) 53 Abbildung 31: Bella Pro Series Video Editing Keyboard 3.0 FCP (Bella, 2008) 55 Abbildung 32: Abgeleitete Taxonomie von Widgets 57

94 Abbildungsnachweis 94 Abbildung 33: Beispielhafte Präsentation einer Listbox (MSDN, 2008) 58 Abbildung 34: Beispielhafte Präsentation einer Combobox (MSDN, 2008) 58 Abbildung 35: Beispielhafte Präsentation einer Radiogroup (Java2s, 2008) 58 Abbildung 36: Beispielhafte Präsentation eines Menüs (gtkmm, 2008) 59 Abbildung 37: Beispielhafte Präsentation eines Trees (dhtmlx, 2008) 59 Abbildung 38: Beispielhafte Präsentation von Checkboxen (Java2s, 2008) 59 Abbildung 39: Beispielhafte Präsentation einer Textbox (codeproject, 2008) 60 Abbildung 40: Beispielhafte Präsentation eines Range als Slider (dhtmlx, 2008) 60 Abbildung 41: Beispielhafte Präsentation eines Range als Spinbutton (laas02, 2008) 60 Abbildung 42: Beispielhafte Präsentation von Menuitems (Java2s, 2008) 61 Abbildung 43: Abbildung Szenario 1 zur Erfassung deiktischer Interaktionen 62 Abbildung 44: Alternative Möglichkeiten zur Selektion eines Objekts 63 Abbildung 45: Abbildung Szenario 2 zur Erfassung metaphorischer Interaktionen 65 Abbildung 46: File und Edit Menü in aufgeklappter Form 66 Abbildung 47: Aufgeklapptes Kontextmenü 66 Abbildung 48: Papierkorbmetapher mit 2 Zuständen 67 Abbildung 49: Drag & Drop von Ordner B2 auf den Papierkorb 67 Abbildung 50: Szenario 3 - eine Flugbuchung 68 Abbildung 51: Auswahl des korrekten Flugziels 69 Abbildung 52: Kalender zur Auswahl des Flugdatums 69 Abbildung 53: Auswahl der Mitreisenden 70 Abbildung 54: Übersicht Szenario 4 - Farbeneinkauf 71 Abbildung 55: Beispiel für Tooltip 71 Abbildung 56: Reiter Farbe & Menge Szenario 4 72 Abbildung 57: Reiter Anbieter und Versand Szenario 4 72 Abbildung 58: Sortieren einer Tabellenspalte 73 Abbildung 59: Ändern der Menge angezeigter Objekte 73 Abbildung 60: Darstellung eines Pagers 73 Abbildung 61: Anbindung interaktiver Szenarien an die WDP 77 Abbildung 62: Einbindung von Szenarien mit Hilfe von Highslide 78 Abbildung 63: Kommunikation zwischen WDP und einem Szenario 79 Abbildung 64: Neu eingeführte Entität InteractiveItem 81 Abbildung 65: Neuer Authentisierungs- und Authentifizierungsablauf 82 Abbildung 66: Mozilla Firebug im Firefox 83

95 Abbildungsnachweis 95 Abbildung 67: Automatisch generierte Übersichtsseite in Mantis 84 Abbildung 68: CLS online - Allgemeiner Teil (CLS-Exp) 100 Abbildung 69: CLS online - Zuordnung Symbole und Begriffe (CLS-ST) 101 Abbildung 70: CLS online - vier interaktive Szenarien (CLS-IA) 102 Abbildung 71: Umsetzung der Schichtenarchitektur (ICEfaces, 2008) 105 Abbildung 72: Paketdiagramm Backend WDP 109 Abbildung 73: Zusammenspiel aller Entity Beans 111 Abbildung 74: Attribute und Methoden der Klasse Questionnaire 113 Abbildung 75: Attribute und Methoden der Klasse Topic 114 Abbildung 76: Klasse Segment mit Attributen und Methoden 114 Abbildung 77: Question Klasse mit Attributen und Methoden 115 Abbildung 78: Klassendiagramm Items 117 Abbildung 79: Klasse Scale 117 Abbildung 80: Klassendiagramm users 118 Abbildung 81: Klasse Reply mit Attributen und Methoden 119 Abbildung 82: Klasse Export 119 Abbildung 83: Session Bean Authenticator 120 Abbildung 84: Session Bean EditSubject 121 Abbildung 85: Session Bean Evaluator 121 Abbildung 86: Session Bean SurveyManager 122 Abbildung 87: Klasse UserSession 123 Abbildung 88: Klassendiagramm Utils. 123 Abbildung 89: Klassendiagramm Components 123

96 Tabellen 96 Tabellen Tabelle 1: Vor- und Nachteile des inkrementellen Modells (nach Balzert, 2008) 21 Tabelle 2: Tabellarische Übersicht der Planungsphase 27 Tabelle 3: Ermittelte Akteure der WDP 29 Tabelle 4: Beschreibung eines Geschäftsprozesses 29 Tabelle 5: Beispiele für Javadoc Tags 48 Tabelle 6: Auswahl möglicher Selektoren in jquery 75 Tabelle 7: Grundlegende Pakete der WDP 110

97 Listings 97 Listings Listing 1: Auszug CILM-SR (Turner et al., 2000) 13 Listing 2: Auszug CILM-KA (Turner et al., 2000) 14 Listing 3: Muster eines Lastenhefts (Balzert, 2000) 28 Listing 4: Ausschnitt der Datei messages_custom_zh.native 44 Listing 5: Laden eines Ressourcenbündels in JSF 44 Listing 6: Zugriff auf eine externe Ressource in JSF 44 Listing 7: Verwendung der Methode getdisplaystring 45 Listing 8: Implementierung der Methode getdisplaystring 45 Listing 9: Actionlink in JSF zum Wechseln der Sprache 45 Listing 10: Ausschnitt der Datei messages_custom_zh.properties 46 Listing 11: Interaktionen im Persistenzkontext mittels eines EntityManagers 47 Listing 12: Verwendung von Javadoc Tags im Quelltext 48 Listing 13: Beispiel eines Ant Targets 49 Listing 14: Ant Task zum Überführen von UTF Dateien ins ASCII Format 50 Listing 15: Einbindung von jquery in eine HTML Seite 75 Listing 16: Beispiel jquery $(document).ready(function) 75 Listing 17: Beispiel Builder Pattern in jquery 75 Listing 18: Beispiel jquery HTML Links 76 Listing 19: Zuweisen einer CSS Klasse mit jquery 76 Listing 20: Entfernen einer CSS Klasse mit jquery 77 Listing 21: Einbindung des Highslide Frameworks in eine HTML Seite 79 Listing 22: Zurückschreiben von Ergebnissen per JavaScript 80 Listing 23: Format eines serialisierten Ergebnisses 80 Listing 24: Aufruf der Firebug Console 82 Listing 25: In Java implementierte Authentifizierung 106 Listing 26: Konfiguration der Persistenzschnittstelle in der persistence.xml 107 Listing 27: Konfiguration von Seam-gen 107 Listing 28: Ausgabe des Programms Seam beim Anlegen eines Projekts 108 Listing 29: Beispiel einer Entity Bean mit ID Generierung 112 Listing 30: Überschriebene tostring Methode 112 Listing 31: Comparator TOPIC_ORDER 113 Listing 32: Prüfung auf vollständige Bearbeitung einer Frage 115

98 Anhang Glossar 98 A.1 Glossar Ajax Asynchronous JavaScript and XML ALISA Adaptive Lernunterstützung zur Interaktiven Systemnutzung Älterer Akteur Ist jemand, der an einem Geschehen aktiv und unmittelbar beteiligt ist. (Balzert, 2000) CL Computer Literacy. Siehe Definition Kapitel 2.3 CLS Von Michael Sengpiel und Diana Dittberner entworfene Computer Literacy Scale. Diese setzt sich aus zwei Teilen zusammen: CLS- Exp (experience) und CLS-ST (symbols & terms). Die in dieser Arbeit entwickelte Onlineversion wurde weiterhin um die CLS-IA (interactive) erweitert (vgl. Kapitel 5). DFG Die Deutsche Forschungsgemeinschaft ist die zentrale Selbstverwaltungseinrichtung der Wissenschaft zur Förderung der Forschung an Hochschulen und öffentlich finanzierten Forschungsinstitutionen in Deutschland. EJB Enterprise Java Beans sind ein auf Java basierendes serverseitiges Komponenten-Modell. Entity Bean Persistente Daten-Komponente der EJB Spezifikation. Framework Ein Rahmenwerk (framework) ist ein durch den Software-Entwickler anpassbares oder erweiterbares System kooperierender Klassen, die einen wiederverwendbaren Entwurf für einen bestimmten Anwendungsbereich implementieren. (Balzert, 2000, S. 834). feasibiliy study Durchführbarkeitsuntersuchung während der Planungsphase. Geschäftsprozessammenhängenden Aufgaben, die von einem Akteur durchgeführt Ein Geschäftsprozess (engl. use case) besteht aus mehreren zu- werden, um ein Ziel zu erreichen bzw. ein gewünschtes Ergebnis zu erstellen. Glue Code Programmcode, der keinen direkten Beitrag dazu leistet die Programmspezifikationen zu erfüllen. Vielmehr ist er notwendig, um einzelne Komponenten zusammen zu kleben, die anderenfalls inkompatibel wären. Halbfabrikat Siehe Komponente Incobi Akronym: Inventar zur Computerbildung inside-out- Von innen nach außen werden zunächst die Produktinterna und Methode dann die Schnittstellen zur Umwelt eines Produkts modelliert. (Balzert, 2000, S. 64). vgl. outside-in-methode

99 Anhang Glossar 99 J2EE Java EE JSF Komponente persistent OOA OOD OOP outside-in- Methode Pattern Session Bean transient UML use case VL VP WDP Webanwendung Widget Siehe Java EE Java EE oder ehemals J2EE steht für Java Plattform Enterprise Edition. Es handelt sich hierbei um eine Spezifikation für Softwarearchitekturen, welche seit 1999 ständig weiter entwickelt wird und aktuell in Version 5 vorliegt. Java Server Faces sind ein Framework-Standard zur Entwicklung von Benutzeroberflächen für Webapplikationen. Ein Halbfabrikat bzw. eine Komponente (engl. component) ist ein in sich abgeschlossener Softwarebaustein, der eine anwendungsorientierte, semantisch zusammengehörende Funktionalität besitzt, die nach außen über Schnittstellen zur Verfügung gestellt wird. (Balzert, 2008, S. 532). Über die Laufzeit des Programms hinweg, dauerhaft gespeicherte Daten. Ablage zum Beispiel in einer Datenbank. Objektorientierte Analyse Objektorientiertes Design Objektorientierte Programmierung Von außen nach innen wird zunächst die Umwelt eines Produkts bzw. Systems modelliert und davon ausgehend die Produktinterna. (Balzert, 2000, S. 64). vgl. inside-out-methode (Muster) Idee, die sich in der Praxis bewährt hat. Prozess-Komponente der EJB Spezifikation, meist transient. Flüchtige Daten, die ihre Lebensdauer mit dem Laufzeitende des Programms beenden. vgl. persistent Unified Modeling Language. Standardisierte Sprache für die Entwicklung von Software und anderen Systemen. Siehe Geschäftsprozess Versuchsleiter Versuchsperson Webbasierte Diagnoseplattform Software-Produkt, dessen Benutzeroberfläche im Webbrowser angezeigt wird. Ein Widget oder Applet ist ein kleines Computerprogramm, das nicht als eigenständige Anwendung betrieben wird, sondern in eine grafische Benutzeroberfläche oder Webseite eingebunden wird.

100 Anhang Screenshots 100 A.2 Screenshots A.2.1 CLS-Exp online Abbildung 68: CLS online - Allgemeiner Teil (CLS-Exp)

101 Anhang Screenshots 101 A.2.2 CLS-ST online Abbildung 69: CLS online - Zuordnung Symbole und Begriffe (CLS-ST)

102 Anhang Screenshots A.2.3 CLS-IA online Abbildung 70: CLS online - vier interaktive Szenarien (CLS-IA) 102

103 Anhang Artefakte 103 A.3 Artefakte A.3.1 Lastenheft der Basisversion der WDP 1 Zielbestimmung Der psychologische Lehrstuhl der Humboldt Universität führt Umfragen in Form von Fragebögen durch. Durch das Produkt sollen diese Fragebögen online verwaltet, ausgefüllt und ausgewertet werden können. 2 Produkteinsatz Das Produkt dient der Verwaltung, Durchführung und Auswertung beliebiger Befragungen am psychologischen Lehrstuhl für Psychologie. Darüber hinaus müssen die Versuchsleiter sowie Versuchspersonen im System erfasst werden. Versuchspersonen können sich jederzeit am System anmelden und an einer Befragung teilnehmen. Versuchsleiter können Umfrageergebnisse auswerten und exportieren sowie neue Versuchspersonen anlegen. 3 Produktübersicht Umweltdiagramm

104 Anhang Artefakte Produktfunktionen /LF10/ Prozess Registrierung Akteure Versuchsleiter, Versuchsperson Beschreibung Versuchspersonen können sich selbst für die Nutzung des Systems registrieren. Versuchsleiter können dritte Personen oder ganze Nutzerserien anlegen. /LF20/ Prozess Akteure Beschreibung /LF30/ Prozess Akteure Beschreibung /LF40/ Prozess Akteure Beschreibung An- und Abmelden Versuchsleiter, Versuchsperson Akteure können sich am System an- und abmelden. Umfrage/Test anlegen Versuchsleiter Versuchsleiter können neue Umfragen/ Tests kreieren und für die Benutzung im System freigeben. Umfrage/Test absolvieren Versuchsperson Angemeldete Versuchspersonen können an Umfragen oder Tests teilnehmen. /LF50/ Prozess Umfrage/Test auswerten Akteure Versuchsleiter Beschreibung Versuchsleiter können erhobene Daten für weitere Auswertungen exportieren. 5 Produktdaten /LD10/ Versuchsleiterdaten (max. 100) /LD20/ Versuchspersonendaten (max ) /LD30/ Fragebogendaten (max. 100) /LD40/ Antwortdaten (max ) 6 Produktleistungen /LL10/ Die Funktion /LF50/ darf nicht länger als 30 Sekunden Antwortzeit benötigen. /LL20/ Alle Reaktionszeiten auf Benutzeraktionen müssen unter 7 Sekunden liegen (außer Funktion /LF50/)

105 Anhang Artefakte Qualitätsanforderungen Produktqualität sehr gut gut normal nicht relevant Funktionalität x Zuverlässigkeit x Benutzbarkeit x Effizienz x Änderbarkeit x Übertragbarkeit x 8 Ergänzungen Funktion /LF30/ wird in weiteren Projekten umgesetzt. Als erster Fragebogen wird die CLS umgesetzt. Einige Versuchspersonen füllen Fragebögen nicht komplett aus, es wäre wünschenswert, die bis zum Abbruch eingegebenen Daten zu speichern. A.3.2 Systemarchitektur Abbildung 71 zeigt die Architektur des Projekts unter Berücksichtigung aller in der Entwurfsphase getroffenen Entscheidungen. Als JavaEE (ehemals J2EE) Server kommt ein jboss Applikationsserver zum Einsatz. Bei der verwendeten Datenbank handelt es sich um MySQL. Abbildung 71: Umsetzung der Schichtenarchitektur (ICEfaces, 2008)

106 Anhang Artefakte 106 A.3.3 Quellcodes und Konfigurationen A Authentifizierung Identity scope=scopetype.session) 3 User currentuser; public boolean authenticate() { 5 try { currentuser = (User) entitymanager.createquery( select u from User u where 7 u.username = #{identity.username} and u.password = #{identity.password} ).getsingleresult(); 9 } catch (PersistenceException e) { return false; 11 } 13 if (currentuser instanceof Investigator) { identity.addrole( admin ); 15 } if (currentuser instanceof Subject) { 17 identity.addrole( subject ); } 19 FacesContext ctx = FacesContext.getCurrentInstance(); 21 HttpServletRequest request = (HttpServletRequest)ctx.getExternalContext().getRequest(); 23 String agent = request.getheader( user-agent ); if (agent.indexof( Firefox ) > -1) return true; 25 return false; } Listing 25: In Java implementierte Authentifizierung

107 Anhang Artefakte 107 A Persistenzkontext 1 <persistence-unit name= ALISA > <provider>org.hibernate.ejb.hibernatepersistence</provider> 3 <jta-data-source>java:/alisadatasource</jta-data-source> <properties> 5 <property name= hibernate.dialect value= org.hibernate.dialect.mysqldialect /> <property name= hibernate.show_sql value= true /> 7 <property name= jboss.entity.manager.factory.jndi.name value= java:/alisaentitymanagerfactory /> 9 </properties> </persistence-unit> Listing 26: Konfiguration der Persistenzschnittstelle in der persistence.xml A Konfiguration und Erstellung eines Projekts mit Seam Wird das Werkzeug Seam mit dem Parameter seam-setup aufgerufen, kann die Konfiguration eines Java EE Projekts vorgenommen werden. Listing 27 zeigt die Eingabe der Konfiguration für die webbasierte Diagnoseplattform. Macintosh-6:jboss-seam GA nzeissig$./seam setup Buildfile: build.xml init: setup: [echo] Welcome to seam-gen :-) [input] Enter your Java project workspace (the directory that contains your Seam projects) [/Users/nzeissig/Documents/workspace/] [/Users/nzeissig/Documents/workspace/] [input] Enter your JBoss home directory [/usr/local/jboss ga/] [/usr/local/jboss ga/] [input] Enter the project name [ALISA] [ALISA] [echo] Accepted project name as: ALISA [input] Select a RichFaces skin (not applicable if using ICEFaces) [bluesky] ([bluesky], classic, ruby, wine, deepmarine, emeraldtown, sakura, DEFAULT) [input] Is this project deployed as an EAR (with EJB components) or a WAR (with no EJB support) [ear] ([ear], war, ) [input] Enter the Java package name for your session beans [de.nzberlin.www] [de.nzberlin.www] [input] Enter the Java package name for your entity beans [de.nzberlin.www] [de.nzberlin.www] [input] Enter the Java package name for your test cases [de.nzberlin.alisa.test] [de.nzberlin. [input] What kind of database are you using? [mysql] (hsql, [mysql], oracle, postgres, mssql, db2, sybase, enterprisedb, h2) [input] Enter the Hibernate dialect for your database [org.hibernate.dialect.mysqldialect] [org.hibernate.dialect.mysqldialect] [input] Enter the filesystem path to the JDBC driver jar [lib/hsqldb.jar] [lib/hsqldb.jar] [input] Enter JDBC driver class for your database [com.mysql.jdbc.driver] [com.mysql.jdbc.driver] [input] Enter the JDBC URL for your database [jdbc:mysql://localhost/alisa] [jdbc:mysql://localhost/alisa] [input] Enter database username [root] [root] [input] Enter database password [] [] [input] skipping input as property hibernate.default_schema.new has already been set. [input] Enter the database catalog name (it is OK to leave this blank) [] [] [input] Are you working with tables that already exist in the database? [n] (y, [n], ) [input] Do you want to drop and recreate the database tables and data in import.sql each time you deploy? [y] ([y], n, ) [input] Enter your ICEfaces home directory (leave blank to omit ICEfaces) [/Applications/ICEfaces SP1-bin/icefaces] [/Applications/ICEfaces SP1-bin/icefaces] [delete] Deleting: /usr/local/jboss-seam ga/seam-gen/build.properties [propertyfile] Creating new property file: /usr/local/jboss-seam ga/seam-gen/build.properties [echo] Installing JDBC driver jar to JBoss server [echo] Type seam create-project to create the new project BUILD SUCCESSFUL Total time: 2 minutes 19 seconds Listing 27: Konfiguration von Seam-gen

108 Anhang Artefakte 108 Nach Eingabe der notwendigen Konfiguration, kann das Werkzeug Seam mit dem Parameter create-project aufgerufen werden. Die Ausgabe von Seam zeigt Listing 28. Macintosh-6:jboss-seam GA nzeissig$./seam create-project Buildfile: build.xml init: init-properties: [echo] /usr/local/jboss ga/ validate-workspace: validate-project: icefaces-staging-copy: [echo] Set up the icefaces directory [copy] Copying 45 files to /usr/local/jboss-seam ga/seam-gen/icefaces-staging initcopy: initpoms: [echo] Setting up dependencies [copy] Copying 1 file to /usr/local/jboss-seam ga/classes/poms [artifact:install] [INFO] Installing /usr/local/jboss-seam ga/classes/poms/root.pom to /Users/nzeissig/.m2/repository/org/jboss/seam/root/2.0.0.GA/root GA.pom [copy] Copying 1 file to /usr/local/jboss-seam ga/classes/poms [artifact:install] [INFO] Installing /usr/local/jboss-seam ga/classes/poms/parent.pom to /Users/nzeissig/.m2/repository/org/jboss/seam/parent/2.0.0.GA/parent GA.pom [copy] Copying 1 file to /usr/local/jboss-seam ga/classes/poms [copy] Copying 1 file to /usr/local/jboss-seam ga/classes/poms [copy] Copying 1 file to /usr/local/jboss-seam ga/classes/poms [copy] Copying 1 file to /usr/local/jboss-seam ga/classes/poms [copy] Copying 1 file to /usr/local/jboss-seam ga/classes/poms [copy] Copying 1 file to /usr/local/jboss-seam ga/classes/poms [copy] Copying 1 file to /usr/local/jboss-seam ga/classes/poms [copy] Copying 1 file to /usr/local/jboss-seam ga/classes/poms copyseam: copyseamdependencies: copyjbossembedded: copy-lib: [echo] Copying Seam and depdencies to the /Users/nzeissig/Documents/workspace//ALISA/lib directory... [copy] Copying 100 files to /Users/nzeissig/Documents/workspace/ALISA/lib [echo] Copying JBoss Embedded configuration to the /Users/nzeissig/Documents/workspace//ALISA/bootstrap directory... [copy] Copying 31 files to /Users/nzeissig/Documents/workspace/ALISA/bootstrap [copy] Copied 33 empty directories to 21 empty directories under /Users/nzeissig/Documents/workspace/ALISA/bootstrap file-copy-war: file-copy-ear: [echo] Copying resources needed for EAR deployment to the /Users/nzeissig/Documents/workspace//ALISA/resources directory... [copy] Copying 1 file to /Users/nzeissig/Documents/workspace/ALISA/resources/WEB-INF [copy] Copying 1 file to /Users/nzeissig/Documents/workspace/ALISA [copy] Copying 6 files to /Users/nzeissig/Documents/workspace/ALISA/resources setup-filters: file-copy: [copy] Copying 11 files to /Users/nzeissig/Documents/workspace/ALISA/resources [copy] Copying 1 file to /Users/nzeissig/Documents/workspace/ALISA [copy] Copying 1 file to /Users/nzeissig/Documents/workspace/ALISA [copy] Copying 1 file to /Users/nzeissig/Documents/workspace/ALISA/resources [copy] Copying 1 file to /Users/nzeissig/Documents/workspace/ALISA/.settings [copy] Copying 1 file to /Users/nzeissig/Documents/workspace/ALISA/resources [copy] Copying 1 file to /Users/nzeissig/Documents/workspace/ALISA/resources [copy] Copying 1 file to /Users/nzeissig/Documents/workspace/ALISA/resources [copy] Copying 1 file to /Users/nzeissig/Documents/workspace/ALISA/resources [copy] Copying 1 file to /Users/nzeissig/Documents/workspace/ALISA/resources [copy] Copying 11 files to /Users/nzeissig/Documents/workspace/ALISA/view [copy] Copying 10 files to /Users/nzeissig/Documents/workspace/ALISA/view [copy] Copying 3 files to /Users/nzeissig/Documents/workspace/ALISA/src/action/de/nzberlin/ALISA [copy] Copying 6 files to /Users/nzeissig/Documents/workspace/ALISA [mkdir] Created dir: /Users/nzeissig/Documents/workspace/ALISA/src/model [mkdir] Created dir: /Users/nzeissig/Documents/workspace/ALISA/src/test [copy] Copying 1 file to /Users/nzeissig/Documents/workspace/ALISA/src/test [mkdir] Created dir: /Users/nzeissig/Documents/workspace/ALISA/nbproject [copy] Copying 3 files to /Users/nzeissig/Documents/workspace/ALISA/nbproject create-project: [echo] A new Seam project named ALISA was created in the /Users/nzeissig/Documents/workspace/ directory [echo] Type seam explode and go to [echo] Eclipse Users: Add the project into Eclipse using File > New > Project and select General > Project (not Java Project) [echo] NetBeans Users: Open the project in NetBeans BUILD SUCCESSFUL Total time: 8 seconds Listing 28: Ausgabe des Programms Seam beim Anlegen eines Projekts

109 Anhang Artefakte 109 A.3.4 Paketdiagramm In diesem Kapitel werden die Pakete der WDP vorgestellt, wie sie nach Abschluss der ersten Ausbaustufe (vgl. Kapitel 5) vorlagen. Abbildung 72 zeigt das Paketdiagramm des Backends der WDP sowie die zusätzlich verwendeten Pakete von Drittanbietern. Aufgrund der Komplexität und der Anzahl der verwendeten Zusatzpakete sind primär die Paketabhängigkeiten der selbst entwickleten Komponenten eingetragen. Abhängigkeiten der verwendeten Frameworks wie Seam, EJB, ICEfaces oder Hibernate sind nicht enthalten und können in den entsprechenden Produktinformationen nachgelesen werden. Abbildung 72: Paketdiagramm Backend WDP Die komplette Datenhaltung der Anwendung ist im Paket entitybeans gekapselt. Der Anwendungsteil hingegen befindet sich im Paket sessionbeans. Die Unterteilung verdeutlicht nicht nur die Trennung zwischen Datenmodell und Anwendungslogik, sondern unterstreicht auch die damit in Java Enterprise Beans verbundene Umsetzung. Alle Interfaces der Klassen des Pakets sessionbeans sind im Paket interfaces zusammengefasst. Darüber hinaus gibt es ein Paket components, welches eigenentwickelte JSF Komponenten beinhaltet. Das Paket utils beeinhaltet gemeinsam genutze Werkzeuge. Tabelle 7 beschreibt die grundlegenden Pakete der WDP.

110 Anhang Artefakte 110 Name Beschreibung eingebundene Pakete entitybeans Alle persistenten Daten eines Systems werden in utils Java Enterprise Beans durch Entity Beans modelliert. Daher sind alle Bestandteile wie Umfragen, Themengebiete, Segmente, Fragen, Antworten, Skalen, Datenexporte sowie Nutzer in diesem Paket zusammengefasst. Die detaillierte Beschreibung der Klassen und der weiteren Unterteilung in Teilpakete erfolgt in Kapitel A.3.5. sessionbeans In Java Enterprise Beans erfolgt die Abbildung von utils Interaktionen eines Nutzers mit dem System durch entitybeans Session Beans. Aktionen wie das Authentifizieren jboss.seam am System, das Anlegen und Ändern von Nutzerdaten, die Beantwortung von Fragen, die Auswertung apache javax von Fragebögen sowie der Export von Datensätzen ins Excelformat werden in diesem Paket zusammengefasst. Eine Beschreibung der Klassen findet in Ka- hibernate com.icesoft pitel A.3.6 statt. utils Das Paket Utils umfasst mehrfach genutzte Werkzeuge. Eine Klasse übernimmt das Schreiben von apache exportfertigen Excelsheets. Die andere realisiert die Übersetzung von technischen Begriffen in die gewählte Sprache des Nutzers. Das Paket wird in Kapitel A.3.7 beschrieben. components Trotz der vielseitig einsetzbaren JSF Standardkomponenten und der durch die Verwendung von ICE- javax com.icesoft faces eingebundenen Komponentensuite, konnten items einige Spezialfälle nicht abgedeckt werden. Um dennoch die komfortablen Vorteile von JSF zu nutzen, ist es möglich, sogenannte Custom Components zu schreiben. Diese sind im Paket components zusammengefasst und werden in Kapitel A.3.8 beschrieben. Tabelle 7: Grundlegende Pakete der WDP

111 Anhang Artefakte 111 A.3.5 Entitybeans Da das Paket aller dem Datenmodell zugrundeliegenden Entity Beans sehr groß ist, können an dieser Stelle nicht alle Klassen inklusive ihrer Methoden in einem Klassendiagramm dargestellt werden. Abbildung 73 zeigt alle Komponenten im Überblick sowie die wichtigsten Beziehungen untereinander. << Entity>> Questionnaire { table=questionnaires} topiclist << Entity>> segmentlist << Entity>> questionlist Topic Segment 1..* { table=topics} 1..* { table=segments} 1..* << Entity>> Question { table=questions} items itemlist 1..* << Entity>> A Item { table=items} << Entity>> A MappingItem << Entity, P Persistence>> << Entity, P Persistence>> InteractiveItem MetricItem {discriminator_value="interactive"} {discriminator_value="metric"} << Entity, P Persistence>> << Entity, P Persistence>> NominalItem OrdinalItem {discriminator_value="nominal"} {discriminator_value="ordinal"} << Entity, P Persistence>> MappingItemText {discriminator_value="mappingimage"} << Entity, P Persistence>> MappingItemImage {discriminator_value="mappingimage"} exports replies scales scale 1..* users << Entity>> Export { table=exports} << Entity>> Replie { table=replies } << Entity>> Scale { table=scales} << Entity>> A User { table=users} << Entity, P Persistence>> Investigator {discriminator_value="admin"} << Entity, P Persistence>> Subject {discriminator_value="subject"} Abbildung 73: Zusammenspiel aller Entity Beans Für alle in dieser Arbeit implementierten Klassen gelten allgemeine Regeln. A Allgemeine Regeln Alle Attribute werden ausschließlich über sogenannte Getter ausgelesen und über Setter geschrieben. Dies ist inbesondere für den Einsatz des jboss Seam Frameworks und die Verwendung von Java Server Faces notwendig. Attribute von Beans können im Frontend dadurch direkt referenziert werden. Alle Klassen, die java.io.serializable implementieren, sollten eine serialversionuid besitzten, welche beim Serialisieren des Objekts mit abgelegt wird und beim späteren Deserialisieren mit der des aktuell geladenen.class-files verglichen werden kann. Darüber hinaus benötigt jedes Objekt eine eindeutige ID, welche für alle Entity

112 Anhang Artefakte 112 Beans in diesem Projekt automatisch unter Zuhilfenahme von Annotationen generiert wird. Listing 29 zeigt eine exemplarische Bean mit den benötigten Gettern und Settern sowie den benutzten Annotationen. 1 import javax.persistence.generatedvalue; import javax.persistence.id; 3 import javax.persistence.column; 5 import...; public class Example implements Serializable{ 7 private static final long serialversionuid = L; 9 exampleid ) public long getexampleid() { 13 return exampled; 15 } public void setexampleid(long exampleid) { 17 this.exampleid = exampleid; } Listing 29: Beispiel einer Entity Bean mit ID Generierung Neben den persistent in der Datenbank abgelegten Attributen werden auf bestimmten Objekten einiger Klassen zusätzlich flüchtige (engl. transient) Daten gespeichert. Beispielsweise verfügt jedes Objekt, welches dem Benutzer der Webanwendung im Webbrowser angezeigt wird, über die beiden Attribute display- Name und displaydescription. In diesen wird die für den aktuellen Kontext (für die gewählte Sprache) die passende Übersetzung abgelegt. Dies geschieht unter Verwendung der Klasse utils.multilanguage. Oftmals ist es sinnvoll, die tostring Methode eines Objekts zu überschreiben, z.b. um diese für Debugfunktionalitäten zu nutzen (vgl. Listing 30). public String tostring(){ 3 return Question(Name: + name + ID: + questionid + ItemList: + itemlist + ) ; 5 } Listing 30: Überschriebene tostring Methode

113 Anhang Artefakte 113 A Questionnaire Die Klasse Questionnaire realisiert das oberste Containerelement einer jeden Umfrage/ eines jeden Tests. Objekte der Klasse Questionnaire besitzen neben den in Kapitel A beschriebenen Attributen einen Namen sowie eine Beschreibung. Abbildung 74: Attribute und Methoden der Klasse Questionnaire Ein Objekt dieser Klasse enthält eine Liste mit den ihr zugeordneten Themengebieten (vgl. A.3.5.3). Darüber hinaus besitzt die Klasse eine Vergleichseinrichtung (engl. comparator), welche die Themengebiete in der Liste anhand ihrer Präzedenz sortiert (vgl. Listing 31). 1 static final Comparator <Topic> TOPIC_ORDER = new Comparator<Topic>(){ public int compare(topic t1, Topic t2) { 3 return new Long( t1.getprecedence()).compareto(new Long(t2.getPrecedence())); } 5 } Listing 31: Comparator TOPIC_ORDER A Topic Objekte der Klasse Topic repräsentieren Themengebiete in einer Umfrage. Sie besitzen neben den in Kapitel A beschriebenen Eigenschaften sowie dem Namen und einer Beschreibung zusätzlich eine Präzedenz, welche die Position (die Stelle des Auftretens) auf einem Fragebogen angibt. Weiterhin ist eine Information zum Schwierigkeitsgrad des Themengebiets vermerkt und im Attribut level gespeichert. Dieses wird in der Anwendung gegen das Erfahrungslevel der Versuchsperson geprüft und dementsprechend angezeigt oder nicht.

114 Anhang Artefakte 114 Abbildung 75: Attribute und Methoden der Klasse Topic Ein Themengebiet kann sich weiterhin in einzelne Segmente untergliedern. A Segment Segmente dienen der Untergliederung von Themenkomplexen, wie sie in Kapitel A beschrieben sind. Primär speichern sie eine Liste von Fragen (engl. Questions), welche in Kapitel A erläutert sind. Abbildung 76: Klasse Segment mit Attributen und Methoden A Question Objekte der Klasse Question repräsentieren Fragen oder Fragestellungen in einer Umfrage/ in einem Test. Auf ihnen sind ein oder mehrere Items in einer Liste vereinigt.

115 Anhang Artefakte 115 Abbildung 77: Question Klasse mit Attributen und Methoden Persistent abgelegt werden kann die URL zu einem Bild sowie zu einer HTML Seite. Letztere verweist auf den Ort, an dem ein externes Testszenario läuft (vgl. Kapitel 5.3). Die URL für das Bild kennzeichnet den Ort im Filesystem, an dem ein Screenshot des Szenarios liegt. Dieses Bild wird dem Benutzer der Webanwendung präsentiert (Abbildung 70). Es gibt zusätzlich eine Prüfung, ob alle Items, die zu dieser Frage gehören, abgeschlossen sind. Die Prüfung darauf erfolgt, indem alle Items der Frage iteriert und einzeln geprüft werden. Sobald ein Item nicht bearbeitet wurde, gilt die Frage als nicht vollständig abgeschlossen (vgl. Listing 32). public boolean isdone() { 3 isdone = true; for (Item item: this.getitemlist()){ 5 if (!item.isdone()) isdone = false; } 7 return isdone; } Listing 32: Prüfung auf vollständige Bearbeitung einer Frage A Items Items repräsentieren die kleinsten Elemente auf einem Fragebogen/ in einem Test. Alle vorhergehend aufgezählten Klassen dienen primär der Kategorisierung und Strukturierung. Items hingegen realisieren die Bestandteile, die eine Interaktion der Versuchsperson verlangen. Alle Items besitzen die aus Kapitel A bekannten Attribute wie ID und Name. Darüber hinaus speichert jedes Item, ob es bereits bearbeitet wurde in dem

116 Anhang Artefakte 116 Attribut isdone. Weiterhin wird für die Darstellung im Frontend die Nutzerantwort für die Gesamtdauer der Beantwortung vorgehalten. Da es mehrere Sorten von Items gibt, welche sich sowohl in der Art des erfassten Datenniveaus sowie in der Repräsentation im Frotend unterscheiden, ist es sinnvoll, das Konzept der Vererbung anzuwenden. Das komplette Klassendiagramm zeigt die Abbildung 78. Die Hauptarten von Items sind: NominalItem, zur Erfassung von Zeichenketten, z.b. einem Namen OrdinalItem, zur Erfassung von Zahlen, z.b. dem Alter MetricItem, zur Erfassung von Werten auf Skalen, z.b. die Nutzung von Computern im Allgemeinen mit Einfachantwortmöglichkeit von selten bis sehr oft. Items dieser Klasse besitzen eine Liste vom Typ Scale (vgl. Kapitel A.3.5.7). MappingItem, zur Realisierung von Zuordnungsaufgaben. Diese speichern jeweils ein Bild, welches den zuzuordnenden Gegenstand enthält sowie den Wert (MappingValue), welcher der richtigen Zuordnung entspricht. Die Klasse untergliedert sich nochmals, je nachdem ob es sich beim Gegenstand der Zuordnung um ein Bild/Symbol oder um ein Wort/Text handelt. Diese Art von Items konnte im Frontend nicht mit den von Java Server Faces gelieferten Standardkomponenten abgebildet werden. Deswegen wurde eine eigene JSF Komponente entwickelt, welche ein solches Item im Frontend realisiert. InteractiveItem, zur Realisierung von generischen Items. Die Klasse wurde primär für die Realisierung der in Kapitel 5 beschriebenen interaktiven Szenarien entwickelt, eignet sich aber auch für die Umsetzung beliebiger Items, welche sich an die Schnittstellenspezifikation aus Kapitel halten.

117 Anhang Artefakte 117 Abbildung 78: Klassendiagramm Items A Scale Wie im vorherigen Abschnitt erwähnt, besitzen einige Items eine Liste mit Elementen vom Typ Scale. Durch dieses Konstrukt lässt sich eine Skala realisieren. Jedes Objekt dieser Klasse besitz einen Wert und ein technisches Label. Dieses wird für die Darstellung im Frontend in die jeweilige Nutzersprache übersetzt (vgl. Kapitel 4.4.1). Abbildung 79: Klasse Scale