Webbasierte Generierung thematischer Softwarelandkarten

Transkript

1 Brandenburgische Technische Universität Cottbus Institut für Informatik Lehrstuhl Software-Systemtechnik Bachelorarbeit Webbasierte Generierung thematischer Softwarelandkarten Web-based generation of thematic maps Beatrice Blaschke Matrikel: Studiengang: ebusiness Ausgabe: Abgabe: Betreuer Prof. Dr. rer.nat. Claus Lewerentz Markus Uhlig M.Sc.

2

3 Eidesstattliche Erklärung Hiermit versichere ich, Beatrice Blaschke, dass ich die vorliegende Bachelorarbeit selbstständig, sowie ohne andere als die angegebenen Quellen und Hilfsmittel angefertigt habe. Alle Ausführungen, die anderen Schriften wörtlich oder sinngemäß entnommen sind, wurden kenntlich gemacht. Cottbus, den 16. Februar 2015 iii

4

5 Abstract Softwarestädte bieten dem Entwickler eine ganzheitliche Sicht auf die Strukturen und Eigenschaften seiner Software. Auf Grund ihrer Darstellung als visuelle Stadt- Metapher ermöglichen sie Analysen und Bewertungen von Qualitätsaspekten während der gesamten Entwicklungszeit. Insbesondere thematische Software-Landkarten sind ein schnell ausführbares und effektives Mittel um gewünschte Informationen einer Software abzuleiten. Denn die Karten sind speziell auf ein Thema zugeschnitten, sodass der Entwickler keine großen Einstellungen mehr vorzunehmen braucht. Bisher werden Software-Landkarten typischerweise eher als Desktop-Applikationen angeboten und haben den Nachteil nicht mobil abrufbar zu sein. Eine Webapplikation als Software-as-a-Service (SaaS) gibt dem Entwickler neben den einheitlich thematischen SW-Landkarten einen Zugriff auf seine externen Projekte sowie eine daraus resultierenden Mobilität. Im Rahmen dieser Arbeit soll daher ein Konzept entwickelt um umgesetzt werden, dass es erlaubt Software-Landkarten auf einem Server zu generieren und Client-seitig in einem Browser zu betrachten und zu navigieren. v

6

7 Inhaltsverzeichnis 1 Einleitung Motivation Zielstellung Aufbau der Arbeit Grundlagen und Stand der Technik SoftUrbs als Webapplikation Unterstützung von CI-Prozessen Verteilung der Programmkomponenten Aufbau von Software-Städten SoftUrbs als Webapplikation Erzeugung einer Software-Landkarte Übertragung der Software-Landkarte Der Server GWT Google Web Toolkit Visualisierung der Karte auf dem Client Der Client Thematische Karten in der Web-Applikation D-Visualisierung mit WebGL Präsentation der Webseite Implementierung des Frontends Implementierung des Backends Ausblick und Fazit 39 vii

8

9 Abbildungsverzeichnis 2.1 Zwei-Schichten-Architektur (two tier model) Bildausschnitt der Desktopapplikation SoftUrbs Beispiel einer Softwarestadt mit einer zirkularen Abbildungsstrategie Beispiel einer Komplexitätskarte Beispiel einer Größenkarte Prozesslandkarte zur Übertragung der Daten Datenformat der geometrischen Stadtelemente Metainformationen über die auf dem Server verfügbaren Projekte Modell zur Übertragung der Geometrien Sequenzdiagramm Ergänzung zur Zwei-Schichten-Architektur (two tier model) Kamera-Szene-Beziehung: Ausrichtung der Kamera Kamera-Szene-Beziehung: erneute Ausrichtung der Kamera Client-Klassen Darstellung einer Softwarestadt auf dem Client Darstellung einer Softwarestadt in der Desktopapplikation Server-Klassen ix

10

11 1 Einleitung 1.1 Motivation Eine Software besitzt im Laufe ihrer Entwicklung verschiedene Stadien. Wie ein Baum mit seinen Altersringen wächst sie - vom ursprünglichen Kern bis hin zu einem dicken Stamm mit Verästlungen. Im Gegensatz zu einem Baum ist die Struktur einer Software nicht immer auf Anhieb erkennbar, besonders wenn sie bereits eine beachtliche Größe erreicht hat. Sie wird undurchschaubar und sobald mehrere Entwickler an einer Software arbeiten, kann eine Qualitätssicherung nicht mehr gewährleistet werden. Erst durch unterstützende Analysewerkzeuge ist es möglich dem entgegenzuwirken. SoftUrbs (ehemals CrocoCosmo 1 ) ist ein solches Werkzeug, welches vom Lehrstuhl für Software-Systemtechnik an der BTU Cottbus-Senftenberg entwickelt wurde. Mittels einer Desktopapplikation stellt das Programm Softwarestädte zur Verfügung, mit denen der Entwickler eine ganzheitliche Sicht auf die Strukturen und Eigenschaften seiner Software erhält. Softwarestädte sind ein probates Mittel und werden seit Jahren teilweise auch in Continuous Integration (CI) Prozessen. Ein CI-Prozess ist der kontinuierliche Prozess, Teile einer Anwendung zusammenzuführen [1]. eingesetzt. Der Entwickler nutzt sie, um Informationen abzuleiten, die bedeutend für die Qualitätssicherung seiner Software sind. Desktopapplikationen haben den Nachteil, dass sie nicht mobil abrufbar sind. Zusätzlich müssen die Tools auf den Rechnern installiert und an die entsprechenden Datenquellen angebunden werden. Mobilität ist jedoch ein wichtiger Bestandteil des alltäglichen Lebens. Vor allem Unternehmen sehen in ihr eine schnellere Handlungsfähigkeit und die Möglichkeit konkurrenzfähig zu bleiben. Webbasierte Anwendungen erfahren daher eine große Beliebtheit, so dass Software-as-a-Service(SaaS)-Angebote sich stetig mehr auf dem Markt verbreiten.[2] Aufgrund dessen soll auch SoftUrbs zu einer webbasierten Anwendung weiterentwickelt werden. Thematische Softwarelandkarten sind ein geeignetes Mittel effizient Softwarestädte generieren zu lassen. Mit Hilfe von vorgefertigten Landkarten kann das gewünschte Nutzungsszenario explizit angesprochen werden. Der Entwickler wird von der Pflicht entbunden, seine Einstellungen in einem Menü selbst vorzunehmen, da die spezifischen Karten 1 projekte/crococosmos/crococosmos-beschreibung.html 1

12 2 1 Einleitung nach Themen kategorisiert sind. Die Überführung des Analysewerkzeugs in eine verteilte Anwendung liegt daher nahe. Thematische Software-Landkarten bieten sich demzufolge hervorragend als SaaS-Modell an. Diese Bachelor-Arbeit beschäftigt sich daher mit der Frage, wie thematische Softwarelandkarten im Web generiert werden können. 1.2 Zielstellung Auf Grund der genannten technischen Anforderungen soll im Rahmen dieser Bachelor- Arbeit eine Spezifikation für die Übertragung thematischer Landkarten zwischen einem Server und Client definiert werden. Neben den geometrischen Informationen und Materialeigenschaften der Stadtelemente müssen ggfs. auch Metadaten der dargestellten Softwareartefakte und abgebildete Metriken übermittelt werden, um thematische Karten auch clientseitig interaktiv zu gestalten. Zusätzlich soll ein Prototyp implementiert werden, der neben einer Übertragung der Kartendaten auch eine navigierbare, dreidimensionale Karte im Webbrowser erlaubt. 1.3 Aufbau der Arbeit Zu Beginn der Arbeit werden grundlegende Fragen und Definitionen geklärt, die dem Leser den Einstieg in das Konzept erleichtern soll. Zudem befasst sich das zweite Kapitel mit dem Stand der Technik, auf dessen Grundlage sich das folgende Konzept, in Kapitel 3, aufbaut. Darin wird erklärt, wie eine thematische Software-Landkarte erstellt, übertragen und auf dem Client visualisiert wird. Es folgt die Präsentation des Frontends auf dem Client. Schließlich folgt das Fazit mit Ausblick.

13 2 Grundlagen und Stand der Technik 2.1 SoftUrbs als Webapplikation SoftUrbs, ehemals Crococosmo, ist ein Entwicklungswerkzeug, das wie im 1. Kapitel erwähnt, dem Entwickler die Chance gibt, eine Software über die Entwicklungszeit hinweg in einer virtuellen Stadt zu analysieren und zu interpretieren. Dazu wird die Software analysiert und in ein Graph-Modell geparst. Durch die Platzierungs- und Abbildungsstrategien entsteht aus dem bearbeiteten Graph-Modell eine Softwarestadt. Die Desktopapplikation kann verschiedene Layouts in einer dreidimensionalen Landschaft mit unterschiedliche Farbeinstellungen und Skalierungen, sogenannten Mappings, als Software-Landkarten abbilden. Dem Entwickler wird dadurch eine breite Palette von Werkzeugmechanismen geboten. Der bisher einzige Nachteil ist, dass diese Applikation nicht online abrufbar ist und auf einem Rechner fest installiert werden muss. Eine webbasierte Applikation, bietet dem Entwickler den Vorteil das Werkzeug nach Belieben zu benutzen. Solche Applikationen sind für den Nutzer als auch für den Anbieter in wirtschaftlicher Hinsicht von Bedeutung. Die eine Partei gewinnt an Mobilität durch Standortunabhängigkeit, geringe bis keine Wartungsarbeiten und geringe IT-Kosten, die andere gewinnt eine stärkere und langfristige Kundenbindung und damit stabile Umsätze. Entwicklungen auf Basis des Cloud Computings erhalten daher immer mehr Aufmerksamkeit. Konzepte wie Software-as-a-Service, kurz SaaS, sind auf diese Art der Zielgruppe ausgerichtet. Der Service gewährleistet dem Kunden online-fähige Standard-Anwendungen, die flexibel skalierbar sind und lediglich individueller Einstellungen bedürfen [2]. SoftUrbs soll sich dem Technologiewandel anpassen, damit auch seine Nutzer die Vorteile einer webbasierten Applikation ausnutzen können. Aufgrund der Verteilung seiner rechenintensiven Prozesse auf einem Server und der Übertragung der fertig inszenierten Karte zum Client, ist SoftUrbs in der Lage, dem Kunden eine solche Flexibilität durch das Angebot von thematischen Software-Landkarten anzubieten. Die Umsetzung in ein solches Geschäftsmodell ergebe gleichzeitig einen erstrebenswerten Service-Gedanken. Der Entwickler kann - egal von wo - rund um die Uhr auf die Entwicklungsinformationen seiner Software zugreifen und wird ebenso davon entlassen die Software auf seinem Rechner zu installieren. Thematische Software-Landkarten als SaaS-Modell wären demnach ein ideales Geschäftsmodell. 3

14 4 2 Grundlagen und Stand der Technik 2.2 Unterstützung von CI-Prozessen In der Softwareentwicklung verwendet man heute im Rahmen seiner Arbeit standardisierte Continuous Integration (CI) Prozesse - insbesondere bei mittleren und großen Systemen. Die Entwickler einer Software verwenden einen CI-Prozess, um in der Integrationsphase am Ende eines Projektes Fehlern und Problemen entgegenzuwirken [3]. Die kontinuierliche Integration beschreibt den Prozess des fortlaufenden Zusammenführens von Komponenten zu einer Anwendung zur Steigerung der Softwarequalität [1]. Durch das Übersetzen und Linken der Anwendungsteile wird automatisch das Gesamtsystem aufgebaut. Das frühzeitige Zusammenfügen einzelner Code-Abschnitte gibt durch die Übersetzung und der automatisierten Ausführung von Tests dem Entwickler sehr schnelles Feedback über vermeintliche Fehler bei der Integration. Ein automatisierter Build und automatisch ausgeführte Tests, stellen sicher, ob die Integration erfolgreich war. Die Versionsverwaltung wird von dem CI-System überwacht, welches sofort Meldungen an die Entwickler sendet, wenn die Integration, z. B. aufgrund eines nicht fehlerfreien Tests, auf dem Team-Server fehlschlug [1]. In der Software-Entwicklungsbranche gibt es viele verschiedene CI-Systeme, wie zum Beispiel Bamboo, Hudson/Jenkins, TeamCity. SoftUrbs kann die evolutionären Eigenschaften einer Software visualisieren. Man erkennt, wie sich das Programm von Version zu Version weiterentwickelt hat. Aus Managementsicht ist das ein besonders wichtiger Aspekt, denn er zeigt, wie Zeit und damit auch Geld in einzelne Programmteile investiert wurden. Weiter bietet SoftUrbs aus Entwicklersicht viel informatives Wissen zu Qualitätsaspekten. Grundsätzlich gilt, dass SoftUrbs in vielerlei Hinsicht in CI-Prozessen einsetzbar ist. Des Weiteren ist es vorstellbar SoftUrbs in bestehende Dashboards, wie z. B. SonarQube, zu integrieren. 2.3 Verteilung der Programmkomponenten Als webbasierte Applikation wird SoftUrbs in mehrere Anwendungen geteilt. Der Browser stellt den Client dar, der seine Informationen vom Server bezieht. Durch die Verteilung der Programmkomponenten wird das komplexe Programm in einem sogenannten verteilten System ablaufen. Mehrere Rechner erhalten Zugriff auf Informationen und können diese so untereinander austauschen. Der grundlegende Ablauf einer Kommunikation zwischen den Client und Server sieht folgendermaßen aus: Ein Prozess, der Client, fordert eine Operation oder einen Service von einem anderen Prozess, dem Server, an. Nach Erhalt einer Anwendungsnachricht führt der Server den angeforderten Service aus und gibt dem

15 2.3 Verteilung der Programmkomponenten 5 Client ein Resultat oder das Ergebnis des Service zurück. Dieses einfache Client-Server-Modell führt zu einer Reduktion auf mehrere Clients und einem Server, und es legt fest, wie eine Anwendung einen Service eines Servers in Anspruch nehmen kann. Möglichkeiten des Client-Server-Modells liegen in der Beschränkung, dass ein Client nur einen individuellen Service in Anspruch nehmen kann und ein Prozess entweder als Client oder nur als Server agieren kann [4, Seite 28]. Eine verteilte Anwendung entsteht nur dann, wenn einzelne Aufgaben auf Softwarekomponenten ausgelagert und dort bearbeitet werden. Schichtenmodelle definieren die Client-Server-Beziehung und wer welche Funktionalitäten zu erfüllen hat. Verschiedene Komponenten können aus einer verteilten Anwendung ermittelt werden - wie die Benutzeroberfläche, das Benutzerinterface, die Verarbeitung, das Datenmanagement und die persistente Datenspeicherung. Sie bilden das Netzwerk, in dem die Komponenten auf Client und Server aufgeteilt werden müssen. Benutzerinterface Verarbeitung, Applikationslogik Grafische Benutzeroberfläche Datenmanagement Daten Client Server Netzwerk Quelle: Eigendarstellung, Anlehnung an G. Bengel - Grundkurs Verteilte Systeme Abbildung 2.1: Zwei-Schichten-Architektur (two tier model) In der Zwei-Schichten-Architektur (two tier model) kommen Thin Clients, Applet Clients, Fat Clients sowie Null Clients zum Einsatz. Allerdings findet man in der Praxis auch verteilte Anwendungen als mehrschichtige Anwendungen (multi tier model), da diese bessere Skalierbarkeit beim Server und den Einschluss von webbasierten Technologien ermöglichen [4]. Beim Null Client wird der Client vom Server zwischen der graphischen Benutzeroberfläche und dem Benutzerinterface getrennt. Der Client übergibt nur Tastaturanschläge und Mausbewegungen an den Server [4]. Der Thin Client trennt die beiden Schichten zwischen Benutzerinterface und der Anwendung [4]. Beim Applet Client übernimmt der Client neben dem Benutzerinterface Teile der Applikationslogik in Form eines Applets und

16 6 2 Grundlagen und Stand der Technik beim Fat Client teilt sich der Client die Applikationslogik mit dem Server oder übernimmt sie ganz, sodass der Server nur einen File- oder Datenbank-Server darstellt [4]. Die Schichtenarchitekturen geben vor, wer mit wem kommuniziert und stellen damit eine genaue Ablauforganisation auf, die dem Austausch von Informationen dient. Der Austausch benötigt ferner ein Zusammenspiel der Softwarekomponenten - eine kooperative Verarbeitung. Für eine erfolgreiche Kommunikation bedarf es einer entsprechenden Koordinierung, die durch folgende Verfahren technologisch unterstützt werden kann: Nachrichtenübertragung (Message Passing), entfernte Prozeduraufrufe (Remote Procedure Call, RPC), entfernte Methodenaufrufe (Remote Method Call, RMC), entfernte Komponentenaufrufe durch Bereitstellung eines Interfaces (Remote Interface Call, RIC), webbasierte Methoden zur Übertragung von Dokumenten und Java-Code im Internet, Suchen und Aufrufen von Web Services (Web Service Call, WSC) [4]. Der simple Übertragungsaustausch von Nachrichten wird durch das Message Passing realisiert. Es kann synchrone als auch asynchrone Nachrichten zwischen Sender und Empfänger austauschen und die persistent auf der Platte oder nicht-persistent im Hauptspeicher zwischenspeichern. Für den synchronen Nachrichtenaustausch verwenden die Nachrichtenübertragungssysteme TCP/IP-Sockets. Für den asynchronen Austausch wird die Übertragung durch den Zwischenspeicher umgesetzt. Voraussetzung für die Verwendung des Message Passing ist, dass bereits ein verteiltes System existiert.[4] Zur Bildung eines verteiltes Systems verwendet man entfernte Prozeduraufrufe. Ein Programm versteht sich als eine nicht verteilte monolithische Anwendung die genauer betrachtet eine Ansammlung von Prozeduren ergibt. In einer verteilten Anwendung werden die Prozeduren in Prozeduraufrufe (Clients) und in die Prozedur selbst (Server) geteilt. Nach der Aufteilung des Programms in Aufruf und Verarbeitung wird die eingangs existierende monolithische Struktur in eine Client-Server-Struktur weiterentwickelt. Um eine Prozedur auf einer anderen Maschine aufrufen zu können, wird die Verwendung von Remote Procedure Calls vorausgesetzt.[4] Für die Weiterentwicklung von SoftUrbs von der Desktopapplikation in eine Webapplikation wird es daher unumgänglich sein, die einzelnen Programmteile in Aufrufe und Aufgabenverarbeitung aufzuteilen und Remote Procedure Calls zu verwenden. Welche weiteren Übertragungsmethoden für eine Umsetzung notwendig sind, werden in der Konzeption und Implementierung aufgezeigt.

17 2.4 Aufbau von Software-Städten Aufbau von Software-Städten Thematische Softwarelandkarten bauen auf dem Prinzip der Software-Städte auf. Sie ermöglichen es erst, Programmiercode in eine dreidimensionale Stadtlandschaft umzusetzen. Die Bedeutung und der Aufbau einer solchen Software-Stadt sind demnach Grundlage für die Entwicklung thematischer Software-Landkarten. Software-Städte sind ein probates Mittel, das dem Entwickler eine ganzheitliche Sicht auf die Strukturen und Eigenschaften seiner Software bietet. Weil die Software- Entwicklung ein komplexer Prozess von der Anforderungserhebung bis hin zu langfristigen Wartungsaktivitäten ist, werden sie als Analysewerkzeug unter anderem in CI-Prozessen zur Überprüfung von Qualitätsmerkmalen eingesetzt. Sie unterstützen den Entwickler den Software-Entwicklungsprozess zu steuern und ihn über den Bau oder über die Instandhaltung des Software-Produktes zu informieren. Dafür wird der aktuelle Entwicklungsstand vieler Dokumente und Daten der Software auf unterschiedlichen Detailebenen und unterschiedlich beschriebenen Perspektiven verwendet [5]. Softwarestädte sind zudem eine von mehreren Techniken evolutionäre Daten zu visualisieren. Allerdings wird im Rahmen dieser Bachelor-Arbeit nur das Analysewerkzeug SoftUrbs, vom Lehrstuhl Software-Systemtechnik der BTU Cottbus - Senftenberg, und die damit verbundene Visualisierungstechnik betrachtet. SoftUrbs ist eine Desktopapplikation zur Analyse von Software-Systemen in Softwarestädten. Eine Softwarestadt ist, wie der Name schon sagt, eine Abbildung einer Stadt. Es handelt sich dabei um eine dreidimensionale Abbildung des Quellcodes einer Software. Der Aufbau einer Softwarestadt in SoftUrbs wird in drei Modelle gegliedert. Die Grundlage bildet die statische Softwarestruktur, das so genannte logische primäre Modell. Es zerlegt das zu analysierende System in Module und stellt die Abhängigkeiten zwischen ihnen dar. Das zweite Modell ist das geometrische sekundäre Modell. Es stellt 3D-Geometrien aufbauend auf den Daten des primären Modells dar, welches die Hauptstruktur und evolutionären Eigenschaften des Software-Systems einnimmt. Die entstehende Gestalt in diesem Modell wird hauptsächlich von den speziellen Layouts der Software-Elemente beeinflusst. Diese Layouts werden aus vier möglichen Aspekten des primären Modells generiert: Aus der Zerlegung der Hierarchie, aus den Eigenschaftselementen, aus den Abhängigkeiten, wie Aufrufen, Zugriffsrelationen oder Typ-Vererbungsrelationen oder aus der Entwicklungszeit [5]. Das 2. Modell ist die Basis für das tertiäre Modell. Das tertiäre Modell kann sehr unterschiedliche Visualisierungen annehmen. Jedes davon wurde entworfen, um ein spezifisches Nutzerszenario zu unterstützen. SoftUrbs verwendet zwei verschiedene Einstellungen, um das tertiäre Modell aus dem sekundären Modell zu kreieren - zum einen die Dekoration und zum anderen die Projektion. Bei der Dekorationseinstellung wird das vollständige sekundäre Modell als Basis verwendet. Doch um visuelle Eigenschaften, wie Farbe oder Textur, zu ändern, benötigt das Modell Daten des

18 8 2 Grundlagen und Stand der Technik primären Modells. Die Projektionseinstellung baut ebenso auf dem sekundären Modell auf. In dieser Einstellung wird das Modell mit 2D-Komponenten wie Icons, Charts oder Diagrammen ergänzt [5]. Die sogenannte dreistufige kartografische Modellierungskette baut daraufhin systematisch eine Software-Stadt auf, ausgehend von den Informationen eines Software- Systems. Für diese Städte bietet sich eine breite Palette an unterschiedlichen Nutzungsszenarien an, die auf einer gemeinsamen Grundlage über die Kommunikation der Software sowie über die Lokalisierung von Produkteigenschaften (wie Größe oder Qualitätsindikatoren) und Prozessereignissen (wie Fehler finden oder Änderungen machen) basiert [5]. Ein Ergebnis dieser Zusammenführung von den drei verschiedenen Modellebenen ist in der Beispielabbildung 2.2 zu sehen. Auf diesen grundlegenden Anforderungen sowie dem dreistufigen kartografischen Modell werden Software-Städte im Analysewerkzeug SoftUrbs generiert und dürfen bei der Erstellung der thematischen Software-Landkarten nicht vernachlässigt werden. Die Unterscheidung und Bedeutung dieser Modelle ist für die Konzeption und Implementierung der thematischen Software-Landkarten von entscheidender Bedeutung. Sie entscheiden, in welchem Zustand die Daten sind, wenn sie für eine Übertragung zum Client bereitstehen. Die Ergebnisse, die in dieser Bachelor-Arbeit erworben werden, werden daher ausschließlich auf dem Programm SoftUrbs aufbauen. Die derzeitige Desktopapplikation von SoftUrbs bietet viele verschiedene Abbildungsmechanismen. Diese werden durch die Wahl des Layouts, durch Abbildungsstrategien sowie Szenario-orientierte Gebäude spezifiziert. In der Abbildung ist eine Softwarestadt zu sehen, deren Geometrien unterschiedliche Bedeutungen haben. Die Türme bzw. Gebäude bilden die Klassen oder Module eines Programmcodes. Bei allen Platzierungsstrategien gilt, wenn die Gebäude sehr nah aneinander stehen, gehören sie zu einer gemeinsamen Komponente. Diese sind wiederum mit anderen Komponenten durch Straßen oder Packings verbunden. Im Ausschnitt 2.2 sieht man eine Stadt mit dem Layout EvoStreets. Die Gebäude sind mit den anliegenden Straßen verbunden. Welche sinnbildlich aus Neben- und Hauptstraßen bestehen. Sie stellen die Beziehungen der einzelnen Klassen zueinander dar. Die Hierarchie ist links in einer Navigationsleiste zu finden. Zudem sind die Gebäude unterschiedlich farbig. Je stärke die Farbe in den roten Bereich rückt, desto mehr Codezeilen hat diese Klasse (LOC).

19 2.4 Aufbau von Software-Städten 9 Quelle: Eigendarstellung Abbildung 2.2: Bildausschnitt der Desktopapplikation SoftUrbs Die Desktopapplikation besitzt eine Symbolleiste mit der man Konfigurationen in der Ansicht vornehmen kann. Dazu gehört u. a. die Veränderung des Layouts, der Zeitpunkt der Visualisierung mittels Zeitleiste oder das Szenario-orientierte Abbilden der Gebäude. Das Layout kann die Anordnung der Gebäude verändern. Dafür gibt es verschiedene Platzierungstypen, wie linear, zirkular oder kürzeste Distanz. Die Wahl der Abbildungsstrategien richtet sich nach dem Informationsbedarf des Nutzers. Nicht jedes Projekt, kann mit allen Abbildungsstrategien dargestellt werden, da jeder Programmcode von Projekt zu Projekt unterschiedlich ist. Welche Abbildungsstrategien möglich sind, wird auch in der Konzeption für die Webkomponente eine wichtige Rolle spielen. Jedoch werden die Layouts der einzelnen Softwarelandkarten vorgegeben. Denn ein Ziel dieser Arbeit ist es ebenso, dem Entwickler einen schnellen Zugang zu Softwarekarten zu ermöglichen. Das bedeutet neben dem mobilen Aspekt auch, dem Entwickler durch die Webkomponente ohne müßige Konfigurationseinstellungen Karten zu präsentieren, die gezielt auf ein Thema abgestimmt sind. Daher werden sie auch thematische Softwarelandkarten genannt.

20

21 3 SoftUrbs als Webapplikation 3.1 Erzeugung einer Software-Landkarte In diesem Kapitel wird SoftUrbs als Webapplikation konzeptioniert. Es wird erörtert, wie man eine Software-Landkarte auf dem Client erzeugt und wie die Daten bis zu ihm gelangen. Dazu werden technische Möglichkeiten vorgestellt, die sich für eine initiale Implementierung eigenen. Um herauszufinden auf welchem Weg man Software-Landkarten in einem Browser erzeugt, muss man zuvor verstehen, wie der bereits existierende Erzeugungsprozess in der Desktopapplikation funktioniert. Eine desktopbetriebene Software besteht im Grunde aus mindestens zwei Teilen: der grafischen Benutzeroberfläche mit Interaktionsspielraum und dem rechnenden im Hintergrund liegenden Part, der zur Ausführung des Programms Prozesse startet, die Daten verwaltet und mit der Hardware kommuniziert [4]. Die gesamte Kommunikation findet zumindest auf einem Rechner statt und ist von außen nicht erreichbar, bzw. steuerbar. Der Aufbau einer Webapplikation ist ähnlich. Sie teilt sich jedoch in einem gewissen Punkt. Ein Teil liegt auf dem Client und ein anderer auf dem Server. Der Client verfügt über die grafische Oberfläche, während der Server mit der Verarbeitungslogik und der Datenbank arbeitet. Webapplikationen haben den Vorteil mobil zu sein. Der Nutzer kann jederzeit auf die Software zugreifen, während der Anbieter Ressourcen spart. Mit Hilfe eines Konzepts soll SoftUrbs nun um eine Webapplikation erweitert werden. Zur Integration einer Web-Anwendung benötigt man folgende Überlegungen: In welchen Programmiersprachen findet die Implementierung statt? Wie werden welche Daten übertragen? Wie werden die Daten aus der bestehenden Software entnommen und in welchem Zustand sollen diese sein? Erfolgt die Berechnung der Stadt auf dem Client oder auf dem Server? 11

22 12 3 SoftUrbs als Webapplikation Erzeugung einer Karte in der Desktopapplikation SoftUrbs ist eine Java-Applikation, die aus verschiedenen externen Quellen (zum Beispiel SonarQube, SVN oder Git) Informationen mittels Extraktoren herauslesen kann. Hierzu analysiert und zerlegt es die Informationen aus der Quelle, um aus einer Software die Codestruktur in ein Graph-Modell zu überführen. Bei den Informationen handelt es sich um ein System bzw. eine Software, das in sich Abhängigkeiten zwischen einzelnen Teilen verbirgt. Das aus der Zerlegung entstehende Graph-Modell, auch Datenmodell genannt, ist ein hierarchischer, attribuierter und gezeiteter Graph. Zudem stellt es das primäre Modell dar und wird damit zur Basis für die Erstellung der dreidimensionalen Software-Landkarte. Ein Graph besteht aus Knoten und Kanten. Weil sich ein System im Laufe der Zeit verändert, in dem es sich zum Beispiel vergrößert, enthält der Graph Informationen, wann ein Knoten hinzugefügt oder entfernt wurde. Hierbei unterscheidet SoftUrbs die Attribute zwischen zeitabhängig und zeitunabhängig. Die Anzahl der Codezeilen ist beispielsweise zeitabhängig, während die Tiefe eines Knotens in der Hierarchie hingegen zeitunabhängig ist. Das Graph-Modell wird mit Hilfe verschiedener Platzierungsstrategien (Layouts) in ein geometrisches Modell überführt. Hierfür werden Layouter verwendet, welche die Elemente im Raum platzieren. SoftUrbs unterscheidet verschiedene Arten von Platzierungsstrategien. Eine Strategie ist die Gebäude der Softwarestadt auf eine Art Plateau aufzubauen. Sie heißen Packings und stellen Komponenten dar. Hier finden sich die Kinder eines Knotens wieder, dessen Zusammengehörigkeit durch ihre räumliche Nähe unterstützt wird. Des Weiteren ist es möglich, die Gebäude mit ihren Packings kreisförmig aufzustellen. Im Kern der zirkularen Abbildung befinden sich die größten Packings, also eine Komponente mit den meisten Klassen (siehe Abb. 3.1). Eine weitere Strategie ist die Gebäude der Stadt mit Straßen zu verbinden, wie in EvoStreetsLayout, das bereits schon im 2. Kapitel vorgestellt wurde (siehe Abb. 2.2). Nach der Platzierungsstrategie folgt die Abbildungsstrategie (Mapping). Das Mapping wird auf die Gebäude der Stadt angewandt. Sie bilden die numerischen Werte auf die geometrischen Freiheitsgrade wie Breite, Tiefe, Höhe und Farbe ab. Das heißt, es werden die quantitativen Eigenschaften ausgelesen und auf geometrische Eigenschaften abgebildet. Die vorhandenen Kennzahlen aus dem Datenmodell entscheiden welche Softwarelandkarten darstellbar sind und welche nicht. Diese Entscheidung betrifft auch Karten, die der Client zur Verfügung stellen wird. Der Client kann dem Entwickler keine Karten zur Auswahl stellen, die mit dem Projekt nicht visualisierbar sind. Eine Karte ist die Abbildung einer Software-Landkarte, die wiederum eine Softwarestadt ist, die eine konkrete Frage beantworten soll. Eine konkrete Frage ist zum Beispiel: Wurde die Software zu kompliziert programmiert, dass Außenstehende sie nicht mehr verstehen können? Wurde der Programmcode ausführlich kommentiert? Haben die Klassen zu viele Codezeilen?

23 3.1 Erzeugung einer Software-Landkarte 13 Quelle: Eigendarstellung Abbildung 3.1: Beispiel einer Softwarestadt mit einer zirkularen Abbildungsstrategie In der Web-Applikation werden dem Entwickler unterschiedliche thematische Software- Landkarten zur Verfügung gestellt, die bestimmte Themengebiete abdecken sollen. In der desktopbetriebenen Software, gibt es dazu keine konkrete Auswahl. Der Entwickler übernimmt die Konfigurationen selbst, in dem er beim Mapping die Werte eigenhändig einstellt. Allerdings gilt das nur für die SoftUrbs-Version, die für diese Bachelor-Arbeit bereitgestellt wurde. Anhand der folgenden Beispiele 3.2 und 3.3 kann man erkennen, wie eine Komplexitätskarte und eine Größenkarte nach Einstellung des Louyouts und Mappings aussehen kann.