Evaluierung von Reporting-Frameworks am Beispiel der ...blogs.gm.fh-koeln.de/faeskorn/files/2008/11/diplom_eval_ado.pdf · Evaluierung von Reporting-Frameworks am Beispiel der ausgewählten

Evaluierung von Reporting-Frameworks am Beispiel

der ausgewählten Open-Source-Anwendungen.

Diplomarbeit

vorgelegt an der Fachhochschule Köln

Campus Gummersbach

im Studiengang Allgemeine Informatik

ausgearbeitet von:

Andrej Doumack

11032929

Erster Prüfer: Prof. Dr. Heide Faeskorn-Woyke

Zweiter Prüfer: Dipl.-Kfm. Kai Lehmann

Gummersbach, im Oktober 2008

S e i t e 1

Abstrakt

In der vorliegenden Arbeit werden ausgewählte Business Intelligence Reporting-

Frameworks aus dem Open Source Bereich verglichen. Dabei wird eine idealtypische

Architektur von Business Intelligence aufgezeigt und eine Einordnung vom

Berichtswesen durchgeführt. In diesem Zusammenhang werden einige theoretische

Eigenschaften von Berichten aufgezeigt.

Um einen Überblick über die Vor- und Nachteile der ausgewählten Frameworks zu

geben, muss ein Kriterienkatalog erarbeitet werden, der eine Bewertung nach

unterschiedlichen Gesichtspunkten ermöglichen soll. Es wird ein besonderer

Schwerpunkt auf die Kriterien aus der Programmierersicht und der Anwendersicht

gelegt. Auf den Kriterienkatalog werden anschließend die ausgewählten Reporting-

Frameworks angewendet, und die Ergebnisse in einer Gesamtübersicht präsentiert, die

eine objektive Empfehlung für das Unternehmen darstellen soll.

Die Evaluierung wurde für das Unternehmen Ikom Unternehmensberatung GmbH

durchgeführt, damit eines der ausgewählten Reporting-Anwendungen später in die

hauseigene Entwicklung integriert werden kann.

S e i t e 2

Inhaltsverzeichnis

Abbildungsverzeichnis .................................................................................................... 5

Tabellenverzeichnis ......................................................................................................... 6

Listingverzeichnis ............................................................................................................ 8

Abkürzungs- und Symbolverzeichnis ............................................................................ 9

Glossar ............................................................................................................................ 10

1. Einleitung ................................................................................................................... 11

1.1. Problembeschreibung ........................................................................................... 11

1.2. Zielsetzung ........................................................................................................... 11

1.3. Inhalt der Diplomarbeit ........................................................................................ 12

2. Business Intelligence und Reporting ....................................................................... 14

2.1. Business Intelligence – theoretische Grundlagen ................................................ 14

2.1.1. Begriffsdefinition .................................................................................................................... 14

2.1.2. Architektur .............................................................................................................................. 17

2.2. Einordnung des Berichtswesens ........................................................................... 18

2.3. Berichtsgestaltung ................................................................................................ 19

2.4. Open Source ......................................................................................................... 21

3. Vorbereitung der Evaluierung ................................................................................. 22

3.1. Evaluierungs-Model ............................................................................................. 22

3.2. Kriterienkatalog.................................................................................................... 23

3.2.1. Kriterien für Vorbewertung .................................................................................................... 23

3.2.2. Kriterien für Hauptbewertung ................................................................................................. 24

3.3. Testberichte .......................................................................................................... 35

3.3.1. Einleitung................................................................................................................................ 35

3.3.2. Übersicht ................................................................................................................................. 35

3.4. Benchmarkanwendung ......................................................................................... 36

3.4.1. Beschreibung .......................................................................................................................... 36

3.4.2. Architektur .............................................................................................................................. 36

4. Auswahl und Vorstellung der Frameworks ............................................................ 38

4.1. Softwareauswahl .................................................................................................. 38

I n h a l t s v e r z e i c h n i s S e i t e 3

4.2. Pentaho Reporting ................................................................................................ 38

4.2.1. Einführung .............................................................................................................................. 38

4.2.2. Funktionsweise ....................................................................................................................... 39

4.2.3. Architektur .............................................................................................................................. 40

4.3. JasperReports ....................................................................................................... 41

4.3.1. Einführung .............................................................................................................................. 41

4.3.2. Funktionsweise ....................................................................................................................... 41

4.3.3. Architektur .............................................................................................................................. 42

4.4. BIRT ..................................................................................................................... 45

4.4.1. Einführung .............................................................................................................................. 45

4.4.2. Funktionsweise ....................................................................................................................... 46

4.4.3. Architektur .............................................................................................................................. 47

5. Durchführung der Evaluierung ............................................................................... 53

5.1. Verteilung der Gewichtungen bei Kategorien...................................................... 53

5.1.1. Gewichtungen unter der Kategorie Functionality ................................................................... 55

5.1.2. Gewichtungen unter Kategorie Usability ................................................................................ 60

5.1.3. Gewichtungen unter Kategorie Documentation ...................................................................... 60

5.1.4. Gewichtungen unter Kategorie Quality .................................................................................. 61

5.1.5. Gewichtungen unter Kategorie Architecture .......................................................................... 61

5.1.6. Gewichtungen unter Kategorie Scalability ............................................................................. 62

5.1.7. Gewichtungen unter Kategorie Community ........................................................................... 62

5.2. Bewertung der Frameworks ................................................................................. 63

5.2.1. Bewertung in der Kategorie Functionality .............................................................................. 63

5.2.2. Bewertung in der Kategorie Usability .................................................................................... 65

5.2.3. Bewertung in der Kategorie Documentation .......................................................................... 67

5.2.4. Bewertung in der Kategorie Quality ....................................................................................... 68

5.2.5. Bewertung in der Kategorie Architecture ............................................................................... 69

5.2.6. Bewertung in der Kategorie Scalability .................................................................................. 70

5.2.7. Bewertung in der Kategorie Community ................................................................................ 71

5.2.8. Ergebnisse der BRR-Bewertung ............................................................................................. 71

5.2.9. Zusatzbewertung der Benutzeroberfläche ............................................................................... 72

5.2.10. Ergebnisse der Zusatzbewertung der Benutzeroberfläche .................................................... 78

5.3. Performance und Speicherauslastung .................................................................. 79

5.3.1. Testumgebung ........................................................................................................................ 79

5.3.2. Ergebnisse JasperReports ....................................................................................................... 80

5.3.3. Ergebnisse Birt ....................................................................................................................... 81

I n h a l t s v e r z e i c h n i s S e i t e 4

5.3.4. Ergebnisse Pentaho Reporting ................................................................................................ 83

5.3.5. Gegenüberstellung der Performance und Speicherauslastung ................................................ 84

5.4. Entscheidungsmatrix ............................................................................................ 88

6. Zusammenfassung ..................................................................................................... 89

Literaturverzeichnis ...................................................................................................... 91

Anhang ........................................................................................................................... 96

S e i t e 5

Abbildungsverzeichnis

Abbildung 1, unterschiedliche Facetten und Abgrenzungen von Business Intelligence. ...................16

Abbildung 2, BI-Schichtenmodell. ......................................................................................................17

Abbildung 3, Prozesse des betrieblichen Berichtswesens. ..................................................................19

Abbildung 4, Merkmale zur Kennzeichnung und Gestaltung von Berichten. ...................................20

Abbildung 5, 4 Phasen des BRR-Models. ...........................................................................................22

Abbildung 6, Klassendiagramm von der ReportBenchmark-Anwendung. .......................................36

Abbildung 7, Pentaho-Reporting High-Level-Architektur. ...............................................................39

Abbildung 8, Pentaho Reporting Architektur. ...................................................................................40

Abbildung 9, JasperReports High-Level-Architektur. ......................................................................42

Abbildung 10, Jasper-Reporting-Engine. ...........................................................................................43

Abbildung 11, BIRT High-Level Architektur. ...................................................................................46

Abbildung 12, BIRT Komponenten als Plug-ins für die Eclipse-Platform ........................................48

Abbildung 13, BIRT Report Designer: Beziehung zwischen Standard- und Spezialkomponenten. .49

Abbildung 14, BIRT Report Viewer: Beziehung zwischen Standard- und Spezialkomponenten. ....50

Abbildung 21, Designer-Oberfläche Birt. ......................................................................................... 115

Abbildung 22, Designer-Oberfläche Pentaho Report Designer. ...................................................... 115

Abbildung 23, Designer-Oberläche IReport. .................................................................................... 116

S e i t e 6

Tabellenverzeichnis

Tabelle 1, Umrechnung für die Endbewertung in der Kategorie Functionality ................................25

Tabelle 2, Metriken aus der Kategorie Usability. ..............................................................................26

Tabelle 3, Metriken aus der Kategorie Quality. .................................................................................28

Tabelle 4, Metriken aus der Kategorie Security.................................................................................29

Tabelle 5, Metriken aus der Kategorie Performance. ........................................................................29

Tabelle 6, Metriken aus der Kategorie Scalability. ............................................................................30

Tabelle 7, Metriken aus der Kategorie Architecture. ........................................................................31

Tabelle 8, Metriken aus der Kategorie Support. ................................................................................31

Tabelle 9, Metriken aus der Kategorie Documentation. ....................................................................32

Tabelle 10, Metriken aus der Kategorie Adoption. ............................................................................33

Tabelle 11, Metriken aus der Kategorie Community. ........................................................................34

Tabelle 12, Metriken aus der Kategorie Professionalism. ..................................................................34

Tabelle 13, Übersicht: Testberichte ....................................................................................................36

Tabelle 14, Übersicht von Open Source BI-Lösungen .......................................................................38

Tabelle 15, Kategorien mit Gewichtungen .........................................................................................53

Tabelle 16, Übersicht: Gewichtungen von Funktionalitäten. .............................................................57

Tabelle 17, Übersicht: Gewichtungen von Metriken unter Kategorie Usability. ..............................60

Tabelle 18, Übersicht: Gewichtungen von Metriken unter Kategorie Documentation. ....................60

Tabelle 19, Übersicht: Gewichtungen von Metriken unter Kategorie Quality. .................................61

Tabelle 20, Übersicht: Gewichtungen von Metriken unter Kategorie Architecture. ........................61

Tabelle 21, Übersicht: Gewichtungen von Metriken unter Kategorie Scalability. ............................62

Tabelle 22, Übersicht: Gewichtungen von Metriken unter Kategorie Community. ..........................62

Tabelle 23, Bewertungstabelle für die Kategorie Functionality. ........................................................65

Tabelle 24, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Usability. ................66

Tabelle 25, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Documentation. .....67

Tabelle 26, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Quality. ..................68

Tabelle 27, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Architecture. .........69

Tabelle 28, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Scalability. .............70

Tabelle 29, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Community. ...........71

Tabelle 30, Übersicht: Ergebnisse der BRR-Bewertung. ...................................................................72

Tabelle 31, Metriken zum Bewerten von der Benutzeroberfläche. ....................................................73

Tabelle 32, Bewertung der Metrik Z1. ...............................................................................................74



T a b e l l e n v e r z e i c h n i s S e i t e 7






Tabelle 40, Bewertung der Metrik Z10. .............................................................................................77



Tabelle 43, Übersicht: Ergebnisse der Zusatzbewertung. ..................................................................79

Tabelle 44, Übersicht der Test-Systeme. ............................................................................................80

Tabelle 45, Performance und Speicherauslastung von JasperReports. .............................................81

Tabelle 46, Performance und Speicherauslastung von BIRT. ...........................................................82

Tabelle 47, Performance und Speicherauslastung von Pentaho Reporting. ......................................84

Tabelle 48, Gegenüberstellung von Performanceergebnissen. ...........................................................85

Tabelle 49, Gegenüberstellung von Speicherauslastungsergebnissen. ...............................................87

Tabelle 50, durchschnittliche Performance nach Formaten. .............................................................87

Tabelle 51, durchschnittliche Speicherauslastung nach Formaten. ...................................................87

Tabelle 52, Entscheidungsmatrix. ......................................................................................................88

S e i t e 8

Listingverzeichnis

Listing 1, Quellcode der Klasse BenchmarkRunner. .........................................................................99

Listing 2, Quellcode der Klasse ReportEngineFactory. .....................................................................99

Listing 3, Quellcode der Klasse AReportingEngine. ........................................................................ 103

Listing 4, Quellcode der Klasse ReportingEngineBirt. .................................................................... 105

Listing 5, Quellcode der Klasse ReportingEngineJasperReports. ................................................... 107

Listing 6, Quellcode der Klasse ReportingEnginePentaho. ............................................................. 114

S e i t e 9

Abkürzungs- und Symbolverzeichnis

BI Business Intelligence

CSV Comma Separated Values

DOC Dateiendung der Dateien des Textverarbeitungsprogramms Microsoft

Word

ETL Extract, Transform, Load

HTML Hypertext Markup Language

J2EE Java 2 Enterprise Edition

JDBC Java Database Connectivity

MDX Multi-dimensional Expressions

ODA Open Data Access

ODT Open Document Text

OLAP On-Line Analytical Processing

PDF Portable Document Format

POJO Plain Old Java Object

PPT Dateiendung der Dateien des Präsentationsprogramms Microsoft

PowerPoint

RCP Rich Client Platform

ROM Report Object Model

RTF Rich Text Format

SVG Scalable Vector Graphics

TXT Abkürzung für Text

XMI XML Metadata Interchange

XML Extensible Markup Language

XMLA XML for Analysis

S e i t e 10

Glossar

Drill-Down: Mit Drill-Down wird eine Funktionalität bezeichnet, mit der der

Detailierungsgrad der vorhandenen Daten erhöht werden kann, um diese

in unterschiedlicher Detailtiefe zu betrachten.

Engine: In der Informationstechnologie wird mit Engine (von engl. Antrieb) ein

eigenständiger Teil eines Computerprogramms bezeichnet, der komplexe

Berechnungen oder Simulationen durchführt.

Framework: Ein Framework (engl. für „Rahmenwerk“) in der Softwaretechnik stellt

ein wiederverwendbares Architekturgerüst für einen

Anwendungsbereich (Domäne) dar und unterstütz das Zusammenspiel

von einzelnen Komponenten. Außerdem bietet ein Framework

Schnittstellen und Konfigurationsmöglichkeiten an, um dieses an die

Bedürfnisse und Anforderungen einer konkreten Anwendung

anzupassen.1

Platform: Mit Platform (engl. für „Plattform“) wird eine Softwarebasis bezeichnet,

auf der eine modul- oder plug-in-orientierte Anwendung aufgebaut

werden kann, z.B. Eclipse.

Rich-Client: Mit Rich-Client (engl. für „Reicher Klient“) werden in der Client-

Server-Architektur die Clients bezeichnet, die reichhaltige

Problemlösungen anbieten. Rich Client ist meistens ein Framework, der

durch Module und Plug-ins erweiterbar ist.

Sub-Reports: Sub-Reports (engl. für „Unter-Berichte“) sind Berichte, die in einen

Hauptbericht eingebunden werden. Die Unter-Berichte können

detailliertere Informationen oder Daten enthalten, die thematisch

verwandt sind.

1 Vgl. Griffel (1998).

S e i t e 11

1. Einleitung

Die ikom Unternehmensberatung GmbH entwickelt mit „smartidee.com“ eine

Softwarelösung für den Bereich Ideenmanagement. Diese Softwarelösung ist für den

Einsatz in Groß- und Mittelstandunternehmen konzipiert.

1.1. Problembeschreibung

Die Grundlage der Arbeit wurde durch folgende Feststellung umrissen:

1. Die angebotenen Reports2 in der Software sind fest definiert, und die Kunden

haben somit keine Möglichkeit zusätzliche Reports selbst zu definieren.

2. Es besteht zwar die Möglichkeit parametrisierte Reports zu erzeugen, aber die

Konfiguration hierfür ist zu komplex.

3. Die erzeugten Berichte stellen die Informationen nur als Tabelle dar, d.h. es

besteht keine Möglichkeit die Informationen in Diagrammen darzustellen.

4. Das Design der Berichte ist nicht an das Corporate-Design des jeweiligen

Unternehmens anpassbar.

5. Es besteht keine Möglichkeit Drill-Down-Reports zu erzeugen, somit sind die

Ergebnisse bei komplexen Kennzahlen nicht nachvollziehbar.

1.2. Zielsetzung

Zur Verbesserung des vorhandenen Reporting-Systems in der angebotenen

Softwarelösung soll eine Evaluierung von Reporting-Frameworks3 durchgeführt

werden. Das ausgewählte Framework wird später in die Anwendung integriert und

somit das alte Reporting-System ersetzen.

Die Anforderungen des Unternehmens an das Reporting-Framework sind:

1. Das Framework muss Open Source4 sein.

2. Das Framework muss die Erzeugung des Reports grafisch unterstützen.

3. Unterstützung von mehreren Datenquellen innerhalb eines Reports.

4. Das Framework muss die Konfiguration von Datenquellen unterstützen.

5. Der Bericht muss die Informationen in Tabellenform darstellen können.

6. Das Framework muss u.a. Säulen-, Kuchen-, Flächen- und Linien-Diagramme

unterstützen.

2 Die Begriffe Report und Bericht werden in dieser Arbeit synonym verwendet, sowie die Begriffe

Reporting und Berichtswesen.

3 Siehe hierzu Glossar.

4 Siehe hierzu Kapitel 2.5.

1 E i n l e i t u n g S e i t e 12

7. Das Framework muss kombinierte Diagramm-Arten unterstützen.

8. Das Framework muss eine kombinierte Darstellung von Tabellen und

Diagrammen unterstützen.

9. Das Framework muss parametrisierte Berichte unterstützen.

10. Das Framework muss Sortierung und Gruppierung von Daten unterstützen.

11. Das Framework muss Aggregation von Daten unterstützen.

12. Das Framework muss freidefinierbares Layout für die Berichte unterstützen.

13. Das Framework muss die Integration von Grafiken in einen Report unterstützen.

14. Das Framework muss den Report in HTML ausgeben können.

15. Das Framework muss den Report in PDF ausgeben können.

16. Das Framework muss den Report in MS Excel ausgeben können.

17. Das Framework muss den Report in MS Word ausgeben können.

18. Das Framework muss den Report in CSV ausgeben können.

1.3. Inhalt der Diplomarbeit

Die vorliegende Arbeit gibt einen Überblick über ausgewählte Reporting-Frameworks,

die nach unterschiedlichen Kriterien bewertet werden.

Da einige der Reporting-Frameworks Business Intelligence Funktionalitäten

beinhalten und in Business Intelligence Suiten eingesetzt werden, wird in Kapitel 2 ein

Überblick über Business Intelligence gegeben. Es wird eine idealtypische Architektur

zu Business Intelligence gezeigt. Darüberhinaus wird eine Einordnung vom

betrieblichen Berichtswesen in die Business Intelligence Architektur vorgenommen und

eine Klassifizierung von Berichten durchgeführt.

Anhand der Klassifizierung von Berichten in Kapitel 2 werden in Kapitel 3

Kriterienkatalog, Bewertungssystem und Testberichte beschrieben, die der

Durchführung der Evaluierung und der Bewertung der Reporting-Frameworks zugrunde

liegen.

Die Auswahl der Frameworks wird in Kapitel 4 getroffen. Die ausgewählten

Frameworks werden kurz vorgestellt. Es werden die Architektur und einige

Besonderheiten der Frameworks aufgezeigt.

Die Durchführung der Evaluierung wird in Kapitel 5 beschrieben. Es werden drei

ausgewählte Frameworks untersucht und deren Vor- und Nachteile beschrieben.

Darüberhinaus werden Performance- und Speicherauslastungstests durchgeführt. Die

gewonnenen Ergebnisse werden in einer Entscheidungsmatrix dargestellt.

1 E i n l e i t u n g S e i t e 13

Zum Abschluss der Diplomarbeit wird in Kapitel 6 eine Handlungsempfehlung

ausgesprochen und ein Ausblick hinsichtlich der getesteten Frameworks gegeben.

S e i t e 14

2. Business Intelligence und Reporting

2.1. Business Intelligence – theoretische Grundlagen

2.1.1. Begriffsdefinition

Am Anfang der 90er entstand der Begriff „Business Intelligence“, der durch die Gartner

Group geprägt wurde. Der Begriffsteil „Intelligence“ bedeutet in diesem

Zusammenhang nicht „Intelligenz“, sondern wird im Sinne von Verständnis, Einsicht,

Aufklärung und Suche interpretiert.5

Im früheren Stadium wurde die Bezeichnung „Business Intelligence“ als Oberbegriff

von Anbietern und Beratern für ihr Angebot an Softwarewerkzeugen für die

Managementunterstützung verwendet. Erst später konnte dieser Begriff aus der Praxis

in wissenschaftlichen Diskussionen etabliert werden. Deswegen gibt es keine eindeutige

wissenschaftliche Definition zu diesem Begriff.6 In der Fachliteratur wurden einige

Versuche unternommen eine Definition herzuleiten:

Grothe (2000):

„Business Intelligence (BI) bezeichnet den analytischen Prozess, der – fragmentierte –

Unternehmens- und Wettbewerbsdaten in handlungsgerichtetes Wissen über die

Fähigkeit, Positionen, Handlungen und Ziele der betrachteten internen oder externen

Handlungsfelder (Akteure und Prozesse) transformiert“.

Strauch u. Winter (2002):

„(…) Business Intelligence (kann) als Sammelbegriff für die aufgrund neuer

Integrationsmechanismen wie Data Warehouse und Applikationsintegration

konvergierenden, ursprünglich isolierten und nacheinander entwickelten Konzeptionen

„Management Information System“, „Decision Support System“ und „Executive

Information System“ interpretiert werden (…)“

Chamoni/Gluchowski (2004):

„Business-Intelligence (BI) kennzeichnet Systeme, die auf der Basis interner Kosten-

und Leistungsdaten sowie externer Marktdaten in der Lage sind, das Management in

seiner planenden, steuernden und koordinierenden Tätigkeit zu unterstützen“.

5 Vgl. Mertens (2002); Chamoni/Gluchowski (2004); Strauch/Winter (2002); Grothe (2000), S. 19;

Gluchowski/Gabriel/Dittmar (2008), S. 89.

6 Vgl. Kemper/Lee (2001); Gluchowski/Kemper (2006); Gluchowski/Gabriel/Dittmar (2008), S. 89;

Strauch/Winter (2002)

2 Business Intelligence und Reporting S e i t e 15

Dittmar/Schulze (2006):

„Eine Vielfalt unterschiedlichster Systeme zur Analyse und Auswertung von Daten mit

dem Ziel der Gewinnung nicht-trivialer Erkenntnisse zu den relevanten

Wirkungszusammenhängen in Unternehmen werden aktuell unter dem Sammelbegriff

Business Intelligence (BI) entwickelt und eingesetzt“

Gluchowski/Kemper (2006):

„Unter Business Intelligence (BI) wird ein integriertes IT-Gesamtkonzept verstanden,

das für die unterschiedlichen Ausprägungen der Anforderungen an geeignete Systeme

zur Entscheidungsunterstützung tragfähige und miteinander verknüpfte Lösungen

anbietet“.

Die zitierten Definitionen weichen voneinander ab. Dennoch besitzen sie eine

Gemeinsamkeit: Business Intelligence soll das Management bei der Entscheidung und

Analyse unterstützen.

Gluchowski verfolgt einen anderen Ansatz, indem er eine Annäherung an den

Begriff versucht durch Aufzeigen und Erörtern von Konzepten und Technologien, die er

in einem strukturierten Ordnungsrahmen darstellt (vgl. Abbildung 1). Die vertikale

Achse stellt die zentralen Phasen des analytischen Datenverarbeitungsprozesses dar. Die

horizontale Achse veranschaulicht die Perspektive sowie die zugehörige

Systemkategorie des jeweiligen Themas, das heute schwerpunktmäßig diskutiert wird.

Es lassen sich hierbei drei gängige Typen von Definitionsansätzen abgrenzen:

Enges BI-Begriffsverständnis

Zum engen Begriffsverständnis gehören Anwendungen und Produkte, die eine

Aufbereitung und Präsentation von organisierten Daten unterstützen. Diese verwenden

solche Techniken wie Slice und Dice oder Color Coding (farbliche Hervorhebung).

Herstellerspezifische Clientlösungen, Briefing-Books, Excel-Add-ins oder

Browsererweiterungen kommen hier als BI-Tools in Betracht. Front-End-Produkte, die

für Reporting-Anwendungen genutzt werden oder Data Mining ermöglichen, gehören

nicht zu diesem Segment. 7

Analyseorientiertes BI-Begriffsverständnis

Hierzu gehören analyseorientierte Konzepte und Anwendungen bzw. ihre

Komponenten, die eine modell- und methodenbasierte Analyse von vorhandenen Daten

ermöglichen. Zu den BI-Tools zählen On-Line Analytical Processing (OLAP)-

7 Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 90; Gluchowski (2001), S. 7.


Werkzeuge, Data Mining-Produkte und Generatoren zur Erstellung von Ad-Hoc-

Berichten sowie darauf basierenden Anwendungen.8

Weites BI-Begriffsverständnis

Dazu werden alle Systemkomponenten gezählt, die operatives Datenmaterial zur

Informations- und Wissensgenerierung aufbereiten und speichern sowie Auswertungs-

und Präsentationsfunktionalitäten anbieten. 9

Abbildung 1, unterschiedliche Facetten und Abgrenzungen von Business Intelligence.10

Durch diese Annäherung leitet Gluchowski eine treffendere Definition von Business

Intelligence her:

„Zusammenfassend lässt sich Business Intelligence damit (zumindest nach dem weiten

BI-Begriffsverständnis (…)) als begriffliche Klammer verstehen, die unterschiedliche

Technologien und Konzepte im Umfeld der entscheidungsunterstützenden Systeme

zusammenführt und dabei eine entscheidungsorientierte Sammlung und Aufbereitung

von Daten über das Unternehmen und dessen Umwelt sowie deren Darstellung in Form

von geschäftsrelevanten Informationen für Analyse-, Planungs- und Steuerungszwecke

zum Gegenstand hat.

Im Einzelnen handelt es sich hierbei um Komponenten zur Extraktion, Bereinigung,

Transformation, Integration, Speicherung und entscheidungsorientierten Aufbereitung

8 Vgl. Gluchowski/Gabriel/Dittmar (2008),S. 90; Gluchowski (2001), S. 7.


10 Übernommen aus Gluchowski/Gabriel/Dittmar (2008), S. 92 in Anlehnung an Gluchowski (2001), S. 7.


relevanter Informationen sowie um die Bausteine zur Präsentation und Analyse dieser

Inhalte.“11

2.1.2. Architektur

Die idealtypische Architektur von BI-Systemen lässt sich in drei Schichten aufteilen:

Datenbereitstellung, Analyse (Datenauswertung) und Präsentation (vgl. Abbildung 2).

Zugriff und Ausgabe

Untersuchung und Auswertung

(Analysesysteme)

-Operative Vorsysteme

-Externe Daten

Speicherung (Data Warehouse)

Aufbereitung (ETL-Systeme)

Präsentations-

schicht

Daten-

bereitstellungs-

schicht

Analyse-

schicht

Abbildung 2, BI-Schichtenmodell.12

Die Basis von BI-Architekturen bildet die Datenbereitstellungsschicht. Diese Schicht

stellt die Daten zur Verfügung, die in den darauf aufbauenden Schichten verwendet

werden. Die Datenbereitstellung wird in zwei weitere Unterschichten aufgeteilt:

Speicherungs- und Aufbereitungsschicht. In der Aufbereitungsschicht werden die Daten

aus unterschiedlichen Quellen extrahiert, transformiert und anschließend an die

Speicherungsschicht weitergegeben, wo die Daten abgelegt werden. Die

Speicherungsschicht wird durch den Einsatz von Datenbanken realisiert, die eine

analytische Orientierung aufweisen. Solche Datenbanklösungen werden als Data

11

Gluchowski/Gabriel/Dittmar (2008), S. 93.

12 Abgeändert übernommen aus Gluchowski/Gabriel/Dittmar (2008), S. 109, vgl. u.a.

Kemper/Mehanna/Unger (2006), S. 10.


Warehouse13

bezeichnet. In der Analyseschicht werden die Daten aus der

Bereitstellungschicht nach verschiedenen Kriterien untersucht und ausgewertet. Die

Präsentationsschicht ist für die Darstellung der abgerufenen Informationen durch den

Endbenutzer zuständig. Die einzelnen Werkzeuge lassen sich nicht immer trennscharf

der Analyse- oder Präsentationsschicht zuordnen. Die Werkzeuge aus der

Analyseschicht verfügen auch über Präsentationsmöglichkeiten, wobei aber der

Schwerpunkt auf den Analysetechniken liegt. Sowie die Werkzeuge aus der

Präsentationsschicht über rudimentäre Analysetechniken (z.B. Summation) verfügen

können, der Schwerpunkt hier aber auf der Präsentation liegt.14

Als Beispiel lassen sich die Reporting-Werkzeuge in die Präsentationsschicht

einordnen. Die Reporting-Werkzeuge sind sehr auf die Darstellung der Informationen

ausgelegt. Dabei wird ein sehr großer Wert auf die Gestaltungsmöglichkeiten der

Berichte gelegt. Die Gestaltungsoptionen in heutigen Reporting-Anwendungen reichen

von statischem Text über Kopf- und Fußzeilen bis hin zu freiplatzierbaren und –

formatierbaren Tabellenfeldern sowie grafischen Objekten.15

2.2. Einordnung des Berichtswesens

Unter dem Begriff des betrieblichen Berichtswesens wird die Erzeugung und

Bereitstellung der Berichte zusammengefasst. Dazu gehören auch alle Personen,

Organisationseinheiten, Vorschriften, Daten und Prozesse, die an der Erzeugung und

Bereitstellung beteiligt sind. Wobei man unter dem Begriff „Berichte“ Dokumente

versteht, die unterschiedliche Informationen in aufbereiteter und kombinierter Form

enthalten.16

Die Abbildung 3 zeigt aus welchen Prozessen das betriebliche Berichtswesen sich

zusammensetzt. Diese Prozesse werden in unterschiedlicher Art und Weise von den BI-

Werkzeugen und Technologien (Data Warehouse, Reporting- und Analyse-Systeme)

unterstütz.17

13

Die Data Warehouse-, OLAP- und ETL-Konzepte werden in dieser Arbeit nicht näher erläutert, diese

werden in folgender Fachliteratur beschrieben: Chamoni (2003); Chamoni/Gluchowski (2006);

Gluchowski/Chamoni (2006); Gluchowski/Kemper (2006); Grothe (2000); Kemper/Mehanna/Unger

(2006); Mertens (2002); Mucksch (2006); Schelp (2006); Gluchowski/Gabriel/Dittmar (2008);

Strauch/Winter (2002); Kemper/Lee (2001); Gluchowski (2001).

14 Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 108; Kemper/Mehanna/Unger (2006), S. 10;

Gluchowski/Kemper (2006).

15 Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 205, 212; Heine/Wende (2004), S. 340 ff.

16 Vgl. Kemper/Mehanna/Unger (2006), S. 110; Gluchowski (2006), S. 208.

17 Kemper/Mehanna/Unger (2006), S. 110; Gluchowski (2006), S. 209; Heine/Wende (2004), S. 331 ff.


Berichtsgestaltung und -erstellung

Berichtsverwaltung

Berichtsverteilung

Berichtsaufnahme und -diskussion

Abbildung 3, Prozesse des betrieblichen Berichtswesens.18

Bei dem Prozess „Berichtsgestaltung“ werden Layout und Platzhalter für die Daten

in einem Bericht definiert. Sie werden bei Berichtserstellung mit Daten ausgefüllt. Der

fertige Bericht wird an die Empfänger verteilt. Wobei der Bericht für spätere Nutzung in

der Berichtsverwaltung aufgenommen wird. Somit kann der Empfänger die

Informationen aus dem Bericht direkt aufnehmen oder später abrufen.

2.3. Berichtsgestaltung

Die Berichte lassen sich nach bestimmten Kriterien kennzeichnen und einordnen. Dazu

gehören die Kriterienklassen wie Zweck, Inhalt, Form, Zeit sowie die Instanz.

Der Berichtszweck hat die zentrale Bedeutung bei der Gestaltung der Berichte. Ist

der Zweck des Berichtes nicht bestimmbar, so kann seine Existenzberechtigung in

Frage gestellt werden.

Die enthaltenen Sachverhalte der Realität werden mit dem Berichtsinhalt

klassifiziert. Die Einteilung kann hier entlang der einzelnen Funktionalbereiche oder

vergleichbarer thematischer Kriterien erfolgen. Für die Nützlichkeit eines Berichts ist

die geeignete Detaillierung der vorliegenden Informationen wichtig. Das

Informationsspektrum sollte dabei angemessen breit ausgelegt werden. Bei den

dargebotenen Informationen sollte man drauf achten, dass diese möglicherweise

ungenaue Angaben haben können.19

18

Modifiziert übernommen aus Kemper/Mehanna/Unger (2006), S. 110.



Abbildung 4, Merkmale zur Kennzeichnung und Gestaltung von Berichten.20

Die Berichte unterscheiden sich durch Informationen, die in unterschiedlicher Weise

dargestellt werden können. Die Informationen lassen sich in grafischer und textlicher

Berichtsform einzeln oder gemischt darstellen. Bei der grafischen Darstellung werden

Geschäftsgrafiken wie Kreis-, Balken- oder Säulendiagramme verwendet. Zu der

textlichen Form gehören die tabellarische Präsentationsform von Informationen, sowie

auch ausformulierte Langtexte. Wegen der Übersichtlichkeit und Verständlichkeit

sollten die Berichtsobjekte strukturiert angeordnet werden. Dies wird üblicherweise mit

den Adressaten abgestimmt, um ein einheitliches Aufbau zu erreichen. Bei der Wahl des

Präsentationsmediums kann die Unterscheidung zwischen elektronischer und

papiergebundener Ausgabeform vorgenommen werden. Von dieser Unterscheidung ist

auch der Übertragungsweg abhängig.21

Wenn die Berichte in bestimmten Berichtsintervallen erzeugen werden, so spielt hier

der zeitliche Gesichtspunkt eine Rolle. Werden die Berichte in regelmäßigen Intervallen

erzeugt, so handelt es sich um periodische Berichte. Solche Berichte beziehen sich

zumeist auf abgelaufene Perioden. Berichte, die in unregelmäßigen Intervallen erzeugt

werden, werden als aperiodische Berichte bezeichnet. Diese Berichte werden bei einer

20

Gluchowski/Gabriel/Dittmar (2008), S. 208; Gluchowski (2006), S. 210.



bestimmten Abweichung in den Sollwerten erstellt. Solche Berichte lassen sich für die

Früherkennung bzw. Frühwarnung nutzen, da diese auf kurzfristige Ereignisse

hinweisen und mit einem dringenden Handlungsbedarf verknüpft sind.22

Aufbau und Inhalt des Berichtes hängen von den Anforderungen des Empfängers

bzw. der Empfängergruppen ab, dabei sollte der genaue Informationsbedarf erhoben

werden, um die Berichte an die Bedürfnisse der Verwender auszurichten. Wichtig ist

auch zu klären, welche Mitarbeiter für die zeitgerechte Anfertigung der Berichte

verantwortlich sind. Hierbei kann zwischen der inhaltlichen und technischen

Verantwortung unterschieden werden.23

2.4. Open Source

Open Source ist aus dem unternehmerischen Umfeld nicht mehr wegzudenken. In den

letzten Jahren ist der Marktanteil von Open Source kontinuierlich gestiegen. Dies ergab

eine Studie der Europäischen Kommission24

.

Die offizielle Definition von Open Source lautet: „Open source doesn't just mean

access to the source code. The distribution terms of open-source software must comply

with the following criteria“25

. Das bedeutet, dass nicht nur die Verfügbarkeit des

Quelltextes, sondern auch die Lizenzbestimmungen für die Weitergabe wichtig sind,

unter denen eine Software als Open Source Software vertrieben oder angeboten werden

darf. Die Lizenzbestimmungen müssen den charakteristischen Merkmalen der Open

Source Definition (OSD) entsprechen.26

22

Vgl. Gluchowski/Gabriel/Dittmar (2008), S. 209; Gluchowski (2006), S. 211.


24 MERIT (2006)

25 Open Source Definition (2008)

26 Open Source Definition (2008)

S e i t e 22

3. Vorbereitung der Evaluierung

3.1. Evaluierungs-Model

Um ein methodisches Vorgehen zu gewährleisten, wurde für die Evaluierung das

Business Readiness Rating Model (BRR)27

zur Bewertung von Open Source Software

verwendet28

. Dieses Model wurde von Carnegie Mellon West Center for Open Source

Investigation, O'Reilly CodeZoo, SpikeSource und Intel Corporation entwickelt. Das

Model ist in 4 Phasen gegliedert (Abbildung 5).

Abbildung 5, 4 Phasen des BRR-Models.

Phase 1 – Quick assessment:

In dieser Phase werden die Komponenten ausgewählt, die evaluiert werden sollen. Nach

der Auswahl werden KO-Kriterien für die Vorbewertung (engl. „quick assessment“)

definiert, die auf die ausgewählten Komponenten angewendet werden. Zum Schluss der

Phase werden die Komponenten aussortiert, die nicht die Kriterien erfüllen.

Phase 2 – Target usage assessment:

In dieser Phase werden die Gewichtungen für die Kategorien und Metriken bestimmt. In

dem Model gibt es zwölf Kategorien: Functionality, Usability, Quality, Security,

27

BRR (2005)

28 Anhand der Evaluierung in Deprez/Alexandre (2008).

3 Vorbereitung der Evaluierung S e i t e 23

Performance, Scalability, Architecture, Support, Documentation, Adoption, Community

und Professionalism. (Die einzelnen Kategorien werden in einem späteren Kapitel näher

erläutert.) Bei der Bestimmung werden zunächst die einzelnen Kategorien nach

Wichtigkeit sortiert. Dazu wird eine Zahl von 1 bis 12 zugewiesen. Dabei steht die 1 für

sehr wichtig bis 12 nicht wichtig. Danach werden die Top 7 Kategorien (oder weniger)

ausgewählt und diesen Kategorien die Gewichtung in Prozent zugewiesen. Die

Gewichtungen müssen in der Summe 100% ergeben.

In jeder Kategorie befinden sich eine oder mehrere Metriken, die mit Gewichtungen

versehen werden. Als Metrik wird in diesem Zusammenhang ein Kriterium verstanden,

welches zur Bewertung herangezogen wird. Die Summe der Gewichtungen für die

Metriken in einer Kategorie muss 100% ergeben. Es besteht die Möglichkeit, die nicht

benötigten Metriken mit 0% zu gewichten.

Phase 3 – Data collection and processing:

Für die ausgewählten Anwendungen werden Daten gesammelt. Die gesammelten Daten

werden auf die einzelnen Metriken in ausgewählten Kategorien angewendet. Jede

Metrik besitzt eine Bewertung von 1 bis 5, dabei ist 1 die schlechteste Note und 5 die

beste. Nach der Notenvergabe werden die gewichteten Werte für die einzelnen Metriken

berechnet.

Phase 4 –Data translation:

In dieser Phase werden die gewichteten Werte der einzelnen Kategorien aus den

gewichteten Werten der Metriken berechnet. Abschließend wird aus den gewichteten

Werten der Kategorien die BRR-Punktezahl berechnet.

3.2. Kriterienkatalog

3.2.1. Kriterien für Vorbewertung

Für die Vorbewertung (engl. „quick assessment“) wurden folgende KO-Kriterien

ermittelt:

1. Nach dem ersten Release ist mehr als ein Jahr vergangen.

2. Release-Zyklus liegt unter sechs Monaten.

3. Projekt wurde in der Programmiersprache Java entwickelt.

4. Projekt besitzt eigene Reporting-Engine.


3.2.2. Kriterien für Hauptbewertung29

3.2.2.1. Functionality-Kategorie

In dieser Kategorie werden diejenigen Funktionalitäten der Anwendung ausgewählt und

bewertet, die den Anforderungen der Anwender entsprechen. Dabei werden die

Funktionalitäten in zwei Arten unterteilt: Standardfunktionalitäten und

Zusatzfunktionalitäten. Alle Funktionalitäten werden mit einer Gewichtung von 1 bis 3

versehen, dabei steht 1 für weniger Wichtig und 3 für sehr Wichtig.

Bei der Bewertung der Standardfunktionalitäten bekommt die Funktionalität einen

positiven Gewichtungswert als Bewertung, wenn sie von der Anwendung unterstützt

wird. Wird die Funktionalität hingegen nicht unterstütz, so wird eine negative

Gewichtung als Bewertung abgegeben. Beispielsweise hat eine bestimmte

Funktionalität die Gewichtung 3, wird diese von Software A unterstützt, so bekommt

diese Software als Bewertung eine 3. Die Software B unterstützt diese Funktionalität

nicht, deswegen wird als Bewertung eine -3 vergeben.

Die Zusatzfunktionalitäten werden etwas anders bewertet. Ist eine Funktionalität

vorhanden, bekommt diese die gleiche Bewertung wie die Gewichtung. Wird die

Funktionalität nicht unterstützt, wird als Bewertung eine 0 vergeben. Beispielsweise hat

eine bestimmte Funktionalität die Gewichtung 2. Die Software A unterstützt diese

Funktionalität, deswegen bekommt diese Software die Bewertung 2. Die Software B

unterstützt diese Funktionalität nicht, deswegen wird bei dieser Software als Bewertung

0 eingetragen.

Bei der Endbewertung in dieser Kategorie wird die Summe der Bewertung aller

Funktionalitäten durch die Summe der Gewichtungen der Standardfunktionalitäten

dividiert und mit 100 multipliziert, um die Bewertung in Prozent zu erhalten.

A=

B=

C=

Der Prozentwert wird in eine Bewertung von 1 bis 5 umgerechnet, dazu wird folgende

Zuweisung verwendet:

29

Vgl. BRR (2005).


Prozentgrenzwerte Bewertung

Mangelhaft 0% 1

Ausreichend 65% 2

Befriedigend 80% 3

Gut 90% 4

Sehr gut 96% 5

Tabelle 1, Umrechnung für die Endbewertung in der Kategorie Functionality

Vorteil bei dieser Bewertung ist, dass eine Anwendung nicht bestraft wird, weil diese

nicht alle oder nur wenige Standardfunktionalitäten unterstützt, dafür aber viele

Zusatzfunktionalitäten anbietet.

3.2.2.2. Usability-Kategorie

In der Usability-Kategorie wird die Benutzerfreundlichkeit der Software bewertet.

Dabei wird geprüft, ob die Benutzeroberfläche einfach für den Endbenutzer zu

verwenden ist. Außerdem wird die Zeit, die benötigt wird, um die Software zu

installieren und zu konfigurieren, gemessen und bewertet.

Metrik: Endbenutzer UI-Erfahrung

Beschreibung: Hier wird gemessen, wie gut die UI durch den Endbenutzer akzeptiert wird.

Es werden die Navigation, die intuitive Bedienbarkeit des Interfaces und

das Steuerungssystem bewertet.

Bewertung: 5 - Einfach und Intuitiv, die Informationen sind gut organisiert, das

Handbuch wird nicht benötigt.

3 - Benötigt ein wenig Einarbeitungszeit, die Informationen sind etwas

organisiert, das Handbuch wird benötigt.

1 - Komplex, zu viele Informationen, keine offensichtliche

Organisation, kann ohne Handbuch nicht verwendet werden.

Metrik: Zeit für Installation der erforderlichen Software, die die Open-

Source-Software voraussetzt.

Beschreibung: Mit dieser Metrik wird gemessen, wie viel Zeit/Anstrengung man benötigt,

um die erforderliche Software zu installieren, die zum Installieren und

Ausführen von der Open-Source-Software benötigt wird. Die Messung

beinhaltet nicht das Einspielen des Betriebssystems.

Bewertung: 5 - < 10 Minuten


4 - 10 - 30 Minuten

3 - 30 min - 1 Stunde

2 - 1 - 4 Stunden

1 - > 4 Stunden

Metrik: Zeit für die Installation und Konfiguration von der Software.

Beschreibung: Hier wird gemessen, wie viel Zeit man für die Installation und

Konfiguration benötigt, damit die Software so schnell wie möglich

lauffähig ist.

Bewertung: 5 - < 10 Minuten

4 - 10 - 30 Minuten

3 - 30 min - 1 Stunde

2 - 1 - 4 Stunden

1 - > 4 Stunden

Tabelle 2, Metriken aus der Kategorie Usability.

3.2.2.3. Quality-Kategorie

Bei dieser Kategorie wird die Qualität der Software gemessen. Dazu werden mehrere

Metriken angewendet, die die Code- und Design-Qualität bewerten. Außerdem wird

bewertet, wie vollständig und fehlerfrei die Software ist.

Metrik: Anzahl der Minor Releases in den letzten 12 Monaten.

Beschreibung: Diese Metrik misst die geplanten Updates und Fehlerkorrekturen. Typische

Minor Releases sind Services Packs in den kommerziellen Produkten.

Bewertung: 5 - 2 Releases

3 - 1 oder 3 Releases

1 - 0 oder >3 Releases

Metrik: Anzahl der Point/Patch Releases in den letzten 12 Monaten.

Beschreibung: Typische, offizielle Poin/Patch Releases beinhalten Korrekturen für P1

Fehler, wie Deadlock-, Speicher- und Sicherheitsschwachstellen.

Bewertung: 5 - 3 – 4 Releases

3 - 1 – 2 oder 5 – 6 Releases


1 - 0 oder > 6 Releases

Metrik: Anzahl der offenen Fehler in den letzten 6 Monaten.

Beschreibung: In dieser Metrik wird die Qualität der Produkt-Nutzung gemessen.

Bewertung: 5 - < 50 Fehler

4 - 50 - 100 Fehler

3 - 100 – 500 Fehler

2 - 500 – 1000 Fehler

1 - > 1000 Fehler

Metrik: Anzahl der behobenen Fehler in den letzten 6 Monaten

Beschreibung: Mit dieser Metrik wird gemessen, wie schnell die Fehler behoben werden

im Vergleich zu den geöffneten Fehlern.

Bewertung: 5 - > 75%

4 - 60% - 75%

3 - 45% - 60%

2 - 25% - 45%

1 - < 25%

Metrik: Anzahl der geöffneten P1/kritischen Fehler.

Beschreibung: Diese Metrik misst die Schwere der gefundenen Qualitätsmängel.

Bewertung: 5 - 0 Fehler

4 - 1 - 5 Fehler

3 - 5 – 10 Fehler

2 - 10 – 20 Fehler

1 - > 20 Fehler

Metrik: Durchschnittliches Alter eines P1 Fehlers in den letzten 6

Monaten

Beschreibung: Wie lange das Team braucht, um einen kritischen Fehler zu beheben, wird

mit dieser Metrik gemessen.

Bewertung: 5 - < 1 Woche


4 - 1 - 2 Wochen

3 - 2 - 3 Wochen

2 - 3 - 4 Wochen

1 - > 4 Wochen

Tabelle 3, Metriken aus der Kategorie Quality.

3.2.2.4. Security-Kategorie

Die Security-Kategorie befasst sich mit der Sicherheit der Software. Hier werden

Metriken verwendet, um die Sicherheit der Software zu bestimmen und den Umgang

mit den Sicherheitsproblemen der Projekte zu bewerten.

Metrik: Anzahl der Sicherheitslücken in den letzten 6 Monaten, die als

extrem kritisch eingestuft wurden.

Beschreibung: Diese Metrik misst die Qualität bezogen auf die Sicherheitslücken. Wie

anfällig ist die Software für die Sicherheitslücken?

Bewertung: 5 - 0 Sicherheitslücken

4 - 1 – 2 Sicherheitslücken



1 - > 6 Sicherheitslücken

Metrik: Anzahl der Sicherheitslücken, die noch offen sind (ungepatcht).

Beschreibung: Hier wird gemessen, ob das Projekt in der Lage ist die Sicherheitsmängel

zu beseitigen.

Bewertung: 5 - 0 Sicherheitslücken

4 - 1 Sicherheitslücken

3 - 2 Sicherheitslücken


1 - > 5 Sicherheitslücken

Metrik: Gibt es bestimmte Informationen (Webseite, Wiki, etc.) für die

Sicherheit?

Beschreibung: Diese Metrik misst, ob die Sicherheitsprobleme bewusst und ernst von dem


Projekt-Team wahrgenommen werden.

Bewertung: 5 - Ja, sehr gut gepflegt

3 - Ja

1 - Nein

Tabelle 4, Metriken aus der Kategorie Security.

3.2.2.5. Performance-Kategorie

Wie die Bezeichnung der Kategorie schon sagt, werden in dieser die Geschwindigkeit

und die Optimierungsmöglichkeiten der Software bewertet.

Metrik: Performance Tests und Benchmark-Berichte vorhanden.

Beschreibung: Diese Metrik misst, ob Performance Tests und Benchmarks veröffentlicht

wurden, die diese Software mit anderer äquivalenter Software vergleichen.

Bewertung: 5 - Ja, mit sehr guten Ergebnissen

3 - Ja

1 - Nein

Metrik: Performance Tuning und Konfiguration

Beschreibung: Hier wird ermittelt, ob Dokumentationen oder Tools gibt, um die

Performance der Komponenten zu optimieren(Informationen über CPU,

Festplatte, Netzwerk).

Bewertung: 5 - Ja, sehr umfangreiche

3 - Ja, einige

1 - Nein

Tabelle 5, Metriken aus der Kategorie Performance.

3.2.2.6. Scalability-Kategorie

In dieser Kategorie wird die Skalierbarkeit der Software bewertet.

Metrik: Referenz-Deployment

Beschreibung: Diese Metrik misst, ob die Software in der Praxis getestet und skaliert

wurde.

Bewertung: 5 - Ja, mit veröffentlichten Benutzeranzahl

3 - Ja


1 - Nein

Metrik: Konzipiert für Skalierbarkeit

Beschreibung: Hier wird gemessen, ob die Komponente hinsichtlich der Skalierbarkeit

konzipiert wurde. Ist es Thread-Sicher? Läuft es in einer Cluster-

Umgebung? Kann die Hardware die Performance-Probleme lösen?

Bewertung: 5 - Ja, umfangreich

3 - Ja, etwas

1 - Nein

Tabelle 6, Metriken aus der Kategorie Scalability.

3.2.2.7. Architecture-Kategorie

Diese Kategorie bewertet die Architektur der Software. Es werden unter anderem die

Modularität, Portierbarkeit, Flexibilität, Erweiterbarkeit und Integration der Software

bewertet.

Metrik: Gibt es irgendwelche Drittanbieter Plug-ins?

Beschreibung: Diese Metrik misst die Konzeption für die Erweiterbarkeit durch die

Drittanbieter Plug-ins.

Bewertung: 5 - >10 Plug-ins

4 - 6 bis 10 Plug-ins

3 - 2 bis 5 Plug-ins

2 - 1 Plug-in

1 - 0 Plug-ins

Metrik: Öffentliche API/ externe Dienste

Beschreibung: Hier wird gemessen, ob es möglich ist die Erweiterung über eine

öffentliche API durchzuführen, und ob die Software für die Anpassung

entworfen wurde.

Bewertung: 5 - Ja, umfangreich

3 - Ja

1 - Nein

Metrik: Ein- und Ausschalten von Funktionen durch Konfiguration


Beschreibung: Hier wird gemessen, ob ein Benutzer die Funktionalitäten durch die

Konfiguration ein- und ausschalten kann.

Bewertung: 5 - Ja, während der Laufzeit

3 - Ja, während der Kompilierung

1 - Nein

Tabelle 7, Metriken aus der Kategorie Architecture.

3.2.2.8. Support-Kategorie

In dieser Kategorie wird der Support der Firmen oder der Community bewertet, die

hinter dieser Software stehen.

Metrik: Durchschnittliches Volumen der Hauptmailinglist in den letzten

6 Monaten.

Beschreibung: Die Hauptmailinglist ist der erste Anlaufpunkt für Benutzer, die kostenlose

Hilfe benötigen.

Bewertung: 5 - > 720 Nachrichten pro Monat

4 - [300 – 720) Nachrichten pro Monat



1 - < 30 Nachrichten pro Monat

Metrik: Qualität von dem professionellen Support.

Beschreibung: Professioneller Support, der bei der Optimierung der lokalen Installation

und Problemen hilft.

Bewertung: 5 - Installation-, Problemlösung-, Integration-/Anpassung-

Support

3 - Nur Installationssupport

1 - Kein professioneller Support

Tabelle 8, Metriken aus der Kategorie Support.

3.2.2.9. Documentation-Kategorie

Die Qualität der Dokumentation, die die Firma oder die Community zu dieser Software

anbieten, wird in dieser Kategorie bewertet.


Metrik: Vorhandensein von verschiedenen Dokumenten.

Beschreibung: Eine gute Dokumentation sollte Dokumente für jede Nutzerschicht

enthalten.

Bewertung: 5 - Installations-/Veröffentlichungs-, Benutzer-, Administrations-,

Optimierungs(Tuning)-, Aktualisierungs- und Entwickleranleitung

sind in mehreren Formaten verfügbar (HTML Einzeldatei, HTML

mehrere Dateien, PDF).

4 - Installations-/ Veröffentlichungs-, Benutzer-, Administrations- und

Aktualisierungsdokumentation sind in mehreren Formaten

verfügbar.

3 - Installations-/ Veröffentlichungs- und Benutzeranleitung ist

verfügbar

2 - Nur ein textbasiertes Installationsdokument existiert.

1 - Keine echten Dokumente. Eine Readme-Datei wird nicht beachtet.

Metrik: Framework für Benutzerbeiträge

Beschreibung: Die besten Anleitungen werden von den Benutzern erstellt. Dies ist ein

Feedback von den Benutzern, die das Produkt verwenden. Hier wird

überprüft, ob es eine Möglichkeit besteht die Anleitung auf der Webseite

des Projekts zu veröffentlichen und ob die veröffentlichte Anleitung von

den Projektmitgliedern überprüft wird.

Bewertung: 5 - Die Benutzer dürfen eigene Beiträge veröffentlichen und diese

werden von den Experten kontrolliert.

3 - Die Benutzer dürfen eigene Beiträge veröffentlichen

1 - Die Benutzer dürfen keine Beiträge veröffentlichen

Tabelle 9, Metriken aus der Kategorie Documentation.

3.2.2.10. Adoption-Kategorie

Diese Kategorie bewertet den Einsatz der Software, durch die Community, Markt und

die Industrie.

Metrik: Wie viele Bücher gibt Amazon.com bei der Suche aus?

Beschreibung: Die Verfügbarkeit von den Büchern zeigt, wie gut das Projekt

angenommen wurde. Für die Messung wird von Amazon.com die


„Advanced Search“ mit folgenden Suchkriterien verwendet:

subject:computer und title:Komponentenname.

Bewertung: 5 - >=15 Bücher

4 - [6 – 15) Bücher

3 - [3 – 6) Bücher

2 - [1 – 3) Bücher

1 - 0 Bücher

Metrik: Referenz-Deployment

Beschreibung: Diese Metrik misst, ob die Software in der Praxis getestet und skaliert

wurde durch einen praktischen Einsatz.

Bewertung: 5 - Ja, mit veröffentlichten Benutzeranzahl

3 - Ja

1 - Nein

Tabelle 10, Metriken aus der Kategorie Adoption.

3.2.2.11. Community-Kategorie

Die Aktivität und die Lebhaftigkeit der Community, die hinter der Software steht,

werden in dieser Kategorie bewertet.

Metrik: Durchschnittliches Volumen einer Hauptmailinglist in den

letzten 6 Monaten.

Beschreibung: Die Hauptmailinglist ist der Platz, wo die Community-Mitglieder einander

helfen.

Bewertung: 5 - > 720 Nachrichten pro Monat




1 - < 30 Nachrichten pro Monat

Metrik: Anzahl von eindeutigen Quellcode-Beitragenden in den letzten 6

Monaten.

Beschreibung: Normalerweise fördern die Quellcode-Beitragenden den Community-

Aufbau rund um das Projekt. Je mehr Quellcode-Beitragenden, desto besser


ist der Community-Support.

Bewertung: 5 - >= 50 Beitragenden

4 - [20 – 50) Beitragenden



1 - <5 Beitragenden

Tabelle 11, Metriken aus der Kategorie Community.

3.2.2.12. Professionalism-Kategorie

Die Professionalität, die hinter Entwicklungsprozess und Projektorganisation steht, wird

in dieser Kategorie bewertet.

Metrik: Projekt Treiber

Beschreibung: Der Projekt Treiber übernimmt das Projektmanagement,

Ressourcenverteilung, usw.

Bewertung: 5 - Unabhängige Gemeinschaft, die von Kapitalgesellschaften

unterstütz wird (z.B. Apache, Eclipse)

4 - Kapitalgesellschaften (z.B. MySQL)

2 - Gruppen

1 - Personen

Metrik: Schwierigkeit, um in das Kernentwicklerteam zu kommen.

Beschreibung: Um die Softwarequalität zu gewährleisten, müssen ausgereifte Projekte

selektiv bei der Akzeptanz von neuen Committern vorgehen.

Bewertung: 5 - Erst wenn man nach außen ein aktiver Committer für eine

Weile war.

3 - Ziemlich schwierig, man muss eine Zeit lang Patches

ausgeliefert haben, die akzeptiert wurden

1 - Jeder kann rein

Tabelle 12, Metriken aus der Kategorie Professionalism.


3.3. Testberichte

3.3.1. Einleitung

Um die Performance- und Speicherauslastungsmessungen durchzuführen, wurden

einige Testberichte entworfen, die von der Benchmarkanwendung als Vorlage

verwendet werden. Die Testberichte stellen dabei die sinnvollen Kombinationsarten von

Elementen in einem Bericht dar, die in einem Unternehmen angewendet werden

können. Die Tabelle 13 gibt eine Übersicht über die Testberichte.

Es wurden keine Drill-Down-Berichte entworfen, da einige der getesteten Reporting-

Frameworks diese Art von Berichten in der Open-Source-Version nicht unterstützten.

3.3.2. Übersicht

Name Berichtsbezeichnung Erläuterung

Tabellen-Bericht

Bericht 1 Eine Tabelle Dieser Bericht besitzt nur eine einzige Tabelle, die

vorformatiert ausgegeben wird.

Bericht 2 Mehrere Tabellen Es werden mehrere Tabellen in einem Bericht

platziert. Beide Tabellen haben unterschiedliche

Informationen, die dargestellt werden.

Zusammengesetzte Berichte

Bericht 3 Tabelle und Diagramm Bei einem zusammengesetzten Bericht werden

eine Tabelle und ein Diagramm verwendet.

Berichte mit Aggregation oder Gruppierung

Bericht 4 Aggregation Dieser Bericht enthält eine Tabelle, bei der eine

Zeile durch Aggregationen(Summation) berechnet

wird. Dabei werden mehrere Aggregationen

angewendet.

Bericht 5 Gruppierung In diesem Bericht wird die Gruppierung

verwendet, dabei wird eine bis zwei Spalten

gruppiert.

Sonstige Berichte

Bericht 6 Sub-Berichte In diesem Bericht wird eine äußere Tabelle mit

einer verschachtelten (inneren) Tabelle


Name Berichtsbezeichnung Erläuterung

verwendet. Dabei generiert die innere Tabelle

Daten durch einen Parameter, der von der äußeren

Tabelle übergeben wurde.

Tabelle 13, Übersicht: Testberichte

Die entsprechenden Abbildungen zu den oben aufgeführten Berichten befinden sich im

Anhang A.

3.4. Benchmarkanwendung

3.4.1. Beschreibung

Zur Performance- und Speicherauslastungmessung wurde eine Benchmarkanwendung

entwickelt. Die Anwendung verwendet die vorgefertigten Testreports, die in dem

jeweiligen Designer von den getesteten Reporting-Frameworks erstellt wurden. Die

Testreports werden von der Anwendung in den Speicher geladen und an die

ausgewählte Reporting-Frameworks übergeben. Die Frameworks beziehen die

benötigten Daten aus der Datenbank und exportieren die Berichte in unterschiedliche

Formate. Bei der Messung werden mehrere Durchläufe gemacht, damit die Messung

genauer ist. Dabei werden die Zeit und der Speicherverbrauch ermittelt und gespeichert.

3.4.2. Architektur

ReportBenchmark Klassendiagramm

+computePerformanceResult() : String

+initEngine()

#createHTMLReport(ein inputFile : File, ein count : int)

#createPDFReport(ein inputFile : File, ein count : int)

#createXLSReport(ein inputFile : File, ein count : int)

+stopEngine()

AReportingEngine

+createReportingEngine(ein engine : String) : AReportingEngine

ReportingEngineFactory

+main(ein args : String[])

BenchmarkRunner«uses»

«create»

«uses»

+start() : Stopwatch

+stop() : Stopwatch

+reset() : Stopwatch

+getElapsedTime() : long

Stopwatch«uses»

+usedMemory() : long

MemUtils«uses»

Abbildung 6, Klassendiagramm von der ReportBenchmark-Anwendung.


Die Architektur von der Anwendung wurde so aufgebaut, dass es möglich ist

mehrere Reporting-Frameworks zu testen, ohne den kompletten Quellcode zu ändern.

Dazu muss für das zu testende Framework eine Klasse implementiert werden, die von

der abstrakten Klasse AReportingEngine erbt.

3.4.2.1. BenchmarkRunner

Die BenchmarkRunner-Klasse ist die Hauptklasse der Anwendung und steuert diese.

Für die Initialisierung der Reporting-Frameworks werden die übergebenen Parameter

geparst und an die ReportingEngineFactory-Klasse weiter gegeben. Danach wird die

Reporting-Engine initialisiert und die Berechnungen durchgeführt, abschließend wird

die Reporting-Engine wieder gestopt.

3.4.2.2. ReportingEngineFactory

Die ReportingEngineFactory-Klasse erzeugt anhand des übergebenen Parameters die

entsprechende ReportingEngine-Klasse.

3.4.2.3. AReportingEngine

Diese Klasse implementiert die Methode computePerformanceResult(). Diese Methode

führt die Performance- und die Speicherauslastungstests durch. Außerdem kann diese

Methode von den einzelnen Implementierungen nicht überschrieben werden. Bei der

Erzeugung der einzelnen ReportingEngine-Klassen, muss man darauf achten, dass die

Methoden initEngine(), createHTMLReport(), createPDFReport(), createXLSReport()

und stopEngine() implementiert werden. Die Methode initEngine() ist für die

Initialisierung der Reporting-Engine zuständig. Die drei Methoden

createHTMLReport(), createPDFReport() und createXLSReport() sind für die

Erzeugung der Berichte zuständig, die in den Formaten HTML, PDF und XLS

exportiert werden. Die Methode stopEngine() führt die abschließenden Arbeiten durch

und beendet die Reporting-Engine.

Quellcode der Benchmarkanwendung befindet sich im Anhang B.

S e i t e 38

4. Auswahl und Vorstellung der Frameworks

4.1. Softwareauswahl

Nach der Internet- und Literaturrecherche30

wurde eine Übersicht von verfügbaren Open

Source BI-Lösungen aufgestellt, Tabelle 14. Dabei wurde darauf geachtet, dass die BI-

Lösungen die Kriterien für die Vorbewertung aus dem Kapitel 2.3.1 erfüllen.

Projekt Aktuelle

Version

Erstes

Release

Designer Reporting-

Engine

Pentaho-BI 1.6 2006 Pentaho

ReportDesigner

JFreeReport

BIRT 2.2.2 2004 BIRT Designer BIRT

JasperIntelligence 3.0 2006 IReport JasperReports

SpagoBI 2.0 2006 SpagoBIStudio JasperReports,

BIRT

openi 1.3 2005 - JasperReports

OpenReports 3.0 2003 - JasperReports,

JFreeReport,

BIRT

Tabelle 14, Übersicht von Open Source BI-Lösungen

Aus der Übersicht geht hervor, dass einige der ausgewählten BI-Lösungen keine

eigene Reporting-Engine benutzen, sondern eine vorhandene Reporting-Lösung aus

anderen Open Source-Projekten verwenden. Die führenden Reporting-Projekte sind

dabei JFreeReport von der Firma Pentaho, JasperReports von der Firma JasperSoft und

BIRT von Eclipse Foundation initiiert und vorangetrieben von der Firma Actuate. Im

weiteren Verlauf der Arbeit werden diese drei Reporting-Frameworks betrachtet und

bewertet.

4.2. Pentaho Reporting

4.2.1. Einführung

Pentaho-Reporting ist ein Modul zum Erstellen von Berichten und ist ein Bestandteil

von der Pentaho-BI-Suite. Dieses Modul wurde unter der Verwendung der Open Source

30

Held (2007); Kleijn (2006); Wayner (2008); Verity (2005)

4 Auswahl und Vorstellung der Frameworks S e i t e 39

Java-Bibliothek JFreeReport entwickelt. Die JFreeReport-Daten basieren auf dem

Swing-TableModel-Interface.

JFreeReport ist seit 2002 auf „sourceforge“ registriert und wurde von der Firma

Object-Refinery Ltd. bis 2006 gesponsert. Ab 2006 wurde JFreeReport von Pentaho

übernommen. Der Projektleiter von JFreeReport Thomas Morgner wurde von Pentaho

als Chief Architect of Reporting Solutions eingestellt. JFreeReport wurde daraufhin in

Pentaho-Reporting-Engine umbenannt und wird jetzt von Pentaho weiterentwickelt. Bis

zur Version 0.8.8 gab es bei dieser Engine keine integrierte Unterstützung der

Datenbanken, d.h. die Daten aus der Datenbank mussten manuell geladen und in

TableModel umgewandelt werden, damit die Reporting-Engine mit ihnen arbeiten

konnte.

4.2.2. Funktionsweise

Die Reportentwicklung unter Pentaho-Reporting unterteilt sich in zwei Stufen:

Designtime und Runtime, Abbildung 7.

RuntimeDesigntime

Action

Sequence

Data

Pentaho Report

Design Wizard

JFreeReport

Pentaho Reporting Engine

HTML

PDF

Print

XML

...

*.xaction

*.xml

Pentaho Report

Designer

Extended

Report

Definition

Abbildung 7, Pentaho-Reporting High-Level-Architektur.

Bei Pentaho-Reporting besteht die Möglichkeit in der Designtime einen Bericht

durch den Pentaho-Report-Designer oder durch den Report-Design-Wizard zu

entwerfen. Der Bericht kann dabei in eine einfache XML-Template-Datei (*.report)

gespeichert werden. Da diese aber von der Reporting-Engine nicht akzeptiert wird,

muss der Bericht exportiert werden. Nach dem Export erstellt der Designer zwei XML-

Dateien (*.xaction und *.xml). In der Action-Datei (*.xaction) werden Aktionen

definiert, die ausgeführt werden müssen, damit ein Bericht erzeugt werden kann. In der

Extended-Report-Definition-Datei (*.xml) wird das komplette Report-Objekt in einem

XML-Format beschrieben.


Für die Runtime werden beide XML-Dateien (*.xaction und *.xml) verwendet, um

einen Bericht zu erzeugen. Die Action-Datei wird interpretiert und die Plattform führt

die entsprechenden Module aus, die für die Aktionen benötigt werden. Verwendet man

nicht die Plattform, sondern nur die Bibliothek, benötigt man die Action-Datei nicht.

Damit die Bibliothek auf die Datenbank zugreifen kann, müssen die Verbindungsdaten

und die benötigten Treiber-Definitionen manuell in die Extended-Report-Definition-

Datei eingetragen werden.

4.2.3. Architektur

Pentaho verwendet eine J2EE-Architektur. Die Pentaho Suite ist prozessorientiert

aufgebaut. Es werden nicht Berichte, Datentransformationen oder andere Objekte

ausgeführt, sondern Business Intelligence Prozesse. Die Prozesse werden durch Action

Sequences beschrieben, die als XML-Dateien abgelegt werden. Eine Action Sequence

kann mehrere Aktionen definieren. Um beispielsweise einen einfachen Bericht zu

erzeugen, werden in der Action Sequence drei Aktionen definiert: Abfrage von

Parametern, Abfrage von Daten aus einer Datenquelle und die Aufbereitung und

Ausgabe von einem Bericht, Abbildung 8. Natürlich lassen sich auch aufwendigere

Prozesse definieren, dazu werden Schleifen und Bedingungen bereitgestellt.

J2EE Server

Action Sequence

Parameter

SQL Rule

Action

Report

Action

Prompt/Filter

Action

Ergebnis

Bericht

We

b B

row

se

r

DBMSSQL

Component

Reporting

Component

Reporting

Engine

SQL

Berichtsdefinition

und Daten

Abfrageergebnis

Bericht

SQL

Ergebnis

BerichtBerichtsdefinition

und Daten

Aufruf

Action Sequence

HTML Formular

Formularparameter

Bericht

Abbildung 8, Pentaho Reporting Architektur.

Durch die modulare Architektur können die Module einfach ausgetauscht werden.

Für die Berichtserzeugung kann nicht nur die Pentaho Reporting Engine genutzt

werden, sondern alternativ die Engine von JasperSoft oder die von BIRT. Hierfür stellt


Pentaho schon vorbereitete Module zur Verfügung. Durch die Modularisierung erreicht

Pentaho eine sehr hohe Flexibilität. Der Nachteil dieser Flexibilität ist eine gewisse

Unübersichtlichkeit.

Natürlich lässt sich die Pentaho-Reporting-Engine auch ohne die BI-Suite einsetzen,

dadurch entfallen die Action-Sequences. Die Aktionen, die von Action-Sequences

ausgeführt werden, müssen dann programmatisch aufgerufen und ausgeführt werden.

4.3. JasperReports

4.3.1. Einführung

JasperReports ist eine Open Source Java-Bibliothek, die eine API (Application

Programming Interface) anbietet, um Berichte zu erstellen. Damit ist es möglich

JasperReports in jede Java-Anwendung einzubauen. Trotzdem wird JasperReports

vorwiegend für Web-Applikationen verwendet, obwohl JasperReports keine

Abhängigkeiten zu der vorhandenen Servlet-API oder den Java EE-Bibliotheken besitzt.

Als Teodor Danciu 2001 beauftragt wurde in einem Projekt Reporting-

Funktionalitäten zu implementieren, hat er eine Evaluierung von vorhandenen

Reporting-Tools durchgeführt, dabei kam heraus, dass diese für das Projekt einfach zu

teuer sind, deshalb hat er beschlossen ein eigenes Reporting-Tool zu schreiben. Das

Projekt, für welches er das Reporting-Tool schreiben sollte, wurde abgebrochen,

deshalb begann er in seiner Freizeit an JasperReports zu arbeiten. Das Projekt wurde im

September 2001 bei Sourceforge.net angemeldet, aber noch kein Quellcode

hochgeladen. Im November 2001 wurde JasperReports in der Version 0.1.5

freigegeben.

2004 holte die Firma Panscopic, die sich mit Embedded Reporting befasste, Teodor

an Bord und änderten den Namen des Unternehmens in JasperSoft. Der offizielle Start

als kommerzielles Unternehmen unter dem neuen Namen erfolgte im April 2005.

JasperSoft sponserte die Entwicklung von JasperReports, dadurch konnten Teodor und

andere JasperSoft-Entwickler in Vollzeit daran arbeiten.


Die Reportentwicklung mit JasperReports unterteilt sich in zwei Stufen: Design- und

Runtime, Abbildung 9.


RuntimeDesigntime

XML

Report

Design

Data

JasperAssistantCustom Report

Designer

Jasper Compiler

Report

Document

Jasper Reporting Engine

HTML

PDF

Print

XML

...*.jrxml

*.jrprint

*.jasper

IReport

Native Binary Template

Abbildung 9, JasperReports High-Level-Architektur.

Zur Designtime wird mit dem Designer IReport oder einem anderen Designer ein

Bericht erzeugt. Dieser wird als XML-Report-Template (*.jrxml) gespeichert. Bevor

man den Bericht an die Jasper-Reporting-Engine übergibt, kann man diesen

kompilieren. Das Kompilieren wird vom Designer bewerkstelligt. Als Ergebnis wird

eine Native-Binary-Template-Datei (*.jasper) erzeugt. Man kann das Kompilieren auch

außerhalb des Designers durchführen, indem man es programmatisch oder mit ANT

realisiert.31

Die Jasper-Reporting-Engine kann die XML-Report-Template-Datei auch

direkt verarbeiten, diese wird von der Engine selbst kompiliert, aber keine Native-

Binary-Template-Datei erzeugt.

Um ein Bericht in der Runtime durch die Jasper-Reporting-Engine zu erzeugen, wird

die Native-Binary-Template-Datei (*.jasper) verwendet. Die Engine holt die benötigten

Daten aus den Datenquellen und bereitet diese auf, als Ergebnis erzeugt diese ein

Report-Dokument, der in eine Datei (*.jrprint) gespeichert werden kann. Das Report-

Dokument ist ein vollständiger Bericht, der zur Betrachtung, zum Drucken oder zum

Exportieren geeignet ist. Das Report-Dokument kann von der Engine in verschiedene

Formate wie z.B. in PDF oder HTML exportiert werden.

4.3.3. Architektur

Die Architektur der JasperReports-Bibliothek ist modular aufgebaut, dadurch lässt sich

diese in jede Java-Anwendung integrieren. Für einige Funktionalitäten, wie PDF-,

31

Vgl. Heffelfinger (2006), S. 16, 34, 36-37.


SVG-, Word- und Excel-Exporte, verwendet JasperReports Fremdbibliotheken aus

JasperReportingEngine

JRXmlLoader

JRXML

Jasper-

Report

JasperPrint

Jasper-

Design

JasperPrint

Manager

JasperExport

Manager

JasperFill

Manager

JRCompiler

JasperCompile

Manager

ScreenPrinterPDFHTMLXML

printexport

fill

compile

parse

SQL

XML

EJB

Hibernate

POJO

JNDI

XQery, XPath

JRDataSource

JDBC, JNDI

Abbildung 10, Jasper-Reporting-Engine.32

anderen Open Source Projekten. Außerdem stellt JasperReports eine API zur

Verfügung, um bestimmte Funktionalitäten zu erweitern oder zu verändern. So ist es

möglich eine eigene JRDataSource zu implementieren, um auf Datenbanken, die

nicht durch JDBC kontaktiert werden können, oder andere Dateien zu zugreifen,

Abbildung 10.

4.3.3.1. JasperDesign

JasperDesign enthält das Rohmaterial des Berichtes, welches von der JasperReports-

Bibliothek verwendet wird, um ein Bericht zu generieren. Die JRXMLLoader-Klasse

erzeugt das JasperDesign, indem es die XML-Datei (*.jrxml) interpretiert. Es ist auch

möglich JasperDesign programmiertechnisch zu ändern, indem man die JasperReports

API verwendet.

32

Vgl. Danciu/Chirita (2007), S. 31.


Alle Instanzen von JasperDesign müssen kompiliert werden, bevor diese für die

Datenaufbereitung und Berichtserzeugung genutzt werden können.

4.3.3.2. JasperReport

JasperReport ist die kompilierte Version von JasperDesign. Diese wird durch den

Kompilierprozess von JasperReports erstellt und ist bereit für die Datenaufbereitung

und Berichtserstellung.

Beim Kompilierprozess wird die Konsistenz geprüft und eine Reorganisation der

Berichtselemente durchgeführt, um einen schnelleren Durchsatz in der Anwendung zu

erzielen. Es wird zudem eine Klasse oder Script-Datei erstellt, je nachdem welcher

Compiler verwendet wird, in der die Berichtsausdrücke (Variablen-, Text- und

Bildausdrücke) gespeichert werden. Diese Klasse oder Script-Datei wird später während

des Datenaufbereitungsprozesses zur Auswertung der Berichtsausdrücke verwendet.

4.3.3.3. JasperPrint

Die Instanz von JasperPrint ist das Ergebnis des Datenaufbereitungsprozesses aus der

JasperReports-Bibliothek, und stellt das proprietäre Format zur Speicherung von

vollfunktionsfähigen und seitenorientierten Dokumenten dar. JasperPrint kann in

verschiedene Formate, wie PDF, HTML, RTF, XLS und andere, transformiert, direkt

durch den eingebauten Report-Viewer dargestellt oder auf die Festplatte gespeichert

werden.

4.3.3.4. JasperCompileManager

Der CompileManager stellt alle Kompilierungsfunktionalitäten der Bibliothek zur

Verfügung. Dieser enthält Methoden, die dem Anwender die Kompilierung der

JRXML-Datei, die von der Festplatte oder über einen Stream kommt, erlaubt. Das

bedeutet, dass die Erzeugung des JasperDesigns intern abläuft und die Methoden direkt

ein JasperReport-Objekt zurück liefern. Es stehen auch Methoden zur Verfügung, die

die JRXML-Datei parsen und als Ergebnis einen JasperDesign-Objekt zurück liefern.

Außerdem enthält der CompileManager einige Methoden zur Template-Verifizierung

und JRXML-Datei-Erzeugung. Dies ist sehr nützlich für die GUI-Anwendung, über die

ein Bericht entworfen werden kann.

4.3.3.5. JasperFillManager

Der FillManager ist für die Datenaufbereitung zuständig. Er enthält mehrere Methoden,

über die das Report-Template geladen und verarbeitet werden kann. Diese unterstützen


das Laden des Report-Templates aus einer Datei, einem Objekt oder auch aus einem

Eingangs-Datenstrom. Außer dem Report-Template, benötigt der FillManager die

Informationen über eine Datenquelle, aus der er die Daten beziehen soll. Es besteht

auch die Möglichkeit bestimmte Report-Parameter zu übergeben, die zur Erzeugung des

Berichts benötigt werden.

Eine Vielzahl von Berichten benötigen die Daten aus einer relationalen Datenbank.

Dazu stellt der FillManager einige Methoden bereit, die wiederum die Informationen zu

einer Datenbankverbindung benötigen. Wenn diese Informationen übergeben werden,

wird vom FillManager automatisch eine JRDataSource für den Zugriff auf die

Datenbank über JDBC geladen.

Möchte man die vorhandene JRDataSource nicht nutzen, kann man eine eigene

JRDataSource erstellen, dazu muss beim Programmieren darauf geachtet werden, dass

diese das Interface JRDataSource aus der JasperReports-Bibliothek implementiert.

4.3.3.6. JasperExportManager

Der ExportManager bietet Methoden zum Transformieren von Report-Dokumenten

(JasperPrint) in verschiedene Formate (PDF, HTML, CVS, RTF, XSL usw.). Es besteht

auch die Möglichkeit die Daten aus verschiedenen Quellen zu erhalten und die

Ergebnisse an verschiedene Ziele zu verschicken (Dateien, Eingangs- und Ausgangs-

Datenströme, usw.).

4.3.3.7. JasperPrintManager

Der PrintManager bietet vorgefertigte Methoden, um das Report-Dokument oder nur

Teile davon anzuzeigen oder zu drucken. Wenn ein Bericht an einen Drucker geschickt

wird, besteht die Möglichkeit den Drucker über ein Druck-Dialog auszuwählen.

4.4. BIRT

4.4.1. Einführung

BIRT (Business Intelligence and Reporting Tools) ist ein auf Eclipse basierendes Open

Source Projekt, welches Teile des Berichtswesen- und Business-Intelligence-

Funktionalitäten für Rich Clients und Web-Applikationen zur Verfügung stellt.

In der ersten Jahreshälfte 2004 wurde BIRT von der Firma Actuate Corporation

finanziert und entwickelt. Am 24. August 2004 trat Actuate als strategischer Entwickler

der Eclipse Foundation bei und schlug das BIRT-Projekt vor. Als das Projekt am


6. Oktober 2004 akzeptiert und zu einem Top-Level-Projekt innerhalb der Eclipse-

Community wurde, spendete Actuate die geleistete Arbeit.


Die Reportentwicklung unter BIRT unterteilt sich in zwei Stufen: Designtime und

Runtime, Abbildung 1. Die Aufteilung in die zwei Stufen hat den Vorteil, dass die

Runtime auf einem Server oder in einer externen Anwendung platziert werden kann und

so von der eigentlichen Reportentwicklung getrennt wird.

RuntimeDesigntime

XML

Report

DesignData

Eclipse

Report

Designer

Web Based

Report

Designer

Custom

Report

Designer...

Report Design Engine

Report

Document

Charting Engine

Report Engine

Generation

Services

Presentation

Services

HTML

PDF

Print

XML

...

*.rptdesign*.rptdocument

Abbildung 11, BIRT High-Level Architektur.33

In der Designtime wird der Report über einen vorhandenen oder eigenen Designer

entworfen und an die Datenquellen angebunden. Die Designer verwenden die API von

der Report-Design-Engine, um eine Report-Design-Datei (*.rptdesign) zu erzeugen.

Diese wird standardmäßig als eine XML-Datei abgespeichert.

Die erzeugte Design-Datei aus der Designtime wird in der Runtime verwendet, um

den Report zu erstellen. Der Prozess der Erstellung läuft in zwei Phasen ab:

Generierung und Präsentation (Rendern).

Bei der Generierung werden in dem Generation-Service die Datenquellen abgefragt

und die Daten aufbereitet, indem diese berechnet und transformiert werden. Als

Ergebnis liefert Generation-Services ein Report-Document (*.rptdocument), in der die

aufbereiteten Daten gespeichert werden.

In der zweiten Phase rendert der Presentation-Service das Report-Document und

erzeugt daraus HTML, PDF oder andere Formate.

33

Vgl. Eclipse-Birt (2008)b


4.4.3. Architektur

Die Architektur von BIRT ist sehr eng in die Architektur von Eclipse integriert, so dass

BIRT aus Plug-ins besteht und dadurch dem Eclipse-Konzept folgt. Der Aufbau von

BIRT lässt sich am besten als ein Gebäude darstellen. In den unteren Ebenen befinden

sich die Eclipse-Platform und die Eclipse-Frameworks, die auf die Eclipse-Platform

aufbauen. Die BIRT-Core-Components befinden sich in der Ebene drei. Sie verwenden

die darunterliegenden Ebenen, in denen sich die Eclipse-Framworks und die Eclipse-

Platform befinden. Die BIRT-Engines bauen auf den Core-Components auf und

verwenden auch die darunterliegenden Ebenen. Die BIRT-Engines werden von BIRT

verwendet, um bestimmte Aufgaben zu erledigen. Diese werden auf der obersten Ebene

von den BIRT-Applikationen verwendet. Die BIRT-Applikationen teilen sich in zwei

Teile auf: BIRT-Designers und BIRT-Run-time-Applications, Abbildung 12.

In den nachfolgenden schematischen Darstellungen der BIRT-Architektur werden

folgende Meta-Bezeichnungen verwendet:

BIRT Report Designer

massive Kästchen: eine Standardkomponente von

BIRT.

Report item extensions

gestrichelte Kästchen:

eine spezielle Komponente, die

von einem Java-Entwickler

verwendet werden kann.

Chart engine

gepunktete Kästchen:

eine Standardkomponente von

BIRT, die von anderen BIRT-

Komponenten verwendet wird.

4.4.3.1. Applikationen

BIRT bietet drei Hauptapplikationen an:


BIRT RCP Report Designer

BIRT Report Viewer


BIRT applications

BIRT designers


Chart Builder

BIRT RCP Report Designer

BIRT run-time application

BIRT Report Viewer

Custom Viewer ...

BIRT engines

Design engine Data engineReport engine

Presentation

engineScript engine

Chart engine

Generation

engine

BIRT core component plug-ins

Eclipse frameworks

Eclipse platforms

Data Tools

Framework

Eclipse Modeling

Framework

Graphical

Framework

Eclipse Tools Platform Eclipse Rich Client Platform

Abbildung 12, BIRT Komponenten als Plug-ins für die Eclipse-Platform34

4.4.3.2. BIRT Report Designer und BIRT RCP Report Designer

Der BIRT Report Designer ist ein grafisches Werkzeug mit dem Berichte entworfen

werden. Er besteht aus mehren Eclipse-Plug-ins und wird in die Eclipse-Workbench

integriert. Unter der Verwendung der Report-Design-Engine, erzeugt der BIRT Report

Designer eine Report-Design-Datei. Report-Design-Dateien sind XML-Dateien, die auf

der Syntax von Report Object Model (ROM) basieren.

Der BIRT RCP Report Designer ist eine eigenständige RCP-Anwendung, die auf

Eclipse-RCP basiert, und besitzt im Gegensatz zum BIRT Report Designer ein

vereinfachtes Design-Interface.

34

Vgl. Weathersby/et al. (2006), S. 48.



Bookmarks

Charts

Data sources

Data filters

Data groups

Data mapping rules

Tools to create and edit report components and rules, including:

Data sets

Expressions

Highlighting rules

Hyperlinks

Library components

Master pages

Properties

Report layout

Report parameters

Report XML

Scripts

Styles

Report online explorer

Library outline explorer

Data explorer

Report item palette

Report online explorer

BIRT report viewer

Data previewer

Data engine

ODA framework

Data sourceCustom data

source

Design engine

Report Object Model (ROM)

Standard BIRT report items

Report item extensions

Report library files

(.rptlibrary)

Report design

(.rptdesign)

Report template files

(.rpttemplate)

Web application

BIRT report viewer

Report previewer Custom Java application

BIRT report viewer Report engine

Abbildung 13, BIRT Report Designer: Beziehung zwischen Standard- und Spezialkomponenten.35

Die Hauptunterschiede sind:

BIRT RCP Report Designer kann zur gleichen Zeit nur eine einzige Design-

Datei geöffnet haben.

BIRT RCP Report Designer hat keinen integrierten Debugger.

BIRT RCP Report Designer unterstütz die Java-Event-Handler nicht.

35

Vgl. Weathersby/et al. (2006), S. 49.


Die Report-Designer-Applikationen unterstützen eine Wiederverwendung von

Report-Designs, indem diese als Templates abgespeichert werden können.

4.4.3.3. BIRT Report Viewer

BIRT Report Viewer ist ein Java Web-Servlet, der aus dem Report-Design einen Report

generiert und präsentiert. Dieser verwendet die Generation-Engine und den Report-

Design, um ein Report-Document zu erzeugen. Weiterhin verwendet der Report Viewer

die Presentation-Engine, um aus dem Report-Document einen Report zu erzeugen.

BIRT report viewer

Report engine

Generation engine

Presentation engine

Report design

(.rptdesign)

Chart engine

Design engine

Report items

Script engine Data engine

Data access engine

Data transform engine

Report executor

Report document

(.rptdocument)

Data sourceCustom data

source

ODA Framework

Data Engine

Data access engine

Script engine Emitters

Report renderer

PDF emitter

HTML emitter

Custom emitterChart Engine

Report

(PDF, HTML, Custom format)

Abbildung 14, BIRT Report Viewer: Beziehung zwischen Standard- und Spezialkomponenten.36

36

Weathersby/et al. (2006), S. 50.


Für die Berichts-Vorschau verwenden die Report Designer den BIRT Report Viewer,

um den Bericht darzustellen.

Der BIRT Report Viewer kann auf verschiedenen Servern eingesetzt werden, z.B.

Apache Tomcat, IBM WebSphere oder BEA WebLogic, um einige davon zu nennen.

4.4.3.4. BIRT-Engines

BIRT verwendet mehrere Engines, diese bieten eine API an, um bestimmte

Funktionalitäten bereit zu stellen. Zum Beispiel bietet die BIRT Data Engine API für

die Datenzugriffe an.

4.4.3.4.1 BIRT Chart-Engine

Die Chart-Engine enthält APIs zur Generierung von Diagrammen und verbindet diese

mit den Daten, die aus dem Data-Source kommen. Die Verwendung der Chart-Engine

ist nicht nur auf BIRT begrenzt. Jede Java-Anwendung kann die Chart-Engine

verwenden, um die Diagramme zu erzeugen und darzustellen. Der BIRT-Report-Viewer

interpretiert die Chart-Design-Informationen aus der Report-Design-Datei und

verwendet die Chart-Engine, um die Diagramme zu generieren.

4.4.3.4.2 BIRT Design-Engine

Die Report-Design-Engine enthält APIs zur Validierung und Generierung von Report-

Design-Dateien. Die Validierung und Generierung der Struktur von Report-Design-

Datei wird anhand der ROM-Spezifikation durchgeführt. Diese Engine wird vom BIRT-

Report-Designer und von einer individuellen Java-Anwendung verwendet, die eine

Report-Design-Datei erstellen möchte. Die Generation-Engine verwendet auch die

Report-Design-Engine zum Erzeugen der Report-Document-Datei.

4.4.3.4.3 BIRT Data-Engine

Die Data-Engine enthält APIs zum Abrufen und Aufbereiten der Daten. Wenn die Data-

Engine von der Generation-Engine verwendet wird, werden die Daten aus dem Data-

Source geholt. Wird die Data-Engine von der Präsentation-Engine verwendet, werden

die Daten aus dem Report-Document geladen.

Die Daten-Engine besteht aus zwei Hauptkomponenten, der Data-Access-

Komponente und der Data-Transform-Komponente. Die Data-Access-Komponente

interagiert mit dem ODA-Framework, um Daten zu erhalten. Die Data-Transform-

Komponente sortiert, gruppiert, aggregiert und filtert die Daten, die von der Data-

Access-Komponente geliefert werden.


Das Open Data Access (ODA) Framework verwaltet ODA-Treiber und native

Treiber. Es lädt die Treiber, öffnet Verbindungen und verwaltet die Abfragen. Das

ODA-Framework verwendet das Data-Tools-Platform-Projekt zum Verwalten von

Verbindungen. Durch die Erweiterungs-Punkte, die vom ODA-Framework angeboten

werden, können eigene ODA-Treiber entwickelt und eingebunden werden. Die eigenen

ODA-Treiber sind wichtig, wenn man eine Datenquelle verwenden möchte, die von

BIRT nicht unterstütz wird.

4.4.3.4.4 BIRT Report-Engine

Die Report-Engine besteht aus zwei Teilen, der Generation-Engine und der

Presentation-Engine. Der BIRT-Report-Viewer und die individuell entwickelten Java-

Applikationen verwenden die Report-Engine, um das Report-Design aufzubereiten und

einen Bericht in einem bestimmten Format zu generieren.

4.4.3.4.4.1 BIRT Generation-Engine

Die Generation-Engine enthält APIs zum Auslesen und zum Interpretieren von Report-

Design. Um Daten aus dem Data-Source, der in dem Report-Design enthalten ist, zu

bekommen und aufzubereiten, verwendet die Generation-Engine die Data-Engine. Als

Ergebnis liefert die Generation-Engine ein Report-Document, welches das

Zwischendokument bei der Erstellung eines Berichts ist.

4.4.3.4.4.2 BIRT Presentation-Engine

Die Presentation-Engine verwendet das Report-Document, welcher von der Generation-

Engine erzeugt wurde, und erstellt daraus einen Bericht in dem gewünschten Format.

Wie die Generation-Engine, verwendet die Presentation-Engine die Data-Engine.

Während des Präsentationsabschnitts werden die Daten von der Data-Engine aus dem

Report-Document geladen.

Für die formatspezifische Darstellung verwendet die Presentation-Engine die

sogenannten Emitter. BIRT besitzt zwei Standard-Emitter: HTML und PDF (in der

aktuellen Version von BIRT werden mehrere Emitter mitgeliefert, um einen Bericht im

Word- oder Excel-Format darzustellen). Falls keine passenden Emitter für die

Darstellung existieren, besteht die Möglichkeit eigene zu entwickeln.

Die Chart-Report-Items und eigens entwickelte Report-Items erweitern die

Presentation-Engine, damit diese auch dargestellt werden können.

S e i t e 53

5. Durchführung der Evaluierung

5.1. Verteilung der Gewichtungen bei Kategorien

Wie im Kapitel 3.1 beschrieben, müssen in der Phase 2 des BRR-Models zwölf

Kategorien nach der Wichtigkeit geordnet und durchnummeriert werden. Aus zwölf

Kategorien sollten die ersten sieben für die Gewichtung ausgewählt werden. Folgende

Kategorien wurden ausgewählt und gewichtet:

Grad Kategorie Gewichtung

1 Functionality 25%

2 Usability 20%

3 Documentation 15%

4 Quality 15%

5 Architecture 10%

6 Scalability 10%

7 Community 5%

8 Adoption 0%

9 Security 0%

10 Performance 0%

11 Support 0%

12 Professionalism 0%

Tabelle 15, Kategorien mit Gewichtungen

Die Kategorien Security, Performance, Support, Adoption und Professionalism

fließen in die Bewertung nicht mit ein und werden im weiteren Verlauf der Arbeit nicht

mehr betrachtet. Die Support-Kategorie wurde nicht in die Bewertung aufgenommen, da

der Support, der von den Firmen angeboten wird, die hinter dem Projekt stehen, nicht

kostenlos ist und dieser nur für die BI-Suiten angeboten wird. Da die Performance und

Speicherauslastung im Rahmen dieser Arbeit gemessen werden, wurde die

Performance-Kategorie nicht ausgewählt. Die Security-Kategorie wurde nicht

ausgewählt, da die Metriken in dieser Kategorie nicht zu den ausgewählten Projekten

passen. Bei den ausgewählten Frameworks wurde das Projekt von Unternehmen

5 Durchführung der Evaluierung S e i t e 54

initialisiert, und wird von diesen auch vorangetrieben und weiterentwickelt, wurde die

Kategorie Professionalism nicht ausgewählt. Außerdem wird in dieser Kategorie

gemessen, wie einfach man in das Core-Team beitreten kann, da dieses Vorhaben nicht

verfolgt wird.

Die wichtigsten der ausgewählten sieben Kategorien sind Functionality und

Usability. Die Kategorie Functionality bekommt eine Gewichtung von 25% und die

Kategorie Usability eine Gewichtung von 20%. Das ausgewählte Framework muss

durch die angebotenen Funktionalitäten die Anforderungen, die an das Framework

gestellt werden, abdecken. Wenn das nicht der Fall ist, kann das Framework nur

begrenzt eingesetzt und genutzt werden. Desweiteren ist die Usability bei den

angebotenen Reporting-Designern sehr wichtig. Wenn das Designer-Werkzeug nur

begrenzt oder unbenutzbar ist, kann dieses die gestellten Anforderungen nicht erfüllen.

Die Kategorien Documentation und Quality bekommen jeweils eine Gewichtung von

15%. Die Dokumentation eines Projekts ist wichtig bei Integration und Verwendung des

Frameworks. Wenn die Dokumentation erhebliche Mängel aufweist oder gar nicht zur

Verfügung steht, wird es sehr mühsam das Framework zu integrieren und zu

verwenden. Die Qualität eines Frameworks ist maßgebend für den Einsatz. Wie oben

schon beschrieben, wird die Qualität anhand der Releases, Patches und Anzahl der

Fehler gemessen. Wenn ein Framework zu oft gepatcht wird, dann bedeutet das, dass

das Framework nicht ausreichend getestet wurde und damit auch bei der Integration

erhebliche Probleme bereiten kann. Bei der Anzahl der gemeldeten Fehler sollte man

allerdings vorsichtig sein, denn je größer das Projekt ist, desto höher ist die

Wahrscheinlichkeit, dass mehr Fehler auftreten können. Hierbei sollte man auf das

Projekt-Team achten, wie dieses mit den Fehlern umgeht und wie schnell diese behoben

werden. Wichtiger Punkt sind die regelmäßigen Releases; denn daran kann man

erkennen, dass das Projekt weiter vorangetrieben wird.

Die weiteren Kategorien Architecture und Scalability wurden mit einer Gewichtung

von jeweils 10% gewertet. Bei der Integration eines Frameworks in die vorhandene

Anwendung, sollte das Framework bestimmte Schnittstellen und eine entsprechende

Architektur anbieten. Wenn das Framework keine sichtbare Architektur hat, wird es

sehr schwierig dieses in eine Anwendung zu integrieren oder das Framework zu

erweitern. Die Skalierbarkeit eines Frameworks ist maßgebend für den Einsatz. Ist ein

Framework nicht skalierbar, ist ein Einsatz in einer Serveranwendung nicht


empfehlenswert. In diesem Fall muss erheblicher Aufwand betrieben werden, um das

Framework skalierbar zu machen.

Die Kategorie Community bekommt eine Gewichtung von 5%. Bei einem

Framework ist seine Verbreitung und Akzeptanz durch die Community und die

Industrie sehr wichtig. Wenn ein Framework nicht so weit verbreitet ist, besteht die

Möglichkeit, dass die Entwicklung eingestellt wird, oder dass die Qualität der Software

nicht gut genug ist, um diese in der Industrie einsetzen zu können. Natürlich ist auch die

Community, die hinter einem Projekt steht, maßgebend für die Weiterentwicklung und

den Support des Projektes. Die erste Anlaufstelle bei einem Problem ist meistens die

Mailingliste oder das Forum, die beide durch die Community gepflegt werden.

5.1.1. Gewichtungen unter der Kategorie Functionality

Die untenstehende Tabelle zeigt die ausgewählten Standardfunktionalitäten mit

Gewichtungen, die ein Reporting-Framework unterstützen muss und die

Zusatzfunktionalitäten, die ein Reporting-Framework haben kann. Die Funktionalitäten

aus der Tabelle 16 wurden anhand der Anforderungen und angebotenen

Funktionalitäten ausgewählt. Die Funktionalitäten wurden in vier Gruppen unterteilt:

Ausgabeformate, Datenquellen, Diagramme und Reporting.

Funktionalitäten Gewichtung

Standardfunktionalitäten

Ausgabeformate

PDF 3

HTML 3

Excel 3

Word (DOC) 2

Word (RTF) 2

Datenquellen

JDBC 3

Hibernate 2

Diagramme



Einbindung dynamischer Inhalte (Bilder, Texte) 3

Einbindung von Charts 3

Reporting

Templating (Schablonen) 3

Verschiedene Datenquellen innerhalb eines Reports 3

Drill-Down-Analyse innerhalb eines Reports 2

Internationalisierung (Zeichensatz, Währung..) 3

Unterstützt Sub-Reports (Verschachtelung) 2

Parametrisierte Reports 3

Aggregationen und Gruppierung 2

Zusatzfunktionalitäten

Ausgabeformate

TXT 1

PPT 1

OpenOffice (ODT) 1

XML 1

CSV 2

SVG (Scalable Vector Graphics) 1

Datenquellen

POJO/Java Beans 2

CSV 1

XML 1

Web Services 1

XML/A,MDX 1

Metadatenunterstützung 1



Reporting

Preview Funktionalität 2

Scheduler für Reportgenerierung 2

E-Mail Bursting (Verteilung) 2

View Engine für Web-Applikation 2

View Engine für Desktop-Anwendung 2

Report-Entwurf aus Web-Applikation 1

Pixelgenaue Report-Erstellung 2

Cross-Tab Unterstützung 2

Tabelle 16, Übersicht: Gewichtungen von Funktionalitäten.

Die Ausgabeformate beinhalten die Datei-Formate in die ein Bericht exportiert

werden kann. Dabei wurden die Formate PDF, HTML und Excel als sehr wichtig

gewichtet, da dies die gängigsten Formate in der Praxis sind. Vor allem ist das HTML-

Format für die Darstellung der Berichte durch eine Web-Anwendung unabdingbar. Als

wichtig wurden die Formate DOC, RTF und CSV gewichtet. Für weniger wichtig

wurden die Formate TXT, PPT, ODT, XML und SVG gewichtet.

Die Datenquellen sind für eine Reporting-Anwendung notwendig, da zum

Aufbereiten und Erstellen der Berichte Daten für den Inhalt benötigt werden. Die

wichtigste Datenquelle ist dabei JDBC. Durch die angebotenen JDBC-Treiber ist es

möglich die Daten aus jeder Datenbank in einem Reporting-Framework zu verwenden.

Für wichtig wurden die Datenquellen Hibernate und POJO befunden, da diese meistens

in einer Serveranwendung verwendet werden.

Durch das Einbinden von dynamischen Inhalten, wie Text und Bilder, besteht die

Möglichkeit, die Berichte verständlicher und angepasster an das Corporate Design des

Unternehmens zu gestallten, deswegen wurde diese Kategorie als sehr wichtig bewertet.

Das Einbinden von Charts in einen Bericht ist sehr wichtig, dadurch kann man die

angebotenen Informationen, die in den Tabellen platziert sind, ergänzen und die

wichtigsten Ergebnisse grafisch darstellen.

Die letzte Gruppe „Reporting“ fasst die Reporting-spezifischen Funktionalitäten

zusammen. In dieser Gruppe sind die Funktionalitäten der Server-Anwendungen und


der Report-Designer gemischt. Als sehr wichtig wurden die Funktionalitäten

Templating, verschiedene Datenquellen innerhalb eines Reports, Internationalisierung

und parametrisierte Reports bewertet.

Das Templating ist beim Entwerfen der Berichte sehr wichtig, da man dadurch eine

Schablone erstellen kann, die ein Corporate Design des Unternehmens besitzt oder eine

bestimmte Struktur des Berichtes beinhaltet. So kann man die Schablone für jeden

einzelnen Report verwenden, ohne diesen immer wieder neu zu entwerfen.

Die Möglichkeit verschiedene Datenquellen innerhalb eines Reports zu verwenden,

ermöglicht das Erstellen von Berichten mit mehreren Tabellen, die unterschiedliche

Datenquellen haben und damit auch verschiedene Informationen anbieten.

Die Internationalisierung innerhalb der Berichte spielt eine sehr große Rolle. Die

automatische Unterstützung dieser Funktionalität ermöglicht das Erstellen von

Berichten in unterschiedlichen Sprachen. Wenn diese Funktionalität nicht unterstützt

wird, so müssen die Berichte für jede einzelne Sprache angepasst werden, was einen

deutlichen Mehraufwand bei dem Entwerfen der Berichte darstellt.

Für dynamisches Reporting sind die parametrisierten Berichte sehr wichtig, dabei

kann man eine allgemeine SQL-Anweisung entwickeln und durch Parameter bestimmte

Ergebnisse erhalten. Dieses Vorgehen wird als Beispiel bei den Berichten verwendet,

die für einen bestimmten Zeitabschnitt oder für eine bestimmte Abteilung generiert

werden sollen.

Als wichtig wurden folgende Funktionalitäten bewertet: Drill-Down-Analyse

innerhalb eines Reports, Sub-Reports (Verschachtelung), Aggregationen und

Gruppierung, Preview Funktionalität, Scheduler für Reportgenerierung, E-Mail

Bursting zur Verteilung, eigene View Engine Web Applikation, Report View Engine,

Reporterstellung aus Webapplikation, pixelgenaue Report-Erstellung und Cross-Tab

Unterstützung.

Für eine bessere Übersicht werden die komplexen Berichte verdichtet, dadurch ist es

nicht ganz klar, wie die Kennzahl, die in dem verdichteten Bericht dargestellt werden,

zustande gekommen sind. Die Funktionalität Drill-Down-Analyse hilft dabei die genaue

Zusammensetzung der Kennzahlen zu verdeutlichen. Indem man auf eine Zahl klicken

kann, wird man vom Reporting-Framework zu einem detaillierteren Bericht

weitergeleitet. Dies muss aber nicht zwangsläufig sein. Die detaillierteren Angaben zu

einer Kennzahl können auch am Ende eines Reports stehen, so dass die Auswahl der


Kennzahl dazu führt, dass die Anwendung automatisch auf den gleichen Bericht zeigt,

nur wird ein anderer Abschnitt ausgewählt.

Die Unterstützung der Sub-Reports(Verschachtelung) ist wichtig, da man dadurch in

einer Tabelle noch Unter-Tabellen erstellen kann, die die ausgewählten Ergebnisse,

weiter aufteilen und verdeutlichen.

Die Aggregationen und Gruppierung in den Berichten sind sehr wichtig, damit kann

man Gesamtergebnisse erzeugen und anzeigen lassen. Durch Aggregationen in den

Berichten kann die Datenbank entlastet werden.

Die Preview Funktionalität eines Berichtes ist bei der Gestaltung wichtig, damit kann

die Voransicht des fertigen Berichts dargestellt werden.

Die beiden Funktionalitäten Scheduler für Reportgenerierung und E-Mail Bursting

sind in einer Serverumgebung und in einem Unternehmen wichtig. Durch den Scheduler

besteht die Möglichkeit, die Berichte in regelmäßigen Abständen automatisch zu

erzeugen, dadurch kann man die Erzeugung der Berichte auf einen Zeitpunkt legen, an

dem die Datenbank ausgelastet werden darf, da einige Berichte teilweise sehr komplexe

SQLs enthalten können. Die E-Mail Bursting Funktionalität bietet die Möglichkeit die

Berichte automatisch an die Benutzer in regelmäßigen Abständen über E-Mails zu

verteilen.

Die Funktionalitäten View Engine für Web-Applikation und View Engine für

Desktop-Anwendungen sind wichtig, um die Berichte dem Benutzer zu präsentieren.

Möchte man die Berichte online präsentieren, so lässt sich das durch eine Web-

Applikation umsetzten. Zu diesem Zweck ist es hilfreich, wenn ein Reporting-

Framework diese Funktionalität anbietet, da man dadurch keine eigene Anwendung

entwickeln muss. Durch die Funktionalität View Engine Applikation besteht die

Möglichkeit die Darstellung von Berichten in eine bestehende Desktop-Anwendung zu

integrieren. Reporting-Frameworks, die auf Programmiersprache Java basieren, bieten

die Möglichkeit, diese Funktionalität in eine bestehende SWING- oder SWT-

Anwendung zu integrieren.

Die pixelgenaue Report-Erstellung ist bei dem Entwurf und der Erzeugung des

Berichtes wichtig. Dadurch lassen sich die Berichte so entwerfen, dass diese in jedem

Format (PDF, HTML, EXCEL usw.) gleich aussehen.

Der Report-Entwurf aus den Web-Applikationen ist weniger wichtig, da die

Anwender, die eine Reporting-Anwendung verwenden, eine genaue Kenntnis von der

Tabellenstruktur der Datenbank besitzen müssen, um die SQLs zu entwickeln. Die


Web-Applikationen zum Entwerfen der Berichte bieten nicht die gleichen

umfangreichen Funktionalitäten wie die Desktop-Anwendungen.

5.1.2. Gewichtungen unter Kategorie Usability

Nr. Metrik Gewichtung

2.1 Endbenutzer UI-Erfahrung 75%

2.2 Zeit für Installation der erforderlichen Software, die die Open-

Source-Software voraussetzt.

0%

2.3 Zeit für die Installation und Konfiguration von der Software 25%

Tabelle 17, Übersicht: Gewichtungen von Metriken unter Kategorie Usability.

Bei der Gewichtung in der Kategorie Usability wurde das Augenmerk mehr auf das

User Interface gelegt. Das User Interface soll den Benutzer beim Entwurf der Berichte

unterstützt, damit es die gestellten Anforderungen erfüllt. Die Metrik 2.1 bekommt

dadurch die Gewichtung 75%.

Die Metrik 2.2 hat 0% bei der Gewichtung bekommen, da alle Reporting-

Anwendungen Java als erforderliche Software voraussetzen.

Die Metrik 2.3 wurde mit 25% gewichtet, da die Installation und Konfiguration der

Software nur einmal durchgeführt wird.

5.1.3. Gewichtungen unter Kategorie Documentation


3.1 Vorhandensein von verschiedenen Dokumenten. 75%

3.2 Framework für Benutzerbeiträge 25%

Tabelle 18, Übersicht: Gewichtungen von Metriken unter Kategorie Documentation.

Die Metrik 3.1 in der Kategorie Documentation wurde mit 75% gewichtet, da das

Vorhandensein der Dokumentation zu einer Anwendung die höchste Priorität hat. Wenn

es keine Dokumentation zu einer Anwendung existiert, so ist es schwierig zu ergründen,

wie man diese konfigurieren und verwenden soll. Dadurch steigt die Einarbeitungszeit.

Die Metrik 3.2 wurde mit 25% gewichtet, da diese Metrik eher zweitranging ist. Die

Tutorials können und dürfen nicht die Dokumentation ersetzen.


5.1.4. Gewichtungen unter Kategorie Quality


4.1 Anzahl der Minor Releases in den letzten 12 Monaten 15%

4.2 Anzahl der Point/Patch Releases in den letzten 12 Monaten 10%

4.3 Anzahl der offenen Fehler in den letzten 6 Monaten 15%

4.4 Anzahl der behobenen Fehler in den letzten 6 Monaten 15%

4.5 Anzahl der geöffneten P1/kritischen Fehler. 20%

4.6 Durchschnittliches Alter eines P1 Fehlers in den letzten 6

Monaten

25%

Tabelle 19, Übersicht: Gewichtungen von Metriken unter Kategorie Quality.

Die ersten Metriken von 4.1-4.4 wurden gleichmäßig gewichtet von 10%-15%. Die

wichtigsten Metriken sind 4.5 und 4.6, diese wurden mit 20% und 25% gewichtet. Die

Anzahl der kritischen Fehler und die Dauer bis diese behoben werden, zeigt wie gut die

Anwendung getestet wird und wie das Projekt mit den kritischen Fehlern umgeht.

5.1.5. Gewichtungen unter Kategorie Architecture


5.1 Gibt es irgendwelche Drittanbieter Plug-ins? 50%

5.2 Öffentliche API/ externe Dienste 30%

5.3 Ein- und Ausschalten von Funktionen durch Konfiguration 20%

Tabelle 20, Übersicht: Gewichtungen von Metriken unter Kategorie Architecture.

Die Metrik 5.1 wurde mit 50% gewichtet, da diese zeigt wie modular die Anwendung

aufgebaut ist, so dass man diese durch Plug-ins um neue Funktionalitäten erweitern

kann.

Die Metrik 5.2 wurde mit 30% gewichtet, da es bei der Integration der Anwendung

wichtig ist, diese später erweitern zu können.

Die Metrik 5.3 wurde mit 20% gewichtet, da diese Metrik tertiär ist.


5.1.6. Gewichtungen unter Kategorie Scalability


6.1 Referenz-Deployment 50%

6.2 Konzipiert für Skalierbarkeit 50%

Tabelle 21, Übersicht: Gewichtungen von Metriken unter Kategorie Scalability.

Die beiden Metriken wurden mit 50% gewichtet, da beide wichtig sind. Wenn es kein

Referenz-Deployment der Anwendung in der Praxis gibt, so kann man nicht

einschätzen, ob diese Anwendung auch in Produktion eingesetzt werden kann.

Wird eine Anwendung nicht für die Skalierbarkeit konzipiert, so kann es in der

Produktion zu Problemen (Speicherverbrauch, Prozessorauslastung) kommen, wenn

mehrere Benutzer den Zugriff auf die Anwendung haben.

5.1.7. Gewichtungen unter Kategorie Community


8.1 Durchschnittliches Volumen einer Hauptmailinglist in den

letzten 6 Monaten. 75%

8.2 Anzahl von eindeutigen Quellcode-Beitragenden in den letzten

6 Monaten. 25%

Tabelle 22, Übersicht: Gewichtungen von Metriken unter Kategorie Community.

Die Metrik 8.1 wurde mit 75% gewichtet, da diese Metrik wichtig ist. Die erste

Anlaufstelle für Probleme mit der Software ist das Forum oder eine Mailingliste. Bei

einer regen Community wird man vom Projekt-Team oder von der Community beraten,

um eine Lösung zum Problem zu finden.

Die Metrik 8.2 wurde mit 25% gewichtet, da es eher sekundär ist, wie viele

Entwickler an dem Projekt arbeiten, was aber nicht außer Acht gelassen werden darf.

Wenn an einem Projekt Unternehmen beteiligt sind, so werden mehr Entwickler für

dieses Projekt abgestellt und somit wird auch die Entwicklung des Projektes

vorangetrieben.


5.2. Bewertung der Frameworks

Nach dem BRR-Model werden in der Phase 3 die Daten gesammelt und auf die

einzelnen Metriken aus den ausgewählten Kategorien angewendet (vgl. Kapitel 3.1).

5.2.1. Bewertung in der Kategorie Functionality

BIRT Pentaho

Reporting

Jasper-

Reports

Standardfunktionalitäten

Ausgabeformate

PDF 3 3 3

HTML 3 3 3

Excel 3 3 3

Word (DOC) 2 -2 -2

Word (RTF) 2 2 2

Datenquellen

JDBC 3 3 3

Hibernate 2 2 2

Diagramme

Einbindung dynamischer Inhalte (Bilder, Texte) 3 3 3

Einbindung von Charts 3 3 3

Reporting

Templating (Schablonen) 3 3 3

Verschiedene Datenquellen innerhalb eines

Reports 3 3 3

Drill-Down-Analyse innerhalb eines Reports 2 -2 2

Internationalisierung (Zeichensatz, Währung..) 3 -3 3

Unterstützt Sub-Reports (Verschachtelung) 2 2 2


BIRT Pentaho

Reporting

Jasper-

Reports

Parametrisierte Reports 3 3 3

Aggregationen und Gruppierung 2 2 2

Zusatzfunktionalitäten

Ausgabeformate

TXT 0 1 1

PPT 1 0 0

OpenOffice (ODT) 0 0 1

XML 1 0 1

CSV 2 0 2

SVG (Scalable Vector Graphics) 1 0 1

Datenquellen

POJO/Java Beans 2 0 2

CSV 1 0 1

XML 1 1 1

Web Services 1 1 0

XML/A,MDX 0 1 1

Metadatenunterstützung 0 1 0

Reporting

Preview Funktionalität 2 2 2

Scheduler für Reportgenerierung 0 2 2

E-Mail Bursting (Verteilung) 0 2 0

View Engine für Web-Applikation 2 2 2

View Engine für Desktop-Anwendung 2 0 2


BIRT Pentaho

Reporting

Jasper-

Reports

Report-Entwurf aus Web-Applikation 0 1 0

Pixelgenaue Report-Erstellung 0 2 2

Cross-Tab Unterstützung 2 0 2

Bewertung in % 142,9% 104,8% 145,2%

Bewertung in Punkten 5 5 5

Tabelle 23, Bewertungstabelle für die Kategorie Functionality.

Betrachtet man die Ergebnisse in der Tabelle 23, sieht man, dass bei der prozentualen

Bewertung JasperReports und BIRT deutlich vorne liegen, da die beiden Frameworks

die meisten Funktionalitäten unterstützen.

Die Drill-Down Analyse und die Internationalisierung wird von Pentaho Reporting

nicht unterstütz, da diese Funktionalitäten von Pentaho in die eigene BI-Suite

ausgelagert wurden, deswegen bekommt Pentaho hier Abzüge. JasperReports und BIRT

decken die Standardfunktionalitäten komplett ab und bekommen Zusatzpunkte bei den

Zusatzfunktionalitäten. Im Gegensatz zu Pentaho Reporting unterstützen BIRT und

JasperReports nahezu alle Ausgabeformate. Bei der Unterstützung der Datenquellen

liegen alle Reporting-Frameworks gleich auf.

Die meisten zusätzlichen Reporting-Funktionalitäten werden durch Pentaho

Reporting und JasperReports unterstützt. BIRT unterstütz solche Funktionalitäten, wie

Scheduler für Reportgenerierung, E-Mail Bursting zur Verteilung und Reportentwurf

aus Web-Applikation in der Open-Source Version nicht. Gegen einen Aufpreis bietet

Actuate in Verbindung mit der kommerziellen Version von BIRT einen Reporting-

Server an, der diese und noch andere Funktionalitäten unterstützt.

5.2.2. Bewertung in der Kategorie Usability

Nr. Metrik BIRT Pentaho

Reporting

Jasper-

Reports

2.1 Endbenutzer UI-Erfahrung 2,25 2,25 2,25

2.2 Zeit für Installation der erforderlichen

Software, die die Open-Source-Software

voraussetzt.

0 0 0



Reporting

Jasper-

Reports

2.3 Zeit für die Installation und Konfiguration

von der Software

1,25 1,25 1,25

Summe 3,5 3,5 3,5

Tabelle 24, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Usability.

In der Metrik 2.1 bekommen alle Designer-Oberflächen der Frameworks eine

ungewichtete Bewertung von 3 Punkten und gewichtet von 2.25, da alle komplex

aufgebaut sind und ohne Handbuch oder Tutorials nur zum Teil benutzbar sind.

Für die Installation von BIRT werden durch das BIRT-Projekt mehrere Pakete zur

Verfügung gestellt: All-in-One, Framework, RCP Designer und die Runtime. Für die

Evaluierung wurde das All-In-One-Paket verwendet. Nach dem Download des Pakets,

muss man dieses nur entpacken. Um die Anwendung zu starten, muss man in den

Unterordner Eclipse wechseln und die Datei eclipse.exe ausführen. Die Dauer der

Installation hängt von der Geschwindigkeit des Rechners ab, wie schnell dieser das

Paket entpackt. Die Installation auf dem Benchmarksystem dauerte unter einer Minute.

BIRT liefert keine Datenbanktreiber, diese muss man gesondert herunterladen und beim

Auswählen der Datenbank in der Anwendung auswählen.

Pentaho stellt mehrere Downloads zur Verfügung. Es ist möglich die Server-

Anwendungen auf verschiedene Weise zu installieren. Möchte man die Anwendungen

unter Windows verwenden, bietet Pentaho einen Windows-Installer an. Für andere

Betriebssysteme wird unter anderem ein Binary-Installer angeboten. Möchte man

keinen Installer verwenden, ist es möglich die Server-Anwendungen als gepacktes Paket

herunterzuladen. Der Designer wird als gepacktes Packet angeboten, den man einfach

nur entpacken muss. Für die Evaluierung wurde der Windows-Installer für Pentaho-

Reporting ausgewählt. Dieser installiert einen Reporting-Server und die grafische

Oberfläche zum Entwerfen der Berichte. Installiert man nur den Designer, so erfolgt die

Installation unter einer Minute, da man das angebotene Paket nur entpacken muss. Die

Installation von Pentaho-Reporting dauerte etwa vier Minuten. Im Gegensatz zu BIRT

und JasperReports liefert Pentaho eine Vielzahl von Datenbanktreibern mit: HSQL,

MySQL, Sybase, Oracle, DB2, PostgreeSQL u.a.

JasperSoft bietet auch mehrere Downloads an und stellt, wie Pentaho, einen

Windows-Installer zur Verfügung. Für Linux-Betriebssysteme stellt JasperSoft auch


einen Binary-Installer zur Verfügung. Es besteht auch die Möglichkeit die

Anwendungen als gepacktes Paket herunterzuladen. Im Gegensatz zu Pentaho und

BIRT wird der Designer als gepacktes Paket und als Windows-Installer angeboten. Für

die Evaluierung wurde der Server als Windows-Installer heruntergeladen. Während der

Installation wird vom Installer auch der Designer für die Berichte mit installiert. Bei der

Installation ist es aufgefallen, dass JasperSoft mit dem Designer die JDBC-

Datenbanktreiber für HSQL- und MySQL-Datenbank mit installiert. Positiv war auch,

dass der Installer eine Auswahlmöglichkeit anbietet. Beispielsweise kann man

auswählen, ob ein Tomcat-Server installiert oder ein vorhandener Server benutzt

werden soll. Als nächstes wird angeboten, eine vorhandene Datenbank zu verwenden

oder eine neue MySQL-Datenbank zu installieren. Die Installation dauerte etwa fünf

Minuten, dabei wurde ein Datenbankserver, Tomcat und IReport installiert und mit

Beispieldaten konfiguriert.

Die benötige Zeit für die Installation betrug bei allen Frameworks unter fünf

Minuten, deswegen bekommen alle Frameworks eine ungewichtete Bewertung von 5

und gewichtet 1,25.

5.2.3. Bewertung in der Kategorie Documentation


Reporting

Jasper-

Reports

3.1 Vorhandensein von verschiedenen

Dokumenten. 3,75 3 3,75

3.2 Framework für Benutzerbeiträge 1,25 0,75 0,75

Summe 5 3,75 4,5

Tabelle 25, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Documentation.

Bei der Metrik 3.1 hat Pentaho Reporting am schlechtesten abgeschnitten, da die

Dokumentation, die durch das Projekt angeboten wird, unvollständig, veraltet und

teilweise fehlerbehaftet ist. Deswegen bekommt hier Pentaho als einziges Framework

eine ungewichtete Bewertung von 4 Punkten und gewichtet 3.

Die höchste Punktzahl bei der Metrik 3.2 hat BIRT mit gewichteten 1,25 Punkten

erreicht. Bevor die Tutorials auf der Seite veröffentlicht werden, werden diese durch die

Moderatoren gelesen und auf Richtigkeit überprüft. Bei den beiden anderen

Frameworks steht das Angebot die Tutorials zu veröffentlichen zwar zur Verfügung, die


Tutorials werden aber nicht auf die Richtigkeit überprüft, was an den Kommentaren

unterhalb der Tutorials erkennbar ist.

In der Kategorie Documentation hat BIRT die höchste Punktzahl 5 Punkten. Das

schlechteste Ergebnis hat Pentaho Reporting mit 3,75 Punkten. Die schlechte

Bewertung kommt durch die mangelnde Qualität und Unvollständigkeit in der

Dokumentation sowie bei den Tutorials.

5.2.4. Bewertung in der Kategorie Quality


Reporting

Jasper-

Reports

4.1 Anzahl der Minor-Releases in den letzten

12 Monaten 0,75 0,75 0,75

4.2 Anzahl der Point/Patch Releases in den

letzten 12 Monaten 0,5 0,3 0,3

4.3 Anzahl der offenen Fehler in den letzten 6

Monaten 0,15 0,6 0,6

4.4 Anzahl der behobenen Fehler in den letzten

6 Monaten 0,75 0,75 0,6

4.5 Anzahl der geöffneten P1/kritischen

Fehler. 0,6 0,4 0,6

4.6 Durchschnittliches Alter eines P1 Fehlers

in den letzten 6 Monaten 1,25 1,25 1,25

Summe 4 4,05 4,1

Tabelle 26, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Quality.

Alle drei Frameworks hatten in den letzten zwölf Monaten zwei Minor-Releases,

dadurch ergibt sich bei der Metrik 4.1 ein gewichteter Wert von 0,75.

Bei der Metrik 4.2 hatte JasperReports fünf Patch-Releases und Pentaho Reporting

sechs. Dadurch ergibt sich bei beiden ein ungewichteter Wert von drei und gewichtet

jeweils 0,3. BIRT hatte nur drei Patch-Releases, dadurch bekommt BIRT einen

ungewichteten Wert von 5 Punkten und gewichtet 0,5.

Bei der Metrik 4.3 hat BIRT schlechteste Bewertung, mit einem ungewichteten Wert

von 1 und gewichtetem Wert von 0,15. In den letzten sechs Monaten wurden 1630


Fehler gemeldet. Bei dem Modul von Pentaho Reporting wurden nur 58 Fehler

gemeldet und bei JasperReports 50 Fehler.

BIRT und Pentaho Reporting haben bei der Metrik 4.4 die besten Ergebnisse, da bei

beiden Projekten über 75% der gemeldeten Fehler behoben wurden, bei JasperReports

waren es nur 66%.

Bei der Anzahl der kritischen Fehler hatte Pentaho Reporting die meisten. In den

letzten sechs Monaten wurden da 12 kritische Fehler gemeldet, was zu einer

ungewichteten Bewertung von 2 Punkten und gewichtet 0,4 Punkte führte.

JasperReports und BIRT hatten unter 9 kritische Fehler, was bei beiden zu einer

ungewichteten Bewertung von 3 und gewichtet 0,6 führte.

Der Umgang mit den kritischen Fehlern ist bei allen drei Projekten sehr positiv. Im

Durchschnitt wurden die kritischen Fehler innerhalb einer Woche behoben, was zu einer

ungewichteten Bewertung von 5 und einer gewichteten 1,25 führte.

Bei der Qualität hat JasperReports das beste Ergebnis mit 4,1 Punkten. Das

schlechteste Ergebnis hatte BIRT. Bei BIRT wurde das Ergebnis durch die hohe Anzahl

der Fehler beeinflusst, weil das Projekt an sich um einiges größer ist als das von

anderen getesteten Frameworks.

5.2.5. Bewertung in der Kategorie Architecture


Reporting

Jasper-

Reports

5.1 Gibt es irgendwelche Drittanbieter Plug-

ins? 2,5 0,5 2

5.2 Öffentliche API/ externe Dienste 1,5 0,9 0,9

5.3 Ein- und Ausschalten von Funktionen

durch Konfiguration 1 1 1

Summe 5 2,4 3,9

Tabelle 27, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Architecture.

BIRT bekommt bei der Metrik 5.1 die Höchstpunktzahl, da BIRT selbst komplett aus

Plug-ins besteht und für die Drittanbieter mehrere Erweiterungs-Punkte anbietet. BIRT

basiert auf der Eclipse-Platform und für diese existieren mehr als 1000 Plug-Ins.

JasperReports bietet Erweiterungsmöglichkeiten in dem Report Designer durch Plug-

ins. Es werden 6 Plug-ins mitgeliefert, deswegen bekommt JasperReports eine


ungewichtete Bewertung von 4 Punkten und gewichtet von 2 Punkten. Im Gegensatz zu

anderen Projekten, die Pentaho betreut und führt, besitzt Pentaho Reporting keine Plug-

In Erweiterungsmöglichkeiten. Der neue Ansatz von Pentaho ist es auf die Eclipse

Platform zu setzen. Leider gibt es im Design Studio bis jetzt keinen Report-Designer,

deswegen wird dieser bei der Metrik 5.1 nicht beachtet. Pentaho Reporting bekommt

nur 1 ungewichteten Punkt und 0,5 gewichtete Punkte.

BIRT bietet eine API und Extension Points, über die man das Framework nicht nur

im Designer sondern auch in der Runtime um eigene Elemente und Zusätze erweitern

kann. Dadurch bekommt BIRT bei der Metrik 5.2 eine ungewichtete Bewertung von 5

Punkten und gewichtet 1,5. Die beiden anderen Frameworks bieten die Möglichkeit,

diese durch die API zu erweitern.

Bei allen drei Frameworks ist es möglich die Funktionalitäten während der Laufzeit

ein- bzw. auszuschalten. Jeder der drei Frameworks bekommt bei der Metrik 5.3

ungewichtete Bewertung von 5 Punkten und gewichtet 1.

Bei der Architektur bekommt BIRT 5 Punkte, da dieser bei der Erweiterung und

Plug-ins die besten Ergebnisse liefert. Pentaho Reporting hat das schlechteste Ergebnis

mit 2,4 Punkten, da es keine Erweiterungen durch die Plug-Ins anbietet.

5.2.6. Bewertung in der Kategorie Scalability


Reporting

Jasper-

Reports

6.1 Referenz-Deployment 2,5 2,5 2,5

6.2 Konzipiert für Skalierbarkeit 2,5 2,5 2,5

Summe 5 5 5

Tabelle 28, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Scalability.

Untersucht man die Seiten der Unternehmen, die die Projekte führen, so kann man

erkennen, dass es eine Vielzahl von Referenz-Deployments existiert. Dadurch bekommt

jedes der Frameworks die höchste Bewertung.

Alle drei Frameworks haben bei der Metrik 6.2 sehr gute Ergebnisse, da alle für die

Skalierbarkeit konzipiert wurden.


5.2.7. Bewertung in der Kategorie Community


Reporting

Jasper-

Reports

8.1 Durchschnittliches Volumen einer

Hauptmailinglist in den letzten 6 Monaten. 3,75 3,75 3,75

8.2 Anzahl von eindeutigen Quellcode-

Beitragenden in den letzten 6 Monaten. 1,25 0,75 0,75

Summe 5 4,5 4,5

Tabelle 29, Übersicht: gewichtete Bewertung der Metriken aus der Kategorie Community.

Die Community aller drei Frameworks ist sehr lebhaft, dies kann man an der Anzahl der

Beiträge in den Foren und den Mailinglisten erkennen. Alle drei Frameworks

bekommen ungewichtet eine Bewertung von 5 Punkten und gewichtet 3,75 bei der

Metrik 8.1.

Bei der Metrik 8.2 bekommt BIRT das beste Ergebnis von 5 Punkten ungewichtet

und 1,25 gewichtet. BIRT wird außer von der Community noch von 4 weiteren

Unternehmen wie Actuate, Innoent Solutions, IBM und InetSoft weiterentwickelt und

vorangetrieben. Dadurch ergibt sich die Entwickleranzahl von über 50 Leuten. Die

beiden anderen Projekte bekommen 0,75 gewichtete Punkte, da bei den beiden nur 10-

19 Entwickler an den Projekten arbeiten.

In der Kategorie Community bekommt BIRT die höchste Bewertung von 5 Punkten.

Pentaho Reporting und JasperReports bekommen jeweils 4,5 Punkten. Alle drei

Projekte haben eine lebhafte Community, BIRT konnte durch die Anzahl der

Entwickler die höchste Punktzahl erreichen.

5.2.8. Ergebnisse der BRR-Bewertung

Nr. Kategorie Gewichtung BIRT Pentaho

Reporting

Jasper-

Reports

1 Functionality 25% 1,25 1,25 1,25

2 Usability 20% 0,70 0,70 0,70

3 Documentation 15% 0,75 0,56 0,68

4 Quality 15% 0,60 0,61 0,62


Nr. Kategorie Gewichtung BIRT Pentaho

Reporting

Jasper-

Reports

5 Architecture 10% 0,50 0,24 0,39

6 Scalability 10% 0,50 0,50 0,50

7 Community 5% 0,25 0,23 0,23

BRR-Punktezahl 4,55 4,085 4,355

Tabelle 30, Übersicht: Ergebnisse der BRR-Bewertung.

Die Ergebnisse beim BRR-Test der drei Frameworks unterscheiden sich nur im

Nachkommastellenbereich. BIRT bekommt die beste BRR-Punktzahl durch die

höchsten Bewertungen in den Kategorien Documentation und Architecture.

5.2.9. Zusatzbewertung der Benutzeroberfläche

Bei der Bewertung der Benutzeroberfläche in dem BRR-Model ist es aufgefallen, dass

die Metrik 2.1 in der Kategorie Usability nicht ausreichend ist, um eine Oberfläche zu

bewerten. Es wird nur eine allgemeine Aussage über die Benutzung getroffen. Da aber

die Report-Designer sehr komplex sind, müssen zusätzliche Metriken definiert werden.

Die untenstehende Tabelle listet die zusätzlichen Metriken auf. Abbildungen der drei

getesteten Benutzeroberflächen befinden sich im Anhang C.

Metrik: Z1 Platzierung der Elemente/Buttons auf der Benutzeroberfläche.

Beschreibung: Mit dieser Metrik wird überprüft: wie gut und übersichtlich die

Elemente auf der Benutzeroberfläche positioniert sind.

Metrik: Z2 Unterstützung durch die Benutzeroberfläche.

Beschreibung: Wie gut wird der Benutzer durch die Benutzeroberfläche unterstützt?

Dazu gibt es einige Mechanismen, wie z.B. Schnellhilfe, Tooltipps.

Metrik: Z3 Wizard Unterstützung.

Beschreibung: Existiert ein Wizard zum Entwerfen von Berichten? Wie schnell und

einfach kann ein Bericht durch den Wizard entworfen werden?

Metrik: Z4 Entwurf der komplexen Berichte.

Beschreibung: Wie einfach oder schwer ist es mit dem vorliegenden Designer einen

komplexen Bericht zu entwerfen. Zu den komplexen Berichten


zählen zum Beispiel die Unter-Berichte, Berichte mit mehreren

Datenbankverbindungen, Berichte mit mehreren Tabellen.

Metrik: Z5 Qualität der Fehlermeldungen.

Beschreibung: Sind die Fehlermeldungen für einen Benutzer verständlich, die

ausgegeben werden?

Metrik: Z6 Entwurf und Konfiguration von Diagrammen.

Beschreibung: Besteht eine Unterstützung durch die Benutzeroberfläche, um ein

Diagramm zu entwerfen? Sind die Dialoge zum Entwerfen der

Diagramme übersichtlich und verständlich?

Metrik: Z7 Entwurf und Konfiguration von Aggregationen und

Gruppierungen.

Beschreibung: Wie einfach kann eine Aggregation oder Gruppierung durch die

Benutzeroberfläche angelegt werden?

Metrik: Z8 Entwurf und Konfiguration von Tabellen.

Beschreibung: Wird der Benutzer durch die Oberfläche unterstütz beim entwerfen

der Tabellen? Wie übersichtlich und einfach wird das Entwerfen von

der Oberfläche angeboten?

Metrik: Z10 Mitgelieferte Hilfe.

Beschreibung: Wird eine Hilfe mitgeliefert?

Metrik: Z11 Stabilität der Anwendung.

Beschreibung: Wie stabil läuft die Anwendung beim entwerfen von Berichten?

Metrik: Z12 Preview-Funktionalitäten.

Beschreibung: Wie komfortabel ist die Vorschau-Funktionalität und in welchen

Formaten lässt sich die Vorschau erstellen?

Tabelle 31, Metriken zum Bewerten von der Benutzeroberfläche.

Die Bewertung bei allen zusätzlichen Metriken erfolgt nach dem Punktesystem von

BRR, d.h. es werden Punkte 1 bis 5 vergeben, dabei ist 1 der schlechteste Wert und 5

der beste. Da alle zusätzlichen Metriken wichtig sind, wird keine Gewichtung

durchgeführt, sondern ein arithmetischer Durchschnitt gebildet.


5.2.9.1. Bewertung der Metrik Z1


Reporting

Jasper-

Reports

Z1 Platzierung der Elemente/Buttons auf der

Benutzeroberfläche. 4 5 4

Tabelle 32, Bewertung der Metrik Z1.

Die Oberflächen von Pentaho- und BIRT-Report-Designer sind übersichtlich aufgebaut

und alle Elemente, die zum Entwerfen der Berichte benötig werden beschriftet.

Dagegen ist die Oberfläche von IReport von JasperReports etwas unübersichtlich

aufgebaut, die Elemente zum Entwerfen der Berichte befinden sich in der Symbolleiste

als Icons. Um zu erfahren welche Funktionalität hinter dem Icon steht, muss man über

das Icon fahren damit der Tooltip dazu angezeigt wird. Pentaho und Jasper bieten in der

Symbolleiste eine übersichtliche Konfiguration für die Schriftarten und Schriftgröße an,

was bei BIRT fehlt.



Reporting

Jasper-

Reports

Z2 Unterstützung durch die



Beim Entwerfen der Berichte ist es aufgefallen, dass BIRT nicht nur durch die

Tooltipps einen Benutzer unterstützt, sondern zusätzlich durch eine Schnellhilfe, in der

beschrieben wird, wofür die einzelnen Dialogfelder stehen, und was man dort eingeben

soll. Die beiden anderen Anwendungen Pentaho Report Designer und IReport

unterstützen den Benutzer nur durch die Tooltipps.



Reporting

Jasper-

Reports

Z3 Wizard Unterstützung. 3 5 5



Alle drei Anwendungen bieten einen Wizard an, um einen Bericht zu entwerfen. Der

schlichteste Wizard war von BIRT, dort konnte man lediglich die Datei benennen und

ein Template auswählen, danach wird man auf ein Tutorial in der Schnellhilfe

verweisen, die automatisch die lokale Hilfe zu BIRT startet. Pentaho Report Designer

und IReport bieten aufwendige Wizards, mit deren Hilfe ein kompletter Bericht

entworfen werden kann. Dazu werden die SQL-Anweisungen abgefragt, die Spalten, die

man in den Bericht aufnehmen möchte, und das Template.



Reporting

Jasper-

Reports

Z4 Entwurf der komplexen Berichte. 5 3 3


Beim Entwerfen von Berichten mit mehreren Tabellen, wobei mehrere SQL-Abfragen

verwendet wurden, ist es aufgefallen, dass nur zwei der getesteten Designer mehrere

SQL-Abfragen verwalten konnten. Dazu gehören BIRT und Pentaho Reporting. Die

Platzierung von mehreren Tabellen war bei Pentaho Reporting und IReport nicht

möglich, weil das Berichtslayout dies nicht zulässt, da auf jedem Bericht nur eine

Tabelle platziert werden kann. Dieses Problem lässt sich aber durch die Unter-Berichte

umgehen. Bei BIRT hingegen lassen sich mehrere Tabellen auf einem Bericht direkt

platzieren oder auch durch die Unter-Berichte lösen. Pentaho Reporting und IReport

machen für neue Unter-Berichte ein neues Fenster auf, was in einigen Fällen zu einem

Synchronisationsproblem führte, z. B. der Unter-Bericht erkannte nicht die übergebenen

Parameter, bis man diesen neue geladen hat.



Reporting

Jasper-

Reports

Z5 Qualität der Fehlermeldungen. 5 4 3


Alle drei bieten einen gesonderten Bereich auf der Oberfläche, in dem die

Fehlermeldungen angezeigt werden. Die Fehlermeldungen, die in diesem Bereich

angezeigt wurden, waren verständlich. Wenn man bei BIRT und Pentaho auf die


Fehlermeldung klickt, wird automatisch das Element ausgewählt, welches diese

Fehlermeldung verursacht hat. Die Fehlermeldungen, die außerhalb des gesonderten

Bereichs angezeigt wurden, waren bei Pentaho und IReport nicht ganz verständlich. Bei

IReport wurde bei der Vorschau eine missverständliche Fehlermeldung, die mit dem

Diagramm zusammenhing, ausgegeben. Daraufhin wurde man auf die Konsole

verwiesen, um die Java-Exception zu untersuchen. Mit der ausgegebenen

Fehlermeldung kann ein einfacher Benutzer, der keine oder wenige Java-Skills hat,

nichts anfangen. Bei Pentaho gab es Fehlermeldungen beim Export von Unter-

Berichten. Diese Fehlermeldung wurde genau wie bei IReport als Java-Exception

ausgegeben.



Reporting

Jasper-

Reports

Z6 Entwurf und Konfiguration von

Diagrammen. 5 4 4


Alle drei Designer bieten einen Wizard zum Entwerfen von Diagrammen an. Das

Entwerfen der Diagramme unter Pentaho Report Designer und IReport erwies sich als

umständlich, da es keine Vorschau auf das Diagramm gibt und man durch die vielen

Einstellungsmöglichkeiten überfordert wird. Bei der Zuweisung von Spalten muss man

sehr viel ausprobieren, um das gewünschte Ergebnis zu bekommen, da es nicht ganz

klar ist, zu welcher Einstellung welche Spalte angegeben werden soll. BIRT macht es

ganz vorbildlich. Es wird eine Vorschau auf das fertige Diagramm angezeigt. In der

Vorschau ist direkt zu sehen, welche Werte an welcher Position eingegeben werden

müssen.



Reporting

Jasper-

Reports


Aggregationen und Gruppierungen. 5 4 4



Bei allen drei Designern funktionierte die Gruppierungsfunktion sehr gut. Die

Aggregation bei Pentaho Report Designer und IReport ist kompliziert aufgebaut. Die

Konfigurationsmöglichkeiten sind nicht eindeutig beschrieben. Um zu einem

gewünschten Ergebnis zu kommen, muss man die einzelnen

Konfigurationseinstellungen ausprobieren.



Reporting

Jasper-

Reports

Z8 Entwurf und Konfiguration von Tabellen. 4 3 3


Bedingt durch das Layout des Berichtes in Pentaho Report Designer und IReport

beschränkt sich der Entwurf der Tabellen auf Platzierung von einzelnen Spalten. Durch

dieses Vorgehen ergibt sich ein Problem, wenn man eine Spalte dynamisch gestalten

möchte. Die Überschrift wird nicht automatisch auf die Spaltenbreite der Daten

vergrößert. Um die einzelnen Spalten zu konfigurieren, wird eine Liste von

Einstellungen angeboten. Durch die Vielzahl von den Einstellungen wird die Liste

unübersichtlich, da man diese nach bestimmten werten absuchen muss. BIRT arbeitet

mit richtigen Tabellen, in die man die Spalten mit der Maus ziehen kann, dadurch

werden auch die Beschriftungen automatisch übernommen. Vergrößert sich die

Datenbreite, so wird auch die Spaltenbreite bei der Überschrift vergrößert. Die

einzelnen Konfigurationen werden über einen Property Editor durchgeführt, der von

BIRT angeboten wird. Im Gegensatz zu anderen Designern sind die Einstellungen in

verschiedene Bereiche aufgeteilt, was übersichtlicher und verständlicher ist.



Reporting

Jasper-

Reports

Z9 Mitgelieferte Hilfe. 5 1 1


Pentaho Report Designer und IReport liefern mit ihren Designern keine Dokumentation

mit und verweisen aus der Oberfläche auf die eigene Webseiten, wo diese

heruntergeladen werden kann. BIRT liefert eine umfangreiche Dokumentation, die in


die Oberfläche integriert ist. Zu der Dokumentation von BIRT gehören: Tutorials,

Tutorials für Entwickler, Buch in online Form, Dokumentation zu der Oberfläche.



Reporting

Jasper-

Reports

Z10 Stabilität der Anwendung. 5 3 3


Pentaho Report Designer und Jasper hatten umfangreiche Speicherprobleme beim

entwerfen von Unter-Berichten. Dabei sind diese mehrmals abgestürzt. BIRT hingegen

lief stabil.



Reporting

Jasper-

Reports

Z11 Preview-Funktionalitäten. 5 5 3


BIRT und Pentaho Reporting bieten die besten Vorschaufunktionalitäten an. Ein Bericht

lässt sich in verschiedenen Formaten betrachten, dazu wird die entsprechende

Anwendung für das ausgewählte Format aufgerufen. JasperReports unterstützt nur die

Java-Preview-Funkionalität. Möchte man einen Bericht in PDF oder HTML betrachten,

dann muss man in das Verzeichnis wechseln, in dem dieses erzeugt wurde, und manuell

öffnen.

5.2.10. Ergebnisse der Zusatzbewertung der Benutzeroberfläche


Reporting

Jasper-

Reports

Z1 Platzierung der Elemente/Buttons auf der


Z2 Unterstützung durch die


Z3 Wizard Unterstützung. 3 5 5

Z4 Entwurf der komplexen Berichte. 5 3 3



Reporting

Jasper-

Reports

Z5 Qualität der Fehlermeldungen. 5 4 3


Diagrammen. 5 4 4


Aggregationen und Gruppierungen. 5 4 4

Z8 Entwurf und Konfiguration von Tabellen. 4 3 3

Z9 Mitgelieferte Hilfe. 5 1 1

Z10 Stabilität der Anwendung. 5 3 3

Z11 Preview-Funktionalitäten. 5 5 3

Ergebnis Benutzeroberfläche 4,64 3,64 3,27

Tabelle 43, Übersicht: Ergebnisse der Zusatzbewertung.

Alle drei Designer haben ihre Vor- und Nachteile, aber am komfortabelsten ist der

Designer von BIRT. Im Gegensatz zu den anderen getesteten Designern ist BIRT mit

Abstand der mächtigste, aber auch vom Datenumfang am größten. Während Pentaho

Report Designer und IReport installiert knapp 50 MB haben, hat BIRT, je nach Version,

90-130 MB.

5.3. Performance und Speicherauslastung

Für jedes ausgewählte Framework wurden die Performance und die Speicherauslastung

durch die entwickelte Benchmarkanwendung getestet. Um genauere Werte zu erhalten,

wurde die Anwendung für jedes einzelne Framework und jeden Bericht neu gestartet.

Um eine realistische Umgebung zu simulieren, wurde ein Random-Test bei der

Speicherauslastung und Performance durchgeführt. Bei diesem Test werden die

Berichte zufällig ausgewählt und generiert.

5.3.1. Testumgebung

Die Benchmark-Tests werden auf zwei separaten Systemen durchgeführt. Das erste

System dient dabei der Ausführung von der Testanwendung. Auf dem zweiten System

wird die Datenbank Oracle 10 eingesetzt. Als Datenbasis dienen dabei die Daten eines

großen Anwenderunternehmens der Software „smartidee“.


Komponenten Benchmark-System Datenbank-System

Prozessor Intel Core 2 Duo 1,83 GHz Pentium 3 GHz

Arbeitsspeicher in

Gigabyte 3 1

Betriebssystem Windows XP Professional Windows XP Professional

Netzwerkbandbreite

in Megabit 1000 100

Java Version 1.6u7

JDBC Version 10.1.0.5.0

Tabelle 44, Übersicht der Test-Systeme.

5.3.2. Ergebnisse JasperReports

Bericht/Format Erstellungszeit Speicherauslastung Dateigröße

Bericht1

HTML 642 ms 3233 KB 1411 KB

XLS 563 ms 3589 KB 132 KB

PDF 756 ms 3237 KB 82 KB

Bericht2

HTML 620 ms 3738 KB 1400 KB

XLS 563 ms 5367 KB 152 KB

PDF 757 ms 4716 KB 83 KB

Bericht3

HTML 191 ms 4634 KB 12 KB

XLS 200 ms 3960 KB 29 KB

PDF 82 ms 5529 KB 114 KB

Bericht4

HTML 609 ms 3445 KB 1412 KB

XLS 581 ms 3163 KB 155 KB



PDF 762 ms 3804 KB 83 KB

Bericht5

HTML 845 ms 3207 KB 1975 KB

XLS 766 ms 4054 KB 232 KB

PDF 1036 ms 3679 KB 116 KB

Bericht6

HTML 1286 ms 5540 KB 1118 KB

XLS 1439 ms 10427 KB 605 KB

PDF 1540 ms 6791 KB 70 KB

Random-Test

HTML 727 ms 6897 KB -

XLS 682 ms 9904 KB -

PDF 863 ms 7860 KB -

Tabelle 45, Performance und Speicherauslastung von JasperReports.

5.3.3. Ergebnisse Birt


Bericht1

HTML 458 ms 24275 KB 758 KB

XLS 556 ms 31461 KB 389 KB

PDF 731 ms 17682 KB 54 KB

Bericht2

HTML 466 ms 25953 KB 763 KB

XLS 570 ms 32269 KB 395 KB

PDF 753 ms 17313 KB 55 KB

Bericht3




XLS37

308/359 ms 19398/22006 KB 7/95 KB

PDF 852 ms 23986 KB 106 KB

Bericht4

HTML 471 ms 16217 KB 759 KB

XLS 553 ms 26113 KB 390 KB

PDF 721 ms 18736 KB 55 KB

Bericht5

HTML 515 ms 24564 KB 941 KB

XLS 690 ms 33230 KB 633 KB

PDF 991 ms 17932 KB 98 KB

Bericht6

HTML 613 ms 22180 KB 552 KB

XLS 1007 ms 32824 KB 614 KB

PDF 1150 ms 18282 KB 60 KB

Random-Test

HTML 479 ms 26148 KB -

XLS 612 ms 36711 KB -

PDF 849 ms 24816 KB -

Tabelle 46, Performance und Speicherauslastung von BIRT.

37

Die Export-Funktionalität für Excel, die BIRT mitliefert, unterstützt kein Export von Bildern und

Diagrammen. Diese Funktionalität lässt sich aber durch eine Zusatzerweiterung nachrüsten. Das zweite

Ergebnis wurde unter Verwendung der Zusatzerweiterung ermittelt.


5.3.4. Ergebnisse Pentaho Reporting


Bericht1

HTML 1198 ms 11947 KB 320 KB

XLS 1166 ms 6825 KB 87 KB

PDF 1385 ms 10348 KB 65 KB

Bericht2

HTML 1299 ms 6349 KB 323 KB

XLS 1205 ms 6591 KB 103 KB

PDF 1216 ms 10394 KB 64 KB

Bericht3


XLS 347 ms 10393 KB 97 KB

PDF 438 ms 13563 KB 71 KB

Bericht4

HTML 1269 ms 9984 KB 321 KB

XLS 1198 ms 6500 KB 98 KB

PDF 1396 ms 7837 KB 65 KB

Bericht5

HTML 1610 ms 8287 KB 465 KB

XLS 1428 ms 7569 KB 113 KB

PDF 1588 ms 10417 KB 98 KB

Bericht6

HTML 2822 ms 8069 KB 302 KB

XLS 2623 ms 12499 KB 67 KB

PDF 2869 ms 6737 KB 99 KB



Random-Test

HTML 1259 ms 12711 KB -

XLS 1230 ms 10496 KB -

PDF 1321 ms 15145 KB -

Tabelle 47, Performance und Speicherauslastung von Pentaho Reporting.38

5.3.5. Gegenüberstellung der Performance und Speicherauslastung

Die untenstehende Tabelle zeigt die Gegenüberstellung von Performanceergebnissen.

Die höchste Performance wurde durch eine farbliche Hervorhebung gekennzeichnet.

Bericht/Format BIRT Pentaho Reporting Jasper-Reports

Bericht1

HTML 458 ms 1198 ms 642 ms

XLS 556 ms 1166 ms 563 ms

PDF 731 ms 1385 ms 756 ms

Bericht2

HTML 466 ms 1299 ms 620 ms

XLS 570 ms 1205 ms 563 ms

PDF 753 ms 1216 ms 757 ms

Bericht3

HTML 319 ms 454 ms 191 ms

XLS 308/359 ms 347 ms 200 ms

PDF 852 ms 438 ms 82 ms

Bericht4

HTML 471 ms 1269 ms 609 ms

38

Von Pentaho Report Designer erzeugten Berichte lassen sich nicht einfach so außerhalb des Pentaho

Servers verwenden. Die XML-Report-Dateien müssen manuell durch einen Texteditor angepasst werden,

um dort die SQL-Anweisung und die Datenbank einzutragen.



XLS 553 ms 1198 ms 581 ms

PDF 721 ms 1396 ms 762 ms

Bericht5

HTML 515 ms 1610 ms 845 ms

XLS 690 ms 1428 ms 766 ms

PDF 991 ms 1588 ms 1036 ms

Bericht6

HTML 613 ms 2822 ms 1286 ms

XLS 1007 ms 2623 ms 1439 ms

PDF 1150 ms 2869 ms 1540 ms

Random-Test

HTML 479 ms 1259 ms 727 ms

XLS 612 ms 1230 ms 682 ms

PDF 849 ms 1321 ms 863 ms

Tabelle 48, Gegenüberstellung von Performanceergebnissen.

BIRT liefert die besten Performanceergebnisse. Wobei Bericht 3 von JasperReports am

schnellsten generiert wurde. Alle drei Reporting-Frameworks haben

Performanceeinbußen beim Erstellen von Unter-Berichten, da hierbei zwei SQL-

Anweisungen abgesetzt werden, wobei die zweite SQL-Anweisung durch eine

Parameterübergabe gesteuert wird. Die schlechtesten Ergebnisse liefert Pentaho

Reporting. Dies kann an der Implementierung des Datenbankmoduls liegen.

Im Gesamtergebnis des Performancetests hat BIRT die besten Ergebnisse. Die

schlechtesten Ergebnisse hat Pentaho Reporting, da Pentaho Reporting bis zu zweimal

langsamer ist als die anderen getesteten Frameworks.

Die nachfolgende Tabelle zeigt die Gegenüberstellung von

Speicherauslastungsergebnissen, die besten Ergebnisse werden wie in der oberen

Tabelle durch farbliche Hervorhebung gekennzeichnet.



Bericht1

HTML 24275 KB 11947 KB 3233 KB

XLS 31461 KB 6825 KB 3589 KB

PDF 17682 KB 10348 KB 3237 KB

Bericht2

HTML 25953 KB 6349 KB 3738 KB

XLS 32269 KB 6591 KB 5367 KB

PDF 17313 KB 10394 KB 4716 KB

Bericht3

HTML 19050 KB 10108 KB 4634 KB

XLS 19398/22006 KB 10393 KB 3960 KB

PDF 23986 KB 13563 KB 5529 KB

Bericht4

HTML 16217 KB 9984 KB 3445 KB

XLS 26113 KB 6500 KB 3163 KB

PDF 18736 KB 7837 KB 3804 KB

Bericht5

HTML 24564 KB 8287 KB 3207 KB

XLS 33230 KB 7569 KB 4054 KB

PDF 17932 KB 10417 KB 3679 KB

Bericht6

HTML 22180 KB 8069 KB 5540 KB

XLS 32824 KB 12499 KB 10427 KB

PDF 18282 KB 6737 KB 6791 KB

Random-Test



HTML 26148 KB 12711 KB 6897 KB

XLS 36711 KB 10496 KB 9904 KB

PDF 24816 KB 15145 KB 7860 KB

Tabelle 49, Gegenüberstellung von Speicherauslastungsergebnissen.

Die höchste Speicherauslastung hat BIRT. Die optimalste Speicherauslastung hat

JasperReports, gefolgt von Penatho Reporting.

Die durchschnittliche Performance nach Dateiformaten soll nochmal die Ergebnisse

verdeutlichen, Tabelle 50.

Format BIRT Pentaho Reporting Jasper-Reports

HTML 474 ms 1416 ms 703 ms

XLS 621 ms 1314 ms 685 ms

PDF 864 ms 1459 ms 828 ms

Tabelle 50, durchschnittliche Performance nach Formaten.

Die untenstehende Tabelle zeigt die durchschnittliche Speicherauslastung nach

Dateiformaten.

Format BIRT Pentaho Reporting Jasper-Reports

HTML 22627 KB 9636 KB 4385 KB

XLS 30659 KB 8696 KB 5781 KB

PDF 19821 KB 10634 KB 5088 KB

Tabelle 51, durchschnittliche Speicherauslastung nach Formaten.

Wenn man die Ergebnisse betrachtet, dann wird man auf zwei der getesteten

Frameworks BIRT und JasperReports aufmerksam. Beide liegen bei dem

Performancetest nah bei einander. Betrachtet man den Speicherauslastungstest, so sieht

man, dass BIRT am speicherhungrigsten ist.


5.4. Entscheidungsmatrix

BIRT Pentaho Reporting Jasper-Reports

Designerversion 2.3.0 1.7 3.0

Engineversion 2.3.0 0.8.9.4 3.0

Paketgröße39

~40 MB ~30 MB ~40 MB

BRR-Punktezahl 4,55 4,085 4,355

UI-Bewertung 4,64 3,64 3,27

Performance

HTML 474 ms 1416 ms 703 ms

XLS 621 ms 1314 ms 685 ms

PDF 864 ms 1459 ms 828 ms

Speicherauslastung

HTML 22627 KB 9636 KB 4385 KB

XLS 30659 KB 8696 KB 5781 KB

PDF 19821 KB 10634 KB 5088 KB

Tabelle 52, Entscheidungsmatrix.

Liegt der Focus auf Performance und speicherschonender Anwendung, so sollte man

sich für JasperReports entscheiden. Wobei Jasper-Reports den schwächsten Designer im

Test hatte. Fällt die Entscheidung auf BIRT, dann muss bei der Gestaltung der Berichte

auf die Menge der Informationen, die dargestellt werden sollen, geachtet werden. Wird

dies nicht beachtet, dann kann es passieren, das BIRT zu viel Speicher verbraucht.

BIRT bietet den mächtigsten Designer, der durch gute Bedienung, umfangreiche

Funktionalitäten und Übersichtlichkeit aufgefallen ist.

39

Die Angabe beinhaltet die benötigten Bibliotheken, um die Berichte zu generieren.

S e i t e 89

6. Zusammenfassung

Das betriebliche Berichtswesen lässt sich mit Hilfe von BI-Konzepten und –Techniken

in einem Unternehmen umsetzen. Dazu stellt Business Intelligence die Reporting-

Werkzeuge zur Verfügung, die eine Vielzahl von Prozessen aus dem Berichtswesen

abdecken. Beispielsweise Gestaltung, Erstellung, Speicherung und Verteilung von

Berichten. Darüber hinaus unterstützen die Reporting-Werkzeuge einige

Analysemöglichkeiten, wie Aggregation, Sortierung, Filterung und Kennzeichnung der

Abweichungen durch farbliche Hervorhebungen.

Bei der Evaluierung der Open Source Reporting-Frameworks ist aufgefallen, dass

das gewählte Business Readiness Rating Model einige Schwächen im Bereich der UI-

Kriterien aufweist (vgl. Kapitel 5.2.9).

Die ausgewählten Reporting-Frameworks unterscheiden sich im Ergebnis durch die

Bewertung mit dem BRR-Model nur im Nachkommastellenbereich. Starke

Unterschiede ergaben sich im Bereich der Dokumentation. Hier wies Pentaho

erhebliche Mängel auf (vgl. Kapitel 5.2.3). Dagegen bot BIRT die beste

Dokumentation. Falls die Dokumentation für bestimmte Fragestellungen nicht

ausreicht, so kann für BIRT und JasperReports weitergehende Literatur erworben

werden. Die Themenreichweite der Bücher offeriert dabei von Integration des

Frameworks bis zur Gestaltung der Berichte.

Alle drei Frameworks bieten eine lokale Anwendung zum Gestalten der Berichte.

Der Designer von BIRT ist durch gute Bedienung, umfangreiche Funktionalitäten und

Übersichtlichkeit aufgefallen. Dagegen wirken JasperReports und Pentaho Reporting

unübersichtlich im Bereich der Konfiguration für Elemente und Diagramme.

Desweiteren wurden bei JasperReports und Pentaho Reporting Stabilitätsprobleme

festgestellt. Für die Gestaltung von einfachen Berichten ist jedoch jeder der hier

betrachteten Designer gut geeignet.

Durch modulare Architektur lassen sich die evaluierten Reporting-Frameworks in

eine bestehende Anwendung als Module integrieren. Wird Pentaho Reporting als Modul

integriert, so gehen einige Funktionalitäten verloren, die durch die bestehende BI-Suite

angeboten werden. Vor allem die Verwendung des Designers von Pentaho ist dadurch

mit einem erheblichen Aufwand verbunden. Da Pentaho Modul selbst keine Business

Prozesse unterstützt, müssen die gespeicherten Berichtsentwürfe manuell durch SQL-

Abfragen und Datenbankinformationen erweitert werden. Die beste Integration in eine

6 Zusammenfassung S e i t e 90

Web-Anwendung bietet BIRT. Dazu wird eine vorgefertigte Servlet-Anwendung

angeboten, die die Berichte in verschiedenen Formaten ausgibt und vor dem Erzeugen

automatisch nach benötigten Parametern fragt. Die Web-Anwendung lässt sich mit

wenig Aufwand an das bestehend Systeme anpassen. JasperReports bietet einige

Beispiele für die Integration in eine Web-Anwendung. Diese benötigen aber mehr

Anpassungen und Erweiterungen, um die Funktionalitäten auf den gleichen Stand wie

BIRT Web-Anwendung zu bringen.

Die performanteste Generierung der Berichte bietet BIRT. Dieser Vorteil ist mit

einer größeren Speicherauslastung verbunden. Im Vergleich zu anderen Frameworks

verbraucht BIRT ~20 MB an Arbeitsspeicher. Die niedrigste Performance wurde bei

Pentaho Reporting festgestellt. Er benötigte teilweise die zwei- bis dreifache Zeit bei

der Generierung der Berichte im Vergleich zu BIRT. JasperReports war nur geringfügig

langsamer als BIRT, verbrauchte aber auch deutlich weniger Speicher.

Abschließend lässt sich sagen, dass der Einsatz von BIRT zu empfehlen ist, da die

Vorteile überwiegen:

Übersichtliche und bedienungsfreundliche Gestaltungsoberfläche für Berichte,

Ausgabemöglichkeiten der Berichte,

Erweiterbarkeit des Frameworks durch Plug-ins,

wenig Aufwand bei der Integration des Frameworks in vorhandene Anwendung

oder Web-Applikation

und eine vollständige Abdeckung der gestellten Anforderungen durch das

Unternehmen.

Der Nachteil der hohen Speicherauslastung kann durch eine intelligente Gestaltung der

Berichte abgeschwächt werden. Indem die relevanten Informationen in geeigneter

Menge ausgewählt werden.

S e i t e 91

Literaturverzeichnis

BRR (2005):

Business Readiness Rating: http://www.openbrr.org/, heruntergeladen am 17.06.2008

Chamoni (2003):

Chamoni, P.: Analytische Informationssysteme für das Controlling - Stand und

Entwicklungsperspektiven, http://www.cundus.de/downloads/ZfCM-AIS.pdf,

heruntergeladen am 19.05.2008.


Chamoni, P./ Gluchowski, P.: Itegrationstrends bei Business-Ingelligence-Systemen -

Empirische Untersuchung auf Basis des Bussines Intelligence Maturity Model, in:

Wirtschaftsinformatik, 46. Jg. 2004, H. 2, S. 119-128.


Chamoni, P./ Gluchowski, P.: Analytische Informationssysteme - Einordnung und

Überblick, in: Chamoni, P./Gluchowski, P. (Hrsg.): Analytische Informationssysteme:

Business Intelligence-Technologien und -Anwendungen. 3. Aufl., Berlin 2006, Springer

Verlag, S. 3-22.

Danciu/Chirita (2007):

Danciu, T./ Chirita, L.: The Definitive Guide to JasperReports. Berkeley 2007, Apress.

Deprez/Alexandre (2008):

Deprez, J.-C./ Alexandre, S.: Comparing Assessment Methodologies for Free/Open

Source Software: OpenBRR and QSOS. Berlin 2008, Springer Verlag.

Dittmar/Schulze (2006):

Dittmar, C./ Schulze, K.: Seine Stärken kennen lernen. In: BI-SPEKTRUM, Jg. 2006,

H. 01, S. 27-31.

Eclipse-Birt (2008)a:

Eclipse-Birt, http://www.eclipse.org/birt/phoenix/, heruntergeladen am 19.05.2008.

Eclipse-Birt (2008)b:

BIRT Project Description and Scope,

http://www.eclipse.org/birt/phoenix/project/description.php, heruntergeladen am

19.05.2008.

Literaturverzeichnis S e i t e 92

Finger (2006):

Finger, R.: BI-Betriebsmodelle auf dem Prüfstand. In: BI-SPEKTRUM, Jg. 2006, H. 02,

S. 21-25.

Gluchowski (2001):

Gluchowski, P.: Business Intelligence. Konzepte, Technologien und Einsatzbereiche, in:

HMD - Praxis der Wirtschaftsinformatik, 38. Jg. 2001, H. 222, S. 5 – 15.

Gluchowski (2006):

Gluchowski, P.: Techniken und Werkzeuge zum Aufbau betrieblicher Berichtssysteme,

in: Chamoni, P./ Gluchowski,P. (Hrsg.): Analytische Informationssysteme: Business

Intelligence-Technologien und -Anwendungen. 3. Aufl., Berlin 2006, Springer Verlag,

S. 207-226.

Gluchowski/Chamoni (2006):

Gluchowski, P./ Chamoni, P.: Entwicklungslinien und Architekturkonzepte des On-Line

Analytical Processing. In: Chamoni, P./ Gluchowski, P. (Hrsg.): Analytische

Informationssysteme: Business Intelligence-Technologien und -Anwendungen. 3. Aufl.,

Berlin 2006, Springer Verlag, S. 143-176.

Gluchowski/Gabriel/Dittmar (2008):

Gluchowski,P./ Gabriel, R./ Dittmar, C.: Management Support Systeme und Business

Intelligence: Computergestützte Informationssysteme

für Fach- und Führungskräfte. 2. Aufl., Berlin Heidelberg 2008, Springer Verlag.

Gluchowski/Kemper (2006):

Gluchowski, P./ Kemper, H.:Quo Vadis Business Intelligence?, in: BI-SPEKTRUM, Jg.

2006, H. 01, S. 12-19.

Griffel (1998):

Griffel, F.: Componentware., Heidelberg 1998, Dpunkt-Verlag.

Grothe (2000):

Grothe, M.: Business Intelligence . Aus Informationen Wettbewerbsvorteile gewinnen.

o.O. 2000, Addison-Wesley Verlag.

Hartmann/Kracker (2004):

Hartmann, M./Kracker, O.: Perspektiven eines web-basierten Berichtswesens und

Beteiligungsmanagements, in: Hartmann, M. (Hrsg.): Berichtswesen für High-Tech-


Unternehmen: Reporting mit Balanced Scorecard, web-basierten Systemen und

Beteiligungsmanagement. Berlin 2004, Erich Schmidt Verlag.

Heffelfinger (2006):

Heffelfinger, D.: JasperReports for JavaDevelopers. Birmingham 2006, Packt

Publishing.

Heine/Wende (2004):

Heine, P./ Wende, K.: Eigenschaften des web-basierten Reporting, in: Hartmann, M.

(Hrsg.): Berichtswesen für High-Tech-Unternehmen: Reporting mit Balanced

Scorecard, web-basierten Systemen und Beteiligungsmanagement. Berlin 2004, Erich

Schmidt Verlag, S. 331-369.

Held (2007):

Held,M./et al.: Business Intelligence mit Pentaho, http://www.heise.de/open/Business-

Intelligence-mit-Pentaho--/artikel/98599/, heruntergeladen am 17.06.2008.

Hübner (2004):

Hübner, J.: Unternehmenskommunikation. In: Hartmann, M. (Hrsg.): Berichtswesen für

High-Tech-Unternehmen: Reporting mit Balanced Scorecard, web-basierten Systemen

und Beteiligungsmanagement. Berlin 2004, Erich Schmidt Verlag, S. 61-79.

JasperSoft (2008):

JasperReports,

http://www.jasperforge.org/jaspersoft/opensource/business_intelligence/jasperreports/,


Kemper/Lee (2001):

Kemper, H./ Lee, P.: Business Intelligence - ein Wegweiser, in: Computerwoche, Jg.

2001, H. 44, S. 54-55.

Kemper/Mehanna/Unger (2006):

Kemper, H./ Mehanna, W./ Unger, C.: Business Intelligence - Grundlagen und

praktische Anwendungen: Eine Einführung in die IT-basierte

Managementunterstützung. Wiesbaden 2006, Vieweg Verlag.

Kleijn (2006):

Kleijn, A.: Business Intelligence mit Open Source, http://www.heise.de/open/Business-

Intelligence-mit-Open-Source--/artikel/73725, heruntergeladen am 17.06.2008.


MERIT (2006):

MERIT: Economic impact of open source software on innovation and the

competitiveness of the Information and Communication Technologies (ICT) sector in

the EU, http://ec.europa.eu/enterprise/ict/policy/doc/2006-11-20-flossimpact.pdf,


Mertens (2002):

Mertens, P.: Business Intelligence - Ein Überblick. In: Information Management &

Consulting, 17. Jg. 2002, Sonderausgabe, S. 65-73.

Mucksch (2006):

Mucksch, H.: Das Data Warehouse als Datenbasis analytischer Informationssysteme, in:

Chamoni, P./ Gluchowski, P. (Hrsg.): Analytische Informationssysteme: Business

Intelligence-Technologien und -Anwendungen. 3. Aufl., Berlin 2006, Springer Verlag,

S. 129-142.

Open Source Definition (2008):

The Open Source Definition, http://www.opensource.org/docs/osd, heruntergeladen am

15.09.2008.

Peh (2006):

Peh, D./ et al.: BIRT: A Field Guide to Reporting. Amsterdam 2006, Addison-Wesley

Longman.

Pentaho (2008):

Pentaho Reporting, http://www.pentaho.com/products/reporting/, heruntergeladen am

19.05.2008.

Probst (2006):

Probst, J.: Berichtswesen. Augsburg 2006, WEKA Media GmbH & Co.KG.

Schelp (2006):

Schelp, J.: "Real"-Time Warehousing und EAI, in: Chamoni, P./Gluchowski, P. (Hrsg.):

Analytische Informationssysteme: Business Intelligence-Technologien und -

Anwendungen. 3. Aufl., Berlin 2006, Springer Verlag, S. 425-438.

Schulze/Dittmar (2006):

Schulze, K./ Dittmar, C.: Business Intelligence Reifegradmodelle, in: Chamoni, P./

Gluchowski, P. (Hrsg.): Analytische Informationssysteme: Business Intelligence-

Technologien und -Anwendungen. 3. Aufl., Berlin 2006, Springer Verlag, S. 71-87.


Strauch/Winter (2002):

Strauch, B./ Winter, R.: Stichwort "Business Intelligence", in: Bellmann, M./ Krcmar,

H./ Sommerlatte, T. (Hrsg.): Praxishandbuch Wissensmanagement - Strategien,

Methoden, Fallbeispiele. 1. Aufl., Düsseldorf 2002, Symposion Publishing, S. 439 - 448

Totok (2006):

Totok, A.: Entwicklung einer Business-Intelligence-Strategie, in: Chamoni, P./

Gluchowski, P. (Hrsg.): Analytische Informationssysteme: Business Intelligence-

Technologien und -Anwendungen. 3. Aufl., Berlin 2006, Springer Verlag, S. 51-70.

Verity (2005):

Verity, J.: Intelligence Gets Smarter, http://cfo.com/article.cfm/4390968/,


Waniczek (2002)a:

Waniczek, M.: Grundlagen der Reporting-Konzeption, http://www.controlling-

portal.org/index.php?load=http://www.controlling-

portal.org/3/Einfuehrung/23/23.shtml, heruntergeladen am 17.06.2008.

Waniczek (2002)b:

Waniczek, M.: Reporting-Audit: Die Analyse des Berichtswesens,

http://www.controlling-portal.org/index.php?load=http://www.controlling-

portal.org/3/Einfuehrung/19/19.shtml, heruntergeladen am 17.06.2008.

Wayner (2008):

Wayner, P.: Product review: Open source reporting goes corporate,

http://www.infoworld.com/article/08/02/18/08TC-open-source-reporting_1.html,


Weathersby/et al. (2006):

Weathersby, J./et al.: Integrating and Extending Birt. Amsterdam 2006, Addison-

Wesley Longman.

Willenborg (2002):

Willenborg, K.: Berichtswesen - Vereinigung von Gegensätzen,

http://www.sapdesignguild.org/editions/edition2/willenborg/index.html,


S e i t e 96

Anhang

A. Abbildungen der Berichte ....................................................................................... 97

B. Benchmarkanwendung Quellcode .......................................................................... 98

C. Abbildungen der Designer-Oberflächen .............................................................. 115

S e i t e 97

A. Abbildungen der Berichte

Die Abbildungen wurden aus datenschutzrechtlichen Gründen entfernt.

S e i t e 98

B. Benchmarkanwendung Quellcode

/**

* Die Klasse BenchmarkRunner ist für die Steuerung der Hauptanwendung

* verantwortlich.

*/

public class BenchmarkRunner {

/** Logger */

private static final Logger logger = Logger

.getLogger(BenchmarkRunner.class);

/**

* Standardkonstruktor für die Klasse BenchmarkRunner

*/

public BenchmarkRunner() {

super();

}

/**

* Die Main-Methode zum Starten der Anwendung.

*

* @param args

* Argumente

*/

public static void main(final String[] args) {

String format = "";

String report = "";

String engine = "";

try {

// Parsen der Programmparameter.

for (String string : args) {

int index = string.indexOf('=');

String param = (string.substring(1, string

.indexOf('=')));

String value = string.substring(index + 1, string

.length());

if (param.equals("report")) {

report = value.toLowerCase();

} else if (param.equals("format")) {

format = value.toLowerCase();

} else if (param.equals("engine")) {

engine = value.toLowerCase();

}

}

// wenn die Parameter leer sind, eine Fehlermeldung ausgeben.

if (format.trim().length() == 0

|| report.trim().length() == 0

|| engine.trim().length() == 0) {

usage();

}

// ausgeben des Parameterinhalts.

logger.info("starting benchmark for engine=" + engine

+ " report=" + report + " and format=" +

format);

// Erstellen der Reportingengine anhand des Engineparameters

AReportingEngine repEngine = ReportEngineFactory

.createReportingEngine(engine);

// initialisieren der Engine.

repEngine.initEngine();

// berechnen und ausgeben der Ergebnisse.

System.out.println(repEngine.computePerformanceResult(

format, report));

// Engine Stoppen.

repEngine.stopEngine();

repEngine = null;

} catch (Exception e) {

e.printStackTrace();

}

B B e n c h m a r k a n w e n d u n g Q u e l l c o d e S e i t e 99

}

/**

* Die Methode gibt die Informationen in der Konsole aus, wie die Anwendung

* zu benutzen ist.

*/

private static void usage() {

System.out.println("Bitte geben Sie Parameter ein:");

System.out.println("-report=Bericht1|Bericht2|...");

System.out.println("-format=HTML|PDF|XLS|random");

System.out.println("-engine=jasper|pentaho|birt");

}

}

Listing 1, Quellcode der Klasse BenchmarkRunner.

/**

* Die Klasse ReportEngineFactory ist eine Factory-Klasse zum Erzeugen von

* AReportingEngine-Objekten.

*

* @author ado

*/

public class ReportEngineFactory {

/**

* Erstellt ein neues AReportingEngine-Objekt.

*

* @param engine

* Parameter für die Engineauswahl(jasper, pentaho oder birt) als

* String.

*

* @return the a reporting engine

*/

public static AReportingEngine createReportingEngine(String engine) {

if (engine.equals("jasper")) {

return new ReportingEngineJasperReports(

"C:/reports/jasper/");

} else if (engine.equals("pentaho")) {

return new ReportingEnginePentaho("C:/reports/pentaho/");

} else if (engine.equals("birt")) {

return new ReportingEngineBirt("C:/reports/birt/");

}

return null;

}

}

Listing 2, Quellcode der Klasse ReportEngineFactory.

/**

* Die Abstrakte Klasse AReportingEngine.

*

* @author ado

*/

public abstract class AReportingEngine {

/** The output folder. */

private String outputFolder = "c:/tmpreport/";

/** Quellverzeichnis */

private String inputFolder = "";

/** Endung der Quelldatei */

private String suffix = "";

/** Anzahl der Durchläufe */

private final int cycles = 1000;


/** Feld für die Zufallsberichte. */

private File[] randomReports = null;

/** Set zum Auffangen der Zuffalszahlen. */

private final Set randomCatcher = new HashSet(6);

/**

* Liefert die Endung der Quelldatei.

*

* @return die Endung.

*/

public final String getSuffix() {

return suffix;

}

/**

* Setzt die Endung der Quelldatei.

*

* @param suffix

* die Endung.

*/

public final void setSuffix(String suffix) {

this.suffix = suffix;

}

/**

* Konstruktor für AReportingEngine mit Quellverzeichnis als Parameter.

*

* @param inputFolder

* das Quellverzeichnis

*/

public AReportingEngine(String inputFolder) {

this.inputFolder = inputFolder;

}

/**

* Liefert das Ausgabeverzeichnis.

*

* @return das Ausgabeverzeichnis.

*/

public final String getOutputFolder() {

return outputFolder;

}

/**

* Liefert das Quellverzeichnis.

*

* @return das Quellverzeichnis.

*/

public final String getInputFolder() {

return inputFolder;

}

/**

* Setzt das Quellverzeichnis.

*


* Quellverzeichnis als String

*/

public final void setInputFolder(String inputFolder) {

this.inputFolder = inputFolder;

}

/**

* Setzt das Ausgabeverzeichnis.

*

* @param outputFolder

* Ausgabeverzeichnist als String.

*/

public final void setOutputFolder(String outputFolder) {

this.outputFolder = outputFolder;

}

/**

* Berechnet die Performance und Speicherauslastung fuer den übergebenen

* Bericht und Ausgabetyp.


*

* @param reportType

* Reporttyp, der erzeugt werden soll(HTML, PDF, XLS oder random.

* @param inputReport

* Name der Quelldatei, aus der ein Bericht erzeugt werden soll.

*

* @return die Ergebnisse als String.

*

* @throws Exception

* exception

*/

public final String computePerformanceResult(String reportType,

String inputReport) throws Exception {

// Wenn der übergebene Parameter für Quelldatei leer ist, eine

// Fehlermeldung ausgeben.

if (inputReport == null || inputReport.trim().length() == 0) {

throw new IllegalArgumentException("InputFile should "

+ "not be empty!");

}

// Wenn der übergebene Parameter für Typ leer ist, eine Fehlermeldung

// ausgeben.

if (reportType == null || reportType.trim().length() == 0) {

throw new IllegalArgumentException(

"reportType should not be empty!");

}

// Initialisierung der StoppUhr.

Stopwatch stopWatch = new Stopwatch().reset();

// Vorbereitung für das Ergebnis

String result = inputReport + ";" + reportType + ";";

// Variable für Quelldatei

File inputFile = null;

// Bei Zuffalsberichten Zuffalsdateien vorbereiten.

if (inputReport.equalsIgnoreCase("random")) {

// Öffnen des Quellverzeichnisses.

File inputFolder = new File(this.inputFolder);

// setzen eines Filters zum Laden der Quelldateien

this.randomReports = inputFolder.listFiles(new FileFilter() {

@Override

public boolean accept(File pathname) {

// die Quelldateien dürfen nur auf den Suffix

// enden und nicht mit "sub" anfangen.

return pathname.getName().endsWith(suffix) &&

!pathname.getName().contains("sub");

}

});

} else {

// Bei Berichten die Quelldatei laden.

inputFile = new File(this.inputFolder + inputReport +

this.suffix);

}

// Ergebnisvariable für Zeit.

long totalTime = 0;

// Ergebnisvariable für Speicher.

long totalMemory = 0;

for (int i = 0; i < this.cycles; i++) {

// Bei Zuffalsberichten Zuffalsquelldatei laden.

if (inputReport.equalsIgnoreCase("random")

&& this.randomReports != null

&& this.randomReports.length != 0) {

inputFile = getRandomFile();

}

// startet die Zeitmessung.

stopWatch.reset().start();

// Auswahl der geeigneten Methode anhand des Berichttyps.

if (reportType.equalsIgnoreCase("PDF")) {

this.createPDFReport(inputFile, i);

} else if (reportType.equalsIgnoreCase("XLS")) {

this.createXLSReport(inputFile, i);

} else if (reportType.equalsIgnoreCase("HTML")) {

this.createHTMLReport(inputFile, i);

}

// stoppt die Zeitmessung.


stopWatch.stop();

// Speicherung der Ergebnisse in die temporäre Variablen.

totalMemory += (MemUtils.usedMemory() / 1024);

totalTime += stopWatch.getElapsedTime();

}

// Berechnung der Ergebnisse.

result += "" + (totalTime / (this.cycles - 200)) + ";"

+ (totalMemory / (this.cycles - 200));

return result;

}

/**

* Berechnet eine Zuffalsdatei und gibt diese zurück.

*

* @return the random file

*/

private File getRandomFile() {

// erzeugt ein neues Random-Objekt.

Random randomGenerator = new Random();

// leert den Zahlenpuffer, wenn dieser voll ist.

if (randomCatcher.size() == this.randomReports.length) {

randomCatcher.clear();

}

// berechnet die Zuffalszahl zwischen 0 und der Anzahl der Berichte.

int randomInt = randomGenerator.nextInt(this.randomReports.length);

// falls die Zuffalszahl nicht neue ist, wird eine neue generiert.

if (!randomCatcher.add(randomInt)) {

return getRandomFile();

}

return this.randomReports[randomInt];

}

/**

* Initialisiert die Reporting-Engine.

*

* @throws Exception

* exception

*/

public abstract void initEngine() throws Exception;

/**

* Generiert ein Bericht im HTML-Format.

*

* @param inputFile

* Bericht-Datei, aus der ein Bericht generiert werden soll.

* @param count

* count

*

* @throws Exception

* exception

*/

protected abstract void createHTMLReport(File inputFile, int count)

throws Exception;

/**

* Generiert ein Bericht im PDF-Format.

*

* @param inputFile


* @param count

* count

*

* @throws Exception

* exception

*/

protected abstract void createPDFReport(File inputFile, int count)

throws Exception;

/**

* Generiert ein Bericht im XLS-Format.

*

* @param inputFile



* @param count

* count

*

* @throws Exception

* exception

*/

protected abstract void createXLSReport(File inputFile, int count)

throws Exception;

/**

* Stoppt die Reporting-Engine.

*

* @throws Exception

* exception

*/

public abstract void stopEngine() throws Exception;

}

Listing 3, Quellcode der Klasse AReportingEngine.

/**

* Die Klasse ReportingEngineBirt enthaelt die Steuerung fuer BIRT, um die

* Berichte in Formaten PDF, HTML und XLS.

*/

public class ReportingEngineBirt extends AReportingEngine {

/** Birt engine. */

private IReportEngine engine;

/**

* Konstruktor.

*


* Quellverzeichnis, aus dem die Berichte geladen werden.

*/

public ReportingEngineBirt(String inputFolder) {

super(inputFolder);

this.setSuffix(".rptdesign");

}

/*

* (non-Javadoc)

*

* @see de.ikom.reporting.AReportingEngine#createHTMLReport(java.io.File,

* int)

*/

@Override

public void createHTMLReport(File inputFile, int count)

throws Exception {

// laden der Design-Datei

IReportRunnable design = this.engine

.openReportDesign(inputFile.getAbsolutePath());

// Erzeugt eine Aufgabe zum Erstellen des Berichtes.

IRunAndRenderTask task = this.engine

.createRunAndRenderTask(design);

// Setzt den Vater-ClassLoader.

task.getAppContext().put(

EngineConstants.APPCONTEXT_CLASSLOADER_KEY,

this.getClass().getClassLoader());

// Initialisiert den Renderer für HTML-Ausgabeformat.

HTMLRenderOption htmloptions = new HTMLRenderOption();

htmloptions.setOutputFileName(this.getOutputFolder()

+ inputFile.getName() + count + ".html");

htmloptions.setOutputFormat("html");

htmloptions.setImageDirectory(this.getOutputFolder());

htmloptions.setEmbeddable(false);

// übergabe des Renderers an die Aufgabe.


task.setRenderOption(htmloptions);

// Ausführen der Aufgabe

task.run();

// schliessen der Aufgabe

task.close();

}

/*

* (non-Javadoc)

*

* @see de.ikom.reporting.AReportingEngine#createPDFReport(java.io.File,

* int)

*/

@Override

public void createPDFReport(File inputFile, int count)

throws Exception {


IReportRunnable design = engine.openReportDesign(inputFile

.getAbsolutePath());


IRunAndRenderTask task = engine






// Initialisiert den Renderer für PDF-Ausgabeformat.

PDFRenderOption options = new PDFRenderOption();

options.setOption(IPDFRenderOption.PAGEBREAK_PAGINATION_ONLY,

Boolean.TRUE);

options.setOutputFileName(this.getOutputFolder()

+ inputFile.getName() + count + ".pdf");

options.setOutputFormat("pdf");


task.setRenderOption(options);


task.run();


task.close();

}

/*

* (non-Javadoc)

*

* @see de.ikom.reporting.AReportingEngine#createXLSReport(java.io.File,

* int)

*/

@Override

public void createXLSReport(File inputFile, int count)

throws Exception {


IReportRunnable design = engine.openReportDesign(inputFile

.getAbsolutePath());


IRunAndRenderTask task = engine






// Initialisiert den Renderer für Excel-Ausgabeformat.

EXCELRenderOption exceloptions = new EXCELRenderOption();

exceloptions.setOutputFileName(this.getOutputFolder()

+ inputFile.getName() + count + ".xls");

exceloptions.setOutputFormat("xls");

exceloptions.setOfficeVersion("office2003");



task.setRenderOption(exceloptions);


task.run();


task.close();

}

/*

* (non-Javadoc)

*

* @see de.ikom.reporting.AReportingEngine#initEngine()

*/

@Override

public void initEngine() throws Exception {

// Konfigurationen für die Engine erzeugen

EngineConfig config = new EngineConfig();

config.setLogConfig("log", Level.OFF);

// Platform starten

Platform.startup(config);

// Factory erzeugen

IReportEngineFactory factory = (IReportEngineFactory) Platform

.createFactoryObject(IReportEngineFactory.EXTENSION_REPORT_ENGINE_FACTORY);

// Engine erzeugen

this.engine = factory.createReportEngine(config);

this.engine.changeLogLevel(Level.OFF);

}

/*

* (non-Javadoc)

*

* @see de.ikom.reporting.AReportingEngine#stopEngine()

*/

@Override

public void stopEngine() throws Exception {

// Engine stoppen.

engine.destroy();

// Platform stoppen.

Platform.shutdown();

}

}

Listing 4, Quellcode der Klasse ReportingEngineBirt.

/**

* Die Klasse ReportingEngineJasperReports enthaelt die Steuerung fuer BIRT, um

* die Berichte in Formaten PDF, HTML und XLS.

*/

public class ReportingEngineJasperReports extends AReportingEngine {

/**

* Konstruktor.

*



*/

public ReportingEngineJasperReports(String inputFolder) {

super(inputFolder);

this.setSuffix(".jasper");

}

/**

* Logger fuer diese Klasse.

*/

private static final Logger logger = Logger


.getLogger(ReportingEngineJasperReports.class);

/** Datenbankverbindung */

private Connection con;

/*

* (non-Javadoc)

*


* int)

*/

@Override


throws Exception {

// Laden und Parsen der Design-Datei

JasperReport jasperReport = (JasperReport) JRLoader

.loadObjectFromLocation(inputFile.getAbsolutePath());

// JasperReport mit Daten aus der Datenbank anreichern.

JasperPrint jasperPrint = JasperFillManager.fillReport(

jasperReport, new HashMap(), con);

// JasperPrint als HTML-Datei exportieren.

JRHtmlExporter exporterHtml = new JRHtmlExporter();

exporterHtml.setParameter(JRExporterParameter.JASPER_PRINT,

jasperPrint);

exporterHtml.setParameter(

JRExporterParameter.OUTPUT_FILE_NAME, this

.getOutputFolder()


exporterHtml.setParameter(JRHtmlExporterParameter.SIZE_UNIT,

JRHtmlExporterParameter.SIZE_UNIT_POINT);

exporterHtml.exportReport();

}

/*

* (non-Javadoc)

*


* int)

*/

@Override


throws Exception {







// JasperPrint als PDF-Datei exportieren.

JasperExportManager.exportReportToPdfFile(jasperPrint, this

.getOutputFolder()


}

/*

* (non-Javadoc)

*


* int)

*/

@Override


throws Exception {







// JasperPrint als XLS-Datei exportieren.


JRXlsExporter exporterXLS = new JRXlsExporter();

exporterXLS.setParameter(JRExporterParameter.JASPER_PRINT,

jasperPrint);

exporterXLS.setParameter(

JRExporterParameter.OUTPUT_FILE_NAME, this

.getOutputFolder()


exporterXLS.setParameter(

JRXlsExporterParameter.IS_ONE_PAGE_PER_SHEET,

Boolean.FALSE);

exporterXLS.exportReport();

}

/*

* (non-Javadoc)

*


*/

@Override


this.con = getConnection();

}

/**

* Liefert die Datenbankverbindung

*

* @return Datenbankverbindung

*

* @throws ClassNotFoundException

* Klasse-Nicht-Gefunden-Exception

* @throws SQLException

* SQL-Exception

*/

private static Connection getConnection()

throws ClassNotFoundException, SQLException {

// Debuginformationen ausgeben

if (logger.isDebugEnabled()) {

logger.debug("getConnection() - start");

}

// Datenbanktreiber laden

Class.forName(Constants.DB_DRIVER);

// Verbindung erzeugen

Connection conn = DriverManager.getConnection(

Constants.DB_CONNECTION_STRING, Constants.DB_USER,

Constants.DB_PASSWORD);

// Debuginformationen ausgeben

if (logger.isDebugEnabled()) {

logger.debug("getConnection() - end - return value="

+ conn);

}

return conn;

}

/*

* (non-Javadoc)

*


*/

@Override


// Datenbankverbindung trennen.

if (this.con != null) {

this.con.close();

this.con = null;

}

}

}

Listing 5, Quellcode der Klasse ReportingEngineJasperReports.


/**

* Die Klasse ReportingEnginePentaho enthaelt die Steuerung fuer BIRT, um die

* Berichte in Formaten PDF, HTML und XLS.

*

* @author ado

*/

public class ReportingEnginePentaho extends AReportingEngine {

/**

* Konstruktor.

*



*/

public ReportingEnginePentaho(String inputFolder) {

super(inputFolder);

this.setSuffix(".xml");

}

/*

* (non-Javadoc)

*


* int)

*/

@Override


throws Exception {

// ResourcenManager initialisieren.

ResourceManager manager = new ResourceManager();

manager.registerDefaults();

// Laden der Quelldatei

Resource res = manager.createDirectly(inputFile.toURI()

.toURL(), JFreeReport.class);

JFreeReport report = (JFreeReport) res.getResource();

// Exportieren im HTML-Format

HtmlReportUtil.createDirectoryHTML(report, this

.getOutputFolder()


}

/*

* (non-Javadoc)

*


* int)

*/

@Override


throws Exception {








// Exportieren im PDF-Format

PdfReportUtil.createPDF(report, this.getOutputFolder()


}

/*

* (non-Javadoc)

*


* int)

*/

@Override


throws Exception {









// Exportieren im XLS-Format

ExcelReportUtil.createXLS(report, this.getOutputFolder()


}

/*

* (non-Javadoc)

*


*/

@Override


// Initialiseren von Engine

JFreeReportBoot.getInstance().start();

}

/*

* (non-Javadoc)

*


*/

@Override


}

}

Listing 6, Quellcode der Klasse ReportingEnginePentaho.

S e i t e 110

C. Abbildungen der Designer-Oberflächen

Abbildung 15, Designer-Oberfläche Birt.

Abbildung 16, Designer-Oberfläche Pentaho Report Designer.

C A b b i l d u n g e n d e r Designer-Oberflächen S e i t e 111

Abbildung 17, Designer-Oberläche IReport.

Ich versichere, die von mir vorgelegte Arbeit selbständig verfasst zu haben. Alle

Stellen, die wörtlich oder sinngemäß aus veröffentlichten oder nicht veröffentlichten

Arbeiten anderer entnommen sind, habe ich als entnommen kenntlich gemacht.

Sämtliche Quellen und Hilfsmittel, die ich für die Arbeit benutzt habe, sind angegeben.

Die Arbeit hat mit gleichem Inhalt bzw. in wesentlichen Teilen noch keiner anderen

Prüfungsbehörde vorgelegen.

20.10.2008, Gummersbach,______________________

(Datum, Ort, Unterschrift)

Documents

Evaluierung von Reporting-Frameworks am Beispiel der ...blogs.gm.fh-koeln.de/faeskorn/files/2008/11/diplom_eval_ado.pdf · Evaluierung von Reporting-Frameworks am Beispiel der ausgewählten