Praca dyplomowa magisterska

Transkrypt

1 Politechnika Warszawska Rok akademicki 2010/2011 Wydział Elektroniki i Technik Informacyjnych Instytut Informatyki Praca dyplomowa magisterska inż. Piotr Kalański Technologia do tworzenia hierarchicznych raportów w aplikacjach WWW Ocena: Opiekun pracy: dr inż. Michał Rudowski Podpis Przewodniczącego Komisji Egzaminu Dyplomowego

2 Kierunek: Informatyka Specjalność: Inżynieria Systemów Informatycznych Data urodzenia: 18 kwietnia 1986 r. Data rozpoczęcia studiów: październik 2010 r. Życiorys Nazywam się Piotr Kalański. Urodziłem się 18 kwietnia 1986 r. w Warszawie. W mieście rodzinnym ukończyłem szkołę podstawową nr 2 im. Janusza Korczaka oraz gimnazjum nr 1 im. Hugona Kołłątaja. W 2002 roku rozpocząłem naukę w XL LO im. Stefana Żeromskiego w Warszawie w klasie o profilu matematyczno-informatycznym. W 2005 roku rozpocząłem studia w Szkole Głównej Gospodarstwa Wiejskiego w Warszawie na Wydziale Zastosowań Matematyki i Informatyki, kierunek Informatyka i Ekonometria. W tym okresie informatyka stała się kluczowym obszarem moich zainteresowań. W 2006 roku rozpocząłem studia na Politechnice Warszawskiej na Wydziale Elektroniki i Technik Informacyjnych, kierunek Informatyka. Od lipca 2008 roku do października 2008 roku uczestniczyłem w Programie Praktyk Letnich w Banku Handlowym S.A. Zadaniem wykonywanym w czasie odbywania praktyk było rozwijanie Portalu Operacji Kredytowych i Leasingowych. Od lutego 2009 roku jestem pracownikiem Kredyt Banku S.A. W organizacji tej pracowałem na następujących stanowiskach: Analityk MIS, Menedżer Aplikacji. Jestem odpowiedzialny za System Wsparcia Sprzedaży. Moje obszary zainteresowań to inżynieria oprogramowania, bazy danych, CRM, Business Intelligence. Podpis studenta Egzamin dyplomowy Złożył egzamin dyplomowy w dn r. z wynikiem Ogólny wynik studiów Dodatkowe wnioski i uwagi Komisji

3 Streszczenie Słowa kluczowe: Raportowanie, Business Intelligence, GWT Abstract Title of paper: Keywords:

4 Spis treści Spis treści i 1 Wstęp Cel pracy Zakres pracy Raportowanie Business Intelligence Definicja [33] Historia powstania Business Intelligence [33] Piramida Business Intelligence [18] Hurtownia danych [35] OLAP [33] Data mining [15] Wybrane rozwiązania Business Intelligence funkcjonujące na rynku Jaspersoft IBM Cognos [4] Podsumowanie Biblioteka Wymagania Wymagania funkcjonalne Wymagania niefunkcjonalne Przypadki użycia Przykładowe bazy danych CRM Service Desk Przykładowe raporty Service Desk CRM i

5 SPIS TREŚCI ii 3.4 Meta-Model Meta-model biznesowy Przykładowy model biznesowy Meta-model raportu Przykładowy raport Projekt Model Web Diagramy sekwencji Implementacja Generowanie zapytania Komunikacja klient - serwer Serializacja do formatu XML Technologia Narzędzia Testy i ocena Środowiska testowe Generacja danych Testy jednostkowe Testy funkcjonalne Aplikacja Możliwości aplikacji Przykładowe analizy Serwer raportów Podsumowanie Designer Wymagania Wymagania funkcjonalne Przypadki użycia Projekt Pakiety Implementacja Technologia Narzędzia Aplikacja Podsumowanie Rozszerzenia Aplikacja mobilna Technologia Narzędzia

6 SPIS TREŚCI iii Aplikacja Wykresy Technologia Aplikacja Podsumowanie Podsumowanie 83 Bibliografia 84 Spis symboli i skrótów 87 Spis rysunków 88 Spis tabel 90

7 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

8 ROZDZIAŁ 1. WSTĘP 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

9 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 Definicja [33] 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 Historia powstania Business Intelligence [33] 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

10 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 Piramida Business Intelligence [18] 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 Hurtownia danych [35] 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

11 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 OLAP [33] 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. Określenie zakresu analizy raportowane. to ustalenie jakie fakty oraz w jakich wymiarach będą

12 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 Wycinanie (ang. drill up) to operacja odwrotna do rozwijania danych. (ang. slice) to filtrowanie danych. Obracanie (ang. pivot) jest to operacja związana z prezentacją danych. Polega ona na zamianie kolumn z wierszami Data mining [15] 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 Wybrane rozwiązania Business Intelligence funkcjonujące na rynku 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 [21] 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

13 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 [19] jest to narzędzie z graficznym interfejsem użytkownika służące do tworzenia raportów. JasperServer [22] 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 [20] 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 [16] 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ę

14 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" " <jasperreport name="name_of_the_report"... >... </jasperreport> Parametry to dane, które nie mogą być wydobyte ze źródła danych. Częstym zastosowaniem parametrów jest określenie warunków zapytania. W przypadku szczególnym parametrem może być samo zapytanie. Przykładowe parametry: Dynamiczny tytuł raportu. Wartości dla 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 }

15 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ą silną stroną 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 obliczenia sumy:

16 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 [17] 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 według analityków Gartnera, jest to opcja warta do rozważenia. Mocne strony Jaspersoft

17 ROZDZIAŁ 2. RAPORTOWANIE 11 Rysunek 2.3: Magic Quadrant Gartnera dla Platform Business Intelligence na 2011 rok. Jaspersoft oferuje platformę Business Intelligence typu 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. Największą zaletą Jaspersoft 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 oraz wersja komercyjna 2 TCO Total Cost of Ownership. Całkowity koszt pozyskania, instalowania, użytkowania oraz utrzymania

18 ROZDZIAŁ 2. RAPORTOWANIE 12 posiada niski koszt 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żliwia testowanie rozwiązań BI dostępnych w chmurze. Duża liczba 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ń typu Open Source. Dane organizacji mówią o komercyjnych klientach co potwierdzają również dane dotyczące obrotów firmy. Jednakże tylko 20 klientów wypełniło ankietę, w której Jaspersoft został określony jako platformy Business Intelligence użytkowana w ramach przedsiębiorstwa. 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 Jaspersoft. Jaspersoft został nisko oceniony w zakresie prostoty kompenentów oraz prostoty integracji elementów platformy IBM Cognos [4] 2.3 Podsumowanie Dostępne na rynku narzędzia zawierają wiele interesujących i przydatnych funkcji. Wspierają one 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ą 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.

19 ROZDZIAŁ 2. RAPORTOWANIE 13 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. Dynamiczna hierarchia grupowania danych Na wstępie dokonano przegląd metod prezentacji danych w postaci tabelarycznej. Tabelka Najprostsza 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 Plus, 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. Ponieważ liczba możliwych hierarchii grupowania jest olbrzymia 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 on możliwość zmiany hierarchii grupowania w dowolny sposób.

20 ROZDZIAŁ 2. RAPORTOWANIE 14 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ć w takim przypadku 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, 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, 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 programista musi samemu utworzyć formularz i przekazać wartości parametrów. Sortowanie danych Jest to funkcja, która bardzo często występuje. Jednak, 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.

21 ROZDZIAŁ 2. RAPORTOWANIE 15 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 sortowaniu 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 ukrycia niepotrzebnych danych. 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 istotnej dla użytkownika 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 formatów wynikowych w tym XLS. Drukowanie raportu Raport powinien zawierać możliwość wydrukowania.

22 ROZDZIAŁ 2. RAPORTOWANIE 16 W przypadku JasperReports istnieje możliwość wyeksportowania raportu do pliku w formacie PDF. Deklaratywny sposób tworzenia raportów Utworzenie raportu nie powinno 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. Wymaga to 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 tych danych generowany jest plik wynikowy. Wnioski Zatem wszystkie omawiane platformy: JasperSoft oraz IBM Cognos posiadają pewne braki, dlatego też istnieje potrzeba zaproponowania nowego narzędzia, które umożliwi prezentowanie raportów w sposób nowatorski. W kolejnym rozdziale omówiono bibliotekę do tworzenia raportów spełniającą wyżej wymienione cechy.

23 Rozdział 3 Biblioteka W tym rozdziale zaprezentowano bibliotekę dla hierarchicznych raportów. Na wstępie przedstawiono wymagania stawiane 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 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; 17

24 ROZDZIAŁ 3. BIBLIOTEKA 18 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 Wymagania niefunkcjonalne Zamrożenie pierwszych kolumn oraz nagłówka; Prezentacja tylko dostępnych danych - uprawnienia; Widok powinien pobierać tylko potrzebne dane: zmniejsza to obciążenie bazy danych oraz umożliwia 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 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.

25 ROZDZIAŁ 3. BIBLIOTEKA 19 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,

26 ROZDZIAŁ 3. BIBLIOTEKA 20 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 zamierza zejść w dół, aby obejrzeć bardziej szczegółowe dane. 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 pokazuje szczegółowe dane 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.

27 ROZDZIAŁ 3. BIBLIOTEKA 21 UC.HIDE.CHILDS Ukrywanie danych Cel Użytkownik zamierza schować dane, aby nie zakłócać 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 zamierza 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 zamierza posortować widok według jednej z kolumn.

28 ROZDZIAŁ 3. BIBLIOTEKA 22 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 zamierza zapisać do pliku dane zawarte w raporcie. Przebieg zdarzeń Nr System Użytkownik 1. Wybiera opcję eksportu danych do pliku 2. System wyświetla okienko z opcją pobrania pliku 3. Wybiera opcję zapisania pliku UC.HIERARCHY Zmiana hierarchii grupowania Cel Użytkownik zamierza zmienić hierarchię, według której grupowane są dane.

29 ROZDZIAŁ 3. BIBLIOTEKA 23 Przebieg zdarzeń Nr System Użytkownik 1. Wybiera opcję zmiany 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 CRM Rysunek 3.5 przedstawia diagram tabel dla fragmentu bazy danych systemu typu CRM 1. 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. 1 CRM Customer Relationship Management

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

31 ROZDZIAŁ 3. BIBLIOTEKA 25 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 czy liczba zatrudnionych.

32 ROZDZIAŁ 3. BIBLIOTEKA 26 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 Service Desk Rysunek 3.6 przedstawia fragment bazy danych dla systemu Service Desk. Fragment ten dotyczy procesu zarządzania incydentami. System umożliwia klientom usługi zgłaszanie nowych incydentów. Pracownik pierwszej linii ma możliwość

33 ROZDZIAŁ 3. BIBLIOTEKA 27 przypisania się do incydentu. System umożliwia wyszukiwanie incydentów oraz dodawanie komentarzy dla incydentów. Baza danych została zaczerpnięta z pracy dyplomowej inżynierskiej Piotra Kalańskiego [23]. 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.

34 ROZDZIAŁ 3. BIBLIOTEKA 28 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 w danej chwili. 3.3 Przykładowe raporty 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 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ż przeanalizowanie zawartego w nich ogromu informacji wymaga wiele czasu. Incydenty Tabela 3.1 przedstawia kolumny raportu dotyczącego incydentów. Zrealizowana biblioteka umożliwia jednokrotne utworzenie raportu, który daje możliwość 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 CRM Spotkania Tabela 3.2 przedstawia kolumny raportu dotyczącego spotkań. Przykładowe analizy, które umożliwia ten raport:

35 ROZDZIAŁ 3. BIBLIOTEKA 29 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ść wyświetlenia wszystkich klientów bezpośrednio pod swoją jednostką 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żytkownik mniej jest zainteresowany informacją z jakimi klientami były spotkania, ale ważne jest dla niego kto na tych spotkaniach był. Menedżer ma możliwość obejrzenia aktywności swoich doradców na wiele sposobów. Przykładowo, może zdecydować się na dodatkowe pogrupowanie spotkań według 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, według 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

36 ROZDZIAŁ 3. BIBLIOTEKA 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 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 klasa, która mapowana jest na tabele w relacyjnej bazie danych, natomiast jej

37 ROZDZIAŁ 3. BIBLIOTEKA 31 atrybuty na wyrażenia oparte na kolumnach tych tabel. DomainClass jest elementem meta-modelu reprezentującym klasę. Jeden z atrybutów tablename wskazuje na tabelę lub perspektywę. Każdy obiekt DomainClass zawiera listę atrybutów typu dziedziczącego z DomainAttribute. DomainAttribute jest klasą bazową dla poszczególnych typów atrybutów. Każdy z tych atrybutów zawiera nazwę oraz identyfikator. SimpleAttribute jest to najprostszy typ atrybutu. Najczęściej jest to mapowanie na jedną z kolumn, ale może to być również wyrażenie SQL wyliczone na podstawie grup kolumn. Przykładem wyrażenia jest złączenie kolumn imię oraz nazwisko. Atrybuty tego typu mogą być miernikami, co oznacza, że będą agregowane na wyższych poziomach hierarchii grupowania. 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 doradcą. DictionaryAttribute jest to specjalny rodzaj ReferenceAttribute, który wskazuje 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, ponieważ redukuje liczbę czynności wykonywanych podczas tworzenia 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, zatem twórca raportu oszczędza czas potrzebny na jej wybranie. Kolejnym powodem istnienie tego typu atrybutów jest fakt występowania cykli w modelu biznesowych, czyli pomiędzy dwoma klasami może istnieć więcej jak jedna ścieżka. W takim przypadku projektant raportu zawsze musi wybrać właściwą ścieżkę poświęcając na to więcej czasu. Natomiast gdy w klasie istnieją atrybuty typu DictionaryAttribute nie ma potrzeby wskazywania dokładnej ścieżki do docelowego atrybutu, ponieważ została ona określona w momencie tworzenia modelu biznesowego Przykładowy model biznesowy Na podstawie bazy danych opisanej w sekcji 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.

38 ROZDZIAŁ 3. BIBLIOTEKA 32 Rysunek 3.8: Przykładowy model biznesowy Podstawową klasą modelu jest Klient, która odpowiada tabeli KLIENCI. Kluczem głównym klasy jest klient id. Atrybuty (typu SimpleAttribute): nazwa, NIP, telefon oraz data podp umowy, 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ł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. W tym przypadku mogą pojawić się wątpliwości związane z istnieniem redundancji aż trzech połączeń między klasami. Po pierwsze wydaje 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

39 ROZDZIAŁ 3. BIBLIOTEKA 33 Rysunek 3.9: Diagram obiektów dla przykładowego modelu biznesowego 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: bezpośrednia oraz przez klasę Klient. Gdyby w klasie Klient 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 wygeneruje 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 Meta-model raportu Na rysunku 3.10 został przedstawiony meta-model raportów. Raport składa się z wielu kolumn 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.

40 ROZDZIAŁ 3. BIBLIOTEKA 34 Rysunek 3.10: Meta-model raportu SimpleReportColumn jest to prosta kolumna powiązana z atrybutem typu SimpleAttribute. ReferenceReportColumn Obiekty tego typu tworzą ścieżkę, która wskazuje 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: ReferenceAttribute. Wyjątek stanowi ostatni element, który jest typu

41 ROZDZIAŁ 3. BIBLIOTEKA 35 SimpleReportColumn, czyli wskazuje na obiekt typu SimpleAttribute. Taki rodzaj kolumny jest wskazany, ponieważ w modelu biznesowym mogą występować cykle, a tym samym istnieje wiele ścieżek pomiędzy dwiema klasami. W takim przypadku projektant raportu zostanie poproszony o wybranie jednej ze wspomnianych ścieżek. Przykładowy model biznesowy opisany w sekcji zawiera cykl pomiędzy klasami: Spotkanie, Doradca oraz Klient Przykładowy raport Na podstawie modelu biznesowego omówionego w sekcji 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 reprezentuje model. Powiązany jest on z klasą Spotkanie. Na rysunku widoczne są dwie kolumny raportu: temat oraz klient. Pierwsza jest typu ReportSimpleColumn i wskazuje 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 posiada budowę modułową, została podzielona na pod projekty. 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 również za komunikację warstwy klienta z warstwą serwera, która korzysta z usług klas dostarczonych w modelu.

42 ROZDZIAŁ 3. BIBLIOTEKA 36 Rysunek 3.11: Diagram obiektów dla raportu Spotkania Model Na rysunku 3.12 przedstawiono diagram pakietów dla modułu związanego z modelem. edu.pw.treegrid.server.classmodel Zawiera klasy reprezentujące model biznesowy. Jest to klasa biznesowa zawierająca 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.

43 ROZDZIAŁ 3. BIBLIOTEKA 37 Rysunek 3.12: Model - diagram pakietów 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 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 Ten pakiet zawiera klasy odpowiedzialne za formatowanie danych: format liczbowy oraz format daty. edu.pw.treegrid.client.report.model Pakiet zawierający źródła danych komunikujące się z serwerem. Klasy te są typu DataSource. edu.pw.treegrid.client.report.events Zdarzenia zachodzące w aplikacji.

44 ROZDZIAŁ 3. BIBLIOTEKA 38 Rysunek 3.13: Klient - diagram pakietów Rysunek 3.14: Serwer - diagram pakietów edu.pw.treegrid.server.web Główną klasą pakietu jest ReportServlet, która odpowiada za obsłużenie zadań klienta. Komunikację klienta z serwerem opisano w sekcji 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

45 ROZDZIAŁ 3. BIBLIOTEKA 39 formatu XML przesyłanego w odpowiedzi na żądania klienta Diagramy sekwencji W sekcji tej opisano przykładowe diagramy sekwencji związane z rozwijaniem danych opisanym w przypadku użycia UC.SHOW.CHILDS Przedstawiono zarówno warstwę klienta jak i 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 klienta w wyniku akcji użytkownika rozwinięcia danych szczegółowych. Na tym diagramie znajdują się następujące klasy: OpenerCell, TreeGridController, TreeGridModel, TreeGridView oraz TreeGridService. OpenerCell to klasa będąca guzikiem, w który należy kliknąć, aby rozwinąć dane. Klasy TreeGridController, TreeGridModel oraz TreeGridView tworzą wzorzec projektowy MVC. Natomiast klasa TreeGrid- Service jest odpowiedzialna za komunikację z serwerem. 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 przekazuje żądanie do modelu TreeGridModel wywołując metodę togglechilds(), która 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 konieczna jest komunikacja z warstwą serwera model dokonuje utworzenia obiektu żądania Request. W pierwszym kroku należy ustalić identyfikator wiersza wykorzystując metodę getpath(). W kolejnym kroku zostaje wywołana metoda fetchchilds() klasy TreeGridService. Po otrzymaniu odpowiedzi od serwera metoda notifystatechanged() informuje o zmianie stanu klienta. Metoda ta dokonuje powiadomienia klasę widoku TreeGridView o zmianie stanu modelu poprzez metodę onmodelstatechanged(). Metoda on- ModelStateChanged() 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 3.16 przedstawia stronę serwera tej samej operacji opisanej powyżej. W wyniku żądania klienta zostaje wywołana metoda fetchchilds() klasy TreeGridService. W pierwszym kroku następuje odczytanie modelu z plików XML za pomocą metody unmarshall() klasy XMLMarshaller. Następnie zostaje wygenerowane zapytanie SQL 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.

46 ROZDZIAŁ 3. BIBLIOTEKA 40 Rysunek 3.15: Diagram sekwencji - rozwijanie danych - klient

47 ROZDZIAŁ 3. BIBLIOTEKA 41 Rysunek 3.16: Diagram sekwencji - rozwijanie danych - serwer

48 ROZDZIAŁ 3. BIBLIOTEKA Implementacja Sekcja ta zawiera opis wybranych problemów implementacyjnych: generowanie zapytania SQL, komunikacji klienta z serwerem oraz serializacji do formatu XML. Następnie opisano wykorzystywane technologie oraz użyte narzędzia 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 związana bezpośrednio 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 to najkrótsza ścieżka, którą można znaleźć przy pomocy algorytmu DFS 2. Po utworzeniu wszystkich ścieżek dla każdej kolumny w raporcie należy je ze sobą połączyć w jedno drzewo, przykładowo postać widoczną na rysunku 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 zachodzi taka sytuacja należy podzielić ścieżkę na dwie części i koniec ścieżki wstawić do odpowiedniego węzła drzewa. Pozwala to uniknąć powstawania duplikatów w drzewie i dopuszczenia do wielokrotnych złączeń pomiędzy tymi samymi 2 DFS Depth First Search

49 ROZDZIAŁ 3. BIBLIOTEKA 43 tabelami, co w rezultacie wpływa pozytywnie na wydajność. W ostatnim kroku algorytmu wystarczy z postaci drzewiastej wygenerować odpowiednie zapytanie SQL. 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 SE- LECT 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ą 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 WWW [32] 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.

50 ROZDZIAŁ 3. BIBLIOTEKA 44 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 Technologia GWT [6] 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 [31] 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 umożliwiający 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 raportu niezbędne do ustalenia hierarchii grupowania. JavaServlets [3] Przy realizacji warstwy serwera wykorzystano standardowe serwlety technologii Java.

51 ROZDZIAŁ 3. BIBLIOTEKA 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 sposobem wykorzystania narzędzia jest tworzenie aplikacji w technologii Java EE. Autor najczęściej korzystał z następujących wtyczek: Subclipse, Mylyn, Web Tools Platform, GWT Plugin oraz Cobertura. Subclipse [34] jest to wtyczka umożliwiająca wykonywanie poleceń SVN z poziomu platformy Eclipse. Mylyn [10] 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 koncentrować się na tym co jest istotne przy realizacji wybranego zadania. Web Tools Platform [7] języku Java. jest platformą do tworzenia aplikacji WWW w Cobertura [5] to wtyczka umożliwiająca obliczenie pokrycia kodu w testach jednostkowych oraz funkcjonalnych. Google Plugin for Eclipse [28] dodaje do platformy Eclipse funkcjonalności ułatwiające tworzenie aplikacji opartych o GWT oraz Google AppEngine. GWT Designer [9] to wtyczka do tworzenia aplikacji z graficznym użytkownika opartych o technologię GWT. Narzędzie umożliwia generowanie kodu źródłowego na podstawie zrealizowanego w sposób graficzny metodą WYSIWYG interfejsu użytkownika, co więcej istnieje możliwość generacji w drugą stronę czyli od kodu źródłowego do interfejsu użytkownika. Apache Maven [2], [30] to narzędzie kompilacji Javy zaprojektowane z myślą o automatyzacji najtrudniejszych zadań związanych z procesem kompilacji. W przeciwieństwie do używanego modelu zadaniowego w Ant zastosowano model

52 ROZDZIAŁ 3. BIBLIOTEKA 46 deklaratywny, w którym struktura i zawartość projektu są opisywane. 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 uwzględniają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 wygenerowaną stronę projektu oraz wszystkie 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 [24] 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 [5] poprzez testy jednostkowe. generuje raport zawierający pokrycie kodu CPD Report [25] to narzędzie wykrywa powtarzające się fragmenty kodu, które łamią zasadę DRY (Dont Repeat Yourself). FindBugs Report [11] 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 [36], które dla każdej klasy generuje diagram kontekstowy zawierający wszystkie powiązane klasy. Po kliknięciu w klasę na tym diagramie użytkownik zostanie automatycznie przeniesiony do jej dokumentacji. JDepend [26] jest narzędziem, które generuje raport dotyczący zbioru metryk na temat kodu źródłowego. Umożliwia to automatyczne 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 czy współczynnik klas abstrakcyjnych do klas konkretnych. Maven Surefire Report jednostkowych. tworzy raport o szczegółowych rezultatach testów generuje kolejny raport badający defekty w kodzie źródło- PMD Report wym.

53 ROZDZIAŁ 3. BIBLIOTEKA 47 Tag List [27] to raport zawierający informacje o znacznikach użytkownika w kodzie źródłowym. Przykładowo o znacznikach typu TODO. 3.7 Testy i ocena Środowiska testowe System był testowany w 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: jdk (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 Baza danych: Oracle 10g Express Edition Kontener serwletów: Apache Tomcat JDK: jdk (64 bitowa) Generacja danych Do generacji danych testowych wykorzystano narzędzie databene benerator [8]. 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

54 ROZDZIAŁ 3. BIBLIOTEKA 48 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 Testy jednostkowe Dla zrealizowanej aplikacji został przygotowany zestaw testów jednostkowych. Rysunek 3.18 pokazuje ich pokrycie. Autor w początkowym etapie rozwoju aplikacji tworzył ją zgodnie z techniką TDD 3. 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. Rysunek 3.18: Pokrycie kodu dla modułu model 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 opisanej w sekcji Testy serwera Zestaw testów funkcjonalnych dla serwera składa się z: testowania modelu, testowania generowanych danych dla raportu oraz testowania eksportu do pliku XLS. Po zadaniu odpowiedniego adresu URL w przeglądarce internetowej w rezultacie 3 TDD Test-driven development

55 ROZDZIAŁ 3. BIBLIOTEKA 49 powinien pojawić się 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 w postaci opisanej w sekcji Liczba elementów record jest równa liczbie kolumn raportu plus trzy. Każdy element record zawiera listę elementów podrzędnych reprezentujących 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 w postaci opisanej w sekcji Elementy record zawierają dane o regionach. Elementy podrzędne Name zawierają nazwy regionów. Użytkownik wybiera dowolny element path oraz zapamiętuje jego wartość. Następnie podaje w polu adresu przeglądarki URL = fetchdata z parametrami: reportid=bazaklientow, hierarchy=region;zespol, parentpath=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.

56 ROZDZIAŁ 3. BIBLIOTEKA 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 do oraz klika w przycisk OK. Punkty weryfikacyjne: System wyświetla tylko jeden wiersz zawierający rok Użytkownik rozwija rok 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. 9. Użytkownik klika w opcję Ustawienia. Do wcześniej ustalonego filtru dodaje dodatkowy warunek: Region starts with R i klika w przycisk OK. Punkty weryfikacyjne: System wyświetla tylko jeden wiersz zawierający rok Użytkownik rozwija rok 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ących się od litery R. 12. Użytkownik rozwija region. Punkty weryfikacyjne: System wyświetla pod wybranym wierszem listę zespołów.

57 ROZDZIAŁ 3. BIBLIOTEKA Aplikacja 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.19). Analityk tworzący raport ma możliwość wybrania 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 może zadać kryterium dla prezentowanych danych. Aplikacja umożliwia skonstruowanie dowolnie złożonego wyrażenia boolowskiego z wykorzystaniem operatorów AND, OR oraz NOT (3.20). 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 aktualnej. Lista możliwych opcji jest pokazana na rysunku Istnieje możliwość wybrania daty aktualnej, kolejnego dnia, poprzedniego dnia a nawet cofnięcia się o zadaną liczbę dni/tygodni/miesięcy. Rysunek 3.20: Konstrukcja filtru

58 ROZDZIAŁ 3. BIBLIOTEKA 52 Rysunek 3.21: Filtr dla daty Rysunek 3.22 przedstawia pasek narzędziowy aplikacji. Pierwsza opcja dotyczy wydruku raportu. Kolejna otwiera okno z ustawieniami, które zostało omówione powyżej. Następna 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 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 kolumna będzie zawsze widoczna na ekranie monitora, nawet gdy widok zostanie przewinięty w prawo, w celu zobaczenia kolumn, które się nie mieszczą na pierwszym ekranie. Rysunek 3.24 przedstawia wyświetlony raport. Użytkownik może w dowolny sposób zwijać lub 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 Przykładowe analizy Dynamiczna zmiana 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.25 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ń pod każdym

59 ROZDZIAŁ 3. BIBLIOTEKA 53 Rysunek 3.23: Menu kontekstowe dla kolumny z nich widoczne są wszystkie spotkania z wybranym klientem w danym 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.26 pozwala uzyskać informacje o klientach, z którymi odbyły się spotkania w wybranych miesiącach. Wykonując prostą operację polegającą 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.27 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 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. W tym celu wystarczy 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 w przypadku, gdy segment klienta zostanie umieszczony nad kolumną miesiąca, to pozwoli na dokonywanie

60 ROZDZIAŁ 3. BIBLIOTEKA 54 Rysunek 3.24: Widok raportu (a) Hierarchia (b) Raport Rysunek 3.25: W jakich miesiącach były spotkania z klientami? 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 polegającej 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

61 ROZDZIAŁ 3. BIBLIOTEKA 55 (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.

62 ROZDZIAŁ 3. BIBLIOTEKA 56 na prezentację tych samych danych z wielu perspektyw Serwer raportów Sekcja ta zawiera omówienie aplikacji udostępniającej raporty utworzone za pomocą zrealizowanej biblioteki. Na wstępie przedstawiono wymagania funkcjonalne, następnie opisano projekt oraz implementację. Na samym końcu zaprezentowano gotową aplikację. System powinien wyświetlać listę raportów, które znajdują się w repozytorium na serwerze. Powinien również 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żą zaletą, ponieważ 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 programistycznych. 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 opisanego w rozdziale 4. Plik jdbc.properties zawiera parametry połączenia z bazą danych: login, hasło użytkownika oraz adres URL. 3.9 Podsumowanie W tym rozdziale została opisana biblioteka do tworzenia hierarchicznych raportów w sposób deklaratywny. Biblioteka spełnia wszystkie cechy wymienione w sekcji 2.3. Ogromną zaletą opisanego narzędzia jest możliwość dynamicznej zmiany hierarchii grupowania co pozwala na przeprowadzanie szeregu analiz na tym samym zbiorze danych. Wykonując prostą czynność zmiany hierarchii raport umożliwia uzyskanie odpowiedzi na zadane wcześniej pytanie. Warstwa prezentacji została zrealizowana z bogatym interfejsem użytkownika, który umożliwia ukrywanie kolumn, zamianę kolumn miejscami, zamrażanie kolumn, zamrażanie nagłówka czy zmianę rozmiaru kolumny. Wszelkie operacje między klientem a

63 ROZDZIAŁ 3. BIBLIOTEKA 57 serwerem są wykonywane w sposób asynchroniczny, co przyspiesza komunikację, ponieważ nie wymagane jest ponowne odświeżenie strony. Klient pobiera tylko i wyłącznie dane, które muszą zostać zaprezentowane użytkownikowi, co wpływa na zmniejszenie ruchu w sieci oraz mniejsze obciążenie bazy danych. Narzędzie daje nieograniczone możliwości filtrowania danych, użytkownik może skonstruować dowolnie złożone wyrażenie logiczne przy pomocy intuicyjnego formularza. Konstrukcja raportów nie wymaga żadnej ingerencji programisty, jest dokonywana w sposób deklaratywny. Co więcej, nie jest wymagana znajomość schematu bazy danych a nawet języka SQL. Administrator bazy danych (lub inna osoba) ma możliwość utworzenia modelu biznesowego, który jest zrozumiały dla osób nietechnicznych. Na podstawie tego modelu analityk biznesowy może tworzyć dowolną liczbę raportów używając klas oraz atrybutów utworzonych wcześniej w modelu biznesowym. Cały model biznesowy oraz definicja raportów zapisywana jest w plikach w formacie XML, co umożliwia ręczne manipulowanie tymi plikami. Dodatkowo są dużo bardziej dostępne, w przeciwieństwie do plików binarnych. Wszystkie pliki mogą zostać utworzone również za pomocą dedykowanego narzędzia z graficznym interfejsem użytkownika, które opisano w rozdziale 4. Zrealizowano również prostą aplikację do udostępniania raportów. Umiejscowienie w odpowiedniej lokalizacji zestawu plików XML oraz konfiguracja połączenia z bazą danych wystarcza do tego, aby aplikacja była zdolna do wyświetlenia wszystkich raportów. Po dokonaniu jakiejkolwiek zmiany w dowolnym z plików XML, czy to w modelu biznesowym czy w jednym z raportów, zostanie ona automatycznie uwzględniona po ponownym uruchomieniu aplikacji. Utworzone raporty również można wyświetlić w dowolnej aplikacji WWW zrealizowanej w technologii Java. Jest to szczególnie łatwe dla aplikacji opartych na GWT, w takim przypadku wystarczy skorzystać z odpowiedniej klasy ReportPanel podając w parametrze konstruktora identyfikator raportu.

64 Rozdział 4 Designer Rozdział ten zawiera opis aplikacji do tworzenia modelu biznesowego oraz raportów przy pomocy graficznego interfejsu użytkownika. Na wstępie opisano wymagania funkcjonalne oraz przypadki użycia. Następnie przedstawiono użyte technologie oraz narzędzia. Na samym końcu zaprezentowano zrealizowaną aplikację. 4.1 Wymagania Wymagania funkcjonalne Założenie nowego projektu. Skonfigurowanie połączenia z bazą danych. Tworzenie modelu biznesowego. 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. 58

65 ROZDZIAŁ 4. DESIGNER Przypadki użycia Aktorzy Twórca modelu biznesowego ich atrybuty. to rola, która tworzy model biznesowy: klasy oraz 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. UC.AC Dodanie klasy Cel Dodanie nowej klasy. Aktor główny Twórca modelu biznesowego Przebieg zdarzeń Nr System Użytkownik 1. Wybiera opcję dodania klasy 2. Wybiera tabelę 3. Podaje nazwę klasy 4. Zatwierdza 5. Wyświetla komunikat o sukcesie Prototyp interfejsu użytkownika UC.ASA Dodanie atrybutu SimpleAttribute Cel Dodanie atrybutu typu SimpleAttribute. Aktor główny Twórca modelu biznesowego

66 ROZDZIAŁ 4. DESIGNER 60 Rysunek 4.1: Przypadki użycia dla twórcy modelu biznesowego Przebieg zdarzeń Nr System Użytkownik 1. Wybiera klasę 2. Wybiera opcję dodania atrybutu SimpleAttribute 3. Podaje wyrażenie 4. Podaje nazwę atrybutu 5. Zatwierdza 6. Wyświetla komunikat o sukcesie

67 ROZDZIAŁ 4. DESIGNER 61 Rysunek 4.2: Przypadki użycia dla projektanta raportów Rysunek 4.3: Dodanie klasy - prototyp Prototyp interfejsu użytkownika Rysunek 4.4: Dodanie atrybutu SimpleAttribute - prototyp

68 ROZDZIAŁ 4. DESIGNER 62 UC.ARA Dodanie atrybutu ReferenceAttribute Cel Dodanie atrybutu typu ReferenceAttribute. Aktor główny Twórca modelu biznesowego Przebieg zdarzeń Nr System Użytkownik 1. Wybiera klasę źródłową 2. Wybiera opcję dodania atrybutu 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 Założenie nowego projektu. Aktor główny Twórca modelu biznesowego

69 ROZDZIAŁ 4. DESIGNER 63 Przebieg zdarzeń Nr System Użytkownik 1. Wybiera opcję nowego projektu 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 opcję konfiguracji 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

70 ROZDZIAŁ 4. DESIGNER 64 UC.A.REPORT Dodanie raportu Cel Dodanie nowego raportu. Aktor główny Projektant raportów Przebieg zdarzeń Nr System Użytkownik 1. Wybiera opcję dodania raportu 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 Dodanie nowej kolumny dla raportu. Aktor główny Projektant raportów

71 ROZDZIAŁ 4. DESIGNER 65 Przebieg zdarzeń Nr System Użytkownik 1. Wybiera raport 2. Wybiera opcję dodania kolumny 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

72 ROZDZIAŁ 4. DESIGNER Projekt Pakiety Rysunek 4.10: Designer - diagram pakietów xalan.designer.model Pakiet zawierający klasy modelu. xalan.designer.service Pakiet udostępniający usługi do zarządzania modelem biznesowym oraz raportami. Zawiera operacje pobierania oraz zapisywania danych. Pakiet zawierający wszelkie widoki: okna dialogowe oraz drze- xalan.designer.view wa.

73 ROZDZIAŁ 4. DESIGNER 67 xalan.designer.view.converters Pakiet odpowiedzialny za dokonywanie konwersji danych tekstowych na obiekty wybranej klasy. Używane przy listach wyboru typu ComboBox. 4.3 Implementacja Technologia Eclipse plugin [29] Aplikacja została zrealizowana jako wtyczka (ang. plugin) do środowiska Eclipse. Główny powód to możliwości integracyjne tej platformy. Użytkownik w jednej aplikacji ma dostępne wszelkie potrzebne narzędzia, gdzie każde z nich jest implementowane w formie wtyczki lub zbioru wtyczek. Dodatkowo architektura tej platformy znacznie ułatwia tworzenie aplikacji z graficznym interfejsem użytkownika. Wiele powtarzających się funkcji zostało już zaimplementowanych, dzięki temu twórca wtyczki może koncentrować się na najistotniejszych aspektach Narzędzia Eclipse PDE Przy tworzeniu aplikacji skorzystano z narzędzia Eclipse PDE (Plug-in Development Environment), które ułatwia proces tworzenia nowych wtyczek do platformy Eclipse umożliwiającej rozwijanie, testowanie, debugowanie oraz wdrażanie. 4.4 Aplikacja W tej sekcji opisano zrealizowaną aplikację. Użytkownik w trakcie pracy z narzędziem porusza się w jednym z trzech widoków: Database Explorer, Classes Explorer oraz Reports Explorer. Database Explorer zawiera podgląd na wszystkie tabele oraz widoki wraz z kolumnami znajdujące się w bazie danych. Umożliwia to szybkie podejrzenie schematu bazy danych. Widok ten został pokazany na rysunku Nie można wykonać żadnej akcji w tym widoku, ponieważ jego rola została ograniczona wyłącznie do funkcji informacyjnej. Kolejny widok Classes Explorer jest używany do zarządzania modelem biznesowym. Zawiera on listę klas wraz z ich atrybutami. Przy manipulowaniu klasami użytkownik ma możliwość dodawania, modyfikowania oraz edycji klas. W celu dodania nowej klasy należy wybrać pierwszą opcję z paska narzędziowego, która ma taką samą ikonkę jak klasa. Po wykonaniu tej czynności zostanie wyświetlone okno z formularzem edycji nowej klasy (rysunek 4.14), w którym należy podać: nazwę klasy, wybrać tabelę z listy oraz podać klucz główny, czyli wybrać jeden z

74 ROZDZIAŁ 4. DESIGNER 68 Rysunek 4.11: Widok Database Explorer atrybutów z listy. Druga opcja z menu służy do edytowania elementów. Po wybraniu elementu w widoku oraz po kliknięciu w przycisk edycji zostanie otworzone odpowiednie okno z formularzem analogicznym do formularza dodania elementu. Trzecia opcja jest używana do usuwania elementów. Kolejne trzy opcje służą do dodawania atrybutów klasy. Możliwe atrybuty zostały opisane w sekcji 3.4. Opcja z niebieskim sześcianem służy do dodawania prostych atrybutów. Formularz związany z tą akcją jest widoczny na rysunku: Wypełniając ten formularz należy podać nazwę atrybutu, wyrażenie SQL oraz określić czy dana kolumna jest miernikiem. Wyrażenie SQL może być po prostu nazwą kolumny, ale w niektórych przypadkach istnieje potrzeba podania bardziej złożonego wyrażenia. Przykładowo w tabele z pracownikami mogą być dwie osobne kolumny na imię oraz nazwisko osoby. Jeżeli w raportach każdy pracownik zawsze będzie wyświetlany jako złożenie imienia oraz nazwiska, to lepiej do klasy dodać od razu atrybut z nazwą pracownika, który jest złączeniem dwóch składowych. W takim przypadku należy wpisać wyrażenie SQL $.imie + + $.nazwisko. Znak $ określa specjalny znacznik, w miejsce którego zostanie podstawiona nazwa tabeli, aby uniknąć problemów związanych z kolumnami, które mają identyczne nazwy a znajdują się w różnych tabelach. Drugim przykładem wyrażenia jest możliwość wydobycia miesięcy, dni, lat z kolumny będącej datą. Dla bazy danych Oracle

75 ROZDZIAŁ 4. DESIGNER 69 Rysunek 4.12: Widok Classes Explorer należy wpisać wyrażenie postaci extract(year from $.month). Kolejna opcja reprezentowana przez ikonkę z trzema sześcianami powoduje dodanie nowego atrybutu typu referencyjnego. Formularz tej akcji widoczny jest na rysunku Użytkownik musi wypełnić następujące pola: podać nazwę atrybutu, wybrać z listy klasę docelową oraz podać kolumnę klucza obcego, według której zostanie dokonane złączenie z kolumną klucza głównego klasy docelowej. Ostatnia opcja związana z atrybutami klasy to dodawanie atrybutów słownikowych. Na pasku narzędziowym jest reprezentowana poprzez zielony sześcian. Po wybraniu tej akcji zostanie wyświetlony formularz z rysunku Użytkownik wypełnia takie same pola jak w przypadku atrybutu referencyjnego dodatkowo wybierając z listy atrybut docelowy. Ostatnie dwie akcje paska narzędziowego służą do rozwijania oraz zwijania wszystkich atrybutów wszystkich klas. Kolejny widok Reports Explorer umożliwia zarządzanie raportami oraz ich kolumnami. Pierwsze trzy opcje z paska narzędziowego służą do dodawania raportów, edycji elementów oraz usuwania elementów. Celem kolejnej opcji jest dodawanie kolumn raportu. Natomiast opcja z ikonką dyskietki służy do zapisy-

76 ROZDZIAŁ 4. DESIGNER 70 Rysunek 4.13: Widok Reports Explorer Rysunek 4.14: Formularz edycji klasy Rysunek 4.15: Formularz edycji Simple Attribute

77 ROZDZIAŁ 4. DESIGNER 71 Rysunek 4.16: Formularz edycji Reference Attribute Rysunek 4.17: Formularz edycji Dictionary Attribute Rysunek 4.18: Formularz edycji raportu

78 ROZDZIAŁ 4. DESIGNER 72 Rysunek 4.19: Formularz edycji kolumny wania modelu biznesowego oraz raportów do repozytorium, czyli zestawu plików w formacie XML. Formularz edycji raportu widoczny na rysunku 4.18 wymaga podania nazwy raportu oraz wybrania z listy klasy głównej raportu. Klasa główna określa rezultat zapytania SQL wpływając na postać złączeń w klauzuli FROM. Wszystkie inne tabele zostają złączone z główną tabelą poprzez szereg złączeń typu klucz obcy równa się klucz główny. Generowanie zapytania SQL zostało opisane w sekcji Dodanie kolumny raportu przebiega w dwóch etapach. Pierwszy etap został pokazany na rysunku Użytkownik musi wypełnić następujące pola: nazwa kolumny, która jest identyfikatorem. Używana jest przy komunikacji klienta z serwerem i nigdzie nie jest wyświetlana;

79 ROZDZIAŁ 4. DESIGNER 73 Rysunek 4.20: Formularz edycji kolumny krok 2 Rysunek 4.21: Formularz edycji kolumny - inna ścieżka tytuł kolumny, czyli etykieta wyświetlana w widoku; opcjonalnie podać format daty lub numeryczny. Format liczby musi być zgodny ze standardem formatów liczbowych biblioteki GWT; podanie ścieżki z ikoną reprezentującą kolumnę. Zostało tutaj podjęte założenie, że jest to ścieżka względna od folderu images znajdującego się w głównym folderze aplikacji. Ikonka jest wyświetlana zarówno w ustalaniu hierarchii grupowania oraz w samym widoku raportu; użytkownik określa, czy dana kolumna może być użyta w hierarchii grupowania. Opcja ta umożliwia wyrzucenie kolumn, które z definicji nie nadają się do grupowania danych, przykładowo: tekstowy opis spotkania, nazwa klienta, dokładna data i czas spotkania;

80 ROZDZIAŁ 4. DESIGNER 74 wybrać z listy typ kolumny: zwykły tekst, liczba całkowita, liczba wymierna, data, wartość logiczna, odnośnik czy obrazek. W przypadku, gdy jest to typ IMG, czyli obrazek w widoku raportu, zostane wyświetlona ikonka, której adres podany jest w wartości kolumny; dla kolumn będących miernikami można podać rodzaj agregacji, wpisując odpowiednią funkcję SQL: sum, avg, min, max, count. Istnieje również możliwość podania funkcji zależnej od bazy danych, przykładowo dla Oracle można podać: variance, stddev, median; wybranie z listy klasy, w której znajduje się atrybut związany z tą kolumną; wybranie atrybutu tej klasy; W kolejnym kroku użytkownik zostanie poproszony o wybranie jednej z możliwych ścieżek od tabeli źródłowej, określonej poprzez główną klasę raportu, do tabeli docelowej zawierającej kolumnę, która określona jest poprzez atrybut docelowy podany w pierwszym kroku. Dokładne znaczenie ścieżek zostało opisane przy generowaniu zapytania SQL w sekcji Na rysunku 4.20 widoczny jest formularz, na którym można wybrać jedną z możliwych ścieżek. Na dole formularza wyświetlany jest podgląd wygenerowanego fragmentu klauzuli WHERE, który odpowiada aktualnie zaznaczonej ścieżce. Na podstawie bazy danych CRM, opisanej w sekcji 3.2.1, zostanie opisany przykładowy scenariusz. Dla raportu dotyczącego spotkań, w którym główna klasa jest związana z tabelą ZDARZENIA, istnieją co najmniej dwa sensowne przypadki określenia doradcy powiązanego z danym spotkaniem. Pierwsza możliwość to po prostu doradca, który był na spotkaniu. Natomiast druga możliwość to doradca będący opiekunem klienta, z którym zostało umówione spotkanie. Dla pierwszej opcji należy wybrać ścieżkę [doradca], wtedy klauzula FROM będzie miała postać widoczną na rysunku 4.20, czyli tabela ZDARZENIA jest bezpośrednio złączona z tabelą DORADCY V. Druga możliwość została pokazana na rysunku W tym przypadku tabela ZDARZENIA najpierw jest złączona z tabelą KLIENCI, a tabela KLIENCI z tabelą DORADCY V. 4.5 Podsumowanie Aplikacja opisana w tym rozdziale znacznie ułatwia tworzenie modelu biznesowego oraz raportów. W wyniku wykonywanych operacji powstaje zestaw plików XML, który należy skopiować w odpowiednią lokalizację w aplikacji serwera, aby zostały wyświetlone wszystkie raporty. Para narzędzi: designer oraz serwer umożliwiają tworzenie oraz udostępnianie raportów bez żadnej ingerencji programisty. Co więcej, wszelkie czynności, z wyjątkiem jednokrotnie wykonanego modelu biz-

81 ROZDZIAŁ 4. DESIGNER 75 nesowego, mogą być wykonywane przez analityka biznesowego nie posiadającego specjalistycznych umiejętności informatycznych. Zarządzanie zarówno modelem biznesowym oraz raportami odbywa się z poziomu dedykowanych formularzy. Wszystkie operacje muszą zostać wykonane w taki sposób co wymaga spożytkowania dużej ilości czasu ze względu na wymaganą liczbę kliknięć. Dodatkowo aktualna wersja aplikacji nie umożliwia wyświetlenia wszystkich danych na jednym widoku, aby projektant miał możliwość spojrzenia na całość projektu a nie tylko na wybrany element. Proponowanym rozwiązaniem, które może być dalszą możliwością rozwoju aplikacji, jest utworzenie widoku zawierającego cały diagram modelu wraz z wszelkimi powiązaniami pomiędzy poszczególnymi obiektami. Diagram ten powinien mieć postać analogiczną do diagramów klas lub diagramów tabel/relacji. Użytkownik powinien dokonywać zmian z poziomu tego widoku. Taka możliwość pozwoliłaby rozwiązać wyżej wymienione problemy. Do implementacji takiej funkcjonalności można by skorzystać z narzędzia Eclipse Graphical Modeling Project (GMP) [13], które dostarcza zestaw generatywnych komponentów i środowisko dla rozwoju graficznych edytorów.

82 Rozdział 5 Rozszerzenia W tym rozdziale opisano dwie aplikacje prezentujące raporty w sposób graficzny za pomocą wykresów. Obie komunikują się z serwerem udostępniającym dane o raportach. Usługa dostarczająca dane w postaci plików XML pozwala ma utworzenie klientów prezentujących dane w dowolny sposób. Jest to kolejna zaleta zrealizowanej platformy. 5.1 Aplikacja mobilna Pierwsza aplikacja została zrealizowana w wersji mobilnej. Użytkownik ma możliwość wybrania raportu, który zamierza wyświetlić. W kolejnym kroku dokonywana jest konfiguracja hierarchii grupowania. Następnie zostaje wyświetlony raport w postaci wykresu słupkowego. System umożliwia zwijanie oraz rozwijanie danych, wybór miernika oraz sortowanie danych według wartości miernika lub etykiet Technologia Android [1] Android to zestaw oprogramowania dla urządzeń mobilnych, który zawiera system operacyjny, middleware i zestaw kluczowych aplikacji. Większość urządzeń wyposażonych w ten system posiada ekran dotykowy: telefony komórkowe, tablety PC oraz czytniki książek elektronicznych. Wybrane firmy korzystające z tego systemu to: HTC, LG, Motorola, Samsung oraz Sony. 76

83 ROZDZIAŁ 5. ROZSZERZENIA Narzędzia ADT Plugin [12] Android Development Tools (ADT) jest wtyczką do Eclipse IDE, która została zaprojektowany aby udostępnić zintegrowane środowisko do budowy aplikacji opartych o system Android. ADT rozszerza możliwości Eclipse umożliwiając szybkie utworzenie nowych projektów Android, tworzenie interfejsu użytkownika aplikacji, dodawanie komponentów w oparciu o Android Framework API, debugowanie aplikacji za pomocą narzędzi SDK Android oraz export plików.apk w celu rozpowszechniania aplikacji Aplikacja Po uruchomieniu aplikacji zostaje wyświetlona lista raportów. Lista ta pobierana jest z zrealizowanego serwera udostępniającego dane o raportach. Plik parsowany jest następnie przez warstwę klienta za pomocą standardowej biblioteki Java. Widok początkowy przedstawiony jest na rysunku 5.1. Rysunek 5.1: Widok wyboru raportu Po wybraniu raportu otworzony zostanie ekran przedstawiony na rysunku 5.2. Po lewej stronie znajduje się lista wszystkich dostępnych kolumn w raporcie. Po wybraniu kolumny z lewej listy, jest ona dodawana na końcu listy wybranych kolumn. Druga lista zwiera hierarchię grupowania, względem której dane będą zwijane/rozwijane podczas generowania wykresu.

84 ROZDZIAŁ 5. ROZSZERZENIA 78 Rysunek 5.2: Widok wyboru kolumn Po naciśnięciu przycisku Plot zostanie wyświetlony wykres (rys. 5.3). W trakcie realizacji projektu zadbano przyjazny interfejs użytkownika, bogaty w animacje oraz starannie dobrane kolory, których barwa jest zależna od wartości prezentowanej przez dany słupek. Dodatkowo zastosowanie cieni i anty aliasingu poprawia czytelność wykresu. Wyróżniono pięć grup wartości słupka: górny kwartyl - kolor niebieski zakres pomiędzy medianą a górnym kwartylem - kolor zielony mediana - kolor fioletowy, przy czym słupek oznaczony jako mediana występuje tylko wtedy, gdy liczba słupków jest nieparzysta zakres pomiędzy medianą a dolnym kwartylem - kolor żółty dolny kwartyl - kolor czerwony Po pojedynczym zaznaczeniu słupka zostanie od podświetlony. Ponowne wybranie spowoduje rozwinięcie danych i wyświetlenie poziomu niżej hierarchii grupowania. Po naciśnięciu przycisku Drill up zostanie wykonana operacja odwrotna, czyli zwinięcie danych i powrót do poziomu wyżej. Użytkownik ma możliwość wyboru miernika, który jest wyświetlany na wykresie, do tego celu jest używana dedykowana lista możliwych mierników. Aplikacja pozwala na sortowanie słupków według wartości malejąco i rosnąco oraz według kolejności alfabetycznej etykiet. W przypadku, gdy wszystkie słupki nie mieszczą się na ekranie wyświetlacza

85 ROZDZIAŁ 5. ROZSZERZENIA 79 Rysunek 5.3: Wygenerowany wykres komórki użytkownika ma możliwość przewinięcia wykresu w dół. Operacja ta została zaimplementowana samodzielnie poprzez metodę ontouch. 5.2 Wykresy WWW Druga aplikacja to strona WWW umożliwiająca wyświetlanie wykresów. W ramach pracy magisterskiej zostały zrealizowane wykresy kołowe oraz słupkowe. Użytkownik ma możliwość rozwijania danych szczegółowych (operacja drill down) oraz zwijania danych (drill up) Technologia Javascript Aplikacja została zrealizowana w całości za pomocą języka Javascript. Strona komunikuję się asynchronicznie z serwerem w celu pobrania potrzebnych danych. Do tego celu została użyta biblioteka jquery. Google Visualization API [14] Google Visualization API umożliwia dostęp do wielu źródeł danych, które można wyświetlić, wybierając z dużego wyboru wizualizacji. W ten sposób można tworzyć raporty i pulpity nawigacyjne, a także analizować i wyświetlać dane poprzez bogactwo dostępnych aplikacji wizualizacyjnych.

86 ROZDZIAŁ 5. ROZSZERZENIA Aplikacja W ramach aplikacji został utworzony komponent, który potrafi wyświetlić dowolny raport w postaci wykresu. Przy tworzeniu wykresu należy podać następujące parametry: elementid Określa miejsca na stronie, w którym zostanie wyświetlony wykres. Jest to identyfikator elementu HTML. reportid Parametr ten ustala raport, dla którego zostanie wyświetlony wykres. Zostaje on określony przy tworzeniu modelu raportu przy pomocy dedykowanego narzędzia Designer opisanego w rozdziale 4. hierarchy Napis reprezentujący hierarchię grupowania podany w postaci: KO- LUMNA 1 ID ; KOLUMNA 2 ID ;...; KOLUMNA N ID, gdzie poszczególne wartości oznaczają identyfikatory kolumn, które również zostały podane podczas tworzenia modelu raportu. Przykładowo napis: region;zespol;doradca może oznaczać hierarchię Region, zespół doradców oraz doradca. Taka hierarchia grupowania oznacza, że przy pierwszym wyświetleniu wykresu zostaną podane wartości miernika dla poszczególnych regionów, po kliknięciu w region zostaną wyświetlone wszystkie zespołu znajdujące się w tym regionie, natomiast po kliknięciu w zespół zostaną podane wartości dla doradców z tego zespołu. measure Identyfikator kolumny, która jest miernikiem. title Tytuł wykresu. Narzędzie to umożliwia konstruowanie dedykowanych paneli menedżerskich (ang. Dashboard), gdzie na jednej stronie będzie wyświetlany zbiór wykresów. Wszelkie dane pobierane są z zewnętrznego serwera w postaci plików XML. W wersji aktualnej wymagana jest minimalna ingerencja programisty, który ma za zadanie wywołanie funkcji Javascript, które definiują parametry wyświetlanego wykresu. Utworzenie dedykowanego narzędzia do tworzenia paneli menedżerskich jest jedną z możliwości rozwoju zrealizowanej platformy. Taki system powinien umożliwiać tworzenie paneli bez żadnej ingerencji programisty w sposób deklaratywny z wykorzystaniem graficznego interfejsu użytkownika. Aplikacja przedstawiona w tym rozdziale udowadnia, że jest to możliwe. Przykładowe analizy Na przykładzie bazy danych systemu CRM opisanej w sekcji przedstawiono przykładowe analizy. Ustalając hierarchię grupowania rok, miesiąc, zespół oraz wybierając jako miernik liczbę spotkań zostanie wyświetlony wykres przedstawiony na rysunku 5.4, na którym widoczna jest liczba spotkań w poszczególnych

87 ROZDZIAŁ 5. ROZSZERZENIA 81 Rysunek 5.4: Wykres kołowy - spotkania w poszczególnych latach Rysunek 5.5: Wykres kołowy - spotkania w poszczególnych miesiącach Rysunek 5.6: Wykres kołowy - spotkania w poszczególnych zespołach latach. Po wybraniu roku zostanie pokazana liczba spotkań w poszczególnych miesiącach tego roku (rysunek 5.5). Następnie po wybraniu miesiąca zostanie wyświetlona liczba spotkań poszczególnych zespołów w tym miesiącu, co zostało pokazane na rysunku 5.6. Po najechaniu na wycinek wykresu zostanie wyświetlona podpowiedź zawierająca nazwę elementu, wartość miernika oraz procentowy udział.