dynamicanalysisof.netapplications forarchitecture-basedmodel...

Christian-Albrechts-University KielDepartment of Computer Science

Software Engineering Group

Diploma Thesis

Dynamic Analysis of .NET Applicationsfor Architecture-Based ModelExtraction and Test Generation

Felix Magedanz ([email protected])

October 15, 2011

Advised by: Prof. Dr. Wilhelm HasselbringDipl.-Inform. André van Hoorn

Abstract

Extending the Kieker framework [Software Engineering Group, University of Kiel 2011]to allow comprehensive dynamic analysis of applications developed with Microsoft’s.NET framework is the fundamental approach taken by this thesis. Furthermore, thepracticality and robustness of the presented extension—which we call Kieker.NET—hadto be proved not only by controlled experiments in the lab, but also by an in-depth casestudy on a real-world software system.We achieved the first goal by developing a .NET-based Kieker framework that does

not just simply co-exist with its Java-counterpart, but rather cooperates with it. Weemployed a .NET/Java bridging technology to make Kieker’s core available to .NET,and ported only as few Java classes as possible. Our monitoring probes are based onPostsharp, a powerful AOP implementation for the .NET framework.With running examples throughout the development stages of our framework, as well

as a comprehensive overhead analysis conducted with a micro-benchmark, we showedthat Kieker.NET is capable of performing almost all tasks in the .NET programmingenvironment that can be done with Kieker’s original monitoring components for Java-based applications.An extensive case study on a complex real-world software system provided by a major

German finance institute, including multiple extracted architecture- and trace-basedmodels and a macro-benchmark, substantiated our findings from the lab studies.

iii

Contents

1. Introduction 11.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Foundations 52.1. Dynamic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2. Kieker Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3. Microsoft .NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . 82.4. Bookstore Sample Application . . . . . . . . . . . . . . . . . . . . . . . . 92.5. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. .NET Integration of Kieker 173.1. .NET Integration Solutions for Kieker . . . . . . . . . . . . . . . . . . . . 173.2. Bridging Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3. .NET Integration with JNBridge . . . . . . . . . . . . . . . . . . . . . . 24

4. Dynamic Analysis With Kieker.NET 314.1. Monitoring Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2. Manual Instrumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3. Monitoring of the Bookstore Sample Application . . . . . . . . . . . . . . 36

5. AOP-Based Monitoring With Kieker.NET 395.1. Aspect-Oriented Programming in .NET . . . . . . . . . . . . . . . . . . . 395.2. Kieker.NET Implementation with Postsharp . . . . . . . . . . . . . . . . 425.3. Aspect Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

v

Contents

6. Overhead Evaluation 556.1. Causes of Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.2. Experiment Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.3. Experiment Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7. Case Study 677.1. Nordic Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677.2. Code Instrumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.3. Dynamic Analysis of Nordic Analytics . . . . . . . . . . . . . . . . . . . 727.4. Architecture-Based Model Extraction . . . . . . . . . . . . . . . . . . . . 727.5. Overhead Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8. Conclusion 878.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898.3. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A. Kieker.NET Visual Studio Solution 93A.1. The Bookstore Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93A.2. The Kieker Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

B. JNBridge Related Configuration Files and Scripts 109B.1. Kieker Proxy Generation with JNBProxy . . . . . . . . . . . . . . . . . . 109B.2. Monitoring Configuration Files . . . . . . . . . . . . . . . . . . . . . . . 110

Bibliography 113

Acknowledgments 117

Declaration 119

vi

List of Figures

2.1. Overview of the Kieker framework components. . . . . . . . . . . . . . . 72.2. Microsoft .NET framework components. . . . . . . . . . . . . . . . . . . 92.3. Structure and dynamics of the Bookstore sample application. . . . . . . . 112.4. DynaMod work packages. . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5. Basic principles of MDSD. . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6. Architectural domains and modernization drivers. . . . . . . . . . . . . . 142.7. ADM horseshoe model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1. Schematic diagram of a re-implementation of Kieker in .NET. . . . . . . 183.2. Schematic diagram of a Kieker client/server architecture. . . . . . . . . . 193.3. Schematic diagram of Kieker for .NET employing a bridging solution. . . 203.4. JNBBridge communication features. . . . . . . . . . . . . . . . . . . . . . 233.5. Kieker.NET as a new framework component of Kieker. . . . . . . . . . . 253.6. JNBridge installation directory structure. . . . . . . . . . . . . . . . . . . 263.7. GUI version of JNBProxy. . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1. Class diagram of the instrumented Bookstore sample application. . . . . 334.2. Monitored execution of instrumented Bookstore sample application. . . . 364.3. Kieker JVM console output. . . . . . . . . . . . . . . . . . . . . . . . . . 374.4. Kieker monitoring log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1. Postsharp’s post-compile-time aspect weaver. . . . . . . . . . . . . . . . . 405.2. Class diagram of all Kieker.NET classes. . . . . . . . . . . . . . . . . . . 435.3. Multithreading problems with bridged ControlFlowRegistry Java class. . 47

6.1. Stages I and II of the experiment design. . . . . . . . . . . . . . . . . . . 59

vii

List of Figures

6.2. Stage III. Quantification of monitoring overhead induced by JNBridge andbridged Java-side Kieker monitoring controller (with Kieker monitoringdisabled). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.3. Stage IV. Quantification of monitoring overhead induced by bridged Java-side Kieker monitoring classes. . . . . . . . . . . . . . . . . . . . . . . . . 62

6.4. Micro-benchmark overall performance analysis results. . . . . . . . . . . 63

7.1. Nordic Analytics component dependency graph. . . . . . . . . . . . . . . 707.2. Manually created Nordic Analytics sequence diagram. . . . . . . . . . . . 757.3. Nordic Analytics assembly component dependency graph (Job 7). . . . . 767.4. Nordic Analytics assembly operation dependency graph (Job 7). . . . . . 777.5. Nordic Analytics aggregated assembly call tree (Job 7). . . . . . . . . . . 787.6. Nordic Analytics assembly component dependency graph (Job 29). . . . . 797.7. Nordic Analytics assembly operation dependency graph (Job 5). . . . . . 807.8. Nordic Analytics assembly component dependency graph (Jobs 1 to 29). 817.9. Nordic Analytics macro-benchmark overall performance analysis results. . 837.10. Detailed Nordic Analytics performance analysis results. . . . . . . . . . . 84

A.1. Bookstore Visual Studio project structure. . . . . . . . . . . . . . . . . . 93A.2. Visual Studio project structure of the .NET-based Kieker. . . . . . . . . 94A.3. Kieker.NET Visual Studio configuration. . . . . . . . . . . . . . . . . . . 95

viii

Listings

4.1. Instrumented Bookstore class. . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1. Transformed method after aspect application. . . . . . . . . . . . . . . . 415.2. Aspect Compile-time initialization method. . . . . . . . . . . . . . . . . . 445.3. Aspect runtime initialization method. . . . . . . . . . . . . . . . . . . . . 445.4. OperationExecutionAspect’s OnEntry() advice. . . . . . . . . . . . . . . 455.5. OperationExecutionAspect’s OnExit() advice. . . . . . . . . . . . . . . . 455.6. Method-level aspect application. . . . . . . . . . . . . . . . . . . . . . . . 485.7. Monitoring log entry for instrumented Catalog.GetBook() method. . . . . 495.8. Class-level aspect application. . . . . . . . . . . . . . . . . . . . . . . . . 495.9. Monitoring log entry for class-level attributed Bookstore sample application. 505.10. Assembly attribute for assembly-level aspect application. . . . . . . . . . 505.11. Assembly attributes for managed assembly-level aspect application. . . . 515.12. Batch file to apply a given aspect to an assembly. . . . . . . . . . . . . . 525.13. Configuring the aspect targets programmatically. . . . . . . . . . . . . . 52

6.1. Performance analysis benchmark (excerpt). . . . . . . . . . . . . . . . . . 576.2. The monitored class containing the single monitored method with param-

eterized (operation) response time. . . . . . . . . . . . . . . . . . . . . . 586.3. The “empty” dummy aspect. . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.1. Aspect multicast attributes and filters, leading to 2.836 instrumentedmethods of Nordic Analytics. . . . . . . . . . . . . . . . . . . . . . . . . 70

A.1. OperationExecutionAspect class. . . . . . . . . . . . . . . . . . . . . . . 96A.2. OperationExecutionAspectProvider class. . . . . . . . . . . . . . . . . . . 101A.3. MonitoringControllerWrapper class. . . . . . . . . . . . . . . . . . . . . . 102A.4. ControlFlowRegistry class. . . . . . . . . . . . . . . . . . . . . . . . . . . 103

ix

Listings

B.1. Proxy generation BATCH script. . . . . . . . . . . . . . . . . . . . . . . 109B.2. Kieker proxy class list text file that defines which Java classes to expose. 109B.3. Batch file to start Kieker JVM. . . . . . . . . . . . . . . . . . . . . . . . 110B.4. jnbcore properties file for JNBridge (TCP). . . . . . . . . . . . . . . . . . 110B.5. jnbcore properties file for JNBridge (HTTP). . . . . . . . . . . . . . . . . 110B.6. jnbcore properties file for JNBridge (shared memory, only needed for

Java/.NET directed communication). . . . . . . . . . . . . . . . . . . . . 111B.7. .NET application configuration file for TCP/Binary communication with

JNBridge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111B.8. .NET application configuration file entry for shared memory communica-

tion with JNBridge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

x

List of Tables

3.1. Comparison of bridging solutions. . . . . . . . . . . . . . . . . . . . . . . 243.2. Exposed Kieker classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.1. Stage I experiment results. . . . . . . . . . . . . . . . . . . . . . . . . . . 636.2. Micro-benchmark overall performance analysis results. . . . . . . . . . . 636.3. Micro-benchmark overhead results. . . . . . . . . . . . . . . . . . . . . . 64

7.1. Code statistics of Nordic Analytics. . . . . . . . . . . . . . . . . . . . . . 687.2. Detailed monitored Job statistics. . . . . . . . . . . . . . . . . . . . . . . 737.3. Nordic Analytics macro-benchmark overall performance analysis results. . 837.4. Nordic Analytics macro-benchmark overhead results. . . . . . . . . . . . 83

xi

1. Introduction

1.1. Motivation

In the world of large business applications, software systems often have a lifespan notonly of a few years, but a few decades. They become legacy systems when they signifi-cantly resist modification and evolution [Brodie and Stonebraker 1995]. However, legacysystems are typically the backbone of an organization’s information flow and the mainvehicle for consolidating business information [Bisbal et al. 1999]. Given these charac-teristics, in addition to the fact that the acquisition costs or development expenses—together with the costs that would emerge in case of a transition to another softwaresystem—can be extremely high, legacy systems are mission critical [Bennett 1995].

Retaining the maintainability of these “critical assets” [Comella-Dorda et al. 2000]by continuous and sustainable modernization is the approach taken by the DynaModProject (DynaMod) [van Hoorn et al. 2011], an ongoing joint research project of theb+m Informatik AG, the University of Kiel, and two associated companies, Dataportand HSH Nordbank AG. The focus of DynaMod lays on techniques for Model-DrivenModernization (MDM) of software systems. The innovative aspect of DynaMod is thatstatic and dynamic analysis are used for reverse engineering of architectural and usagemodels [van Hoorn et al. 2011]. These models, together with semantic augmentation,are the foundation for subsequent generative forward engineering steps and tests.

As one of the envisioned case study systems of DynaMod is a function library devel-oped with the Microsoft .NET framework, this diploma thesis will be conducive to andtherefore part of the DynaMod project (for a more detailed introduction to DynaModsee Section 2.5.1).

The goals of this thesis are presented in the next Section 1.2. An overview of thedocument structure is given in Section 1.3.

1

1. Introduction

1.2. Goals

The context of this work is given by the DynaMod project. As indicated by the title,its main purposes are (1) architecture-based model extraction and (2) test generationfor applications developed with .NET, and therefore running on Microsoft Windowsoperating systems. The following goals will be substantial for accomplishing (1) and (2)and determine the steps of the approach of this work, which are loosely based on someof the work packages defined by DynaMod.

1.2.1. Technical Instrumentation of .NET

The first goal is enabling .NET-based applications to be dynamically analyzed with theKieker framework (Kieker) [van Hoorn et al. 2009]. For more details on Kieker seeSection 2.2. As of today, Kieker is currently restricted to Java-based systems only.Performance—or the absence of overhead caused by the presented solutions—will be

a main concern of the tasks corresponding to this goal, as time related analysis, e.g.,monitoring of the execution time of a method call, would be drastically affected byoverhead due to utilized frameworks, bridging solutions or other ways of frameworkintercommunication. The same holds for monitoring activities in “live” environments,where delays are often not tolerable.Another important feature of Kieker is instrumentation by employing techniques based

on aspect-oriented programming (AOP) [Kiczales et al. 1997]. This allows monitoring(e.g., measuring the response times of certain method calls) without actually modifyingthe source code. This feature must be provided for .NET applications as well.

1.2.2. Extraction of Architectural and Usage Models

Developing techniques based on DynaMod and other similar approaches for extract-ing architecture-based models from .NET-based systems and enriching them with user-behavior data is the second goal of this thesis. Selecting appropriate meta-models andgenerating usage models with data obtained by dynamic analysis will be the essentialtasks. As Kieker already supports different types of models to be generated from dataobtained by monitoring, accomplishing the first goal (i.e., instrumentation) also (par-tially) accomplishes this one.

2

1.3. Document Structure

1.2.3. Test Generation

Developing means for test automation for .NET-based systems is the third goal. Thetests should be based on extracted models obtained by the previous steps, and must becompatible with a testing framework to support the required test automation to testeven large systems. The generated tests should also be generic and therefore easilyadoptable to another system based on the same domain model—which is most likelythe same system but modernized with techniques of model-driven modernization in thiscontext.

1.2.4. Evaluation

The final goal is a proof of concept with multiple .NET-based applications, whichwill indicate the practicality and efficiency of the developed methods and hopefully—presumably after several reiterations—contribute to the success of the “mother project”DynaMod. The main evaluation will be based on one of the case study systems ofDynaMod, namely Nordic Analytics, the C#-based function library mentioned in themotivation to this document. HSH Nordbank AG uses this library internally for assess-ment and risk control of finance products.

1.3. Document Structure

The structure of this document is described in the following list.

Chapter 2 briefly introduces the foundations of this work and presents some technolo-gies that are crucial for understanding the following chapters. We also hint torelated work.

Chapter 3 focuses on the .NET integration of Kieker. Different approaches are pre-sented, followed by our developed solution.

Chapter 4 shows how the newly integrated Kieker can be used in the .NET framework.With the results of the previous chapter, basic dynamic analysis of .NET applica-tions is already possible, and its core functionality will be illustrated with the helpof a running example .

3

1. Introduction

Chapter 5 deals with the employment of techniques based on aspect-oriented program-ming to allow for a more elegant way of integrating monitoring logic into a systemunder observation.

Chapter 6 introduces a staged micro-benchmark that will be used for a comprehensiveevaluation of the overhead that is caused by our monitoring framework.

Chapter 7 presents a case study that hopefully will show the practicality and robustnessof our solutions. The case study system will also be used for a comprehensivemacro-benchmark.

Chapter 8 draws the conclusions of this thesis and gives an outlook to possible futurework that could be done to further improve dynamic analysis of .NET applicationswith Kieker.

4

2. Foundations

This chapter gives an overview of some of the prime methods and technologies thatwill be used and referenced throughout the thesis. After a short motivation to dynamicanalysis in Section 2.1, we introduce the Kieker framework for dynamic analysis inSection 2.2.Section 2.3 presents the basic concepts of Microsoft’s .NET framework, and Section 2.4

introduces a sample application that we use throughout this thesis. Finally, a shortoverview of related work is given in Section 2.5.

2.1. Dynamic AnalysisDynamic software analysis is performed by executing the software and analyzing it atruntime, therefore providing information about the runtime behavior of software systems.Advantages of this method compared to static analysis—with the latter being basicallysource code analysis—are usage profiling as well as the ability to obtain performancemeasurements. The significance of the findings may depend on the test input the softwareis executed with.In their recently published article, Cornelissen et al. [2009] reported on a systematic

literature survey with a research body of 4,795 articles that had been published between1999 and 2008. They systematically selected 176 articles for their comprehensive study.After analyzing and categorizing their selection, their main findings were

1. that a significant technical progress had been made in the past decade by puttinggreat effort into comparing and combining earlier techniques;

2. that the studied literature may overemphasize standard object-oriented systemsat the cost of more modern web applications, distributed software systems, andmultithreaded systems. They argue that dynamic analysis is especially suitablefor those systems;

5

2. Foundations

3. that comparisons and benchmarking should be considered more often as evaluationmethods than they currently are. Moreover, conducting controlled experiments istheir recommended evaluation procedure.

They also encourage researchers to make their tools publicly available, so that evaluationand verification is possible.

2.2. Kieker Framework

Dynamic analysis in the context of this thesis will be done with the Kieker framework[Software Engineering Group, University of Kiel 2011] by van Hoorn et al. [2009]. Kiekeris a monitoring framework that allows dynamic analysis of (Java-based) applications byproviding monitoring probes employing AspectJ, Java EE Servlet, Spring, and ApacheCXF technology.Kieker is actively developed and maintained by the Software Engineering Group at

the University of Kiel and, according to the description on the project website1, hasalready been used for monitoring and profiling in several distributed industry systemsof companies in the telecommunications and business sectors. Kieker is licensed underthe Apache License, Version 2.0, and located for download at SourceForge2.

2.2.1. Kieker Components

Kieker is composed of two main components, Kieker.Monitoring and Kieker.Analy-

sis (Figure 2.1). By dynamically analyzing an instrumented application, the monitoringcomponent creates monitoring records. These records (bundled in a monitoring log) canlater be read by the analysis component. The Kieker.TraceAnalysis plugin can beused to extract several different types of models and trace data visualization from themonitoring logs.

2.2.2. Concept

The starting point of all monitoring with Kieker is the concept of probes. Monitoringprobes are in some way integrated into a system under observance—Kieker provides

1http://se.informatik.uni-kiel.de/kieker/2http://sourceforge.net/projects/kieker/files/kieker/

6

http://se.informatik.uni-kiel.de/kieker/

http://sourceforge.net/projects/kieker/files/kieker/

2.2. Kieker Framework

Mo

nit

ori

ng

Rec

ord

sCurrent time

Memory/swap usage

CPU utilization

Operation execution

Resource utilization

<your monitoring record type>

Kieker.Monitoring

Per

iodi

c S

ampl

ing

JMX

In

terf

ace

Logg

ing

Tim

e S

ourc

e

Mo

nit

ori

ng

W

rite

rM

on

ito

rin

g

Co

ntr

olle

rM

on

ito

rin

g

Pro

be

Logg

ing

Ser

ia-

lizat

ion

Des

eria

-liz

atio

n

Mo

nit

ori

ng

R

eco

rd

Kieker.Analysis

Mo

nit

ori

ng

R

ead

er

An

alys

is /

Vis

ual

izat

ion

Plu

g-I

n

An

alys

is

Co

ntr

olle

r

Mo

nit

ori

ng

Wri

ters

Mo

nit

ori

ng

Pro

bes

/Sa

mp

lers

Tim

e S

ou

rces

File system

Database (SQL)

<your monitoring writer>

Asy

nchr

. writ

ers

Syn

cr.

System time (nanos)

<your time source>

Con

trol

-flo

wtr

acin

gSpring AspectJ

ServletCXF/SOAP

Manual instrumentation

<your interception technology>

Res

ourc

em

onito

ring

<your technology>

CPU utilization

Memory usage

Sig

ar

Ser

vlet

<your monitoring probe>

File system

Database (SQL)

Java Messaging Servcice (JMS)

Java Management Ext. (JMX)

Named pipe

<your monitoring reader>

File system

Named pipe

Real-time replayer

Mo

nit

ori

ng

Rea

der

s

<your visualization>

Sequence diagrams

Dependency graphs

Call graphs

Vis

ualiz

atio

n

Arc

hite

ctur

e re

cons

tr.

Pip

e an

d fil

ter

fram

ewo

rk

An

alys

is/V

isu

aliz

atio

n P

lug

-In

s

<your trace analysis>

Tra

ce a

naly

sis

<your reconstruction plug-in>

<your analysis plug-in/tool>

Java Messaging Servcie (JMS)

Java Management Ext. (JMX)

Figure 2.1.: Overview of the Kieker framework components [Software EngineeringGroup, University of Kiel 2011].

7

2. Foundations

several techniques for that—and collect and possibly preprocess monitoring data whenthe analyzed application is executed.The next element in Kieker’s “chain of command” is the monitoring controller. When

the probes are triggered, they interact closely with the monitoring controller. For exam-ple, the controller provides a time source that can be used for temporal measurementsby the probes. The data collected by the probes is passed to the controller as records(with OperationExecutionRecord being a prominent example in this work).To store the monitoring data, a monitoring log writer is employed by the monitoring

controller. The elected writer implementation (e.g., filesystem writer, database writer,or writers employing Java Management Extensions (JMX) and Java Messaging Service(JMS)) is responsible for serializing the data as so-called monitoring logs. As mentionedbefore, these logs are the foundation of all further analysis with the Kieker analysiscomponents.For more details on Kieker and how it can be used for continuous monitoring of

software services and comprehensive dynamic analysis, see the Kieker project website,van Hoorn et al. [2009], and the Kieker user guide by Ehmke et al. [2011].

2.3. Microsoft .NET Framework

Microsoft .NET3 is a programming framework that supports a wide range of program-ming languages. Applications developed with (and for) .NET target primarily computerswith Microsoft Windows operating systems, but other implementations exist as well.One special aspect of .NET is its capability to support language interoperability. A

function written in one of the supported languages can be used in any other supportedlanguage as well. The most common .NET languages are C++, C#, and VB.NET, butmany other compatible languages (for example J#, an implementation of Java) exist.Figure 2.2 shows the main components of the .NET framework. The core is the Com-

mon Language Infrastructure (CLI) with its Common Intermediate Language (CIL) andits (software-based) runtime environment system Common Language Runtime (CLR).Every application written in a supported language will be compiled into bytecode with

the CIL syntax. This bytecode can be executed in the software environment of the CLR.

3http://msdn.microsoft.com/netframework

8

http://msdn.microsoft.com/netframework

2.4. Bookstore Sample Application

VB.NET Code

J# Code

Common Language Infrastructure

C# Code

CommonIntermediate

Language

100100110100101110101010110101011101010101101010101001011010101111

Compiler

Compiler

Compiler

CommonLanguageRuntime

Figure 2.2.: Microsoft .NET framework components.

Microsoft also provides their Visual Studio, an Integrated Development Environment(IDE) that targets mainly .NET developers, currently available in the 2010 version.Visual Studio is a commercial product, but there is also an Express version available fordownload on the MSDN website for free. The initial release of .NET was in 2002, thecurrent release version is .NET 4.0.

2.4. Bookstore Sample Application

For having a convenient sample application for this work, we ported the Bookstoresample application introduced by Ehmke et al. [2011] to the .NET environment by re-implementing the classes in C#. The class diagram in Figure 2.3(a) shows the classesof the .NET-based Bookstore and lists the members of each class.Representing a customer facility to search for books (Bookstore), combined with

a customer relationship management system (CRM), the Bookstore sample applicationprovides a basic test setting for the development of our Kieker port to .NET. Most ofthe methods are just stubs, as there is no need to actually do something there for ourpurposes.The sequence diagram in Figure 2.3(b) and the operation dependency graph in Fig-

ure 2.3(c) illustrate the dynamics of the application. The sequence diagram shows a

9

2. Foundations

typical trace (i.e., the order in which a given set of methods calls each other) throughthe different classes. The operation dependency graph is augmented by the number ofcalls that are made when executing the sample application. On most of the edges this isthe number 10, because the main method of the BookstoreStarter class actually starts10 threads that execute the Request() method in parallel. This element has been addedto the Bookstore sample application to allow concurrency tests as well.

2.5. Related Work

2.5.1. The DynaMod Project: Dynamic Analysis for Model-DrivenSoftware Modernization

DynaMod4 is currently an active research project, which addresses model-driven mod-ernization of software systems. The project started with the beginning of 2011 andhas a two-year funding from the German Federal Ministry of Education and Research(BMBF). The Consortium that initiated the project consists of four members: the b+mInformatik AG as development partner and consortium leader, the University of Kielas scientific partner, and two associated companies, Dataport and HSH Nordbank AG.Dataport and HSH Nordbank AG provide the case study systems that are going tobe (partly) modernized and therefore be used to evaluate the techniques developed byDynaMod.The following key characteristics of the envisioned approach of DynaMod are listed in

the paper by van Hoorn et al. [2011]:

1. Combining static and dynamic analysis for extracting models of a legacy system’sarchitecture and usage profile.

2. Augmenting these models with information that is relevant to the subsequentarchitecture-based modernization steps.

3. Automatically generating implementation artifacts and test cases based on theinformation captured in the models.

Figure 2.4 shows a finer grained view on the work packages of DynaMod—aligned withthe horseshoe model for re-engineering. Based on static analysis, the first DynaMod work

4http://kosse-sh.de/dynamod/ (in German).

10

http://kosse-sh.de/dynamod/

2.5. Related Work

(a) Class diagram of the Bookstoresample application.

@4:..BookstoreStarter @3:..Bookstore @1:..Catalog @2:..Crm

Main()

Request(..)

SearchBook()

GetBook(..)

GetOffers()

GetBook(..)

(b) Sequence diagram of the Bookstore sample application.

<<assembly component>>@4:..BookstoreStarter

<<assembly component>>@3:..Bookstore

<<assembly component>>@2:..Crm

<<assembly component>>@1:..Catalog

Main() Request(..)1 SearchBook()10GetOffers()10

GetBook(..)10

10

$

1

9

(c) Assembly operation dependency graph of the Bookstore sample application.

Figure 2.3.: Structure and dynamics of the Bookstore sample application, followingEhmke et al. [2011].

11

2. Foundations

��

��

��

��

��

��

��

��

��

� ��

Figure 2.4.: DynaMod work packages [van Hoorn et al. 2011].

package (WP1) focuses on the extraction of architectural models. Appropriate meta-models will be developed by employing and extending standards defined by the ObjectManagement Group for Architecture-Driven Modernization (ADM, see Section 2.5.2).Supported programming platforms will be limited by those emerging from the evaluationcase studies provided by Dataport and HSH Nordbank AG.

The legacy system’s internal behavior and external usage profile are the concerns ofthe dynamic analysis (WP2). For more detail on dynamic analysis and the employedKieker framework see Section 2.2.

Definition of transformations (WP3) means developing transformation rules for thetranslation of enriched architecture-level models (i.e., models that describe the existingsystems) towards possible target architectures. ADM meta-models may serve for thesource models as well as the target models.

Code generation tasks (WP4) employ model-to-code transformation techniques intro-duced by Stahl and Völter [2006] with the Model Driven Software Development (MDSD)approach (see Figure 2.5 for the basic principles of MDSD). The modeling infrastruc-ture will be based on the Eclipse Modeling Platform (EMP)—which includes the former

12

2.5. Related Work

Figure 2.5.: Basic principles of MDSD: different methods of code “generation”.

oAW framework that has been co-developed by the DynaMod consortium member b+mInformatik AG.Based on usage models of the legacy system obtained by dynamic analysis, model-

based testing (WP5) utilizes appropriate testing tools—most probably the load test toolApache JMeter—for workload generation and testing of both the modernized and theoutdated system. This will allow comparison of quality properties like performance andreliability.The evaluation (WP6) of the developed methodology and tooling infrastructure will

be based on three case study systems from Dataport and HSH Nordbank AG. Theyare considered to be benchmark examples and representatives of modernization projectspending in practice.

2.5.2. Architecture-Driven Modernization

Architecture-Driven Modernization (ADM) is a collection of standards defined by theObject Management Group (OMG). Two White Papers [Ulrich and Khusidman 2007;Khusidman 2008] are provided at the OMG’s website that present a basic insight intothe purposes of ADM.Basically, ADM is the migration of an existing software system to a target (i.e., mod-

ernized) system by applying project-based incremental transformations to the underlyingarchitecture of that system. These projects can be located in the business domain, drivenby business related purposes (i.e., changes to business semantics or business processes),

13

2. Foundations

(a) Business & IT architecture domains. (b) Modernization drivers & trajectories.

Figure 2.6.: Architectural domains (a) and modernization drivers (b) [Ulrich and Khusid-man 2007].

Figure 2.7.: ADM horseshoe model [Ulrich and Khusidman 2007].

as well as in the IT domain, driven by modifications to the technical architectures. (SeeFigure 2.6).Historically, modernization projects focused on the transformation of technical archi-

tectures. The approach proposed by OMG is referred to as the ADM horseshoe model,as the knowledge curve of the transformational path resembles an upside down horseshoe(see Figure 2.7).Business architecture-driven modernization is by far the most complex transformation

in this model because it incorporates all three architectures. As synchronization of thetransformational paths must be both vertically and horizontally (i.e., in the business-to-physical implementation as well as existing-to-target), very little modernization work inthe business architecture-driven modernization has been effectively deployed according

14

2.5. Related Work

to Ulrich and Khusidman [2007]. This is supposedly because the mapping paradigmsbetween the architectures lack standardization. Among others, the Knowledge DiscoveryMeta-Model (KDM) [OMG 2010] and Software Metrics Meta-Model (SMM) [OMG 2009]are those standards defined by the OMG’s KDM Task Force to facilitate complex busi-ness architecture-driven modernization.

15

3. .NET Integration of Kieker

Dynamic analysis in the context of this thesis will be done with the Kieker framework.As Kieker is a Java framework, monitoring is currently restricted to Java-based systems.Enabling .NET-based applications to be dynamically analyzed with Kieker is the maingoal of this chapter.Section 3.1 deals with the assessment of different solutions to the problem of .NET

integration of Kieker. In Section 3.2 we present three (commercial) .NET/Java bridgingsolutions. The one most feasible for our implementation is then presented in detail inSection 3.3.

3.1. .NET Integration Solutions for KiekerThe first step of the technical instrumentation of .NET is the determination of the bestway to enable the monitoring logic of Kieker to be called out of the .NET programmingenvironment. Due to the design of the .NET framework, this would allow monitor-ing of applications written in all .NET programming languages (with C#, C++, andVB.NET being the popular ones). There are several possible solutions, with three beingdescribed in more detail in this section. Finally we present our approach based on ashort evaluation of the alternatives.

3.1.1. Alternative Approaches

The following paragraphs provide an overview of the diverse possible implementations,ordered by descending assumptive complexity of implementation.

Re-implementing Kieker in .NET

Copying all functionality by re-implementing Kieker in a .NET programming languagelike C# is one solution to the task of bringing the functional range of Kieker to .NET.

17


X86 compatible computer system(s)

JVM«library»kieker.jar

«executable»JavaApplication.jar

CLR«library»Kieker.dll

«executable»DotNetApplication.exe

Monitoring LogicMonitoring Logic

Figure 3.1.: Schematic diagram of a re-implementation of Kieker in .NET.

As C# is syntactically quite similar to Java, this approach would result in a more orless direct copy of Kieker’s classes and interfaces (Figure 3.1). Existing .NET frameworkscould be utilized to achieve the same range of application that is provided by the Javaplatform..NET applications execute in the Common Language Runtime (CLR) (see Section 2.3),

which is based on the same concept as Java’s Virtual Machine, so the expected runtimecharacteristics of a Kieker port for .NET could be expected to be much similar to thoseof its Java archetype.

Building a Client/Server Architecture

Another option is the employment of a communication method like web services forinteraction between a Kieker server (Java-based) and a rather lightweight—yet to bedeveloped—Kieker client based on a .NET programming language.Existing Kieker components could be extended to enable Kieker to act as a server

that “listens” to network ports and reacts to messages sent by the client, i.e., providinga web service. Possible messages could be the creation of a collection of monitoring data(called a record), a method execution time measurement, etc.

18

3.1. .NET Integration Solutions for Kieker



«executable»kiekerServer.jar

CLR«library»

KiekerClient.dll


Monitoring LogicMonitoring Logic

Communication

Figure 3.2.: Schematic diagram of a Kieker client/server architecture.

The communication interface could be defined by a machine-readable description ofthe operations provided by the web service, which is most commonly done with a WebService Description Language (WSDL).The client would basically provide an interface that is compatible with all applications

written in a programming language compatible with the target platform .NET (seeFigure 3.2 for a schematic diagram) and send relevant information to the server viamessages defined by the WSDL. In this case, the client would be more than just aKieker probe. At least all communication with the monitoring controller—which shouldprobably stay on the Java-side—must be handled here as well (see Section 2.2 for thebasic principles of Kieker’s components).

Employing a Bridging Solution

Several (mostly commercial) bridging solutions enable interoperability between .NETand Java by providing tools to wrap Java classes into .NET-compatible Dynamic-LinkLibraries (dll), which are the Java-archive (jar) equivalent of Windows Programming.The other direction (Java/.NET) is also possible in some cases. The wrapped classes,so called proxies, can be utilized by the target architecture as if they were native.

19




«library»javaSideRuntime.jar

CLR

«library»KiekerProxy.dll


Monitoring Logic

Monitoring Logic

TCP/IP *

«library»DotNetSideRuntime.dll

* or shared mem / SOAP

Figure 3.3.: Schematic diagram of Kieker for .NET employing a bridging solution.

Figure 3.3 gives an overview of the involved components when employing a bridge.In the case of our Kieker port, the KiekerProxy.dll library would be generated fromthe Kieker Java classes with the proxy generation tool provided by the bridge. TheDotNetSideRuntime.dll and javaSideRuntime.jar are runtime libraries that ship with thebridge and need to be accessible for the respective execution environments. Thus, allinter-process communication is managed by the bridge and mostly hidden from the user/programmer. Most of the solution’s communication is based on TCP/IP, but some alsosupport shared memory or even messaging based on web service protocols like SimpleObject Access Protocol (SOAP).

3.1.2. Evaluation

Re-implementing Kieker for .NET would probably be the “cleanest” solution, as noadditional overhead due to—in this case unnecessary—framework inclusion or commu-nication would influence or even falsify monitoring results. As of today, the Java-based

20

3.2. Bridging Solutions

source code of Kieker consists of about 50 Java classes that use different Java tech-nologies and frameworks. Mirroring all this functionality in .NET would be a verytime-consuming task. Another severe drawback of this solution would be the redun-dancy of the two code bases for Kieker (one for the Java platform and one for .NET)with basically the same functionality. This is the reason why we decided against theapproach of re-implementing Kieker.Even though extending Kieker to a client/server architecture looks like an appealing

solution, it is questionable whether (1) because of the performance requirements, the“client” to some extend would become a complete re-implementation of Kieker after all(at least of the monitoring part), and (2) considering the third option, the implementa-tion of a .NET-based client, alongside with the modifications to the original Java-basedKieker, would be worth the effort. As pointed out before, all communication would haveto be implemented and optimized from scratch to allow efficient client/server interac-tion. Bridging solutions claim to have all that “out-of-the-box”. One advantage of thedevelopment of a Kieker server and the corresponding communication interface wouldbe the re-usability of such a solution.The employment of a commercial bridging solution seems to be efficient and relatively

easy to implement, but its performance impact, i.e., the overhead that comes withbridging technologies, must be evaluated properly. As most of the existing bridgesare commercial, license costs must also be taken into consideration. Because of therather efficient impression of this approach, we decided to choose the employment of abridging solution for the technical instrumentation of .NET with Kieker. Structurally,the resulting .NET integration of Kieker can also be considered a “Kieker client”, as weimplement the probes on the target architecture, and all communication is taken careof by the bridging solution.


In this section we present three solutions to the .NET/Java interoperability problem. Af-ter giving a short overview of the considered solutions in Section 3.2.1, namely EZ JCom[Desiderata Software 2011], J-Integra.NET (J-Integra) [Intrinsyc Software International,Inc. 2011], and JNBridgePro (JNBridge) [JNBridge LLC. 2011a], we discuss our evalu-ation in Section 3.2.2.

21


3.2.1. Overview of Commercial Bridging Solutions

In general, .NET/Java bridging solutions can be divided into two classes, distinguishedby whether they target the Component Object Model COM interface (classic windowsprogramming, which is now largely superseded by .NET) or .NET directly.

EZ JCom

EZ JCom is a bridging solution that allows COM components to be called from Java,and likewise allows Java to be called from COM-aware languages such as the .NETlanguages. It provides a user interface for proxy generation and also has 64-bit support,but not in the evaluation version. There was no intrinsic support for .NET, but as COMcomponents are accessible in .NET, this would not have been critical.Aside from its relatively high license costs, the major drawback of EZ JCom was

its lack of documentation and its restricted evaluation version that would randomlyterminate the established bridge connection when utilized.

J-Integra

With J-Integra.NET and J-Integra COM, J-Integra provides two products that seem tofulfill our requirements. However, we evaluated only J-Integra.NET, as we are interestedin calling Java from the .NET environment.Like the evaluation version of EZ JCOM, the trial license of J-Integra.NET had the

limitation to perform a shutdown after two hours of continuous use. That was unac-ceptable for us, as we expected the monitoring sessions of our case study system to bemuch longer (which they certainly were).

JNBridge

JNBridge seemed to provide all functionality we needed. It aims directly at .NET/Javaintercommunication, can be integrated into a Kieker build process, and ships with acomplete reference documentation. The proxy generation tool of JNBridge has a userinterface version as well as a command line tool. JNBridge allows different ways of .NET/Java intercommunication. Figure 3.4 gives an overview of all configurable options. Formore information about .NET/Java intercommunication with JNBridge see Section 3.3.

22


Figure 3.4.: JNBBridge communication features [JNBridge LLC. 2011a].

23


Criteria EZ JCom J-Integra JNBridgeDocumentation - +/- +Actuality - - +Ease of use +/- +/- +GUI version + + +Build integration - + +Shared memory comm. + - +Unrestricted evaluation - - +License costs - - -

Table 3.1.: Comparison of bridging solutions.

3.2.2. Evaluation

Table 3.1 clearly identifies JNBridge as our “weapon of choice” for .NET/Java inter-operability. After evaluating JNBridge along with the alternatives, the comprehensiveand up-to-date documentation, the comparatively long history of regular software up-dates, and the ability to support allegedly fast shared memory communication lead tothe decision to employ JNBridge for .NET/Java intercommunication in the context ofour Kieker port.

3.3. .NET Integration with JNBridge

Enabling .NET applications to communicate with a Java system by simply “calling”Java methods can be done with JNBridge in a straightforward manner. As pointedout before, the documentation [JNBridge LLC. 2011b] and demos that come with thedistributed installation file give a good overview on how to start, but also have enoughdepth to allow more advanced application.We follow the introduction given in the Evaluation and Quick Start Guide [JNBridge

LLC. 2011c] to present the necessary steps for installation, configuration, and basicuse of JNBridge. The following information should be sufficient for understanding ourimplementation of Kieker.NET employing JNBridge. In the remainder of this section,all given examples cover .NET → Java directed communication (previously referred to as.NET/Java), i.e., .NET code that calls Java code through the JNBridge communication

24


Figure 3.5.: Kieker.NET as a new framework component of Kieker.

mechanism, as this is the only way we employ JNBridge for Kieker.NET. The otherdirection (Java → .NET) is also possible, but is not shown here.Our targeted result is an extension of the existing Kieker architecture, as shown in

Figure 3.5

3.3.1. Download and Installation

To download the latest version of JNBridge, one has to register with a valid emailaddress at the JNBridge web page1 to obtain a fully functional 30-day trial license andthe download link (more detail on JNBridge licensing, especially for open source projectssuch as Kieker, follows in Section 3.3.2).There are two different usage scenarios when installing JNBridge on a computer:

proxy generation and proxy use. Hence, as for JNBridge version 6.0 (Sept. 2011), eitherDevelopment Configuration for proxy generation or Deployment Configuration for proxyuse has to be selected after launching the JNBridge installation file.

Development Configuration is the mode for proxy generation. That means, that theproxy generation tool JNBProxy will be installed along with the JNBridge runtimelibraries. With this tool, the developer is able to generate the proxy classes thatwill be used to “call” methods written in the other programming language(s) andcompiled to the respective bytecode. We used this tool to generate the Kieker-

1http://www.jnbridge.com/downloads.htm

25

http://www.jnbridge.com/downloads.htm


JNBridgePro vX.X/2.0-targeted/

jnbproxy.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Proxy generation tooljnbproxyGui.exe . . . . . . . . . . . . . . . . . . . . . . . . . .Proxy generation tool (GUI version)JNBShare.dll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .NET-sideJNBSharedMem.dll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .NET-sideRegistrationTool.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . License registration

jnbcore/bcel-5.1-jnbridge.jar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Java-sidejnbcore.jar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Java-sidejnbcore_http.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Java-sidejnbcore_sharedmem.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Java-sidejnbcore_tcp.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Java-side

Figure 3.6.: JNBridge installation directory structure (only files we refer to are shownhere).

Proxy.dll proxy library for use in a .NET environment. More on proxy generationin Section 3.3.3.

Deployment Configuration has to be selected when JNBridge is installed on a com-puter where .NET or Java applications will be run that make use of the JNBridgeinteroperability capabilities. This might be either a client machine for productionuse, e.g., a terminal in a supermarket that runs a .NET front-end that communi-cates with a server located Java back-end, or a workstation where the .NET sideand the Java-side are hosted in parallel on the same computer. In our case, this isthe convenient configuration for monitoring.

Figure 3.6 lists all files referred to in this chapter with their location inside the JNBridgeinstallation directory.

3.3.2. License Activation

After installing JNBridge, JNBridgePro registration tool (RegistrationTool.exe) has to belaunched to activate a valid license. For evaluation purposes, the 30-day trial-license-keyreceived via email after registration may be sufficient.When evaluating JNBridge for an open source project like Kieker, or for use in tem-

porary project or work such as a thesis, a trial-extension-key for up to 6 months or even

26


Figure 3.7.: GUI version of JNBProxy.

more can be obtained through contacting the JNBridge sales team. This is how wemanaged to work with JNBridge for the past 8 months.

3.3.3. Proxy Generation

JNBProxy, the JNBridge proxy generation tool, is installed with JNBridge when se-lecting Development Configuration during installation. To generate proxies, the devel-oper may either launch the GUI version (jnbproxygui.exe) or the command-line version(jnbproxy.exe) of the tool. Figure 3.7 shows the main view of the GUI version.

• The Environment pane on the left side shows the loaded Java classes. For ourproject, the contents of the kieker-1.4.jar Java archive that ships with the Kiekerdistribution had been loaded.

• In the middle, the Exposed Proxies pane shows the classes that will be exposedvia the proxy file that will be generated. The exposed classes correspond with thecheckboxes in the Environment pane on the left side. This is how the developer

27


Namespace Exposed classeskieker.common.record AbstractMonitoringRecord

BranchingRecord

CPUUtilizationRecord

CurrentTimeRecord

IMonitoringRecord

MemSwapUsageRecord

OperationExecutionRecord*ResourceUtilizationRecord

kieker.monitoring.core.configuration Configuration*kieker.monitoring.core.controller AbstractController

IMonitoringController*MonitoringController*

kieker.monitoring.core.sampler ISampler

ScheduledSamplerJob

kieker.monitoring.timer ITimeSource*

Table 3.2.: Exposed Kieker classes.

selects the classes to expose. We only exposed classes that are reasonable to useon the .NET-side (Table 3.2).

• The right pane shows the Signature of a selected class. This provides all necessaryinformation when selecting the classes to expose.

In Table 3.2 we list the exposed Kieker classes. All classes marked with (*) are actuallyused for manual instrumentation or by our Kieker.NET implementation. The otherexposed classes are candidates for future extension of the work of porting the functionalrange of Kieker to .NET, e.g., by supporting other types of kieker.common.record fordifferent monitoring purposes.After defining what classes to expose, the library with the proxies can be generated

and is then ready to be referenced and used by the target framework, which will be.NET in our case. As depicted in Figure 3.5, the resulting proxy classes embody a newKieker component. Throughout the remainder of this document, we will refer to ourgenerated proxy library that contains the exposed Kieker classes as KiekerProxy.dll.

28


The GUI version of JNBProxy also allows to generate a command-line script (BATCHfile) for integration of proxy generation into a build process. See Listing B.1 for a scriptthat can be used to generate the Kieker proxy library. For more detail on configurationand operation of the proxy generation tool see the JNBridge Users’ Guide [JNBridgeLLC. 2011b].

29

4. Dynamic Analysis With Kieker.NET

In this chapter, we present the first part of an extension of the original Kieker framework,which we call Kieker.NET, for dynamic analysis of .NET applications. In Section 4.1,we give a detailed introduction on how to configure the monitoring environment fordynamic analysis with Kieker.NET. Section 4.2 provides instructions on how to fulfillthe minimum requirements for monitoring in .NET (i.e., monitoring probes) are providedthat allow manual instrumentation by mixing monitoring logic with business logic.Section 4.3 concludes this chapter with the results of a complete monitored run of the

Bookstore sample application employing the techniques we developed so far.

4.1. Monitoring Configuration

4.1.1. Java-Side Configuration

Before using the generated proxy library KiekerProxy.dll in our Bookstore sample applica-tion, the Java-side, i.e., the computer that hosts the JVM with the exposed Kieker Javaclasses loaded, must be properly configured. Starting of the JVM can be configured tobe triggered automatically. Then, whenever a first use of a proxy is made, a JVM withthe corresponding Java classes available is started within the same process the .NETapplication is running. This can be configured in a configuration file on the .NET-Sideas shown in Section 4.1.2. Another option is starting the Java-side manually. This addsanother level of control, but is actually necessary if the Java-side resides on a differentmachine than the .NET-side.In any case, the JVM with the exposed classes is started by executing a Java pro-

gram (com.jnbridge.jnbcore.JNBMain) that ships with JNBridge as part of the libraryjnbcore.jar. Manual starting of the JVM can be done efficiently by using a batch file.Listing B.3 shows our start-kieker-jvm.bat batch file that can be used to start the Kieker

31


JVM for JNBridge operation. The JVM can also be started programmatically fromwithin an existing JVM running another Java program.Configuration of the JVMs communication parameters (essentially the IP adress) must

be done with a properties file. This can be either jnbcore_sharedmem.properties for sharedmemory communication, jnbcore_http.properties for HTTP/SOAP communication, orjnbcore_tcp.properties for communication via TCP/Binary as in our case. Listing B.4shows our configuration for the Kieker JVM (note that these are the default files thatship with JNBridge).Figure 3.6 helps locating the JNBridge-related files when editing the batch file. Analog

to starting of the JVM, its configuration can also be done programmatically.When the communication settings are properly configured, Kieker itself also has

a kieker.monitoring.properties file that allows different monitoring configurations. AsKieker.NET basically provides only the .NET-compatible monitoring probes, all con-figuration entries in that file are still valid and necessary. Aside from basic settings likethe name of the Kieker instance and the hostname (both to appear in the monitoring logfile names), the actual monitoring log writer and different other monitoring parametersare set up here.

4.1.2. .NET-Side Configuration

On the .NET-side, all that has to be done to access the exposed Java classes is referencingthe generated proxy library, in our case KiekerProxy.dll, together with the appropriate JN-Bridge runtime library, JNBShare.dll for TCP/IP communication or JNBSharedMem.dllfor shared memory communication. The .NET application that uses the proxy classesneeds some JNBridge-specific configuration entries to be added to its app.config file. Thistells the .NET-side which communication mechanism should be used, the ip or hostnameof the server (i.e., the Java-side), and whether the secure communication via SecureSockets Library (SSL) should be used. These settings have to match those configured inthe Java-side’s jnbcore_tcp.properties or jnbcore_http.properties configuration file men-tioned before when using TCP/Binary or HTTP/SOAP communication, respectively.Listing B.7 shows a sample app.config file—consisting solely of the JNBridge-relatedentries—configured for TCP/Binary communication. Listing B.8 shows the necessaryentries when shared memory communication is used. For this, the correct locations ofJava’s jvm.dll (installed with any version of the Java Runtime Environment (JRE) or

32

4.2. Manual Instrumentation

Figure 4.1.: Class diagram of the instrumented Bookstore sample application.

Java Development Kit (JDK)), as well as the location of JNBridge’s own libraries haveto be configured in the App.config file before execution. If the application does not yethave a configuration file, the naming scheme is Application1.exe.config for a compiledapplication Application1.exe.Now that our JNBridge .NET/Java interoperability environment is set up, the next

step is the implementation of the manual instrumentation on the .NET-side to allowmonitoring with Kieker.NET.


Manual instrumentation with Kieker.NET can be implemented in a straightforward man-ner and is not much different to the way Kieker allows manual instrumentation of Javacode as shown in Ehmke et al. [2011].To demonstrate manual instrumentation, we use the C# Bookstore sample applica-

tion, as introduced in Section 2.4. The instrumented classes can be found in the Book-storeInstrumented sub-folder of our Kieker.NET Visual Studio solution. Figure 4.1 showshow the bridged MonitoringController is integrated when instrumenting the classes

33


Bookstore and CRM. Note that all MonitoringController class members are actuallyavailable on the .NET-side.

4.2.1. Monitoring Probes

Listing 4.1 shows the instrumented Bookstore class. Specifically, we want to monitor theexecution of method calls to Catalog.GetBook(). The parameter of type bool is notrelevant in this context. Instrumentation of CRM is identical.

1. To monitor a method call in this class, first we need a reference to an instanceof the Kieker monitoring controller class MonitoringController. This referenceis obtained in Line 22. The call to the static getInstance() method is actuallyour first application of JNBridge. Note that the using directives (Lines 1, 2) alsoreference actual Java classes.

2. To monitor the execution time of calls to Catalog.GetBook(), we measure timebefore and after the call (Lines 28 and 34, directly surrounding the actual callin Line 31). Time measurement is also done by calling Kieker getTime() Javamethods through JNBridge.

3. After that, we create a new OperationExecutionRecord with our time measure-ments and the name of the monitored method (Lines 37, 38) and hand it over toour MonitoringController (Line 42).

Validating and all further handling and storing of monitored data is done on the Java-side by Kieker and does not need to be changed.

4.2.2. Monitoring Preliminaries

For runtime monitoring of the Bookstore sample application, we just need to build theBookstore project with the instrumented Bookstore class shown above, and run itsexecutable BookstoreInstrumented.exe.It is important that the Kieker JVM is running on the Java-side before executing the

instrumented application if TCP/Binary or HTTP/SOAP communication is chosen. Asthe .NET-side runtime library of JNBridge needs access to the JVM as soon as any

34


1 using kieker.common.record; // Bridged Java class.2 using kieker.monitoring.core.controller; // Bridged Java class.34 public class Bookstore5 {6 private readonly Catalog _catalog;7 private readonly Crm _crm;89 // Private field that holds a reference to Java -based10 // MonitoringController.11 private readonly IMonitoringController _monitoringController;1213 public Bookstore ()14 {15 _catalog = new Catalog ();16 _crm = new Crm(_catalog);1718 // Retrieving a reference to Java -based MonitoringController19 // by calling a static Java method.20 _monitoringController = MonitoringController.getInstance ();21 }2223 public void SearchBook ()24 {25 // Measure time before method call.26 var tin = _monitoringController.getTimeSource ().getTime ();2728 // Actual method call to be monitored.29 _catalog.GetBook(true);3031 // Measure time when method returns.32 var tout = _monitoringController.getTimeSource ().getTime ();3334 // Create a new OperationExecutionRecord with monitored data.35 var e = new OperationExecutionRecord(36 typeof (Catalog).FullName , "GetBook ()", tin , tout);3738 // Pass the new record to MonitoringController for further39 // processing.40 _monitoringController.newMonitoringRecord(e);41 _crm.GetOffers ();42 }43 }44 }

Listing 4.1: Instrumented Bookstore class.

35


Figure 4.2.: Monitored execution of instrumented Bookstore sample application.

bridged type is accessed, the monitored application will throw a TypeInitialization-

Exeption caused by JNBridge on startup otherwise. When using shared memory com-munication, the Kieker JVM is started by the monitored process itself.

4.3. Monitoring of the Bookstore Sample Application

The following Sections show the console output of both a monitored execution of ourinstrumented Bookstore sample application as well as the corresponding Kieker JVM.

4.3.1. .NET-Side

On .NET-side, there is nothing notably different when executing the instrumented ver-sion of Bookstore. Figure 4.2 shows the console output of one execution of the Bookstore.

4.3.2. Java-Side

As pointed out before, the Kieker JVM has to be started before executing an in-strumented application (when using TCP/binary communication as in our example).The state of the running JVM before monitoring is the output in the first four linesof Figure 4.3. After that, there is only output generated by Kieker itself. Most ofit is printed before monitoring and reflects the actual configuration of the startedMonitoringController.

36

4.3. Monitoring of the Bookstore Sample Application

Figure 4.3.: Kieker JVM console output after instrumented Bookstore sample applica-tion has been run once.

37


Figure 4.4.: Resulting Kieker monitoring log for the instrumented Bookstore sampleapplication.

4.3.3. Kieker Monitoring Log

After a successful run of the monitored application, in this case the execution of the com-piled BookstoreInstrumented.exe, the configured Kieker’s AsyncFsWriter wrote a moni-toring log file to the hard disk of the machine that hosts the Java-side. Figure 4.4 showsthe file that is generated through manual instrumentation as shown in the previous sec-tions. As expected, Kieker monitored 20 calls to Catalog.GetBook(), where 10 calls areproduced by Bookstore and the other 10 by Crm.Note that a trace analysis is not possible with this data, as no entries (other than -1)

are there for eoi and ess values [van Hoorn et al. 2009]. This is because we did not keeptrack of execution order or execution stack size with our basic manual instrumentation.An analysis of the involved components or component’s operations is also not promising,as we kept track of only one single method. A more efficient way of instrumenting thecode is required to allow a deeper analysis of complex applications. The following Chap-ter introduces much more powerful instruments that will cope with the instrumentationof even very complex systems easily.

38

5. AOP-Based Monitoring WithKieker.NET

To allow non-intrusive and efficient instrumentation of .NET applications, Kieker.NETsupports monitoring based on the concepts of aspect-oriented programming (AOP). InSection 5.1, we give a basic overview of different types of AOP in .NET and present threedifferent technologies that support AOP for .NET-based applications. The solution wechose for Kieker.NET is presented in detail in Section 5.2. One challenge when dealingwith AOP is often the way the aspects are actually applied to the code. In Section 5.3,we show different ways of how Kieker.NET’s main aspect can be applied.

5.1. Aspect-Oriented Programming in .NET

The principles of aspect-oriented programming (AOP) [Kiczales et al. 1997] can beapplied to the .NET languages just as well as to any other object-oriented language.The core concept of cross-cutting concerns (i.e., aspects) is not language-restricted.Several AOP frameworks for .NET exist, but they differ significantly in how, when,

and to which targets aspects can be applied (or woven). Kiczales et al. [1997] definedtwo different approaches of when the aspects are applied to the code, runtime weavingand compile-time weaving. For .NET implementations of AOP, the same classificationcan be used.

5.1.1. Postsharp

Postsharp [SharpCrafters s.r.o. 2011a] calls itself a static aspect weaver because aspectsdeveloped with Postsharp can only be woven to the targeted code at compile-time (post-compile-time is also possible). The aspect weaver of Postsharp does this by altering theapplication’s CIL code after it had been compiled (Figure 5.1).

39

5. AOP-Based Monitoring With Kieker.NET

VB.NET Code

J# Code

Common Language Infrastructure

C# Code

CommonIntermediate

Language

100100110100101110101010110101011101010101101010101001011010101111

Compiler

Compiler

Compiler

CommonLanguageRuntime

Postsharp

Figure 5.1.: Postsharp’s post-compile-time aspect weaver.

Postsharp provides aspect parent classes and interfaces for most of the common cross-cutting concerns. Developing an aspect is done by deriving from such a class or im-plementing an interface and override/implement the aspect advices (i.e., the notifica-tions when a method is entered and exited for the most common example, Postsharp’sOnMethodBoundaryAspect).

Programmatically, aspect application can be done by utilizing .NET attributes (the.NET equivalent of Java annotations). When an aspect is applied to a method, schemat-ically, the aspect transforms the method at compile-time as shown in Listing 5.1.

For more information on aspect development and application see Section 5.2 and thePostsharp reference documentation [SharpCrafters s.r.o. 2011b].

5.1.2. Spring.NET

Spring.NET1 is an open source application framework led and sustained by Spring-Source2, the developers of the popular Spring development framework for Java.

1http://www.springframework.net/2http://www.springsource.com/

40

http://www.springframework.net/

http://www.springsource.com/

5.1. Aspect-Oriented Programming in .NET

1 void InstrumentedMethod (...)2 {3 OnEntry ();4 try5 {6 // Original method body.7 OnSuccess ();8 return returnValue;9 }10 catch ( Exception e )11 {12 OnException ();13 }14 finally15 {16 OnExit ();17 }18 }

Listing 5.1: Transformed method after aspect application.

Spring.NET supports AOP through dependency injection for applications that havebeen developed with the framework. As opposed to Postsharp, aspect weaving inSpring.NET is called dynamic because it will be done at runtime.This always has the advantage that the application the aspect is applied to does not

have to be altered at all, because the aspect can be woven into its bytecode at runtime.There is one huge disadvantage coming with the AOP implementation of Spring.NET

(aside from the fact that, first of all, a potential monitored application must be aSpring.NET application), namely the fact that only virtual methods can be targetedby aspects.

5.1.3. Castle DynamicProxy

Castle DynamicProxy3 is another dynamic AOP implementation for .NET. Comparedto Spring.NET it has the “advantage” that it is not required for an application to bedeveloped with a certain application framework (other than .NET itself). But it sharesSpring.NET’s drawback of allowing only virtual methods to be targeted by the runtimeaspect weaver. In C#, all methods are per default non-virtual (unlike Java methods).

3http://docs.castleproject.org/

41

http://docs.castleproject.org/


5.2. Kieker.NET Implementation with Postsharp

The AOP implementation of the Java-based Kieker is based on AspectJ, which supportsboth compile-time and runtime weaving. Unfortunately, no equivalent framework existsfor .NET, so we had to decide which way to go with our implementation.We chose Postsharp for our work, as it is the de facto standard when it comes to

compile-time aspect weaving in a .NET-based environment. Moreover, the limited ap-plicability of both of the other presented solutions was not acceptable, especially withthe case study system in mind.Our Postsharp-based implementation of Kieker.NET consists of the C# classes shown

in the class diagram in Figure 5.2. We adopted the namespace from the Java-basedKieker framework, ported all the code that has to be executed platform-specific, andfinally added new classes to the corresponding contexts. As we wanted to avoid coderedundancies, we only ported code where it was necessary. In the following sections,we present our implementation in detail and will also comment on the platform-specificchanges that had to be done to the Java-based classes. The complete source code forthe presented classes can be found in Appendix A.2.3.

5.2.1. The OperationExecutionAspect Class

As introduced in Section 5.1.1, Postsharp basically is a post-compiler that weaves aspectsinto applications or function libraries by altering their Common Intermediate Language(CIL) bytecode (see Section 2.3 for an introduction to the concepts of .NET). Ourcross-cutting concern for monitoring is the creation of OperationExecutionRecords atruntime. We want every instrumented method to have monitoring code—the probes—executed before and after the method call.The aspect that contains this code is our class OperationExecutionAspect. Figure 5.2

shows the class diagram with the aspect itself and its base class that is provided by Post-sharp, alongside with other supporting classes that will be introduced in the followingsections. See Chapter A.2.3 for the complete source code of these classes. We explainour implementation by describing the (public) methods of our aspect. Note that thefour implemented methods are all inherited or implemented from Postsharp aspect baseclasses or interfaces (also shown in Figure 5.2).

42


Figure 5.2.: Class diagram of all Kieker.NET classes.

43


CompileTimeInitialize() is used for gathering information about the monitored method(i.e., its name and parameter types) as well as the declaring type. This can be doneat compile-time (or build-time), so that no use of System.Reflection has to bemade at runtime. As reflection in .NET is done by examination of an assembly’smeta-data, avoiding such operations at runtime is preferable whenever possible.Especially when dealing with costly operations like string formatting as in ourcase (the methods for that are omitted here), taking advantage of compile-timeinitialization is most certainly beneficial for the performance at runtime.

1 public override void CompileTimeInitialize(MethodBase method , ...)2 {3 _componentName = FormatType(method.DeclaringType.FullName);4 _method = FormatMethodName(method.Name)5 + FormatParameters(method.GetParameters ());6 }

Listing 5.2: Aspect Compile-time initialization method.

RuntimeInitialize() deals with initialization of the aspect’s references to the Moni-

toringController and the ControlFlowRegistry. This method is executed onaspect load-time, i.e., when the class that contains the implementation of moni-tored methods is loaded for the first time. This is due to the fact that our bridgedaccess to the Java-side Kieker JVM can only be established at runtime. Trying toinitialize bridged types at compile-time results in a TypeInitializationExceptionin the build process—a very uncommon behavior. In this case, the type of our field_ctrlInst is such a bridged Java type, accessed through the MonitoringControl-lerWrapper.

1 public override void RuntimeInitialize(MethodBase method)2 {3 _ctrlInst = MonitoringControllerWrapper.MonitoringController;4 _cfRegistry = ControlFlowRegistry.Instance;5 }

Listing 5.3: Aspect runtime initialization method.

OnEntry() contains the code that will be executed before the body of the monitoredmethod is entered. In our case, this is time measurement, the initialization of aOperationExecutionRecord, and to support tracing, we also manage counter for

44


execution order and call stack size at this point. To allow concurrency, we have toinitialize the OperationExecutionRecord locally, thus avoiding interference frompossible concurrent calls to the same monitored method. This is only possiblebecause we can store the collected data in the aspect context for later use.

1 public override void OnEntry(MethodExecutionArgs args)2 {3 if (! _ctrlInst.isMonitoringEnabled ()) { return; }4 OperationExecutionRecord execData = InitExecutionData ();5 int eoi = 0; // execution order index6 int ess = 0; // execution stack size7 if (execData.isEntryPoint)8 {9 _cfRegistry.StoreThreadLocalEoi (0);10 _cfRegistry.StoreThreadLocalEss (1);11 }12 else13 {14 eoi = _cfRegistry.IncrementAndRecallThreadLocalEoi ();15 ess = _cfRegistry.RecallAndIncrementThreadLocalEss ();16 }17 if ((eoi == -1) || (ess == -1))18 {19 _ctrlInst.terminateMonitoring ();20 }21 execData.eoi = eoi;22 execData.ess = ess;23 // Time when monitored method begins execution.24 execData.tin = _ctrlInst.getTimeSource ().getTime ();25 // Store execData for further use in OnExit ().26 args.MethodExecutionTag = execData;27 }

Listing 5.4: OperationExecutionAspect’s OnEntry() advice.

OnExit() is executed when the monitored method returns. Here, we measure the timeagain, and hand over all data to the (Java-based) MonitoringController.

1 public override void OnExit(MethodExecutionArgs args)2 {3 if (! _ctrlInst.isMonitoringEnabled ()) { return; }4 // Restore execData.5 OperationExecutionRecord execData = (OperationExecutionRecord)

args.MethodExecutionTag;6 // Time the monitored method is finished.7 execData.tout = _ctrlInst.getTimeSource ().getTime ();

45


8 if (execData.isEntryPoint)9 {10 _cfRegistry.UnsetThreadLocalTraceId ();11 }12 // Create a new monitoring record with the measured data.13 _ctrlInst.newMonitoringRecord(execData);14 if (execData.isEntryPoint)15 {16 _cfRegistry.UnsetThreadLocalEoi ();17 _cfRegistry.UnsetThreadLocalEss ();18 }19 else20 {21 _cfRegistry.StoreThreadLocalEss(execData.ess);22 }23 }

Listing 5.5: OperationExecutionAspect’s OnExit() advice.

Of the four advices of the base aspect OnMethodBoundaryAspect, we only implementOnEntry() and OnExit(), as we are not interested in exception logging in this context.

5.2.2. The ControlFlowRegistry Class

To support (thread-safe) call tracing, we needed to re-implement the ControlFlowRe-

gistry of Java-based Kieker in C#. The sequence diagram in Figure 5.3 shows theproblem that occurs when using the bridged ControlFlowRegistry. There was no wayto ensure that the ThreadLocal fields of the registry on Java-side are accessed by theexact threads that initiated the aspect in the first place. Instead, we observed thataspects were not able to recall their (supposed-to-be thread-local) values they stored inthe registry in previous executions.The functionality of the methods of our implementation of ControlFlowRegistry—

which are basically accessor and mutator methods for thread-local fields traceId, exe-cution order index (eoi), and execution stack size (ess)—is mostly unchanged from theJava version.Listing A.4 shows the source code of this class. Analog to the Java-based class, we

used the Singleton pattern [Gamma et al. 1995] to ensure that only one instance of theControlFlowRegistry exists at a time and all aspects have the same reference to it. Thisis important, because we want to store global call traces, and identifying the connectionbetween data generated by single aspects would be impossible otherwise.

46


OperationExecutionAspectMonitoredClass

OnEntry()

OnEntry()

UserProcess JNBridge ControlFlowRegistry

set()

IncrementAndRecallThreadLocalEoi()

Get()

MonitoredOperation() Java classes

StoreThreadLocalEoi()

ThreadLocal ThreadLocal

= ?

MonitoredOperation()

Figure 5.3.: Multithreading problems with bridged ControlFlowRegistry Java class.

For the same reasons, the SessionRegistry class of Java-based Kieker should alsobe re-implemented when the functional range of Kieker.NET is extended to supportsession-based monitoring.

5.2.3. The MonitoringControllerWrapper Class

As the name suggests, this class is a wrapper for the Java-based MonitoringController

instance which we access via JNBridge. Basically, this would not be necessary, butwe wanted to hook into the ProcessExit event of the monitored application to sent aterminateMonitoring() signal to the MonitoringController. Aside from providing areference to the singleton MonitoringController to our .NET-side, this is all we do here.Structurally, inheriting from the Java-based MonitoringController and overriding theshutdown logic would be possible, but the class is final on Java-side, and this alsoapplies to the .NET-side. See Listing A.3 for the source code of this class.

47


5.2.4. The OperationExecutionAspectProvider Class

This class, an implementation of Postsharp’s IAspectProvider, can be used to applyaspects to compiled function libraries (dll) or applications (exe) where no alterations ofsource code and no new build is needed. More details on this in Section 5.3.4.

5.3. Aspect Application

Our Postsharp-based implementation of Kieker.NET supports several levels to applythe aspect, i.e., the Kieker monitoring probe, to an application. Sections 5.3.1, 5.3.2,and 5.3.3 deal with applications techniques that involve different degrees of changesto the targeted source code and new build of the targeted application. Additionally,Section 5.3.4 presents an approach for aspect application to compiled assemblies thatcannot be altered by editing their source code.

5.3.1. Method Level

Aspect application on method level can be considered the common case. This simplyallows instrumentation of a method without mixing monitoring and business logic. List-ing 5.6 shows how our OperationExecutionAspect can be applied to the Bookstore sam-ple application’s Catalog.GetBook() method by simply adding the [OperationExecu-

tionAspect] attribute to it.

1 public class Catalog2 {3 [OperationExecutionAspect]4 public void GetBook(bool complexQuery)5 {6 Thread.Sleep(complexQuery ? 20 : 2);7 }8 }

Listing 5.6: Method-level aspect application.

All calls to Catalog.GetBook() are now monitored. Listing 5.7 shows one entry ofthe monitoring log that is generated by Kieker for this instrumentation when runningthe Bookstore sample application once.

48


1 $1 ;1317074261977377840;1; BookstoreAnnotated.Catalog.GetBook(System.Boolean);N/A;3242591731706757121;1317074261974127505;1317074261976446825; Felix -PC;0;0

Listing 5.7: Monitoring log entry for instrumented Catalog.GetBook() method.

For the 10 iterations of BookstoreStarter calling Bookstore.SearchBook(), Kiekercreated exactly 20 monitoring log entries, all of them much similar to the one shown inListing 5.7, with zero values on logged execution order index and execution stack size(the last two values). This is because the instrumentation of one single method cannotproduce traces as long as no recursion is involved.

5.3.2. Class Level

Class-level aspect application is much similar to method-level application. Here, theOperationExecutionAspect attribute is added to classes directly. This automaticallyapplies the aspect to all methods of a class, regardless of their access level modifier.In our Bookstore sample application, these classes could be Bookstore and Catalog,which now also should allow us to actually monitor traces (note that this is also possiblewith method-level aspect application, even if the effort of applying the aspect would behigher).

1 [OperationExecutionAspect]2 public class Bookstore3 {4 private readonly Catalog _catalog;5 private readonly Crm _crm;67 public Bookstore ()8 {9 _catalog = new Catalog ();10 _crm = new Crm(_catalog);11 }1213 public void SearchBook ()14 {15 _catalog.GetBook(false);16 _crm.GetOffers ();17 }18 }

Listing 5.8: Class-level aspect application.

49


Listing 5.8 exemplifies class-level aspect application on the Bookstore class. Addingthe attribute to the class constructor (Bookstore()) and the SearchBook() methodinstead of the class would have the exact same effect. For Catalog, the attribute justcan be moved from the GetBook() method to the class declaration.

1 $1 ;1317137637484078573;1; BookstoreAnnotated.Catalog.ctor();N/A;1837468647967162369;1317137637482419620;1317137637483238505; Felix -PC;1;1

2 $1 ;1317137637485977494;1; BookstoreAnnotated.Bookstore.ctor();N/A;1837468647967162369;1317137637479510425;1317137637485432545; Felix -PC;0;0



5 $1 ;1317137637500195841;1; BookstoreAnnotated.Bookstore.SearchBook ();N/A;1837468647967162370;1317137637489299418;1317137637499837534; Felix -PC;0;0



8 $1 ;1317137637513432038;1; BookstoreAnnotated.Bookstore.SearchBook ();N/A;1837468647967162371;1317137637502548764;1317137637513064965; Felix -PC;0;0

9 ...

Listing 5.9: Monitoring log entry for class-level attributed Bookstore sample application.

Monitoring the execution of the class-level attributed classes produces the monitoringlog shown in Listing 5.9. This time, the tracing values are zero and non-zero, whichwould allow us to consider a first Kieker trace analysis (although the resulting diagramswould be incomplete, as not all classes (i.e., Crm) are instrumented and therefore notunder observation).

5.3.3. Assembly Level

Attributing all classes of an assembly produces the same result as the one single instruc-tion shown in Listing 5.10. With this, we apply the aspect to all methods of all classescontained in the assembly.

1 [assembly: OperationExecutionAspect]

Listing 5.10: Assembly attribute for assembly-level aspect application.

In fact, the [assembly: ...] attribute can be anywhere inside any class of the wholeassembly, but it can be considered good practice to have a dedicated “class" file (in ourcase named AspectInfo.cs) added to the other sources that contain the classes that willbe monitored.

50


It may be necessary to control to what methods the aspect will actually be applied.The above example is an unlimited multicast that makes no restrictions, resulting inthe instrumentation of all classes’ methods. Listing 5.11 shows three example assemblyattributes that can be used to manage aspect application.

1 [assembly: OperationExecutionAspect(2 AttributeTargetTypes = "Bookstore .*")]34 [assembly: OperationExecutionAspect(5 AttributeExclude = true ,6 AttributeTargetTypes = "Bookstore.Crm.*")]78 [assembly: OperationExecutionAspect(9 AttributeExclude = true ,10 AttributeTargetMembers = "regex:ctor|get_ .*| set_.*")]

Listing 5.11: Assembly attributes for managed assembly-level aspect application.

By specifying the AttributeTargetTypes property of the first attribute, we instructPostsharp to apply our aspect to all classes in the Bookstore namespace (for our Book-store example application, this is analog to the attribute in Listing 5.10). With thesecond attribute, we exclude the classes in the Bookstore.Crm namespace—that havebeen included before—by specifying the AttributeExclude=true property. The thirdattribute removes constructors and accessor and mutator methods from our observation.

Especially the third attribute can be quite valuable when monitoring complex soft-ware systems where a too coarse grained positioning of monitoring points can lead tounmanageable amounts of monitoring output (logs), as well as poor performance [vanHoorn et al. 2009]. For more detail on how to specify aspect target elements, see thePostsharp reference documentation [SharpCrafters s.r.o. 2011b].

We now finally have a convenient tool that allows comprehensive dynamic analysisof .NET applications. With assembly-level aspect application, we can target all classesof an application at once, without having to modify any of the original classes. Forthe Bookstore sample application, the operation dependency graph and the sequencediagram that are shown in the Foundations chapter in Section 2.4 are actually generatedby monitoring the .NET-based Bookstore sample application with assembly-level aspectapplication.

51


5.3.4. Build-Independent Aspect Application

With the help of a new feature in the newest version of Postsharp (version 2.1) andour OperationExecutionAspectProvider introduced in Section 5.1.1, we can apply theOperationExecutionAspect also to compiled assemblies, regardless whether targetingpure function library assemblies (dll) or executables (exe).

1 @ECHO OFF2 SETLOCAL34 SET POSTSHARP=C:\Program Files (x86)\PostSharp 2.15 SET .NET_VERSION =2.06 SET ARCHITECTURE=x867 SET TARGET_ASSEMBLY=Bookstore.exe89 @"%POSTSHARP%\Release\postsharp.%.NET_VERSION%-%ARCHITECTURE%-cil.exe" "

%TARGET_ASSEMBLY%" /p:AspectProviders=Kieker.Monitoring.Probe.Postsharp.OperationExecution.OperationExecutionAspectProvider ,Kieker /p:Output=output\Bookstore.exe

1011 @COPY /y *.dll .\ Output12 @PAUSE

Listing 5.12: Batch file to apply a given aspect to an assembly.

Listing 5.12 shows how Postsharp can be utilized for this type of aspect application.Here, we apply the OperationExectuionAspect to our non-instrumented Bookstore.execompiled executable. Afterwards, the now instrumented file will be in a subfolder calledOutput, together witch all needed libraries.

1 foreach (MethodInfo targetMethod in type.GetMethods(BindingFlags.Instance| BindingFlags.Public | BindingFlags.DeclaredOnly))

2 {3 ...4 }

Listing 5.13: Configuring the aspect targets programmatically.

The aspect targets can be defined in the OperationExecutionAspectProvider class.Listing 5.13 shows the line of this class where this can be done programmatically. Itwould probably be better to extend the aspect provider, so that the aspect targets canbe defined by an external configuration file, e.g., in XML format.

52


Creating a Bookstore.exe.config file as described in Section 4.1.2 with the entries forJNBridge is all that is needed to monitor execution of Bookstore.exe with Kieker.NETwithout the need to have access to the source code.Any usage of the interface IAspectProvider—that includes our OperationExecution-

AspectProvider—requires a valid Professional license of Postsharp registered on thecomputer where the aspect application as described above will be performed.

53

6. Overhead Evaluation

Evaluation of the performance of Kieker.NET is the main concern of this chapter. Forthis, we have to quantify the overhead that is induced by Kieker.NET to an applicationunder observance. We present monitoring overhead analysis with a micro-benchmark,following van Hoorn et al. [2009], and concentrate on quantitative assessment, moreprecisely on quantifying the monitoring overhead that is induced by Kieker.NET.That Kieker.NET works for small example applications (i.e., that the logged data is

valid and can be analyzed further with Kieker’s analysis tools), has already been shownin our running examples throughout Chapters 4 and 5.By measuring and assessing the monitoring overhead and comparing the results with

reference values obtained by runtime analysis of non-instrumented applications, wepresent information that may allow to weigh whether monitoring of certain componentsis adequate (e.g., complex computation of a mathematical problem that involves a largesum of iterative steps).Because of the number of involved frameworks and utilities (Postsharp, JNBridge,

Java), we expect several different causes of overhead with their diverse performance (i.e,response time) impacts. We try to break down and identify these causes in Section 6.1.A convenient experiment design that allows us to distinguish and quantify all involvedcauses for overhead is introduced in Section 6.2. Finally, we present the results of ouranalysis in Section 6.3.

6.1. Causes of Overhead

When the decisions to employ the different frameworks for Kieker.NET were made, theirimpact on the pure performance was not the main deciding factor. As we described inSections 3.1 and 5.1, it was more the practicality and technical maturity of the solutionsthat abetted their employment.

55


The overhead caused by the original Java-based Kieker was thoroughly evaluatedand analyzed by van Hoorn et al. [2009]. Here, we need to focus on the .NET-relatedtechnologies, namely Postsharp and JNBridge. Especially JNBridge is expected to havea significant impact on performance.However, as we evaluate Kieker.NET as a whole, we have to be aware of the different

causes for the expected overhead. With this in mind, the more fine-grained our observa-tions can be, the better. Hence, the goal for our experimental setting(s) must be findinga way to distinguish each source of overhead individually. Possible causes of overheadare:

.NET Framework itself is supposedly a cause for overhead, given its application vir-tual machine approach as opposed to native compiled code (e.g., compiled C orCOBOL applications). For two reasons we are not going to incorporate this intoour performance analysis at all. First, the native Java Kieker runs in a comparableJava environment as well, so there is not point in considering .NET as a cause ofoverhead. And second, all applications that can potentially be monitored withKieker.NET are affected by a possible overhead themselves.

Postsharp is potentially the first cause of overhead that is directly related to our tech-nological choices when implementing Kieker.NET. Here, we have to assess theoverhead that comes with the employment of AOP. The aspect class of Postsharpwe chose for Kieker.NET places code (i.e., advices) on a methods boundary. Towhat extend the performance impact of this is linear to the amount of instructionsadded is to be analyzed.

JNBridge with its .NET/Java intercommunication features is expected to account forthe biggest part of Kieker.NET’s monitoring overhead. According to the JNBridgeuser guide, it is also crucial which communication mechanism is used, as sharedmemory is supposed to be much faster than the other two alternatives TCP/binaryand HTTP/SOAP. We will try to verify this by using both in our experiments.

Java-side Kieker is somewhat directly related to JNBridge. Without the class loader ofJNBridge, there would be no active Kieker instance. And analyzing the (communi-cation) overhead of JNBridge without the respective Java classes to communicatewith would not make any sense. There is, of course, a certain amount of monitor-ing to be expected from the Java classes, because—after all—their methods are

56

6.2. Experiment Design

called via JNBridge. Quantifying this very amount is most probably outside of thefocus of this analysis, as it would require additional alterations to the Java classes,which is not envisioned.

Our Experiment design to be introduced in the next section attempts to take all differentcauses of monitoring overhead into account by introducing a staged design.

6.2. Experiment DesignAll experiments presented in this chapter are performed on an up-to-date workstation,powered by an Intel Xeon W3530 quad-core processor running at 2.8 GHz, with 12GB DDR3 memory, and an Intel 510 series solid-state drive. The operating system isMicrosoft Windows 7 Professional 64-bit. The micro-benchmark is a Microsoft .NET3.5 project, using Postsharp version 2.1.3.3 and JNBridgePro version 5.1. The Java-side(Kieker 1.4-dev-SNAPSHOT) is hosted by a version 1.6.0_24-b07 JVM.

6.2.1. Benchmark

The benchmark is a .NET 3.5 console application. An excerpt with the part where theactual method call of the monitored method is made is shown in Listing 6.1.

1 #region Benchmark23 var monitoredClass = new MonitoredClass ();4 var stopWatchSingle = new Stopwatch ();56 for (var i = 0; i < TotalOperationCalls; i++)7 {8 stopWatchSingle.Start();9 monitoredClass.MonitoredOperation(MethodTime);10 stopWatchSingle.Stop();11 if (i >= TotalOperationCalls - MonitoredOperationCalls)12 {13 ResponseTimes.Add(stopWatchSingle.Elapsed.TotalMilliseconds);14 }15 stopWatchSingle.Reset();16 }1718 #endregion

Listing 6.1: Performance analysis benchmark (excerpt).

57


Listing 6.2 shows the MonitoredClass with its single MonitoredOperation(). Wetried to keep the non-instrumented execution time of the monitored method as closeas possible to the reference value given by the parameter methodTime (we chose 100microseconds). To achieve this, we also utilized the .NET Stopwatch class, the sameclass used for the actual response time measurement as shown before.

1 class MonitoredClass2 {3 readonly Stopwatch _stopWatch = new Stopwatch ();45 [OperationExecutionAspect]6 public void MonitoredOperation(double methodTime)7 {8 _stopWatch.Start();9 while (_stopWatch.Elapsed.TotalMilliseconds < methodTime)10 {11 }12 _stopWatch.Reset();13 }14 }

Listing 6.2: The monitored class containing the single monitored method withparameterized (operation) response time.

In one benchmark run, we call MonitoredOperation() exactly 100,000 times and storeeach response time in an array after a call returns. To avoid scattered results due toincluding the “warm-up phase” in our analysis, we only record the last 10,000 callsmade. Later, we calculate mean, median, and standard deviation values for these 10,000recorded calls. To verify the results, we complete one “initialization” run and five “live”runs subsequently for each stage of the benchmark.

6.2.2. Staged Benchmark Execution

The following staged benchmark design is the core of our analysis. We try to incorporateand distinguish most causes of monitoring overhead by successively enabling the differenttechnologies and frameworks in the five stages of our experiment design. It follows adescription of the stages and justification for why we think which exact overhead istriggered and therefore identified in each single stage.

58


Stage I: Reference

The first stage is the non-instrumented benchmark application. The results of this stageare the reference values for all further comparisons. Every additional microsecond neededby any of the following stages can be considered overhead. The sequence diagram inFigure 6.1(a) shows this. The reference time for the monitored operation will be denotedas ∆I in the remainder of this chapter.

MonitoredClassUserProcess

ΔI


(a) Stage I. Method execution time.

DummyAspectMonitoredClass

OnEntry()

OnExit()

UserProcess

ΔI ΔII


(b) Stage II. Postsharp overhead.

Figure 6.1.: Stages I and II of the experiment design.

Stage II: Postsharp

In the second stage, the overhead that comes with the employment of Postsharp is ana-lyzed. For that, the MonitoredOperation() will be “instrumented” with the quasi emptyDummyAspect shown below in Listing 6.3. The OnEntry() and OnExit() methods are notcomplete stubs to avoid possible compiler optimizations, but the added instructions canbe considered as non-demanding.The resulting sequence diagram in Figure 6.1(b) shows the expected overhead ∆II .

As Postsharp is a compile-time aspect weaver, we expect the performance impact of thisstage to be relatively insignificant.

59


1 [Serializable]2 class DummyAspect : OnMethodBoundaryAspect3 {4 private int _x;56 public override void OnEntry(MethodExecutionArgs args)7 {8 _x = 1;9 }1011 public override void OnExit(MethodExecutionArgs args)12 {13 _x = _x == 1 ? 2 : 1;14 }15 }

Listing 6.3: The “empty” dummy aspect.

Stage III: JNBridge/Kieker #1

In this Stage, the OperationExecutionAspect of Kieker.NET is applied to the Moni-

toredOperation(), but for now, Kieker monitoring will be disabled.A closer look at the OnEntry() and OnExit() methods of the aspect (see Section 5.2)

reveals that in this configuration, the aspect makes exactly one call to the Java-basedMonitoringController before and after execution of MonitoredOperation(), to checkwhether Kieker monitoring is enabled. If not, the aspect methods return immediately.The resulting overhead as depicted in Figure 6.2 is the sum of ∆IIIa and ∆IIIb. Asmentioned before, we will not distinguish between “pure” JNBridge overhead (∆IIIa)and the resulting Java overhead (∆IIIb), because they clearly belong together.As JNBridge supports multiple communication mechanisms, it may also be of in-

terest to show how switching from the allegedly fast shared memory mode to TCP/binary affects the overall performance of Kieker.NET. For that, we include an addi-tional Stage IIITCP in our analysis.

Stage IV: Kieker #2

Now with Kieker monitoring enabled, the full aspect will be executed on each call toMonitoredOperation() in this stage. Figure 6.3 shows the combined monitoring over-head as ∆IV . There is no need for a finer grained classification in this stage, as we

60



OnEntry()

OnExit()

UserProcess

ΔI ΔII

MonitoringControllerProxy JNBridge MonitoringController

isMonitoringEnabled()

isMonitoringEnabled()

ΔIIIa ΔIIIb

MonitoredOperation()Java class

Figure 6.2.: Stage III. Quantification of monitoring overhead induced by JNBridge andbridged Java-side Kieker monitoring controller (with Kieker monitoringdisabled).

incrementally got to this point and can subtract the previous results to get ∆IV without∆II and ∆III included if needed.We set Kieker’s monitoring writer to the DummyWriter class to exclude all possible

hard disk access delay from the observations of this stage. The DummyWriter receives alldata just as, for example, the “regular” AsyncFsWriter, but does nothing further withit, so no overhead coming from storing the monitoring logs can be expected.

Stage V: HDD Access

All that is left for the final stage is enabling Kieker’s actual monitoring log writer, inour case the AsyncFsWriter, and see how flushing the monitored data to the Java-side’s file system impacts the performance of a monitored application. We omit anothersequence diagram for this stage, as it would look exactly like the one of Stage IV shownin Figure 6.3 without going deeper into the class structure of Java-side Kieker.

61



OnEntry()

OnExit()

UserProcess

ΔI ΔIV

MonitoringControllerProxy JNBridge MonitoringController

* *

*

* *

*

MonitoredOperation()Java class

Multiple callsto Java-side

ΔIIIΔII

Figure 6.3.: Stage IV. Quantification of monitoring overhead induced by bridged Java-side Kieker monitoring classes.

6.3. Experiment Results

After executing one “initialization” and five “live” runs for each stage, we collectedmany time measurements concerning the overhead caused by Kieker.NET to a monitoredapplication.

In the first stage, as expected, the execution time of MonitoredOperation() (∆I)is about 100 microseconds. Table 6.1 shows the results of the total of six runs with100,000 (10,000 actually recorded) executions each for Stage I. The measured executiontime is close to the value of 100 microseconds. We suspect the Stopwatch class to beaccountable for the (admittedly very small) difference.

During the following benchmark executions for the Stages II to V, it can be observedthat the results of the initialization and live runs do not significantly deviate from eachother. Therefore, we combine the results of all stages in Table 6.2 and Figure 6.4. Wechoose the results of each stage’s third live run, and use those for the calculation of the∆II to ∆V values, too.

62


Run Init 1st 2nd 3rd 4th 5thMean 100.1547 100.1686 100.0719 100.1165 100.1086 100.0997

Median 100.0000 100.0000 100.0000 100.0000 100.0000 100.0000Std. dev. 0.0026 0.0035 0.0015 0.0022 0.0021 0.0023

Table 6.1.: Stage I experiment results. Response times (in microseconds) of a singleoperation.

100.07

100.12

179.01

242.14

1,526.79

1,563.11

100.00

100.00

175.60

222.00

1,497.50

1,536.20

0 200 400 600 800 1000 1200 1400 1600 1800

I

II

III

III*

IV

V

Execution time (μs)

Mean Median

Figure 6.4.: Micro-benchmark overall performance analysis results (the row marked with(*) is Stage IIITCP).

Stage I II III IIITCP IV VMean 100.0719 100.1212 179.0138 242.1381 1,526.7927 1,563.1077

Median 100.0000 100.0000 175.6000 222.0000 1,497.5000 1,536.2000Std. dev. 0.0015 0.0019 0.0190 0.0328 0.5134 0.5237

Ratio 1.0000 1.0004 1.7888 2.4196 15.2569 15.6198

Table 6.2.: Micro-benchmark overall performance analysis results. Results taken fromeach stage’s third run. All values in microseconds, ratio values are withrespect to Stage I for each stage.

63


∆ II III IIITCP IV V ΣMean 0.0493 78.8926 (142.0169) 1,347.7789 36.3150 1,463.0358

Median 0.0000 75.6000 (122.0000) 1,321.9000 38.7000 1,436.2000

Table 6.3.: Micro-benchmark overhead results. All values in microseconds.

As expected, the overhead induced by Postsharp (∆II) can be considered nonsignif-icant. As shown in Table 6.3, the application of the DummyAspect produced a meanexecution time increase of only .0493 microseconds. This is most probably the executiontime of the two lines of code in each of the aspect’s methods, alongside with the fact thatthe the actual execution of MonitoredOperation is transformed into a try-catch-finallyblock statement by Postsharp at compile-time, as shown in our Postsharp introductionin Section 5.1.1.

The performance impact of applying our OperationExecutionAspect has a differentorder of magnitude. For ∆III (the sum of ∆IIIa and ∆IIIb), we calculate a mean valueof 78.8926 microseconds when using JNBridge’s shared memory communication, and forTCP/binary, the calculated value of ∆IIIT CP

even doubles that with 142.0169 additionalmicroseconds when compared to the results of Stage II.

This significant increase in execution time is coming from the two calls the aspectmakes (one in OnEntry() and one in OnExit()) to the Java-based MonitoringController

instance through the JNBridge proxy class. On the Java-side, there is definitely nocomplex computation involved in checking if Kieker monitoring is enabled (which is notthe case in Stage III).

As our OperationExecutionAspectmakes several calls through JNBridge when Kiekermonitoring is enabled, the results for Stage IV are not surprising after examining theprevious Stage. In Stage IV, we calculated a mean value of 1347.7789 microseconds for∆IV , which is more than a thousand times the reference execution time of about 100microseconds.

Compared to the previous stages, the hard disk access “measured” in Stage V issurprisingly not a major cause of overhead. This is probably due to the rather slowcommunication of JNBridge that gives the asynchronous file system writer of Kiekerplenty of time to be started and executed without affecting the performance at all. Thedeviation of execution times of the Stages IV and V is also almost identical, which is

64


surprising as well, because we expected a greater variability when any hard disk accessis involved.In summary, the total overhead when monitoring a method’s execution with the Post-

sharp/JNBridge-based Kieker.NET is about 1.5 milliseconds.

65

7. Case Study

Aside from the performance impact that our monitoring framework has on the moni-tored application, testing and analyzing its robustness and also its practicality is equallyimportant. For that, HSH Nordbank AG provided us their Nordic Analytics risk as-sessment system as a case study system. We employed Kieker.NET for comprehensivedynamic analysis of Nordic Analytics. The results are presented in this case study.Section 7.1 begins with a short introduction to Nordic Analytics and explains how the

system was used for the analysis. In Section 7.2, we focus on the challenges of findingthe right instrumentation (or monitoring points) to find a adequate balance betweencompleteness of monitoring data regarding the models to be extracted and the sheer sizeand complexity of this data.In Sections 7.3 and 7.4, we present some of the data we obtained from Nordic Ana-

lytics during several monitoring sessions and instrumented evaluations of prepared riskassessment Jobs. This includes multiple extracted component and operation dependencygraphs.To substantiate our results of the overhead analysis with the micro-benchmark in

Chapter 6, we also conducted the same experiment in a comprehensive performance(macro-)benchmark of Nordic Analytics, presented in Section 7.5.

7.1. Nordic Analytics

Nordic Analytics is a complex, C#-based function library for assessment and risk controlof finance products, developed and actively employed by the German financial instituteHSH Nordbank AG.With Nordic Analytics, the user can create/modify and then evaluate a set of diverse

(given) Jobs that contain, for example, valuation of interest rate cap and floor options,Swaptions, TARN, Swaps, or SABR-volatility, employing multiple different financial

67

7. Case Study

Classes 1,657Abstract Classes 136Interfaces 218Enums 234Enums values 1,313Value types 27Properties 4,815Objects 2,272Methods 23,920Total lines of code 390,481Code lines 245,069Comment lines 111,651Empty lines 33,761

Table 7.1.: Code statistics of Nordic Analytics.

models such as Blacksholes, Monte Carlo, etc. This involves complex mathematicalcalculations and tree operations.Nordic Analytics provides an Application Programming Interface (API) and can also

be used either as a function library for Microsoft Excel, where the user can trigger anevaluation of Job data out of Excel, or as a stand-alone console application that has oneor more Jobs formatted as text files, so called Nordic Analytics Object (NAO) files, asinput. These text files are usually generated with Excel as well.Nordic Analytics was first released in 2004 and was initially developed in cooperation

with Prof. Dr. Wolfgang Schmidt from HfB - Frankfurt School of Finance &Management,and is now maintained and further developed by the Financial Engineering departmentof HSH Nordbank AG.

7.1.1. Code Statistics

HSH Nordbank AG provided us with some code statistics of the current version (2.0.52)of Nordic Analytics. Table 7.1 shows those that are relevant to our case study. Thesheer amount of classes and methods is remarkable and—as we will see—introducessome problems when finding the “right” code instrumentation.

68

7.2. Code Instrumentation

7.1.2. Nordic Analytics Monitoring Environment

As Kieker.NET probes can only be applied by re-building the code of an application (thisis because of the post-compile-time aspect weaver of Postsharp), it was not possible tocontinuously monitor Nordic Analytics in its operational “live” environment.Instead, the application we utilized for our case study is Nordic Analytics Console

Application, which can be used to evaluate prepared Jobs. The Financial Engineeringdepartment of HSH Nordbank AG developed a set of test files (or Nordic Analyticsbenchmark), consisting of about 650 Jobs that cover all functionality of Nordic Analyt-ics. To run this test, one can simply point Nordic Analytics Console Application to thefolder that contains all these 650 test files and execute a full evaluation. Our contri-bution to the DynaMod project (in which HSH Nordbank AG participates) focuses onextraction of architectural models, so the monitoring of “artificial” (but probably morecomprehensive) operation was not a drawback for our work at all.During our first monitoring attempts with the newly developed Kieker.NET, we found

that the sheer amount of calculations and repetitive model evaluations of the benchmarkwith 650 Jobs was probably a case of “too much information”. In addition to finding aconvenient instrumentation (i.e., restricting the set of methods that are actually moni-tored to only the important ones), down-scaling of the benchmark was required.With the help of Dr. Marcus Steinkamp of HSH Nordbank AG, we managed to narrow

the test down to 29 Jobs that cover many of the important model evaluations and shouldlead to feasible architectural models when analyzed.


One very challenging task was the process of finding the right code instrumentation(or monitoring points) for Nordic Analytics. As shown in Table 7.1, Nordic Analyticsis a rather complex system, consisting of many components. The monitoring with thefirst instrumentation we came up with—after first discussions with the developers of thesystem—had to be cancelled after eight days of continuous monitoring and producingmore than 40 GB of monitoring logs. At that moment, only four of the 650 Jobs had beencompleted. The resulting assembly component dependency graph we—out of curiosity—created with Kieker is shown in Figure 7.1. Creating an operation dependency graph or

69

7. Case Study

Figure 7.1.: Nordic Analytics component dependency graph with (close-to) full instru-mentation, generated with Kieker.TraceAnalysis.

even a call tree was impossible with all tools we tested, because the complexity of thedata caused out-of-memory terminations all the time.With elaborated aspect multicast attributes and filters (see Listing 7.1), we limited

our instrumentation of Nordic Analytics to 2,863 of the total 23,920 methods, primarilyby trying to avoid instrumentation of accessor and mutator methods, as well as some“low-level” methods used excessively by some complex calculations.Together with limiting the number of Jobs executed while monitoring to only 29,

this rather sophisticated set of aspect multicast attributes and filters allowed us togather much smaller monitoring logs, and therefore enabled us to finally extract moremeaningful system models than the “negative example” shown in Figure 7.1.

1 // Includes23 [assembly: OperationExecutionAspect(4 AttributeTargetTypes = "NordicAnalyticsProject.Engine.Analytics .*")]5 [assembly: OperationExecutionAspect(6 AttributeTargetTypes = "NordicAnalyticsProject.Engine.Evaluation .*")]7 [assembly: OperationExecutionAspect(8 AttributeTargetTypes = "NordicAnalyticsProject.Engine.Job.*")]9 [assembly: OperationExecutionAspect(10 AttributeTargetTypes = "NordicAnalyticsProject.Engine.ObjectFactory.

cObjectPool")]

70


11 [assembly: OperationExecutionAspect(12 AttributeTargetTypes = "NordicAnalyticsProject.Engine.Result .*")]13 [assembly: OperationExecutionAspect(14 AttributeTargetTypes = "NordicAnalyticsProject.Engine.Securities .*")]1516 // Excludes1718 [assembly: OperationExecutionAspect(19 AttributePriority = 5,20 AttributeExclude = true ,21 AttributeTargetTypes = "NordicAnalyticsProject.Engine.Analytics.

ObjectFunctions .*")]22 [assembly: OperationExecutionAspect(23 AttributePriority = 5,24 AttributeExclude = true ,25 AttributeTargetTypes = "NordicAnalyticsProject.Engine.Analytics.

cAnalyticsConstructorLog")]26 [assembly: OperationExecutionAspect(27 AttributePriority = 5,28 AttributeExclude = true ,29 AttributeTargetTypes = "NordicAnalyticsProject.Engine.Evaluation.

PricingModels.AmericanOptionPricingModel .*")]30 [assembly: OperationExecutionAspect(31 AttributePriority = 5,32 AttributeExclude = true ,33 AttributeTargetTypes = "NordicAnalyticsProject.Engine.Evaluation.

PricingModels.BermudanStyleOptionPricingModel.NormalShortRateTreeModel .*")]

34 [assembly: OperationExecutionAspect(35 AttributePriority = 5,36 AttributeExclude = true ,37 AttributeTargetTypes = "NordicAnalyticsProject.Engine.Securities.

cCashFlowDescriptionTableFloatFlowDescription")]38 [assembly: OperationExecutionAspect(39 AttributePriority = 5,40 AttributeExclude = true ,41 AttributeTargetTypes = "NordicAnalyticsProject.Engine.Securities.

cCashFlowDateGrid")]4243 // Removing ctors , getters , setters , and NA-intrinsic tracking methods.4445 [assembly: OperationExecutionAspect(46 AttributePriority = 10,47 AttributeExclude = true ,48 AttributeTargetMembers = "regex:ctor|get_ .*| set_ .*| TrackUsage .*")]

Listing 7.1: Aspect multicast attributes and filters, leading to 2.836 instrumentedmethods of Nordic Analytics.

71

7. Case Study

7.3. Dynamic Analysis of Nordic Analytics

After the optimization of the number and exact locations of monitoring points as de-scribed before, we were finally able to extract plenty of useful data from Nordic Analytics.Of the 2,863 methods we instrumented with our OperationExecutionAspect, a total

of 1,087 methods were actually called during the execution of Nordic Analytics ConsoleApplication evaluating the 29 Jobs of the benchmark we prepared.The full monitored execution resulted in a total of 51 Kieker monitoring log files,

with a combined file size of 357 MB. These monitoring log files contain execution dataof 1,255,467 operations (i.e., method calls), including trace and timing information foreach operation execution.In Table 7.2, we present some information about each individual Job. This data was

collected not by monitoring a sequential execution of all 29 Jobs, but by starting NordicAnalytics Console Application for each Job individually. This is why the sum of alloperation executions in Table 7.2 is not exactly equal to 1,255,467 (i.e., the numberwe determined out of a single sequential execution of all 29 Jobs in a row as describedabove). Obviously, there was a (very small) “infrastructural overhead” included in themonitoring data when starting each Job individually. On the other hand, the resultsshow that our instrumentation seems to “avoid” almost all methods that are not directlyrelated to Job evaluation, which is good, as we can be sure that the monitoring pointswe chose cover only the core functionality of Nordic Analytics.

7.4. Architecture-Based Model Extraction

One of the main goals of our work is to provide the means for architecture-based modelextraction of .NET applications. With our implementation of Kieker.NET, we wereable to generate the monitoring log files that allowed comprehensive models of NordicAnalytics to be created with Kieker’s trace analysis tool Kieker.TraceAnalysis.We start with a sequence diagram that has been created manually prior to our case

study by a member of the Financial Engineering department of HSH Nordbank AG(Figure 7.2). It shows the expected internal component dependencies and control flowfor an evaluation of a (rather simple) Swaption valuation with Nordic Analytics.In Figure 7.3, we show an assembly component dependency graph created out of moni-

toring logs obtained by monitoring evaluation of Job 7, which is also a Swaption valuation

72


Job Operation executions Monitoring log size (MB))1 6,212 1.462 8,139 1.943 254,000 60.704 62,292 16.205 3,973 0.946 1,797 0.427 1,802 0.438 11,573 2.799 5,669 1.3510 4,301 1.0011 46,105 12.1012 84,842 26.7013 4,498 1.0514 10,598 3.5915 9,332 3.0016 95,785 32.7017 3,283 0.8018 230,099 60.6019 56,966 16.7020 3,130 0.7421 3,113 0.7322 64,053 20.8023 139,168 45.8024 44,574 15.7025 29,930 7.0326 907 0.2927 49,540 17.3028 14,448 3.4229 5,422 1.27Σ 1,255,551 357.56

Table 7.2.: Detailed monitored Job statistics.

73

7. Case Study

much like the depicted execution in the manually created sequence diagram. The cor-responding assembly operation dependency graph and aggregated assembly call tree, alsocreated with Kieker.TraceAnalysis, are shown in Figures 7.4 and 7.5.Figures 7.6 and 7.7 then present the extracted models of the evaluation of two more

complex Jobs (5 and 29), involving Constant Maturity Swaps (CMS) and utilization ofstatic replication models by Hagan.Finally, Figure 7.8 shows the combined result of our refined instrumentation, the

assembly component dependency diagram of the evaluation of all 29 Jobs of the bench-mark. Opposed to the “negative example” shown in Figure 7.1, this graph actuallycould (and probably will) be a valuable source of information when used in architecturalanalysis of Nordic Analytics.All following models except Figure 7.2 are vector graphics that allow seamless zooming

when viewed in digital format.

74


Figure 7.2.: Nordic Analytics components involved in a (rather simple) Swaption valu-ation. The Sequence diagram was manually created prior to our case studyby a member of the Financial Engineering department of HSH NordbankAG.

75

7. Case Study

$<

<as

sem

bly

com

pone

nt>

>@

1:..c

Ana

lytic

s7

<<

asse

mbl

y co

mpo

nent

>>

@6:

..cS

ingl

eOpt

ionS

ecur

ity

1

<<

asse

mbl

y co

mpo

nent

>>

@15

:..cJ

obO

bjec

t

1

<<

asse

mbl

y co

mpo

nent

>>

@2:

..cV

aRM

etho

dFac

tory

2

<<

asse

mbl

y co

mpo

nent

>>

@3:

..cA

ccru

alC

onve

ntio

n

1343

<<

asse

mbl

y co

mpo

nent

>>

@4:

..cO

bjec

tPoo

l

22

<<

asse

mbl

y co

mpo

nent

>>

@8:

..cS

ecur

ityF

acto

ry1

<<

asse

mbl

y co

mpo

nent

>>

@9:

..cM

odel

Typ

e5

<<

asse

mbl

y co

mpo

nent

>>

@10

:..cM

odel

Par

amet

ers

2

<<

asse

mbl

y co

mpo

nent

>>

@11

:..cM

odel

Des

crip

tion

1

<<

asse

mbl

y co

mpo

nent

>>

@12

:..cJ

obD

escr

ipto

r

1

<<

asse

mbl

y co

mpo

nent

>>

@13

:..cE

valu

atio

nObj

ects

8

<<

asse

mbl

y co

mpo

nent

>>

@14

:..cJ

ob

7

<<

asse

mbl

y co

mpo

nent

>>

@5:

..cS

ecur

ity

<<

asse

mbl

y co

mpo

nent

>>

@7:

..cS

wap

tion

1

11 1

<<

asse

mbl

y co

mpo

nent

>>

@17

:..cS

ecur

ityD

epen

denc

y3

3

64

<<

asse

mbl

y co

mpo

nent

>>

@18

:..cV

alua

tionD

ateF

inde

r

1

<<

asse

mbl

y co

mpo

nent

>>

@25

:..cV

alua

tionC

ontr

ol1

<<

asse

mbl

y co

mpo

nent

>>

@26

:..cI

mpl

icitC

alib

ratio

n

3

68

<<

asse

mbl

y co

mpo

nent

>>

@16

:..cT

ypeF

ilter

10

<<

asse

mbl

y co

mpo

nent

>>

@19

:..cP

ricin

g

31

1

1

<<

asse

mbl

y co

mpo

nent

>>

@24

:..cS

wap

tionP

ricin

gMod

el2

<<

asse

mbl

y co

mpo

nent

>>

@20

:..cS

wap

tionP

ricin

gAna

lytic

512

4

<<

asse

mbl

y co

mpo

nent

>>

@21

:..cP

lain

Sw

apD

ateG

rid1

<<

asse

mbl

y co

mpo

nent

>>

@22

:..cP

lain

Sw

apP

ricin

g

2

25

<<

asse

mbl

y co

mpo

nent

>>

@23

:..cS

wap

tionP

ricin

gRes

ult

2 1

1

1

2

7

Figure 7.3.: Assembly component dependency graph of the monitored execution ofNordic Analytics evaluating a Swaption valuation using a Blackscholesmodel (Job 7).

76


<<assembly component>>@26:..cImplicitCalibration

<<assembly component>>@25:..cValuationControl

<<assembly component>>@24:..cSwaptionPricingModel

<<assembly component>>@23:..cSwaptionPricingResult

<<assembly component>>@22:..cPlainSwapPricing

<<assembly component>>@21:..cPlainSwapDateGrid

<<assembly component>>@20:..cSwaptionPricingAnalytic

<<assembly component>>@19:..cPricing

<<assembly component>>@18:..cValuationDateFinder

<<assembly component>>@17:..cSecurityDependency

<<assembly component>>@16:..cTypeFilter

<<assembly component>>@15:..cJobObject

<<assembly component>>@14:..cJob

<<assembly component>>@13:..cEvaluationObjects

<<assembly component>>@12:..cJobDescriptor

<<assembly component>>@11:..cModelDescription

<<assembly component>>@10:..cModelParameters

<<assembly component>>@9:..cModelType

<<assembly component>>@8:..cSecurityFactory

<<assembly component>>@7:..cSwaption

<<assembly component>>@6:..cSingleOptionSecurity

<<assembly component>>@5:..cSecurity

<<assembly component>>@4:..cObjectPool

<<assembly component>>@3:..cAccrualConvention

<<assembly component>>@2:..cVaRMethodFactory

<<assembly component>>@1:..cAnalytics

IsCalibrated(..)

Evaluate(..)

InitializeLMMPricing(..)

1

InitializeCommodityMCPricing(..)

1

InitializeIndexMCPricing(..)1

IsHistoricalSecurity(..)

1

IsShortRateMC(..)

1

CreateSwaptionPricing(..)

1

Price(..)

1

JobPartObjects(..)

2

SetJobPart(..)

1

GetHashCode()

1

Price(..)

PriceSwaption(..)

1

SetResultProperties(..)1

GetSpecificMarketData(..)

1

PriceSwaption(..)

1

GetPricingResult(..) AddResultProperty(..)11

AddResultProperty(..)

1

FairRate(..)

PriceFloatLeg(..)

1PriceFixLeg(..)1

PriceFloatCF(..)10

PriceFixCF(..)10

BuildDateGrids(..) GetAdditionalDays(..)25

GetVolatility(..)1

GetObject(..)

3

GetObject(..)

1

PriceSwaption(..)1

1

1

1

GetBlackScholesOptionType(..)

1GetSwaptionValueEvaluationType(..)1

StoreAdditionalPricingResults(..)

1

GetSwapTenor()2

GetSwapTenorTime()

1

5

GetEndDate()1

Price(..)1

AddIPricingResults(..)

1

1

1

1

1

2

1

GetValuationDate()

GetObject(..)

GetDependencies()

ReplaceDependence()

Accept(..)

Objects(..)

10

Objects(..)

29

GetObjects(..)GetObjects(..)3

35

ReplaceDependence(..)ReplaceDependence(..)1

GetUseUsageTracking(..)

InitializeMarketDataUsageTracking()

9

InitializeObjectTracking(..)

9

InitializeUsageTracking()

9

1

9

1

InitializeTemplateObjects()

SetStoreLossDistributions()

InitializePartialJobs(..)

10

Evaluate()

1

1

1

1

1

1

BuildNotBuiltDefaultCurves()

1

ToString()1

ClearIntermediateObjects()

1

MarketDataUsageCheck()

1

1

321

SetObjectAndCheckImpliedCalibration(..)2

2

3

9

FindCollections(..)

SetCollectionObjects(..)

GetObjectSignatures(..)

CheckObjectsAreUnique(..)

InitializeObjects()

CopyOrId(..)

ReplaceDependenceByObjectSignature()

1

1

1

1

GetObjects()4

GetDependencyHandle()

1

ReadObjectsTable(..) ReadObjectsTable(..)1

ReadObjects(..)1

ProveOfUniqueObjects(..)

1

CheckNumberOfObjects(..)

2

ReadScenarioTable(..)

InitMembersWithCorrespondingNullValues()

Initialize(..)

ReadMethodAssetClassSpecification(..)

GetDefaultIRSubModelType(..)

InitializeMethodAssetClassSpecification()

ReadAnalyticMethodsTable(..)

CreateInstance(..)

ReadDescriptionTableProperties(..)

1

ReadCurrencyProperty(..)

1

GetUnderlyingCashRateIndex()1

ReadDescriptionTableProperties(..)

1

GetCreditNames()

Insert(..) OnInsertObject(..)7

OnClearPool()

Create(..)

GetVersionNumber()

GetCompilationDate()

SetContactMessage()

ReadObjectsFromFile(..) CreateObject(..)6

CreateObject(..)6

CreateObjectPreProcessing(..)6

CreateObject(..)

6

1

1

1

1

1

1

1

1

1

1343

2

CreateObjectPostProcessing(..)

6

6

EvaluateJob(..)

1

1

1

1

1

1

1

1

1

1

1

1

3

1

1

WriteLogInfo(..)1

WriteLogInfo(..)1

WriteObjectsToFile(..) GetOutConverter(..)1

ClearPools()

15

$

1

1

1

1

1

1

1

1

1

Figure 7.4.: Assembly operation dependency graph of a monitored execution of NordicAnalytics evaluating a Swation valuation utilizing a Blackscholes model(Job 7).

77

7. Case Study

$

@1:..cAnalytics

.GetVersionNumber()

1

@1:..cAnalytics

.GetCompilationDate()

1

@1:..cAnalytics

.SetContactMessage()

1

@1:..cAnalytics

.ReadObjectsFromFile(..)

1

@1:..cAnalytics

.EvaluateJob(..)

1

@6:..cSingleOptionSecurity

.GetCreditNames()

1

@15:..cJobObject

.GetObjects(..)

1

@1:..cAnalytics

.WriteObjectsToFile(..)

1

@1:..cAnalytics

.ClearPools()

1

@1:..cAnalytics

.CreateObject(..)

6

@1:..cAnalytics

.CreateObject(..)

6

@1:..cAnalytics

.CreateObjectPreProcessing(..)

6

@1:..cAnalytics

.CreateObject(..)

6

@2:..cVaRMethodFactory

.Create(..)

2

@3:..cAccrualConvention

.GetAdditionalDays(..)

1343

@1:..cAnalytics

.CreateObjectPostProcessing(..)

6

@8:..cSecurityFactory

.CreateInstance(..)

1

@9:..cModelType

.ReadM

ethodAssetClassSpecification(..)

1

@9:..cModelType

.GetDefaultIRSubModelType(..)

1

@9:..cModelType

.InitializeMethodAssetClassSpecification()

1

@9:..cModelType

.ReadAnalyticMethodsTable(..)

1

@10:..cM

odelParameters

.InitMembersWithCorrespondingNullValues()

1

@10:..cM

odelParameters

.Initialize(..)

1

@11:..cM

odelDescription

.ReadScenarioTable(..)

1

@12:..cJobDescriptor

.ReadObjectsTable(..)

1

@4:..cObjectPool

.Insert(..)

6

@4:..cObjectPool

.OnInsertObject(..)

6

@5:..cSecurity

.ReadCurrencyProperty(..)

1

@7:..cSwaption

.ReadDescriptionTableProperties(..)

1


.ReadDescriptionTableProperties(..)

1

@7:..cSwaption

.GetUnderlyingCashRateIndex()

1


.ReadObjectsTable(..)

1


.ReadObjects(..)

1


.ProveOfUniqueObjects(..)

1


.CheckNumberOfObjects(..)

2

@13:..cEvaluationObjects

.FindCollections(..)

1


.SetCollectionObjects(..)

1


.GetObjectSignatures(..)

1


.CheckObjectsAreUnique(..)

1


.InitializeObjects()

1


.CopyOrId(..)

3

@9:..cModelType

.InitializeMethodAssetClassSpecification()

1

@14:..cJob

.GetUseUsageTracking(..)

1

@14:..cJob

.InitializeMarketDataUsageTracking()

1

@14:..cJob

.InitializeUsageTracking()

1

@14:..cJob

.InitializeTemplateObjects()

1

@14:..cJob

.SetStoreLossDistributions()

1

@14:..cJob

.InitializePartialJobs(..)

1

@14:..cJob

.Evaluate()

1

@1:..cAnalytics

.WriteLogInfo(..)

1

@4:..cObjectPool

.Insert(..)

1

@1:..cAnalytics

.WriteLogInfo(..)

1

@15:..cJobObject

.Objects(..)

9

@14:..cJob

.InitializeObjectTracking(..)

9

@15:..cJobObject

.Objects(..)

9


.Objects(..)

9

@16:..cTypeFilter

.Accept(..)

3

@15:..cJobObject

.GetObjects(..)

1

@15:..cJobObject

.Objects(..)

9

@14:..cJob

.InitializeObjectTracking(..)

9

@5:..cSecurity

.GetHashCode()

1


.GetObjects(..)

1

@15:..cJobObject

.Objects(..)

9


.Objects(..)

9

@16:..cTypeFilter

.Accept(..)

3

@15:..cJobObject

.JobPartObjects(..)

10

@15:..cJobObject

.JobPartObjects(..)

10


.Objects(..)

10

@15:..cJobObject

.Objects(..)

1

@15:..cJobObject

.ReplaceDependence(..)

1

@14:..cJob

.BuildNotBuiltDefaultCurves()

1

@15:..cJobObject

.GetObjects(..)

1

@14:..cJob

.ToString()

1

@18:..cValuationDateFinder

.GetValuationDate()

1

@25:..cValuationControl

.Evaluate(..)

1

@14:..cJob

.ClearIntermediateObjects()

1

@15:..cJobObject

.JobPartObjects(..)

1

@14:..cJob

.MarketDataUsageCheck()

1


.Objects(..)

1

@16:..cTypeFilter

.Accept(..)

1


.ReplaceDependence(..)

1


.ReplaceDependenceByObjectSignature()

1


.GetObjects()

4

@5:..cSecurity

.GetDependencyHandle()

1 @17:..cSecurityDependency

.GetObject(..)

1

@17:..cSecurityDependency

.GetDependencies()

1

@17:..cSecurityDependency

.ReplaceDependence()

1

@15:..cJobObject

.Objects(..)1


.Objects(..)

1


.GetObjects(..)

1

@14:..cJob

.SetJobPart(..)

1

@15:..cJobObject

.JobPartObjects(..)

2

@19:..cPricing

.InitializeLMMPricing(..)

1

@19:..cPricing

.InitializeCommodityMCPricing(..)

1

@19:..cPricing

.InitializeIndexMCPricing(..)

1

@19:..cPricing

.IsHistoricalSecurity(..)

1

@19:..cPricing

.IsShortRateMC(..)

1

@19:..cPricing

.CreateSwaptionPricing(..)

1

@5:..cSecurity

.GetHashCode()

1

@19:..cPricing

.Price(..)

1

@15:..cJobObject

.JobPartObjects(..)

2


.Objects(..)

2

@7:..cSwaption

.GetEndDate()

1

@14:..cJob

.SetJobPart(..)

1

@15:..cJobObject

.JobPartObjects(..)

1

@19:..cPricing

.Price(..)

1

@5:..cSecurity

.GetHashCode()

1

@19:..cPricing

.AddIPricingResults(..)

1

@15:..cJobObject

.JobPartObjects(..)1


.Objects(..)

1

@5:..cSecurity

.GetHashCode()2

@24:..cSwaptionPricingM

odel

.Price(..)

1


odel

.PriceSwaption(..)

1

@20:..cSwaptionPricingAnalytic

.GetSpecificMarketData(..)

1


.PriceSwaption(..)

1

@23:..cSwaptionPricingResult

.SetResultProperties(..)

1

@14:..cJob

.GetObject(..)

3


.GetVolatility(..)

1

@14:..cJob

.GetObject(..)

3

@15:..cJobObject

.JobPartObjects(..)

4

@14:..cJob

.SetObjectAndCheckImpliedCalibration(..)

1

@5:..cSecurity

.GetHashCode()

1

@15:..cJobObject

.JobPartObjects(..)

4


.Objects(..)

4

@14:..cJob

.GetObject(..)

1

@15:..cJobObject

.JobPartObjects(..)

17

@14:..cJob

.SetObjectAndCheckImpliedCalibration(..)

1

@5:..cSecurity

.GetHashCode()

1

@15:..cJobObject

.JobPartObjects(..)

17


.Objects(..)

17


.PriceSwaption(..)

1

@7:..cSwaption

.GetSwapTenor()

2

@21:..cPlainSwapDateGrid

.BuildDateGrids(..)

1

@22:..cPlainSwapPricing

.FairRate(..)

1


.PriceFixLeg(..)

1



5


.GetBlackScholesOptionType(..)

1


.GetSwaptionValueEvaluationType(..)

1


.GetSwapTenorTime()

1


.StoreAdditionalPricingResults(..)

1



25


.PriceFloatLeg(..)

1


.PriceFixLeg(..)

1


.PriceFloatCF(..)

10


.PriceFixCF(..)

5


.PriceFixCF(..)

5


.AddResultProperty(..)

11


.AddResultProperty(..)

1


odel

.GetPricingResult(..)

1

@15:..cJobObject

.JobPartObjects(..)

1


.Objects(..)

1

@15:..cJobObject

.Objects(..)

9

@26:..cImplicitCalibration

.IsCalibrated(..)

3

@15:..cJobObject

.Objects(..)

9


.Objects(..)9

@16:..cTypeFilter

.Accept(..)

3

@4:..cObjectPool

.OnInsertObject(..)

1


.GetObjects(..)

1

@1:..cAnalytics

.GetOutConverter(..)

1

@4:..cObjectPool

.OnClearPool()

15

Figure 7.5.: Aggregated assembly call tree of a monitored execution of Nordic Analyticsevaluating a Swation valuation utilizing a Blackscholes model (Job 7).

78


$<

<as

sem

bly

com

pone

nt>

>@

1:..c

Ana

lytic

s7

<<

asse

mbl

y co

mpo

nent

>>

@6:

..cS

wap

1

<<

asse

mbl

y co

mpo

nent

>>

@33

:..cJ

obO

bjec

t

1<

<as

sem

bly

com

pone

nt>

>@

2:..c

Obj

ectP

ool

27<

<as

sem

bly

com

pone

nt>

>@

3:..c

VaR

Met

hodF

acto

ry3

<<

asse

mbl

y co

mpo

nent

>>

@5:

..cC

redi

tBas

kets

1

<<

asse

mbl

y co

mpo

nent

>>

@14

:..cS

crip

tTab

les

1

<<

asse

mbl

y co

mpo

nent

>>

@25

:..cS

ecur

ityF

acto

ry

1

<<

asse

mbl

y co

mpo

nent

>>

@26

:..cM

odel

Typ

e

5

<<

asse

mbl

y co

mpo

nent

>>

@27

:..cM

odel

Par

amet

ers

2

<<

asse

mbl

y co

mpo

nent

>>

@28

:..cM

odel

Des

crip

tion

1

<<

asse

mbl

y co

mpo

nent

>>

@29

:..cJ

obD

escr

ipto

r1

<<

asse

mbl

y co

mpo

nent

>>

@30

:..cE

valu

atio

nObj

ects

13

<<

asse

mbl

y co

mpo

nent

>>

@31

:..cJ

ob

7

<<

asse

mbl

y co

mpo

nent

>>

@4:

..cS

ecur

ity

1

<<

asse

mbl

y co

mpo

nent

>>

@7:

..cL

egD

escr

ipto

r

4

<<

asse

mbl

y co

mpo

nent

>>

@10

:..cL

eg

32

<<

asse

mbl

y co

mpo

nent

>>

@16

:..cS

crip

tCas

hFlo

wH

andl

er2

<<

asse

mbl

y co

mpo

nent

>>

@43

:..cC

olle

ctor

1

<<

asse

mbl

y co

mpo

nent

>>

@8:

..cP

ayof

fDes

crip

tor

4

20

<<

asse

mbl

y co

mpo

nent

>>

@9:

..cC

redi

tDes

crip

tor

2424

<<

asse

mbl

y co

mpo

nent

>>

@11

:..cC

ashF

low

Bui

lder

4

<<

asse

mbl

y co

mpo

nent

>>

@13

:..cC

ashF

low

100

<<

asse

mbl

y co

mpo

nent

>>

@22

:..cC

ashF

low

Scr

iptG

ener

ator

20

<<

asse

mbl

y co

mpo

nent

>>

@36

:..cC

heck

Cur

renc

y40

<<

asse

mbl

y co

mpo

nent

>>

@37

:..cC

heck

Inde

x

40

<<

asse

mbl

y co

mpo

nent

>>

@42

:..cI

ndex

Fix

ingD

escr

iptio

nCol

lect

or

40

<<

asse

mbl

y co

mpo

nent

>>

@47

:..cL

MM

Pric

ing+

cDat

esC

olle

ctor

20

<<

asse

mbl

y co

mpo

nent

>>

@48

:..cI

ndex

Nam

eCol

lect

or

20

<<

asse

mbl

y co

mpo

nent

>>

@56

:..cC

heck

Scr

iptF

unct

ionA

rgum

ents

20

<<

asse

mbl

y co

mpo

nent

>>

@67

:..cC

urre

ncyC

olle

ctor

20

20

20

<<

asse

mbl

y co

mpo

nent

>>

@12

:..cA

ccru

alC

onve

ntio

n

20

20

2020

<<

asse

mbl

y co

mpo

nent

>>

@15

:..cS

crip

tPar

amet

ers

<<

asse

mbl

y co

mpo

nent

>>

@17

:..cF

orm

ulaB

uild

er

20

<<

asse

mbl

y co

mpo

nent

>>

@18

:..cS

tand

ardF

orm

ulaB

uild

er

2020

<<

asse

mbl

y co

mpo

nent

>>

@19

:..cS

crip

tOpt

ions

<<

asse

mbl

y co

mpo

nent

>>

@20

:..cR

epla

ceIn

dexN

ameB

yFun

ctio

n

<<

asse

mbl

y co

mpo

nent

>>

@21

:..cS

crip

t30 60

<<

asse

mbl

y co

mpo

nent

>>

@45

:..cS

etIn

dex

40

<<

asse

mbl

y co

mpo

nent

>>

@62

:..cS

etIn

dexV

alue

s

500

40

20

402040

<<

asse

mbl

y co

mpo

nent

>>

@23

:..cO

ptio

nDes

crip

tor

<<

asse

mbl

y co

mpo

nent

>>

@24

:..cO

ptio

nSw

ap1

5

1

2

7

41

5

1<

<as

sem

bly

com

pone

nt>

>@

34:..

cSec

urity

Dep

ende

ncy

3

2

172

<<

asse

mbl

y co

mpo

nent

>>

@35

:..cV

alua

tionD

ateF

inde

r

1

<<

asse

mbl

y co

mpo

nent

>>

@75

:..cV

alua

tionC

ontr

ol1

<<

asse

mbl

y co

mpo

nent

>>

@76

:..cI

mpl

icitC

alib

ratio

n7

<<

asse

mbl

y co

mpo

nent

>>

@32

:..cT

ypeF

ilter

177

25

40

20

<<

asse

mbl

y co

mpo

nent

>>

@38

:..cL

MM

Pric

ing+

cSec

urity

Che

ckF

orL

MM

4

<<

asse

mbl

y co

mpo

nent

>>

@39

:..cP

ortf

olio

3

1

2

1

1

<<

asse

mbl

y co

mpo

nent

>>

@40

:..cL

MM

Pric

ing

10

3

5

<<

asse

mbl

y co

mpo

nent

>>

@46

:..cP

ricin

gPar

ams

1

<<

asse

mbl

y co

mpo

nent

>>

@49

:..cL

ibor

Dat

eGrid

6

<<

asse

mbl

y co

mpo

nent

>>

@54

:..cL

ibor

Sam

ples

Fac

tory

1

<<

asse

mbl

y co

mpo

nent

>>

@41

:..cS

crip

tInd

exD

escr

ipto

rFun

ctio

n

<<

asse

mbl

y co

mpo

nent

>>

@44

:..cT

erm

Tre

eFun

ctio

nInd

ex25

0

2

40

40 20 2010 21

20

40

113

8

20

20

20

1

2020

<<

asse

mbl

y co

mpo

nent

>>

@50

:..cL

ibor

Sam

ples

5991

<<

asse

mbl

y co

mpo

nent

>>

@52

:..cS

imul

atio

nPar

amsL

SF

acto

ry1

<<

asse

mbl

y co

mpo

nent

>>

@68

:..cL

ibor

Mar

ketM

odel

10

<<

asse

mbl

y co

mpo

nent

>>

@51

:..cS

imul

atio

nPar

amsL

SL

NF

acto

ry2

<<

asse

mbl

y co

mpo

nent

>>

@53

:..cL

ibor

Sam

ples

LN

1439

1

6

3

<<

asse

mbl

y co

mpo

nent

>>

@55

:..cP

ricin

g3

1

1

1 1

4

<<

asse

mbl

y co

mpo

nent

>>

@57

:..cM

onte

Car

loP

ricin

g

2

10

1

3

8

1060

250

139

6

2

4

24

36

<<

asse

mbl

y co

mpo

nent

>>

@58

:..cP

ricin

gPar

amsS

crip

t

4

<<

asse

mbl

y co

mpo

nent

>>

@59

:..cS

crip

tPric

ingP

aram

sMC

7

<<

asse

mbl

y co

mpo

nent

>>

@60

:..cL

ibor

Sam

ples

Num

erai

re

52

<<

asse

mbl

y co

mpo

nent

>>

@61

:..cC

ashF

low

Tot

alN

ameC

ompa

rer

6055

<<

asse

mbl

y co

mpo

nent

>>

@63

:..cS

crip

tEva

luat

ion

1450

<<

asse

mbl

y co

mpo

nent

>>

@64

:..cS

crip

tCF

Det

ails

500

<<

asse

mbl

y co

mpo

nent

>>

@65

:..cM

onte

Car

loP

ricin

g+C

onst

antO

ne50

0

<<

asse

mbl

y co

mpo

nent

>>

@66

:..cF

low

Mat

rix50

0

<<

asse

mbl

y co

mpo

nent

>>

@70

:..cF

low

Det

ails

201

<<

asse

mbl

y co

mpo

nent

>>

@71

:..cO

ccur

ence

2

<<

asse

mbl

y co

mpo

nent

>>

@72

:..cS

crip

tRes

ultG

ener

ator

Par

ams

502

<<

asse

mbl

y co

mpo

nent

>>

@73

:..cS

crip

tRes

ults

Gen

erat

or10

<<

asse

mbl

y co

mpo

nent

>>

@74

:..cP

athW

iseR

esul

t

1

2

20

1

1

6

210

250

250

20

<<

asse

mbl

y co

mpo

nent

>>

@69

:..cF

low

Det

ails

Row

158

1985

2

1040

20

2

2

222 305

20 20

20

1

1

2

6

Figure 7.6.: Assembly component dependency graph of a monitored execution of NordicAnalytics evaluating a computationally intensive CMS utilizing a staticreplication model by Hagan (Job 29).

79

7. Case Study

<<assembly component>>@55:..cImplicitCalibration

<<assembly component>>@54:..cValuationControl

<<assembly component>>@53:..cSecurityDetailsCFP

<<assembly component>>@52:..cLegDetailsCFP

<<assembly component>>@51:..cCashRateVolatilityFinder

<<assembly component>>@50:..cAccruedInterestCalculator

<<assembly component>>@49:..cSwapRateVolatilityFinder

<<assembly component>>@48:..cVolatilityFinder

<<assembly component>>@47:..cIndexSpreadModel

<<assembly component>>@46:..cMarketAnalyticModel

<<assembly component>>@45:..cReplicationModelLRM

<<assembly component>>@44:..cSetIndex

<<assembly component>>@43:..cTermTreeFunctionIndex

<<assembly component>>@42:..cPlainSwapDateGrid

<<assembly component>>@41:..cPricingParamsCFP

<<assembly component>>@40:..cPricingParamsCreditLinked

<<assembly component>>@39:..cPricingParams

<<assembly component>>@38:..cCollector

<<assembly component>>@37:..cScriptIndexDescriptorFunction

<<assembly component>>@36:..cIndexFixingDescriptionCollector

<<assembly component>>@35:..cCashFlowPricingModel

<<assembly component>>@34:..cPricing

<<assembly component>>@33:..cValuationDateFinder

<<assembly component>>@32:..cSecurityDependency

<<assembly component>>@31:..cJobObject

<<assembly component>>@30:..cTypeFilter

<<assembly component>>@29:..cJob

<<assembly component>>@28:..cEvaluationObjects

<<assembly component>>@27:..cJobDescriptor

<<assembly component>>@26:..cModelDescription

<<assembly component>>@25:..cModelParameters

<<assembly component>>@24:..cModelType

<<assembly component>>@23:..cSecurityFactory

<<assembly component>>@22:..cCashFlowScriptGenerator

<<assembly component>>@21:..cScript

<<assembly component>>@20:..cReplaceIndexNameByFunction

<<assembly component>>@19:..cScriptOptions

<<assembly component>>@18:..cStandardFormulaBuilder

<<assembly component>>@17:..cFormulaBuilder

<<assembly component>>@16:..cScriptCashFlowHandler

<<assembly component>>@15:..cScriptParameters

<<assembly component>>@14:..cScriptTables

<<assembly component>>@13:..cCashFlow

<<assembly component>>@12:..cCashFlowBuilder

<<assembly component>>@11:..cLeg

<<assembly component>>@10:..cCreditDescriptor

<<assembly component>>@9:..cPayoffDescriptor

<<assembly component>>@8:..cLegDescriptor

<<assembly component>>@7:..cSwap

<<assembly component>>@6:..cCreditBaskets

<<assembly component>>@5:..cSecurity

<<assembly component>>@4:..cAccrualConvention

<<assembly component>>@3:..cVaRMethodFactory

<<assembly component>>@2:..cObjectPool

<<assembly component>>@1:..cAnalytics

IsCalibrated(..)

Evaluate(..)

InitializeSubModels(..)

1

InitializeDelegates(..)

1

InitializePrepareForPricingDelegate()

1

InitializeLMMPricing(..)1

InitializeCommodityMCPricing(..)

1

InitializeIndexMCPricing(..)

1

IsHistoricalSecurity(..)

1

IsShortRateMC(..)

1

IsCashflowPricing(..)

1

Price(..)

1

JobPartObjects(..)

2

SetJobPart(..)

1

GetHashCode()

1

CompleteSecurityDetails(..)

CompleteSecurityDetailsIfStorePricingDetails(..) isCapOrFloor()2

CompleteSecurityAndModelDependentLegDetailsIfStorePricingDetails()

ModelDependentSecurityDetailsOutput(..)

FillLegDetails(..)

GetFXValue(..)

2

FillLegDetailsIfStorePricingDetails(..)

ModelSpecificLegDetailsOutput(..)

IsForwardCapFloor(..)

2

GetVolatility(..)

GetVolatility(..)

18

GetLMMVolatilityTypes()

18

ReturnVolatility(..)

18

GetObject(..)

36

GetObject(..)

18

Create(..)

36

Accrual(..)

Calculate(..)15

CalcPartialPeriodLength(..)4

IsHistorical(..)

4

GetAdditionalDays(..)

4

AccrualAtSettlement(..) 15

GetVolatility(..) GetBlackVolatilityTypes()10

20

10

10

CreateInstance(..)

GetCcyVolatility(..)

38

GetIdxRefVolatility(..)

38

GetObject(..)

38

38

ForwardRatesWithoutAdjustment(..)

ForwardRate(..)

28

GetCashFlowIndex(..)

14

GetCashFlowIndex2(..)

14

ForwardRates(..)

PrepareForCashflow(..)

14

168

42

42

GetObject(..)

42

84

552

CapletRate(..)

14

FloorletRate(..)14

FixedIndexRates(..)

1

1

CheckAbilityToHandleLeg(..)

CheckAbilityToHandleCashFlow(..) ForwardRate(..)

196

546

PrepareForPricing(..)

Action(..) FindIndex(..)60

GetObservationAndFixingDates(..)60

GetIndexName(..)

60

GetIndex(..)

BuildDateGrids(..)

10

GetFixIntervals()10

80

300

ResetFlow()

ResetFlow()

18

GetHashCode()

292

GetCashFlowIndexes(..)101

ResetCashFlow()

15

ResetLeg()

2

CollectIndexDescriptions(..)

ApplyToAllFlows(..)

1

GenerateCashFlowIndexes(..)

30

SetIndexesOfIndexTremTreeFunctions(..)1

GetIndexDescriptor(..)

30

74

ForEachFormula(..)

30

202

AddObject()

IsNDef(..)

30

Action(..)

15

Action(..)

30

30

AddObject(..)30

30

30

InitializeDelegatesIRSubModelType(..)1

Price(..)

2

2

1

1

2

2

2

1

1

1

1

Price(..)1

15

2

Price(..)2

GetCashFlowIndexNames()

2

2

15Price(..)

15

15

15

15

15

PricingCouponCashflow(..)

15

GetDiscountCurve(..)

15

GetForecastCurves(..)

15

15

GetIndexNames()

15

GetCouponPayType(..)

15RateCalculation(..)15

FlowAndPVLetCalculation(..)

15

15

15

IndexSpreadRateCalculation(..)15

15

15

14

14

14

14

1

59

44

GetIndexVolatility(..)

28

15

15

18

10

28

GetEndDate()

1

Price(..)

1 AddIPricingResults(..)

1

1

1

2

1

1

GetValuationDate()

GetObject(..)

GetDependencies()

ReplaceDependence()Objects(..)

Accept(..)

107

Objects(..)

49

GetObjects(..)

GetObjects(..)

3

848ReplaceDependence(..)

ReplaceDependence(..)

1

GetObject(..)

GetObject(..)

18 18

GetUseUsageTracking(..)

InitializeMarketDataUsageTracking()

9

InitializeObjectTracking(..)9

InitializeUsageTracking()

9

1

9

1

InitializeTemplateObjects()

SetStoreLossDistributions()

InitializePartialJobs(..)

10

Evaluate()1

1

1

1

1

1

BuildNotBuiltDefaultCurves()1

ToString()

1ClearIntermediateObjects()1

MarketDataUsageCheck()

1

1

180

GetInterestCurve(..)

15

150

75

GetIndexDescriptors(..)

30GetForecastCurve(..)

60

60

GetForecastCurve(..)60 GetInterestCurve(..)60 60

504

SetObjectAndCheckImpliedCalibration(..)70

70

GetObject(..)

42

42

120

2

18

10

9

FindCollections(..)

SetCollectionObjects(..)

GetObjectSignatures(..)

CheckObjectsAreUnique(..)

InitializeObjects()

CopyOrId(..)

ReplaceDependenceByObjectSignature()

1

1

1

1

GetObjects()12

GetDependencyHandle()

1

ReadObjectsTable(..)

ReadObjectsTable(..)1

ReadObjects(..)

1

ProveOfUniqueObjects(..)

1

CheckNumberOfObjects(..)2

ReadScenarioTable(..)

InitMembersWithCorrespondingNullValues()

Initialize(..)

ReadMethodAssetClassSpecification(..)

GetDefaultIRSubModelType(..)

InitializeMethodAssetClassSpecification()

ReadAnalyticMethodsTable(..)

CreateInstance(..)

ReadScriptParametersTable(..)

1

InitializeScriptText(..)

1

InitializeScriptReferenceObjects(..)

1

ReadScriptVariablesTable(..)

1

ReadScriptIndexDescriptors(..)

1

InitializeRangeAccrual(..)

1

InitializeLegs(..)

1

InitializeMiscellaneousPayments(..)

1

SetScriptsToCashFlows(..)

1

CheckAbilityToBeHandled()

1

CheckConsistency()

1

PostPreparation()

1

GetCreditBasketNamesTable(..)

1

ReadBasketsWithNotional(..)

1

ReadCurrencyProperty(..)

1

Action(..)

30

FillOptionsList()

15

BuildRateFormula()

15

BuildNotionalFormula()

15

GetFormula(..)

15

15

GetCashFlowName(..)

15

390

195

Action(..)195

GenerateRateFormula(..)

15

AddFormula(..)15

15

GenerateCollaredFloaterFormula(..)15 GenerateCollaredFloaterStandardFormula(..)15 GetIndexSpreadIndexExpression(..)15

Function(..)35 Plus(..)

15

Multiply(..)

30

Function(..)

15

15

Multiply(..)30

20

ToNumberFormatedString(..)35

5

SetIndexNames(..)

PostProcessing(..)

CalcDayCountFraction(..)

15


SetDefaultValues()

SetDefaultValue(..)60

CheckConsistency()

CheckNotional()

15

CheckMembersInitialization()

15

CheckStartAndEndDate()

15

CheckFixingAndPaymentDate()

15

CheckDefaultPayType()

15

CheckRangeAccrual()

15

CheckSecondIndex()

15CheckMultiplierIfIndexSpread()

15CheckPayoffPart(..)

15CheckScript()15

CheckCapFloor()

15

CheckConsistency(..)

15

Build()

BuildNothing(..)

8

BuildAccrualStartDate(..)

2

BuildAccrualEndDate(..)

2

BuildPaymentDate(..)

2

BuildFixingDate(..)

2

BuildPerformanceAnchorDate(..)

2

BuildPerformanceResetRequired(..)

2

BuildAveragingStartDate(..)

2

BuildAveragingEndDate(..)

2

BuildNotionalInput(..)

2

BuildNotionalChangeInput(..)

2

BuildCurrency(..)

2

BuildQuantity(..)

2

BuildUnit(..)

2

BuildPayReceive(..)

2

BuildDayCountConvention(..)

2

BuildDiscountReference(..)

2

BuildIndexName(..)

2

BuildIndex2Name(..)

2

BuildIndexNatural(..)

2

BuildPerformanceCoupon(..)

2

BuildScriptName(..)

2

BuildSpread(..)

2

BuildMultiplier(..)

2

BuildMultiplier2(..)

2

BuildConstantRate(..)

2 BuildCouponFloor(..)

2 BuildCouponCap(..)

2 BuildStrikeRate(..)

2 BuildPayoffOption(..)

2BuildPayoffOptionType(..)2

BuildWidth(..)

2

BuildAveragingType(..)

2

BuildSpreadMethod(..)

2

BuildPayoffRate(..)

2

BuildATMPayoff(..)

2

BuildCouponInput(..)

2

BuildPayCoupon(..)

2

BuildAnnuityInput(..)

2

BuildPayNotionalChange(..)

2

BuildNotionalDiscountReference(..)

2

BuildRedeemNotional(..)

2

BuildDefaultPayType(..)

2

BuildNthCreditBasketEvent(..)

2

BuildPaymentDelayInDefault(..)

2

BuildPayAccrualInDefault(..)

2

BuildPayRecoveryInDefault(..)

2

BuildFixedRecoveryRate(..)

2

BuildLossAttachment(..)

2

BuildLossDetachment(..)

2

BuildAccrualConvention(..)

2

BuildAveragingFixingFrequency(..)

2

BuildCreditName(..)

2

ReadNotionalsFromCreditBaskets(..)

2

BuildRangeAccrual(..)

2

BuildDayCountFraction()

2

CreateInstance(..)

15

GetColumn(..)

2

SetCreditNameAndCreditBasketNames(..)

15

GetNotional(..)

15

2

CalculateDayCountFraction(..)

15

15

BuildAveragingDescriptions(..)

GenerateCashFlowDescriptionTable(..) GetCashFlowDescriptionColumn(..)16

GetCashFlowDescriptionColumn(..)92

GetCashFlowDescriptionColumn(..)

4

PayNotional(..)

4

4

SetCashFlowDescriptors(..)

2

2

InitMembers(..)

15


15

CheckConsistencyAndSetDefaultValues()

15

15

ApplyToAllCashFlows(..)

15

15

15

GetCreditBasketNames(..)

GetNthCreditBasketEvent(..) GetDefaultNthCreditBasketEvent(..)2

RiskyFloatLeg(..)

2

2

15

GetBasketWithNotional(..)

15

CheckScript()

15

CheckNthCreditBasketEvent()

15CheckOption()

15

CheckOptionType()15

CheckDoubleComponents()

15

InitMembersWithNullValues()

Initialize(..)

2

2

GetLegType(..)2

RiskyFloatLeg(..)2

GetStartDate(..)

2

GetDefRollStart(..)2

GetEndDate(..)2

GetStartDate(..)2

2

GetLegsFromLegsTable(..)

1

GetLegsFromCashflowDescriptionTables(..)1

2

2

2

2

GetLegSpecifyingTables(..)2

2

GetScriptCashFlowRelation(..)1

2

2

1

4

GetCreditNames()

PostProcessing(..)

Insert(..) OnInsertObject(..)15

OnClearPool()

GetVersionNumber()

GetCompilationDate()

SetContactMessage()

ReadObjectsFromFile(..) CreateObject(..)14 CreateObject(..)14 CreateObjectPreProcessing(..)14

CreateObject(..)

14

1

1

1

1

1

1

1

1

1

1352

5

CreateObjectPostProcessing(..)

14

1

1

14

EvaluateJob(..)

1

1

1

1

1

1

1

1

1

1

1

1

11

1

1

WriteLogInfo(..)

1

WriteLogInfo(..)1

WriteObjectsToFile(..)

GetOutConverter(..)

1

ClearPools()

15

$

1

1

1

1

1

1

1

1

1

Figure 7.7.: Assembly operation dependency graph of a monitored execution of NordicAnalytics evaluating another complex CMS, again with a static replicationmodel by Hagan (Job 5).

80


$<

<as

sem

bly

com

pone

nt>

>@

1:..c

Ana

lytic

s11

9

<<

asse

mbl

y co

mpo

nent

>>

@6:

..cS

wap

24

<<

asse

mbl

y co

mpo

nent

>>

@32

:..cJ

obO

bjec

t

29

<<

asse

mbl

y co

mpo

nent

>>

@92

:..cS

ingl

eOpt

ionS

ecur

ity

12

<<

asse

mbl

y co

mpo

nent

>>

@16

6:..c

Inde

xOpt

ion

3

<<

asse

mbl

y co

mpo

nent

>>

@2:

..cO

bjec

tPoo

l

762

<<

asse

mbl

y co

mpo

nent

>>

@3:

..cV

aRM

etho

dFac

tory

109

<<

asse

mbl

y co

mpo

nent

>>

@5:

..cC

redi

tBas

kets

24

<<

asse

mbl

y co

mpo

nent

>>

@12

:..cA

ccru

alC

onve

ntio

n

2709

7

<<

asse

mbl

y co

mpo

nent

>>

@14

:..cS

crip

tTab

les

24

<<

asse

mbl

y co

mpo

nent

>>

@23

:..cS

ecur

ityF

acto

ry

38

<<

asse

mbl

y co

mpo

nent

>>

@24

:..cM

odel

Typ

e

159

<<

asse

mbl

y co

mpo

nent

>>

@25

:..cM

odel

Par

amet

ers

64

<<

asse

mbl

y co

mpo

nent

>>

@26

:..cM

odel

Des

crip

tion

32

<<

asse

mbl

y co

mpo

nent

>>

@27

:..cJ

obD

escr

ipto

r

33

<<

asse

mbl

y co

mpo

nent

>>

@28

:..cE

valu

atio

nObj

ects

365

<<

asse

mbl

y co

mpo

nent

>>

@30

:..cJ

ob

203

<<

asse

mbl

y co

mpo

nent

>>

@95

:..cP

lain

Sw

apD

ateG

rid

4874

<<

asse

mbl

y co

mpo

nent

>>

@96

:..cP

lain

Sw

apP

ricin

g

3526

<<

asse

mbl

y co

mpo

nent

>>

@11

1:..c

Pla

inF

ixL

egD

ateG

ridD

escr

ipto

r

337

<<

asse

mbl

y co

mpo

nent

>>

@11

2:..c

Pla

inF

loat

Leg

Dat

eGrid

Des

crip

tor

337

<<

asse

mbl

y co

mpo

nent

>>

@14

9:..c

Ris

k

3

<<

asse

mbl

y co

mpo

nent

>>

@4:

..cS

ecur

ity

10

<<

asse

mbl

y co

mpo

nent

>>

@7:

..cL

egD

escr

ipto

r

82

<<

asse

mbl

y co

mpo

nent

>>

@10

:..cL

eg

365

10

<<

asse

mbl

y co

mpo

nent

>>

@15

:..cS

crip

tPar

amet

ers

88

<<

asse

mbl

y co

mpo

nent

>>

@16

:..cS

crip

tCas

hFlo

wH

andl

er

357

<<

asse

mbl

y co

mpo

nent

>>

@21

:..cS

crip

t

526

<<

asse

mbl

y co

mpo

nent

>>

@39

:..cC

olle

ctor

9

<<

asse

mbl

y co

mpo

nent

>>

@11

3:..c

Pay

offS

crip

t

60

<<

asse

mbl

y co

mpo

nent

>>

@8:

..cP

ayof

fDes

crip

tor

80

504

<<

asse

mbl

y co

mpo

nent

>>

@9:

..cC

redi

tDes

crip

tor

582

69

650

<<

asse

mbl

y co

mpo

nent

>>

@11

:..cC

ashF

low

Bui

lder

90

<<

asse

mbl

y co

mpo

nent

>>

@13

:..cC

ashF

low

2489

<<

asse

mbl

y co

mpo

nent

>>

@22

:..cC

ashF

low

Scr

iptG

ener

ator

568

<<

asse

mbl

y co

mpo

nent

>>

@37

:..cI

ndex

Fix

ingD

escr

iptio

nCol

lect

or

906

<<

asse

mbl

y co

mpo

nent

>>

@60

:..cC

heck

Cur

renc

y

214

<<

asse

mbl

y co

mpo

nent

>>

@61

:..cC

heck

Inde

x

142

<<

asse

mbl

y co

mpo

nent

>>

@65

:..cL

MM

Pric

ing+

cDat

esC

olle

ctor

68

<<

asse

mbl

y co

mpo

nent

>>

@66

:..cI

ndex

Nam

eCol

lect

or

176

<<

asse

mbl

y co

mpo

nent

>>

@73

:..cC

heck

Scr

iptF

unct

ionA

rgum

ents

106

<<

asse

mbl

y co

mpo

nent

>>

@84

:..cC

urre

ncyC

olle

ctor

310

<<

asse

mbl

y co

mpo

nent

>>

@15

4:..c

Set

Infla

tionQ

uote

s32

<<

asse

mbl

y co

mpo

nent

>>

@20

0:..c

Leg

Typ

eChe

ck

25

568

504

568

572

568

566

156

156

<<

asse

mbl

y co

mpo

nent

>>

@17

:..cF

orm

ulaB

uild

er49

0

<<

asse

mbl

y co

mpo

nent

>>

@18

:..cS

tand

ardF

orm

ulaB

uild

er

61

490

1602

<<

asse

mbl

y co

mpo

nent

>>

@19

:..cS

crip

tOpt

ions

<<

asse

mbl

y co

mpo

nent

>>

@20

:..cR

epla

ceIn

dexN

ameB

yFun

ctio

n

10 2766

2776

1

<<

asse

mbl

y co

mpo

nent

>>

@44

:..cS

etIn

dex

3270

2

<<

asse

mbl

y co

mpo

nent

>>

@79

:..cS

etIn

dexV

alue

s

7911

3

<<

asse

mbl

y co

mpo

nent

>>

@11

4:..c

Inde

xNam

eCol

lect

or37

4

<<

asse

mbl

y co

mpo

nent

>>

@11

5:..c

Scr

iptC

ashF

low

Han

dler

+cR

epla

ceIn

dexN

ameB

yFun

ctio

n84

97

<<

asse

mbl

y co

mpo

nent

>>

@11

6:..c

Par

amet

erS

ette

r

8497

<<

asse

mbl

y co

mpo

nent

>>

@18

1:..c

Ter

mT

reeF

unct

ionA

vg

6

980

490

980

490

980

35

48

168

9626

<<

asse

mbl

y co

mpo

nent

>>

@59

:..cO

ptio

nSw

ap

35

<<

asse

mbl

y co

mpo

nent

>>

@93

:..cS

wap

tion

11

<<

asse

mbl

y co

mpo

nent

>>

@16

5:..c

FX

Opt

ion

6

15

51

<<

asse

mbl

y co

mpo

nent

>>

@29

:..cR

elat

iveH

isto

rical

VaR

Met

hod

27

<<

asse

mbl

y co

mpo

nent

>>

@33

:..cS

ecur

ityD

epen

denc

y15

3

2

1669

3341

1298

9

<<

asse

mbl

y co

mpo

nent

>>

@34

:..cV

alua

tionD

ateF

inde

r

32

<<

asse

mbl

y co

mpo

nent

>>

@55

:..cV

alua

tionC

ontr

ol

33

<<

asse

mbl

y co

mpo

nent

>>

@56

:..cI

mpl

icitC

alib

ratio

n

227

1

<<

asse

mbl

y co

mpo

nent

>>

@12

4:..c

SA

BR

Cal

ibra

tionF

acto

ry+

cIsC

ube

1

<<

asse

mbl

y co

mpo

nent

>>

@13

1:..c

For

war

dRat

eCur

ves+

cIsF

orw

ardC

urve

1

<<

asse

mbl

y co

mpo

nent

>>

@31

:..cT

ypeF

ilter

2

1346

3

2481

<<

asse

mbl

y co

mpo

nent

>>

@35

:..cP

ricin

g

90

20

27

27

<<

asse

mbl

y co

mpo

nent

>>

@36

:..cC

ashF

low

Pric

ingM

odel

21

<<

asse

mbl

y co

mpo

nent

>>

@63

:..cP

ortf

olio

3

<<

asse

mbl

y co

mpo

nent

>>

@64

:..cL

MM

Pric

ing

8

<<

asse

mbl

y co

mpo

nent

>>

@74

:..cM

onte

Car

loP

ricin

g

7

4

<<

asse

mbl

y co

mpo

nent

>>

@98

:..cS

wap

tionP

ricin

gMod

el

8

<<

asse

mbl

y co

mpo

nent

>>

@10

2:..c

Ber

mud

anS

tyle

Opt

ionP

ricin

gMod

el

2

2

<<

asse

mbl

y co

mpo

nent

>>

@17

0:..c

Inde

xOpt

ionM

odel

2

<<

asse

mbl

y co

mpo

nent

>>

@17

2:..c

Infla

tionP

ricin

gMod

el

1

<<

asse

mbl

y co

mpo

nent

>>

@18

5:..c

Mul

tiFac

torM

CF

acto

ry

1

45

443

2811

1668

<<

asse

mbl

y co

mpo

nent

>>

@40

:..cP

ricin

gPar

ams

44

<<

asse

mbl

y co

mpo

nent

>>

@41

:..cP

ricin

gPar

amsC

redi

tLin

ked

488

<<

asse

mbl

y co

mpo

nent

>>

@42

:..cP

ricin

gPar

amsC

FP

1888

<<

asse

mbl

y co

mpo

nent

>>

@45

:..cD

efau

ltFun

ctio

ns

1987

<<

asse

mbl

y co

mpo

nent

>>

@46

:..cM

arke

tAna

lytic

Mod

el

1593

<<

asse

mbl

y co

mpo

nent

>>

@47

:..cA

ccru

edIn

tere

stC

alcu

lato

r

884

<<

asse

mbl

y co

mpo

nent

>>

@48

:..cV

olat

ility

Fin

der

375

<<

asse

mbl

y co

mpo

nent

>>

@49

:..cC

ashR

ateV

olat

ility

Fin

der

267

<<

asse

mbl

y co

mpo

nent

>>

@50

:..cC

onve

xity

Adj

ustm

entM

odel

666

<<

asse

mbl

y co

mpo

nent

>>

@52

:..cC

redi

tMon

teC

arlo

Mod

el

21

<<

asse

mbl

y co

mpo

nent

>>

@53

:..cL

egD

etai

lsC

FP

106

<<

asse

mbl

y co

mpo

nent

>>

@54

:..cS

ecur

ityD

etai

lsC

FP

106

<<

asse

mbl

y co

mpo

nent

>>

@57

:..cL

inea

rRat

eMod

elB

lack

86

<<

asse

mbl

y co

mpo

nent

>>

@99

:..cR

eplic

atio

nMod

elL

RM

193

<<

asse

mbl

y co

mpo

nent

>>

@10

0:..c

Inde

xSpr

eadM

odel

126

<<

asse

mbl

y co

mpo

nent

>>

@10

1:..c

Sw

apR

ateV

olat

ility

Fin

der

108

<<

asse

mbl

y co

mpo

nent

>>

@16

2:..c

Rep

licat

ionM

odel

22

4

906

<<

asse

mbl

y co

mpo

nent

>>

@38

:..cS

crip

tInd

exD

escr

ipto

rFun

ctio

n

2118

1539 36

<<

asse

mbl

y co

mpo

nent

>>

@43

:..cT

erm

Tre

eFun

ctio

nInd

ex

7623

1539

182

319

31

3464

847

953

953

488

1084

76

259

512

1304

218

2570

392

10

2

109

2371

282

130

3460

9

<<

asse

mbl

y co

mpo

nent

>>

@51

:..cJ

obD

ataS

tore

42

71

36

966

534

801

801

84

320

346

84

13

2

1

6

1

10

1

21

34

44

34

28

3

37

51

175

45

8

<<

asse

mbl

y co

mpo

nent

>>

@10

3:..c

Dea

lDat

es

2

<<

asse

mbl

y co

mpo

nent

>>

@12

1:..c

Cal

ibra

tion

16

<<

asse

mbl

y co

mpo

nent

>>

@15

0:..c

Jarr

owY

ildiri

mM

odel

1

<<

asse

mbl

y co

mpo

nent

>>

@15

2:..c

Jarr

owY

ildiri

mM

CM

odel

1

<<

asse

mbl

y co

mpo

nent

>>

@15

3:..c

Infla

tionJ

arro

wY

ildiri

mM

CP

ricin

g

1

<<

asse

mbl

y co

mpo

nent

>>

@15

9:..c

His

toric

alV

alue

AtR

isk

4

<<

asse

mbl

y co

mpo

nent

>>

@16

1:..c

Tim

eCon

sum

ingC

alcu

latio

n

2

<<

asse

mbl

y co

mpo

nent

>>

@16

4:..c

Tim

eCon

sum

ingC

alcu

latio

nWith

outF

orm

1

<<

asse

mbl

y co

mpo

nent

>>

@19

0:..c

Cou

nter

Par

tyR

iskF

acto

ry2

<<

asse

mbl

y co

mpo

nent

>>

@19

1:..c

Cou

nter

Par

tyR

isk

2

28

4

6

43

86

46

<<

asse

mbl

y co

mpo

nent

>>

@58

:..cO

ptio

nDes

crip

tor

7

15

142

74

<<

asse

mbl

y co

mpo

nent

>>

@62

:..cL

MM

Pric

ing+

cSec

urity

Che

ckF

orL

MM

8

6

2

2

42

34

6

2

10

<<

asse

mbl

y co

mpo

nent

>>

@67

:..cL

ibor

Dat

eGrid

12

<<

asse

mbl

y co

mpo

nent

>>

@72

:..cL

ibor

Sam

ples

Fac

tory

2

2

176

176

<<

asse

mbl

y co

mpo

nent

>>

@68

:..cL

ibor

Sam

ples

9917

<<

asse

mbl

y co

mpo

nent

>>

@70

:..cS

imul

atio

nPar

amsL

SF

acto

ry

2

<<

asse

mbl

y co

mpo

nent

>>

@85

:..cL

ibor

Mar

ketM

odel

10

<<

asse

mbl

y co

mpo

nent

>>

@69

:..cS

imul

atio

nPar

amsL

SL

NF

acto

ry4

<<

asse

mbl

y co

mpo

nent

>>

@71

:..cL

ibor

Sam

ples

LN

1439

1

13

3

<<

asse

mbl

y co

mpo

nent

>>

@11

7:..c

Lib

orS

ampl

esR

SL

N2

156

<<

asse

mbl

y co

mpo

nent

>>

@11

8:..c

Scr

iptK

eyF

unct

ion

250

6

<<

asse

mbl

y co

mpo

nent

>>

@18

7:..c

Ter

mT

reeF

unct

ionN

ameO

nly

6

4

12

2122

38

638

16

120

139

18

8

59

<<

asse

mbl

y co

mpo

nent

>>

@75

:..cP

ricin

gPar

amsS

crip

t

14

<<

asse

mbl

y co

mpo

nent

>>

@76

:..cS

crip

tPric

ingP

aram

sMC

19

<<

asse

mbl

y co

mpo

nent

>>

@77

:..cL

ibor

Sam

ples

Num

erai

re

95

<<

asse

mbl

y co

mpo

nent

>>

@78

:..cC

ashF

low

Tot

alN

ameC

ompa

rer

1162

5

<<

asse

mbl

y co

mpo

nent

>>

@80

:..cS

crip

tEva

luat

ion

2841

<<

asse

mbl

y co

mpo

nent

>>

@81

:..cS

crip

tCF

Det

ails

968

<<

asse

mbl

y co

mpo

nent

>>

@82

:..cM

onte

Car

loP

ricin

g+C

onst

antO

ne

960

<<

asse

mbl

y co

mpo

nent

>>

@83

:..cF

low

Mat

rix

1910

<<

asse

mbl

y co

mpo

nent

>>

@87

:..cF

low

Det

ails

264

<<

asse

mbl

y co

mpo

nent

>>

@88

:..cO

ccur

ence

2

<<

asse

mbl

y co

mpo

nent

>>

@89

:..cS

crip

tRes

ultG

ener

ator

Par

ams

966

<<

asse

mbl

y co

mpo

nent

>>

@90

:..cS

crip

tRes

ults

Gen

erat

or

29

<<

asse

mbl

y co

mpo

nent

>>

@91

:..cP

athW

iseR

esul

t

4

3

<<

asse

mbl

y co

mpo

nent

>>

@15

7:..c

Jarr

owY

ildiri

mM

CM

odel

+cJ

arro

wY

ildiri

mIR

MC

120

<<

asse

mbl

y co

mpo

nent

>>

@15

8:..c

Jarr

owY

ildiri

mN

umer

aire

33

<<

asse

mbl

y co

mpo

nent

>>

@18

6:..c

Com

mod

ityM

CP

ricin

g

4

<<

asse

mbl

y co

mpo

nent

>>

@18

8:..c

Gab

illon

Sam

ples

109

<<

asse

mbl

y co

mpo

nent

>>

@18

9:..c

Inte

rest

Cur

veN

umer

aire

5

9

152

6

6

6

295

455942

4327

<<

asse

mbl

y co

mpo

nent

>>

@11

9:..c

Scr

iptK

eyF

unct

ionN

otio

nal

428

<<

asse

mbl

y co

mpo

nent

>>

@12

0:..c

Scr

iptK

eyF

unct

ionR

ate

106

42

310

1

3

4

5

<<

asse

mbl

y co

mpo

nent

>>

@86

:..cF

low

Det

ails

Row

200

2927 648

2

1040

103

12

1062

6

2256

103

98

106

2

3

1 12

1

<<

asse

mbl

y co

mpo

nent

>>

@12

2:..c

Cal

ibra

tionI

mpl

emen

tatio

n

2

<<

asse

mbl

y co

mpo

nent

>>

@19

8:..c

Sw

aptio

nCol

lect

ionC

alib

ratio

n

3

<<

asse

mbl

y co

mpo

nent

>>

@19

9:..c

Cal

ibra

tionP

aram

s

3

<<

asse

mbl

y co

mpo

nent

>>

@20

1:..c

Cal

ibra

tionP

aram

sAT

MS

trik

es

3

<<

asse

mbl

y co

mpo

nent

>>

@20

4:..c

Am

ortiz

erC

alib

ratio

nStr

ikes

1

<<

asse

mbl

y co

mpo

nent

>>

@94

:..cS

wap

tionP

ricin

gAna

lytic

5

16

4

8

4

8

6018

8

<<

asse

mbl

y co

mpo

nent

>>

@97

:..cS

wap

tionP

ricin

gRes

ult

84

622

271

1661

8

<<

asse

mbl

y co

mpo

nent

>>

@20

5:..c

Rep

licat

ionM

odel

PV

01

85

918

243

252

350

96

432

2

4

4

3

379

167

4944 2

4

4

8

42

2

36

120

4944

4944

<<

asse

mbl

y co

mpo

nent

>>

@10

4:..c

Sec

urity

Pric

ingP

aram

sBS

OP

2

<<

asse

mbl

y co

mpo

nent

>>

@10

5:..c

Pric

ingP

aram

sBS

OP

9

<<

asse

mbl

y co

mpo

nent

>>

@10

6:..c

Flo

wC

ontr

ol

79

<<

asse

mbl

y co

mpo

nent

>>

@10

7:..c

Flo

wC

ontr

olL

ist

7

<<

asse

mbl

y co

mpo

nent

>>

@10

8:..c

Cas

hFlo

wD

etai

lsB

SO

P

30

<<

asse

mbl

y co

mpo

nent

>>

@10

9:..c

Leg

Det

ails

BS

OP

9

<<

asse

mbl

y co

mpo

nent

>>

@11

0:..c

Sec

urity

Det

ails

BS

OP

11

3

1

56

47

18

20

23

14

2

42

73

18

29

9

9

18

56

4

47

3 302

10

6

83

428

106

1

6

19

2

24

<<

asse

mbl

y co

mpo

nent

>>

@12

3:..c

Cap

letC

alib

ratio

n

5

<<

asse

mbl

y co

mpo

nent

>>

@12

7:..c

SA

BR

Cal

ibra

tionF

acto

ry1

<<

asse

mbl

y co

mpo

nent

>>

@13

9:..c

Sho

rtR

ateV

olC

alib

ratio

n

2 1

13

1

1

<<

asse

mbl

y co

mpo

nent

>>

@13

8:..c

SA

BR

Fix

Bet

aFro

mC

ubeC

alib

ratio

n

1

2

689

10

8 20

<<

asse

mbl

y co

mpo

nent

>>

@12

5:..c

Vol

atili

tyC

ubeC

hang

eQuo

teT

ypeC

alib

ratio

n

<<

asse

mbl

y co

mpo

nent

>>

@12

6:..c

Vol

atili

tyC

ubeC

hang

eQuo

teT

ypeC

alib

ratio

n+cV

olC

ubeT

abD

escr

iptio

n

2

2

1

1011

<<

asse

mbl

y co

mpo

nent

>>

@12

9:..c

Vol

atili

tyC

ubeS

etA

TM

Vol

Cal

ibra

tion

1

<<

asse

mbl

y co

mpo

nent

>>

@13

0:..c

SA

BR

Vol

Cal

ibra

tionU

tility

2

<<

asse

mbl

y co

mpo

nent

>>

@13

5:..c

SA

BR

Fix

Bet

aCal

ibra

tionR

esul

t

1

<<

asse

mbl

y co

mpo

nent

>>

@13

7:..c

SA

BR

Fix

Bet

aFro

mC

ubeC

alib

ratio

nVol

atili

ty

1

<<

asse

mbl

y co

mpo

nent

>>

@12

8:..c

AT

MC

ubeV

olat

ility

Sur

face

25

2

<<

asse

mbl

y co

mpo

nent

>>

@13

2:..c

For

war

dRat

eCur

ves

1

<<

asse

mbl

y co

mpo

nent

>>

@13

3:..c

SA

BR

Fix

Bet

aCal

ibra

tor

<<

asse

mbl

y co

mpo

nent

>>

@13

4:..c

SA

BR

Vol

Tem

plat

e<

<as

sem

bly

com

pone

nt>

>@

136:

..cS

AB

RF

ixB

etaC

alib

ratio

n257525

335

1

1

1

4

1

1

2

2

4

<<

asse

mbl

y co

mpo

nent

>>

@14

0:..c

Sw

aptio

nExp

iryC

ompa

rer

22

<<

asse

mbl

y co

mpo

nent

>>

@14

1:..c

Sho

rtR

ateV

olC

alib

ratio

nPar

ams

1

<<

asse

mbl

y co

mpo

nent

>>

@14

6:..c

Cap

letC

alib

ratio

nCon

trol

10

<<

asse

mbl

y co

mpo

nent

>>

@14

7:..c

Sw

aptio

nCal

ibra

tionC

ontr

ol

25

<<

asse

mbl

y co

mpo

nent

>>

@14

8:..c

Con

erD

ateC

alib

ratio

nCon

trol

Exp

iryC

ompa

rer

25

6

6

6

6

6 25

<<

asse

mbl

y co

mpo

nent

>>

@14

2:..c

Sw

apD

escr

ipto

rCon

tain

er

6

<<

asse

mbl

y co

mpo

nent

>>

@14

3:..c

Sw

apD

escr

ipto

r

6

<<

asse

mbl

y co

mpo

nent

>>

@14

5:..c

Sw

aptio

nDes

crip

tor

6

145

338

<<

asse

mbl

y co

mpo

nent

>>

@14

4:..c

Sw

aptio

nSho

rtR

ateD

escr

ipto

r6

3

2

2

5

<<

asse

mbl

y co

mpo

nent

>>

@15

1:..c

Jarr

owY

ildiri

mM

odel

Par

amet

ers

2

2

8

7

3

<<

asse

mbl

y co

mpo

nent

>>

@15

5:..c

Jarr

owY

ildiri

mG

ener

icN

umer

aire

2

<<

asse

mbl

y co

mpo

nent

>>

@15

6:..c

Jarr

owY

ildiri

mT

erm

inal

Num

erai

re

1

1

2

2

2

3

32

1

842

1

986

3

419

16

15

1

2

1

<<

asse

mbl

y co

mpo

nent

>>

@16

0:..c

His

toric

alV

alue

AtR

isk+

cSce

norio

Nam

eGen

erat

or2

<<

asse

mbl

y co

mpo

nent

>>

@16

3:..c

His

toric

alV

aRR

esul

t

3

54

36

1824

24

6

4

<<

asse

mbl

y co

mpo

nent

>>

@16

7:..c

Inde

xOpt

ionM

odel

Tre

e

3

8

1

20

<<

asse

mbl

y co

mpo

nent

>>

@16

8:..c

Inde

xOpt

ionM

arke

tDat

aFX

10

<<

asse

mbl

y co

mpo

nent

>>

@16

9:..I

Inde

xOpt

ionM

arke

tDat

a

5

5

18 10 5

<<

asse

mbl

y co

mpo

nent

>>

@17

1:..c

Inde

xOpt

ionM

odel

Ana

lytic

9

1

1

2

1

<<

asse

mbl

y co

mpo

nent

>>

@17

9:..c

Jarr

owY

ildiri

mA

naly

ticP

ricin

gMod

el1

<<

asse

mbl

y co

mpo

nent

>>

@17

3:..c

Ana

lytic

Col

lare

dFlo

atin

gRat

eCal

cula

tion

<<

asse

mbl

y co

mpo

nent

>>

@17

4:..c

Ana

lytic

Sim

pleP

lain

Van

illaC

oupo

nFac

tory

61

<<

asse

mbl

y co

mpo

nent

>>

@17

5:..c

Jarr

owY

ildiri

mA

naly

ticP

ricin

gPar

ams

976

366

122

<<

asse

mbl

y co

mpo

nent

>>

@17

7:..c

Jarr

owY

ildiri

mC

aple

tFlo

orle

t

244

<<

asse

mbl

y co

mpo

nent

>>

@17

6:..c

Ana

lytic

Per

form

ance

Cal

cula

tion

1261

61

<<

asse

mbl

y co

mpo

nent

>>

@17

8:..c

Ana

lytic

Col

lare

dFlo

atin

gRat

eCal

cula

tion+

cInf

latio

nLin

kedR

ate

122

61

1

2

67

134

265

67

1

68134 6

6

6767 61

<<

asse

mbl

y co

mpo

nent

>>

@18

0:..c

Ana

lytic

Fix

edR

ateC

alcu

latio

n

6

2153

6

<<

asse

mbl

y co

mpo

nent

>>

@18

2:..c

IsIn

dexM

CP

ricea

ble

2

<<

asse

mbl

y co

mpo

nent

>>

@18

3:..c

Mul

tiFac

torM

CP

ricin

g

1

3

1

1

<<

asse

mbl

y co

mpo

nent

>>

@18

4:..c

Sam

pleD

ates

Bui

lder

3

3

1

1

2

1

1

3

3

1

99

1

3

12

2

4

1

4

<<

asse

mbl

y co

mpo

nent

>>

@19

2:..c

Sec

urity

Che

ckM

etho

ds

1

<<

asse

mbl

y co

mpo

nent

>>

@19

3:..c

CP

RS

peci

alM

odel

Fac

tory

1

1

<<

asse

mbl

y co

mpo

nent

>>

@19

5:..c

Cou

nter

Par

tyR

iskS

peci

alM

odel

s

2

<<

asse

mbl

y co

mpo

nent

>>

@19

7:..c

Cou

nter

Par

tyR

iskA

naly

tic

1

1

2

1

3

2

11

5

2

1

<<

asse

mbl

y co

mpo

nent

>>

@19

4:..c

CP

RF

XT

ree

4

1

2

1

2

<<

asse

mbl

y co

mpo

nent

>>

@19

6:..c

CP

RA

naly

ticP

FE

Cas

hflo

w

25

2952

630

50

630

630

1

2

11

1

1

4

2 112

3

<<

asse

mbl

y co

mpo

nent

>>

@20

2:..c

Am

ortiz

erC

aliA

TM

Str

ikes

1

<<

asse

mbl

y co

mpo

nent

>>

@20

3:..c

Cal

ibra

tedS

wap

tionD

ata

1

11

2104

1715

3

1708

5

Figure 7.8.: Assembly component dependency graph of the monitored execution ofNordic Analytics evaluating the complete benchmark (Jobs 1 to 29).

81

7. Case Study

7.5. Overhead Analysis

Aside from testing the model extraction capabilities of Kieker.NET, we also seized theopportunity to conduct a comprehensive macro-benchmark using the Nordic Analyticsbenchmark introduced in the previous sections. For that, we applied the same exper-iment design we used for the micro-benchmark to our overhead analysis with NordicAnalytics.

7.5.1. Experimental Setting

The test system was a Lenovo Thinkpad T61 with an Intel Core 2 Duo T7300 dual coreprocessor with 2.0 GHz, 2 GB memory, and Windows XP Professional SP3 as operatingsystem. The development environment where we could actually edit the source code ofNordic Analytics (which was not really necessary for monitoring with the final versionof Kieker.NET, though) was Visual Studio 2005 with the .NET 2.0 framework. We usedJava version 1.6.0_03-b05 (to host Kieker 1.4-dev-SNAPSHOT), JNBridge version 5.1,and Postsharp 2.1.3.3. The version of the analyzed Nordic Analytics build was 2.0.50.

7.5.2. Results

As in the micro-benchmark, the macro-benchmark consisted of multiple runs, one initial-ization run and five live runs each, of a sequential (batch) execution of the evaluation ofthe 29 jobs introduced above, were each individual execution time as well as the overallexecution times were measured.The chart in Figure 7.9 and Table 6.2 show the combined results of our analysis,

whereas the data contained in Figure 7.10 gives detailed insight into all measured runsin all stages.The benchmark results support our findings of Chapter 6. Postsharp (Stage II) has a

clear (but probably negligible) performance impact, and the two calls through JNBridgemade in Stage III (again, one in OnEntry() and one in OnExit()) take the benchmark’sexecution time to a higher order of magnitude.As soon as the OperationExecutionAspect is fully applied (and Kieker monitoring is

enabled), the performance of the monitored application again suffers almost exponen-tially.

82


11.86

13.39

149.24

353.72

2223.79

2212.92

11.83

13.42

149.41

353.72

2223.56

2209.08

0 500 1000 1500 2000 2500

I

II

III

III*

IV

V

Execution time (μs)

Mean Median

Figure 7.9.: Nordic Analytics macro-benchmark overall performance analysis results (therow marked with (*) is Stage IIITCP).

Stage I II III IIItcp IV VMean 11.86 13.39 149.24 353.72 2,223.79 2,212.92

Median 11.83 13.42 149.41 353.72 2,223.56 2,209.08Std. dev. 0.08 0.06 0.26 1.06 2.94 13.35

Ratio 1.00 1.13 12.58 29.83 187.52 186.60

Table 7.3.: Nordic Analytics macro-benchmark overall performance analysis results. Allvalues in microseconds, ratio values are with respect to Stage I for all Stages.

∆ II III IIItcp IV V ΣMean 1.53 135.85 (340.33) 2,074.55 -10.87 2,201.06

Median 1.59 135.99 (340.30) 2,074.15 14.48 2,226.21

Table 7.4.: Nordic Analytics macro-benchmark overhead results. All values in micro-seconds.

83

7. Case Study

Mac

ro-B

ench

mar

k (N

ord

ic A

nal

ytic

s)

Stag

eR

un

T NA

ΔΣ 1

-29

12

34

56

78

91

01

11

21

31

41

51

61

71

81

92

02

12

22

32

42

52

62

72

82

9

013.25

46.3%

6.13

0.52

0.03

0.30

0.33

0.02

0.03

0.00

0.22

0.25

0.02

0.33

0.39

0.14

0.00

0.14

1.11

0.08

0.16

0.52

0.12

0.03

0.05

0.53

0.27

0.27

0.14

0.00

0.05

0.08

111.83

44.0%

5.21

0.58

0.03

0.30

0.31

0.02

0.03

0.02

0.22

0.25

0.00

0.28

0.38

0.14

0.00

0.14

0.28

0.09

0.14

0.52

0.14

0.03

0.05

0.52

0.25

0.27

0.12

0.00

0.05

0.05

211.83

44.0%

5.21

0.53

0.03

0.30

0.30

0.02

0.03

0.02

0.23

0.27

0.02

0.28

0.38

0.14

0.02

0.14

0.30

0.08

0.16

0.52

0.12

0.03

0.05

0.50

0.25

0.27

0.14

0.00

0.05

0.03

311.75

44.9%

5.28

0.55

0.02

0.31

0.31

0.02

0.03

0.02

0.22

0.27

0.02

0.28

0.38

0.14

0.02

0.16

0.27

0.09

0.16

0.52

0.12

0.03

0.05

0.53

0.25

0.27

0.14

0.02

0.03

0.05

411.95

43.4%

5.19

0.55

0.03

0.31

0.30

0.00

0.03

0.00

0.22

0.27

0.00

0.30

0.36

0.14

0.02

0.14

0.30

0.08

0.16

0.53

0.12

0.02

0.05

0.52

0.27

0.27

0.14

0.00

0.03

0.03

511.94

43.2%

5.16

0.53

0.03

0.30

0.30

0.02

0.03

0.00

0.22

0.27

0.00

0.28

0.36

0.14

0.00

0.14

0.33

0.08

0.16

0.52

0.12

0.02

0.05

0.52

0.27

0.27

0.12

0.00

0.03

0.05

Me

an11.86

43.9%

5.21

0.55

0.03

0.30

0.30

0.02

0.03

0.01

0.22

0.27

0.01

0.28

0.37

0.14

0.01

0.14

0.30

0.08

0.16

0.52

0.12

0.03

0.05

0.52

0.26

0.27

0.13

0.00

0.04

0.04

Q.5

11.83

44.0%

5.21

0.55

0.03

0.30

0.30

0.02

0.03

0.02

0.22

0.27

0.00

0.28

0.38

0.14

0.02

0.14

0.30

0.08

0.16

0.52

0.12

0.03

0.05

0.52

0.25

0.27

0.14

0.00

0.03

0.05

SD0.08

0.01

0.04

0.02

0.00

0.00

0.00

0.01

0.00

0.01

0.00

0.01

0.01

0.01

0.01

0.00

0.01

0.01

0.02

0.00

0.01

0.00

0.01

0.00

0.00

0.01

0.01

0.00

0.01

0.01

0.01

0.01

014.39

43.9%

6.32

0.75

0.03

0.38

0.48

0.02

0.05

0.02

0.25

0.27

0.02

0.36

0.38

0.19

0.00

0.17

0.36

0.14

0.23

0.56

0.14

0.03

0.09

0.56

0.25

0.31

0.17

0.00

0.05

0.06

113.42

46.7%

6.27

0.72

0.05

0.39

0.44

0.02

0.05

0.02

0.27

0.28

0.02

0.36

0.39

0.19

0.00

0.17

0.33

0.14

0.23

0.56

0.14

0.05

0.08

0.55

0.23

0.31

0.17

0.00

0.05

0.06

213.38

46.9%

6.27

0.67

0.05

0.38

0.48

0.02

0.05

0.00

0.27

0.30

0.02

0.36

0.39

0.19

0.02

0.17

0.30

0.16

0.23

0.58

0.14

0.03

0.08

0.55

0.25

0.31

0.16

0.00

0.05

0.06

313.45

46.8%

6.29

0.70

0.05

0.38

0.45

0.02

0.06

0.00

0.27

0.27

0.02

0.34

0.39

0.19

0.02

0.17

0.36

0.16

0.22

0.56

0.14

0.03

0.08

0.56

0.25

0.31

0.16

0.00

0.05

0.08

413.44

47.2%

6.34

0.75

0.05

0.38

0.47

0.02

0.05

0.00

0.27

0.27

0.02

0.36

0.39

0.17

0.00

0.17

0.36

0.17

0.23

0.56

0.14

0.03

0.08

0.56

0.25

0.31

0.17

0.00

0.05

0.06

513.28

46.8%

6.22

0.69

0.05

0.38

0.45

0.02

0.06

0.00

0.25

0.28

0.00

0.36

0.39

0.17

0.02

0.16

0.34

0.17

0.22

0.56

0.14

0.03

0.09

0.56

0.25

0.31

0.16

0.00

0.05

0.06

Me

an13.39

46.9%

6.28

0.71

0.05

0.38

0.46

0.02

0.05

0.00

0.27

0.28

0.02

0.36

0.39

0.18

0.01

0.17

0.34

0.16

0.23

0.56

0.14

0.03

0.08

0.56

0.25

0.31

0.16

0.00

0.05

0.06

Q.5

13.42

46.8%

6.27

0.70

0.05

0.38

0.45

0.02

0.05

0.00

0.27

0.28

0.02

0.36

0.39

0.19

0.02

0.17

0.34

0.16

0.23

0.56

0.14

0.03

0.08

0.56

0.25

0.31

0.16

0.00

0.05

0.06

SD0.06

0.2%

0.04

0.03

0.00

0.00

0.01

0.00

0.00

0.01

0.01

0.01

0.01

0.01

0.00

0.01

0.01

0.00

0.02

0.01

0.00

0.01

0.00

0.01

0.00

0.00

0.01

0.00

0.00

0.00

0.00

0.01

RII

:I1.13

1.067

1.20

1.29

1.79

1.26

1.51

1.25

1.80

0.33

1.20

1.05

2.00

1.25

1.05

1.30

1.00

1.17

1.14

1.90

1.45

1.08

1.13

1.31

1.64

1.07

0.95

1.15

1.24

0.00

1.32

1.52

0146.14

57.7%

84.36

1.14

0.62

26.11

6.77

0.22

0.09

0.05

1.20

0.62

0.23

4.88

3.45

0.39

0.05

0.44

1.61

0.34

21.42

3.38

0.17

0.06

1.17

4.94

0.30

2.92

0.25

0.06

1.31

0.17

1149.50

57.9%

86.50

1.11

0.66

26.48

6.95

0.22

0.09

0.03

1.22

0.66

0.25

5.02

3.56

0.38

0.05

0.44

1.67

0.34

22.17

3.50

0.17

0.08

1.22

5.08

0.30

3.03

0.25

0.06

1.34

0.17

2148.81

58.0%

86.30

1.17

0.66

26.41

6.91

0.22

0.09

0.05

1.20

0.66

0.25

4.95

3.55

0.36

0.06

0.44

1.66

0.36

22.11

3.47

0.19

0.06

1.20

5.08

0.30

3.03

0.23

0.08

1.36

0.19

3149.44

57.9%

86.58

1.12

0.66

26.62

6.91

0.22

0.09

0.05

1.20

0.64

0.23

4.98

3.56

0.41

0.06

0.44

1.64

0.34

22.20

3.48

0.17

0.06

1.23

5.12

0.30

3.03

0.25

0.06

1.34

0.17

4149.41

57.9%

86.58

1.12

0.66

26.58

6.94

0.22

0.09

0.05

1.22

0.66

0.25

5.00

3.55

0.36

0.06

0.44

1.66

0.34

22.14

3.53

0.17

0.06

1.22

5.05

0.30

3.05

0.25

0.08

1.34

0.19

5149.06

57.9%

86.29

1.14

0.66

26.48

6.91

0.22

0.09

0.05

1.22

0.64

0.23

5.00

3.55

0.38

0.05

0.44

1.66

0.34

22.08

3.48

0.17

0.06

1.20

5.08

0.30

3.00

0.25

0.08

1.34

0.19

Me

an149.24

57.9%

86.45

1.13

0.66

26.51

6.92

0.22

0.09

0.05

1.21

0.65

0.24

4.99

3.55

0.38

0.06

0.44

1.66

0.34

22.14

3.49

0.17

0.06

1.21

5.08

0.30

3.03

0.25

0.07

1.34

0.18

Q.5

149.41

57.9%

86.50

1.12

0.66

26.48

6.91

0.22

0.09

0.05

1.22

0.66

0.25

5.00

3.55

0.38

0.06

0.44

1.66

0.34

22.14

3.48

0.17

0.06

1.22

5.08

0.30

3.03

0.25

0.08

1.34

0.19

SD0.26

0.0%

0.13

0.02

0.00

0.08

0.02

0.00

0.00

0.01

0.01

0.01

0.01

0.02

0.00

0.02

0.00

0.00

0.01

0.01

0.04

0.02

0.01

0.01

0.01

0.02

0.00

0.02

0.01

0.01

0.01

0.01

RII

I:I

12.58

1.318

16.59

2.07

23.57

87.22

22.78

13.75

3.00

3.83

5.46

2.45

30.25

17.57

9.55

2.70

4.67

3.06

5.60

4.10

141.92

6.69

1.40

2.46

24.28

9.81

1.16

11.21

1.86

18.00

35.37

4.33

0355.42

58.4%

207.64

1.84

1.58

66.17

16.75

0.52

0.16

0.11

2.64

1.22

0.61

11.86

8.39

0.67

0.12

0.86

3.36

0.64

55.39

7.92

0.23

0.12

2.88

11.92

0.39

7.08

0.36

0.17

3.34

0.34

1354.78

58.5%

207.51

1.67

1.59

66.31

16.75

0.52

0.16

0.11

2.64

1.22

0.59

11.89

8.41

0.64

0.12

0.86

3.38

0.61

55.39

7.88

0.23

0.12

2.88

11.91

0.38

7.09

0.33

0.16

3.33

0.34

2352.66

58.6%

206.53

1.69

1.59

65.78

16.78

0.52

0.16

0.11

2.64

1.22

0.61

11.94

8.42

0.64

0.14

0.86

3.38

0.61

55.03

7.83

0.23

0.12

2.86

11.80

0.38

7.05

0.33

0.16

3.31

0.34

Me

an353.72

58.5%

207.02

1.68

1.59

66.05

16.77

0.52

0.16

0.11

2.64

1.22

0.60

11.92

8.42

0.64

0.13

0.86

3.38

0.61

55.21

7.86

0.23

0.12

2.87

11.86

0.38

7.07

0.33

0.16

3.32

0.34

Q.5

353.72

58.5%

207.02

1.68

1.59

66.05

16.77

0.52

0.16

0.11

2.64

1.22

0.60

11.92

8.42

0.64

0.13

0.86

3.38

0.61

55.21

7.86

0.23

0.12

2.87

11.86

0.38

7.07

0.33

0.16

3.32

0.34

SD1.06

0.0%

0.49

0.01

0.00

0.27

0.02

0.00

0.00

0.00

0.00

0.00

0.01

0.02

0.00

0.00

0.01

0.00

0.00

0.00

0.18

0.02

0.00

0.00

0.01

0.05

0.00

0.02

0.00

0.00

0.01

0.00

RII

Itcp

:I29.83

1.33

39.74

3.07

56.79

217.25

55.15

32.50

5.33

9.17

11.89

4.59

75.00

41.95

22.62

4.57

10.83

5.97

11.42

7.26

353.91

15.05

1.85

4.62

57.40

22.89

1.47

26.19

2.50

40.00

87.37

8.10

02227.36

59.5%

1325.08

7.06

10.06

433.17

107.41

3.22

0.66

0.64

15.50

6.19

3.73

75.55

52.94

3.12

0.80

4.41

21.97

3.17

363.19

47.72

0.69

0.53

18.20

74.75

1.02

43.86

1.22

1.00

21.41

1.89

12225.14

59.6%

1325.13

7.09

10.02

432.73

107.30

3.28

0.64

0.70

15.50

6.25

3.73

75.78

52.95

3.08

0.84

4.36

22.05

3.19

363.23

47.80

0.72

0.61

18.20

74.80

1.08

43.81

1.20

1.03

21.28

1.88

22223.56

59.5%

1323.89

7.12

10.02

432.86

107.06

3.23

0.70

0.67

15.44

6.16

3.70

75.59

52.91

3.12

0.77

4.41

21.97

3.20

363.03

47.72

0.70

0.55

18.23

74.67

1.02

43.64

1.19

1.06

21.31

1.84

32228.31

59.6%

1327.04

7.06

10.09

433.48

107.58

3.20

0.67

0.66

15.53

6.22

3.75

75.72

53.16

3.20

0.77

4.44

22.11

3.20

363.66

47.80

0.73

0.59

18.25

74.84

0.98

43.75

1.20

1.05

21.47

1.88

42222.53

59.6%

1323.62

7.09

10.00

432.94

107.19

3.22

0.67

0.67

15.44

6.25

3.72

75.47

52.97

3.12

0.78

4.41

21.95

3.27

362.45

47.72

0.67

0.52

18.22

74.69

1.09

43.62

1.20

1.02

21.38

1.88

52219.39

59.5%

1320.02

6.94

10.02

432.14

106.91

3.23

0.66

0.61

15.39

6.14

3.72

75.34

52.70

3.11

0.78

4.45

21.91

3.14

361.14

47.59

0.67

0.53

18.27

74.56

1.09

43.64

1.20

1.02

21.23

1.89

Me

an2223.79

59.5%

1323.94

7.06

10.03

432.83

107.21

3.23

0.67

0.66

15.46

6.20

3.72

75.58

52.94

3.13

0.79

4.41

22.00

3.20

362.70

47.73

0.70

0.56

18.23

74.71

1.05

43.69

1.20

1.04

21.33

1.87

Q.5

2223.56

59.6%

1323.89

7.09

10.02

432.86

107.19

3.23

0.67

0.67

15.44

6.22

3.72

75.59

52.95

3.12

0.78

4.41

21.97

3.20

363.03

47.72

0.70

0.55

18.23

74.69

1.08

43.64

1.20

1.03

21.31

1.88

SD2.94

0.0%

2.30

0.06

0.03

0.43

0.23

0.03

0.02

0.03

0.05

0.05

0.02

0.16

0.15

0.04

0.03

0.03

0.07

0.04

0.87

0.08

0.02

0.03

0.02

0.10

0.04

0.07

0.00

0.02

0.08

0.02

RIV

:I187.52

1.355

254.12

12.88

358.21

1423.8

352.66

202.00

22.27

55.17

69.64

23.32

465.50

266.13

142.31

22.33

65.67

30.65

74.32

38.10

2325.0

91.43

5.63

21.54

364.68

144.23

4.08

161.82

9.08

259.00

561.42

44.62

02259.63

59.4%

1342.90

7.20

10.19

439.52

108.80

3.25

0.69

0.69

15.53

6.30

3.81

76.95

53.94

3.25

0.75

4.50

22.41

3.23

367.12

48.11

0.66

0.58

18.34

76.19

0.98

44.36

1.23

1.03

21.41

1.88

12202.47

59.4%

1308.87

7.06

9.94

428.48

105.86

3.20

0.69

0.64

15.20

6.09

3.69

74.30

52.14

2.98

0.81

4.39

21.64

3.11

359.20

47.20

0.69

0.55

17.88

73.41

1.02

43.44

1.22

1.06

21.12

1.86

22226.14

59.6%

1326.05

6.97

10.08

433.77

107.61

3.28

0.70

0.64

15.52

6.22

3.73

75.81

53.06

3.06

0.86

4.38

21.83

3.19

363.12

47.69

0.70

0.55

18.25

74.81

1.08

43.70

1.19

1.09

21.28

1.88

32196.27

59.7%

1310.14

6.86

9.95

426.81

105.98

3.25

0.70

0.62

15.34

6.14

3.66

74.73

52.42

3.02

0.80

4.38

21.48

3.14

361.22

47.22

0.73

0.56

17.95

73.83

1.06

43.16

1.20

1.09

20.98

1.86

42230.66

59.6%

1328.94

6.97

10.02

433.91

107.67

3.30

0.73

0.66

15.48

6.20

3.73

76.00

53.36

3.14

0.78

4.48

21.81

3.17

364.77

47.86

0.67

0.55

18.22

75.11

1.05

43.83

1.17

1.08

21.33

1.89

52209.08

59.5%

1315.15

6.89

9.98

427.97

106.77

3.22

0.66

0.69

15.34

6.19

3.72

75.45

52.72

3.14

0.80

4.44

21.58

3.16

361.23

47.62

0.67

0.58

18.17

74.34

1.05

43.53

1.20

0.98

21.22

1.84

Me

an2212.92

59.6%

1317.83

6.95

9.99

430.19

106.78

3.25

0.70

0.65

15.38

6.17

3.71

75.26

52.74

3.07

0.81

4.41

21.67

3.15

361.91

47.52

0.69

0.56

18.09

74.30

1.05

43.53

1.20

1.06

21.19

1.87

Q.5

2209.08

59.6%

1315.15

6.97

9.98

428.48

106.77

3.25

0.70

0.64

15.34

6.19

3.72

75.45

52.72

3.06

0.80

4.39

21.64

3.16

361.23

47.62

0.69

0.55

18.17

74.34

1.05

43.53

1.20

1.08

21.22

1.86

SD13.35

0.1%

8.22

0.07

0.05

3.03

0.77

0.04

0.02

0.02

0.11

0.05

0.03

0.65

0.44

0.06

0.03

0.04

0.13

0.03

1.89

0.26

0.02

0.01

0.15

0.62

0.02

0.23

0.02

0.04

0.12

0.02

RV

:I186.60

1.355

252.94

12.68

356.93

1415.1

351.24

203.13

23.20

54.17

69.26

23.19

463.25

264.99

141.77

21.91

67.50

30.65

73.20

37.55

2319.9

91.03

5.58

21.46

361.88

143.44

4.08

161.23

9.06

265.00

557.53

44.43

Job

Eva

luat

ion

(in

se

con

ds)

I VII III

IVIII T

CP

Figure 7.10.: Detailed Nordic Analytics performance analysis results.

84


One interesting detail is the difference between the standard deviation of Stages IVand V. It is obvious, that—even though Mean and Median do not significantly differfrom each other—the hard disk access of Stage V has an influence on the deviation ofexecution times.The per-Job results of Figure 7.10 show that some Jobs have a relatively small impact

on the execution time increase from one stage to another, whereas other Jobs have amuch more significant part in it. Jobs 18 and 24 are an example for that, particularlynoticeable by the difference of their ratio values. Job 18 has a huge performance impactratio of RIV :I = 2, 325, whereas Job 24 affects the execution time of Stage IV comparedto Stage I only with a ratio of RIV :I = 4.08. This is somewhat related to the sheeramount of operations each Job “produces”. For our example, Job 18 consist of 230,099operation executions (i.e., monitored method calls) and Job 24 of 44,574. But this aloneis not the reason for the difference, as other Jobs have far less operation executions,but a greater ratio. A deeper analysis of the nature of those Jobs would be required tounderstand the exact reasons for this behavior.

85

8. Conclusion

With the results presented in this thesis it is now possible to conduct comprehensive mon-itoring and dynamic analysis of applications developed with and targeting the Microsoft.NET Framework by employing the Java-based Kieker framework [Software EngineeringGroup, University of Kiel 2011].In Section 8.1 we summarize our work by outlining the contents of the individual

chapters of this thesis. The overall results are discussed in Section 8.2, including somefinal thoughts about the applicability of the presented techniques in real-world softwareenvironments.

8.1. SummaryExtending Kieker with its dynamic analysis capabilities to target the Microsoft .NETframework required us to go through several development stages, including some initialtechnological decisions.

.NET Integration of KiekerAfter giving a brief introduction to some basic terms and foundations to the field of ourwork in Chapter 2, we focused on finding answers to the question of how the integrationof Kieker into the .NET framework can be accomplished (Chapter 3). We presentedthree possible approaches and subsequently, based on a short evaluation, our solution—an implementation based on JNBridge [JNBridge LLC. 2011a].

Dynamic Analysis with Kieker.NETThe outcome of that first development stage was a .NET-compatible function library(KiekerProxy.dll) that enabled us to directly use and call the exposed Kieker Java classesand their methods, respectively, in .NET. Running examples using a sample applicationthroughout Chapter 4 proved that our solution was already capable of allowing basiccode instrumentation and dynamic analysis after that first stage.

87

8. Conclusion

AOP-Based Monitoring with Kieker.NETThe next step was finding a way to employ techniques based on the ideas of aspect-oriented programming to the newly developed Kieker.NET framework. In Chapter 5we provide a detailed description on how we implemented non-intrusive instrumentationtechniques using Postsharp [SharpCrafters s.r.o. 2011a]. With the post-compile-timeaspect weaver of Postsharp, our solution supports different options for weaving thecross-cutting concern (i.e., the monitoring probes) into a software system.

Overhead EvaluationA comprehensive evaluation of our solution was the closing development stage. Chapter 6provided an overhead evaluation in which we introduced a micro-benchmark to find outto what extend monitoring with Kieker.NET impacts the performance of a system underobservation.

Case Study: Nordic AnalyticsFinally, we applied Kieker.NET to our case study system Nordic Analytics by HSHNordbank AG and presented our findings in Chapter 7. This helped proving the practi-cality and robustness of our solution. We also conducted the same overhead evaluationwe developed for the micro-benchmark mentioned above with a Nordic Analytics testsuite that was also provided to us by HSH Nordbank AG.During first examinations of the Kieker.NET-generated component and operation de-

pendency models presented in Chapter 7 in cooperation with some of the developersof Nordic Analytics, we already identified spots where—according the HSH team—fartoo many calls to some specific components were obviously made and recorded by ourmonitoring framework. We take this as a proof-of-concept and are confident that theextended models we extracted, and which we will provide to the HSH team shortly, willcontribute to further increasing the maturity, robustness, and performance of NordicAnalytics.Thus, the first, second, and fourth goal of our work can be considered accomplished.

For accomplishing the first goal, we provided technical instrumentation of .NET appli-cation, as presented in Chapters 3 to 5. Towards reaching the second goal, we extractedseveral system models out of monitoring data obtained by dynamic analysis of both ourbookstore sample application as well as the case study system Nordic Analytics. Withthat, we also successfully evaluated our methodologies and therefore accomplished thefourth goal.

88

8.2. Discussion

Test GenerationBecause the case study system Nordic Analytics already had an elaborated and completetest suite, we shifted our focus in the later stages of our work towards comprehensiveoverhead analysis and model extraction presented in Chapters 6 and 7. Therefore,we could not reach our third goal, and did not provide any new methodologies for(automated) test generation.

8.2. Discussion

Technological ChoicesIn hindsight, the employment of JNBridge might not have been the ideal solution for theintegration of Kieker into .NET. JNBridge is a mature .NET/Java intercommunicationutility that can easily be used and held up well to most of the promises that are madeon its product website and the comprehensive users’ guide [JNBridge LLC. 2011b]. Butour overhead evaluation showed, with both the micro- and the macro-benchmark havingsimilar results, that the performance impact of our OperationExecutionAspect is quitesignificant. This is primarily caused by the calls to the Java-side through JNBridge.Comparing our overhead analysis results with the findings made by van Hoorn et al.[2009] makes it clear that a Java-side monitoring controller is definitely not the cause forsuch overhead. Their reported overhead is only about 2.5 microseconds per monitoredoperation, opposed to the 1.5 milliseconds we determined for Kieker.NET.The employment of Postsharp was convenient and no real drawbacks can be mentioned

in that context. In our opinion, the only downside of Postsharp is that it does not supportload-time aspect weaving, but that is probably more a fundamental characteristic of theapproach taken by Postsharp than a yet unimplemented feature.

Finding the “Right” Monitoring PointsFor most instrumented methods, applying a rather complex aspect like the Operation-

ExecutionAspect increases the amount of code to be executed by large. When instru-menting, for example, a simple “getter”, it suddenly becomes a multi-line operationwith several components involved. In our case, even proxy methods may be called viathe TCP/binary mechanism of JNBridge when configured this way. This fact pointsto the main struggle we had when trying to apply our lab-tested methodologies to thecomplex case study system Nordic Analytics. It literally took weeks of suffering from

89

8. Conclusion

disk space shortages and repeatedly crashing tools for graph generation caused by themassive overflow of monitored operation execution data before we managed to elaboratea decent instrumentation.Dynamic analysis should be taken into account in the earliest development stages of

any software system. This could be done by defining layers for monitoring points, so thatit is easier to differentiate between pure calculations and architecture- and component-wide calls. Monitoring of both categories most certainly has its use, but probably oftennot at the same time. During the refining process of the set of monitoring points forour case study system Nordic Analytics, it was obvious that a clearer line between purecalculations and “infrastructure” would have made dynamic analysis of this system mucheasier.

8.3. Future Work

Future work on the topics of this thesis could consist of the following points.

8.3.1. Kieker.NET

• Integrating Kieker.NET into the Kieker distribution and build process.

• Combining JNBridge configuration files with Kieker’s properties file by addingsome new entries to the latter. Likewise, configuration of the Java-side couldbe done programmatically. For this, a small Java client could be implementedthat replaces start-kieker-jvm.bat and starts the Java-side with all needed classes(JNBridge, Kieker) on the Java classpath.

• Adding support for other probes, records, etc. to Kieker.NET. All Java types canbe bridged with JNBridge.

• Finding a way to support load-time aspect weaving in .NET as AspectJ does inJava.

• Adding support for other .NET technologies like the Spring framework.

• Re-implementation of Records and MonitoringControllers would probably makesense due to large overhead caused by JNBridge communication.

90

8.3. Future Work

• Re-ordering of calls to the Java-side in OnEntry() and OnExit() could also mini-mize communication overhead. The same holds for evaluating alternative ways tomeasure a methods execution time, as Kieker.NET makes a Java call for that inits current state.

8.3.2. Model Extraction

It was originally intended to add support for other model types to Kieker’s analysiscomponent. Envisioned for this thesis were:

• Use Case Maps.

• UML Timing Diagrams.

• UML Sequence Diagrams annotated with timing information.

8.3.3. Test Generation

As we made no further research into this topic, hardly any advice for future work canbe given.

91

A. Kieker.NET Visual Studio Solution

A.1. The Bookstore Projects

Kieker.NET/Bookstore/

Properties/AssemblyInfo.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project specific build options

Bookstore.csBookstore.csproj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VS Project fileBookstoreStarter.csCatalog.csCRM.cs

BookstoreAnnotated/BookstoreInstrumented/Kieker/Kieker.NET.sln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kieker.NET VS solution file

Figure A.1.: Bookstore Visual Studio project structure.

A.1.1. Project Configuration

All Bookstore sample applications are plain .NET 4.0 C# console applications with nofurther customization.

A.1.2. References

There are no references other than the System library of .NET needed for the un-instrumented Bookstore sample application. For manual instrumentation (BookstoreIn-strumented), we need our generated KiekerProxy.dll as well as JNBridge’s JNBShare.dlland JNBSharedMem.dll to access the Kieker Java types. When using Postsharp aspects

93


in our annotated Bookstore example (BookstoreAnnotated), we also need a reference tothe Postsharp.dll library.

A.1.3. Classes

See the attached CD-ROM for the Visual Studio projects containing the different .NET-based Bookstore sample application classes.

A.2. The Kieker Project

Kieker.NET/Bookstore/BookstoreAnnotated/BookstoreInstrumented/Kieker/

Monitoring/Core/

Controller/MonitoringControllerWrapper.cs

Registry/ControlflowRegistry.cs

Probe/Postsharp/

OperationExecution/OperationExecutionAspect.csOperationExecutionAspectProvider.cs

Properties/AssemblyInfo.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project specific build options

Kieker.csproj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kieker VS project fileKieker.NET.sln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kieker.NET VS solution file

Figure A.2.: Visual Studio project structure of the .NET-based Kieker.

A.2.1. Project Configuration

In Figure A.3 we present the basic configuration for our Kieker.NET project. On theleft side are the project related settings, and the Solution Explorer on the right side

94


Figure A.3.: Kieker.NET Visual Studio configuration.

shows our project references (i.e., third party libraries, see Section A.2.2) and the classesKieker.NET consists of (Section A.2.3).Kieker.NET targets .NET Framework 3.5, as our major case study system, Nordic

Analytics by HSH Nordbank AG, is a .NET 2.0 application. These .NET versions arecompatible.The desired output type of our .NET project is just a class library, as we do not need

an application. All other settings are default for our Kieker.NET Visual Studio project.

A.2.2. References

JNBShare.dll is the runtime library of JNBridge that needs to be referenced in order toallow the referencing project to call Java methods through the proxy class. Thislibrary is needed for TCP/Binary or HTTP/SOAP based communication.

JNBSharedMem.dll is needed if JNBridge is configured to communicate with the Java-side via shared memory, i.e., the .NET side and Java side are running on the samemachine.

95


KiekerProxy.dll is the proxy library generated with the JNBProxy proxy generationtool. This library basically contains all exposed Java methods and therefore pro-vides those to the .NET side to be called by any .NET project that references thislibrary.

Postsharp.dll comes as part of the Postsharp distribution and is needed for creatingaspects out of attributes as well as compile-time aspect weaving.

A.2.3. Classes

All classes shown here can also be found in the Visual Studio project and solution folderson the attached CD-ROM.

OperationExecutionAspect

1 using System;2 using System.Reflection;3 using System.Text;4 using kieker.common.record; // Bridged Java class.5 using kieker.monitoring.core.controller; // Bridged Java class.6 using Kieker.Monitoring.Core.Controller;7 using Kieker.Monitoring.Core.Registry;8 using PostSharp.Aspects;910 namespace Kieker.Monitoring.Probe.Postsharp.OperationExecution11 {12 [Serializable]13 public class OperationExecutionAspect : OnMethodBoundaryAspect14 {15 // According to the Postsharp documentation , fields that are only16 // needed at runtime , and are unknown at compile -time , should be17 // marked with the [NonSerialized] attribute.18 [NonSerialized]19 private static IMonitoringController _ctrlInst;20 [NonSerialized]21 private static ControlFlowRegistry _cfRegistry;2223 private string _componentName;24 private string _method;2526 /// <summary >27 /// Compile -time initialization of component name , method name ,28 /// and parameter types of the method to which the current aspect29 /// instance has been applied.

96


30 /// </summary >31 /// <remarks >32 /// This improves runtime performance , as it avoids use of33 /// <c>System.Reflection </c> as well as string building at34 /// runtime.35 /// </remarks >36 /// <param name=" method">37 /// Method to which the current aspect instance has been applied.38 /// </param >39 public override void CompileTimeInitialize(MethodBase method ,

AspectInfo aspectInfo)40 {41 _componentName = FormatType(method.DeclaringType.FullName);42 _method = FormatMethodName(method.Name) + FormatParameters(

method.GetParameters ());43 }4445 /// <summary >46 /// Initializes the current aspect at run time.47 /// </summary >48 /// <param name=" method">49 /// Method to which the current aspect is applied.50 /// </param >51 public override void RuntimeInitialize(MethodBase method)52 {53 _ctrlInst = MonitoringControllerWrapper.MonitoringController;54 _cfRegistry = ControlFlowRegistry.Instance;55 }5657 /// <summary >58 /// Method executed <b>before </b> the body of methods to which59 /// this aspect is applied.60 /// </summary >61 /// <param name="args">62 /// Event arguments specifying which method is being executed ,63 /// which are its arguments , etc.64 /// </param >65 public override void OnEntry(MethodExecutionArgs args)66 {67 if (! _ctrlInst.isMonitoringEnabled ())68 {69 return;70 }71 OperationExecutionRecord execData = InitExecutionData ();72 int eoi = 0; // execution order index73 int ess = 0; // execution stack size74 if (execData.isEntryPoint)75 {76 _cfRegistry.StoreThreadLocalEoi (0);77 _cfRegistry.StoreThreadLocalEss (1);

97


78 }79 else80 {81 eoi = _cfRegistry.IncrementAndRecallThreadLocalEoi ();82 ess = _cfRegistry.RecallAndIncrementThreadLocalEss ();83 }84 if ((eoi == -1) || (ess == -1))85 {86 Console.WriteLine("eoi and/or ess have invalid values:" +

" eoi == " + eoi + " ess == " + ess);87 _ctrlInst.terminateMonitoring ();88 }89 execData.eoi = eoi;90 execData.ess = ess;91 // Time when monitored method begins execution.92 execData.tin = _ctrlInst.getTimeSource ().getTime ();93 // Store execData for use in OnExit ().94 args.MethodExecutionTag = execData;95 }969798 /// <summary >99 /// Method executed <b>after </b> the body of methods to which this100 /// aspect is applied , even when the method exits with an101 /// exception (this method is invoked from the <c>finally </c>102 /// block).103 /// </summary >104 /// <param name="args">105 /// Event arguments specifying which method is being executed and106 /// which are its arguments.107 /// </param >108 public override void OnExit(MethodExecutionArgs args)109 {110 if (! _ctrlInst.isMonitoringEnabled ())111 {112 return;113 }114115 // Restore execData.116 OperationExecutionRecord execData = (OperationExecutionRecord)

args.MethodExecutionTag;117118 // Time the monitored method is finished.119 execData.tout = _ctrlInst.getTimeSource ().getTime ();120 if (execData.isEntryPoint)121 {122 _cfRegistry.UnsetThreadLocalTraceId ();123 }124125 // Create a new monitoring record with the measured data.

98


126 _ctrlInst.newMonitoringRecord(execData);127 if (execData.isEntryPoint)128 {129 _cfRegistry.UnsetThreadLocalEoi ();130 _cfRegistry.UnsetThreadLocalEss ();131 }132 else133 {134 _cfRegistry.StoreThreadLocalEss(execData.ess);135 }136 }137138 /// <summary >139 /// Initializes all relevant data for monitoring.140 /// </summary >141 /// <returns >142 /// The <c>OperationExecutionRecord </c> for this monitoring143 /// session.144 /// </returns >145 private OperationExecutionRecord InitExecutionData ()146 {147 long traceId = _cfRegistry.RecallThreadLocalTraceId ();148 OperationExecutionRecord execData = new

OperationExecutionRecord(_componentName , _method , traceId);149 execData.isEntryPoint = false;150 if (execData.traceId == -1)151 {152 execData.traceId = _cfRegistry.

GetAndStoreUniqueThreadLocalTraceId ();153 execData.isEntryPoint = true;154 }155 execData.hostName = _ctrlInst.getHostName ();156 execData.experimentId = _ctrlInst.getExperimentId ();157 return execData;158 }159160 /// <summary >161 /// Can be used to cut the names of generic types that contain the162 /// string " ‘1[...]".163 /// </summary >164 /// <param name="name">165 /// The type name as string to be formatted.166 /// </param >167 /// <returns >The formatted type name as string.</returns >168 private static string FormatType(string name)169 {170 if (name != null && name.Contains("‘"))171 {172 string [] names = name.Split(new char[] {’‘’});173 name = names [0];

99


174 }175 return name;176 }177178179 /// <summary >180 /// For some reason , <code >args.Method.Name </code > is ".ctor" for181 /// constructors , whereas there is no "." for all other methods.182 /// </summary >183 /// <param name="name">The string to be formatted.</param >184 /// <returns >The formatted string withoud a leading ".".</ returns >185 private static string FormatMethodName(string name)186 {187 if (name.IndexOf(’.’) == 0)188 {189 name = name.Substring (1);190 }191 return name;192 }193194 /// <summary >195 /// Creates a string that contains the parameter types.196 /// </summary >197 /// <param name=" parameters">198 /// A method ’s list of parameters.199 /// </param >200 /// <returns >201 /// The formatted parameter list as string , e.g.202 /// <c>( System.Int32 , System.String)</c>.203 /// </returns >204 private static string FormatParameters(ParameterInfo [] parameters)205 {206 StringBuilder formattedParameters = new StringBuilder("(");207 for (int i = 0; i < parameters.Length; i++)208 {209 formattedParameters.Append(FormatType(parameters[i].

ParameterType.FullName));210 if (parameters.Length > 1 && i < parameters.Length - 1)211 {212 formattedParameters.Append(", ");213 }214 }215 formattedParameters.Append(")");216 return formattedParameters.ToString ();217 }218 }219 }

Listing A.1: OperationExecutionAspect class.

100


OperationExecutionAspectProvider

1 using System;2 using System.Collections.Generic;3 using System.Reflection;4 using PostSharp.Aspects;56 namespace Kieker.Monitoring.Probe.Postsharp.OperationExecution7 {8 /// <summary >9 /// This class allows build -independent aspect application to10 /// 3rd-party libraries where no source code is available.11 /// </summary >12 public class OperationExecutionAspectProvider : IAspectProvider13 {14 readonly OperationExecutionAspect _aspectToApply = new

OperationExecutionAspect ();1516 public IEnumerable <AspectInstance > ProvideAspects(object

targetElement)17 {18 Assembly assembly = (Assembly)targetElement;19 List <AspectInstance > instances = new List <AspectInstance >();20 foreach (Type type in assembly.GetTypes ())21 {22 ProcessType(type , instances);23 }24 return instances;25 }2627 private void ProcessType(Type type , List <AspectInstance > instances

)28 {29 foreach (MethodInfo targetMethod in type.GetMethods(

BindingFlags.Instance | BindingFlags.Public | BindingFlags.DeclaredOnly))

30 {31 instances.Add(new AspectInstance(targetMethod ,

_aspectToApply));32 }3334 foreach (Type nestedType in type.GetNestedTypes ())35 {36 ProcessType(nestedType , instances);37 }38 }39 }40 }

Listing A.2: OperationExecutionAspectProvider class.

101


MonitoringControllerWrapper.cs

1 using System;2 using kieker.monitoring.core.configuration; // Bridged Java class.3 using kieker.monitoring.core.controller; // Bridged Java class.45 namespace Kieker.Monitoring.Core.Controller6 {7 /// <summary >8 /// This class wraps the Java MonitoringController object.9 /// </summary >10 internal class MonitoringControllerWrapper11 {12 private static readonly object SyncRoot = new Object ();13 private static IMonitoringController _monitoringController;1415 internal static IMonitoringController MonitoringController16 {17 get18 {19 if (_monitoringController == null)20 {21 lock (SyncRoot)22 {23 if (_monitoringController == null)24 _monitoringController = kieker.monitoring.core

.controller.MonitoringController.createInstance(Configuration.createSingletonConfiguration ());

25 AppDomain.CurrentDomain.ProcessExit +=CurrentDomainProcessExit;

26 }27 }28 return _monitoringController;29 }30 }3132 private static void CurrentDomainProcessExit(object sender ,

EventArgs e)33 {34 if (_monitoringController != null)35 {36 _monitoringController.terminateMonitoring ();37 }38 }3940 }41 }

Listing A.3: MonitoringControllerWrapper class.

102


ControlFlowRegistry.cs

1 using System;23 namespace Kieker.Monitoring.Core.Registry4 {5 /// <summary >6 /// This class is more ore less a direct copy of the java class.7 /// </summary >8 /// <remarks >9 /// Re-implemented because of the multi -threading capabilities that10 /// should be handled directly in .NET.11 /// </remarks >12 internal class ControlFlowRegistry13 {14 private static readonly object SyncRoot = new Object ();15 private static volatile ControlFlowRegistry _instance;1617 private long _lastThreadId;1819 [ThreadStatic]20 private static long _threadLocalTraceId;21 [ThreadStatic]22 private static int _threadLocalEoi;23 [ThreadStatic]24 private static int _threadLocalEss;2526 /// <summary >27 /// Thread -safe Singelton implementation28 /// </summary >29 internal static ControlFlowRegistry Instance30 {31 get32 {33 if (_instance == null)34 {35 lock (SyncRoot)36 {37 if (_instance == null)38 _instance = new ControlFlowRegistry ();39 }40 }41 return _instance;42 }43 }4445 /// <summary >46 /// In order to (probabilistically !) avoid that other instances in47 /// our system (on another node , in another vm, ...) generate the48 /// same thread ids , we fill the left -most 16 bits of the thread

103


49 /// id with a uniquely distributed random number50 /// (0 ,0000152587890625 = 0 ,00152587890625%).51 /// As a consequence , this constitutes a uniquely distributed52 /// offset of size 2^(64 -1 -16) = 2^47 = 140737488355328L in the53 /// worst case. We restrict ourselves to the positive long values54 /// so far. Of course , negative values may occur (as a result of55 /// an overflow) -- this does not hurt!56 /// </summary >57 private ControlFlowRegistry ()58 {59 Random r = new Random ();60 long baseValue = ((long)r.Next (65536) << (sizeof(long) - 16 -

1));61 _lastThreadId = baseValue;62 }6364 /// <summary >65 /// This (thread -safe) method provides a trace id.66 /// </summary >67 /// <remarks >68 /// Since we use -1 as a marker for an invalid trace id, it must69 /// not be returned! The 0 stands for an uninitialized trace id70 /// and must also not be returned.71 /// </remarks >72 /// <returns >A globally unique trace id.</returns >73 public long GetUniqueTraceId ()74 {75 lock (SyncRoot)76 {77 _lastThreadId ++;78 if (_lastThreadId == -1)79 {80 _lastThreadId ++;81 }82 if (_lastThreadId == 0)83 {84 _lastThreadId ++;85 }86 }87 return _lastThreadId;88 }8990 /// <summary >91 /// This method returns a thread -local trace id which is globally92 /// unique and stores it locally for the thread.93 /// </summary >94 /// <remarks >95 /// The thread is responsible for invalidating the stored96 /// trace id using the method <c>unsetThreadLocalTraceId () </c>!97 /// </remarks >

104


98 /// <returns >A thread -local trace id </returns >99 public long GetAndStoreUniqueThreadLocalTraceId ()100 {101 _threadLocalTraceId = GetUniqueTraceId ();102 return _threadLocalTraceId;103 }104105 /// <summary >106 /// This method stores a thread -local trace id.107 /// </summary >108 /// <remarks >109 /// The thread is responsible for invalidating the stored110 /// trace id using the method <c>unsetThreadLocalTraceId () </c>!111 /// </remarks >112 /// <param name=" traceId">113 /// The current trace id to be stored.114 /// </param >115 public void StoreThreadLocalTraceId(long traceId)116 {117 _threadLocalTraceId = traceId;118 }119120 /// <summary >121 /// This method returns the thread -local trace id previously122 /// registered.123 /// </summary >124 /// <returns >125 /// The trace id. -1 if no trace id has been registered for this126 /// thread.127 /// </returns >128 public long RecallThreadLocalTraceId ()129 {130 if (_threadLocalTraceId == 0)131 {132 _threadLocalTraceId = -1;133 }134 return _threadLocalTraceId;135 }136137 /// <summary >138 /// This method unsets a previously registered trace id.139 /// </summary >140 public void UnsetThreadLocalTraceId ()141 {142 _threadLocalTraceId = -1;143 }144145 /// <summary >146 /// Used to explicitly register an execution order index (eoi).147 /// </summary >

105


148 /// <remarks >149 /// The thread is responsible for invalidating the stored eoi150 /// using the method <c>UnsetThreadLocalEoi () </c>!151 /// </remarks >152 /// <param name="eoi">153 /// The execution order index (eoi) to store.154 /// </param >155 public void StoreThreadLocalEoi(int eoi)156 {157 _threadLocalEoi = eoi;158 }159160 public int IncrementAndRecallThreadLocalEoi ()161 {162 int curEoi = _threadLocalEoi;163 if (curEoi == -1)164 {165 return -1;166 }167 int newEoi = curEoi + 1;168 _threadLocalEoi = newEoi;169 return newEoi;170 }171172173 /// <summary >174 /// Returns the thread -local execution order index (eoi)175 /// previously registered.176 /// </summary >177 /// <returns >178 /// The execution order index (eoi). -1 if no eoi registered.179 /// </returns >180 public int RecallThreadLocalEoi ()181 {182 return _threadLocalEoi;183 }184185 /// <summary >186 /// Unsets a previously registered execution order index (eoi).187 /// </summary >188 public void UnsetThreadLocalEoi ()189 {190 _threadLocalEoi = -1;191 }192193 /// <summary >194 /// Used to explicitly register an execution stack size (ess).195 /// </summary >196 /// <remarks >197 /// The thread is responsible for invalidating the stored ess

106


198 /// using the method <c>UnsetThreadLocalEss () </c>!199 /// </remarks >200 /// <param name="ess">201 /// The execution stack size (ess) to store.202 /// </param >203 public void StoreThreadLocalEss(int ess)204 {205 _threadLocalEss = ess;206 }207208 /// <summary >209 /// Recalls and increments the current thread -local execution210 /// stack size (ess).211 /// </summary >212 /// <returns >The incremented execution stack size (ess)</returns >213 public int RecallAndIncrementThreadLocalEss ()214 {215 int curEss = _threadLocalEss;216 if (curEss == -1)217 {218 return -1;219 }220 _threadLocalEss = curEss + 1;221 return curEss;222 }223224 /// <summary >225 /// Returns the thread -local execution stack size (ess).226 /// </summary >227 /// <returns >228 /// The thread -local execution stack size (ess). -1 if no ess229 /// registered.230 /// </returns >231 public int RecallThreadLocalEss ()232 {233 return _threadLocalEss;234 }235236 /// <summary >237 /// Unsets a previously registered execution stack size (ess).238 /// </summary >239 public void UnsetThreadLocalEss ()240 {241 _threadLocalEss = -1;242 }243 }244 }

Listing A.4: ControlFlowRegistry class.

107

B. JNBridge Related ConfigurationFiles and Scripts

B.1. Kieker Proxy Generation with JNBProxy

1 @ECHO OFF2 SETLOCAL34 SET JNBRIDGE=C:\Program Files (x86)\JNBridge\JNBridgePro v5.1\5 SET KIEKER=C:\Kieker6 SET CLASSPATH=%KIEKER%\dist;%KIEKER%\dist\kieker-1 .4 -dev-SNAPSHOT.jar;

%KIEKER%\lib;%KIEKER%\lib\commons-logging-1 .1.1. jar7 SET CLASSLIST=C:\Kieker.JNB\KiekerProxy-classList.txt8 SET DLL_NAME=KiekerProxy9 SET DLL_VERSION =1.4.0.010 SET JAVA=C:\Windows\system32\java.exe1112 "%JNBRIDGE%2 .0 -targeted\jnbproxy.exe" /ns /pd n2j /cp "%CLASSPATH%" /f "

%CLASSLIST%" /d . /n %DLL_NAME% /jp "%JNBRIDGE%jnbcore\jnbcore.jar" /bp"%JNBRIDGE%jnbcore\bcel-5 .1 -jnbridge.jar" /pro b /host localhost /port8085 /java "%JAVA%" /vn %DLL_VERSION%

Listing B.1: Proxy generation BATCH script.

1 java.lang.Class r2 java.lang.Object r3 kieker.common.record.AbstractMonitoringRecord r4 kieker.common.record.BranchingRecord r5 kieker.common.record.CPUUtilizationRecord r6 kieker.common.record.CurrentTimeRecord r7 kieker.common.record.IMonitoringRecord r8 kieker.common.record.MemSwapUsageRecord r9 kieker.common.record.OperationExecutionRecord r10 kieker.common.record.ResourceUtilizationRecord r11 kieker.monitoring.core.configuration.Configuration r12 kieker.monitoring.core.controller.AbstractController r

109

B. JNBridge Related Configuration Files and Scripts

13 kieker.monitoring.core.controller.IMonitoringController r14 kieker.monitoring.core.controller.MonitoringController r15 kieker.monitoring.core.sampler.ISampler r16 kieker.monitoring.core.sampler.ScheduledSamplerJob r17 kieker.monitoring.timer.ITimeSource r

Listing B.2: Kieker proxy class list text file that defines which Java classes to expose.

B.2. Monitoring Configuration Files

B.2.1. Java-Side

1 @ECHO OFF2 SETLOCAL34 SET JNBRIDGE=C:\Program Files (x86)\JNBridge\JNBridgePro v5.15 SET KIEKER=C:\Kieker6 SET CLASSPATH=%KIEKER% \; %KIEKER%\dist\kieker-1 .4 -dev-SNAPSHOT.jar;%KIEKER%

\lib\commons-logging-1 .1.1. jar;%JNBRIDGE%\jnbcore\jnbcore.jar;%JNBRIDGE%\jnbcore\bcel-5 .1 -jnbridge.jar

78 START java -cp "%CLASSPATH%" com.jnbridge.jnbcore.JNBMain /props "

%JNBRIDGE%\jnbcore\jnbcore_tcp.properties"

Listing B.3: Batch file to start Kieker JVM.

1 # Java -side (.NET -to-Java) properties2 javaSide.serverType=tcp3 javaSide.workers =54 javaSide.timeout =100005 javaSide.port =80856 # .NET -side (Java -to -.NET) properties7 dotNetSide.serverType=tcp8 dotNetSide.host=localhost9 dotNetSide.port =8086

Listing B.4: jnbcore properties file for JNBridge (TCP).

1 # Java -side (.NET -to-Java) properties2 javaSide.serverType=http3 javaSide.workers =54 javaSide.timeout =100005 javaSide.port =8085

110

B.2. Monitoring Configuration Files

6 # .NET -side (Java -to -.NET) properties7 dotNetSide.serverType=http8 dotNetSide.host=localhost9 dotNetSide.port =8086

Listing B.5: jnbcore properties file for JNBridge (HTTP).

1 # .NET -side (Java -to -.NET) properties2 dotNetSide.serverType=sharedmem34 # edit optional paths to .NET -side assemblies here5 # IMPORTANT: Use front -slashes (/) in all file paths below6 dotNetSide.assemblyList .1= path to first .NET -side assembly7 dotNetSide.assemblyList .2= path to second .NET -side assembly8 # supply as many .NET -side assemblies as necessary910 # edit path to JNBJavaEntry.dll here11 # IMPORTANT: Use front -slashes (/) in all file paths below12 dotNetSide.javaEntry=C:/ Program Files/JNBridge/JNBridgePro v4.1/2.0 -

targeted/JNBJavaEntry.dll1314 # edit optional path to .NET -side application configuration file below15 # IMPORTANT: Use front -slashes (/) in all file paths below16 # dotNetSide.appConfig=path to .NET -side application configuration file

Listing B.6: jnbcore properties file for JNBridge (shared memory, only needed for Java/.NET directed communication).

B.2.2. .NET-Side

1 <?xml version="1.0" encoding="utf -8" ?>2 <configuration >3 <configSections >4 <sectionGroup name="jnbridge">5 <section name="dotNetToJavaConfig"6 type="System.Configuration.SingleTagSectionHandler ,7 System , Version =2.0.0.0 ,8 Culture=neutral , PublicKeyToken=b77a5c561934e089"/>9 <section name="javaToDotNetConfig"10 type="System.Configuration.SingleTagSectionHandler ,11 System , Version =2.0.0.0 ,12 Culture=neutral , PublicKeyToken=b77a5c561934e089"/>13 <section name="tcpNoDelay"14 type="System.Configuration.SingleTagSectionHandler ,15 System , Version =2.0.0.0 ,16 Culture=neutral , PublicKeyToken=b77a5c561934e089"/>

111

B. JNBridge Related Configuration Files and Scripts

17 <section name="javaSideDeclarations"18 type="System.Configuration.NameValueSectionHandler ,19 System , Version =2.0.0.0 ,20 Culture=neutral , PublicKeyToken=b77a5c561934e089"/>21 </sectionGroup >22 </configSections >23 <jnbridge >24 <dotNetToJavaConfig scheme="jtcp"25 host="localhost"26 port="8085"27 useSSL="false" />28 </jnbridge >29 </configuration >

Listing B.7: .NET application configuration file for TCP/Binary communication withJNBridge.

1 <jnbridge >2 <dotNetToJavaConfig scheme="sharedmem"3 jvm="%JAVA_HOME %\ server\jvm.dll"4 jnbcore="%JNBRIDGE %\ jnbcore\jnbcore.jar"5 bcel="%JNBRIDGE %\ jnbcore\bcel -5.1- jnbridge.jar"6 classpath="%KIEKER %;7 %KIEKER %\dist;8 %KIEKER %\dist\Kieker -1.4. jar;9 %KIEKER %\lib;10 %KIEKER %\lib\commons -logging -1.1.1. jar" />11 </jnbridge >

Listing B.8: .NET application configuration file entry for shared memory communicationwith JNBridge.

112

Bibliography

[Bennett 1995] K. Bennett. Legacy systems: Coping with success. IEEE Software, 12:19–23, January 1995.

[Bisbal et al. 1999] J. Bisbal, D. Lawless, B. Wu, and J. Grimson. Legacy informationsystems: issues and directions. Software, IEEE, 16(5):103 –111, September 1999.

[Brodie and Stonebraker 1995] M. Brodie and M. Stonebraker. Migrating legacy sys-tems: gateways, interfaces & the incremental approach. Morgan Kaufmann PublishersInc., San Francisco, CA, USA, 1995.

[Comella-Dorda et al. 2000] S. Comella-Dorda, K. Wallnau, R. Seacord, and J. Robert.A survey of black-box modernization approaches for information systems. In SoftwareMaintenance, 2000. Proceedings. International Conference on, pages 173 –183, 2000.

[Cornelissen et al. 2009] B. Cornelissen, A. Zaidman, A. van Deursen, L. Moonen,and R. Koschke. A systematic survey of program comprehension through dynamicanalysis. IEEE Transactions on Software Engineering, 35(5):684–702, 2009.

[Desiderata Software 2011] Desiderata Software. EZ JCom version 1.8, May 2011. URLhttp://www.ezjcom.com/. Last visited July 12, 2011.

[Ehmke et al. 2011] N. Ehmke, A. van Hoorn, and R. Jung. Kieker 1.4 User Guide,October 2011. URL http://se.informatik.uni-kiel.de/kieker/documentation/.Last visited October 13, 2011.

[Gamma et al. 1995] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design patterns:elements of reusable object-oriented software. Addison-Wesley Longman PublishingCo., Inc., Boston, MA, USA, 1995.

113

http://www.ezjcom.com/

http://se.informatik.uni-kiel.de/kieker/documentation/

Bibliography

[Intrinsyc Software International, Inc. 2011] Intrinsyc Software International, Inc. J-Integra .NET version 2.4, May 2011. URL http://j-integra.intrinsyc.com/net.

asp. Last visited July 12, 2011.

[JNBridge LLC. 2011a] JNBridge LLC. JNBridgePro version 5.1, July 2011a. URLhttp://www.jnbridge.com/jnbpro.htm. Last visited September 15, 2011.

[JNBridge LLC. 2011b] JNBridge LLC. JNBridgePro Users’ Guide version 6.0, May2011b. URL http://www.jnbridge.com/usersguide.pdf. Last visited September 15,2011.

[JNBridge LLC. 2011c] JNBridge LLC. JNBridgePro Evaluation and Quick Start Guideversion 6.0, April 2011c. URL http://www.jnbridge.com/evaluationguide.pdf.Last visited September 15, 2011.

[Khusidman 2008] V. Khusidman. ADM Transformation, June 2008. URL http:

//adm.omg.org/.

[Kiczales et al. 1997] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. V. Lopes,J.-M. Loingtier, and J. Irwin. Aspect-oriented programming. In Proceedings of theEuropean Conference on Object-Oriented Programming (ECOOP ’97), pages 220–242,1997.

[OMG 2009] OMG. Architecture-Driven Modernization (ADM): Software MetricsMeta-Model (KDM), March 2009. URL http://www.omg.org/spec/SMM/Current.

[OMG 2010] OMG. Architecture-Driven Modernization (ADM): Knowledge Discov-ery Meta-Model (KDM), December 2010. URL http://www.omg.org/spec/KDM/

Current/.

[SharpCrafters s.r.o. 2011a] SharpCrafters s.r.o. Postsharp version 2.1, September2011a. URL http://www.sharpcrafters.com.

[SharpCrafters s.r.o. 2011b] SharpCrafters s.r.o. Postsharp reference documentation,September 2011b. URL http://www.sharpcrafters.com/postsharp/documentation.

[Software Engineering Group, University of Kiel 2011] Software Engineering Group,University of Kiel. Kieker version 1.4, 2011. URL http://se.informatik.uni-kiel.

de/kieker/. Last visited August 29, 2011.

114

http://j-integra.intrinsyc.com/net.asp

http://j-integra.intrinsyc.com/net.asp

http://www.jnbridge.com/jnbpro.htm

http://www.jnbridge.com/usersguide.pdf

http://www.jnbridge.com/evaluationguide.pdf

http://adm.omg.org/

http://adm.omg.org/

http://www.omg.org/spec/SMM/Current

http://www.omg.org/spec/KDM/Current/

http://www.omg.org/spec/KDM/Current/

http://www.sharpcrafters.com

http://www.sharpcrafters.com/postsharp/documentation



Bibliography

[Stahl and Völter 2006] T. Stahl and M. Völter. Model-Driven Software Development:Technology, Engineering, Management. Wiley, Chichester, UK, 2006.

[Ulrich and Khusidman 2007] W. Ulrich and V. Khusidman. Architecture-Driven Mod-ernization: Transforming the Enterprise, October 2007. URL http://adm.omg.org/.

[van Hoorn et al. 2009] A. van Hoorn, M. Rohr, W. Hasselbring, J. Waller, J. Ehlers,S. Frey, and D. Kieselhorst. Continuous monitoring of software services: Designand application of the Kieker framework. Technical Report TR-0921, Department ofComputer Science, University of Kiel, Germany, November 2009. URL http://www.

informatik.uni-kiel.de/uploads/tx_publication/vanhoorn_tr0921.pdf.

[van Hoorn et al. 2011] A. van Hoorn, S. Frey, W. Goerigk, W. Hasselbring, H. Knoche,S. Köster, H. Krause, M. Porembski, T. Stahl, M. Steinkamp, and N. Wittmüss. Dy-naMod project: Dynamic analysis for model-driven software modernization. In JointProceedings of the 1st International Workshop on Model-Driven Software Migration(MDSM 2011) and the 5th International Workshop on Software Quality and Main-tainability (SQM 2011), pages 12–13, March 2011.

115

http://adm.omg.org/

http://www.informatik.uni-kiel.de/uploads/tx_publication/vanhoorn_tr0921.pdf

http://www.informatik.uni-kiel.de/uploads/tx_publication/vanhoorn_tr0921.pdf

Acknowledgments

I’d like to thank

• my advisor André van Hoorn for his support and advice.

• HSH Nordbank AG for providing desk space and a laptop with a copy of NordicAnalytics, and specifically Sönke Köster and Dr. Marcus Steinkamp of the Fi-nancial Engineering department for all the information and courtesy for the casestudy with their risk evaluation system.

• Prof. Dr. Wilhelm Hasselbring for making this diploma thesis possible.

117

Declaration

This thesis is my own work and contains no material that has been submitted for anydegree or examination at any other university.To the best of my knowledge and belief, this thesis contains no material previously

published by any other person except where due acknowledgment has been made.

Kiel, October 15, 2011

Felix Magedanz

119

dynamicanalysisof.netapplications forarchitecture-basedmodel...

Documents