Modellbasierte Laufzeit-Performance-Vorhersage für komponentenbasierte Softwarearchitekturen

Transkript

1 Christian-Albrechts-Universität zu Kiel Institut für Informatik Arbeitsgruppe Software Engineering Diplomarbeit Modellbasierte Laufzeit-Performance-Vorhersage für komponentenbasierte Softwarearchitekturen Nicolas Günther 15. November 2011 Betreut von: Prof. Dr. Wilhelm Hasselbring Dipl.-Inform. André van Hoorn

2 ii

3

4

5 Zusammenfassung Anforderungen an die Qualität von Software werden in Form von Service Level Agreements festgehalten. Zur Einhaltung von SLAs werden oftmals mehr Ressourcen bereitgestellt, als zur Bewältigung der Last notwendig sind. Die Abschätzung benötigter Ressourcen auf Grundlage pessimistischer Lastschätzungen führt zur Verschwendung von Ressourcen in Situation geringer Last. Das SLAstic-Framework soll durch die Rekonfiguration von Softwarearchitekturen zur Laufzeit ressourceneffizient die Einhaltung von SLAs ermöglichen. Durch die Simulation bzw. Analyse von speziellen Performance-Modellen soll die Performance von Softwaresystemen vorhergesagt werden, um über notwendige Rekonfigurationen zu entscheiden. In der vorliegenden Arbeit wird zunächst eine Modelltransformation von im SLAstic-Framework verwendeten Modellen in Modelle, die zur Performance Analyse geeignet sind, entwickelt und implementiert. Für die Extraktion des Kontrollflusses der durch das SLAstic-Framework verwalteten Systeme, wird das SLAstic-Metamodell erweitert und die im ersten Schritt entstandene Transformation um die Überführung entsprechender dynamischer Aspekte ergänzt. Schließlich wird das entstandene Transformationsprogramm auf dessen Eignung für den Einsatz im SLAstic-Framework untersucht. v

6

7 Inhaltsverzeichnis 1. Einleitung Motivation Ziele Struktur der Arbeit Grundlagen Modellgetriebene Softwareentwicklung ATLAS Transformation Language (ATL) Modellbasiertes Software Performance Engineering Palladio Component Model (PCM) SLAstic Modelltransformationen Beispielanwendung: Bookstore Transformation von SLAstic-Modellen in PCM -Modelle TypeRepository (SLAstic) Repository (PCM ) ComponentAssembly (SLAstic) System (PCM ) ExecutionEnvironment (SLAstic) ResourceEnvironment (PCM ) ComponentDeployment (SLAstic) Allocation (PCM ) Implementierung der Transformation in ATL Extraktion von RDSEFFs und UsageModels durch dynamische Analyse Evaluation von Möglichkeiten zur Extraktion von RDSEFFs Erweiterung des SLAstic-Metamodells Extraktion von RDSEFFs durch dynamische Analyse Extraktion von UsageModels (PCM ) vii

8 Inhaltsverzeichnis 5. Evaluation Fragestellung und Ziele Szenarien Ergebnisse Verwandte Arbeiten Fazit Zusammenfassung Diskussion Zukünftige Arbeit A. Anleitung: Ausführung der Transformation von SLAstic-Modellen in PCM- Modelle 77 A.1. Ausführen der Transformation A.2. PCM -Bench B. ATL-Transformation 85 Literaturverzeichnis 101 Danksagung 107 Eigenständigkeitserklärung 109 viii

9 Abbildungsverzeichnis 2.1. ATL-Architektur und ATL Virtual Machine ATL-Perspektive in Eclipse Layered Queueing Networks: Beispielinstanz Palladio-Prozess: Übersicht SLAstic.Control: Überblick SLAstic-Operationen zur Rekonfiguration UML Klassendiagramm der Bookstore-Beispielanwendung UML Sequenzdiagramm der Bookstore-Beispielanwendung TypeRepositoryModel (SLAstic) Metamodell Repository (PCM ) Metamodell PCM -Repository-Diagramm der Bookstore-Anwendung ComponentAssemblyModel (SLAstic) Metamodell System (PCM ) Metamodell PCM -System-Diagramm der Bookstore-Anwendung ExecutionEnvironment (SLAstic) Metamodell ResourceEnvironment (PCM ) Metamodell PCM -ResourceEnvironment der Bookstore-Anwendung in Baumansicht ComponentDeployment (SLAstic) Metamodell Allocation (PCM ) Metamodell PCM -Allocation-Diagramm der Bookstore-Anwendung ATL-Transformation: SLAstic2PCM Eclipse-Launch-Configuration für die Transformation der Bookstore-Beispielanwendung UML Klassendiagramm: SlasticToPcmTransformation ix

10 Abbildungsverzeichnis 4.1. Beispiel: Absolute Häufigkeiten von Operationsaufrufen der Bookstore- Beispielanwendung UsageModel (Metamodell). Elemente, die durch die Erweiterung des Metamodells hinzugekommen sind, sind gelb hervorgehoben ResourceDemandingSEFF (Metamodell) Muster für die Erzeugung der RDSEFFs Muster für die Erzeugung der LoopActions ExternalCallAction (Metamodell) UML Sequenzdiagramm der angepassten Bookstore-Anwendung Operation searchbook: absolute und relative Häufigkeitsfunktion für Folgeaufrufe der Operationen getbook 4.8(a), sowie getoffers 4.8(b) PCM -SEFF-Diagramm der searchbook-operation PCM -SEFF-Diagramm der getbook-operation PCM -SEFF-Diagramm der getoffers-operation UsageModel (PCM ) Metamodell PCM -UsageModel-Diagramm der Bookstore-Anwendung Erzeugung der SLAstic-Modellinstanzen Abhängigkeitsgraph für die Bookstore-Anwendung Abhängigkeitsgraph für die JPetStore-Anwendung Abhängigkeitsgraph für das Kundenportal (Ausschnitt) Zusammenhang zwischen beschreibenden Metriken und Ausführungszeiten 68 A.1. Eclipse Konfiguration A.2. Zusätzliche Einstellungen A.3. Repository Model Editor A.4. Allocation Diagram x

11 Tabellenverzeichnis 3.1. SLAstic-Modell der Boosktore-Anwendung. Verweise zwischen Modellelementen erfolgen über die ID s Grundlegende Abbildung der Submodelle TypeRepository (SLAstic) Repository (PCM ) ComponentAssembly (SLAstic) System (PCM ) ExecutionEnvironment (SLAstic) ResourceEnvironment (PCM ) ComponentDeployment (SLAstic) Allocation (PCM ) SLAstic-UsageModel der Bookstore-Anwendung auf Grundlage der Aufruffolgen T 0, T 1, T 2. Die Verweise beziehen sich auf das SLAstic-SystemModel aus Tabelle Monitoring Logs SLAstic-Modellinstanzen Statistik Messergebnisse der Ausführung der Transformation xi

12

13 Listings 2.1. Syntax von Matched Rules [ATL Group 2011] Beispiel einer Lazy Rule Beispiel für den Aufruf einer Lazy Rule Syntax von Called Rules [ATL Group 2011] ATL-Regel: TypeRepositoryModel (SLAstic) Repository (PCM ) ATL-Regel: Execution Container (SLAstic) ResourceContainer (PCM ) ATL-Regel: ComponentType (SLAstic) BasicComponent (PCM ) ATL-Called Rule zur Erzeugung einer ProvidedRole (PCM ) ATL-Regel: NewExternalCallAction (PCM ) A.1. Verwendungshinweise des Skripts slastic2pcm.sh A.2. Kommando zum Starten der Transformation B.1. ATL-Transformation xiii

14

15 1. Einleitung 1.1. Motivation Smith und Williams [2002] definieren Performance als den Grad, zu dem ein Softwaresystem oder eine Softwarekomponente Zielvorgaben bezüglich der Rechtzeitigkeit einhält. Bei der Entwicklung von komplexen, verteilten Systemen werden Anforderungen an die Qualität der Software in Form von Service Level Agreements (SLAs) vertraglich festgehalten. Zur Einhaltung vereinbarter SLAs werden oftmals mehr Ressourcen bereitgestellt, als zur Bewältigung der zu einem Zeitpunkt gegebenen Last notwendig sind. Die Abschätzung benötigter Ressourcen auf Grundlage pessimistischer Lastschätzungen führt zu der Verschwendung von Ressourcen in Situationen geringerer Last. Wünschenswert wäre eine effiziente Verwendung von Ressourcen, die sich an der aktuellen Arbeitslast orientiert,und eine frühzeitige Anpassung an zu erwartende Änderungen der Auslastung. Das SLAstic-Framework [van Hoorn et al. 2009a] soll mittels der Rekonfiguration von Softwarearchitekturen zur Laufzeit ressourceneffizient die Einhaltung von SLAs ermöglichen. Der PerformancePredictor ist eine Komponente des SLAstic-Frameworks zur Performance Vorhersage (siehe Abschnitt 2.5). Bisher existiert diese Komponente nur als Platzhalter, d.h. es geschieht keine Vorhersage von Performance-Eigenschaften. Stattdessen reagiert das Framework rein reaktiv auf aktuelle Workload- und Performance- Erhebungen, wobei erst dann rekonfiguriert wird, wenn bereits SLAs verletzt sind. Ziel der vorliegenden Arbeit ist es, diese Komponente zur Performance-Vorhersage zu entwerfen, zu implementieren, sowie anhand beispielhafter Szenarien die Qualität der Vorhersagen zu evaluieren. 1

16 1. Einleitung 1.2. Ziele Aus den in Abschnitt 1.1 beschriebenen Inhalten der vorliegenden Arbeit lassen sich folgende Teilziele formulieren: Z1 Erstellung benötigter Modelltransformationen Das SLAstic-Framework arbeitet mit spezifischen Modellrepräsentationen (SLAstic- Metamodell). Für die modellbasierte Vorhersage von Performance-Eigenschaften sind spezialisierte Metamodelle besser geeignet [Balsamo et al. 2004], d.h. zur Integration in SLAstic sind Modelltransformationen nötig. Passende Metamodelle sollen im Rahmen der Diplomarbeit untersucht und entsprechende Transformationen entwickelt und implementiert werden. Z2 Implementierung der Komponente Performance Predictor Um den PerformancePredictor in das SLAstic-Framework zu integrieren, ist zum einen das Implementieren entsprechender Schnittstellen nötig. Zum anderen müssen die Transformationen aus Z1, sowie zugehörige Algorithmen bzw. Tools zur Lösung der Modelle, mit eben dieser Komponente integriert werden. Z3 Evaluation der Performance-Vorhersagen mittels Testszenarien Zur Evaluation der Performance-Vorhersagen werden Testszenarien konstruiert. Beispielsweise können Architekturmodelle vorhandener Software, sowie simulierter Workload verwendet werden. Ziel der Evaluation ist die Bewertung der Vorhersagen unter Berücksichtigung folgender Fragen: Wie genau sind die Vorhersagen, d.h. wie groß ist der Fehler gegenüber den tatsächlich gemessenen Daten? Wieviel Zeit braucht das Lösen bzw. Simulieren der Modelle und gibt es Situationen, in denen die benötigte Zeit die Erfüllung der SLAs gefährdet? Inwiefern ist die Qualität der Vorhersage abhängig von Attributen der Softwarearchitektur, wie der Größe des Modells (z.b. Anzahl der Komponenten)? Z4 Evaluation der Performance-Vorhersagen unter Berücksichtigung unterschiedlicher Anwendungsfälle Die Ergebnisse aus der Evaluation aus Z3 müssen zusätzlich im Kontext unter- 2

17 1.3. Struktur der Arbeit schiedlicher Anwendungsfälle für den PerformancePredictor bewertet werden, wie z.b.: Die Vorhersage von Performance-Eigenschaften aufgrund von Workload-Vorhersagen des WorkloadForecaster, zur Weiterverarbeitung im AdaptationPlanner. Die Evaluation unterschiedlicher vorgeschlagener Konfigurationen durch den AdaptionPlanner. Es soll untersucht werden, inwieweit verschiedene Anwendungsfälle hier zu unterschiedlichen Anforderungen an die Geschwindigkeit und die Qualität der Vorhersage führen, bzw. ob sich verschiedene Metamodelle in unterschiedlicher Weise für verschiedene Anwendungsfälle eignen. Während der Bearbeitung der vorliegenden Arbeit hat sich der Schwerpunkt von den ursprünglich definierten Zielen Z1-Z4, hin zu einer intensiveren Bearbeitung des Zieles Z1 verschoben. Es stellte sich heraus, dass für die Erstellung der Modelltransformationen eine umfangreiche Betrachtung der Extraktion von Performance-Eigenschaften durch dynamische Analyse vonnöten ist. Die beschriebenen Ziele werden jedoch im Fazit in Kapitel 6 wieder aufgegriffen und gehen in den Ausblick auf zukünftige Arbeiten in Abschnitt 6.3 ein Struktur der Arbeit Das Kapitel 2 enthält einen Überblick über die für die vorliegende Arbeit notwendigen Grundlagen. Einer einleitenden Betrachtung der modellgetriebenen Softwareentwicklung folgt eine Übersicht der wichtigsten Konzepte der Transformationssprache ATL. Im Anschluss daran werden Konzepte des modellbasierten Software Performance Engineering eingeführt und das Palladio Component Model (PCM) vorgestellt. Schließlich folgt ein Überblick über das SLAstic-Framework. Das Kapitel 3 beschreibt den Entwurf der im Rahmen der vorliegenden Arbeit entstandenen Modelltransformationen. Einleitend wird die Bookstore-Beispielanwendung vorgestellt, anhand derer in den darauf folgenden Abschnitten der Entwurf der einzelnen Transformationsschritte erläutert wird. Das Kapitel schließt mit einer Betrachtung der Implementierung der Transformationen mit der Transformationssprache ATL. 3

18 1. Einleitung In Kapitel 4 werden die dynamischen Aspekte der Transformation gesondert betrachtet. Zunächst werden verschiedene Ansätze zur Rekonstruktion sogenannter RDSEFFs (siehe Abschnitt 2.4) diskutiert. Anschließend werden die zur Umsetzung des gewählten Ansatzes nötigen Erweiterungen des SLAstic-Metamodells (siehe Abschnitt 2.5) beschrieben und die Extraktion von RDSEFFs und UsageModels erläutert. In Kapitel 5 folgt eine Evaluation des entstandenen Transformationsprogrammes. Nach einer einleitenden Darstellung der Fragestellung und der Ziele der Evaluation werden die für die Evaluation verwendeten Szenarien eingeführt. Danach werden die Ergebnisse der Evaluation präsentiert. Das Kapitel schließt mit einer Betrachtung verwandter Arbeiten. Das Fazit bildet in Kapitel 6 den Abschluss der Arbeit, in welchem die Zusammenfassung und eine anschließende Diskussion der Ergebnisse dargestellt werden. Schließlich folgt ein Ausblick auf zukünftige Arbeiten im Kontext der vorliegenden Arbeit. 4

19 2. Grundlagen In diesem Kapitel wird ein Überblick über die wesentlich in der vorliegenden Arbeit verwendeten Methoden und Technologien gegeben. Nach einer Einführung in die modellgetriebene Softwareentwicklung in Abschnitt 2.1, wird in Abschnitt 2.2 die Transformationssprache ATL dargestellt. Die Verwendung von Modellen im Software Performance Engineering wird in Abschnitt 2.3 beschrieben. In Abschnitt 2.4 wird das Palladio Component Model (PCM) vorgestellt und schließlich befindet sich in Abschnitt 2.5 eine Beschreibung des SLAstic-Frameworks Modellgetriebene Softwareentwicklung Das Ziel der Modellgetriebenen Software-Entwicklung (Model-Driven Software Development, MDSD) ist die Anhebung des Abstraktionsgrads bei der Erstellung von Software- Systemen durch die Einführung von Modellen [Reussner und Hasselbring 2006]. Ein Modell ist dabei eine vereinfachte Beschreibung eines Systems. Häufig werden mehrere Modelle verwendet um verschiedene Aspekte des modellierten Systems zu verdeutlichen (sogenannte Sichten). Ein Metamodell ist ein Modell, welches Regeln zur Erstellung von bestimmten Modellen definiert. Von einer Modellinstanz eines Metamodells spricht man bei einem Modell, das nach den Regeln des Metamodells erzeugt wurde. Beispielsweise ist ein UML-Modell eine Instanz des UML-Metamodells. Um die Konformität unterschiedlicher Metamodelle zu gewährleisten, wird ein zusätzliches Modell verwendet, nach dessen Regeln die Metamodelle erzeugt werden. Man spricht dabei von einem Meta-Metamodell. Meta Object Facility (MOF) Ein Beispiel für ein selbstbeschreibendes Meta-Metamodell ist die Meta Object Facility (MOF) [OMG 2011], eine Spezifikation der Object Management Group (OMG). Ziel 5

20 2. Grundlagen der Spezifikation ist die Standardisierung der Beschreibung von Modellen und Metamodellen. Eine Reihe anderer, von der OMG standardisierte Technologien verwenden MOF. Prominente Beispiele sind die Unified Modelling Language (UML) oder XMI, der OMG-Standard für die Serialisierung von Modellen. Die MOF-Spezifikation unterscheidet zwischen der Teilspezifikation Essential MOF (EMOF), welche grundlegende Konzepte enthält und Complete MOF (CMOF), welche basierend auf EMOF weitere Konzepte beinhaltet. Eclipse Modeling Framework (EMF) Das Eclipse Modeling Framework (EMF) [Steinberg et al. 2009] ist eine Implementierung des MOF-Standards. Das innerhalb von EMF genutzte Meta-Metamodell Ecore ist isomorph zu dem durch die EMOF-Spezifikation definierten Meta-Metamodell. EMF stellt, basierend auf der Eclipse Entwicklungsumgebung eine Reihe von Werkzeugen zur modellgetriebenen Softwareentwicklung bereit. Dazu gehören beispielsweise Werkzeuge zur Generierung von Java-Code aus Modellen und zur Betrachtung und zum Editieren von Modellen. Transformation von Modellen Wichtiger Bestandteil der modellgetriebenen Softwareentwicklung ist die Transformation von Modellen. Durch die Verwendung von spezialisierten Metamodellen, die jeweils unterschiedliche Aspekte eines Softwaresystems modellieren, ergibt sich die Notwendigkeit Modelle in Instanzen eines anderen Metamodells zu transformieren. Eine Modelltransformation ist eine Abbildung, die Modellinstanzen einer Menge von Quellmodellen in Modellinstanzen einer Menge von Zielmodellen überführt [Reussner und Hasselbring 2006]. Bei der Transformation von Modellen unterscheidet man zwischen der Verfeinerung, d.h. einer Transformation, die das Quellmodell bei sinkendem Abstraktionsgrad um Details anreichert, sowie der Abstraktion, einer Transformation, bei der von Details zugunsten abstrakter Aspekte abstrahiert wird. Eine weitere Unterscheidung bei der Transformation von Modellen besteht zwischen der Modell-zu-Text-Transformation (M2T), welche aus Modellen Text erzeugt (z.b. Quellcode oder XML) und der Modell-zu-Modell- Transformation (M2M ), welche Modelle ineinander überführt. 6

21 2.2. ATLAS Transformation Language ( ATL) Technologien zur Transformation von Modellen Zur Transformation von Modellen existieren eine Reihe von Transformationssprachen. Diese sind unter anderem, die auf dem EMF basierenden Sprachen Operational QVT 1 und ATL [Jouault et al. 2008] für M2M -Transformationen sowie JET 2, Acceleo 3 und Xpand 4 für T2T-Transformationen, inklusive entsprechender Werkzeugunterstützung auf Basis der Eclipse Entwicklungsumgebung. Operational QVT ist eine Implementierung des imperativen Teils des OMG-Standards Query/Viev/Transformation für eine M2M -Transformationssprache durch das Eclipse Projekt. ATL ist eine QVT-ähnliche Sprache, mit deklarativen und imperativen Anteilen. ATL wurde im Rahmen der vorliegenden Arbeit verwendet, eine detaillierte Beschreibung von ATL findet sich in Abschnitt 2.2. JET ist ein Framework zur M2T-Transformation, mit dem Fokus der Erzeugung von Quelltext. Mithilfe von Templates können Modelle in verschiedene Arten von Quelltext transformiert werden (z.b. Java, HTML). Acceleo ist eine einfache Implementierung des OMG-Standards MOF Model To Text Language (MTL) für eine M2T-Transformationssprache. Xpand transformiert ebenso Modelle auf Basis von Templates in Text, bietet aber eine Reihe fortgeschrittener Programmiertechniken, wie z.b. aspektorientierte Programmierung und funktionale Erweiterungen ATLAS Transformation Language (ATL) Die ATLAS Transformation Language (ATL) [Jouault und Kurtev 2006b,a; Jouault et al. 2008] ist eine Sprache und eine Sammlung von Werkzeugen zur Transformation (M2M) von Modellen. Entwickelt wurde ATL von der ATLAS Group am französischen National Institute for Research in Computer Science and Control (INRIA), als Antwort auf eine Ausschreibung der Object Management Group (OMG) für eine mit den OMG- Standards kompatible Transformationstechnologie. 1 siehe 2 siehe 3 siehe 4 siehe 7

22 2. Grundlagen (a) (b) Abbildung 2.1.: ATL-Architektur (2.1(a)) und ATL Virtual Machine (2.1(b)) [Jouault und Kurtev 2006a] Architektur Die ATL-Architektur besteht aus drei Schichten (siehe Abbildung 2.1(a)): ATLAS Model Weaving (AMW), ATL und ATL Virtual Machine (ATL VM) [Jouault und Kurtev 2006a]. AMW erlaubt die Definition und die Ausführung eigener Sprachen auf der ATL VM. Da sowohl ATL als auch AMW selbst als Metamodelle definiert sind, werden entsprechende eigene Sprachen oder Erweiterungen mittels einer Modelltransformation (M2M) in ATL übersetzt. Die Anwendung von AMW ist nicht auf Modelltransformationen beschränkt. Die Transformationssprache ATL setzt sich aus deklarativen und imperativen Konstrukten zusammen. Durch Transformation in ATL-Bytecode wird eine ATL-Modelltransformation auf der ATL VM lauffähig. Die ATL VM ist auf Basis verschiedener Modellierungstechnologien implementiert (siehe Abbildung 2.1(b)), beispielsweise dem Eclipse Modeling Framework (EMF) und dem Netbeans MetaData Repository (MDR). Der ATL-Compiler läuft selbst auf der ATL VM und erzeugt ATL-Programme, die auf eben dieser lauffähig sind Konzepte ATL ist eine Hybridsprache, bestehend aus deklarativen und imperativen Konzepten. Empfohlen wird ein deklarativer Programmierstil, es existieren jedoch imperative Konzepte, um komplexe Transformationsschritte zu vereinfachen. Die wichtigsten deklarativen Konzepte sind die sogenannten Matched Rules und Lazy Rules. Die wesentlichen im- 8

23 2.2. ATLAS Transformation Language ( ATL) perativen Konzepte sind die Called Rules und imperative Codeblöcke, sogenannte Action Blocks. Diese vier Konzepte werden in den nachfolgenden Abschnitten kurz beschrieben. Matched Rules Eine Matched Rule beschreibt, wie Zielmodell-Elemente aus Quellmodell-Elementen generiert werden. Dazu enthält eine solche Regel den Typ der zu transformierenden Quellmodell- Elemente, den Typ und Multiplizität der zu generierenden Zielmodell-Elemente, sowie die Logik die den Transformationschritt beschreibt. Eine Matched Rule hat der in Listing 2.1 gezeigten Syntax zu entsprechen. Listing 2.1: Syntax von Matched Rules [ATL Group 2011] 1 rule rule_name { 2 from 3 in_var : in_type [ i n model_name ]? [ ( 4 c o n d i t i o n 5 ) ]? 6 to 7 out_var1 : out_type1 [ i n model_name ]? ( 8 b i n d i n g s 1 9 ), 10 out_var2 : d i s t i n c t out_type2 f o r e a c h ( e i n c o l l e c t i o n ) ( 11 b i n d i n g s 2 12 ), out_varn : out_typen [ i n model_name ]? ( 15 bindingsn 16 ) 17 [ do { 18 statements 19 } ]? 20 } Jede Regel wird über einen Namen identifiziert (rule_name). Der Rumpf einer Regel beginnt mit dem Source Pattern, eingeleitet mit dem Schlüsselwort from. Das Source Pattern spezifiziert den Typ der Quellmodellelemente, die mit dieser Regel transformiert werden. Das Schlüsselwort to leitet danach das Target Pattern ein, welches die im 9

24 2. Grundlagen Zielmodell zu erzeugenden Elemente beschreibt. Die Matched Rules werden bei der Ausführung der Transformation automatisch auf passenden Quellmodellelementen angewendet. Lazy Rules Im Unterschied zu einer Matched Rule wird eine Lazy Rule nicht automatisch auf passende Quellmodellelemente angewendet, sondern muss (z.b. aus einer Matched Rule heraus) explizit aufgerufen werden. Syntaktisch entsprechen Lazy Rules der Definition von Matched Rules in Listing 2.1, mit dem Unterschied, dass der Regel das Schlüsselwort lazy vorangestellt werden muss. Listing 2.2 zeigt ein Beispiel für eine solche Regel. In Listing 2.3 ist der Aufruf der Lazy Rule aus Listing 2.2 aus einer MatchedRule heraus zu sehen. Listing 2.2: Beispiel einer Lazy Rule 1 l a z y rule getcross { 2 from 3 i : e c o r e! EObject 4 to 5 r e l : metamodel! R e l a t i o n s h i p ( 6 ) 7 } Listing 2.3: Beispiel für den Aufruf einer Lazy Rule 1 rule Example { 2 from 3 s : e c o r e! EObject 4 to 5 t : metamodel! Node ( 6 name < s. t o S t r i n g ( ), 7 edges < thismodule. getcross ( s ) 8 ) 9 } 10

25 2.2. ATLAS Transformation Language ( ATL) Called Rules Ähnlich wie die Lazy Rules müssen Called Rules explizit aufgerufen werden. Called Rules erlauben jedoch die Definition und die Übergabe von benannten Parametern. Eine Called Rule muss der in Listing 2.4 angegebenen Syntax entsprechen. Listing 2.4: Syntax von Called Rules [ATL Group 2011] 1 [ e n t r y p o i n t ]? rule rule_name ( parameters ) { 2 [ using { 3 var1 : var_type1 = init_exp1 ; varn : var_typen = init_ expn ; 6 } ]? 7 [ to 8 out_var1 : out_type1 ( 9 b i n d i n g s 1 10 ), 11 out_var2 : d i s t i n c t out_type2 f o r e a c h ( e i n c o l l e c t i o n ) ( 12 b i n d i n g s 2 13 ), out_varn : out_typen ( 16 bindingsn 17 ) ]? 18 [ do { 19 statements 20 } ]? 21 } Action Blocks Die in den Definitionen der Syntax von Matched Rules (siehe Listing 2.1) bzw. Called Rules (siehe Listing 2.4) angegebenen optionalen Blöcke, die durch das Schlüsselwort do eingeleitet werden, sind sogenannte Action Blocks. Ein Action Block erlaubt die Ausführung von imperativem Code nach der Ausführung des Target Pattern der Regel. Dies ist nützlich, um beispielsweise Eigenschaften von Elementen im Zielmodell auf eine Art 11

26 2. Grundlagen und Weise zu initialisieren oder zu ändern, die sich deklarativ nur kompliziert ausdrücken lässt. Weitere Konzepte und Beispiele Neben den vorgestellten, wichtigsten Konzepten existieren in ATL viele weitere Konzepte, wie z.b. die Vererbung von Regeln, Helpers oder Unique Lazy Rules. Für eine vollständige Spezifikation der Sprache siehe ATL Group [2011]. In den Kapiteln 3 und 4, sowie in Anhang B der vorliegenden Arbeit befinden sich Beispiele für die Transformation von Modellen mit ATL Werkzeuge Mit dem ATL-Plugin für Eclipse gibt es eine umfangreiche Werkzeugunterstützung für die Entwicklung mit ATL. Neben dem Syntax Highlighting und der automatischen Vervollständigung im ATL-Editor gibt es beispielsweise einen integrierten Debugger und Unterstützung bei der Erzeugung von Ant Tasks für ATL. Abbildung 2.2 zeigt einen Screenshot der ATL-Perspektive in Eclipse. 12

27 2.2. ATLAS Transformation Language ( ATL) Abbildung 2.2.: ATL-Perspektive in Eclipse 13

28 2. Grundlagen 2.3. Modellbasiertes Software Performance Engineering Software Performance Engineering (SPE) bezeichnet die Gesamtheit von Aktivitäten im Bereich Software Engineering und damit zusammenhängende Analyse im Softwareentwicklungszyklus, die darauf abzielen Performance-Anforderungen zu erfüllen [Woodside et al. 2007]. Das modellbasierte Software Performance Engineering versucht dies durch die Einführung und Analyse von Performance-Modellen zu erreichen. Üblicherweise werden Performance-Eigenschaften von Softwaresystemen durch Messungen untersucht. Die manuelle oder automatische Instrumentierung der Software erlaubt die Überprüfung von Anforderungen bezüglich der Performance. Ein Problem bei der Untersuchung der Performance durch Messungen ist, dass die untersuchte Software für das Messen bereits vorliegen muss, wobei eine Analyse in frühen Phasen des Softwareentwicklungszyklus nicht möglich ist. Ein weiteres Problem besteht darin, dass Messergebnisse interpretiert werden müssen, da die Ergebnisse keine Möglichkeiten zur Verbesserung der Performance darstellen. Die Untersuchung von Performance-Eigenschaften eines Softwaresystems mit Hilfe von Performance-Modellen verspricht diese Probleme zu lösen. Performance-Modelle beschreiben, wie ein System Ressourcen verwendet und wie die Auslastung von Ressourcen das Verhalten des Systems beeinflusst [Woodside et al. 2007]. Durch Simulation oder analytische Methoden ist es mittels Performance-Modellen und entsprechenden Werkzeugen möglich, die Performance vor der Implementierung eines Systems vorherzusagen. Ein weiterer Anwendungsfall für Performance-Modelle ist dennoch die Untersuchung von bestehenden Softwaresystemen. Durch manuelle oder automatische Verfahren können aus bestehenden Softwaresystemen Performance-Modelle extrahiert werden. So entstandene Modelle sind ideal um den Einfluss von Änderungen am System auf dessen Performance zu analysieren, ohne diese Änderungen direkt implementieren zu müssen, um erst dann den Einfluss dieser Modifikationen messen zu können. Beispiele von Performance-Modellen sind Queueing Networks und stochastische Petri- Netze (für einen Überblick siehe Balsamo et al. [2004]). Eine erweiterte Form der Queueing Networks sind die Layered Queueing Networks [Omari et al. 2005; Franks et al. 2011]. Im Gegensatz zu gewöhnlichen Queueing Networks [Baskett et al. 1975] werden bei LQNs Entitäten und deren Kommunikation in einer hierarchischen Struktur modelliert. In der Beispielinstanz in Abbildung 2.3 sind wesentliche Elemente von LQN-Modellen zu erkennen. Die Parallelogramme identifizieren sogennante Tasks. Dies können sowohl 14

29 2.3. Modellbasiertes Software Performance Engineering Abbildung 2.3.: Layered Queueing Networks: Beispielinstanz [Koziolek und Reussner 2008] 15

30 2. Grundlagen logische als auch physische Entitäten sein. Die kleineren Parallelogramme innerhalb der größeren identifizieren sogenannte Entries, dies sind im wesentlichen Dienste, die der jeweilige Task anbietet. Tasks ohne Entries können auch als Kreis dargestellt werden. In dem Task Application Server ist zu erkennen, wie die Abarbeitung von Aufrufen eines Entry durch einen Aktivitätsgraphen in verfeinerter Form dargestellt werden kann. Wichtig sind darüber hinaus verschiedene Performance-Annotationen, wie die durchschnittliche Anzahl von Aufrufen an den Kanten, sowie der Zeitbedarf, der innerhalb der Entries abgetragen ist. Es existieren leistungsfähige Werkzeuge zur analytischen Lösung und Simulation von LQNs (siehe Franks et al. [2011]). Während die bisher diskutierten Performance-Modelle vor allem im Hinblick auf die Performance-Analyse entworfen wurden, steht beim Palladio Component Model (PCM) die Beschreibung von Performance-Eigenschaften auf Ebene der Softwarearchitektur komponentenbasierter Softwaresysteme im Fokus. Eine detallierte Beschreibung von PCM befindet sich in Abschnitt 2.4. Weitere Beispiele für solche Architekturmodelle sind die UML-Profile UML Profile for Schedulability, Performance and Time (SPT) [Smith und Williams 2002] und UML Profile for MARTE: Modeling and Analysis of Real-Time and Embedded Systems (MARTE) [Gérard und Selic 2008] Palladio Component Model (PCM) Das Palladio Component Model (PCM) ist ein Meta-Modell für die Beschreibung von komponentenbasierten Software-Architekturen [Reussner et al. 2007]. Schwerpunkt von PCM ist die Modellierung von Aspekten, die bezüglich der Performance relevant sind. Es existieren eine Reihe von Werkzeugen zur Erstellung und Analyse von PCM -Modellen. PCM besteht aus verschiedenen domänenspezifischen Sprachen, eine für jede Entwicklerrolle in dem zugrunde liegenden Software-Entwicklungsprozess für komponentenbasierte Softwaresysteme [Becker et al. 2009]: Komponentenentwickler spezifizieren eine abstrakte und parametrische Beschreibung der Komponenten und ihres Verhaltens. Softwarearchitekten fügen von Komponentenentwicklern entworfene Komponenten zu einer Applikation zusammen. 16

31 2.4. Palladio Component Model (PCM) Abbildung 2.4.: Palladio-Prozess: Übersicht [Becker et al. 2009] System deployers modellieren die Ressourcen der Umgebung und die Zuweisung von Komponenten zu den verschiedenen Resourcen. Domänenexperten erstellen Modelle der Nutzung des Systems, z.b. kritische Nutzungsszenarien und typische Parameter. Abbildung 2.4 zeigt eine Übersicht über die verschiedenen Rollen und deren Modellierungssprachen sowie Transformationen in Performance-Modelle und Implementierungsartefakte. Für die Vorhersage von Eigenschaften bezüglich der Performance eines Softwaresystems, wie beispielsweise den Durchsatz oder Antwortzeiten, ist die Modellierung bestimmter Aspekte nötig. Dazu gehören die Implementierung von Komponenten inklusive eventueller externer Dienste, von denen eine Komponente abhängt. Darüberhinaus müssen die Art und Weise in der Komponenten verwendet werden (z.b. durch Benutzerinteraktion), sowie Eigenschaften der ausführenden Umgebung modelliert werden (z.b. durch Spezifikation von Eigenschaften der Hardware). PCM erlaubt die Modellierung aller dieser Aspekte und ermöglicht so die Vorhersage von Auswirkungen von deren Änderungen. Zu jeder der oben beschriebenen Entwicklerrolle gibt es ein zugehöriges Submodell. 17

32 2. Grundlagen Das RepositoryModel (Komponentenentwickler) enthält die Spezifikation von Komponenten, Interfaces und Datentypen. Interfaces bestehen aus einer Liste von Signaturen. Komponenten können Interfaces bereitstellen oder von ihnen abhängig sein. Darüberhinaus kann ein Repository für jede von einer Komponente über ein Interface bereitgestellte Operation, eine Spezifikation dessen Implementierung in Form einer ResourceDemandingServiceEffectSpecification (RDSEFF) enthalten. Ein RDSEFF modelliert die Reihenfolge in der verwendete Dienste aufgerufen werden, inklusive des für die Performance- Vorhersage nötigen Ressourcenbedarfs. Das SystemModel (Softwarearchitekten) beschreibt die Architektur des Systems, bestehend aus Instanzen der im Repository definierten Komponenten (AssemblyContext). Eine Komponente, die ein bestimmtes Interface bereitstellt, kann mit einer Komponente, die von diesem Interface abhängig ist durch einen AssemblyConnector verbunden werden. Das System kann seinerseits wiederum Interfaces bereitstellen oder von ihnen abhängen. Dies wird durch SystemProvidedRoles bzw. SystemRequiredRoles modelliert. Eine solche Rolle kann mit einem SystemDelegationConnector mit Komponenten verbunden werden, die das passende Interface bereitstellen bzw. von ihm abhängen. Das ResourceEnvironmentModel (System Deployer) spezifiziert die ResourceContainer und eventuelle Verbindungen zwischen ihnen. Ein ResourceContainer repräsentiert eine physische Entität, wie z.b. einen Server oder Desktop-Rechner, oder aber Entitäten wie z.b. einen Application Server oder einen Webbrowser. Eine Verbindung zwischen solchen Containern ist beispielsweise eine Netzwerkverbindung. Das AllocationModel (System Deployer) beschreibt die Zuweisung von AssemblyContexts zu den ausführenden Containern. Dazu wird ein AssemblyContext erneut als ein AllocationContext instanziiert. Dies geschieht um Szenarien modellieren zu können, in denen beispielsweise eine Komponente von mehreren ResourceContainers bereitgestellt wird. Das UsageModel (Domänenexperte) spezifiziert die Interaktion von Benutzern mit dem Softwaresystem. Das UsageModel besteht aus mehreren UsageScenarios. Ein UsageScenario besteht aus einem Workload und einer Spezifikation des Verhaltens des Benutzers. Der Workload definiert die Anzahl der Benutzer und die Häufigkeit derer Benutzung des Systems. Das Verhalten der Benutzer wird durch Kontrollflusskonstrukte beschrieben (Fallunterscheidungen, Schleifen, Operationsaufrufe). Detaillierte schematische Darstellungen der einzelnen Submodelle, Beispiele von PCM - Instanzen und weitere Details sind in den Kapiteln 3 und 4 zu finden. 18

33 2.5. SLAstic 2.5. SLAstic Bei der Planung benötigter Ressourcen für ein Software-System wird oft eine statisch hohe Auslastung des Systems angenommen. Dies führt zu schlechter Ressourceneffizienz in Phasen geringer Nutzung, d.h. zu unnötig hohen Kosten bezüglich des Energieverbrauchs und laufender Kosten für die Infrastruktur. Abbildung 2.5.: SLAstic.Control: Überblick [van Hoorn 2011] SLAstic ist ein Framework für die effiziente Laufzeit-Verwaltung von Ressourcen in verteilten komponentenbasierten Software-Systemen [van Hoorn et al. 2009a]. Die Architektur des Systems wird basierend auf Messungen der aktuellen Auslastung, sowie Lastvorhersagen, unter laufender Berücksichtigung geltender Service Level Agreements (SLAs), angepasst. Abbildung 2.5 zeigt einen Überblick über das SLAstic-Framework. Im Rahmen der Diplomarbeit von Stöver [2009] wurde eine Java-Implementierung des SLAstic-Frameworks erstellt. Für einige Komponenten des Frameworks sind bisher lediglich Platzhalter vorhanden. So gibt es für die Komponente PerformancePredic- 19

34 2. Grundlagen (a) Replikation und Dereplikation von Software-Komponenten. (b) Migration von Software-Komponenten. (c) Deallokation und Allokation von Execution Containern. Abbildung 2.6.: SLAstic-Operationen zur Rekonfiguration [von Massow et al. 2010] tor, die der Vorhersage der Performance des beobachteten Systems dient, bisher nur eine leere Implementierung des zugehörigen Interfaces IPerformancePredictor. An dieser Stelle knüpft die vorliegende Arbeit an, in deren Rahmen eine neue Implementierung des Interfaces IPerformancePredictor entstanden ist. Die Komponente WorkloadForecaster liefert dem PerformancePredictor eine Workload- Vorhersage für einen geeigneten Vorhersagezeitraum. Durch analytisches Lösen bzw. durch Simulation eines Modells der betrachteten Software-Architektur, unter Berücksichtigung der Workload-Vorhersage, sollen Vorhersagen über Performance-Attribute des Systems innerhalb des Vorhersagezeitraums erzeugt werden. Zentraler Bestandteil von SLAstic sind verschiedene, in Abbildung 2.6 dargestellte, Operationen zum Rekonfigurieren der Architektur, welche die Anpassung von Performance- und Effizienzeigenschaften eines Software-Systems zur Laufzeit ermöglichen [von Massow et al. 2010]: Replikation und Dereplikation von Software-Komponenten. Die Replikationsoperation erzeugt eine neue Instanz einer Komponente in einem anderen Execution 20

35 2.5. SLAstic Container. Anfragen werden dann auf die verfügbaren Instanzen verteilt. Analog dazu entfernt die Dereplikationsoperation eine Instanz einer Komponente. Migration von Software-Komponenten. Die Migrationsoperation entfernt die Instanz einer Komponente aus einem Execution Container, um in einem anderen Container eine neue Instanz der Komponente zu erzeugen. Allokation und Deallokation von Execution Containern. Die Allokationsoperation stellt einen zusätzlichen Execution Container bereit, wohingegen die Deallokationsoperation einen vorhandenen Container entfernt. Das SLAstic-Framework entscheidet anhand der analytischen Lösung bzw. Simulation eines Modells des verwalteten Softwaresystems zur Laufzeit über nötige Operationen zur Rekonfiguration des Systems. Dieses Modell wird zur Laufzeit verfeinert und mit der Laufzeit-Architektur synchronisiert. Details zum SLAstic-Metamodell und Beispiele von SLAstic-Modellinstanzen befinden sich in den Kapiteln 3 und 4. Für die Performance-Vorhersage wurde der Simulator SLAstic.SIM entwickelt und in das SLAstic-Framework integriert [von Massow et al. 2010]. SLAstic.SIM simuliert Instanzen des PCM -Metamodells unter Verwendung von generiertem oder aufgezeichnetem Workload. Für die Performance-Vorhersage zur Laufzeit müssen die SLAstic-Modelle entsprechend in PCM -Instanzen überführt werden. Die im Rahmen dieser Arbeit, zu diesem Zweck, entstandene Transformation ist in den Kapiteln 3 und 4 beschrieben. 21

36

37 3. Modelltransformationen Das SLAstic-Framework arbeitet mit spezifischen Modellrepräsentationen (SLAstic-Metamodell). Für die modellbasierte Vorhersage von Performance-Eigenschaften sind spezialisierte Metamodelle besser geeignet [Balsamo et al. 2004]. Mit SLAstic.SIM [von Massow et al. 2010] existiert bereits ein in das SLAstic-Framework integrierter Simulator für PCM -Instanzen. Um das Modell des untersuchten Softwaresystems zur Laufzeit mit SLAstic.SIM zu simulieren, wird es in eine PCM -Instanz transformiert. Neben der Simulation des entstandenen Modells mit SLAstic.SIM ist dann die Verwendung der PCM -Bench und die Simulation mit SimuCom möglich. Im Abschnitt 3.1 wird die Bookstore-Anwendung vorgestellt, anhand derer die Transformation verdeutlicht werden soll. Abschnitt 3.2 beschreibt die grundlegenden Aspekte der Transformation von SLAstic-Modellen in PCM -Modelle. Die Abschnitte beschreiben die Transformation der verschiedenen Submodelle und in Abschnitt 3.7 wird die Implementierung der Transformation als ein ATL-Programm erläutert Beispielanwendung: Bookstore Bei der Bookstore-Beispielanwendung handelt es sich um ein Online-Bestellsystem für Bücher, in dem Benutzer in einem Katalog nach Büchern suchen und entsprechende Angebote unterschiedlicher Händler erhalten. Die Anwendung besteht aus den drei fachlichen Klassen Bookstore, CRM und Catalog, die jeweils eine Operation bereitstellen (siehe Klassendiagramm in Abbildung 3.1). Die Operation searchbook der Klasse Bookstore wird für die Simulation von Benutzerinteraktion mit dem System durch den WorkloadGenerator BookstoreStarter aufgerufen. Der Aufruf der searchbook-operation resultiert in Aufrufen der Operationen getbook und getoffers der Klassen Catalog bzw. CRM. Der Aufruf der Operation getoffers resultiert wiederum in einem Aufruf der get- Book-Operation der Klasse Catalog (vlg. Sequenzdiagramm in Abbildung 3.2). 23

38 3. Modelltransformationen Abbildung 3.1.: UML Klassendiagramm der Bookstore-Beispielanwendung [Ehmke et al. 2011] Anhand der Bookstore-Anwendung werden in den folgenden Abschnitten einzelne Transformationsschritte verdeutlicht. Quellmodell der Transformation ist eine durch dynamische Analyse gewonnene SLAstic-Modellinstanz der Bookstore-Anwendung. In Tabelle 3.1 sind die Bestandteile einer zugehörigen SLAstic-Modellinstanz dargestellt. 24

39 3.1. Beispielanwendung: Bookstore BookstoreStarter bookstore:bookstore catalog:catalog crm:crm main searchbook getbook getoffers getbook Abbildung 3.2.: UML Sequenzdiagramm der Bookstore-Beispielanwendung [Ehmke et al. 2011] 25

40 3. Modelltransformationen Tabelle 3.1.: SLAstic-Modell der Boosktore-Anwendung. Verweise zwischen Modellelementen erfolgen über die ID s (a) ComponentTypes ID Name ProvidedInterfaces RequiredInterfaces Operations (ReturnType) 0 Bookstore T 0 1, 2 searchbook (N/A) 1 Catalog T 1 - getbook (N/A) 2 CRM T 2 1 getoffers (N/A) (b) Interfaces ID Name Signatures (ReturnType) 0 IBookstore T searchbook (N/A) 1 ICatalog T getbook (N/A) 2 ICRM T getoffers (N/A) (c) ExecutionContainerTypes ID Name 0 thehostname T (d) ConnectorTypes ID Name Interface 0 CONNECTOR_T_50374a d96-9e77-400f7fd90d CONNECTOR_T_6562dd3c-5f75-4feb-8e95-c45e23c452d8 1 2 CONNECTOR_T_7bbe1313-8a21-42b9-93a5-dba531ad3fb8 2 3 CONNECTOR_T_051b a-49da-aa65-394db8b7c2ec 0 (e) ComponentAssemblyModel ID SystemProvidedInterfaces 0 0 (f) AssemblyComponents ID Name ComponentType ProvidingConnectors RequiringConnectors 0 Bookstore 0 0, 2 1 Catalog 1 0, 1 2 CRM (g) SystemProvidedInterfaceDelegationConnectors ID Name ConnectorType ProvidingComponent 0 ASM_SYSPROVCONN_NN_d95beb19-ff f0e-a2938d6761f4 3 0 (h) AssemblyComponentConnectors ID Name ConnectorType ProvidingComponent RequiringComponent 0 ASM_CONN_NN_119181b3-b30d-4e23-a7e8-e33de2835e5f ASM_CONN_NN_7de67a35-6cdd-402e-8f1b-dd836dfce ASM_CONN_NN_f0e3358f-d7f a9d-a3f299a11a4c (i) DeploymentComponents ID AssemblyComponent ExecutionContainer (j) ExecutionContainers ID Name ExecutionContainerType 0 thehostname 0

41 3.2. Transformation von SLAstic-Modellen in PCM-Modelle Tabelle 3.2.: Grundlegende Abbildung der Submodelle SLAstic PCM TypeRepository Repository, ResourceRepository ComponentAssembly System ExecutionEnvironment ResourceEnvironment ComponentDeployment Allocation - Usage 3.2. Transformation von SLAstic-Modellen in PCM-Modelle Zur Transformation von SLAstic-Modellen in PCM -Modelle wurde ein ATL-Programm (siehe Abschnitt 2.2) entwickelt und in das SLAstic-Framework integriert. Im Folgenden werden die semantischen Details dieser Transformation beschrieben. Zur Illustration werden Screenshots der in die PCM -Bench importierten PCM -Instanz, welche durch die Transformation der Bookstore-Beispielanwendung gewonnen wurde, abgebildet. Die beiden beteiligten Metamodelle (SLAstic und PCM ) sind auf oberster Ebene in mehrere Submodelle aufgeteilt. Tabelle 3.2 zeigt die grundlegenden Abbildungen der Submodelle des SLAstic-Metamodells auf diejenigen des PCM -Metamodells. Es ist ersichtlich, dass lediglich für das PCM -UsageModel keine semantische Entsprechung im SLAstic-Metamodell existiert. Es werden zunächst nur strukturelle Aspekte bzw. solche Aspekte, die aus der statischen Analyse gewonnen werden können, betrachtet. Informationen aus der dynamischen Analyse und über Benutzerinteraktionen werden in Kapitel 4 betrachtet TypeRepository (SLAstic) Repository (PCM) In beiden Metamodellen existiert das Konzept des Repository. Ein Repository (PCM ) enthält im wesentlichen Spezifikationen von Komponenten und Interfaces [Reussner et al. 2007]. Das Repository (PCM ) beinhaltet keinerlei Informationen über die Instanziierung und das Deployment dieser Komponenten. Tabelle 3.3 zeigt die zentralen Abbildungen der Transformation des TypeRepository (SLAstic) in das Repository (PCM ). Komponenten werden im SLAstic-Metamodell durch sogenannte ComponentTypes repräsentiert, im PCM -Metamodell entspricht dies der BasicComponent (siehe Abbildungen 3.3 und 3.4). PCM erlaubt auch die hierarchische Komposition von Kom- 27

42 3. Modelltransformationen Tabelle 3.3.: TypeRepository (SLAstic) Repository (PCM ) SLAstic PCM TypeRepositoryModel Repository ComponentType BasicComponent Interface Interface Operation Interface, ProvidedRole Signature Signature - Datatype Abbildung 3.3.: TypeRepositoryModel (SLAstic) Metamodell ponenten zu sogenannten CompositeComponents (PCM ). Im SLAstic-Metamodell existiert zu diesen zusammengesetztem Komponenten keine Entsprechung, daher werden durch die Transformation lediglich BasicComponents (PCM ) erzeugt. Zu den Datatypes (PCM ) existieren im SLAstic-Metamodell keine direkten Entsprechungen. Für das Ziel der Performance-Vorhersage sind die Datatypes (PCM ) aber unbedeutend und werden daher nicht berücksichtigt. Im SLAstic-Metamodell sind die von einer Komponente bereitgestellten bzw. verwendeten Interfaces direkt mit der Komponente verknüpft. Im PCM -Metamodell erfolgt diese Verknüpfung über eine ProvidedRole (PCM ) bzw. eine RequiredRole (PCM ). Für jedes von einer BasicComponent (PCM ) bereitgestelltes Interface muss dessen Implementierung durch ein RDSEFF modelliert werden. Die Extraktion des RDSEFFs durch dynamische Analyse wird in Kapitel 4 gesondert beschrieben. 28

43 3.3. TypeRepository ( SLAstic) Repository ( PCM) Abbildung 3.4.: Repository (PCM ) Metamodell Für die Quellmodellelemente ExecutionContainerType (SLAstic), ResourceType (SLAstic), NetworkLinkType (SLAstic) und ConnectorType (SLAstic) existieren im Zielmetamodell keine direkten Entsprechungen. Die Informationen aus dem Quellmodell über diese Elemente werden jedoch in diversen Transformationsschritten verwendet. Als Beispiel für die Implementierung der Transformation mit ATL zeigt Listing 3.1 die Regel zur Abbildung des TypeRepositoryModels (SLAstic) auf das Repository (PCM ). Weitere Beispiele für ATL-Transformationsregeln und deren detaillierte Erklärung finden sich in Abschnitt 3.7. Abbildung 3.5 zeigt das aus der SLAstic-Modellinstanz der Bookstore-Anwendung durch die Transformation gewonnene Repository (PCM ). Listing 3.1: ATL-Regel: TypeRepositoryModel (SLAstic) Repository (PCM ) 1 rule TypeRepositoryModelToRepository { 2 from s r c : S l a s t i c! TypeRepositoryModel 3 to t g t : Pcm! Repository i n REPOSITORY ( 4 Assuming t h e r e i s only one r e p o s i t o r y. 5 i d < repository_1, 6 entityname < d e f a u l t R e p o s i t o r y, 7 r e p o s i t o r y D e s c r i p t i o n < r e p o s i t o r y d e s c r i p t i o n, 8 i n t e r f a c e s R e p o s i t o r y < s r c. i n t e r f a c e s, 9 components Repository < s r c. componenttypes 10 ) 11 } 29

44 3. Modelltransformationen Abbildung 3.5.: PCM -Repository-Diagramm der Bookstore-Anwendung Tabelle 3.4.: ComponentAssembly (SLAstic) System (PCM ) SLAstic PCM ComponentAssemblyModel System AssemblyComponent AssemblyContext AssemblyComponentConnector AssemblyConnector SystemProvidedInterfaceDelegationConnector ProvidedDelegationConnector 3.4. ComponentAssembly (SLAstic) System (PCM) Das ComponentAssembly-Modell (SLAstic) definiert die logischen Bestandteile eines Systems. Wichtigste Bestandteile sind dabei AssemblyComponents (SLAstic), als Instanzen der ComponentTypes (SLAstic) aus dem Repository (siehe Abschnitt 3.3). In Tabelle 3.4 sind die zentralen Abbildungen dieses Transformationsschrittes dargestellt. Die Abbildungen 3.6 und 3.7 zeigen die Struktur der beteiligten Metamodelle. Die Transformation bildet jede AssemblyComponent (SLAstic) auf einen Assembly- Context (PCM ) ab. Ein AssemblyContext (PCM ) erlaubt, genau wie die Assembly- Component (SLAstic), die mehrfache Verwendung eines Komponententyps in verschiedenen Umgebungen [Reussner et al. 2007]. Aus den AssemblyComponents (SLAstic) bzw. AssemblyContexts (PCM ) lassen sich die RequiredRoles und ProvidedRoles der zugehörigen Komponente ableiten. Ein AssemblyConnector ( PCM) verbindet eine RequiredRole ( PCM) einer Komponente in einem AssemblyContext mit einer ProvidedRole ( PCM) einer Komponente in einem anderen Kontext. Das bedeutet, dass jeder Aufruf einer Operation in einer RequiredRole ( PCM) an die über einen AssemblyConnector ( PCM) und eine ProvidedRole ( PCM) verknüpfte 30

45 3.4. ComponentAssembly ( SLAstic) System ( PCM) Abbildung 3.6.: ComponentAssemblyModel (SLAstic) Metamodell Abbildung 3.7.: System (PCM ) Metamodell Komponente geleitet wird [Reussner et al. 2007]. Ein AssemblyConnector (SLAstic) entspricht genau einem AssemblyConnector (PCM ). Vom System nach außen angebotene Dienste (durch Interfaces bzw. Signatures) werden über einen SystemProvidedInterfaceDelegationConnector ( SLAstic) mit einer passenden AssemblyComponent (SLAstic) verbunden. Im PCM -Metamodell entspricht so eine Verbindung einem ProvidedDelegationConnector (PCM ). Abbildung 3.8 zeigt das aus dem SLAstic-Modell der Bookstore-Anwendung erzeugte System (PCM ). 31

46 3. Modelltransformationen Abbildung 3.8.: PCM -System-Diagramm der Bookstore-Anwendung Tabelle 3.5.: ExecutionEnvironment (SLAstic) ResourceEnvironment (PCM ) SLAstic PCM ExecutionEnvironmentModel ResourceEnvironment ExecutionContainer ResourceContainer ResourceSpecification ProcessingResourceSpecification 3.5. ExecutionEnvironment (SLAstic) ResourceEnvironment (PCM) Das ExecutionEnviroment (SLAstic) bzw. ResourceEnvironment (PCM ) beschreibt eine Menge von Entitäten, auf denen Komponenten alloziert und mittels derer Komponenten ausgeführt werden können (siehe Abbildungen 3.9 und 3.10). Die entscheidenden Abbildungen dieses Teils der Transformation sind in Tabelle 3.5 aufgeführt. Im Repository (SLAstic) werden ExecutionContainerTypes (SLAstic) spezifiziert (siehe Abbildung 3.3). Ein ExecutionContainerType (SLAstic) repräsentiert den Typ einer physikalischen oder abstrakten Entität inklusive deren Ressourcen (z.b. CPU, Speicher). Im ExecutionEnvironment (SLAstic) werden Instanzen dieser ExecutionContainerTypes (SLAstic) spezifiziert, die ExecutionContainers (SLAstic). Im PCM -Metamodell gibt es das vergleichbare Konzept des ResourceContainer (PCM ). Allerdings wird hier nicht zwischen Typen und deren Instanzen differenziert. Jeder 32

47 3.5. ExecutionEnvironment ( SLAstic) ResourceEnvironment ( PCM) Abbildung 3.9.: ExecutionEnvironment (SLAstic) Metamodell Abbildung 3.10.: ResourceEnvironment (PCM ) Metamodell 33

48 3. Modelltransformationen Abbildung 3.11.: PCM -ResourceEnvironment der Bookstore-Anwendung in Baumansicht ExecutionContainer (PCM ) aus dem Quellmodell wird unter Berücksichtigung der in der Typdefinition angegebenen Ressourcen in einen ResourceContainer (PCM ) im ResourceEnvironment (PCM ) übersetzt. Dabei werden im Falle von mehreren Instanzen desselben ExecutionContainerTypes (SLAstic) die zugehörigen Informationen bezüglich der Ressourcen im ResourceEnvironment (PCM ) redundant eingefügt. Abbildung 3.11 zeigt das ResourceEnvironment (PCM ) der Bookstore-Anwendung in einer Baumdarstellung, welche die in der PCM -Bench verfügbare Darstellungsform für ein ResourceEnvironment (PCM ) ist. 34

49 3.6. ComponentDeployment ( SLAstic) Allocation ( PCM) Tabelle 3.6.: ComponentDeployment (SLAstic) Allocation (PCM ) SLAstic PCM ComponentDeploymentModel Allocation DeploymentComponent AllocationContext Abbildung 3.12.: ComponentDeployment (SLAstic) Metamodell 3.6. ComponentDeployment (SLAstic) Allocation (PCM) Das ComponentDeploymentModel (SLAstic) beschreibt die Zuweisung von Instanzen der AssemblyComponents (SLAstic, siehe Kapitel 3.4) auf ExecutionContainer (SLAstic). Eine solche Zuweisung wird im SLAstic-Metamodell als DeploymentComponent bezeichnet. Die grundlegenden Abbildungen der Transformation des ComponentDeployment- Model (SLAstic) sind in Tabelle 3.6 dargestellt. Im PCM -Metamodell existiert der sogenannte AllocationContext (PCM ) als Äquivalent zur DeploymentComponent (SLAstic). Die Transformation kann direkt erfolgen. Abbildung 3.13.: Allocation (PCM ) Metamodell 35

50 3. Modelltransformationen Abbildung 3.14.: PCM -Allocation-Diagramm der Bookstore-Anwendung SLAstic-System-Modell - TypeRepository - ExecutionEnvironment - ComponentAssembly - ComponentDeployment SLAstic-Usage-Modell SLAstic2PCM Ausführung durch: - Eclipse-Launcher - Kommandozeile - Java-API PCM-Modell - ResourceType - Repository - ResourceEnvironment - Allocation - System - UsageModel Abbildung 3.15.: ATL-Transformation: SLAstic2PCM Abbildung 3.14 zeigt das durch die Transformation erzeugte PCM -Allocation-Diagramm der Bookstore-Anwendung Implementierung der Transformation in ATL Die in den vorherigen Abschnitten beschriebene Transformation von SLAstic- Modellen in PCM -Instanzen ist in ATL (siehe Abschnitt 2.2) implementiert. Die vorgestellten Abbildungen von SLAstic-Konstrukten auf PCM -Konstrukte werden in ATL als Regeln formuliert. Im Folgenden wird die Definition der ATL-Regeln anhand einiger Beispiele erläutert. Eine ausführliche Anleitung für die Ausführung der Transformation befindet sich in Anhang A. Der vollständige Quelltext der ATL-Transformation ist Anhang B zu entnehmen. Eine Übersicht über den Prozess der Transformation (SLAstic2PCM ) ist in Abbildung 3.15 zu sehen. Benötigte Eingabe für die Transformation sind das SLAstic-System-Modell und das SLAstic-UsageModel (siehe Kapitel 4). Ausgabe ist dann das PCM -Modell, bestehend aus den Submodellen ResourceType, Repository, ResourceEnvironment, Allocation, System und UsageModel. Die Transformation kann auf unterschiedliche Weisen ausgeführt werden. 36

51 3.7. Implementierung der Transformation in ATL Ausführung der Transformation (SLAstic2PCM) Die Transformation kann aus der Eclipse-Entwicklungsumgebung mit installiertem ATL- Plugin gestartet werden. Es muss eine entsprechende Eclipse-Launch-Configuration konfiguriert werden. Abbildung 3.16 zeigt einen Screenshot der Eclipse-LaunchConfiguration für die Bookstore-Beispielanwendung. Für eine detaillierte Anleitung zur Ausführung der Transformation in Eclipse siehe Anhang A. Zur Integration der Transformation in das SLAstic-Framework bietet die Java-Klasse SlasticToPcmTransformation (siehe Abbildung 3.17) eine API mit verschiedenen Möglichkeiten der Modellverarbeitung. Die Methode transform startet die Transformation entweder auf Basis des SLAstic-System-Modells und des SLAstic-Usage-Modells als Laufzeitobjekt (SLAsticModel), als EMF-Ressourcen oder durch das Übergeben eines Pfades zu einem serialisierten SLAstic-Modell. Anschließend lassen sich durch verschiedene getter-methoden die einzelnen PCM - Submodelle zur weiteren Verarbeitung beziehen. Außerdem ermöglicht die Methode extractpcmmodel das PCM -Modell in serialisierter Form in Dateien abzuspeichern. Die Verwendung dieser Klasse als Kommandozeilenwerkzeug (durch das Shell-Skript slastic2pcm.sh) zur Transformation serialisierter Modellinstanzen wird in Anhang A beschrieben. ExecutionContainer (SLAstic) ResourceContainer (PCM) Listing 3.2 zeigt eine einfache ATL-Regel zur Transformation der ExecutionContainer (SLAstic) in ResourceContainer (PCM ) (siehe Kapitel 3.5). Da die beiden Konstrukte semantisch nahezu äquivalent sind, sind keine strukturellen Eingriffe nötig. Da id s in PCM Zeichenketten sind, wird die tostring-methode auf die ganzzahlige SLAsticid angewendet. Der Name des ExecutionContainer wird direkt übernommen. Der Liste der activeresourcespecifications (PCM ) wird die entsprechende Liste aus dem SLAstic-Modell zugewiesen. Die Transformation der Listenelemente erfolgt dann durch eine weitere Regel. 37

52 3. Modelltransformationen Abbildung 3.16.: Eclipse-Launch-Configuration für die Transformation der Bookstore- Beispielanwendung 38

53 3.7. Implementierung der Transformation in ATL SlasticToPcmTransformation +transform(systemmodel : SystemModel, usagemodel : UsageModel) : void +transform(systemmodelpath : String, usagemodelpath : String) : void +transform(systemmodelresource : Resource, usagemodelresource : Resource) : void +getpcmresourcetypemodel() : IModel +getpcmrepositorymodel() : IModel +getpcmresourceenvironmentmodel() : IModel +getpcmallocationmodel() : IModel +getpcmsystemmodel() : IModel +getpcmusagemodel() : IModel +extractpcmmodel(componentcontext : IComponentContext, outputfileprefix : String) : void +extractpcmmodel(directory : String, outputfileprefix : String) : void +main(args : String[]) : void Abbildung 3.17.: UML Klassendiagramm: SlasticToPcmTransformation Listing 3.2: ATL-Regel: Execution Container (SLAstic) ResourceContainer (PCM ) 1 rule ExecutionContainerToResourceContainer { 2 from s r c : S l a s t i c! ExecutionContainer 3 to t g t : Pcm! ResourceContainer in RESOURCEENVIRONMENT ( 4 i d < s r c. i d. t o S t r i n g ( ), 5 entityname < s r c. name, 6 a c t i v e R e s o u r c e S p e c i f i c a t i o n s _ R e s o u r c e C o n t a i n e r < s r c. executioncontainertype. r e s o u r c e s 7 ) 8 } ComponentType (SLAstic) BasicComponent (PCM) Listing 3.3 zeigt einen weiteren Ausschnitt aus der Transformation. Es handelt sich um eine komplexere Regel zur Transformation eines ComponentType (SLAstic) in eine BasicComponent (PCM ) (siehe Abschnitt 3.3). Die id wird aus dem Quellmodell, um den Buchstaben c als Präfix ergänzt, übernommen. Der Name der Komponente wird unverändert übernommen. Listing 3.3: ATL-Regel: ComponentType (SLAstic) BasicComponent (PCM ) 1 rule ComponentTypeToBasicComponent { 2 from s r c : S l a s t i c! ComponentType 3 to t g t : Pcm! BasicComponent i n REPOSITORY ( 39

54 3. Modelltransformationen 4 i d < c + s r c. id. t o S t r i n g ( ), 5 entityname < s r c. name, 6 p r o v i d e d R o l e s _ I n t e r f a c e P r o v i d i n g E n t i t y < s r c. p r o v i d e d I n t e r f a c e s >c o l l e c t ( i n t e r f a c e 7 thismodule. NewProvidedRole ( i n t e r f a c e, s r c ) 8 ), 9 r e q u i r e d R o l e s _ I n t e r f a c e R e q u i r i n g E n t i t y < s r c. r e q u i r e d I n t e r f a c e s >c o l l e c t ( i n t e r f a c e 10 thismodule. NewRequiredRole ( i n t e r f a c e, s r c ) 11 ), 12 s e r v i c e E f f e c t S p e c i f i c a t i o n s B a s i c C o m p o n e n t < s r c. o p e r a t i o n s >c o l l e c t ( o p e r a t i o n 13 thismodule. NewResourceDemandingSEFF ( o p e r a t i o n ) 14 ) 15 ) 16 } Für die im SLAstic-Modell direkt mit dem ComponentType verknüpften bereitgestellten bzw. benötigten Interfaces müssen im PCM -Modell entsprechende ProvidedRoles bzw. RequiredRoles erzeugt werden. Dies geschieht durch die ATL-Called Rules NewProvidedRole bzw. NewRequiredRole. Listing 3.4 zeigt dies am Beispiel der Regel NewProvided- Role. Die Erzeugung der RDSEFFs erfolgt analog durch die Called Rule mit dem Namen NewResourceDemandingSEFF (siehe Kapitel 4). Listing 3.4: ATL-Called Rule zur Erzeugung einer ProvidedRole (PCM ) 1 rule NewProvidedRole ( i n t e r f a c e : S l a s t i c! I n t e r f a c e, componenttype : S l a s t i c! ComponentType ) { 2 to t g t : Pcm! ProvidedRole i n REPOSITORY ( 3 i d < pr + i n t e r f a c e. i d. t o S t r i n g ( ) + _ + componenttype. i d. t o S t r i n g ( ), 4 entityname < Provided_ + i n t e r f a c e. name + _ + componenttype. name, 5 providedinterface ProvidedRole < Pcm! I n t e r f a c e. a l l I n s t a n c e s ( ) >any ( pcm_interface 6 pcm_interface. i d = i + i n t e r f a c e. id. t o S t r i n g ( ) 7 ) 8 ) 9 do { 40

55 3.7. Implementierung der Transformation in ATL 10 t g t ; 11 } 12 } Beim Erzeugen der ProvidedRole werden id und Name aus den entsprechenden Eigenschaften der beteiligten Komponente und dem bereitgestellten Interface mit ergänzenden Präfixen gebildet. Das betreffende Interface (PCM ) wird anhand der id des der Regel übergebenen Interface (SLAstic), aus der Menge aller verfügbaren Interfaces (PCM ), identifiziert. 41

56

57 4. Extraktion von RDSEFFs und UsageModels durch dynamische Analyse Eine Resource Demanding Service Effect Specification (RDSEFF) beschreibt den Kontrollfluss eines Dienstes einer Komponente (siehe Abschnitt 2.4). Um eine PCM -Instanz in SimuCom oder SLAstic.SIM zu simulieren, muss das Verhalten jedes bereitgestellten Dienstes jeder Komponente mithilfe einer RDSEFF spezifiziert werden. Um das Verhalten eines Dienstes mittels einer RDSEFF zu modellieren, sind folgende Informationen nötig: Der Bedarf an Ressourcen der während der Abarbeitung des Dienstes ausgeführten Aktionen. Die Verwendung externer Dienste, z.b. die Anzahl von Aufrufen sowie deren relative Häufigkeit. Das SLAstic-SystemModel enthält diese nötigen Informationen nicht, so dass sich allein aus SLAstic-SystemModel-Instanzen keine RDSEFFs gewinnen lassen. Aus diesem Grund wurde das SLAstic-Metamodell um ein sogenanntes UsageModel erweitert. Dieses UsageModel wird bei der Erzeugung einer SLAstic-Modellinstanz zur Laufzeit um die zur Rekonstruktion von RDSEFFs nötigen Informationen angereichert. In den Abschnitten 4.1 werden Ansätze zur Erweiterung des SLAstic-Metamodell diskutiert und in Abschnitt 4.2 der gewählte Ansatz genauer beschrieben. Abschnitt 4.3 handelt von der Extraktion des Kontrollflusses von Operationen durch dynamische Analyse. Abschnitt 4.4 beschreibt die Extraktion von UsageModels (PCM ). 43

58 4. Extraktion von RDSEFFs und UsageModels durch dynamische Analyse BookstoreStarter + main() 10 Bookstore + searchbook() 4 17 CRM + getoffers() Catalog + getbook() 12 Abbildung 4.1.: Beispiel: Absolute Häufigkeiten von Operationsaufrufen der Bookstore- Beispielanwendung 4.1. Evaluation von Möglichkeiten zur Extraktion von RDSEFFs Die nötigen Informationen zur Extraktion der RDSEFFs (siehe oben) sind im SLAstic- Metamodell nicht enthalten. Das SLAstic-Metamodell muss also auf eine Art und Weise erweitert werden, die es erlaubt, das Modell dynamisch mit den nötigen Informationen anzureichern. Es wurden verschiedene Varianten dieser Erweiterung diskutiert. Ein erster Ansatz sieht lediglich das Zählen jedes Aufrufs einer Operation vor. Eine schematische Darstellung einer auf diese Weise angereicherten Modellinstanz der Bookstore-Beispielanwendung ist in Abbildung 4.1 zu sehen. Die Kanten entsprechen Aufrufbeziehungen zwischen den einzelnen Operationen. Die Kantenbeschriftung entspricht der Anzahl der Aufrufe der jeweiligen Operationen über die durch die Kante identifizierte Aufrufbeziehung während des beobachteten Zeitraumes. Mit Hilfe dieser absoluten Häufigkeiten von Operationsaufrufen lässt sich nun die durchschnittliche Anzahl an Aufrufen einer Operation bezüglich der aufrufenden Operation errechnen. Aus dem Beispiel aus Abbildung 4.1 ergibt sich z.b. die durchschnittliche Anzahl von 4 10 Aufrufen der Operation getbook während einer Ausführung der Operation searchbook. Der Kontrollfluss einer Operation lässt sich dann als Markow-Kette mit ein- 44

59 4.2. Erweiterung des SLAstic-Metamodells er Schleife für jeden Operationsaufruf und Übergangswahrscheinlichkeiten entsprechend der durchschnittlichen Aufrufe der Operationen modellieren. Die Modellierung des Kontrollflusses mit Markow-Ketten kann nicht auf die RDSEFFs im PCM -Metamodell abgebildet werden [Reussner et al. 2007]. Da bei der Modellierung von Schleifen mit Markow-Ketten die Anzahl der Iterationen immer durch eine geometrische Verteilung beschränkt ist, wurde bei dem Entwurf von PCM ein anderer Ansatz gewählt [Koziolek und Firus 2007]. Der in PCM gewählte Ansatz erlaubt die Verwendung beliebiger diskreter Wahrscheinlichkeitsverteilungen für die Anzahl von Iterationen einer Schleife. Für jeweils eine feste Anzahl an Iterationen für eine Schleife wird eine Wahrscheinlichkeit angegeben. Beispielsweise besteht in dem folgenden Ausdruck einer Wahrscheinlichkeitsverteilung in PCM für die Iterationsanzahl einer Schleife die Wahrscheinlichkeit 0.2 für einen Schleifendurchlauf, 0.5 für drei Iterationen sowie 0.3 für 10 Durchläufe. IntP MF [(1; 0.2)(3; 0.5)(10; 0.3)] Die Anreicherung des SLAstic-Modells mit den absoluten Häufigkeiten von Operationsaufrufen reicht also nicht aus. Zusätzlich muss die Häufigkeit jeder auftretenden Anzahl von externen Operationsaufrufen festgehalten werden, um geeignete Wahrscheinlichkeitsverteilungen im Zielmodell generieren zu können. Die entsprechenden Erweiterungen des SLAstic-Metamodells sind im nachfolgenden Abschnitt beschrieben Erweiterung des SLAstic-Metamodells Das SLAstic-Metamodell wurde um ein sogenanntes UsageModel erweitert, welches das bisherige SLAstic-Metamodell anreichert. Bei der Gestaltung des UsageModel stand die einfache Transformierbarkeit in PCM -Modellinstanzen, speziell die Transformation in RDSEFFs, im Mittelpunkt. Abbildung 4.2 zeigt das dem UsageModel zu Grunde liegende Metamodell. Das UsageModel enthält Informationen über die Häufigkeit von Aufrufen und über die Beziehung (z.b. der Aufruf einer Operation über eine Verbindung durch einen Konnektor oder der Aufruf von außen) der Operationen des beobachteten Systems innerhalb des überwachten Zeitraums. Für jede aufgerufene Operation enthält die OperationCallFrequency die absolute Häufigkeit an Aufrufen. Diese setzt sich zusammen aus: 45

60 4. Extraktion von RDSEFFs und UsageModels durch dynamische Analyse Abbildung 4.2.: UsageModel (Metamodell). Elemente, die durch die Erweiterung des Metamodells hinzugekommen sind, sind gelb hervorgehoben. 46

61 4.3. Extraktion von RDSEFFs durch dynamische Analyse Abbildung 4.3.: ResourceDemandingSEFF (Metamodell) den absoluten Häufigkeiten von Aufrufen der betrachteten Operation von außerhalb des Systems (z.b. durch Benutzerinteraktion). Diese sind im UsageModel als SystemProvidedInterfaceDelegationConnectorFrequencies enthalten. den absoluten Häufigkeiten von Aufrufen der betrachteten Operation innerhalb des Systems, d.h. ausgehend von der Ausführung anderer Operationen. Diese sind im UsageModel als AssemblyComponentConnectorCallFrequencies enthalten. Darüber hinaus enthält das UsageModel mit den CallingRelationships detaillierte Informationen über die Verteilung von Häufigkeiten interner Operationsaufrufe. Für jede Beziehung zwischen einer aufrufenden Operation und aufgerufenen Interfaces und Signaturen wird hier die Häufigkeit der Aufrufe der aufgerufenen Interfaces und Signaturen innerhalb eines Aufrufs der aufrufenden Operation gespeichert Extraktion von RDSEFFs durch dynamische Analyse Für jede Operation eines ComponentType im Quellmodell wird während der Transformation ein RDSEFF im Zielmodell erzeugt. Ausgangspunkt der Extraktion des Kontrollflusses einer Operation sind die CallingRelationships im UsageModel (SLAstic). Aus Abbildung 4.3 geht hervor, dass ein RDSEFF im Wesentlichen eine Zuordnung der Signatur der beschriebenen Operation zu einer Reihe von AbstractActions ist (ResourceDemandingBehaviour). Die Transformation erzeugt die Folge der Aktionen nach folgendem Muster, verkettet in der Reihenfolge der Aufzählung: 47

62 4. Extraktion von RDSEFFs und UsageModels durch dynamische Analyse Abbildung 4.4.: Muster für die Erzeugung der RDSEFFs 1. Eine StartAction als Einstiegspunkt der RDSEFF. 2. Eine InternalAction, um eventuellen Bedarf an Ressourcen beim Einstieg in eine Operation zu modellieren. 3. Eine LoopAction für jede CallingRelationship, an der die betrachtete Operation als aufrufende Operation beteiligt ist. Die Erzeugung der LoopActions wird im Folgenden gesondert betrachtet. 4. Eine InternalAction, um eventuellen Ressourcenbedarf vor Beendigung der Operation zu modellieren. 5. Eine StopAction. Dieses Muster für die Erzeugung der RDSEFFs ist in Abbildung 4.4 grafisch dargestellt. Die Reihenfolge der LoopActions ist aus dem SLAstic-Modell nicht rekonstruierbar und für die Performance-Vorhersage unbedeutend, so dass diese in beliebiger Reihenfolge verkettet werden können. Erzeugung der LoopActions Eine LoopAction besteht aus dem IterationCount, der die Anzahl der Iterationen der Schleife angibt, sowie aus einer Folge von AbstractActions als Schleifenrumpf. Für den IterationCount wird ein Histogramm für eine Wahrscheinlichkeitsverteilung in Form einer PCMRandomVariable erzeugt, die die aus der CallingRelationship ( SLAstic) bekannten absoluten Häufigkeiten als relative Wahrscheinlichkeiten ausdrückt. Die Erzeugung des Schleifenrumpfes als Folge von AbstractActions erfolgt nach folgendem Muster (verkettet in der Reihenfolge der Aufzählung): 48

63 4.3. Extraktion von RDSEFFs durch dynamische Analyse Abbildung 4.5.: Muster für die Erzeugung der LoopActions 1. Eine StartAction als Beginn des Rumpfes der Schleife. 2. Eine InternalAction zur Modellierung von eventuellem Ressourcenbedarf vor dem Aufruf der über die CallingRelationship verknüpften aufzurufenden Operation. 3. Eine ExternalCallAction, welche dem Aufruf der verknüpften Operation entspricht. 4. Eine InternalAction, um eventuellen Ressourcenbedarf nach Beendigung des externen Aufrufs abzubilden. 5. Eine StopAction. Das Muster für die Erzeugung der LoopActions ist in Abbildung 4.5 grafisch dargestellt. Spezifikation von Iterationshäufigkeiten mit Hilfe stochastischer Ausdrücke Die Anzahl der Iterationen einer LoopAction kann neben einem absoluten Wert auch durch einen stochastischen Ausdruck mit relativen Häufigkeiten für verschiedene Iter- 49

64 4. Extraktion von RDSEFFs und UsageModels durch dynamische Analyse Abbildung 4.6.: ExternalCallAction (Metamodell) ationsanzahlen angegeben werden. Dies entspricht einer diskreten Wahrscheinlichkeitsverteilung. Die FrequencyDistribution enthält die auftretenden Iterationsanzahlen value 1...n sowie die zugehörigen absoluten Häufigkeiten frequency 1...n. Für jede Iterationsanzahl wird die relative Häufigkeit h i 1...n(valuei ) errechnet. Diese ergibt sich aus der zugehörigen absoluten Häufigkeit frequency i und aus der Summe aller Aufrufe der Operation (s):. h i (value i ) = frequency i s Für mehrere Iterationsanzahlen und zugehörige absolute Häufigkeiten wird die Verteilung in PCM -Modellen in Tupelschreibweise angegeben: IntP MF [(value 1 ; h 1 (value 1 ))(value 2 ; h 2 (value 2 ))... (value n ; h n (value n ))]. Erzeugung der ExternalCallActions Die für die Extraktion der RDSEFFs entscheidende Eigenschaft einer ExternalCallAction ist die in Abbildung 4.6 ersichtliche Verknüpfung der Signatur des aufgerufenen Interfaces bzw. der Signatur mit der entsprechenden OperationRequiredRole der betroffenen Komponente. 50

65 4.3. Extraktion von RDSEFFs durch dynamische Analyse Abbildung 4.7.: UML Sequenzdiagramm der angepassten Bookstore-Anwendung Für diesen Transformationsschritt wird also lediglich anhand der Signaturen der Operationen die entsprechende OperationRequiredRole aus dem Repository identifiziert, um die ExternalCallAction zu erzeugen Anpassung der Bookstore-Anwendung Zur Illustration der Extraktion von RDSEFFs wurde die Bookstore-Anwendung angepasst. Statt der linearen Aufrufstruktur der Operationen, wie sie im Sequenzdiagramm in Abbildung 3.2 zu sehen ist, kann nun eine variable Aufrufstruktur abgebildet werden (siehe Abbildung 4.7). Die Aufruffolge ist über Parameter beeinflussbar. Zur Erzeugung von SLAstic-Modellinstanzen der Bookstore-Anwendung mit verschiedenen Aufruffolgen dient eine Funktion: F t : Z Z Z Z P(T races), mit t Z 4, einem Tupel, welches die Anzahl der Operationsaufrufe für die Operationen searchbook, getbook, getoffers und getbook spezifiziert (in dieser Reihenfolge). 51

66 4. Extraktion von RDSEFFs und UsageModels durch dynamische Analyse Tabelle 4.1.: SLAstic-UsageModel der Bookstore-Anwendung auf Grundlage der Aufruffolgen T 0, T 1, T 2. Die Verweise beziehen sich auf das SLAstic-SystemModel aus Tabelle 3.1 CallingOperation (Komponente, Operation) CalledInterface (a) CallingRelationships CalledSignature (Interface, Signatur) FrequencyDistribution (Aufrufanzahl,Häufigkeit) (2, getoffers) 1 (1, getbook (N/A)) (2,27),(4,24),(88,4) (0, searchbook) 2 (2, getoffers (N/A)) (1,4),(2,12),(3,9) (0, searchbook) 1 (1, getbook (N/A)) (1,9),(3,12),(8,4) (b) OperationCallFrequencies Frequency Operation (Komponente, Operation) 25 (0, searchbook) 579 (1, getbook) 55 (2, getoffers) (c) SystemProvidedInterfaceDelegationConnectorFrequencies Frequency Signature (Interface, Connector Signatur) 25 (0, searchbook(n/a)) 0 Das heißt, F t (1, 1, 1, 1) entspricht dem linearen Programmdurchlauf aus Abbildung 3.2. T races ist die Menge aller möglichen Programmdurchläufe, mit: T races = {(id Z, {e i e i = (AssemblyComponent, Operation, eoi, eos)})}. Zur Erläuterung der Extraktion von RDSEFFs am Beispiel der Operation searchbook wurden folgende Auffruffolgen gewählt (T i P(T races), i N): T 0 = F t (12, 3, 2, 4) T 1 = F t (9, 1, 3, 2) T 2 = F t (4, 8, 1, 88) Daraus ergibt sich das in Tabelle 4.1 dargestellte SLAstic-UsageModel. 52

67 4.3. Extraktion von RDSEFFs durch dynamische Analyse searchbook / getbook searchbook / getoffers Absolute Haeufigkeit Relative Haeufigkeit Absolute Haeufigkeit Relative Haeufigkeit Anzahl Aufrufe (a) Anzahl Aufrufe (b) Abbildung 4.8.: Operation searchbook: absolute und relative Häufigkeitsfunktion für Folgeaufrufe der Operationen getbook 4.8(a), sowie getoffers 4.8(b). Extraktion der RDSEFF zur Operation searchbook Aus dem Sequenzdiagramm in Abbildung 4.7 geht hervor, dass ein Aufruf der Operation searchbook Aufrufe der Operationen getbook und getoffers verursacht. Der Kontrollfluss der Operation besteht also im Zielmodell aus zwei verketteten LoopActions, deren Iterationsanzahl aus dem UsageModel (SLAstic) hervorgeht. Abbildung 4.8 zeigt die sich aus dem UsageModel (SLAstic) (siehe Tabelle 4.1) ergebenden absoluten und relativen Häufigkeiten der Aufrufe der Operationen getbook und getoffers, wie sie sich aus der dynamischen Analyse ergeben könnten. Zusätzlich ist jeweils die zu den absoluten Häufigkeiten zugehörige Wahrscheinlichkeitsfunktion angegeben. Nach der Erzeugung der zu dem RDSEFF zugehörigen Aktionen nach dem in Abschnitt 4.3 beschriebenen Muster sowie der Erzeugung der PCMRandomVariables (siehe Abschnitt 4.3) ergibt sich durch die Transformation die in Abbildung 4.9 dargestellte Instanz eines RDSEFF. Die Abbildungen 4.10 und 4.11 zeigen die RDSEFFs zu den Operationen getbook bzw. getoffers, die auf die gleiche Weise entstanden sind. 53

68 4. Extraktion von RDSEFFs und UsageModels durch dynamische Analyse Abbildung 4.9.: PCM -SEFF-Diagramm der searchbook-operation 54

69 4.4. Extraktion von UsageModels (PCM) Abbildung 4.10.: PCM -SEFF-Diagramm der getbook-operation Abbildung 4.11.: PCM -SEFF-Diagramm der getoffers-operation 4.4. Extraktion von UsageModels (PCM) Die Spezifikation der Verwendung von Diensten, die das System nach außen anbietet, erfolgt durch ein UsageModel (PCM ) (siehe Abbildung 4.12). Für jeden dieser Dienste wird im UsageModel (PCM ) ein UsageScenario (PCM ) benötigt. Ein UsageScenario besteht aus einem Workload, welcher die Häufigkeit von Benutzerinteraktionen modelliert, und der ScenarioBehaviour, der Spezifikation der bei dem Aufruf von Diensten durch Benutzer ausgeführten Schritte [Reussner et al. 2007]. Durch die Transformation wird ein OpenWorkload für jedes UsageScenario erzeugt. Dies entspricht einer unbeschränkten Anzahl von Benutzern, die das System mit einer bestimmten Häufigkeit betreten und nach der Beendigung des Szenarios wieder verlassen. Die Häufigkeit (Interarrival Time) ergibt sich aus dem Quotienten der Häufigkeit der Aufrufe des betrachteten Dienstes von außen (SystemProvidedInterfaceDelegationCon- 55

70 4. Extraktion von RDSEFFs und UsageModels durch dynamische Analyse Abbildung 4.12.: UsageModel (PCM ) Metamodell Abbildung 4.13.: PCM -UsageModel-Diagramm der Bookstore-Anwendung 56

71 4.4. Extraktion von UsageModels (PCM) nectorfrequency (SLAstic)) und der Dauer des bei der Gewinnung des SLAstic-Modells beobachteten Zeitraums. Die für die ScenarioBehaviour nötigen Aktionen werden nach dem folgenden Muster erzeugt (verkettet in der Reihenfolge der Aufzählung): 1. Eine Aktion Start, als Einstiegspunkt der Beschreibung des Szenarios. 2. Einem EntryLevelSystemCall, welcher dem Aufruf des entsprechenden Dienstes entspricht. 3. Eine Aktion Stop. In Abbildung 4.13 ist das UsageModel-Diagramm für die Bookstore-Anwendung zu sehen. 57

72

73 5. Evaluation In diesem Kapitel wird die Eignung des im Rahmen der vorliegenden Arbeit entstandenen Transformationsprogrammes SLAstic2PCM für den Einsatz im SLAstic-Framework untersucht. In Abschnitt 5.1 werden die Ziele der Evaluation definiert. Die für die Evaluation verwendeten Szenarien werden in Abschnitt 5.2 vorgestellt und in Abschnitt 5.3 werden die Ergebnisse der Untersuchung präsentiert. Schließlich werden in Abschnitt 5.4 verwandte Arbeiten betrachtet Fragestellung und Ziele Ziel der Evaluation ist die Überprüfung der Eignung, der in den Kapiteln 3 und 4 vorgestellten SLAstic2PCM -Transformation, für den Einsatz im SLAstic-Framework. Dazu wird die Transformation auf Modelle von Softwaresystemen mit unterschiedlichem Umfang angewandt. So sollen Aussagen über die Skalierbarkeit des Transformationsprogrammes getroffen werden und diesbezüglich Zusammenhänge mit verschiedenen, die Softwaresysteme beschreibenden Metriken, aufgezeigt werden. Folgende Fragestellungen bzw. Ziele sollen beantwortet bzw. erreicht werden: E1 Funktioniert die Transformation mit Modellen von Softwaresystemen realistischen Umfangs? E2 Wie verhält sich, angewandt auf Modelle unterschiedlichen Umfangs, die Laufzeit des Transformationsprozesses? E3 Welche Metriken beeinflussen die Laufzeit der Transformation? Zur Beantwortung von E1 wird die Transformation auf die in Abschnitt 5.2 beschriebenen Systeme angewendet. Getestet werden soll hier in erster Linie das Funktionieren der Transformation. 59

74 5. Evaluation Für die Fragestellung E2 werden zusätzlich die Laufzeiten bei Anwendung der Transformation auf die verschiedenen Szenarien gemessen und analysiert. Zur Untersuchung von E3 werden Metriken zur Quantifizierung der Modelle eingeführt und Zusammenhänge zwischen diesen Metriken und der Laufzeit der Transformation untersucht. Im Folgenden werden potentielle Probleme aufgezeigt, die das Funktionieren der Transformation in annehmbarer Zeit beeinflussen könnten. Mögliche Skalierungsprobleme der Transformation Die Verwendung der Transformation mit Modellen hoher Komplexität könnten einige häufig verwendete ATL-Konstrukte die in Abschnitt 5.1 diskutierten Aspekte negativ beeinflussen. Listing 5.1 zeigt einen entsprechenden Ausschnitt aus dem Transformationsprogramm. Listing 5.1: ATL-Regel: NewExternalCallAction (PCM ) 1 rule NewExternalCallAction ( r e l a t i o n s h i p : S l a s t i c! C a l l i n g R e l a t i o n s h i p ) { 2 to t g t : Pcm! E x t e r n a l C a l l A c t i o n i n REPOSITORY ( 3 c a l l e d S e r v i c e _ E x t e r n a l S e r v i c e < Pcm! S i g n a t u r e. a l l I n s t a n c e s ( ) >any ( pcm_signature 4 pcm_signature. servicename = r e l a t i o n s h i p. c a l l e d S i g n a t u r e. name 5 ), 6 r o l e _ E x t e r n a l S e r v i c e < Pcm! BasicComponent. a l l I n s t a n c e s ( ) >any ( component 7 component. i d = c + r e l a t i o n s h i p. c a l l i n g O p e r a t i o n. componenttype. id. t o S t r i n g ( ) 8 ). r e q u i r e d R o l e s _ I n t e r f a c e R e q u i r i n g E n t i t y >any ( r o l e 9 r o l e. requiredinterface RequiredRole. id = i + r e l a t i o n s h i p. c a l l e d I n t e r f a c e. i d. t o S t r i n g ( ) 10 ) 11 ) 12 do { 13 t g t ; 14 } 15 } 60

75 5.2. Szenarien Die dargestellte ATL-CalledRule NewExternalCallAction erzeugt für jede im Quellmodell vorhandene CallingRelationship (SLAstic) eine ExternalCallAction (PCM). Das zum Setzten der Signatur des aufzurufenden Dienstes der neuen ExternalCallAction verwendete Konstrukt Pcm!Signature.allInstances() bezieht eine Liste aller im Zielmodell bereits erzeugten Signaturen. Anschließend wird in dieser Liste mit dem any-konstrukt die Signatur mit dem passenden Namen gesucht. Ähnlich verhält es sich bei dem Setzen der passenden RequiredRole (PCM). Hier wird eine Liste aller im Zielmodell bereits erzeugten BasicComponents (PCM) gefiltert. Das heißt, dass die Komplexität des dargestellten Transformationsschrittes von der Anzahl der CallingRelationships (SLAstic) im Quellmodell sowie der Anzahl der im Zielmodell durch die Transformation entstandenen Signaturen und Komponenten abhängt. Eine ähnliche Herangehensweise wurde bei der Implementierung der Transformation auch in diversen anderen Transformationsschritten verwendet Szenarien In diesem Abschnitt werden die für die Evaluation verwendeten Szenarien beschrieben. Abschnitt beschreibt das Vorgehen bei der Erzeugung der zugehörigen Modelle. In Abschnitt werden die zugrunde liegenden Systeme vorgestellt. Abschnitt führt die zur Quantifizierung der Modelle gewählten Metriken ein Erzeugung der Modelle Die zur Evaluation verwendeten Modelle werden durch das Abspielen von aufgezeichneten Kieker-Logs erstellt. Abbildung 5.1 zeigt eine schematische Übersicht des Prozesses zur Erzeugung der SLAstic-Modelle und deren Transformation in PCM -Instanzen. Durch das Abspielen, von im Einsatz des jeweiligen Systems aufgezeichneten Laufzeitdaten, wird das vom SLAstic-Framework verwaltete Softwaresystem ausgeführt. Das SLAstic-Framework erzeugt daraus das SLAstic-Modell, welches sich aus den statischen Informationen im SLAstic-System-Model und den dynamischen Informationen über die Verwendung des Systems im SLAstic-Usage-Model zusammensetzt. An dieser Stelle setzt die Transformation der SLAstic-Modelle mit der in den Kapiteln 3 und 4 beschriebenen SLAstic2PCM -Transformation an. 61

76 5. Evaluation Kieker-FileSystem-Log SLAstic- Framework SLAstic- UsageModel SLAstic- SystemModel SLAstic2PCM PCM-Model Abbildung 5.1.: Erzeugung der SLAstic-Modellinstanzen $ 1635 <<assembly searchbook() 1635 <<assembly getoffers() <<assembly getbook(..) Abbildung 5.2.: Abhängigkeitsgraph für die Bookstore-Anwendung Beschreibung der für die Evaluation eingesetzten Systeme Bookstore Die Bookstore-Beispielanwendung wurde bereits in Kapitel 3 vorgestellt. Die absoluten Häufigkeiten der verschiedenen Operationsaufrufe, der für die Evaluation verwendeten Laufzeitdaten, sind in dem Abhängigkeitsgraph in Abbildung 5.2 ersichtlich. Die Bookstore-Beispielanwendung ist das kleinste verwendete System für die Evaluation. JPetStore Die ibatis JPetStore-Anwendung 1 ist ursprünglich als Beispielanwendung für verschiedene Technologien aus der Java Enterprise Edition (Java EE) entstanden. Es handelt sich um eine Webseite mit einem Online-Shopsystem, welches dem Kauf verschiedener fiktiver Haustiere dient. Der Benutzer kann Haustiere aus verschiedenen Kategorien (wie z.b. Hunde oder Katzen) in seinem Warenkorb ablegen. Im Anschluss daran erfolgt die eigentliche Bestellung, mit der Erfassung benötigter Daten des Benutzers (z.b. Name und Lieferadressse). Die JPetstore-Anwendung entspricht im Umfang eher einem realistischen System als die Bookstore-Beispielanwendung. Für die Evaluation werden 1 siehe 62

77 5.2. Szenarien die in Abbildung 5.3 durch absolute Häufigkeiten von Operationsaufrufen dargestellten Laufzeitdaten verwendet. Kundenportal eines Telekommunikationsdienstleisters Das betrachtete Softwaresystem ist das Kundenportal eines der größten Telekommunikationsdienstleister Norddeutschlands, das deren Kunden z.b. die Konfiguration ihres Kundenkontos ermöglicht. Zur Evaluation des Monitoring Frameworks Kieker wurde dieses Kundenportal instrumentiert und reale Laufzeitdaten über mehrere Tage hinweg aufgezeichnet [van Hoorn et al. 2009b]. Der instrumentierte Teil des Systems besteht aus mehreren Instanzen eines Front-End Servers, welcher die webbasierte Benutzerschnittstelle zur Verfügung stellt sowie eines Java Application Servers, welcher mit Back- End Systemen, wie der Datenbank etc. kommuniziert. In Abbildung 5.4 ist ein Ausschnitt der gemessenen absoluten Häufigkeiten von Operationsaufrufen dargestellt. SPECjEnterprise 2010 SPECjEnterprise ist eine Benchmark-Software zur Untersuchung der Performance von Java EE Application-Servern, sowie der darunter liegenden Infrastruktur, wie Datenbanken, CPU s und Festplatten. Die für die Evaluation eingesetzten absoluten Häufigkeiten von Operationsaufrufen sind zu umfangreich um sie in der vorliegenden Arbeit grafisch darzustellen Verwendete Metriken und deren Anwendung auf die Szenarien Verwendete Metriken sind zunächst solche, die den Umfang der Kieker Monitoring Logs beschreiben: Dateigröße des Kieker Monitoring Logs Anzahl der Operationsausführungen Anzahl der von Kieker rekonstruierten Traces 2 siehe 63

78 5. Evaluation <<assembly $ dofilter(..) <<assembly component>> 2441 doget(..) dopost(..) process(..) <<assembly neworder() 1151 <<assembly insertorder(..) 1151 neworderform() 1290 <<assembly 2599 signoff() signon() 1290 <<assembly getaccount(..) <<assembly additemtocart() <<assembly isiteminstock(..) viewcart() <<assembly viewcategory() getproductlistbycategory(..) getitem(..) getcategory(..) viewitem() getproduct(..) viewproduct() getitemlistbyproduct(..) Abbildung 5.3.: Abhängigkeitsgraph für die JPetStore-Anwendung 64

79 5.2. Szenarien... <<assembly 1367 getsmscontacts(..) 3074 getsmsnumbers(..) 1039 getantivirlicenselist(..) 322 sendsms(..) 39 getsmsauthorization(..) 517 getmailquota(..) 520 getftpquota(..) 155 getsmsauthorizations(..) 5 queuesms(..) 94 getorderstaticipresult(..) 48 getincreasebandwidthresult(..) 15 addantivirlicense(..) 44 sendsupportrequest(..) 36 scheduleantivirlicenseactivation(..) addsmscontact(..) 27 getmysqlquota(..) 70 getmysqlversion(..) 72 removesmscontact(..) 6 createsmstoken(..) 4 activatesmsnumber(..) 3 <<assembly component>> 4 $ <<assembly dofilter(..) <<assembly handlemessage(..) handlemessage(..) createwlanaccount(..) orderstaticip(..) getvirtualserverenvironment() <<assembly 217 getdomains(..) gettopleveldomains(..) 15 getdomains(..) 14 getdomaincategory(..) 8 57 isdomainfree(..) 1 getfederalstateforzipcode(..) 1 isvalidcontact(..) 3 10 performdomainorder(..) 5426 getdomaininfo(..) 4332 deletesubdomain(..) restartdomaintransfer(..) 45 reassigndomain(..) 171 createsubdomain(..) Abbildung 5.4.: Abhängigkeitsgraph für das Kundenportal (Ausschnitt) 65

80 5. Evaluation Tabelle 5.1.: Monitoring Logs Szenario Größe des Anzahl Operationsausführungen Anzahl der Monitoring Logs Rekonstruierten Traces Bookstore 892 kb JPetStore 63 MB Kundenportal 164 MB SPECjEnterprise 380MB Szenario Tabelle 5.2.: SLAstic-Modellinstanzen Statistik Anzahl Anzahl Signaturen Anzahl Anzahl Komponenten Execution- CallingRe- Container lationships Anzahl Wertpaare Bookstore JPetStore Kundenportal SPECjEnterprise Offensichtlich hängt die Dauer der Transformation nicht lediglich von der Komplexität des betrachteten Softwaresystems ab, sondern auch von der Granularität der Instrumentierung und der Länge des beobachteten Zeitraumes. Für die genannten Metriken bezüglich der Monitoring Logs ergeben sich für die vorgestellten Szenarien die in Tabelle 5.1 dargestellten Werte. Für die Quantifizierung der SLAstic-Modelle werden folgende Metriken betrachtet: Anzahl der extrahierten Komponenten Anzahl der extrahierten Signaturen Anzahl der extrahierten ExecutionContainer Anzahl der CallingRelationships Anzahl der Wertpaare in den zu den CallingRelationships zugehörigen Häufigkeitsverteilungen Für die vorgestellten Szenarien ergeben sich die in Tabelle 5.2 dargestellten Werte. 66

81 5.3. Ergebnisse 5.3. Ergebnisse Für das Messen der Ausführungszeit der Transformation, für die einzelnen Szenarien, wurde das Unix time-kommando mit dem slastic2pcm.sh-skript (siehe Anhang A), in mehreren Durchgängen verwendet. Ausgeführt wurden Messungen mit einem Intel Core i Prozessor (4 Kerne, 3,30 Ghz) und 6 GB Arbeitsspeicher auf einem Linux-System (Kernel ). Für alle Szenarien funktionierte die Transformation in annehmbarer Zeit, wobei die längste gemessene Ausführungszeit mit 5,035 Sekunden eine Messung der Transformation des SPECjEnterprise 2010 Benchmark war. Alle entstandenen PCM -Modelle lassen sich mit der PCM -Bench öffnen, weiterverarbeiten und mit dem SimuCom-Simulator simulieren. Die mittleren Ausführungszeiten der Transformation der verschiedenen Szenarien sowie die Standardabweichung sind in Tabelle 5.3 aufgeführt. Es ist deutlich sichtbar, dass die Ausführungszeit mit dem Umfang des transformierten Modells steigt (vgl. hierzu Tabelle 5.2). Jedoch bleibt die in Abschnitt 5.1 beschriebene und befürchtete Potenzierung der Laufzeit aus. Abbildung 5.5 stellt die einzelnen Metriken zur Beschreibung der SLAstic-Modellinstanzen in Zusammenhang mit den gemessenen mittleren Ausführungszeiten dar. Auf eine vergleichende Darstellung der Anzahl der ExecutionContainer mit den gemessenen Ausführungszeiten wurde verzichtet, da die Anzahl der Container über die Szenarien hinweg kaum variiert (vgl. Tabelle 5.2). Eine Korrelation der Anzahl der Komponenten, Signaturen, CallingRelationships und Wertpaare ist deutlich zu erkennen. Allerdings kann auf diese Weise keine Aussage darüber getroffen werden, ob einige der betrachteten Merkmale im Einzelnen als kausale Ursache für die ansteigende Ausführungszeit bei höherer Komplexität des Modells verantwortlich sind. Für eine systematische Untersuchung des Zusammenhangs der vorgestellten Metriken mit gemessenen Ausführungszeiten, könnten statt den verwendeten realistischen Szenarien, künstliche Modelle erzeugt und transformiert werden, und einzelne Merkmale über die Messungen variieren, während die restlichen Merkmale konstant gehalten werden. 67

82 5. Evaluation Tabelle 5.3.: Messergebnisse der Ausführung der Transformation Szenario Mittlere Ausführungszeichung Standardabwei- (Sekunden) Bookstore 0,9985 0,049 JPetStore 1,177 0,043 Kundenportal 2,2608 0,032 SPECjEnterprise 4,9192 0, mittlere Ausfuehrungszeit (s) bookstore jpetstore kundenportal specj mittlere Ausfuehrungszeit (s) bookstore jpetstore kundenportal specj Anzahl Komponenten Anzahl Signaturen 6 6 mittlere Ausfuehrungszeit (s) bookstore jpetstore kundenportal specj mittlere Ausfuehrungszeit (s) bookstore jpetstore kundenportal specj Anzahl CallingRelationships Anzahl Wertpaare Abbildung 5.5.: Zusammenhang zwischen beschreibenden Metriken und Ausführungszeiten 68

83 5.4. Verwandte Arbeiten 5.4. Verwandte Arbeiten Der in dieser Arbeit vorgestellte Ansatz ist verwandt mit der Extraktion von Performance- Modellen durch statische Analyse (Abschnitt 5.4.1) und dynamische Analyse (Abschnitt 5.4.2), mit Ansätzen zum modellbasierten Software Performance Engineering und der Transformation von entsprechenden Modellen (Abschnitt 5.4.3) Statische Analyse Es existieren diverse Ansätze zur Extraktion von Modellen bestehender Softwaresysteme durch statische Analyse. Chouambe et al. [2008] beschreiben ein Verfahren zur Rekonstruktion von Modellen komponentenbasierter Softwarearchitekturen durch Analyse von Quelltext. Es handelt sich um einen halbautomatischen iterativen Prozess der Komponenten anhand von Quelltext-Metriken, wie z.b. Kopplung oder Abstraktheit, extrahiert. Um das Modell in der nächsten Iteration zu verfeinern, werden am Ende jeder Iteration die erkannten Komponenten durch einen Experten bewertet. Fokus dieser Arbeit ist die Erkennung von Komponenten durch statische Analyse. Die entstehenden Modelle sind Instanzen des PCM -Metamodells. Der Ansatz reicht für die Performance-Vorhersage auf Grundlage der erzeugten Modelle nicht aus, da das interne Verhalten von Komponenten nicht analysiert wird. Das Verfahren von Chouambe et al. [2008] wird durch die Arbeit von Kappler et al. [2008] ergänzt. Durch statische Analyse wird das Verhalten der Komponenten in Form von RDSEFFs (siehe Abschnitt 2.4) rekonstruiert und das mit dem Ansatz von Chouambe et al. [2008] gewonnene PCM -Modell angereichert. Das vorgestellte Werkzeug Java2PCM ermöglicht es den Kontrollfluss von Komponenten durch Analyse des Quelltextes auf RD- SEFFs abzubilden. Java2PCM erkennt Fallunterscheidungen, interne Aktionen sowie den Aufruf von externen (aus Sicht der betrachteten Komponente) Operationen. Der Ressourcenbedarf von internen Aktionen bzw. dem Aufruf externer Operationen kann nicht durch Java2PCM ermittelt werden. Diese Informationen müssen entweder manuell nachgetragen oder durch dynamische Analyse ermittelt werden. 69

84 5. Evaluation Dynamische Analyse Die dynamische Analyse von Softwaresystemen zielt vor allem auf die Extraktion des Laufzeit-Verhaltens durch Beobachtung des Systems. Die Extraktion von UML-Sequenzdiagrammen durch dynamische Analyse von verteilten Java-Programme beschreiben Briand et al. [2006]. Die Beobachtung von zu analysierenden Operation geschieht durch deren Instrumentierung mittels AOP (Aspektorientierte Programmierung). Durch das Ausführen des instrumentierten Softwaresystems entstehen dann sogenannte Szenariodiagramme, unvollständige UML-Sequenzdiagramme, die lediglich einzelne Ausführungspfade beschreiben. Die entstandenen Szenariodiagramme werden zu (vollständigen) UML-Sequenzdiagrammen vereinigt. Der vorgestellte Ansatz adressiert nicht explizit komponentenbasierte Softwaresysteme. Die Erzeugung von UML-Sequenzdiagrammen ermöglicht nicht den Einsatz von Werkzeugen zur Performance-Vorhersage wie beispielsweise SimuCom (siehe Abschnitt 2.4). Brosig et al. [2011] beschreiben die Rekonstruktion von PCM -Modellen durch dynamische Analyse von komponentenbasierten Systemen. Der Ansatz ermöglicht die Analyse von Java EE (Java Enterprise Edition) Anwendungen, die auf dem Oracle WebLogic Server (WLS) laufen. Das WebLogic Diagnostics Framework (WLDF) erlaubt die Instrumentierung von Java EE Anwendungen. Die Extraktion der Architektur und des Laufzeit-Verhaltens in Form von RDSEFFs erfolgt auf Grundlage der zur Laufzeit erhoben Daten. Auch der Ressourcenbedarf von Operationen kann so ermittelt werden, so dass vollständige PCM -Instanzen erzeugt werden, die mit den entsprechenden Werkzeugen simulierbar sind. Der Ansatz von Israr et al. [2005] verfolgt einen ähnlichen Ansatz. Anhand von Trace- Daten aus Monitoring-Werkzeugen werden LQN -Modellinstanzen erzeugt Transformation von Performance Modellen Während für PCM -Modelle vor allem Werkzeuge zur Simulation zur Verfügung stehen, gibt es für LQN -Modelle Werkzeuge für deren analytische Lösung. Koziolek und Reussner [2008] beschreiben eine Modelltransformation von PCM -Modellen in LQN - Instanzen, mit dem Ziel die LQN -Werkzeuge zum analytischen Lösen nutzen zu können. Zusammen mit der in der vorliegenden Arbeit vorgestellten Transformation von SLAstic-Modellen in PCM -Instanzen ergeben sich neue Möglichkeiten des Werkzeugeinsatzes durch Verkettung der Transformationen. 70

85 5.4. Verwandte Arbeiten Das UML Profile for Schedulability, Performance, and Time (SPT) ergänzt klassische UML-Modelle um Performance-Annotation. Petriu und Woodside [2004] beschreiben die Transformation von SPT-Instanzen in eine Zwischenrepräsentation, nämlich das Core Scenario Model (CSM). Das CSM ist auf eine einfache Transformierbarkeit in Performance-Modelle, wie z.b. LQN ausgelegt. 71

86

87 6. Fazit In diesem Kapitel werden die Ergebnisse der vorliegenden Arbeit zusammengefasst (Abschnitt 6.1), die Erreichung der in Abschnitt 1.2 definierten Ziele und die Auswahl von Technologien diskutiert (Abschnitt 6.2) sowie Ansatzpunkte für zukünftige Arbeiten aufgezeigt (Abschnitt 6.3) Zusammenfassung Transformation von SLAstic-Modellen in PCM-Modelle In dieser ersten Phase wurde eine Transformation von SLAstic-Modellen in PCM -Modelle entwickelt. Zunächst standen strukturelle Eigenschaften bzw. statische Aspekte der Modelle im Mittelpunkt. Gemeinsamkeiten und Unterschiede der beiden beteiligten Metamodelle wurden herausgearbeitet. Daraufhin wurde die Transformation in ATL implementiert. Außerdem entstanden in dieser Phase eine Java-Integration des Transformationsprogrammes sowie ein Shell-Skript zur Ausführung der Transformation. Extraktion von RDSEFFs und UsageModels Am Anfang dieser Phase stand zunächst eine ausgiebigere Planung der Möglichkeiten zur Extraktion dynamischer Aspekte der Modelle. Es stellte sich heraus, dass das SLAstic-Metamodell um entsprechende Aspekte ergänzt werden muss. Hierzu wurden verschiedene Varianten diskutiert und schließlich die in Kapitel 4 beschriebene Erweiterung des SLAstic-Metamodells um das UsageModel vorgenommen. Anschließend wurden darauf aufbauend weitere Transformationsschritte entwickelt und implementiert. Evaluation Abschließend wurde das entstandene Transformationsprogramm auf seine Eignung für den Einsatz im SLAstic-Framework untersucht. Die Ausführungszeit der Transformation 73

88 6. Fazit für Modelle von Softwaresystemen unterschiedlichen Umfangs wurde gemessen und mit Metriken zur Beschreibung der Modelle gegenübergestellt Diskussion Erreichung der Ziele Z1 Erstellung benötigter Modelltransformationen Ziel war zum einen die Untersuchung geeigneter Metamodelle zur Performance- Vorhersage sowie die Implementierung entsprechender Transformationen. Die Wahl fiel auf die Implementierung der Transformation in PCM -Modelle, da die Existenz einer Transformation von PCM -Modellen in LQN -Modelle die Verwendung eines weiteren geeigneten Metamodells erlaubt. Die Transformation von SLAstic- Modellinstanzen in PCM -Modelle wurde erfolgreich entwickelt und implementiert. Dieses Ziel entwickelte sich aufgrund des Umfangs der nötigen Arbeit in diesem Zusammenhang zum Schwerpunkt der vorliegenden Arbeit. Z2 Implementierung der Komponente PerformancePredictor Die Komponente zur Performance-Vorhersage wurde implementiert und die entstandene Transformation integriert. Es wurde gezeigt, dass sich auf diese Weise zur Laufzeit das aktuelle SLAstic-Modell des durch SLAstic verwalteten Systems transformieren lässt. Allerdings wird die Transformation bisher nur bei Beendigung des PerformancePredictor ausgeführt, ohne dass das entstehende Modell danach weiter verarbeitet wird. Eine Untersuchung des richtigen Zeitpunktes, zum Anstoßen der Transformation und das Simulieren der entstandenen Modelle, steht aus. Z3 Evaluation der Performance-Vorhersagen mittels Testszenarien Da das Simulieren der PCM -Modelle nicht mehr in die PerformancePredictor-Komponente integriert werden konnte, blieb auch die Evaluation von Performance-Vorhersagen aus. Stattdessen wurde die Eignung des Einsatzes des Transformationsprogrammes im SLAstic-Framework mittels verschiedener Szenarien evaluiert. Z4 Evaluation der Performance-Vorhersagen unter Berücksichtigung unterschiedlicher Anwendungsfälle Auch die Bearbeitung einer Evaluation im Kontext verschiedener Anwendungsfälle 74

89 6.2. Diskussion blieb aufgrund der fehlenden Integration der Simulation der Performance-Modelle in das SLAstic-Framework aus. Auswahl der Technologien Die Wahl einer Transformationstechnologie, die auf EMF aufsetzt, war aufgrund der großen Verbreitung von EMF und dessen Verwendung im SLAstic-Framework richtig und praktisch alternativlos. Für die Wahl einer auf EMF basierenden Transformationssprache hätte es aber verschiedene Alternativen gegeben. Außerdem hätte die Transformation ohne eine spezielle Sprache zur Modelltransformation in Java, unter Verwendung der EMF-API, implementiert werden können. Aufgrund des für Modelltransformationen geeignet empfundenen deklarativen Ansatzes und der vergleichsweise umfangreichen Dokumentation fiel die Wahl auf ATL. Diese Entscheidung stellte sich als eine gute Wahl heraus, wenngleich im Folgenden auch einige negative Erfahrungen mit ATL beschrieben werden sollen. Die Dokumentation von ATL erwies sich als teilweise unpräzise und lückenhaft. Allerdings stellte sich heraus, dass die aktive Community im Eclipse M2M-Forum 1 auch komplexe Fragen zu ATL innerhalb weniger Tage kompetent beantwortet. Auch die ATL- Entwickler sind dort aktiv. So wurde eine Frage mit dem Vorschlag zur Verwendung eines zwar vorhandenen, aber undokumentierten Sprachkonstrukts beantwortet. Die Fehlersuche in ATL-Programmen erwies sich als teilweise schwierig. Da ATL auf Java und verschiedenen Technologien aus dem Java-Umfeld fußt, sind Fehlermeldungen oft Java Stack-Traces, die Ausnahmen in den Begriffen verwendete Technologien beschreiben, aber die Fehler nicht auf der Ebene des eigentlichen ATL-Programms ausdrücken. Auch diverse Bugs in der ATL-Implementierung waren ein Problem für die Implementierung der Transformation. In diesen Fällen ließen sich aber, auch mit Hilfe des genannten Forums, Workarounds finden. Trotzdem ist die Verwendung von ATL einer Implementierung der Transformation in Java vorzuziehen, da das Programmieren auf Ebene der Modelle die Entwicklung deutlich angenehmer macht, den Aufwand verringert und der Code durch Verwendung der Begriffe der beteiligten Metamodelle sehr gut lesbar ist. 1 siehe 75

90 6. Fazit 6.3. Zukünftige Arbeit Ansatzpunkte für zukünftige Arbeiten im Kontext der vorliegenden Arbeit könnten sich in folgenden Vorschlägen finden lassen: Eine systematische Evaluation des Transformationsprogrammes (vgl. Abschnitt 5.3). Die Extraktion der ResourceDemands für die ExternallCallActions und InternalActions innerhalb der extrahierten RDSEFFs fehlt für die Simulation der PCM - Modelle mit aussagekräftigen Ergebnissen. Eine Untersuchung des verwendeten Ansatzes von Brosig et al. [2011] kann ein geeigneter Ausgangspunkt sein. Die Ergänzung der Transformation um die Berücksichtigung der NetworkLinks zwischen Containern. Interessant ist hier vor allem die Extraktion zugehöriger Delays, analog zu der Extraktion von ResourceDemands. Die Fertigstellung der Komponente PreformancePredictor mit dem Anstoßen des Simulators emphslastic.sim (vgl. Abschnitt 6.2). Die Evaluation der Genauigkeit der durch die Transformation entstehenden Modelle nach den in den Kapiteln 3 und 4 entwickelten Verfahren. Die ausgebliebene Evaluation der Performance-Vorhersagen durch Simulation der PCM -Modelle (vgl. Z3 und Z4 in Abschnitt1.2 und 6.2). Die Untersuchung der Eignung des in Kapitel 4 beschriebenen Verfahrens zur Erzeugung von OpenWorkloads für die PCM-UsageModels. Die Verkettung der entstandenen Transformation mit der in Koziolek und Reussner [2008] beschriebenen Transformation von PCM -Modellen in LQN -Instanzen. 76

91 A. Anleitung: Ausführung der Transformation von SLAstic-Modellen in PCM-Modelle Die Transformation von SLAstic-Modellen in PCM -Modelle kann auch außerhalb eines laufenden SLAstic-Systems angewendet werden. Dies geschieht entweder durch das Starten der Transformation aus Eclipse heraus (siehe Abschnitt A.1.1) oder durch das Starten der Transformation als Kommandozeilenanwendung (siehe Abschnitt A.1.2). A.1. Ausführen der Transformation A.1.1. Eclipse Launch Configuration Die Transformation kann aus einem Eclipse mit installiertem ATL-Plugin gestartet werden (z.b. Eclipse Helios Modeling Tools 1 ). Um eine entsprechende Run Configuration zu erstellen, klickt man mit der rechten Maustaste die Datei slastic2pcm.atl im Verzeichnis transformation des SLAstic-Projekts an und wählt dort Run as Run Configurations. In dem Dialog, der daraufhin erscheint (siehe Abbildung A.1), erzeugt man durch Doppelklick auf ATL Transformation eine neue Run Configuration. Im Abschnitt ATL Module wählt man die Datei slastic2pcm.atl aus dem Workspace aus. Daraufhin erscheinen in dem Dialog zusätzliche Abschnitte zur Konfiguration der Ein- und Ausgabemodelle. Im Abschnitt Source Models wählt man die Datei, die das zu transformierende serialisierte SLAstic-Modell beinhaltet. Im Abschnitt Target Models müssen Pfade für die Ausgabe der verschiedenen PCM -Submodelle konfiguriert werden. Für die Kompatibilität mit der PCM -Bench ist es hier zwingend notwendig, dass die 1 Download siehe s-incubating-components/heliossr1 77

92 A. Anleitung: Ausführung der Transformation von SLAstic-Modellen in PCM-Modelle Abbildung A.1.: Eclipse Konfiguration 78

93 A.1. Ausführen der Transformation Dateiendungen der verschiedenen PCM -Submodelle genau den jeweiligen Modellbezeichnern entsprechen (resourcetype, repository, etc.). Vgl. hierzu Abbildung A.1. Damit die Transformation korrekt ausgeführt werden kann, muss im Reiter Advanced die Option Allow inter-model references aktiviert werden. Es bietet sich zusätzlich an, die Optionen Clear console before launch und Print execution times on console zu aktivieren, um eine Rückmeldung über die Beendigung der Transformation zu erhalten (vgl. Abbildung A.2). Durch einen Klick auf den Run-Button wird die Transformation gestartet. A.1.2. Kommandozeile Alternativ kann die Transformation auch ohne Eclipse von der Kommandozeile mit dem Skript slastic2pcm.sh gestartet werden. Listing A.1 zeigt die Hilfeausgabe des Skripts slastic2pcm.sh mit Hinweisen zu dessen Verwendung. Listing A.2 zeigt das Starten der Transformation für eine serialisierte SLAstic-Modellinstanz, welche aus den Dateien bookstore.slastic und bookstore.slasticusage besteht. Listing A.1: Verwendungshinweise des Skripts slastic2pcm.sh 1 usage : 2 org. t r u s t s o f t. s l a s t i c. p l u g i n s. ngu. t r a n s f o r m a t i o n. SlasticToPcmTranformation 3 h, help Print t h i s usage i n f o r m a t i o n 4 o, output <arg> P r e f i x f o r PCM output f i l e s 5 p, path <arg> Path f o r PCM model output f i l e s 6 s, system <arg> SLAstic system model i n s t a n c e input f i l e 7 u, usage <arg> SLAstic usage model i n s t a n c e input f i l e Listing A.2: Kommando zum Starten der Transformation 1. / s l a s t i c 2 p c m. sh s bookstore. s l a s t i c u bookstore. s l a s t i c u s a g e o bookstore 79

94 A. Anleitung: Ausführung der Transformation von SLAstic-Modellen in PCM-Modelle Abbildung A.2.: Zusätzliche Einstellungen 80

95 A.2. PCM-Bench A.2. PCM-Bench Um das erzeugte PCM -Modell mit der PCM -Bench zu verwenden, legt man in der PCM - Bench ein neues Projekt an und kopiert die PCM -Ausgabedateien in das entsprechende Projektverzeichnis. Wegen einem Bug 2 in ATL müssen noch eventuelle fehlerhafte Referenzen zwischen den einzelnen Submodellen angepasst werden. Dazu öffnet man die Dateien der einzelnen Submodelle mit einem Texteditor und prüft, ob in Referenzen auf Submodelle statt dem korrekten Dateinamen new-model angegeben ist und ersetzt dies gegebenenfalls durch den Dateinamen des referenzierten Submodells. Die Modelle lassen sich dann mit den dafür vorgesehenen Editoren der PCM -Bench öffnen. Zum Beispiel zeigt Abbildung A.3 ein aus einem SLAstic-Modell erzeugtes Repository im Repository Model Editor. Durch Rechtsklick auf eines der Submodelle und Auswahl von Initialize Diagram lassen sich für einige Submodelltypen Diagramme erzeugen. Zur besseren Übersicht müssen dort die verschiedenen Diagrammbestandteile manuell umgeordnet werden. Abbildung A.4 zeigt ein zu dem Allocation Model zugehöriges Allocation Diagram. 2 Siehe Eclipse Bugzilla 81

96 A. Anleitung: Ausführung der Transformation von SLAstic-Modellen in PCM-Modelle Abbildung A.3.: Repository Model Editor 82

97 A.2. PCM-Bench Abbildung A.4.: Allocation Diagram 83