=Paper=
{{Paper
|id=None
|storemode=property
|title=Vorschlag Hypermodelling: Data Warehousing für Quelltext
|pdfUrl=https://ceur-ws.org/Vol-733/paper_frey.pdf
|volume=Vol-733
|dblpUrl=https://dblp.org/rec/conf/gvd/Frey11
}}
==Vorschlag Hypermodelling: Data Warehousing für Quelltext==
https://ceur-ws.org/Vol-733/paper_frey.pdf
Vorschlag Hypermodelling: Data Warehousing für
Quelltext
Tim Frey
OvG University Magdeburg, Germany
tim.frey@tim-frey.com
ABSTRACT können, aus dem betriebswirtschaftlichen Kontext für Quelltext
This paper explains the idea to load source code into a Data einzusetzen. Es werden dabei erste Überlegungen zu deren
Warehouse. First, separation of concerns is explained. Follow- Einsatz präsentiert. Das Fernziel des Einsatzes dieser Analyse-
ing, the motivation to load source code in a Data Warehouse is verfahren ist es, Data Warehouse Technologie als Werkzeug
briefly presented. Afterwards, the multi-dimensionality of soft- zur Quelltextanalyse nutzen zu können.1
ware is discussed. Also, a first model for software in a Data Im Folgenden wird zuerst die Motivation und Vision, Quelltext
Warehouse is shown. Nearby, the challenge that multiple cubes in ein Data Warehouse zu laden, beschrieben. Danach wird die
will be needed in order to load software in a Data Warehouse is Mehrdimensionalität von Software erläutert, um den Bezug zu
elucidated. Thereafter, related work is shown and its relation to mehrdimensionalen Daten im Data Warehouse zu geben. Im
the revealed idea is explained. Finally, conclusions are done Anschluss werden erste relationale Schemata präsentiert und
and future work paths are described. diskutiert, die Quelltext in einem Data Warehouse abbilden
können. Durch deren Darstellungen werden weitere Anforde-
Categories and Subject Descriptors rungen für zukünftige Schemata aufgedeckt. Nachfolgend wer-
D.2.3 [Software Engineering]: Coding Tools and Techniques; den verwandte Arbeiten, im Vergleich zu der in diesem Papier
D.2.7 [Software Engineering]: Distribution, Maintenance, and vorgeschlagenen Idee, erläutert. Am Ende werden Rückschlüs-
Enhancement se und weitere Arbeitspfade beschrieben.
General Terms
Human Factors 2. MOTIVATION UND VISION
Im betriebswirtschaftlichen Bereich existiert eine Vielzahl von
Keywords Systemen, deren Daten in einem Data Warehouse zusammenge-
Separation of Concerns, OLAP fasst und homogenisiert werden. Dies ermöglicht es, diese zu
aggregieren, Mining zu betreiben und strategische Entschei-
1. EINLEITUNG dungen zu treffen [5]. Des Weiteren werden Data Warehouses
Bei der Softwareentwicklung ist das Prinzip der Separation of
zur integrierten Unternehmensplanung verwendet. Dabei wer-
Concerns (deutsch: Trennung der Belange, kurz SOC) etabliert.
den Planziele in einem Data Warehouse hinterlegt [6].2
Dieses Prinzip entspricht der Handlungsweise, ein Softwaresys-
tem aus verschiedenen Blickwinkeln zu betrachten und die
Codierung für jeden Blickwinkel, in einzelnen Modulen zu
erstellen [1]. Diese Blickwinkel werden oftmals auch Belang
oder Concern genannt. Verschiedene Programmiersprachen
stellen dabei verschieden mächtige Mechanismen zur Verfü-
gung, um Module für die einzelnen Blickwinkel zu erstellen.
Durch die Modularisierung wird eine erhöhte Wiederverwend-
barkeit und Verständlichkeit erreicht. Trotz der Anwendung
von SOC ist die Erstellung und die Untersuchung von Software
eine große Herausforderung. Ferner ist es nicht einfach mög-
lich, einzelne Concerns in Module zu kapseln, weil eine "abso-
lute" Modularität mit gängigen eingesetzten Programmierpara- Abbildung 1: Prozesse mit einem Data Warehouse
digmen nicht möglich ist [2,4]. So ist es zum Beispiel bei der Dargestellt ist dies in Abbildung 1. Daten werden aus operati-
Kodierung von Problemstellungen durch das objektorientierte ven Systemen in ein Data Warehouse geladen. Diese Daten
Paradigma nicht möglich, alle Concerns in einzelne Module zu
verpacken. Ein Modul ist oftmals für verschiedene Zuständig-
keiten zugleich programmiert [2, 3, 4]. Folglich sind verschie- 1
Aufgrund des Bezuges des Papieres auf SOC und Data Ware-
dene Concerns in Modulen vermischt und werden nicht in ein-
house Technologien wird im weiteren Verlauf von einer Ver-
zelnen Modulen, wie es eigentlich die Idee von SOC ist, ko-
trautheit mit SOC [1] und den hierbei auftretenden Problemen
diert. Um die Analyse von Software im Zusammenhang mit
[2,4], Frameworks [8,9], aspekt-orientierter Programmierung
Concerns zu ermöglichen, muss folglich ein Analyseverfahren
[12], domänen-spezifischen Sprachen [11], Annotationen [10]
den Umstand der Vermischung von Concerns in Modulen be-
und Grundkenntnissen im Data Warehouse Bereich [5,7]
achten. Der Beitrag dieses Papiers ist daher die Idee, mehrdi-
ausgegangen.
mensionale Analyseverfahren, die solche Umstände beachten
2
Eine integrierte Unternehmensplanung ist die Hinterlegung
von Planzielen in einem Data Warehouse. In diesem werden
Copyright is held by the author/owner(s). hierbei Merkmalkombinationen in Verbindung mit Kennzah-
GvD Workshop’11, 31.05.-03.06.2011, Obergurgl,Österreich. len gespeichert, wobei zumindest ein Merkmal ein zukünfti-
ges Zeitdatum darstellt. Der Zusammenhang zwischen strate-
gischen Entscheidungen und Planung ist, dass strategische
Entscheidungen zu Planzielen führen können.
55
werden dann genutzt, um Berichte zu erzeugen. Aufgrund die- oder sie spannen Dimensionen auf, die orthogonal zu den bishe-
ser Berichte werden Entscheidungen getroffen. Diese führen zu rigen Dimensionen stehen. Dabei rücken diese neuen Dimensi-
einer Planung für die Zukunft. Der Plan wird dann als Planda- onen in den Vordergrund und bisherige Dimensionen werden
ten im Data Warehouse gespeichert. Dabei können die Planda- verdeckt, was einer Drehung des Würfels ähnlich ist.
ten auch dazu führen, dass automatisiert in die operativen Sys- In Abbildung 2 wird Quelltext, der selbst in eine
teme geschrieben wird (grauer Pfeil). Durch Planung und deren Frameworkdimension aufsteigt, grafisch visualisiert. Dabei sind
Umsetzung entstehen neue Daten in den operativen Systemen. zuerst zwei Frameworks A und B zu sehen. Der Quelltext kon-
Diese werden dann wieder in das Data Warehouse geladen und sumiert die Fähigkeiten eines Frameworks A und eines anderen
können mit den Plandaten verglichen werden. Das führt zu B, womit eine Komposition von beiden Frameworks erreicht
Entscheidungen und gegebenenfalls zu einem neuen Plan [7]. wird. Ein solches Konsumieren kann z.B. ein Funktionsaufruf
Bei der Softwareentwicklung fallen ebenfalls Artefakte in einer oder jedes andere Nutzen der Fähigkeiten eines Frameworks
Vielzahl von Systemen an, und bei vielen Projekten ist die sein. Die Pfeile zeigen das Konsumieren von Fähigkeiten an.
Quelltextbasis zu groß, um einfach überblickt oder analysiert zu Aufgrund dessen, dass neuer Quelltext den bestehenden Quell-
werden. Die Vision ist daher eine integrierte, homogenisierte text nutzt, steigt der zuvor erzeugte Quelltext im unteren Teil
Sicht auf Software als multidimensionales Gebilde, durch die der Grafik, selbst zur eigenständigen Dimension auf. Diese
die verschiedenen Artefakte, die im Produktlebenszyklus auf- wird dann von neuem Quelltext konsumiert. Dabei kann es
treten, abgebildet werden können. Der Kern der Idee ist, dass auch sein, dass der New Code nicht mehr das originale Frame-
Software nicht nur aus der Applikationslogik besteht, sondern work B nutzt, sondern nur den zuvor erzeugten Code und Fra-
aus einer Vielzahl weiterer Artefakte, wie zum Beispiel Tests. mework A, was durch die Schraffierung angedeutet ist.
Eine multidimensionale Anordnung im Data Warehouse könnte Die Idee ist, dass Frameworkfunktionen oftmals Concerns re-
eine integrative Komponente sein, die es erlaubt, die Software präsentieren. Somit können die verschiedenen Concerns der
aus verschiedenen Blickwinkeln zu betrachten. Desweiteren Software mit Dimensionen gleichgesetzt werden.
würde es der Einsatz dieser Technologie zulassen, außer der
Analyse weitere Anwendungen möglich zu machen. Der Pla-
nungsprozess in Data Warehouses, der zur integrierten Planung
verwendet wird, könnte dazu dienen, Qualitätskriterien zu defi-
nieren, oder auch Weiterentwicklungen von Software zu planen
und diese dann mit der erfolgten Realität zu vergleichen.
Ziel dieser Arbeit ist es daher, erste Möglichkeiten des Spei-
cherns von Quelltext in einem Data Warehouse zu untersuchen.
Diese erste Evaluation soll Hinweise über die Realisierbarkeit
des Einsatzes von Data Warehouses zur Quelltextuntersuchung
liefern.
3. MEHRDIMENSIONALE SOFTWARE
Software wird normalerweise unter der Nutzung von Frame-
works, die vorgefertigte Funktionalität bereitstellen, erstellt.
[8,9]. Software kann als ähnlich zu einem n-dimensionalen
Hyperwürfel betrachtet werden. Die Ecken bzw. Kanten des
Würfels sind Frameworkfunktionen. Durch diese Anschauung
ist es nötig, Software nicht nur aus einer Position zu betrachten.
Die Ansicht ist ähnlich zu einem Hyperwürfel und kann gedreht
werden. Eine Drehung kann hierbei verschiedene Dimensionen
in den Vordergrund verschieben und andere im Hintergrund
verschwinden lassen. Dieser Vergleich zeigt, dass der Mensch
nicht dazu fähig ist Software, die ähnlich einem Hyperwürfel
ist, direkt und vollständig zu erfassen. Darstellungen sind viel-
mehr Projektionen in den Verständnisraum des Menschen. Abbildung 2: Quelltext, der zur Dimension aufsteigt
Die Analogie zu einem Hyperwürfel kann auf dessen Konstruk- Daraus folgt eine abstrahierte Darstellung des Sachverhaltes
tion reduziert werden. Dabei kann ein Würfel gesehen werden, von Abbildung 2 in Abbildung 3. Hierbei wurden die Dimensi-
der durch weitere Dimensionen erweitert wird. Im Falle von onen des Quelltextes mit C für Concern gekennzeichnet. Die
Software wird ein Würfel durch Quelltext "befüllt", der sich im Komposition durch Quelltext von verschiedenen Concerns ist
vorgegebenen Rahmen eingliedert. Dies bedeutet, dass Quell- durch den Verbindungsvektor VC1 dargestellt. In Abbildung 3b
textmodule aufgrund der Nutzung verschiedener wird diese Dimension, beziehungsweise dieser Concern, selbst
Frameworkfunktionen verschiedenen Dimensionen zugehörig wiederum konsumiert (VC2). Der gestrichelte VC1 Vektor und
sind. Diese Zugehörigkeit ergibt sich daraus, dass die einzelnen dessen Parallelverschiebung zeigt, dass die neue Dimension
Concerns nicht in Modulen getrennt sind, und somit ein Modul komplett gleichberechtigt zu den „normalen“ C Dimensionen
durch die Nutzung verschiedener Funktionen verschiedenen ist.
Dimensionen gleichzeitig zugehörig sein kann.
Beim Erstellen von Software werden Funktionen, die im „aktu-
ell erstellten“ Quelltext selbst sind und nicht aus Frameworks
stammen, auch genutzt. Der Programmierer erzeugt sich ein
eigenes Framework für seine spezielle Aufgabe. Dieses setzt
auf bestehende Funktionen von Frameworks auf oder definiert Abbildung 3: Quelltext der zur Dimension aufsteigt
vollkommen neue Funktionen. Somit wird ein Teil des Würfel- Ein weiterer Umstand, den es zu beachten gilt, ist die Anord-
inhaltes zu neuen Dimensionen. Diese befinden sich in dem nung der Concerns im Falle von Quelltext. Dieser kann, wie
Würfelrahmen und erzeugen hierin spezialisierte Unterräume beschrieben mehreren Concerns zugehörig sein. Diese können
56
sich zudem in verschiedenen Hierarchien befinden. Beispiels- enthalten. Oftmals werden Annotationen in Frameworks defi-
weise könnte eine Hierarchie VC2 zu VC1 und Cn sein. VC1 niert und daher ist die Annotationstabelle mit der
wiederum ist die Wurzel der Cx, Cy Hierarchie. Abstrakt dar- Frameworktabelle verknüpft. Die Parameter Tabelle zeigt die
gestellt ist dies in Abbildung 4a. Dort wird die Hierarchie vi- Möglichkeit, dass Annotationen auch Parameter besitzen kön-
sualisiert, in der sich VC2 befindet. VC2 bildet dabei den Ur- nen. Zusätzlich sind oftmals externe domänenspezifische Spra-
sprung von dem aus die Hierarchie aufgespannt wird. In Abbil- chen (domain specific language (DSL)) mit Quelltext assoziiert.
dung 4b wird der Sachverhalt verallgemeinert gezeigt, dass Durch diese können zu Quelltextfragmenten verschiedene
Dimensionen/Concerns auch hierarchisch angeordnet sein kön- Funktionalitäten hinzu konfiguriert werden [11]. Ein bekanntes
nen. Verschiedene Tiefenebenen sind als Dimensionsebenen Beispiel hierfür ist die Konfiguration persistenter Klassen über
(DE1- DEn) beschriftet.3 Die Wurzel der Hierarchien bildet eine DSL. In modernem Quelltext treten auch Aspekte [12] auf.
dabei das Fragment, in dem die einzelnen Concerns komponiert Aspekte sind Fragmente die es ermöglichen, Funktionalität, die
wurden. Ein praktisches Beispiel für Hierarchien sind Metho- nach dem Objektparadigma nicht an einer Stelle kodiert werden
denaufrufe oder Vererbung. kann, an einem zentralen Punkt zu realisieren. In diesem wird
dann angegeben welche Module von dem Aspektcode (Advice)
betroffen sind. Die Konfiguration der betroffenen Module er-
folgt über sogenannte pointcuts. Zuletzt kann ein Modul einer
Komponente und Aufgaben zugordnet werden. Beispielsweise
können solche Aufgaben das Einpflegen von Änderungen in der
Funktionalität darstellen.
Abbildung 4: Dimensionshierarchien
Da in modernem Quelltext oftmals eine hohe Anzahl von Fra-
meworks verwendet wird, stellt sich die Herausforderung, trotz
der Analogie zwischen Frameworkfunktionen und Dimensio-
nen, diese bei einer Umsetzung in einem Schema nicht voll-
ständig gleichzusetzen. Dies hat den Grund, dass oftmals eine
Vielzahl von Frameworks in Quelltext verwendet wird und
somit eine hohe Anzahl verschiedener Dimensionen wahr-
scheinlich die Skalierbarkeit der Umsetzung beeinflussen wür-
de. Folglich sollten Frameworkfunktionen als eine Dimension
Abbildung 5: Grundlegendes relationales Quelltextschema
mit verschiedenen Elementen, den eigentlichen Funktionen der
Frameworks, modelliert werden.
Ziel ist ein Modell, welches die zuvor genannten Sachverhalte
4.1.2 Schneeflockenschema
Das in Abschnitt 4.1.1 dargestellte Schema wurde in Abbildung
in einem Data Warehouse abbildet. Dies kann genutzt werden,
6, an ein Schneeflockenschema angelehnt, erweitert. Eine gene-
um Abfragen auf Quelltext zu ermöglichen. Aufgrund der
rische Zuordnung von Modulen zu Concerns wird besser er-
Mehrdimensionalität des Ansatzes und dem Hintergrund, dass
möglicht und mehr Sachverhalte können dargestellt werden.
bei der Programmierung Modelle die Realität abbilden, ist der
Ebenfalls wird der Umstand beachtet, dass eine generische
Name der Kombination, zwischen Data Warehouse und Soft-
Darstellung der Beziehungen im Quelltext aus Abschnitt 3
warequelltext, Hypermodelling.
dargestellt wird und verschiedene Frameworks nicht als eigen-
ständige Tabelle realisiert sind. Vielmehr sind die
4. MODELLIERUNG Frameworkfunktionen in einer Tabelle zusammengefasst.
Data Warehouses nutzen im Normalfall eine relationale Daten- Wie zu sehen ist, verweist die Faktentabelle auf verschiedene
quelle, um OLAP-Würfel zu füllen. Daher ist der erste Schritt Concerns, zu denen die Zugehörigkeit durch Cmembership in
ein relationales Schema, das Quelltext in einem Data Warehou- Prozent ausgedrückt werden kann. Als Modulgranularität wurde
se abbildet. In Data Warehouses werden zu der Abbildung von eine Funktion gewählt. Diese stellt eine kleine Einheit klarer
Daten in relationalen Tabellen im Normalfall Stern- oder Funktionalität dar und gliedert sich in eine Klasse ein. Folglich
Schneeflockenschemata verwendet [31]. Nachfolgend werden ist Aggregation von Fakten auf Klassenebene möglich. Eine
zwei relationale Modelle, inspiriert von diesen, gezeigt. Zuletzt Funktion kann andere Funktionen nutzen (Function_call). Hier-
wird die OLAP Darstellung angerissen und Problematiken des bei kann spezifiziert werden, ob der Konsum ein Aufruf oder
entwickelten Schemas aufgezeigt. ein andere Nutzungsart (Usage type), wie zum Beispiel das
Überschreiben einer Funktion eines Frameworks ist. Ebenfalls
4.1.1 Einfaches Schema können Typen eines Frameworks, wie zum Beispiel durch An-
In Abbildung 5 ist exemplarisch eine Tabellenstruktur mit
notationen oder Erbschaftbeziehungen, konsumiert werden
Fragmenten, die in Quelltext vorkommen, an ein Sternschema
(Type_usage).
angelehnt, dargestellt. In der Abbildung ist das zentrale Ele-
Rückverweise auf die Faktentabelle zeigen, dass Hierarchien
ment die Faktentabelle. Eine Zeile in dieser repräsentiert ein
von Funktionen möglich sind. Die Aufrufhierarchie wird durch
Quelltextfragment, wie ein Modul. Ein solches ist zum Beispiel
die CallHierarchy Table dargestellt. Die EvolvedConcernCode
eine Klasse oder Funktion. Eine Klasse kann Annotationen
Tabelle ermöglicht es, Funktionen/Fakten selbst als Concern zu
führen. Durch diese Tabelle kann Quelltext, der sich zum
3
Die Ebenen sind rein zur besseren Visualisierung dargestellt; Concern entwickelt (siehe Abschnitt 3), aber kein Teil eines
nicht jede Dimension muss über die gleiche Anzahl von Hie- Frameworks ist, dargestellt werden.
rarchien verfügen.
57
Besonders interessant ist die Issue Tabelle, die Bugs darstellt. somit keine Repräsentation der Programmstruktur, sondern
Diese können auf zugehörige Tests verweisen. Dabei können vielmehr die Assoziation von Programmelementen miteinander.
auch Tasks oder deren Kontext mit solchen Issues verbunden Ein Beispiel für die Assoziation von Programmelementen mit-
sein. Ebenfalls wurde der Umstand ins Modell eingeflochten, einander ist die zuvor beschriebene Aufrufhierarchie. Da somit
dass Packages oftmals Layer zugeordnet werden können. beide OLAP-Würfel eine Assoziation zu dem Quelltext besit-
Metrics, Profiling info und Author zeigen, dass weitere Infor- zen, können diese dann in einem Verknüpften OLAP-Würfel
mationen im Bezug auf Quelltext dargestellt werden können. zusammengeführt werden. In diesem Linked Cube werden dann
zusätzliche Fakten, mit denen des logischen Modells einer Pro-
grammiersprache zusammen geführt.
Abbildung 7: OLAP-Würfel, Zuordnung von Quelltext
Schlussendlich zeigt sich, dass für die Entwicklung eines relati-
onalen Schemas, zuerst Fakten von der Struktur von Quelltext
getrennt werden sollten. Danach können die verschiedenen
Fakten in einem weiteren Modell zusammengeführt werden.
5. VERWANDTE ARBEITEN
Auf der Homepage4 des Hypermodelling Projektes befinden
sich weitere Informationen über die Idee, Quelltext in ein Data
Warehouse zu laden und verwandte Forschung.
Die Gruppe der Source Code Query Tools stellt im Wesentli-
chen Programme dar, die Quelltext aufgrund von Abfragen
untersuchen können. Diese Werkzeuge können als verwandte
Abbildung 6: Quelltext, Schneeflockenschema Arbeiten zu der Idee von Hypermodelling gesehen werden, da
diesen zu Grunde liegt, Quelltext, aufgrund von Abfragen zu
4.1.3 OLAP-Darstellung untersuchen. JQuery ist ein Abfrage basierter Source Code
Grundlegend zeigt das Schema aus Abschnitt 4.1.2 bei näherer Browser für Java. Realisiert ist er als Eclipse Plugin [13].
Betrachtung die Einschränkung, dass eine direkte Umsetzung in JQuery stellt eine deklarative Abfragesprache zur Verfügung
einen OLAP-Würfel keine elegante Lösung darstellt. Insbeson- und erlaubt es, durch diese verschiedene Ansichten auf Quell-
dere die rückverweisende CallHierarchy besitzt Eigenschafen text zu erzeugen [14]. Ferret ist ein weiteres Source Code Que-
einer Faktentabelle; CallHierarchy kann mehrmals gleiche Ein- ry Tool und wurde von Brian de Alwis im Rahmen seiner Dis-
träge besitzen, wenn eine Funktion mehrmals die gleiche Funk- sertation entwickelt [15, 16]. Es erlaubt es ähnlich JQuery,
tion aufruft. Zur Realisierung sollte somit mit der Sichtweise Abfragen an Java Quelltext zu erstellen. Ferret ist hauptsächlich
einer zentralen Faktentabelle gebrochen werden. dafür gedacht, den Quelltext aufgrund seiner Aufrufstruktur
In Abbildung 7 ist aufgrund der zuvor genannten Einschrän- und Vererbung zu untersuchen. Lost ist ein Query Tool für
kungen daher die Idee, mehrere OLAP-Würfel zu erstellen, die aspekt-orientierte Programmierung [17]. Grundlegend verfol-
einen Bezug zu den Daten eines konkreten Programmes, das gen alle Source Code Query Tools das gleiche Ziel und besitzen
analysiert werden soll, haben. Ziel ist es einen OLAP-Würfel, ähnliche Funktionalität. JQuery erscheint von allen Tools das
ähnlich A, zu erstellen, der Zuordnungen mit einem logischen am besten gepflegteste und mächtigste zu sein und kann somit
Modell einer Programmiersprache enthält. Hierbei kann dieser als bestes Vergleichsprodukt zu Hypermodelling gesehen wer-
OLAP-Würfel durch zusätzliche Daten, die im direkten Zu- den. Im Vergleich zu Hypermodelling unterscheiden sich die
sammenhang zu der Programmiersprachenlogik, stehen ange- Source Code Query Tools darin, dass diese nicht das Ziel ver-
reichert werden. Solche Daten könnten zum Beispiel Tests oder folgen, Data Warehouse Technologie zur Analyse von Quell-
deren Ergebnisse sein. Dieser OLAP-Würfel stellt ein Abbild text zu nutzen. Ebenfalls orientiert sich ihre Funktionsweise
der Programmiersprachenstruktur dar, welches durch ein kon- oder die Abfragemöglichkeiten nicht an Data Warehouse Tech-
kretes Program als Fakten „befüllt“ wird. nologie.
In einem weiteren OLAP-Würfel werden dann Fakten, die nicht
der Programmiersprachenstruktur entsprechen, definiert. Jedoch
besitzen die Daten zumindest einen Bezug zu dem Quelltext-
4
model. Im Vergleich zu OLAP-Würfel A ist OLAP-Würfel B http://hypermodelling.com
58
Martin Robillard forscht auf dem Gebiet der Concernanalyse. strebt wird. Dies ist zudem auch darin zu sehen, dass Sourcerer
Sein Werkzeug, ConcernMapper [18], soll helfen, Quelltext keine Faktentabellen nutzt, um Beziehungen im Quelltext ab-
nach verschiedenen Concerns zu unterteilen und ist auf manuel- zubilden.
le Zuordung von Concerns zu Quelltextfragmenten ausgelegt. Codegenie, dass auf Sourcerer aufsetzt, ermöglicht es, Kompo-
Der Unterschied zu den Source Code Query Tools ist, dass der nenten aufgrund von Testfällen aufzudecken und in ein Pro-
Concern Mapper keine Abfragesprache oder ähnliche Mittel gramm zu integrieren [25, 26]. Ähnlich zu Codegenie zeigt [27]
nützt, sondern dieser auf die rein manuelle Zuordnung von weitere Möglichkeiten der Komponentenaufdeckung, unter der
Concerns ausgelegt ist. Der größte Nachteil im Vergleich zu Zuhilfenahme von Codesuchmaschinen und gibt einen Über-
Hypermodelling ist, dass das Anlegen und Zuordnen der blick und Vergleich über die Aufdeckung von Komponenten.
Concerns eine Mehrarbeit des Entwicklers bedeutet und nicht Im Vergleich zu diesen Codesuchmaschinen liegt der Fokus
das Ziel verfolgt wird, Abfragen aufgrund dem Entwickler be- von Hypermodelling auf der Analyse und Abfragen aufgrund
kannter Quelltextelemente zu ermöglichen. von Concerns. Eine Verwendung der Hypermodelling Idee zur
In [19] wird ein Verfahren beschrieben, bei dem ein Metrics Codesuche könnte jedoch eine interessante Anwendung sein.
Warehouse eingesetzt wird. Dieses erinnert aufgrund des Orthographic Software Modeling (OSM) ist der Ansatz, mehr-
Warehouses entfernt an die Idee des Hypmermodelling. Dabei dimensionale Navigation durch Modelle bei der Softwareent-
wird bei dem Verfahren beschrieben, wie Projekte anhand von wicklung einzusetzen [30]. Ziel ist es, Quelltext und die zuge-
Metriken, gesteuert werden können. Dies bezieht sich auf Met- hörigen Modelle in einem zentralen Modell abzubilden um
riken aus betriebswirtschaftlichen Systemen und nicht direkt daraus die verschiedenen Modellansichten dynamisch erzeugen
auf Metriken, die durch eine Funktion aus Quelltext berechnet zu können [28]. Um die Navigation durch die verschiedenen
werden können. Diese Metriken werden dann in ein nicht näher Modellansichten zu ermöglichen, werden verschiedene Dimen-
erläutertes Metrics Warehouse geladen, das einem Data Ware- sionen und deren Ausprägungen definiert. Zum Beispiel eine
house ähnlich ist. Der genaue Aufbau des Metrics Warehouses, Dimension die in ihren Ausprägungen die Abstraktionsebenen
die Struktur der Daten, und der Inhalt des Warehouses wird festlegt oder eine Projektionsdimension, deren Ausprägung die
nicht näher beschrieben. Struktur oder die Interaktion von Elementen beschreibt. Die
Source Code Mining ist die Anwendung von Data Mining Al- Auswahl einer Kombination von Ausprägungen von Dimensio-
gorithmen auf die Quelltext, Bug Datenbanken und Versions- nen bestimmt letztendlich dann, welches Modell gezeigt wird
verwaltungssysteme [20]. Somit stellt diese Technik auch die [29]. Die mehrdimensionale Navigation und die Sichtweise von
Zielsetzung auf, Quelltext zu analysieren und dadurch Verbes- Software als ein mehrdimensionales Konstrukt, das von ver-
serungen zu erreichen, und kann somit als ähnlich erachtet wer- schiedenen Blickwinken aus betrachtet werden kann, ähnelt
den. Die Hauptidee hierbei ist es, Bugs aus Issue Tracking Sys- Hypermodelling. Jedoch verfolgt OSM nicht das Ziel, Data
temen, mit deren Lösungen aus Versionsverwaltungssystemen, Warehouse ähnliche Mechanismen zu nutzen, um dadurch
aufgrund der entsprechenden Quelltexte zu verknüpfen und Quelltext untersuchen zu können. Ferner liegen die Ziele von
darauf Data Mining zur Analyse zu nutzen. Muster im Quelltext Hypermodelling nicht direkt in der Modellierung von Software,
werden aufgedeckt, interpretiert und Handlungen abgeleitet. sondern vielmehr darin, Abfragen unter der Nutzung verschie-
Solche Analysen können beispielsweise zu Feststellungen füh- dener Concerns zu ermöglichen. In diesem Kontext könnte
ren, dass Problemlösungen, die an einem bestimmten Wochen- natürlich auch die dynamische Erstellung von Ansichten bei
tag gemacht wurden, mit einer hohen Wahrscheinlichkeit wie- OSM als Abfragen verstanden werden, und es könnte interes-
der zurückgenommen werden [21]. Das Source Code Mining sant sein, eine Kombination zwischen OSM und Hypermodel-
besitzt den Nachteil, dass derzeit nur Zusammenhänge zwi- ling zu untersuchen.
schen Fehlern und Beziehungen zwischen einzelnen Quelltext- Bezogen auf die Data Warehouse Schemata zeigen [5] und [31]
elementen im Source Code aufgedeckt werden können. Es wird einen umfassenden Überblick über das Thema Data Warehouse.
dabei kein Verfahren offenbart, wie weitere Daten in die Wis- Hier werden die verschiedenen Schemata besprochen und prak-
sensbasis integriert werden können. Des Weiteren verfolgt tische Beispiele aufgezeigt. Business Intelligence, wie auch die
Source Code Mining im Vergleich zu Hypermodelling nicht das integrierte strategische Unternehmensplanung im speziellen
Ziel, eine Datenbasis in Form des Ladens von Daten in ein Data Anwendungsfall, wird in [7] beschreiben. Ein betriebswirt-
Warehouse zu erschaffen, auf welcher dann Analysen ausge- schaftlich- orientierter Überblick der integrierten Unterneh-
führt werden können. mensplanung stellt [6] dar. Einen herstellerneutralen Überblick
In [22] wird Software Intelligence beschrieben. Software über die Planung mit Data Warehouse Systemen bietet [32].
Intelligence wird hier als die Anwendung von Business
Intelligence Mechanismen oder Technologien auf Software 6. ZUSAMMENFASSUNG UND AUSBLICK
beschreiben. Dies ist der hier vorgestellten Idee ähnlich. Der In diesem Papier wurde die Idee, Quelltext in ein Data Ware-
Unterschied liegt darin, dass Software Intelligence nicht das house zu laden, vorgestellt. Hierbei wurde beschrieben, dass
Ziel verfolgt, Quelltext in OLAP-Würfel zu laden und sich auf Quelltext ein mehrdimensionales Gebilde aus Concerns ist.
Source Code Mining konzentriert. Dabei wurde insbesondere der Umstand hervorgehoben, dass
Die Untersuchung von Quelltext unter der Zuhilfenahme einer Module oftmals mehreren Concerns zugeordnet werden kön-
relationalen Datenbank zur Analyse wird im Sourcerer Projekt nen. Es wurde erläutert, dass in diesem mehrdimensionalen
durchgeführt [23]. Das relationale Modell umfasst vier Tabel- Gebilde neue Dimensionen durch Kompositionen erschaffen
len. Quelltext wird in Projekte, Dateien, Kommentare und Enti- werden können. Dieser Umstand zeigt eine besondere Heraus-
täten die mit Beziehungen verknüpft sind, aufgeteilt. Solche forderung, im Bezug auf das Laden von Quelltext in ein Data
Entitäten sind zum Beispiel Klassen, Interfaces und Methoden Warehouse. Unter Beachtung dieser Rahmenbedingung wurden
[24]. Im Vergleich zu Hypermodelling zeigt der Umfang des relationale Modelle mit Faktentabellen präsentiert, in die Quell-
relationalen Modells einen wesentlichen Unterschied; Hyper- text geladen werden kann. Durch deren Darstellung konnte die
modelling visualisiert schon in den ersten vorgestellten Model- Problematik aufgedeckt und verdeutlicht werden: Eine einzige
len die verschiedenen Beziehungen in unterschiedlichen Tabel- Faktentabelle ist zur Darstellung von Quelltext nicht ausrei-
len. Zudem ist das Ziel von Hypermodelling, Data Warehouse chend. Zuletzt wurden verwandte Arbeiten präsentiert, deren
und insbesondere OLAP-Würfel zu verwenden. Dies ermög- Analyse zeigt, dass die Idee, Quelltext in ein Data Warehouse
licht Aggregationen von Fakten, was bei Sourcerer nicht er- zu laden, bisher noch nicht durchgeführt wurde. Dennoch deu-
59
ten die verwandten Arbeiten darauf hin, dass der primäre Ein- of Declarative Languages, 8th International Symposium.
satzort für Abfragewerkzeuge derzeit die integrierte Entwick- Springer. 2006.
lungsumgebung ist. [15] B. de Alwis, G. C Murphy. Ferret: A Tool Supporting
Eine wichtige Folgerung aus den Darstellungen dieses Papiers Software Exploration. The University of British Columbia
ist, dass bei der Erstellung eines weiteren Schemas, Quelltext in Vancouver, Canada.
verschiedene Fakten aufgeteilt werden sollte. Dies wird benö- http://www.cs.ubc.ca/~bsd/research/ferret/
tigt, um ein relationales Modell zu erstellen. Somit stellt sich [16] B. de Alwis. Supporting Conceptual Queries Over Inte-
für zukünftige Arbeiten die Frage, welche Mittel einer Pro- grated Sources of Program Information . PHD Thesis.
grammiersprache als strukturell und welche als assoziativ zu- University of British Columbia, Vancouver Canada. 2008
einander begriffen werden können. Eine derzeitige Überlegung [17] J.-H. Pfeiffer. Complex code querying and navigation for
ist daher Quelltext als Mechanismen von Kategorisierung AspectJ. OOPSLA ’05. ACM. 2005
(strukturell) und Komposition (assoziativ) zu betrachten. Kate- [18] M. P. Robillard and F.Weigand-Warr. ConcernMapper:
gorisierung ist hierbei alles, das einer logischen Zuordnung simple view-based separation of scattered concerns. In
dient. Zum Beispiel Klassen zu Packages. Komposition stellen Proceedings of the 2005 OOPSLA Workshop on Eclipse
sämtliche Elemente dar, die eine direkte Auswirkung auf die technology eXchange, ACM, 2005
Funktionalität ausüben, wie Methodenaufrufe. Dennoch sind [19] C. R. Pandian. Software metrics: a guide to planning,
hier Diskussionspunkte offen. So ist es zum Beispiel fragwür- analysis and application. Auerbach Publications. 2003
dig, ob Ableitungen eher eine Kategorisierung oder eine Kom- [20] Mining Software Archives.Lehrstuhl für Softwaretechnik
position darstellen. Ziel dieser Überlegungen ist es Quelltext in Universität des Saarlandes – Informatik. Prof. Zeller.
OLAP-Würfel zu laden, um dadurch komplexe Analysen von http://www.st.cs.uni-saarland.de/softevo/.
Quelltext zu ermöglichen. [21] T. Zimmermann, A. Zeller. When do changes induce fix-
Eine weitere Überlegung kommt aus der Betrachtung der ver- es?. ICSE 05, ACM. 2005
wandten Arbeiten, die Großteils für Eclipse umgesetzt wurden. [22] A. E. Hassan, T. Xie.Software Intelligence: Future of Min-
Diese inspirieren dazu, OLAP ähnliche Abfragen direkt in der ing Software Engineering Data.In Proceedings of
integrierten Entwicklungsumgebung zu ermöglichen. Dies kann FSE/SDP Workshop on the Future of Software Engineer-
ein besonders großer Vorteil für Entwickler sein, da diese mit ing Research .Santa Fe. ACM. 2010
solchen Hypermodelling Abfragen direkt in der Entwicklungs- [23] Sushil Bajracharya, Trung Ngo, Erik Linstead et. al. Sour-
umgebung Quelltext untersuchen können. cerer: A Search Engine for Open Source Code Supporting
Structure-Based Search, OOPSLA’06. USA. ACM. 2006
7. LITERATUR [24] Sushil K. Bajracharya, Joel Ossher, Cristina V. Lopes,
[1] E. W. Dijkstra. Selected Writings on Computing: A Per- Sourcerer - An Infrastructure for Large-scale Collection
sonal Perspective. On the role of scientific thought. Sprin- and Analysis of Open-source Code, Third International
ger.1982 Workshop on Academic Software Development Tools and
[2] W.Harrison, H. Ossher. Subject-oriented programming: a Techniques, Belgium, ACM, 2010
critique of pure objects. OOPSLA '93. ACM. 1993 [25] Otavio Lemos, Sushil Bajracharya et al.. CodeGenie: Us-
[3] Bernhard Lahres, Gregor Rayman. Objektorientierte Pro- ing Test-Cases to Search and ReuseSource Code, ASE’07,
grammierung. Galileo Computing. 2009 2007, Atlanta, Georgia, USA. ACM
[4] H. Ossher, P. Tarr. Multi-dimensional separation of con- [26] Otávio Augusto Lazzarini Lemos , Sushil Bajracharya and
cerns and the hyperspace approach. In Proceedings of the Joel Ossher , CodeGenie: a Tool for Test-Driven Source
Symposium on Software Architectures and Component Code Search, OOPSLA’07, Canada. ACM, 2007
Technology. Kluwer. 2001. [27] O. Hummel, “Semantic Component Retrieval in Software
[5] W.H. Inmon. Building the Data Warehouse. 4th ed., Engineering”,Ph.D. dissertation, Faculty of Mathematics
J.Wiley & Sons, New York. 2005. and Computer Science, University of Mannheim, 2008.
[6] M. C. Meier, W. Sinzig, P. Mertens. Enterprise Manage- [28] C. Atkinson and D. Stoll: "Orthographic Modelling Envi-
ment with SAP SEM/Business Analytics. 2nd Edition, ronment", in Proceedings of Fundamental Approaches to
Springer. Berlin. 2005 Software Engineering (FASE'08), Hungary, Spring, 2008
[7] J. M. Gómez, C. Rautenstrauch, P. Cissek. Einführung in [29] C. Atkinson and D. Stoll: "An Environment for the Ortho-
Business Intelligence mit SAP NetWeaver 7.0. Sprin- graphic Modeling of Workflow Components", in Proceed-
ger.2008 ings of the Prozessinnovationen mit Unternehmenssoft-
[8] S. H. Kaisler. Software paradigms. John Wiley and ware (PRIMIUM), Germany, 2008
Sons.2005 [30] C. Atkinson, D. Brenner, et al.. Modeling Components and
[9] W. Pree. Meta Patterns - A Means For Capturing the Es- Component-Based Systems in KobrA, in A. Rausch, R.
sentials of Reusable Object-Oriented Design. ECOOP 94. Reussner et al. The Common Component Modeling Ex-
Springer. 1994 ample: Comparing Software Component Models, Springer,
[10] J. A. Bloch. Metadata Facility for the Java Programming 2008
Language. 2004. http://www.jcp.org/en/jsr/detail?id=175 [31] R. Kimball, M. Ross. The data warehouse toolkit: the
[11] T. Stahl, M. Völter, S. Efftinge, A. Haase. Modellgetrie- complete guide to dimensional modeling. John Wiley and
bene Softwareentwicklung: Techniken, Engineering, Ma- Sons. 2002
nagement. Dpunkt Verlag.2007 [32] F. Navrade. Strategische Planung mit Data-warehouse-
[12] R. E. Filman, T. Elrad, S. Clarke, M. Aksit Aspect- systemen. Gabler Verlag. 2008.
Oriented Software Development. Addison-Wesley Profes-
sional; 1 edition. 2004
[13] JQuery a query-based code browser. homepage. The Uni-
versity of British ColumbiaVancouver, Canada.
http://jquery.cs.ubc.ca/index.htm.
[14] K. De Volder. JQuery: A Generic Code Browser with a
Declarative Configuration Language. In Practical Aspects
60