Praca dyplomowa magisterska

Politechnika Warszawska Rok akademicki 2010/2011 Wydział Elektroniki i Technik Informacyjnych Instytut Informatyki Praca dyplomowa magisterska inż. Piotr Kalański TODO Ocena: Opiekun pracy: dr inż. Michał Rudowski Podpis Przewodniczącego Komisji Egzaminu Dyplomowego

Kierunek: Informatyka Specjalność: Inżynieria Systemów Informatycznych Data urodzenia: 18 kwietnia 1986 r. Data rozpoczęcia studiów: październik 2010 r. Życiorys TODO Podpis studenta Egzamin dyplomowy Złożył egzamin dyplomowy w dn......................................... 2010 r. z wynikiem.................................................................... Ogólny wynik studiów.......................................................... Dodatkowe wnioski i uwagi Komisji................................................... Streszczenie Słowa kluczowe: Abstract Title of paper: Keywords:

Spis treści Spis treści i 1 Wstęp 1 1.1 Cel pracy................................ 2 1.2 Zakres pracy.............................. 2 2 Raportowanie 3 2.1 Business Intelligence.......................... 3 2.1.1 Definicja [24].......................... 3 2.1.2 Historia powstania Business Intelligence [24]......... 3 2.1.3 Piramida Business Intelligence [11].............. 4 2.1.4 Hurtownia danych [26]..................... 4 2.1.5 OLAP [24]........................... 5 2.1.6 Data mining [8]......................... 6 2.2 Istniejące rozwiązania Business Intelligence............. 6 2.2.1 Jaspersoft............................ 6 2.2.2 IBM Cognos.......................... 12 2.3 Podsumowanie............................. 12 3 Biblioteka 16 3.1 Wymagania............................... 16 3.1.1 Wymagania funkcjonalne................... 16 3.1.2 Wymagania niefunkcjonalne.................. 17 3.1.3 Przypadki użycia........................ 17 3.2 Przykładowe bazy danych....................... 22 3.2.1 CRM.............................. 22 3.2.2 Service Desk.......................... 25 3.3 Przykładowe raporty.......................... 27 3.3.1 Service Desk.......................... 27 3.3.2 CRM.............................. 27 i

SPIS TREŚCI ii 3.4 Meta-Model............................... 29 3.4.1 Meta-model biznesowy..................... 29 3.4.2 Przykładowy model biznesowy................ 30 3.4.3 Meta-model raportu...................... 32 3.4.4 Przykładowy raport...................... 34 3.5 Projekt................................. 34 3.5.1 Model.............................. 34 3.5.2 Web............................... 35 3.5.3 Diagramy sekwencji...................... 39 3.6 Implementacja............................. 39 3.6.1 Generowanie zapytania.................... 40 3.6.2 Komunikacja klient - serwer.................. 41 3.6.3 Serializacja do formatu XML................. 41 3.6.4 Technologia........................... 42 3.6.5 Narzędzia............................ 42 3.7 Testy i ocena.............................. 44 3.7.1 Środowiska testowe....................... 44 3.7.2 Generacja danych....................... 45 3.7.3 Testy jednostkowe....................... 45 3.7.4 Testy funkcjonalne....................... 45 3.8 Aplikacja................................ 48 3.8.1 Możliwości aplikacji...................... 48 3.8.2 Przykładowe analizy...................... 50 3.8.3 Serwer raportów........................ 53 4 Designer 55 4.1 Wymagania............................... 55 4.1.1 Wymagania funkcjonalne................... 55 4.1.2 Przypadki użycia........................ 55 4.2 Projekt................................. 63 4.2.1 Diagramy sekwencji...................... 63 4.3 Implementacja............................. 63 4.3.1 Technologia........................... 63 4.3.2 Diagramy pakietów....................... 63 4.4 Aplikacja................................ 63 4.5 Podsumowanie............................. 63 5 Aplikacja mobilna 64 5.1 Wymagania............................... 64 5.2 Projekt................................. 64 5.3 Implementacja............................. 64 5.3.1 Technologia........................... 64

SPIS TREŚCI iii 5.3.2 Narzędzia............................ 64 5.4 Aplikacja................................ 64 5.5 Podsumowanie............................. 64 6 Podsumowanie 65 Bibliografia 66 Spis symboli i skrótów 68 Spis rysunków 69 Spis tabel 71

Rozdział 1 Wstęp Dzisiejszy rynek technologii informatycznych oferuje wiele narzędzi wspierających proces raportowania. Są to rozwiązania zarówno komercyjne (Business Objects, IBM Cognos) jak i Open Source: Jasper Reports, Eclipse BIRT. Rozwiązania Open Source umożliwiają tworzenie wyłącznie raportów statycznych, w których brakuje interakcji z użytkownikiem oraz wspierają głównie raportowanie operacyjne. Natomiast narzędzia komercyjne pozwalają na tworzenie bardziej dynamicznych raportów, w których dostępna jest możliwość poruszania się po hierarchii danych, sortowania wierszy oraz filtrowania danych. Żadne z wyżej wymienionych narzędzi nie umożliwia ograniczania zakresu widocznych danych (uprawnienia), zwijania/rozwijania danych, dynamicznej zmiany hierarchii grupowania, zamrożenia widocznych kolumn i wierszy nagłówka (funkcjonalność dostępna między innymi w programie Excel). Wymienione funkcje mogą zdecydowanie uatrakcyjnić przeglądanie raportu. Użytkownik widzi takie dane do których ma uprawnienia oraz które go w danej chwili interesują. Ma możliwość szybkiego obejrzenia szczegółowych danych. Na rynku dostępna jest biblioteka SmartGWT spełniająca niektóre z wyżej wymienionych wymagań. W ramach tej biblioteki został utworzony Widget TreeGrid, który pozwala na zwijanie/rozwijanie danych, zamrożenie widocznych kolumn oraz wierszy nagłówka. Narzędzie to nie umożliwia natomiast ograniczania widocznych danych oraz dynamicznej zmiany hierarchii. Dodatkowo źródło danych dla tego komponentu musi być w postaci tabeli zawierającej powiązanie rekurencyjne, co jest znaczącym ograniczeniem. Kolejne wady tego rozwiązania to brak wsparcia dla filtracji danych (filtr musi zostać zaimplementowany programowo) oraz brak wsparcia dla modelu biznesowego (np. świat obiektów w Business Objects), który ułatwia tworzenie raportów analitykom, którzy nie muszą znać struktury bazy danych. 1

ROZDZIAŁ 1. WSTĘP 2 1.1 Cel pracy Zaprojektowanie oraz zaimplementowanie biblioteki umożliwiającej tworzenie hierarchicznych raportów dla aplikacji www w sposób deklaratywny. 1.2 Zakres pracy TODO

Rozdział 2 Raportowanie Rozdział ten zawiera wprowadzenie do Business Intelligence z omówieniem hurtowni danych, OLAP oraz eksploracji danych. W poszczególnych sekcjach zostały zaprezentowane wybrane narzędzia klasy Business Intelligence: JasperReports oraz IBM Cognos. Podsumowanie rozdziału zawiera przedstawienie najbardziej pożądanych cech nowego narzędzia do raportowania. 2.1 Business Intelligence 2.1.1 Definicja [24] Business Intelligence jest definiowane przez firmę Gartner jako zorientowany na użytkownika proces zbierania, eksploracji, interpretacji i analizy danych, który prowadzi do usprawnienia i zracjonalizowania procesu podejmowania decyzji biznesowych w celu kreowania wzrostu wartości przedsiębiorstwa. 2.1.2 Historia powstania Business Intelligence [24] Na powstanie Business Intelligence miało wpływ kilka nurtów. Po pierwsze wykorzystanie komputerów w dziedzinie statystyki i w badaniach operacyjnych przyczyniło się do powstania systemów wspomagania decyzji. Kolejny nurt to prace nad sztuczną inteligencją rozpoczęte w latach 50. W ramach tej dziedziny opracowano wiele algorytmów przydatnych do wspierania rzeczywistych procesów decyzyjnych, które wykraczały poza możliwości systemów wspomagania decyzji. Jednak kluczowym nurtem był rozwój relacyjnych baz danych oraz rozwój języka zapytań SQL. Kolejny etap to rozwój w latach 80. dziedziny projektowania i tworzenia hurtowni danych, czyli baz danych na potrzeby wspierania decyzji biznesowych. W tym czasie zaczęły również powstawać pierwsze pakiety narzędziowe. 3

ROZDZIAŁ 2. RAPORTOWANIE 4 W latach 90. Business Intelligence stało się terminem powszechnie znanym wśród fachowców oraz standardem oferowanym przez firmy specjalistyczne i największych producentów oprogramowania, takich jak: IBM, Microsoft, Oracle czy SAP. 2.1.3 Piramida Business Intelligence [11] Rysunek 2.1: Piramida Business Intelligence Narzędzia analityczne Business Intelligence można uporządkować wedle stopnia złożoności. Jest on proporcjonalnie zależny od poziomu skomplikowania oraz odwrotnie proporcjonalny do częstości używania oraz liczby potencjalnych użytkowników. Rysunek 2.1 przedstawia piramidę narzędzi klasy Business Intelligence. Na samym dole znajduje się oprogramowanie hurtowni danych, które umożliwia projektowanie struktury bazy danych oraz pobieranie, czyszczenie i transformację danych. Na drugim poziomie znajdują się narzędzia do raportowania i zapytań ad-hoc. Pozwalają one początkowemu użytkownikowi na tworzenie i używanie raportów. Trzeci poziom tworzą narzędzia OLAP 1, czyli środowisko wielowymiarowych analiz. Na samej górze piramidy są narzędzia do eksploracji danych, których celem jest odnajdywanie zależności w obrębie danych oraz prognozowanie. 2.1.4 Hurtownia danych [26] Hurtownia danych definiowana jest jako uporządkowana tematycznie, zintegrowana, zawierająca wymiar czasowy oraz nieulotna baza danych wspomagająca podejmowanie decyzji. 1 OLAP OnLine Analytical Processing

ROZDZIAŁ 2. RAPORTOWANIE 5 Uporządkowanie tematycznie oznacza ograniczenie zbieranych danych do określonego obszaru biznesowego, np: sprzedaży czy marketingu. Jest to odmienne podejście do baz danych systemów transakcyjnych, gdzie gromadzone są dane dotyczące działań lub procesów biznesowych. Zintegrowany oznacza, że dane pochodzą z różnych źródeł i zostały sprowadzone do wspólnego modelu korporacyjnego. Zawierający wymiar czasu Gromadzone są dane zmieniające się w czasie. Prawie wszystkie zapytania kierowane do hurtowni wymagają podania wycinka czasu. Nieulotny Dane raz umieszczone w hurtowni nie ulegają zmianie. To samo zapytanie powinno zawsze zwracać ten sam rezultat. 2.1.5 OLAP [24] Przetwarzanie analityczne on-line (OLAP) jest wielowymiarową analizą danych zainicjowaną przez użytkownika biznesowego i obejmuje złożone mechanizmy raportowania, analizy oraz wizualizacji danych. OLAP składa się z dwóch zasadniczych elementów: wielowymiarowego modelu danych oraz zbioru operacji. Model danych Sposób modelowania danych odzwierciedla potrzeby raportowania danych biznesowych. Analizuję się wskaźniki biznesowe, które w modelu logicznym nazywane są faktami lub miernikami. Przykładowe fakty to wielkość sprzedaży, liczba spotkań czy saldo kredytowe. W trakcie analizy istotny jest kontekst, który zwany jest wymiarem lub atrybutem, taki jak klient, czas czy produkt. Codd odzwierciedla to swoim spostrzeżeniem: Z reguły jest wiele różnych wymiarów, według których można analizować pewien zbiór danych. Ta złożona perspektywa, czyli wielowymiarowy obraz pojęciowy, wydaje się być sposobem, w jaki większość ludzi biznesu z natury widzi swoje przedsiębiorstwo. Zbiór operacji Podstawowe operacje analizy danych to określenie zakresu analizy, drążenie/rozwijanie, zwijanie, wycinanie oraz obracanie. to ustalenie jakie fakty oraz w jakich wymia- Określenie zakresu analizy rach będą raportowane.

ROZDZIAŁ 2. RAPORTOWANIE 6 Drążenie/rozwijanie (ang. drill down) to przejście z danych bardziej ogólnych do bardziej szczegółowych. Przykładowo podczas analizy sprzedaży w poszczególnych latach można przejść do analizy wyników w miesiącach wybranego roku. Zwijanie (ang. drill up) to operacja odwrotna do rozwijania danych. Wycinanie (ang. slice) to filtrowanie danych. Obracanie jest to operacja związana z prezentacją danych. Polega ona na zamianie kolumn z wierszami. 2.1.6 Data mining [8] Eksploracja danych to ekstrakcja interesujących (nietrywialnych, niejawnych, wcześniej nieznanych i potencjalnie użytecznych) wzorców (wiedzy) z dużych zbiorów danych. Do najpopularniejszych zadań eksploracji danych należą: klasyfikacja, grupowanie oraz odkrywanie reguł asocjacyjnych. Klasyfikacja to dokonanie przypisania obiektu do jednej z predefiniowanych klas decyzyjnych na podstawie wartości jego atrybutów. Grupowanie to podział zbioru obiektów na grupy o podobnych właściwościach. Obiekty w tej samej grupie powinny być jak najbardziej do siebie podobne, natomiast w jak największym stopniu różnić się od obiektów w innych grupach. Odkrywanie reguł asocjacyjnych to wyszukiwanie zbiorów obiektów, które często występują razem w określonym kontekście. Wystąpienie jednego zbioru obiektów implikuje pojawienie się drugiego zbioru. 2.2 Istniejące rozwiązania Business Intelligence 2.2.1 Jaspersoft Jaspersoft to firma specjalizująca się w dostarczaniu rozwiązań klasy Business Intelligence. Do kluczowych produktów tej firmy należą: JasperReports, ireport, JasperServer oraz JasperETL. JasperReports [14] to biblioteka Open Source do tworzenia raportów w wielu popularnych formatach: PDF, HTML, XLS oraz XML. Została zaimplementowana w całości w technologii Java. Twórcy biblioteki przywiązali dużą uwagę do

ROZDZIAŁ 2. RAPORTOWANIE 7 elastyczności rozwiązania w podejściu do źródła danych oraz formatu wynikowego. Programista ma możliwość utworzenia własnej klasy dostarczającej danych lub odpowiedzialnej za eksport do formatu wynikowego. Oczywiście zostały przygotowane najczęściej używane źródła danych: połączenie z bazą danych, pliki w formatach: CSV, XLS oraz XML, obiekty POJO, Hibernate. Dla pliku wynikowego również zostały przygotowane klasy eksportujące raport do najbardziej popularnych formatów: PDF, XLS, HTML oraz XML. ireport [12] jest to narzędzie z graficznym interfejsem użytkownika służące do tworzenia raportów. JasperServer [15] to aplikacja WWW, której celem jest udostępnianie raportów użytkownikom. Wybrane funkcjonalności tej aplikacji to: prezentowanie raportów, zarządzanie uprawnieniami użytkowników, cykliczne odświeżanie raportów, eksportowanie raportów do wybranego formatu wynikowego. JasperETL [13] jest narzędziem wspierającym projektowanie procesów ETL. Użytkownik ma do dyspozycji zbiór komponentów pełniących określone zadania, przykładowo: plik źródłowy, plik wynikowy, odczyt/zapis do bazy danych, mapowanie danych. Budowanie procesu ETL polega na połączeniu tych komponentów w całość i dokonaniu ich konfiguracji. Cykl życia raportu [9] Rysunek 2.2: JasperReports - Cykl życia raportu Rysunek 2.2 przedstawia cykl życia każdego raportu. Pierwsza czynność to utworzenie szablonu raportu, czyli pliku w formacie XML. Zawiera on deklarację

ROZDZIAŁ 2. RAPORTOWANIE 8 elementów znajdujących się w raporcie. Po stworzeniu szablonu silnik Jasper- Reports dokonuje kompilacji raportu. W rezultacie powstaje raport w postaci skompilowanej. Taki plik przyjęło się nazywać jasper - od rozszerzenia. Następną fazą jest wypełnienie raportu danymi z źródła danych. Na samym końcu następuje wyeksportowanie raportu do wybranego formatu wynikowego. Szablon raportu Szablon raportu jest to plik w formacie xml. Zgodnie z przyjętą konwencją rozszerzenie pliku to jrxml. Każdy szablon zawiera dane o parametrach, polach oraz o elementach raportu. Struktura pliku jest następująca: <?xml version="1.0"?> <!DOCTYPE jasperreport PUBLIC "-//JasperReports//DTD Report Design//EN" "http://jasperreports.sourceforge.net/dtds/jasperreport.dtd"> <jasperreport name="name_of_the_report"... >... </jasperreport> Parametry to dane, które nie mogą być wydobyte z źródła danych. Częstym zastosowaniem parametrów jest określenie warunków zapytania. W przypadku szczególnym parametrem może być same zapytanie. Przykładowe parametry: Dynamiczny tytuł raportu. Wartości do warunków w zapytaniach. Nazwa użytkownika, który uruchomił raport. Parametr reprezentujący dynamiczny tytuł raportu może być zadeklarowany w następujący sposób: <parameter name="reporttitle" class="java.lang.string"/> Natomiast parametr, który jest identyfikatorem klienta do zapytania, może być zadeklarowany: <parameter name="customerid" class="java.lang.integer"/> W dalszej kolejności taki parametr może zostać użyty w warunku zapytania w następujący sposób: SELECT FROM Orders WHERE CustomerID = $P{ CustomerId }

ROZDZIAŁ 2. RAPORTOWANIE 9 Parametr może zostać umieszczony w raporcie poprzez zastosowanie następującej składni: $P{PARAMETER} Pola są to zmienne zmapowane z źródła danych na pola wykorzystywane w raporcie. Dla źródła danych w postaci bazy danych będą to po prostu kolumny zapytania. Każde pole deklarowane jest przy pomocy elementu field. Przykładowo, dla tabeli zawierającej cztery kolumny: EmployeeId, LastName, FirstName, HireDate należy zadeklarować następujące pola: <field name="employeeid" class="java.lang.integer"/> <field name="lastname" class="java.lang.string"/> <field name="firstname" class="java.lang.string"/> <field name="hiredate" class="java.util.date"/> Pole może zostać umieszczone w raporcie poprzez zastosowanie następującej składni: $F{FIELD} Wyrażenia są potężną funkjonalnością JasperReports. Umożliwiają one wykonanie złożonych obliczeń. Istnieje możliwość wykorzystania funkcji bibliotecznych: wykonanie obliczeń arytmetycznych, operacje na napisach oraz operacje na datach. W wyrażeniach można wykorzystać pola oraz zmienne. Przykładem wyrażenia jest dokonanie złączenia dwóch napisów: <textfieldexpression> $F{FirstName} + " " + $F{LastName} </textfieldexpression> Może to być także bardziej skomplikowane wyrażenie: <textfieldexpression> $F{FirstName} + " " + $F{LastName} + " was hired on " + (new SimpleDateFormat("MM/dd/yyyy")).format($F{HireDate}) + "." </textfieldexpression> Zmienne są specjalnym obiektem zbudowanym w oparciu o wyrażenie. Jeżeli istnieje potrzeba wykorzystania danego wyrażenia więcej jak jeden raz to należy utworzyć zmienną. Zmienna może przechowywać wartość agregacji jednego z mierników. Jako funkcje agregacji można wykorzystać: count, sum, average, lowest, highest, variance, etc. Przykład deklaracji zmiennej dokonującej policzenia sumy:

ROZDZIAŁ 2. RAPORTOWANIE 10 <variable name="quantitysum" class="java.lang.double" calculation="sum"> <variableexpression>$f{quantity}</variableexpression> </variable> Istnieje również szereg wbudowanych zmiennych. Poniżej trzy przykładowe: PAGE NUMBER numer aktualnej strony. COLUMN NUMBER numer aktualnej kolumny. PAGE COUNT liczba stron. Kompilacja Kompilacja to przekształcenie szablonu raportu w postaci pliku xml na postać binarną do formatu jasper. Wypełnienie Na tym etapie następuje podstawienie danych z źródła danych oraz parametrów. W ten sposób otrzymujemy postać raportu gotową do wyeksportowania. Eksport Eksport raportu jest to proces wygenerowania pliku w wybranej postaci wynikowej z wypełnionego raportu. Biblioteka udostępnia szereg eksporterów do popularnych formatów: pdf, html, xml, xls, csv, txt czy rtf. Pozycja Jaspersoft w raporcie Gartnera [10] Jaspersoft został doceniony przez analityków Gartnera, o czym świadczy pojawienie się tego rozwiązania wśród graczy niszowych platform Business Intelligence na rok 2011 (rysunek 2.3). Według raportu Gartnera ważnym elementem w wyborze platformy Business Intelligence w roku 2010 była cena rozwiązania. Jest to jeden z kluczowych powodów, dla których wśród rozwiązań komercyjnych pojawiło się rozwiązanie Open Source. Druga popularna platforma Open Source - Pentaho nie spełniła wszystkich warunków, aby zająć swoje miejsce wśród najlepszych rozwiązań Business Intelligence, aczkolwiek wedle analityków Gartnera, jest to opcja warta do rozważenia. Mocne strony Jaspersoft Jaspersoft oferuje platformę Open Source z szerokim wachlarzem możliwości. Składa się ona z JasperServer, JasperReports, ireport, JasperETL. Klienci mają możliwość umieszczenia raportów w swoich aplikacjach.

ROZDZIAŁ 2. RAPORTOWANIE 11 Rysunek 2.3: Magic Quadrant Gartnera dla Platform Business Intelligence na 2011 rok. Największa zaletą jest niski koszt. TCO 2 jest najniższy wśród wszystkich dostawców BI. Wedle opinii klientów koszt utrzymania tego rozwiązania jest poniżej średniej. Pomimo tego, że jest to rozwiązanie Open Source z niskim kosztem licencji planowany jest rozwój funkcjonalności, które nie są uwzględnione w większości konkurencyjnych rozwiązań. Wczesne sukcesy w dostarczaniu rozwiązań w chmurze (cloud computing). W 2010 roku JasperSoft uruchomiło platformę Jaspersoft Live, która umoż- 2 TCO Total Cost of Ownership. Całkowity koszt pozyskania, instalowania, użytkowania oraz utrzymania

ROZDZIAŁ 2. RAPORTOWANIE 12 liwia testowanie rozwiązań BI dostępnych w chmurze. Wysoki procent klientów JasperSoft zadeklarowało wdrożenie platformy w chmurze prywatnej lub publicznej. Jest to wynik wyższy niż konkurencyjnych rozwiązań. Ostrzeżenia Jaspersoft uważa się za lidera rozwiązań Open Source. Dane organizacji mówią o 13500 komercyjnych klientach co potwierdzają również dane dotyczące obrotów firmy. Jednakże tylko 20 klientów spełnia kryteria wyznaczone przez raport Gartnera. Wdrożenia Jaspersoft dotyczą firm mniejszej wielkości oraz mniejszego wolumenu danych niż większość rozwiązań zawartych w raporcie. Zakres wdrożeń częściej dotyczy konkretnego departamentu a nie całej organizacji. Jaspersoft najczęściej wdrażane jest w celach raportowych. Z tego powodu klienci twierdzą, że ta platforma jest mniej funkcjonalna niż rozwiązania konkurencyjne. Wsparcie techniczne oferowane przez firmę zostało ocenione nisko, pomimo tego, iż jest to kluczowy element strategii biznesowej firmy. Jaspersoft został nisko oceniony w zakresie prostoty kompenentów oraz prostoty integracji elementów platformy. 2.2.2 IBM Cognos 2.3 Podsumowanie Dostępne na rynku narzędzia zawierają wiele interesujących oraz przydatnych funkcji. Wspierają tworzenie zaawansowanych raportów. Aczkolwiek nie istnieje narzędzie idealne, które umożliwiałoby tworzenie raportów jeszcze bardziej zorientowanych na użytkownika. Raportów bardziej interaktywnych, które posiadają funkcje wbudowane funkcje sortowania, filtrowania, zwijania oraz rozwijania danych czy możliwość zmiany hierarchii grupowania. W poniższych sekcjach zostaną opisane cechy, które powinno posiadać idealne narzędzie raportujące. Prezentowanie raportów poprzez przeglądarkę Jest to ważne wymaganie, ponieważ użytkownicy mają dostęp do tych raportów z dowolnego miejsca w organizacji czy nawet na świecie - w zależności czy dana aplikacja dostępna jest poza granicami firmy. Wymaganie te ma również pozytywny wpływ na dzielenie się danymi. Z punktu widzenia administratorów utrzymanie, instalacja oraz zarządzanie zmianami w tego typu systemach jest łatwiejsze. Pakiet JasperSoft spełnia te wymaganie. Istnieje możliwość udostępnienia raportów w aplikacji JasperServer.

ROZDZIAŁ 2. RAPORTOWANIE 13 Dynamiczna hierarchia grupowania danych Na wstępie dokonano przegląd metod prezentacji danych w postaci tabelarycznej. Tabelka Najbardziej prymitywna metoda. Wszystkie dane prezentowane są w postaci tabeli dwuwymiarowej. W przypadku dużego wolumenu danych nie można nic wywnioskować z takiej postaci. Małym udoskonaleniem jest możliwość filtrowania oraz sortowania danych. Tabelka z pojedynczym poziomem grupowania Pogrupowanie danych według jednej z kolumn (np. produkt, rok, departament) oraz wyliczenie agregacji mierników na poziomie grup. Jest to udoskonalenie prostej tabelki, aczkolwiek czasami istnieje potrzeba pogrupowania według zawartości więcej niż jednej kolumny (wymiarze). Niektóre aplikacje zawierają nawet setki raportów w takiej postaci. Przykładem jest system Service Desk, który posiada następujące raporty: incydenty według serwisanta, incydenty według statusu, incydenty według priorytetu itd. Tabelka z wieloma poziomami grupowania Udoskonalenie poprzedniej metody umożliwiające utworzenie hierarchii grupowania, przykładowo rok, kwartał, miesiąc lub grupa produktu, produkt. Aczkolwiek liczba możliwych hierarchii grupowania jest olbrzymia, więc to użytkownik powinien mieć możliwość jej ustalenia. Tabelka z dynamiczną hierarchią grupowania Użytkownik sam decyduje według jakiej hierarchii chce oglądać dane. Ma możliwość zmiany hierarchii grupowania w dowolny sposób. Właśnie dlatego taka funkcja powinna być udostępniona bezpośrednio użytkownikom raportów, a nie tylko twórcom raportów, którzy są zobowiązani do utworzenia wszelkich możliwych kombinacji. Tworząc raporty przy pomocy JasperReports programista jest zobowiązany ustalić hierarcię grupowania. Użytkowik raportu nie ma możliwości zmienić tej hierarchii. Programista musi utworzyć drugi raport. Zamrażanie wierszy nagłówka oraz kolumn Jest to funkcjonalność dostępna w narzędziu Excel. Niestety jeszcze rzadko spotykana w technologiach WWW. Jest to bardzo wygodna funkcja dla użytkownika raportu, ponieważ w przypadku, gdy dane nie mieszczą się na pojedynczym ekranie monitora bardzo dużym utrudnieniem jest ciągłe przewijanie ekranu w celu zobaczenia pierwszej kolumny lub pierwszego wiersza danych. Dlatego też dodanie takiej funkcji do istniejących narzędzi jest bardzo pożądane. W narzędziu JasperReports problem ten został częściowo rozwiązany. Na każdej stronie raportu występują wiersze nagłówka. Nie jest to idealne rozwiązanie,

ROZDZIAŁ 2. RAPORTOWANIE 14 ponieważ zwiększa rozmiar raportu oraz nagłówki nie są umieszczone w tym samym miejscu na monitorze. JasperReports nie umożliwia zamrożenia pierwszej kolumny. Filtrowanie danych Wszystkie narzędzia umożliwiają filtrowanie danych, ale nie jest ono wystarczająco wygodne. Prawie zawsze istnieje potrzeba zdefiniowania formularza do filtrowania danych co jest czasochłonne oraz wymaga dodatkowej pracy. Dodatkowo trzeba zarządzać zmianami, gdy zostaną dodane jakieś atrybuty do istniejącego raportu. Wygodniejsze rozwiązanie zostało zrealizowane w narzędziu Excel. W tym rozwiązaniu użytkownik ma możliwość filtrownia danych po dowolnej z kolumn. Gdy dojdzie nowa kolumna do arkusza danych to nie trzeba wykonywać dodatkowej pracy przy konstrukcji formularza do filtrowania. Tworząc raport w JasperReports należy ręcznie skonstruować formularz do filtrowania danych poprzez zadeklarowanie parametrów oraz ich użycie w warunkach zapytania. JasperServer automatycznie poprosi użytkownika o podanie wartości parametrów. W przypadku użycia JasperReports w innej aplikacji programist musi samemu utworzyć formularz i przekazać wartości parametrów. Sortowanie danych Jest to funkcja, która bardzo często występuje. Aczkolwiek, gdy raport może zostać wyświetlony tylko w postaci pliku w formacie PDF to w naturalny sposób taka funkcja nie może zostać zrealizowana. Ze względu na format wynikowy raport utworzony w technologii JasperReports nie zawiera możliwości sortowania danych poprzez użytkownika. Nawet istnieją ograniczenia w posortowaniu danych poprzez programistę. Gdy zostanie ustalona hierarchia grupowania, narzędzie wymaga, aby dane źródłowe były posortowane według kolumn występujących w tej hierarchii. Przykładowo jeżeli raport jest pogrupowany według regionów oraz zespołów to dane również muszą być pogrupowane według tych dwóch kolumn. Raportowanie wewnątrz systemu Większość pakietów Business Intelligence wymaga udostępniania raportów w osobnym środowisku. Z punktu widzenia użytkownika jest to kolejny system, do którego musi się zalogować, pamiętać hasło dostępu oraz musi poświęcić swój czas na jego naukę. Dlatego też twórcy oprogramowania Business Intelligence zauważyli, że umieszczanie raportów bezpośrednio w aplikacjach WWW ma swoje zalety i jest wysoce pożądaną funkcją przez użytkowników. Istnieje możliwość umieszczenia raportu JasperReports wewnątrz aplikacji opartych o Spring framework, gdzie została przygotowana specjalna klasa widoku JasperView. Zwijanie/rozwijanie danych W przypadku wielkiego wolumenu danych, który zajmuję wiele ekranów monitora istnieje potrzeba schowania nie potrzebnych da-

ROZDZIAŁ 2. RAPORTOWANIE 15 nych. Powinno to działać jako ukrywanie całego poziomu drzewa utworzonego przez hierarchię grupowania. Użytkownik powinien mieć możliwość dowolnego zwijania oraz rozwijania gałęzi drzewa tak, aby były widoczne tylko takie dane, które są dla niego istotne. Pozwala to zaoszczędzić czas pracy użytkownika. Raport utworzony w JasperReports zawiera wszystkie dane od razu rozwinięte. Użytkownik nie ma możliwości ich zwijania oraz rozwijania. Jest to uciążliwe, gdy raport zajmuje kilkanaście/kilkadziesiąt stron co utrudnia znalezienie informacji. Export do XLS Wybrani użytkownicy powinni mieć możliwość wyeksportowania wszystkich danych raportu do pliku w formacie xls. JasperReports umożliwia wyeksportowanie raportu do większości popularnych wynikowych w tym XLS. Drukowanie raportu Raport powinien zawierać możliwość wydrukowania. W przypadku JasperReports istnieje możliwość wyeksportowania raportu do pliku w formacie PDF. Deklaratywny sposób tworzenia raportów Utworzenie raportu powinno nie wymagać ingerencji programisty, aby ten cel osiągnąć wymagane jest deklaratywne tworzenie raportów. Dodatkowo czynność ta powinna być wykonywana przez osobę, która nie musi posiadać dużej wiedzy informatycznej w tym nie musi znać modelu fizycznego bazy danych. Dlatego też raport powinien być tworzony w oparciu o model biznesowy, który jest zrozumiały przez analityków biznesowych. Przykładem takiego modelu jest świat obiektów występujący w narzędziu Business Objects. W wersji darmowej JasperReports użytkownik jest zobowiązany opierać tworzenie raportów o zapytania w języku SQL. Co wymaga znajomości schematu bazy danych. Wersja komercyjna zawiera możliwość utworzenia modelu biznesowego. Pobieranie tylko widocznych danych Do prezetacji raportu powinny zostać pobrane tylko takie dane, które są aktualnie widoczne dla użytkownika. Przede wszystkim pobranie wszystkich danych powiązanych z danym raportem może być zbyt czasochłonne ze względu na konieczność przejrzenia całej zawartości tabeli oraz czas transportu danych poprzez sieć. JasperReports wymaga pobrania wszystkich danych jednokrotnie na podstawie, których generowany jest plik wynikowy. W kolejnym rozdziale omówiono bibliotekę do tworzenia raportów spełniającą wyżej wymienione cechy.

Rozdział 3 Biblioteka W tym rozdziale zaprezentowano bibliotekę dla hierarchicznych raportów. Na wstępie przedstawiono wymagania stawianej takiej bibliotece z podziałem na wymagania użytkownika oraz twórcy raportów. Następnie omówiono przypadki użycia raportu. W kolejnej sekcji przedstawiono przykładowe bazy danych oraz raporty. Omówiono meta-model biznesowy oraz raportów łącznie z przykładami. W kolejnych sekcjach opisano projekt, implementację oraz przeprowadzone testy aplikacji. Na końcu zaprezentowano działającą aplikację z naciskiem na możliwości analizowania danych. 3.1 Wymagania 3.1.1 Wymagania funkcjonalne Perspektywa użytkownika Użytkownik korzystający z raportu, powinien mieć możliwość oglądania tylko takich danych, które go w danej chwili interesują. Powinien mieć możliwość wprowadzania dynamicznych zmian w raporcie: sortowania, zamrażania kolumn oraz zmiany hierarchii grupowania. Powinien mieć również możliwość wyeksportowania danych do pliku w formacie csv lub xls. Zatem biblioteka winna obsługiwać następujące rodzaje ingerencji i typy prezentacji na raportach: sortowanie wierszy; zwijanie/rozwijanie danych; filtrowanie danych; różne typy kolumn: waluta, data, wartość boolowska, odsyłacz; 16

ROZDZIAŁ 3. BIBLIOTEKA 17 dynamiczna zmiana hierarchii; eksport danych do pliku; zapisanie aktualnego stanu raportu; Perspektywa twórcy raportów Twórca raportu powinien mieć możliwość utworzenia nowego raportu w sposób deklaratywny a nie programowo. To założenie skraca czas pracy oraz zmniejsza liczbę błędów. Raporty powinny być możliwe do utworzenia dla osoby, która nie jest specjalistą z dziedziny informatyki. Utworzenie pliku XML, który reprezentuje model raportu. Do utworzenia modelu może zostać wykorzystane narzędzie z graficznym interfejsem użytkownika. Utworzenie pojedynczego raportu powinno trwać nie więcej niż kilkadziesiąt minut. Narzędzie powinno umożliwiać utworzenie modelu biznesowego (świat klas) w oparciu o który zostaną zbudowane raporty. 3.1.2 Wymagania niefunkcjonalne Zamrożenie pierwszych kolumn oraz nagłówka; Prezentacja tylko dostępnych danych - uprawnienia; Widok powinien pobierać tylko potrzebne dane, umożliwia to mniejsze obciążenie bazy danych oraz szybsze przesłanie danych przez sieć; Prezentacja raportu w postaci dynamicznej strony HTML; System powinien wspierać przeglądarki internetowe w podanych wersjach: Firefox 3.x, Google Chrome 3.x oraz Internet Explorer 6.x. 3.1.3 Przypadki użycia Aktorzy Użytkownik raportu to osoba korzystająca z raportu. Diagram przypadków użycia Rysunek 3.1 przedstawia przypadki użycia dostępne dla użytkownika raportów.

ROZDZIAŁ 3. BIBLIOTEKA 18 Rysunek 3.1: Przypadki użycia dla użytkownika raportu UC.DR Wyświetlenie raportu Przebieg zdarzeń Nr System Użytkownik 1. Użytkownik wybiera raport 2. System wyświetla raport UC.KR Korzystanie z raportu Przebieg zdarzeń Użytkownik wykonuje dowolną liczbę razy jedną z czynności: U C.SHOW.CHILDS, U C.HIDE.CHILDS, UC.F ILT ER, UC.SORT,

ROZDZIAŁ 3. BIBLIOTEKA 19 UC.EXP ORT, UC.HIERARCHY. Prototyp interfejsu użytkownika Rysunek 3.2: Główny panel raportu - prototyp UC.SHOW.CHILDS Rozwijanie danych Cel Użytkownik dla danego poziomu hierarchii grupowania w raporcie, chce zejść w dół, aby obejrzeć dane bardziej szczegółowe. W szczególności może być to pokazanie danych na najniższym poziomie. Przebieg zdarzeń Nr System Użytkownik 1. Klika w ikonkę krzyżyka w wierszu, który chce rozwinąć 2. System pokazuję dane szczegółowe dla wybranego elementu Wymagania niefunkcjonalne Pierwsze wyświetlenie elementów podrzędnych powoduje pobranie ich z serwera, natomiast kolejne pobierane są z pamięci podręcznej klienta.

ROZDZIAŁ 3. BIBLIOTEKA 20 UC.HIDE.CHILDS Ukrywanie danych Cel Użytkownik chce schować dane, w celu nie zakłócania dalszego korzystania z raportu. Przebieg zdarzeń Nr System Użytkownik 1. Klika w ikonkę w wierszu, dla którego chce schować szczegóły 2. System ukrywa wszystkie dane podrzędne. UC.FILTER Filtrowanie raportu Cel Użytkownik chce przefiltrować zbiór danych poprzez zadanie filtra na wybranych kolumnach. Przebieg zdarzeń Nr System Użytkownik 1. Wybiera opcję filtrowania danych 2. Definiuje filtr 3. Zatwierdza poprzez wybranie opcji filtruj 4. Pyta użytkownika, czy chce wyświetlić nowy raport 5. Potwierdza wyświetlenie nowego raportu 6. Wyświetla nowy raport z zadanym filtrem Prototyp interfejsu użytkownika UC.SORT Sortowanie Cel Użytkownik chce posortować według jednej z kolumn.

ROZDZIAŁ 3. BIBLIOTEKA 21 Rysunek 3.3: Budowanie filtru - prototyp Przebieg zdarzeń Nr System Użytkownik 1. Zaznacza kolumnę 2. System odświeża raport z posortowanymi danymi według zadanej kolumny UC.EXPORT Eksport do pliku Cel Użytkownik chce zapisać dane zawarte w raporcie do pliku. Przebieg zdarzeń Nr System Użytkownik 1. Wybiera opcję eksport do pliku 2. System wyświetla okienko z opcją pobrania pliku 3. Wybiera opcję zapisz plik UC.HIERARCHY Zmiana hierarchii grupowania Cel Użytkownik chce zmienić hierarchię, według której grupowane są dane.

ROZDZIAŁ 3. BIBLIOTEKA 22 Przebieg zdarzeń Nr System Użytkownik 1. Wybiera opcje zmiana hierarchii grupowania 2. System wyświetla formularz, w którym można wybrać listę atrybutów 3. Kolejno wybiera listę atrybutów 4. Wybiera opcję zakończ 5. Pyta użytkownika, czy chce wyświetlić nowy raport 6. Potwierdza 7. Wyświetla nowy raport Prototyp interfejsu użytkownika Rysunek 3.4: Hierarchia grupowania - prototyp 3.2 Przykładowe bazy danych W tej sekcji zostały opisane przykładowe bazy danych na podstawie, których zaprezentowano meta-model biznesowy, meta-model raportów oraz przykładowe raporty. 3.2.1 CRM Rysunek 3.5 przedstawia diagram tabel dla fragmentu bazy danych systemu typu CRM. Fragment ten dotyczy funkcjonalności kalendarza doradcy oraz kartoteki klientów. System umożliwia planowanie spotkań z klientami, generowanie raportów aktywności doradców, zarządzanie kalendarzem oraz wyszukiwanie klientów.

ROZDZIAŁ 3. BIBLIOTEKA 23 Rysunek 3.5: Diagram tabel dla systemu CRM

ROZDZIAŁ 3. BIBLIOTEKA 24 KLIENCI Tabela przechowująca dane o klientach oraz potencjalnych klientach, jest to rozróżniane po kolumnie CZY KLIENT. SEGMENTY Słownik z możliwymi segmentami klientów. ETAPY PROSPEKTOW Słownik z możliwymi etapami potencjalnych klientów. Przykładowe etapy to: nowy, klient zainteresowany, klient niezainteresowany, podpisana umowa. PRACOWNICY Tabela przechowująca dane o pracownikach organizacji. HIERARCHIA ORG Tabela przechowująca hierarchię organizacyjną. Kolumna NADRZEDNE ID jest kluczem obcym na jednostkę nadrzędną. HIERARCHIA PRACOWNIK Tabela zawiera dane o jednostkach organizacyjnych, które są widoczne dla danego pracownika. ZDARZENIA Tabela przechowująca kalendarz: telefony z klientami, spotkania z klientami oraz pozostałe zdarzenia. RODZAJE ZDARZEN Słownik z możliwymi rodzajami zdarzeń, np: spotkanie, telefon oraz urlop. STANY ZDARZENIA Słownik z możliwymi stanami zdarzeń: planowane, zamknięte oraz odrzucone. DANE FINANSOWE Tabela zawierająca dane finansowe na temat klientów: przychód, dochód, liczba zatrudnionych.

ROZDZIAŁ 3. BIBLIOTEKA 25 Rysunek 3.6: Diagram tabel dla zarządzania incydentami STATUSY PROSPEKTOW Słownik z możliwymi stanami potencjalnych klientów: nowy, po telefonie, po spotkaniu. 3.2.2 Service Desk Rysunek 3.6 przedstawia fragment bazy danych dla systemu Service Desk. Fragment ten dotyczy procesu zarządzania incydentami. System umożliwia zgłaszanie nowych incydentów klientom usługi. Pracownik pierwszej linii ma możliwość przy-

ROZDZIAŁ 3. BIBLIOTEKA 26 pisania się do incydentu. System umożliwia wyszukiwanie incydentów. System umożliwia dodawanie komentarzy dla incydentów. Baza danych została zaczerpnięta z pracy dyplomowej inżynierskiej autorstwa Piotra Kalańskiego [16]. INCIDENTS Tabela przechowująca informacje o incydentach. CATEGORIES IM Słownik z kategoriami incydentów. URGENCY TYPES IM Słownik z typami pilności incydentów. STATUSES IM Słownik z możliwymi statusami incydentów. PRIORITY TYPES IM Słownik z typami priorytetów incydentów. IMPACT TYPES IM Słownik z typami wpływów incydentów. COMMENTS Tabela z komentarzami dotyczącymi danego incydentu. Każdy komentarz zawiera datę dodania oraz autora. EMPLOYEES Tabela z pracownikami. Każdy incydent powiązany jest z pracownikami na dwa sposoby: pracownik, który zgłosił incydent, serwisant przypisany do incydentu. SUPPORT GROUPS Tabela z grupami wsparcia. Każdy incydent jest przypisany do jednej grupy wsparcia.

ROZDZIAŁ 3. BIBLIOTEKA 27 SERVICES Tabela zawierająca dane o usługach. Każdy incydent jest przypisany do jednej usługi. INCIDENT HISTORY Tabela zawierająca pełną historię zmian dla każdego incydentu. Zawiera datę dokonania zmiany, użytkownika, który dokonał zmiany oraz stan incydentu z tej chwili w czasie. 3.3 Przykładowe raporty 3.3.1 Service Desk Niektóre systemy Service Desk zawierają nawet setki raportów operacyjnych. Przykładowo dla procesu zarządzania incydentami istnieją następujące raporty: incydenty według kategorii, incydenty według grupy wsparcia, incydenty według priorytetu, incydenty według statusu, incydenty według priorytetu oraz incydenty według serwisanta. Wszystkie te raporty są do siebie bardzo podobne. Różnią się jedynie atrybutem według którego grupowane są dane. Taka liczebność raportów jest uciążliwa dla użytkownika, ponieważ nikt nie ma czasu przeglądać takiego ogromu informacji. Incydenty Tabela?? przedstawia kolumny raportu dotyczącego incydentów. Zrealizowana biblioteka umożliwia utworzenie jednokrotnie raportu, który daje możliwość użytkownikowi wyboru atrybutów według których zostaną zgrupowane dane. Co więcej użytkownik ma możliwość podania wielu atrybutów, które będą tworzyć hierarchię grupowania. Przykładowo istnieje możliwość pogrupowania incydentów według grupy wsparcia oraz przypisanego specjalisty lub według grupy wsparcia oraz priorytetu. Menedżer incydentów ma również możliwość ustalenia hierarchii priorytet->grupa wsparcia, w celu uzyskania informacji o grupach wsparcia, które rozwiązuję najpilniejsze zgłoszenia. Proste raportowanie operacyjne nie daje takich możliwość, ponieważ liczba potencjalnych raportów rośnie wykładniczo. 3.3.2 CRM Spotkania Tabela 3.2 przedstawia kolumny raportu dotyczącego spotkań. Przykładowe analizy, które umożliwia ten raport:

ROZDZIAŁ 3. BIBLIOTEKA 28 Kolumna w raporcie Tabela Kolumna Incydent ID INCIDENTS INCIDENT ID Status STATUS TYPES IM NAME Kategoria CATEGORIES IM NAME Priorytet PRIORITY TYPES IM NAME Temat INCIDENTS SUBJECT Data dodania INCIDENTS CREATION DATE Grupa wsparcia SUPPORTS GROUPS NAME Serwisant EMPLOYEES LAST NAME Tabela 3.1: Raport incydenty Spotkania klienta Jeżeli jednym z atrybutów grupujących jest klient, to pod nim będą prezentowane wszystkie spotkania spełniające zadane kryterium (np: zakres dat). Menedżer dowolnego szczebla ma możliwość bezpośrednio pod swoją jednostką wyświetlenia wszystkich klientów lub może ich pogrupować według jednostki podrzędnej. Przykładowo dyrektor regionu pod swoim regionem może widzieć wszystkich klientów przypisanych do tego regionu, ale może również pogrupować ich według oddziałów. Spotkania doradcy W tym przypadku atrybutem grupującym jest doradca. Użytkownika mniej interesuje z jakimi klientami były spotkania, ale ważne jest dla niego kto na tych spotkaniach był. Menedżer ma możliwość obejrzenie aktywności swoich doradców na wiele sposobów. Przykładowo może zdecydować się na dodatkowe pogrupowanie spotkań wedle miesiąca spotkania, co umożliwi mu sprawdzenie aktywności doradców w poszczególnych miesiącach. Dodatkowo każdy menedżer ma możliwość dołączenia jednostek podrzędnych wedle, których chce dokonać dodatkowego pogrupowania. Kolumna w raporcie Tabela Kolumna Centrala HIERARCHIA NAZWA Region HIERARCHIA NAZWA Oddział HIERARCHIA NAZWA Doradca PRACOWNICY NAZWISKO Klient KLIENCI NAZWA Data spotkania ZDARZENIA DATA ZDARZENIA Temat ZDARZENIA TEMAT Opis ZDARZENIA OPIS Tabela 3.2: Raport spotkania

ROZDZIAŁ 3. BIBLIOTEKA 29 Baza potencjalnych klientów 3.4 Meta-Model W tej sekcji został przedstawiony meta-model biznesowy. Model biznesowy tworzony jest przez osobę znającą strukturę relacyjnej bazy danych. Na podstawie tego modelu projektant może utworzyć nowy raport. Został również zaprezentowany meta-model raportów. 3.4.1 Meta-model biznesowy Rysunek 3.7: Meta-model biznesowy Rysunek 3.7 przedstawia meta-model dla modelu biznesowego. Jest on tworzony przez osobę znającą zawartość bazy danych. Pojęciem podstawowym jest

ROZDZIAŁ 3. BIBLIOTEKA 30 klasa, która jest mapowana na tabele w relacyjnej bazie danych, natomiast jej atrybuty na wyrażenia oparte na kolumnach tych tabel. DomainClass jest elementem meta-modelu reprezentującym klasę. Jeden z atrybutów tablename wskazuję na tabelę lub perspektywę. Każdy obiekt DomainClass zawiera listę atrybutów, które są typu dziedziczącego z DomainAttribute. DomainAttribute jest klasą bazową dla poszczególnych typów atrybutów. Każdy z tych atrybutów zawiera nazwę. SimpleAttribute jest to najprostszy typ atrybutu. Najczęściej jest to mapowanie na jedną z kolumn, ale również może to być wyrażenie SQL wyliczone na podstawie grup kolumn. Przykładem wyrażenia jest złączenie kolumn imię oraz nazwisko. ReferenceAttribute jest to typ atrybutu, który jest referencją na inną klasę. Jest to odpowiednik kluczy obcych w relacyjnych bazach danych. Przykładowo klasa Klient może zawierać referencję na klasę Doradca, co odpowiada relacji pomiędzy klientem banku oraz jego doradcy. DictionaryAttribute jest to specjalny rodzaj ReferenceAttribute, który wskazuję na atrybut innej klasy, a nie na całą klasę. Ten rodzaj atrybutu nie jest niezbędny, ale jest ułatwieniem dla twórcy raportów, który może wykonać mniej czynności przy tworzeniu raportu. DictionaryAttribute został stworzony z myślą o tabelach słownikowych, które zwykle zawierają dwie kolumny: identyfikator/kod oraz nazwę. W takim przypadku istnieje tylko jedna kolumna, która może zostać wyświetlona w raporcie, więc twórca raportu nie musi tracić czasu na jej wybranie. 3.4.2 Przykładowy model biznesowy Na podstawie bazy danych opisanej w sekcji 3.2.1 przedstawiono przykładowy model biznesowy. Został on zaprezentowany na rysunku 3.8. Fragment modelu został również przedstawiony w postaci diagramu obiektów (rysunek: 3.9). Widoczna jest tam klasa Klient z czterema atrybutami: klient id, nazwa, segment oraz DaneFinansowe. Podstawową klasą modelu jest Klient, która odpowiada tabeli KLIENCI. Kluczem głównym klasy jest klient id. Atrybuty: nazwa, NIP, telefon oraz data podp umowy są typu SimpleAttribute, mapowane są na odpowiednie kolumny tabeli KLIENCI. Atrybut DaneFinansowe jest typu ReferenceAttribute. Wskazuje on na klasę DaneFinansowe przy pomocy klucza obcego: KLIENT ID. Przykładem atrybutu typu DictionaryAttribute jest segment, który jest odwo-

ROZDZIAŁ 3. BIBLIOTEKA 31 Rysunek 3.8: Przykładowy model biznesowy łaniem na atrybut nazwa klasy Segment. Kolumną wykorzystaną przy złączeniu z tabelą SEGMENTY jest SEGMENT ID. Kolejne przykłady atrybutów typu DictionaryAttribute to: doradca, oddzial oraz region. Wszystkie trzy pochodzą z klasy Doradca. Tutaj mogą pojawić się wątpliwości związane z istnieniem redundancji aż trzech połączeń między klasami. Po pierwsze wydaję się, że należy wykonać dodatkową pracę przy tworzeniu modelu biznesowego. Oczywiście stwierdzenie to jest prawdziwe, aczkolwiek czynność ta wykonywana jest jednokrotnie. Natomiast dla danego modelu biznesowego może istnieć wiele raportów, w których będą występować atrybuty: doradca, oddzial oraz region. Przeniesienie tych atrybutów do klasy Klient wpływa pozytywnie na skrócenie czasu pracy projektanta raportów, ponieważ nie musi wskazywać na atrybuty pochodzące z klas: Oddzial lub Region, natomiast może wskazać bezpośrednio atrybuty z klasy Klient. Dodatkowo, gdy dla danego modelu biznesowego istnieje cykl, tak jak dla modelu przykładowego między klasami: Klient, Doradca oraz Spotkanie, to może pojawić się problem w ustaleniu w jaki sposób dostać się do atrybutu nazwa z klasy Doradca. Dla klasy Spotkanie istnieją dwie ścieżki:

ROZDZIAŁ 3. BIBLIOTEKA 32 Rysunek 3.9: Diagram obiektów dla przykładowego modelu biznesowego bezpośrednia oraz przez klasę Klient. Gdyby w tabeli klienci nie istniał atrybut doradca to projektant musiałby za każdym razem wskazywać, którą ścieżkę chce wybrać, co wiążę się z wydłużeniem czasu pracy. Druga wątpliwość związana jest z wydajnością. Czy silnik biblioteki wygeneruję zapytanie, które trzykrotnie łączy tabelę KLIENCI z tabelą PRACOWNICY? Odpowiedź jest negatywna, ponieważ sytuacja ta zostanie wykryta i zostanie wykonane tylko jedno złączenie. Reasumując rodzaj atrybutu DictionaryAttribut został utworzony w celu skrócenia czasu pracy projektanta raportów. 3.4.3 Meta-model raportu Na rysunku 3.10 został przedstawiony meta-model raportów. Raport składa się z wielu kolumn, które są typu pochodnego z ReportColumn. Każda z nich jest powiązana z atrybutem klasy. Raport zawiera wskazanie na klasę, względem której ustalane są jego kolumny. SimpleReportColumn jest to prosta kolumna, która jest powiązana z obiektem typu SimpleAttribute. ReferenceReportColumn Obiekty tego typu tworzą ścieżkę, która wskazuję atrybut docelowy. Ścieżka ta rozpoczyna się w głównej klasie (wskazanej przy pomocy mainclass). Każdy węzeł ścieżki powiązany jest z atrybutem meta-modelu klas:

ROZDZIAŁ 3. BIBLIOTEKA 33 Rysunek 3.10: Meta-model raportu ReferenceAttribute. Wyjątkiem jest ostatni element, który jest typu SimpleReportColumn, czyli wskazuję na obiekt typu SimpleAttribute. Taki rodzaj kolumny jest potrzebny, ponieważ w modelu biznesowym mogą być cykle. Z czego wynika istnienie wielu ścieżek pomiędzy dwiema klasami. W takim przypadku projektant raportu zostanie poproszony o wybranie jednej z tych ścieżek. Przykładowy model biznesowy opisany w sekcji 3.4.2 zawiera cykl

ROZDZIAŁ 3. BIBLIOTEKA 34 pomiędzy klasami: Spotkanie, Doradca oraz Klient. 3.4.4 Przykładowy raport Na podstawie modelu biznesowego omówionego w sekcji 3.4.2 przedstawiono realizację raportu Spotkania zaprezentowanego w sekcji 3.3. Kolumna w raporcie Klasa Atrybut Region Klient region Oddział Klient oddzial Doradca Klient doradca Klient Klient nazwa Data spotkania Spotkanie data Temat Spotkanie temat Opis Spotkanie opis Tabela 3.3: Raport spotkania - realizacja Rysunek 3.11 przedstawia diagram obiektów dla fragmentu tego raportu. Obiekt klasy Report reprezentuję model. Powiązany jest on z klasą Spotkanie. Na rysunku widoczne są dwie kolumny raportu: temat oraz klient. Pierwsza jest typu ReportSimpleColumn i wskazuję na atrybut temat klasy Spotkanie, natomiast druga jest typu ReportReferenceColumn, ponieważ wskazuje na atrybut innej klasy niż klasa mainclass. Widoczna jest tutaj ścieżka od klasy Spotkanie do atrybutu nazwa z klasy Klient, która reprezentowana jest przy pomocy klas: ReportReferenceColumn oraz ReportSimpleColumn. 3.5 Projekt Zrealizowana aplikacja została podzielona na pod projekty co odzwierciedla modułową budowę. Pierwszy projekt jest związany z modelem. Zawiera on klasy reprezentujące model biznesowy, który został opisany w sekcji 3.4 oraz model raportów (3.4.3). Podstawowe zadanie tego modułu to generowanie zapytania na podstawie dostarczonego modelu. Drugi projekt związany jest z prezentacją raportów. Zawiera on klasy dotyczące interfejsu użytkownika. Projekt ten również odpowiada za komunikację warstwy klienta z warstwą serwera, która korzysta z usług klas dostarczonych w modelu. 3.5.1 Model Na rysunku 3.12 został przedstawiony diagram pakietów dla modułu związanego z modelem.

ROZDZIAŁ 3. BIBLIOTEKA 35 Rysunek 3.11: Diagram obiektów dla raportu Spotkania edu.pw.treegrid.server.classmodel zawiera klasy reprezentujące model biznesowy. Jest to klasa biznesowa, która zawiera listę atrybutów. edu.pw.treegrid.server.reportmodel pakiet, który zawiera klasy związane z modelem raportów. Jest to klasa Raportu oraz kolumny raportu. edu.pw.treegrid.server.filter klasy związane z filtrowaniem danych. edu.pw.treegrid.server.query zadaniem tego pakietu jest generowanie zapytania SQL dla danego raportu przy ustalonym kryterium oraz dla określonej hierarchii grupowania. edu.pw.treegrid.server.service w tym pakiecie dostępne są klasy dostarczające usługi do operacji na modelu. Klasa XMLMarshaller odpowiedzialna jest za serializację oraz deserializację modelu do plików w formacie XML. Natomiast klasa TreeServiceImpl udostępnia usługi związane z pobieraniem modelu raportu oraz pobieraniem danych dla raportu. 3.5.2 Web edu.pw.treegrid.client.report.controller Pakiet pełniący rolę kontrolera z wzorca projektowego MVC (Model View Controller). Do jego głównych zadań należy

ROZDZIAŁ 3. BIBLIOTEKA 36 Rysunek 3.12: Model - diagram pakietów obsługa akcji użytkownika. edu.pw.treegrid.client.report.view Pakiet zawierający klasy związane z warstwą prezentacji: okno z ustawieniami, panel raportu czy okno pomocy. edu.pw.treegrid.client.format W tym pakiecie są klasy odpowiedzialne za formatowanie danych: format liczbowy oraz format daty. edu.pw.treegrid.client.report.model Pakiet zawierający źródła danych, które komunikują się z serwerem. Klasy te są typu DataSource. edu.pw.treegrid.client.report.events Zdarzenia zachodzące w aplikacji. edu.pw.treegrid.server.web Główną klasą pakietu jest ReportServlet, która odpowiada za obsłużenie zadań klienta. Komunikacja klienta z serwerem opisano w sekcji 3.6.2.

ROZDZIAŁ 3. BIBLIOTEKA 37 Rysunek 3.13: Klient - diagram pakietów Rysunek 3.14: Serwer - diagram pakietów edu.pw.treegrid.server.view XLS. Klasa odpowiedzialna za utworzenie pliku w formacie edu.pw.treegrid.server.converters Klasy, których zadaniem jest konwersja obiektów danego typu na obiekty typu Record, które następnie są przekształcane do formatu XML przesyłanego w odpowiedzi na żądania klienta.

ROZDZIAŁ 3. BIBLIOTEKA 38 Rysunek 3.15:

ROZDZIAŁ 3. BIBLIOTEKA 39 Rysunek 3.16:

ROZDZIAŁ 3. BIBLIOTEKA 40 3.5.3 Diagramy sekwencji W sekcji tej opisano przykładowe diagramy sekwencji związane z rozwijaniem danych. Przedstawiono zarówno warstwę klienta oraz serwera. Diagramy zostały zaprezentowane na podstawie klas analitycznych nie związanych z konkretną technologią. Diagram na rysunku 3.15 przedstawia operacje wykonywane po stronie w wyniku na akcję użytkownika rozwinięcia danych szczegółowych. Po kliknięciu na przycisk do rozwijania danych zostanie wywołana metoda onclick() klasy TreeGridController, która pełni rolę kontrolera według wzorca projektowego MVC. Następnie kontroler przekazuję żądanie do modelu TreeGridModel wywołując metodę togglechilds(), której odpowiada za zwijanie oraz rozwijanie danych. Model dokonuje sprawdzenia czy jest to operacja rozwinięcia czy zwinięcia danych. W przypadku rozwinięcia danych model również sprawdza, czy potrzebne dane zostały już wcześniej pobrane z serwera. Jeżeli potrzebna jest komunikacja z warstwą serwera model dokonuje utworzenia obiektu żądania Request. W pierwszym kroku należy ustalić identyfikator wiersza co jest dokonywane poprzez metodę getpath(). W kolejnym kroku zostaje wywołana metoda fetchchilds() klasy TreeGridService. Po otrzymaniu odpowiedzi od serwera zostaje wywołana metoda notifystatechanged(), która oznacza zmianę stanu klienta. Metoda ta dokonuje powiadomienie klasy widoku TreeGridView poprzez metodę onmodelstatechanged() o zmianie stanu modelu. Metoda onmodelstatechanged() powoduje odświeżenie widoku poprzez wywołanie metody repaint(), która usuwa wszystkie wiersze widoku - metoda cleartable() oraz dodaje nowe wiersze addrows() pobrane wcześniej od modelu przy pomocy metody getvisibleobjects(). Drugi diagram widoczny na rysunku?? przedstawia stronę serwera tej samej operacji opisanej powyżej. W wyniku żądania klienta zostaje wywołana metoda fetchchilds() klasy TreeGridService. W pierwszym kroku zostaje odczytany model z plików XML za pomocą metody unmarshall() klasy XMLMarshaller. Następnie zostaje wygenerowane zapytanie SQL co jest wykonane w metodzie generatequerytree() klasy QueryGenerator. W dalszej kolejności zostanie wywołana metoda fetch() klasy DataSource, która odpowiada za komunikację z bazą danych. W wyniku zostanie zwrócona lista wierszy, która musi zostać następnie przetransformowana do postaci zwracanej do klienta. 3.6 Implementacja Sekcja ta zawiera omówienie wybranych problemów implementacyjnych: generowanie zapytania SQL, komunikacji klienta z serwerem oraz serializacji do formatu XML. Następnie została opisana wybrana technologia oraz wykorzystane narzędzia.

ROZDZIAŁ 3. BIBLIOTEKA 41 3.6.1 Generowanie zapytania Rysunek 3.17: Diagram obiektów dla generowania zapytania Na podstawie modelu biznesowego omówionego w sekcji 3.4 generowane jest zapytanie w języku SQL. W etapie pośrednim tworzone jest drzewo, które umożliwia wygenerowanie polecenia SELECT. Dla każdej kolumny raportu można utworzyć ścieżkę postaci: TABELA 1,..., TABELA N, KOLUMNA. Pierwsza tabela jest bezpośrednio związana z danym raportem poprzez główną klasę raportu, przykładowo Klient. Poszczególne tabele na tej liście reprezentują złączenia klucza głównego z kluczem obcym, aż do otrzymania TABELI N, która zawiera poszukiwaną kolumnę. Na podstawie wszystkich tabel oraz ich kolumn można utworzyć graf, w którym połączenia reprezentują powiązania pomiędzy poszczególnymi tabelami. W takim grafie poszukiwana ścieżka od źródłowej tabeli do kolumny docelowej jest to najkrótsza ścieżka, którą można znaleźć przy pomocy algorytmu DFS 1. Po utworzeniu wszystkich ścieżek dla każdej kolumny w raporcie należy je ze sobą połączyć w jedno drzewo, przykładowo postać widoczna jest na rysunku 3.16. W tym celu została zaimplementowana metoda, która potrafi wstawić ścieżkę do drzewa. Przy tej operacji należy uwzględnić fakt, że poszczególne ścieżki mogą mieć taki sam początek, czyli jedna ścieżka jest prefiksem drugiej. Gdy taka sytuacja zachodzi to należy taką ścieżkę podzielić na dwie oraz wstawić do drzewa koniec ścieżki do odpowiedniego węzła. Pozwala to uniknąć powstawania duplikatów w drzewie co w etapie końcowym doprowadziło do wielokrotnych złączeń pomiędzy tymi samymi tabelami co oczywiście ma negatywny wpływ na wydajność. W ostatnim kroku algorytmu wystarczy z postaci drzewiastej wygenerować odpowiednie zapytanie SQL, co jest już operacją prostą. Powiązania pomiędzy węzłami reprezentują złączenia pomiędzy tabelami, natomiast węzły z kolumnami są uwzględnione przy generowaniu klauzuli SELECT. 1 Depth First Search

ROZDZIAŁ 3. BIBLIOTEKA 42 3.6.2 Komunikacja klient - serwer Komunikacja między klientem a serwerem jest oparta o format XML. Na wszystkie żądania klienta, serwer zwraca plik XML, który ma postać przedstawioną na poniżej: - <response> <status>0</status> - <data> + <record></record> + <record></record> + <record></record> </data> </response> Element record zawiera listę elementów podrzędnych o dowolnych nazwach. Lista ta odpowiada strukturze mapy, gdzie nazwa elementu jest kluczem natomiast zawartość elementu jest wartością. Po stronie klienta zaimplementowano klasy dziedziczące z klasy RestDataSource z biblioteki SmartGWT. Komunikacja pomiędzy klientem oraz serwerem zgodna z tą biblioteką jest szczegółowo opisana w dokumentacji technicznej dostępnej na stronie [23]. 3.6.3 Serializacja do formatu XML Za serializację modelu odpowiada klasa XMLMarshaller. Zawiera ona następujące metody dokonujące serializacji oraz deserializacji: serializereport() dokonuje zapisania raportu do pliku XML, deserializereport() wczytuje raport z pliku XML, serializeclasses() zapisuje model biznesowy do pliku XML, deserializeclasses() wczytuje model biznesowy z pliku XML. Każda klasa modelu: raport, kolumna raportu, klasa biznesowa czy atrybut klasy zawiera metody serializetoxml() oraz deserializefromxml(), które odpowiadają za zapisanie oraz odczytanie danych do/z pliku XML. Taki wzorzec projektowy umożliwia hermetyzację tej operacji w poszczególnych klasach. Każda z nich posiada najlepszą wiedzę jak dokonać tej czynności. W przypadku dokonania zmiany, przykładowo dodanie atrybutu, wystarczy zajrzeć do jednego pliku źródłowego i dokonać modyfikacji tych dwóch metod.

ROZDZIAŁ 3. BIBLIOTEKA 43 3.6.4 Technologia GWT [3] Google Web Toolkit to technologia której celem jest tworzenie aplikacji WWW bez potrzeby programowania w HTML oraz JavaScript. Programista tworzy aplikację w języku Java, następnie kompilator GWT dokonuje transformacji kodu źródłowego do JavaScript, którego celem jest utworzenie dynamicznej strony HTML. Tworzenie aplikacji w GWT bardziej przypomina tworzenie tradycyjnych aplikacji okienkowych niżeli aplikacji WWW. Cała aplikacja jest jedną stroną WWW, klient musi tylko raz pobrać kod JavaScript. Następnie przy komunikacji warstwy klienta z warstwą serwera, która inicjowana jest poprzez zdarzenia akcji użytkownika takie jak kliknięcie w guzik, dokonywane są zmiany w interfejsie. Cała aplikacja oparta jest na okienkach a nie na stronach. Autor zdecydował się na wybranie tej technologii ze względu na bibliotekę SmartGWT, która zawiera gotowe klasy do tworzenia interfejsu użytkownika. SmartGWT [22] to biblioteka napisana w technologii GWT. Składa się z listy komponentów na podstawie których programista ma możliwość implementowania aplikacji z bogatym interfejsem użytkownika. Warstwę prezentacji części praktycznej pracy magisterskiej zrealizowano na podstawie komponentu TreeGrid. Jest to widok, który umożliwia wyświetlenie drzewa zawierającego kolumny. Do funkcjonalności tej klasy należą: sortowanie danych, zwijanie/rozwijanie danych, zamrażanie wierszy nagłówka oraz zamrażanie kolumn. Zrealizowane prace rozbudowały możliwości tego widoku dodając integrację z warstwą serwera, której celem jest dostarczanie danych poprzez generowanie zapytania SQL. Przy realizacji warstwy prezentacji wykorzystano również klasy do konfiguracji filtrowania oraz klasy z listą obiektów, na której widoczne są kolumny raporty do ustalenie hierarchii grupowania. 3.6.5 Narzędzia IBM Rational Software Architect to narzędzie do tworzenia diagramów UML na etapach analizy oraz projektowania oprogramowania. Przy pomocy tego narzędzia zrealizowano projekt aplikacji. Utworzono diagramy komponentów, klas, obiektów, sekwencji oraz przypadków użycia. W załączonej płycie CD znajduje się wygenerowana dokumentacja z Rational Software Architect. Spring SourceToolSuite jest narzędziem opartym na platformie Eclipse, składającym się z szeregu wtyczek (ang. plugin). Głównym wykorzystaniem narzędzia jest tworzenia aplikacji w Java EE. Autor najczęściej korzystał z następujących wtyczek: Subclipse, Mylyn, Web Tools Platform, GWT Plugin oraz Cobertura. Subclipse [25] jest to wtyczka, która umożliwia wykonywanie poleceń SVN z poziomu platformy Eclipse.

ROZDZIAŁ 3. BIBLIOTEKA 44 Mylyn [6] to narzędzie do zarządzania zadaniami. Przy realizacji danego zadania automatycznie zostaje zapamiętany kontekst bezpośrednio z nim związany: wszystkie metody, atrybuty itd. Po powrocie do wybranego zadania narzędzie automatycznie ogranicza pliki źródłowe w widoku Navigator do tych, które zostały wcześniej zapamiętane. Dzięki temu programista może się koncentrować na tym co jest istotne przy realizacji wybranego zadania. Web Tools Platform [4] języku Java. jest platformą do tworzenia aplikacji WWW w Cobertura [2] to wtyczka umożliwiająca obliczenie pokrycia kodu w testach jednostkowych oraz funkcjonalnych. Apache Maven [1], [21] to narzędzie kompilacji Javy zaprojektowane z myślą i automatyzacji najtrudniejszych zadań związanych z procesem kompilacji. W przeciwieństwie do Anta zastosowano model deklaratywny, w którym struktura i zawartość projektu są opisywane zamiast modelu zadaniowego. Maven oferuje również wiele innych funkcjonalności. Zależności projektu są deklarowane i zarządzane w jasny sposób. Narzędzie automatycznie pobiera wymagane biblioteki z repozytorium Mavena uwzgledniając zależności przechodnie. Maven umożliwia również generowanie czytelnej, wysokiej jakości dokumentacji technicznej oraz różnego rodzaju raportów. W załączonej płycie CD umieszczono wszystkie wygenerowaną stronę projektu oraz raporty. Użyto następujących raportów: Checkstyle, Cobertura Test Coverage, CPD Report, FindBugs Report, JavaDocs, JDepend, Maven Surefire Report, PMD Report oraz Tag List. Checkstyle [17] to narzędzie, które pomaga programistom pisać kod zgodny z ogólnie przyjętymi standardami. Raport generowany zawiera listę ostrzeżeń lub błędów, które odbiegają od norm. Cobertura Test Coverage [2] poprze testy jednostkowe. utworzony raport zawiera pokrycie kodu CPD Report [18] to narzędzie wykrywa powtarzające się fragmenty kodu, które łamią zasadę DRY (Dont Repeat Yourself). FindBugs Report [7] w kodzie źródłowym. narzędzie, którego celem jest znalezienie defektów JavaDocs to narzędzie do generowania dokumentacji technicznej. Autor dodatkowo zintegrował JavaDoc z narzędziem UmlGraphDoc [27], które dla każdej klasy generuje diagram kontekstowy zawierający wszystkie powiązane klasy.

ROZDZIAŁ 3. BIBLIOTEKA 45 Po kliknięciu w klasę na tym diagramie użytkownik zostanie automatycznie przeniesiony do jej dokumentacji. JDepend [19] jest narzędziem, które generuje raport dotyczące zbioru metryk na temat kodu źródłowego. Umożliwia to automatycznie zmierzenie jakości projektu w takich aspektach jak utrzymanie, ponowne wykorzystanie czy rozwijanie. Wybrane metryki to: liczba klas, liczba pakietów zależnych od danego pakietu, liczba pakietów od których dany pakiet zależy, współczynnik klas abstrakcyjnych do klas konkretnych. raport o szczegółowych rezultatach testów jed- Maven Surefire Report nostkowych. PMD Report kolejny raport badający defekty w kodzie źródłowym. Tag List [20] raport zawierający informacje o znacznikach użytkownika w kodzie źródłowym. Przykładowo o znacznikach typu TODO. 3.7 Testy i ocena 3.7.1 Środowiska testowe System był testowany na następujących środowiskach: Środowisko 1 System operacyjny: Windows 7 Ultimate 64 bitowy Procesor: Intel Core(TM) i5 CPU 750 2,67 GHz RAM: 4,00 GB Baza danych: Oracle 10g Express Edition Kontener serwletów: SpringSource tc Server v6.0 JDK: jdk1.6.0 17 (64 bitowa) Środowisko 2 System operacyjny: Windows 7 Professional 64 bitowy Procesor: Intel Core(TM) i3 CPU M350 2,27 GHz RAM: 4,00 GB

ROZDZIAŁ 3. BIBLIOTEKA 46 Baza danych: Oracle 10g Express Edition Kontener serwletów: Apache Tomcat 6.0.29 JDK: jdk1.6.0 21 3.7.2 Generacja danych Do generacji danych testowych wykorzystano narzędzie databene benerator [5]. Jest to framework służący do generowania danych testowych. Opis generowanych danych jest zawarty w pliku w formacie XML. Użytkownik ma możliwość generowania danych testowych według wybranego rozkładu funkcji prawdopodobieństwa. Przydatną funkcją jest lista encji, która służy do generowania danych typu: adres, telefon, imię, nazwisko, nazwa firmy, strona WWW. Wszystkie wyżej wymienione generatory wykorzystano w testach związanych z bazą klientów. Dla testów jednostkowych zostały przygotowane pliki w formacie CSV, które zawierają dane specjalnie przygotowane do tego rodzaju testów. Natomiast dla testów funkcjonalnych dane generowane są w sposób losowy. Użytkownik może w bardzo prosty sposób manipulować wolumenem danych poprzez ustawienie odpowiedniej liczby wygenerowanych wierszy. 3.7.3 Testy jednostkowe Dla zrealizowanej aplikacji został przygotowany zestaw testów jednostkowych. Rysunek 3.17 pokazuje ich pokrycie. Autor w początkowym etapie rozwoju aplikacji tworzył ją zgodnie z techniką TDD 2. Jest to najlepsza technika do tworzenia testów jednostkowych, ponieważ powinny one powstawać równolegle z kodem aplikacji. W przypadku tej techniki powstają nawet przed utworzeniem kodu. Testy jednostkowe umożliwiły wykrycie drobnych błędów, które zostały zidentyfikowane szybciej niż przy pomocy testów funkcjonalnych. Testy jednostkowe zdecydowanie ułatwiają wprowadzanie zmian do istniejącego kodu, ponieważ w momencie popełnienia błędu zostanie on szybko wykryty poprzez zrealizowany zestaw testów. 3.7.4 Testy funkcjonalne Przy testach funkcjonalnych oddzielnie sprawdzono warstwę serwera oraz klienta. W pierwszej kolejności dokonano weryfikacji serwera, ponieważ klient bazuje na danych dostarczanych przez serwer. W poszczególnych paragrafach przedstawiono przykładowe testy funkcjonalne na podstawie bazy danych systemu CRM. 2 TDD Test-driven development

ROZDZIAŁ 3. BIBLIOTEKA 47 Rysunek 3.18: Pokrycie kodu Testy serwera Zestaw testów funkcjonalnych dla serwera składa się z: testowanie modelu, testowanie generowanych danych dla raportu oraz testowanie eksportu do pliku XLS. Po zadaniu odpowiedniego adresu URL w przeglądarce internetowej w rezultacie powinien się pojawić dokument XML zawierający odpowiednie dane. Przy testowaniu generowanych danych dla raportu sprawdzono możliwość zwijania oraz rozwijania danych poprzez podanie odpowiedniego adresu URL. Model raportu Celem testu jest sprawdzenie odpowiedzi serwera na żądanie pobrania modelu raportu. Użytkownik wpisuję adres URL: fetchmodel.htm z parametrami: reportid=bazaklientow. Punkty weryfikacyjne: W rezultacie powinien zostać wyświetlony dokument XML postaci opisanej w sekcji 3.6.2. Liczba elementów record jest równa liczbie kolumn raportu plus trzy. Każdy element record zawiera listę elementów podrzędnych reprezentujący parametry kolumny. Element title zawiera nazwę kolumny raportu. Pobieranie danych Test sprawdza pobieranie danych dla raportu oraz możliwość rozwijania danych (operacja drill down). Użytkownik podaje URL = fetchdata z parametrami reportid=bazaklientow, hierarchy=region;zespol, parentpath=null. Punkty weryfikacyjne: System w rezultacie wyświetla dokument XML postaci opisanej w sekcji 3.6.2. Elementy record zawierają dane o regionach. Elementy podrzędne Name zawierają nazwy regionów. Użytkownik wybiera dowolny element path oraz zapamiętuje wartość jego wartość. Następnie podaje w polu adresu przeglądarki URL = fetchdata

ROZDZIAŁ 3. BIBLIOTEKA 48 z parametrami: reportid=bazaklientow, hierarchy=region;zespol, parent- Path=PATH, gdzie PATH to wcześniej zapamiętana wartość. Punkty weryfikacyjne: System wyświetla analogiczny dokument XML jak w punkcie powyżej, ale zamiast regionów zostają zwrócone dane o zespołach. Przykładowy test klienta Test weryfikuje warstwę klienta na podstawie raportu o spotkaniach. 1. Użytkownik ustala hierarchię grupowania rok, miesiąc, region oraz zespół oraz klika w przycisk OK. Punkty weryfikacyjne: System wyświetla widok zawierający listę wierszy z poszczególnymi latami. 2. Użytkownik rozwija wybrany rok. Punkty weryfikacyjne: System wyświetla pod wybranym wierszem listę miesięcy. 3. Użytkownik rozwija wybrany miesiąc. Punkty weryfikacyjne: System wyświetla listę regionów. 4. Użytkownik rozwija region. Punkty weryfikacyjne: System wyświetla pod wybranym wierszem listę zespołów. 5. Użytkownik klika w opcję Ustawienia. Ustala filtr na datę spotkania od 2010-04-01 do 2010-11-30 oraz klika w przycisk OK. Punkty weryfikacyjne: System wyświetla tylko jeden wiersz zawierający rok 2010. 6. Użytkownik rozwija rok 2010. Punkty weryfikacyjne: System wyświetla pod wybranym wierszem listę miesięcy od kwietnia do listopada. 7. Użytkownik rozwija dowolny miesiąc. Punkty weryfikacyjne: System wyświetla listę regionów. 8. Użytkownik rozwija region. Punkty weryfikacyjne: System wyświetla pod wybranym wierszem listę zespołów.

ROZDZIAŁ 3. BIBLIOTEKA 49 9. Użytkownik klika w opcję Ustawienia. Do wcześniej ustalonego filtru użytkownik dodaje dodatkowy warunek: Region starts with R i klika w przycisk OK. Punkty weryfikacyjne: System wyświetla tylko jeden wiersz zawierający rok 2010. 10. Użytkownik rozwija rok 2010. Punkty weryfikacyjne: System wyświetla pod wybranym wierszem listę miesięcy od kwietnia do listopada. 11. Użytkownik rozwija dowolny miesiąc. Punkty weryfikacyjne: System wyświetla listę regionów zaczynającym się od litery R. 12. Użytkownik rozwija region. Punkty weryfikacyjne: System wyświetla pod wybranym wierszem listę zespołów. 3.8 Aplikacja 3.8.1 Możliwości aplikacji Po uruchomieniu aplikacji użytkownik zobaczy okno z ustawieniami raportu. W pierwszej kolejności należy ustalić hierarchię grupowania. Do tego celu wyświetlane są dwie listy, które zawierają wybrane kolumny raportu będące kandydatami grup (3.18). Analityk tworzący raport ma możliwość wybranie podzbioru kolumn, które zostaną wyświetlone w tym widoku. Jest to przydatna opcja, ponieważ niektóre kolumny są nieodpowiednie, aby tworzyć grupę. Przykładowo pola opisowe takie jak opis spotkania, czy komentarz z dużym prawdopodobieństwem są unikatowe. Rysunek 3.19: Ustalenie hierarchii grupowania W kolejnym kroku użytkownik ma możliwość zadania kryterium dla prezentowanych danych. Aplikacja umożliwia skonstruowanie dowolnie złożonego wyrażenia boolowskiego z wykorzystaniem operatorów AND, OR oraz NOT (3.19).

ROZDZIAŁ 3. BIBLIOTEKA 50 Przy ustalaniu warunku użytkownik ma do dyspozycji bogatą listę gotowych pozycji, w skład których wchodzą takie jak: zaczyna się od, kończy się na, zawiera, jest pomiędzy, równa się, jest mniejsze, jest większe czy jest puste. Największe możliwości dotyczą filtrowania po dacie. Użytkownik ma możliwość zadania daty w sposób bezwględny podając konkretną datę lub w sposób względny wobec daty dzisiejszej. Lista możliwych opcji jest pokazana na rysunku 3.20. Można wybrać datę dzisiejszą, kolejny dzień, poprzedni dzień a nawet cofnąć się o zadaną liczbę dni/tygodni/miesięcy wstecz. Rysunek 3.20: Konstrukcja filtru Rysunek 3.21: Filtr dla daty Rysunek 3.21 przedstawia pasek narzędziowy aplikacji. Pierwsza opcja dotyczy wydruku raportu, kolejna opcja otwiera okno z ustawieniami, które zostało omówione powyżej, kolejna opcja umożliwia eksport danych do pliku XLS ostatnia pozycja wyświetla okno pomocy. Rysunek 3.22: Pasek narzędziowy aplikacji Po kliknięciu w jedną z kolumn zostanie wyświetlone menu kontekstowe zawierające opcje dotyczące kolumn 3.22. Z tego poziomu można sortować dane rosnąco lub malejąco, wybrać kolumny, które mają być widoczne w widoku lub dokonać zamrożenia wybranej kolumny. Po wykonaniu tej czynności wybrana

ROZDZIAŁ 3. BIBLIOTEKA 51 kolumna będzie zawsze widoczna na ekranie monitora nawet gdy widok zostanie przewinięty w prawo, w celu zobaczenie kolumn, które się nie mieszczą na pierwszym ekranie. Rysunek 3.23: Menu kontekstowe dla kolumny Rysunek 3.23 przedstawia wyświetlony raport. Użytkownik może w dowolny sposób zwijać czy rozwijać kolejne poziomy drzewa. Po kliknięciu w jedną z kolumn lewym przyciskiem myszy dane zostaną posortowane według niej. Aplikacja umożliwia również zmianę rozmiaru kolumny oraz zamianę kolumn miejscami. 3.8.2 Przykładowe analizy Możliwość dynamicznej zmiany hierarchii grupowania daje olbrzymie możliwości analizowania danych. W zależności od wybranych kolumn raportu użytkownik może uzyskać odpowiedź na zadane pytanie. Na przykładzie raportu spotkania, który omówiono w rozdziale 3.2, zaprezentowano różne możliwości analizowania danych. Wybranie hierarchii grupowania widocznej na rysunku 3.24 daje informację o tym w jakich miesiącach były spotkania z wybranym klientem. Rozwijając wiersz z klientem poniżej zostaną wyświetlone wszystkie lata w jakich odbyły się spotkania z wybraną firmą, każdy rok zawiera pod sobą miesiące spotkań, natomiast pod miesiącem widoczne są wszystkie spotkania z wybranym klientem w tym miesiącu. Po usunięciu z hierarchii kolumn rok oraz miesiąc raport będzie przedstawiać całą historię kontaktów z klientem. Ustalenie hierarchii z rysunku 3.25 pozwala uzyskać informacje o klientach z którymi odbyły się spotkania w

ROZDZIAŁ 3. BIBLIOTEKA 52 Rysunek 3.24: Widok raportu (a) Hierarchia (b) Raport Rysunek 3.25: W jakich miesiącach były spotkania z klientami? wybranych miesiącach. Wykonując prostą operację, która polega na przeniesieniu kolumny klienta powyżej kolumny miesiąca można uzyskać odpowiedź na zupełnie inne pytanie. Ten sam raport może zostać użyty do analizowania aktywności doradców klienta. Hierarchia z rysunku 3.26 pozwala uzyskać odpowiedź na pytanie dotyczące aktywności doradcy w wybranych miesiącach. Dokonując niewielkiej zmiany w hierarchii, która polega na przeniesieniu kolumny doradcy pod kolumną miesiąc można dokonać porównania aktywności doradców w wybranych miesiącach. Dla każdej z wyżej wymienionych analiz można w łatwy sposób zamienić okres

ROZDZIAŁ 3. BIBLIOTEKA 53 (a) Hierarchia (b) Raport Rysunek 3.26: Z jakimi klientami były spotkania w wybranym miesiącu? (a) Hierarchia (b) Raport Rysunek 3.27: Aktywność doradców w podziale na miesiące. (a) Hierarchia (b) Raport Rysunek 3.28: Porównanie aktywności doradców w wybranych okresach.

ROZDZIAŁ 3. BIBLIOTEKA 54 z miesiąca na kwartał lub rok czy pogrupować prezentowane dane według hierarchii organizacyjnej na przykład tak, aby doradcy byli widoczni pod zespołami sprzedażowymi. Narzędzie umożliwia również dokonanie podanych analiz w rozbiciu na segmenty klientów. Wystarczy w tym celu dodać kolumnę z segmentem klienta do hierarchii grupowania. Klientów można pogrupować na różne sposoby przykładowo: klienci potencjalni, klienci nowi, klienci aktywowani lub w zależności od wielkości klienta: małe firmy, średnie firmy, duże firmy. Umieszczając segment klienta poniżej miesiąca można uzyskać odpowiedź na pytanie z jakimi grupami klientów umawiane są spotkania. Natomiast, gdy segment klienta zostanie umieszczony nad kolumną miesiąca to pozwoli na dokonywanie wyżej wymienionych analiz dla poszczególnych grup klientów. W tej sekcji opisano przykładowe analizy dla prostego raportu, który składa się tylko z kilku kolumn. Na tak prostym przykładzie przedstawiono szereg konfiguracji, które pozwalają uzyskać odpowiedź na różnego rodzaju pytania. Każda konfiguracja wymaga bardzo małego wysiłku ze strony użytkownika, wystarczy ustalić odpowiednią kolejność kolumn. Dokonując niewielkiej zmiany, która polega na zamianie kolumn miejscami można uzyskać odpowiedź na zupełnie inne pytanie. Potencjalne możliwości manipulowania hierarchią grupowania są ogromne. Użytkownik raportu może w dowolny sposób ustalić kolejność kolumn co pozwala na prezentację tych samych danych z wielu perspektyw. 3.8.3 Serwer raportów Sekcja ta zawiera omówienie aplikacji, której celem jest udostępnianie raportów utworzonych za pomocą zrealizowanej biblioteki. Na wstępie przedstawiono wymagania funkcjonalne, następnie opisano projekt oraz implementację. Na samym końcu zaprezentowano działającą aplikację. System powinien wyświetlać listę raportów, które znajdują się w repozytorium na serwerze. System powinien umożliwiać wybranie raportu oraz jego wyświetlenie. Administrator tego systemu umieszcza repozytorium plików XML w odpowiedniej lokalizacji oraz dokonuje konfiguracji połączenia z bazą danych. Te dwie czynności są wystarczające do tego, aby serwer mógł udostępniać raporty użytkownikom. Po dokonaniu zmiany w dowolnym z plików, podmianie, dodaniu lub usunięciu pliku czy modyfikacji połączenia z bazą danych zmiany te zostaną automatycznie uwzględnione po ponownym uruchomieniu aplikacji. Jest to duża zaleta zrealizowanej aplikacji, w której wszystkie dane o modelu biznesowym oraz raportach zawarte są w plikach XML i na podstawie ich zawartości serwer może prezentować raporty użytkownikom. Przy dokonywaniu jakichkolwiek zmian nie wymagana jest ingerencja programisty, natomiast wszystkie zmiany nanoszone są w plikach XML. Zastosowany model deklaratywny jest narażony na mniejsze ryzyko popełnienia błędów niż tradycyjne podejście wymagające prac programi-

ROZDZIAŁ 3. BIBLIOTEKA 55 stycznych. Repozytorium składa się z plików XML, które zawierają model biznesowy zawarty w pliku classes.xml oraz listy plików w folderze reports, w którym znajdują się pliki zawierające opis raportów. Wszystkie pliki XML mogą zostać utworzone w sposób ręczny lub za pomocą dedykowanego narzędzia z graficznym interfejsem użytkownika, które opisano w rozdziale 4. Plik jdbc.properties zawiera parametry połączenia z bazą danych: login, hasło użytkownika oraz adres URL.

Rozdział 4 Designer 4.1 Wymagania 4.1.1 Wymagania funkcjonalne Założenie nowego projektu. Skonfigurowanie połączenia z bazą danych. Dodawanie klas. Dodawanie atrybutów klas. Podgląd tabel z bazy danych. Tworzenie raportów. Dodawanie raportów. Dodawanie kolumn do raportów. Wyświetlenie klas i ich atrybutów. Wyświetlenie klas w postaci drzewa. Wyświetlenie klas w postaci graficznej. Wyświetlenie raportów i ich kolumn. 4.1.2 Przypadki użycia Aktorzy Twórca modelu biznesowego ich atrybuty. to rola, która tworzy model biznesowy: klasy oraz 56

ROZDZIAŁ 4. DESIGNER 57 Projektant raportów to rola odpowiedzialna za tworzenie nowych raportów na podstawie modelu biznesowego. Diagram przypadków użycia Rysunek 4.1 przedstawia przypadki użycia dostępne dla twórcy modelu biznesowego, natomiast na rysunku 4.2 widoczne są przypadki użycia dla projektanta raportów. Rysunek 4.1: Przypadki użycia dla twórcy modelu biznesowego

ROZDZIAŁ 4. DESIGNER 58 Rysunek 4.2: Przypadki użycia dla projektanta raportów UC.AC Dodanie klasy Cel Dodanie nowej klasy. Aktor główny Twórca modelu biznesowego Przebieg zdarzeń Nr System Użytkownik 1. Wybiera opcje dodaj klasę 2. Wybiera tabelę 3. Podaje nazwę klasy 4. Zatwierdza 5. Wyświetla komunikat o sukcesie

ROZDZIAŁ 4. DESIGNER 59 Rysunek 4.3: Dodanie klasy - prototyp Prototyp interfejsu użytkownika UC.ASA Dodanie atrybutu SimpleAttribute Cel Dodanie atrybutu typu SimpleAttribute. Aktor główny Twórca modelu biznesowego Przebieg zdarzeń Nr System Użytkownik 1. Wybiera klasę 2. Wybiera opcje dodaj atrybut SimpleAttribute 3. Podaje wyrażenie 4. Podaje nazwę atrybutu 5. Zatwierdza 6. Wyświetla komunikat o sukcesie Prototyp interfejsu użytkownika UC.ARA Dodanie atrybutu ReferenceAttribute Cel Dodanie atrybutu typu ReferenceAttribute. Aktor główny Twórca modelu biznesowego

ROZDZIAŁ 4. DESIGNER 60 Rysunek 4.4: Dodanie atrybutu SimpleAttribute - prototyp Przebieg zdarzeń Nr System Użytkownik 1. Wybiera klasę źródłową 2. Wybiera opcje dodaj atrybut ReferenceAttribute 3. Podaje nazwę atrybutu 4. Wybiera klasę docelową 5. Wybiera kolumnę klucza obcego 6. Zatwierdza 7. Wyświetla komunikat o sukcesie Prototyp interfejsu użytkownika Rysunek 4.5: Dodanie atrybutu ReferenceAttribute - prototyp UC.NEW.PROJECT Założenie projektu Cel Aktor główny Twórca modelu biznesowego

ROZDZIAŁ 4. DESIGNER 61 Przebieg zdarzeń Nr System Użytkownik 1. Wybiera opcje nowy projekt 2. Podaje nazwę projektu 3. Zatwierdza UC.DB.CONN Skonfigurowanie połączenia z bazą danych Aktor główny Twórca modelu biznesowego Przebieg zdarzeń Nr System Użytkownik 1. Wybiera opcje konfiguracja połączenia z bazą danych 2. Wybiera typ bazy danych 3. Podaje ścieżkę z biblioteką JDBC 4. Podaje nazwę i hasło użytkownika adres serwera i port nasłuchujący Prototyp interfejsu użytkownika Rysunek 4.6: Skonfigurowanie połączenia z bazą danych - prototyp

ROZDZIAŁ 4. DESIGNER 62 UC.A.REPORT Dodanie raportu Cel Aktor główny Projektant raportów Przebieg zdarzeń Nr System Użytkownik 1. Wybiera opcje dodaj raport 2. Podaje nazwę raportu 3. Wybiera główną klasę 4. Zatwierdza 5. Wyświetla komunikat o sukcesie Prototyp interfejsu użytkownika Rysunek 4.7: Dodanie raportu - prototyp UC.A.RCOLUMN Dodanie kolumny raportu Cel Aktor główny Projektant raportów

ROZDZIAŁ 4. DESIGNER 63 Przebieg zdarzeń Nr System Użytkownik 1. Wybiera raport 2. Wybiera opcje dodaj kolumnę 3. Wybiera atrybut 4. Wybiera jedną z ścieżek 5. Zatwierdza 6. Wyświetla komunikat o sukcesie Prototyp interfejsu użytkownika Rysunek 4.8: Dodanie kolumny raportu krok 1 - prototyp Rysunek 4.9: Dodanie kolumny raportu krok 2 - prototyp