Stephan Salinger Institut für Informatik Arbeitsgruppe ... · Stephan Salinger, Institut für...

Stephan Salinger

Institut für InformatikArbeitsgruppe Software Engineering

Grundlagen und Basisstrukturen für die Visualisierung konzeptueller Beschreibungen von Programmiermikroprozessen

Stephan Salinger, Institut für Informatik 2/41

Überblick

• Was diese Präsentation will:• Grundlage bilden für eine Diskussion über die Visualisierung von

konzeptionellen Beschreibungen von Programmiermikroprozessen• Speziell soll geklärt werden: In wie weit tragen die bisher

erarbeiteten generischen Kodierkonzepte (Stand: 01.12.2005) bei einer Umsetzung der Visualisierung

• Was diese Präsentation leistet:• Kurzeinführung in das Forschungsumfeld (Thematik und

Methodik), in dem die Visualisierung verwendet werden soll• Beschreibung der entwickelten generischen Kodierkonzepte und

deren Umsetzung mittels der QDA-Software ATLAS.ti

• Was diese Präsentation nicht leistet (aber zum Teil voraussetzt):• Detaillierte Einführung in Paarprogrammierung,

Programmierfehler, qualitative Forschungsmethodiken, GroundedTheory, ATLAS.ti und allgemeine Visualisierungsaspekte

• Festlegung, wie die Visualisierung "aussieht"


Aufbau

1. Einführung in das Umfeld der geplanten Visualisierung• Forschungsgegenstand• Forschungsmethodik• Werkzeug• Probleme

2. Generische Kodierkonzepte3. Umsetzung der generischen Kodierkonzepte in ATLAS.ti4. Grundfunktionalitäten einer Visualisierung


Forschungsgegenstand und-methodik (1)

• Ziel der Forschung: Untersuchung der Arbeitsweise von Programmierern unter verschiedenen Gesichtspunkten• Paarprogrammierung: Zwei Programmierer arbeiten

zusammen an einem Rechner• Entstehung von Programmierfehlern

• Datenerhebung: Detaillierte Beobachtung von Programmiersitzungen• Synchrone Aufzeichnung der Aktivitäten

• Desktop• Video• Audio



• Das Datenmaterial sind beispielsweise Videodateien mit nachstehendem Aufbau



• Analyse der Daten/Forschungsmethodik: Qualitative Analyse des Datenmaterials• z.B. Grounded Theory (GT)

• GT ist keine Theorie, wie der Namen vielleicht vermuten lässt, sondern ein Forschungsstil

• Methodik zur Entwicklung einer datenverankerten Theorie

• GT ist eine handlungs- und interaktionsorientierte Methode der Theorieentwicklung

• Ein Kernarbeitsschritt von GT ist das Kodieren:• Bildung von Konzepten/Kategorien und die Zuordnung von Daten

(Indikatoren) zu diesen- Vereinfacht ausgedrückt: Es werden konzeptionell

beschreibende Labels an bestimmte Stellen im Datenmaterial gehängt (z.B. "Dokumentation lesen")

• GT besteht noch aus einer Vielzahl von weiteren Methodiken, die aber im Detail hier nicht weiter ausgeführt werden sollen



• Analyse der Daten/Kodieren:• GT: Analyse von Daten durch Bildung (und Verfeinerung

und Ordnung) von Konzepten• Phänomene im Datenmaterial werden durch den Kodierer

identifiziert• Im Videomaterial z.B. ein Ausschnitt, in dem etwas "Auffälliges"

passiert

• Ein identifiziertes Phänomen wird mit einem (evtl. neu zu definierenden Konzept) annotiert

• Z.B. mit "Dokumentation heranziehen"

• Konzepte werden in GT also erst im Verlauf des Kodierprozesses gebildet

• GT ist unter diesem Blickpunkt eine explorativeForschungsmethodik

• Als Werkzeug für das Kodieren wird die QDA-SoftwareATLAS.ti verwendet



• Analyse der Daten/ATLAS.ti :



• Analyse der Daten/Kodieren mit ATLAS.ti:• Definieren eines

Abschnittes (Quotation) von Interesse im Videomaterial

• Annotieren des Abschnittes mit Codes

• Evtl. verlinken des Abschnittes mit anderen Abschnitten

• Visualisierung ist ausschließlich über so genannte Networkviews möglich



• Probleme bei der Verwendung von ATLAS.ti:• Programmiermikroprozesse haben eine zeitlichen Verlauf,

dieser kann auf konzeptueller Ebene in ATLAS.ti nicht (gefiltert) visualisiert werden

• Networkviews geben keine Information über die zeitliche (und inhaltliche) Verteilung von Konzepten

• Achtung: Die Annotierung von Konzepten an Videointervalle birgt ein weiteres Problem: Gilt das Konzept über das gesamte Intervall hinweg?

- Die einzige Lösung, das Bilden von sehr kurzen Quotations, ist nicht wirklich praktikabel!

• Keine Muster über die Zeit hinweg erkennbar• Keine Visualisierung von auf bestimmte Interessen hin

gefilterten Informationen über die Zeit hinweg möglich


Aufbau




Generische Kodierkonzepte (1)

• Motivation (Wofür brauchen wir definierte generische Kodierkonzepte?):• Um die Kodierung von Programmierprozessen visualisieren zu

können, muss klar sein, welche Objekte und Operationen hierbei auftreten

• (Im Prinzip wollen wir "Spuren" sehen. Hauptaufgabe des generischen Kodierkonzeptes ist es, solche zu definieren.)

• Diese Objekte und Operationen sollten • möglichst so generisch sein, dass sie in unterschiedlichen qualitativen

Forschungssituationen angewendet werden können• sich an gängigen Objekten und Methoden (z.B. aus der GT)

orientieren (und somit GT oder ähnliches erlauben)• besonders in Hinblick auf die Kodierung von Daten mit zeitlichem

Verlauf konzipiert sein• (eine möglichst einfache Umsetzung in ATLAS.ti erlauben)

• Es werden eine Reihe von Objekten definiert, mit deren Hilfe später die für die Visualisierung interessanten Objekte konstruiert werden können



• Abschnitte:• Abschnitte sind zusammenhängende Bereiche im Datenmaterial,

in denen ein oder mehrere Phänomene beobachtet werden• z.B. Intervalle in einem Video

• Besitzen u.a. einen Namen und optional eine Beschreibung• Bei Videoabschnitten z.B. auch einen Anfangspunkt und eine Länge

• Konzepte:• Konzeptionelle Bezeichnungen oder Etiketten, die einzelnen

Ereignissen, Vorkommnissen oder anderen Beispielen für Phänomene zugeordnet werden

• Besitzen einen Namen und optional eine Beschreibung• Bei der Paarprogrammierung z.B. "Driverwechsel"

• Annotieren:• Der Prozess der Zuordnung von Konzepten zu Abschnitten• Ein Abschnitt kann prinzipiell mit beliebig vielen Konzepten

annotiert werden• Annotation:

• Die konkrete Zuordnung (als Relation) eines Konzeptes zu einem Abschnitt



• Konzeptklassen:• Als strukturierendes Hilfsmittel zerfällt die Menge aller

Konzepte in so genannt Konzeptklassen• Diese Klassen sind frei definierbar

• Im Prinzip nur durch einen Namen und ggf. eine Beschreibung

• Die Anzahl solcher Klassen ist im Prinzip unbeschränkt• Ein Konzept kann in mehreren Klassen enthalten sein• Konzeptklassen sind i.A. Zusammenfassungen von

Konzepten nach semantischen Gesichtspunkten• Beispiele für Konzeptklassen aus der bisherigen Analyse

von Programmiermikroprozessen:• Aktivitäten: Beschreiben Phänomene, die sich über ein

gewisses Intervall erstrecken, z.B. "Kodieren"• Ereignisse: Bezeichnen Phänomene, die im Prinzip keine

zeitliche Ausdehnung haben, z.B. "Driverwechsel"



• Eigenschaften:• Eigenschaften charakterisieren die einzelnen Annotationen von

Konzepten genauer• Eigenschaften sind (GT folgend) selber Konzepte• Es gelten folgende Regeln:

• Eigenschaften werden unabhängig von bestimmten anderen Eigenschaften selber als Konzepte definiert.

• Eigenschaften können durch eine definierte Relation anderen Konzepten zugewiesen werden. Erst diese Zuweisung macht sie eigentlich zu Eigenschaften.

• Eigenschaften besitzen Ausprägungen. Diese Ausprägungen stellen die möglichen Werte der Eigenschaft dar.

• Ausprägungen werden durch eine bestimmte Relation an Eigenschaften zugewiesen.

• Beim Annotieren eines Konzeptes müssen nicht alle Eigenschaften verwendet werden.

• Eigenschaften kann man als eigene Konzeptklasse begreifen



• Beispiel für Eigenschaften und Ausprägungen:

Dokumentation heranziehen

Navigation

Zielsetzung

Zielgerichtet

Inspiration

Konkrete Information finden

Konzept AusprägungenEigenschaften



• Vererbung von Annotationen:• Ausgangssituation: Abschnitte können ineinander

enthalten sein• Dies kann z.B. dafür verwendet werden, um nur Teilbereichen

eines Abschnittes ein bestimmtes Konzept zuzuordnen

• Für einen Abschnitt A2, der vollständig in einem Abschnitt A1 liegt, gilt, dass eine Annotation für A1 implizit auch für A2 gilt

• Dieses Vorgehen liefert eine Ersparnis von Annotationen und redundanten Informationen



• Nebeneffekt der Vererbung von Annotationen:• Das geschilderte Vererbungskonzept erlaubt

Mehrfachvererbung:• Überschneidet sich beispielsweise ein Abschnitte A1 (mit

einem annotierten Konzept K1) mit einem Abschnitt A2 (mit einem annotierten Konzept K2) und liegt in diesem Durchschnitt ein Abschnitt A3, so erbt A3 die Konzepte K1 und K2.

A1 A2A3

K1 K2



• Primärannotationen:• Man betrachte alle zu einem Abschnitt gehörenden

Annotationen:• Direkt annotierte Annotationen und• geerbte Annotationen

• Diese Menge kann man in Teilmengen nach der Zugehörigkeit der Konzepte zu Konzeptklassen zerfallen lassen

• Jeder dieser Teilmengen besteht potentiell aus mehr als ein oder zwei Annotationen

• Oft ist es aber hilfreich, eine oder mehrere Annotationen aus so einer Menge herauszugreifen und diesen eine besondere Bedeutung zu geben

• Solche Annotationen sollen Primärannotationen heißen• Primärannotationen beziehen sich also immer auf ein

bestimmtes (zeitliches) Intervall und eine bestimmte Konzeptklasse



• Beispiel für Primärannotationen bei Programmiermikroprozessen:• Oft ist es interessant, die Hauptaktivität (Konzept der

Konzeptklasse Aktivität) in einem Intervall zu markieren• Falls sich beispielsweise bei der Paarprogrammierung das

Paar in einem bestimmten Intervall trennt, kann es zu zwei gleichzeitig gültigen Primärannotationen (bzgl. der Konzeptklasse Aktivität) kommen

• Achtung: Die Festlegung von Primärannotationen spiegelt in der Regel den Blickwinkel des Kodierers auf die Daten wider

• Sekundärannotationen• Alle Annotationen die nicht Primärannotationen sind



• Spuren von Annotationen:• Annotationen können so genannten Spuren zugewiesen

werden• Spuren repräsentieren einen bestimmten Blick des

Kodierers auf eine zeitliche Abfolge von ausgewählten Annotationen

• Standardverfahren zum Definieren von Spuren sind:• Auswahl aller Annotationen eines bestimmten Konzeptes• Auswahl aller Annotationen einer bestimmten Konzeptklasse• Auswahl aller Primärannotationen einer bestimmten

Konzeptklasse

• Beispiel für eine Spur bei Programmiermikroprozessen:• Abfolge aller Hauptbeschäftigungen



• Verlinkung von Abschnitten:• Abschnitte können durch bestimmte, definierbare,

wiederverwendbare Relationen miteinander verlinkt werden

• Diese Relationen besitzen zumindest einen Namen und ggf. eine Richtung

• Optional haben sie eine Beschreibung• Durch die Verlinkung können beispielsweise zeitliche und

inhaltliche Zusammenhänge zw. Abschnitte festgehalten werden

• Beispiel für die Verlinkung von Abschnitten bei Programmiermikroprozessen:• Ordnung aller Abschnitte, in denen ein Programmierer an

einem bestimmten Teilstück Kode arbeitet



• Verlinkung von Konzepten:• Auch Konzepte können durch bestimmte, definierbare,

wiederverwendbare Relationen miteinander verlinkt werden

• Diese Relationen besitzen wieder zumindest einen Namen und ggf. eine Richtung

• Optional haben sie eine Beschreibung• Durch solche Relationen können beispielsweise die schon

erwähnten Beziehungen zw. Konzepten und ihren Eigenschaften ausgedrückt werden


Aufbau




Umsetzung der generischen Kodierkonzepte in ATLAS.ti (1)

• Ziel:• Modellierung der generischen Kodierkonzepte mit Hilfe der

Objekte in ATLAS.ti• Primary Documents (PDs)• Quotations• Codes• Families

• Durchführung von visualisierbaren Kodierungen von Programmiermikroprozessen

• Zum großen Teil existiert eine 1-zu-1-Abbildung zwischen den generische Konzepten und den Objekten in ATLAS.ti

• Die Umsetzungen sind aber nicht in jedem Fall durch ATLAS.ti vorgegeben, sondern wurden im Rahmen der ersten Kodierungen von Programmiermikroprozessen entwickelt



• Daten sind Primary Documents (PDs)• ATLAS.ti kann in einem Projekt (Hermeneutic Unit (HU))

prinzipiell beliebig viele PDs halten• PDs können Textdokumente (plain, RTF), Bilder und Videos

(MPEG) sein• Wir können unsere Daten also direkt mit ATLAS.ti

verwalten



• Abschnitte sind Quotations:• Teile von PDs können in ATLAS.ti als sogenannte

Quotations markiert werden• Videoquotations sind Instanzen mit Attributen wie Name,

Startzeitpunkt, Länge (jeweils in Anzahl Frames) etc.• Sie können also verwendet werden um bestimmte Phänomene im

Videomaterial "herauszuschneiden"/zu markieren

• Quotations können ineinander enthalten sein oder sich schneiden



• Phänomene in Teilphänomen zerlegen:• Da Quotations ineinander enthalten sein können, ist die

Zerlegung von Phänomene in ATLAS.ti kein Problem, bzw. bedarf eigentlich keiner zusätzlichen Aktionen vom Kodierer

• Allerdings sind diese Zerlegung in ATLAS.ti nur schwer wieder sichtbar zu machen (z.B. in den Networkviews)

• Hilfskonstrukt: Deshalb kann man Relationen (part of) verwenden, um die Beziehung zw. Quotations in ATLAS.tibesser sichtbar zu machen



• Konzepte sind Codes:• Quotations können in ATLAS.ti mit Codes annotiert werden• Codes bestehen aus einem Namen und einer optionalen

Beschreibung• Codes können frei definiert werden



• Konzeptklassen (Codeklassen) lassen sich mittels Families modellieren:• In ATLAS.ti lassen sich Codes zu so genannten Families

zusammenfassen• Families besitzen einen Namen, optional eine Beschreibung

und die ihnen zugewiesenen Codes• Ein Code kann in beliebig vielen Familien liegen• Aktivitäten, Ereignisse (oder auch Eigenschaften) sind also

in ATLAS.ti Familien• Ein Problem in ATLAS.ti ist die Sichtbarkeit der

Zugehörigkeit zu Familien im Code Manager, in den Networkviews etc.

• Aus diesem Grund kann man den Namen der Codes je nach Zugehörigkeit zu Familien mit einem Präfix versehen, z.B. "A.Dokumentation heranziehen"



• Details zu Modellierung von Eigenschaften• Eigenschaften sind Codes• Eigenschaften sind über die ATLAS.ti-Relation "is property

of" anderen Codes zugewiesen• Eigenschaften müssen nicht exklusiv zu einem anderen

Code gehören• Auch Ausprägungen von Eigenschaften sind Codes• Ausprägungen von Eigenschaften sind über die ATLAS.ti-

Relation "is a" Eigenschaften zugewiesen• Nicht die Eigenschaften, sondern die Ausprägungen von

Eigenschaften werden als Annotationen verwendet• Vorsicht: Hier kann es zu Uneindeutigkeiten derart kommen,

dass nicht klar ist, zu welchem annotierten Konzept eine annotierte Ausprägung gehört



• Beispiel für die Verwen-dung von (Ausprä-gungenvon) Eigen-schaften



• Modellierung von Primärannotationen in ATLAS.ti• Da sich

• Abschnitte direkt auf Quotations (inkl. Hierachie) und• Konzepte direkt auf Codes (inkl. Vererbung)

abbilden lassen, kann die generische Definition vom Primärannotationen direkt übernommen werden

• D.h.:• Die Primärannotation (bzgl. einer Codeklasse C) einer

Quotation X ist die Primärannotation (bzg. C) der obersten Quotation Y, die X umschließt und einen Code der Klasse C annotiert hat

• Besitzt eine Quotation keine übergeordnete Quotation, der ein Code aus C zugeordnet ist, so sind alle ihr direkt zugeordneten Codes von C Primärcodes

• Achtung: Die Festlegung von Primärcodes ist eine Wahl des Kodierers. Er tut dies durch die Festlegung von Quotations, Annotationen und Codeklassen.



• Spuren ATLAS.ti• Spuren sind in ATLAS.ti nicht direkt modellierbar bzw.

sichtbar• Spuren können aber (wie im generischen Konzept) mittels

Codes, Codeklassen oder Primärcodes definiert werden• Spuren können sich also z.B. wie folgt bilden:

• Auswahl aller Annotationen eines bestimmten Konzeptes• Auswahl aller Annotationen einer bestimmten Konzeptklasse• Auswahl aller Primärannotationen einer bestimmten

Konzeptklasse• …

• Das "Sichtbarmachen" von Spuren ist Aufgabe der Visualisierungssoftware (da ATLAS.ti dies nicht leistet)



• Hyperlinks als Relationen zw. Abschnitten• In ATLAS.ti können Relationen zw. Quotations definiert und frei

verwendet werden. Diese heißen Hyperlinks.• Hyperlinks bestehen aus Namen, evtl. Beschreibung,

Eigenschaften (symmetrisch/asymmetrisch/transitiv) etc.• Hiermit können also beispielsweise inhaltliche Zusammenhänge

dargestellt werden. Z.B.:• Fortsetzung einer Tätigkeit über mehrere Quotations hinweg• Tätigkeiten, die sich auf eine bestimmte Codestelle beziehen

• Dies wäre ein Hyperlink zw. Quotations in einem Video und einer Quotation in einem Textdokument (mit dem zugehörigen Programmcode)



• Code-Code-Relationen als Relationen zw. Konzepten• In ATLAS.ti können Relationen zw. Codes definiert und frei

verwendet werden. Diese heißen Code-Code-Relationen.• Code-Code-Relationen bestehen aus Namen, evtl. Beschreibung,

Eigenschaften (symmetrisch/asymmetrisch/transitiv) etc.• Solche Relationen werden z.B., wie bereits gesehen, zw. Codes

und seinen Eigenschaften verwendet.


Aufbau




Grundfunktionalitäten einer Visualisierung (1)

• Alle Objekte in ATLAS.ti lassen sich innerhalb einer XML-Datei exportieren• Eine Visualisierungsssoftware muss

• dieses Format lesen können und dabei• implizite Objekte (wie die oben definierten Spuren)

erkennen können



• Auswahl/Definition und der darzustellenden Spuren• Darstellung von Annotationen (zeitlich proportional) in

den Spuren• Zoomen in der Menge der ausgewählten Spuren• Filtern der Daten in den darzustellenden Spuren nach

• Teilmengen von Annotationen• Verlinkungen (z.B. bzgl. bestimmer Relationen)• Eigenschaften

• Geeignete Darstellung/Einblendung von Eigenschaften an Annotationen

• …



• Und wie könnte eine Visualisierung nun grob aussehen?

Kodierungsschritt Problem behandeln Kodierungsschritt

0350

0400

0500

0600

0650

0700

0750

0800

0950

1000

1050

1100

1250

1300

1350

1400

1450

1500

1550

Primärcodes

Doku heran-ziehen

Doku heran-ziehen

Doku heran-ziehen

Ein-wand erhe-ben

Driver-wech-

sel

Sekundärcodes

Ereignisse

D

O

Autonom/dominierend

Kodierungsschritt Problem behandeln Kodierungsschritt

0350

0400

0500

0600

0650

0700

0750

0800

0950

1000

1050

1100

1250

1300

1350

1400

1450

1500

1550

Primärcodes

Doku heran-ziehen

Doku heran-ziehen

Doku heran-ziehen

Ein-wand erhe-ben

Driver-wech-

sel

Sekundärcodes

Ereignisse

D

O

Autonom/dominierend

Oder anders!?


Vielen Dank!

Date post:	29-Jun-2018
Category:	Documents
Upload:	doanque
View:	221 times
Download:	0 times