Lieferung 8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene

Transkript

1 Lieferung 8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene für das BMBF-Projekt Modellgetriebene agile Entwicklung für mobile Anwendungen (ModAgile Mobile) Arbeitspaket AP 8 Test- und Qualitätssicherungsumgebung Arbeitspaketleitung Andrena Förderkennzeichen 01IS11012A-C Projektleitung andrena objects AG Jochen Winzen Partner andrena objects ag arconsis IT-Solutions GmbH FZI Forschungszentrum Informatik Autoren Antonia Volk, Christian Jansohn, Martin Küster Lieferdatum M21 Letztes Änderungsdatum Version 1.0 ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 1

2 1 Einleitung USUS ( ist ein Eclipse Plugin, das die Softwareentwicklung unterstützt. Das Plugin integriert mehrere Tools die dabei helfen, u.a. zur statischen Codeanalyse und zur Bestimmung der Testabdeckung. Ein weiteres zentrales Element von USUS ist die Bestimmung von Codequalität mit Hilfe von Metriken. Diesen Metriken liegen OO-Designprinzipien zur Grundlage. Stellen, die auf eine schlechte Qualität deuten, sogenannte Hotspots, werden direkt ausgewiesen. Änderungen am Code werden sofort ausgewertet und Feedback dazu wird unmittelbar angezeigt. Indikatoren verdeutlichen, welche Auswirkungen Änderungen auf die Codequalität haben. Die Anzeige von möglichen Problemstellen im Code, ermöglicht es dem Entwickler, diese zu beheben. Dies ist möglich, da USUS direkt in die Entwicklungsumgebung integriert ist. Eine einfache Bedienbarkeit ist somit ebenfalls gewährleistet. Für die Modellentwicklung jedoch kann USUS nicht ohne weiteres verwendet werden. Die Grundlage bei der Berechnungen der Metriken ist Sourcecode, deren Ergebnisse liefern Aussagen über dessen Qualität. So ergibt z.b. eine Aussage über die Anzahl der Anweisungen in einer Methode keinen Sinn, da im Modell nur festgelegt wird, dass eine Methode existiert. Insbesondere ist eine hohe Qualität von Modellen wichtig, da diese die Grundlage von (generiertem) Sourcecode liefern. Auch wäre es wünschenswert Vorteile von USUS, wie das unmittelbare Feedback, in der modellgetriebenen Entwicklung einsetzen zu können. Das Ziel, welches bei der Erweiterung von USUS auf Modellebene verfolgt wurde, besteht also darin, ein Eclipseplugin zu erstellen, in dem die Qualität von Modellen mit Metriken bestimmt wird. Die Auswertung der Metriken soll unmittelbar erfolgen, um den Entwickler sofort Feedback zu geben, damit die Qualität der Modelle verbessert wird. Das verwendete Vorgehen bestand darin, dass wir das ursprüngliche USUS als Grundlage verwendet haben und zwar sowohl konzeptionell, als auch Teile des Codes. Der erste Fokus lag darauf, Metriken für Modelle zu berechnen, deswegen wurden alle Views, die nicht dafür benötigt werden, entfernt. Eine Übersicht aller noch vorhandener Views ist in Kapitel 3. Die Metriken wurden ausgetauscht und durch Metriken ersetzt, die auf Modellen basieren. Ein Überblick über diese Metriken findet sich in Kapitel 2. 2 Metrikerhebung Die Metrikerhebung wurde für zwei Modelltypen umgesetzt, die für die Generierung der mobilen Anwendungen besonders wichtig ist. Die wissenschaftlichen Ergebnisse der Metrikerhebung zur Qualitätssicherung von Modellen wurden innerhalb einer vom FZI betreuten Bachelorarbeit [1] erarbeitet und im Projektkonsortium diskutiert und verfeinert. 2.1 Domänen- und App-Modelle Zunächst für die Domänenmodelle, also Daten- und Strukturmodelle, die erfassen, welche Entitäten in der modellierten Domäne existieren. Für die Modellierung dieser Domänenentitäten wurde das vom Eclipse Modeling Framework (EMF) bereitgestellte Metamodell Ecore verwendet. Mit diesem Modell lassen sich in etwa dieselben Eigenschaften festlegen, wie mit einem UML Klassenmodell. Klassen modellieren dabei die Domänenentitäten, Attribute deren Eigenschaften und Assoziationen deren Beziehungen. Der Grund für die Wahl dieses Modell war die gute Abbildbarkeit auf objektorientiere Strukturen wie Klassen und Referenzen. Wegen der guten Übereinstimmung mit objektorientieren Strukturen lassen sich alle Metriken auf solche Modelle übertragen, die aus der Qualitätssicherung von objektorientiertem Code bekannt sind. Dies umfasst Eigenschaften wie die Größe (in Anzahl Attribute und Referenzen) der Klassen, oder darin enthaltene Vererbungstiefen. Ziele, die durch die Metrikerhebung erfüllt werden sollen, umfassen die Konsistenz, die Strukturiertheit, die Wiederverwendbarkeit und die Verständlichkeit von Modellen. Neben den Domänenobjekten wurden auch Metriken definiert und erhoben, die spezifisch für Modelle von mobilen Anwendungen ( App-Modelle ) sind. Da das App-Modell für die Generierung des Anwendungscodes ein zentraler Bestandteil ist, muss dieser auch entsprechend qualitätsgesichert werden. Die Frage, welche Metriken hierfür besonders geeignet sind, musste im Rahmen des Arbeitspaketes beantwortet werden. Auch für die App-Modelle wurden Ziele definiert, die durch die ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 2

3 Metriken erfüllt werden sollen. Dies betraf wie bei den Domänenmodellen die Konsistenz, die Verständlichkeit sowie die Wiederverwendbarkeit der Modelle. Zudem wurden aber noch die Ziele Testabdeckung und Usability hinzugenommen. 2.2 GQM-Ansatz zur Metrikauswahl Für die Qualitätssicherung von Code mithilfe von Metriken exisitert eine Vielzahl von nützlichen und weniger nützlichen Metriken. Als Teil des Arbeitspaketes musste die Frage beantwortet werden, welche von diesen Metriken brauchbar für die Qualitätssicherung von Modellen sind. Um nicht die Fülle von Metriken untersuchen zu müssen, wurde ein zielgerichtetes Vorgehen verwendet. Die Brauchbarkeit einer Metrik wurde anhand von Zielen und daraus abgeleiteten Fragen definiert, wie sie vom Goal-Question- Metric-Ansatz von Basili et al. bekannt sind. Falls eine Metrik eine dieser Fragen beantwortet, wurde sie als brauchbar eingeordnet, andernfalls nicht. Ziel: Konsistenz von Modellen (Domänenmodelle, App-Modelle) Ziel: Verständlichkeit von Modellen (Domänenmodelle, App-Modelle) Ziel: Strukturiertheit von Modellen (Domänenmodelle) Ziel: Wiederverwendbarkeit von Modellen (Domänenmodelle, App-Modelle) Ziel: Hohe Testabdeckung der Modelle (App-Modelle) Ziel: Hohe Usability (App-Modell) Auf Basis dieser Ziele wurden dann Fragen definiert, die eine Antwort darauf geben können, ob die oben genannten Ziele erreicht wurden. 2.3 Modellbasiertes Vorgehen zur Metrikdefinition und Verarbeitung Dem modellgetrieben Paradigma folgend, wurde auch für die Definition und Konfiguration von Metriken sowie für die Speicherung von Ergebnissen Modelle verwendet. Zunächst beschreibt das Metrikmodell (Abbildung 1), wie Metriken erfasst werden. Eine Metrik ist dabei vom Typ Metric und befindet sich in einer MetricCollection. Das GQMModel modelliert den in Abschnitt 2.2 erläuterten Zusammenhang zwischen Zielen und Metriken. Die über die Assoziation gqmmetrics referenzierten Metriken dienen also, um die im GQM-Modell angelegten Fragen zu beantworten. ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 3

4 Abbildung 1 Das Metrikmodell (aus [1], S. 40) Das Konfigurationsmodell (Abbildung 2) enthält die für die Konfiguration einer Metrik notwendigen Parameter. Insbesondere Schwellwerte (threshold in MetricSettings) sind wichtig für die Definition, wann eine Metrik zu einer Verletzung führt. Diese Schwellwerte sind schwer domänen- und modellunabhängig zu definieren. Expertenwissen oder ein Benchmark können die geforderten Werte liefern. Im Projekt Modagile wurde ein Interview durchgeführt, welches sinnvolle Schwellwerte für die Parameter schätzen ließ. Abbildung 2 Das Konfigurationsmodell (aus [1], S. 42) Schließlich wurde noch ein Modell definiert, das die Ergebnisse eines Messlaufs beinhaltet und speichert (Abbildung 3). Zentrale Klasse in diesem Modell ist das ResultObject. Es stellt den Bezug her zwischen ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 4

5 der Konfiguration einer Metrik und den Elementen, auf denen diese Metrik ausgerechnet wird (über appmodelelement oder ecoremodelelement). Abbildung 3 Das Ergebnismodell (aus [1], S. 43) In drei Container-Stufen können Metriken aggregiert werden: zunächst pro Modell-Typ (also Domänenvs. App-Modell, via CalculationResults), dann anhand der Metrik-Klasse (via MetricClassTypeResultContainer) und schließlich auf Basis der Metrik selbst (via MetricResultContainer). 3 Darstellung in Eclipse-Views Das Eclipse Plugin besteht aus einer Perspektive, die drei Views umfasst. Die erste View dient der Auswahl von Modellen, für die die Metriken berechnet werden sollen (Modellauswahl-View). In der zweiten View (Cockpit-View) werden die ermittelten Metriken ausgewiesen. Die letzte View (Hotspots View) zeigt alle gefunden Hotspots zu einer Metrik an. 3.1 Modellauswahl-View Die Modellauswahl-View dient zur Auswahl der Modelle, für die Metriken berechnet werden sollen. Es werden hier alle Modelle, die sich im Workspace befinden, in einer Liste angezeigt. Usus für Modelle unterstützt sowohl allgemeine Modelle (Dateiendung.ecore) und Modagile spezifische Screenflowmodelle (Dateiendung.app). Die Berechnung beginnt automatisch, wenn die Modelle verändert und gespeichert werden. Wenn die Berechnung abgeschlossen ist, werden die Ergebnisse sofort im Cockpit angezeigt. ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 5

6 3.2 Cockpit-View Abbildung 4 Auswahl der Modelle Die Cockpitview ist der zentrale Punkt von Usus für Modelle. Hier wird die Auswertung aller berechneten Metriken für die ausgewählten Modelle angezeigt. Die Anzeige findet in Form einer Tabelle statt. Jede Zeile entspricht dabei einer Metrik. Durch einen Doppelklick auf eine Zeile lassen sich die Hotspots der Metrik in einer separaten View öffnen. Eine Trendanzeige informiert ob sich die Qualität der Modelle verbessert bzw. verschlechtert hat. Abbildung 5 Usus Cockpit Eine Darstellung des Cockpits befindet sich in Abbildung 5. Der größte Teil nimmt die Tabelle mit der Auswertung der Metriken ein. Diese enthält im Detail folgende Spalten: - Indicator: Der Name der Metrik. ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 6

7 - Avg. Rating: Durchschnittlicher Wert der Metrik. Dieser berechnet sich als Summe aller Werte der jeweiligen Metrik, geteilt durch die Anzahl der Einheiten, auf die sie sich bezieht. - Hotspots: die Anzahl der Hotspots zu dieser Metrik. - Total: Anzahl der Einheiten, die für die Auswertung der Metrik herangezogen wurden. Da sich Metriken auf unterschiedliche Einheiten eines Modells beziehen können, wird zusätzlich der Typ angegeben, auf den sich die Metrik bezieht. - Trend: Ein Indikator, wie sich der Wert der Metrik verändert. Ein Minus deutet an, dass sich der Wert verschlechtert. Ein Plus deutet an, dass sich der Wert verbessert. Im Cockpit befinden sich zusätzlich über der Tabelle noch zwei Steuerelemente. Das erste dient dazu einen Snapshot anzulegen, bei dem der Trend zurückgesetzt wird. Das ist nützlich wenn man gezielt ein Modell verändern möchte. Man erzeugt vor der Anpassung einen Snapshot. Wenn man mit den Änderungen fertig ist, zeigt der Trend genau an, wie sich die Anpassungen auf die Metriken ausgewirkt haben. Mit dem zweiten Element lässt sich eine Neuberechnung der Metriken erzwingen. Das automatische Neuberechnen lässt sich einem Eintrag im Kontextmenü aktivieren/deaktivieren. 3.3 Hotspot-View In der Hotspot-View werden alle Hotspots zu einer Metrik angezeigt. Öffnen lassen sich diese durch einen Doppelklick auf die Metrik im Cockpit. Dargestellt werden die Hotspots in Form einer Tabelle. Pro Zeile befindet sich eine ausgewertete Einheit. Der Typ der Einheit hängt von der jeweiligen Metrik ab. Die Tabelle enthält folgende Spalten: - Value: Ergebnis der Metrikberechnung auf der Einheit - Name: Name der betreffenden Einheit (z.b. der Name einer Klasse in einem Modell) - Path: Pfad zu dem betroffenen Modell - Trend: Analog zu der Ausweisung des Trends im Cockpit wird eine Verbesserung durch ein Plus und eine Verschlechterung durch ein Minus dargestellt. Zusätzlich wird noch angezeigt, wie stark sich der Wert verändert hat. Abbildung 6 Usus Hotspots mit ausgewähltem Hotspot Durch einen Doppelklick auf eine Zeile in der Tabelle, wird der Hotspot, je nach Dateityp, direkt im passenden Editor geöffnet. Dadurch kann die Datei sofort bearbeitet werden. Die Suche danach entfällt. ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 7

8 4 Szenario/ Beispiel Das folgende Szenario illustriert beispielhaft die Verwendung von Usus für Modelle. Dabei wurde bewusst ein sehr einfaches Modell gewählt, um die grundlegende Funktionsweise zu verdeutlichen. Um mit Usus arbeiten zu können, muss zunächst die Perspektive Model Metrics Usus geöffnet werden. Mit ihr öffnen sich die folgenden Views Projects covered by Usus und das Usus Cockpit. Die Projekte, auf deren Modellen Metriken berechnet werden sollen, müssen sich im Workspace befinden. Das folgende Bild zeigt das Beispielprojekt. Dieses enthält zwei Ecore-Modelle und ein App-Modell. Abbildung 7 Package Explorer In der View Projects covered by Usus tauchen nun diese drei Modelle auf. Mit Hilfe der Checkboxen ist es möglich, die auszuwertenden Modelle auszuwählen. Wir beschäftigen uns zunächst mit dem Ecore- Modell ModelOne und wählen dieses aus. Abbildung 8 Covered Projects Das Beispielmodell besteht zu Beginn aus den beiden Klassen ClassOne und ClassTwo, wobei ClassTwo die Oberklasse von ClassOne ist. ClassOne hat ein Atrribut, ClassTwo zwei Attribute und eine Operation. ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 8

9 Abbildung 9 ModelOne im ersten Zustand Das Ecore-Modell wird im Folgenden aus Übersichtsgründen in Diagrammform dargestellt. Zum Vergleich sieht man hier das Modell in der Baumstruktur: Abbildung 10 ModelOne in der Baumstruktur Speichert man das Modell, aktualisiert sich automatisch das Usus Cockpit und zeigt die berechneten Metriken an. Aktualisiert sich das Cockpit nicht, sollte überprüft werden, ob die automatische Berechnung der Metriken aktiviert ist: ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 9

10 Abbildung 11 Aktivieren der automatischen Berechnung Prinzipiell werden im Cockpit sowohl Metriken für Ecore-Modelle als auch für App-Modelle ausgegeben. Die Metriken für das angelegte Modell sind im Bild rot markiert. Man erkennt, dass im aktuellen Modell noch keine Hotspots, also kritische Stellen, enthalten sind. Abbildung 12 Usus Cockpit für ModelOne Im nächsten Schritt fügen wir dem Modell die neue Klasse ClassThree mit einem Attribut und einer Operation hinzu. ClassTwo erbt von ClassThree. ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 10

11 Abbildung 13 ModelOne im zweiten Zustand Das aktualisierte Cockpit sieht nun so aus: Abbildung 14 Usus Cockpit für ModelOne im zweiten Zustand Wie man leicht am Trend erkennt, haben sich zwei Metriken so verschlechtert, dass der Schwellwert überschritten wurde und ein Hotspot angezeigt wird. Der definierte Schwellwert ist im Tooltip ersichtlich, der erscheint, wenn man den Mauszeiger über die entsprechende Metrik bewegt. Mit einem Doppelklick auf eine Metrik öffnet sich die Hotspot-View, aus der die konkreten Hotspots ersichtlich werden. ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 11

12 Abbildung 15 Usus Hotspots Man sieht, dass sich der Hotspot in der Klasse ClassOne im Modell bezieht, da für diese Klasse der Schwellwert der empfohlenen Vererbungstiefe überschritten wurde. Ein Doppelklick auf den Hotspot öffnet die betreffende Stelle im entsprechenden Editor. Möchte man die nächste Entwicklung an einem Modell mit der aktuellen Version vergleichen, bietet das Cockpit die Möglichkeit eines Snapshots. Mit Hilfe dieses Snapshots wird das aktuelle Ergebnis der Metrikberechnung zwischengespeichert und mit der nächsten ausgeführten Berechnung verglichen. Das bedeutet, dass der Trend zurückgesetzt wird und nach der nächsten Berechnung der Trend in Relation zum vorherigen Ergebnis angezeigt wird. Abbildung 16 Snapshot Erzeugt man also einen Snapshot vom aktuellen Stand des konstruierten Beispiels, kann man nach der Weiterarbeit am Modell das Metrikergebnis mit dem vorherigen Stand vergleichen. Um das zu demonstrieren, wird das Modell so angepasst, dass die Vererbung zwischen ClassTwo und ClassThree wegfällt. ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 12

13 Abbildung 17 ModelOne im dritten Zustand Speichert man und untersucht den aktuellen Zustand der Metriken, sieht man schnell, dass sich das Ergebnis im Vergleich zum vorherigen verbessert hat. Das erkennt man deutlich am grünen Indikator in der Trend-Spalte. Abbildung 18 Usus Cockpit für ModelOne im dritten Zustand Wie beschrieben, ermöglich Usus für Modelle auch die Bewertung von App-Modellen. Um das zu zeigen, kann man sich beispielhaft folgendes Modell anlegen: ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 13

14 Abbildung 19 App-Model Nachdem man auch in der Covered-Projects-View einen Haken vor das App-Modell gesetzt hat, wird dieses in die Metrikberechnung mit einbezogen. Auf der folgenden Abbildung sieht man das Ergebnis der Berechnung. Dabei erkennt man auch, dass Ecore- und App-Modelle gleichzeitig ausgewertet werden können. Die auf das App-Modell bezogenen Metriken sind wieder mit einem roten Rahmen markiert: ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 14

15 Abbildung 20 Usus Cockpit für das App-Modell 5 Fazit Im Rahmen dieses Arbeitspaketes wurde ein eigenständiges Eclipseplugin entwickelt, das die Funktionalität von USUS auf Modelle überträgt. Es ist dazu in der Lage, Modellmetriken zu berechnen und anzuzeigen. Es war sinnvoll, ein eigenständiges Plugin zu entwickeln. Das liegt vor allem darin begründet, dass statt Quellcode Modelle ausgewertet werden und somit eine komplett andere technische Basis notwendig ist. Der Fokus bei der Entwicklung lag auf der Berechnung und Auswertung von Metriken. Weitere Bestandteile von Usus wie YellowCount und das Histogramm wurden zunächst weggelassen. Bei zukünftigen Weiterentwicklungen ist es denkbar, die Auswertung weiterer Modelltypen möglich zu machen. Weiter könnte eine sinnvolle Ergänzung darin bestehen, einen einfachen Anknüpfpunkt für benutzerdefinierte Metriken anzubieten. 6 Literaturverzeichnis [1] T. Lutz, Qualitätssicherungsmetriken für Modelle, Hochschule Karlsruhe, [2] Beck et al., Manifesto for Agile Software Development, [Online]. Available: ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 15

16 [3] T. Horn, Scrum, [Online]. Available: [4] J. Sutherland und K. Schwaber, The Scrum Guide, July [Online]. Available: [5] J. Sutherland und K. Schwaber, The Scrum Guide, [Online]. Available: ModAgile Mobile L8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene 16