Praca dyplomowa magisterska

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

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

Spis treści Spis treści i 1 Wstęp 1 1.1 Cel pracy................................ 2 1.2 Zakres pracy.............................. 2 2 Raportowanie 3 2.1 Metody prezentacji danych...................... 3 2.1.1 Tabelka............................. 3 2.1.2 Tabelka z pojedynczym poziomem grupowania....... 3 2.1.3 Tabelka z wieloma poziomami grupowania.......... 3 2.1.4 Tabelka z dynamiczną hierarchią grupowania........ 3 2.2 Business Intelligence.......................... 4 2.2.1 Definicja [9]........................... 4 2.2.2 Historia powstania Business Intelligence [9]......... 4 2.2.3 Piramida Business Intelligence [3]............... 4 2.3 Istniejące rozwiązania Business Intelligence............. 5 2.3.1 Jaspersoft............................ 5 2.3.2 IBM Cognos.......................... 10 3 Biblioteka 11 3.1 Wymagania............................... 11 3.1.1 Wymagania funkcjonalne................... 11 3.1.2 Wymagania niefunkcjonalne.................. 12 3.1.3 Przypadki użycia........................ 12 3.2 Przykładowe bazy danych....................... 17 3.2.1 CRM.............................. 17 3.2.2 Service Desk.......................... 20 3.3 Przykładowe raporty.......................... 22 3.3.1 Service Desk.......................... 22 i

SPIS TREŚCI ii 3.3.2 CRM.............................. 22 3.4 Meta-Model............................... 24 3.4.1 Meta-model biznesowy..................... 24 3.4.2 Przykładowy model biznesowy................ 25 3.4.3 Meta-model raportu...................... 27 3.4.4 Przykładowy raport...................... 29 4 Designer 31 4.1 Wymagania............................... 31 4.1.1 Wymagania funkcjonalne................... 31 4.1.2 Przypadki użycia........................ 31 Bibliografia 39 Spis symboli i skrótów 40 Spis rysunków 41 Spis tabel 42

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

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

Rozdział 2 Raportowanie 2.1 Metody prezentacji danych 2.1.1 Tabelka Najbardziej prymitywna metoda. Wszystkie dane prezentowane są w postaci tabeli dwuwymiarowej. W przypadku dużego wolumenu danych nie można nic wywnioskować z takiej postaci. Małym udoskonaleniem jest możliwość filtrowania oraz sortowania danych. 2.1.2 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). 2.1.3 Tabelka z wieloma poziomami grupowania Udoskonalenie poprzedniej metody umożliwiające utworzenie hierarchii grupowania, przykładowo rok, kwartał, miesiąc lub grupa produktu, produkt. Aczkolwiek możliwych hierarchii grupowania może być zbyt dużo. 2.1.4 Tabelka z dynamiczną hierarchią grupowania Użytkownik sam decyduje według jakiej hierarchii chce oglądać dane. 3

ROZDZIAŁ 2. RAPORTOWANIE 4 2.2 Business Intelligence 2.2.1 Definicja [9] Business Intelligence jest definiowane przez firmę Gartner jako zorientowany na użytkownika proces zbierania, eksploracji, interpretacji i analizy danych, który prowadzi do usprawnienia i zracjonalizowania procesu podejmowania decyzji biznesowych w celu kreowania wzrostu wartości przedsiębiorstwa. 2.2.2 Historia powstania Business Intelligence [9] Na powstanie Business Intelligence miało wpływ parę 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. Ważniejszym 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. W latach 90 Business Intelligence stało się terminem powszechnie znanym wśród fachowców oraz standardem oferowanym przez firmy specjalistyczne oraz największych producentów oprogramowania takich jak IBM, Microsoft, Oracle czy SAP. 2.2.3 Piramida Business Intelligence [3] 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ę rodzajów narzędzi klasy Business Intelligence. Na samym dole znajduję się oprogramowanie hurtowni danych, które umożliwia projektowanie struktury bazy danych, pobieranie danych, czyszczenie danych oraz 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, czyli środowisko wielowymiarowych analiz. Na samej górze piramidy są narzędzia do eksploracji danych, których celem jest znalezienie zależności w danych i prognozowanie.

ROZDZIAŁ 2. RAPORTOWANIE 5 Rysunek 2.1: Piramida Business Intelligence 2.3 Istniejące rozwiązania Business Intelligence 2.3.1 Jaspersoft Jaspersoft jest 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 [6] to biblioteka Open Source do tworzenia raportów w wielu popularnych formatach: PDF, HTML, XLS, XML. Została zaimplementowana w całości w technologii Java. Twórcy biblioteki przywiązali dużą uwagę 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, XML. ireport [4] jest to narzędzie z graficznym interfejsem użytkownika służące do tworzenia raportów. JasperServer [7] jest 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.

ROZDZIAŁ 2. RAPORTOWANIE 6 JasperETL [5] jest to narzędzie wspierające 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 dokonania ich konfiguracji. Cykl życia raportu [1] Rysunek 2.2: JasperReprots - 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ę elementów znajdujących w raporcie. Po stworzeniu szablonu silnik JasperReports dokonuje kompilacji raportu. W wyniku powstaje raport w postaci skompilowanej. Przyjęło się taki plik 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ęto konwencją rozszerzenie pliku to jrxml. Każdy szablon zawiera informację o parametrach, polach oraz o elementach raportu. Struktura pliku jest następująca: <?xml version="1.0"?> <!DOCTYPE jasperreport PUBLIC "-//JasperReports//DTD Report Design//EN" "http://jasperreports.sourceforge.net/dtds/jasperreport.dtd"> <jasperreport name="name_of_the_report"... >...

ROZDZIAŁ 2. RAPORTOWANIE 7 </jasperreport> Parametry są to dane, które nie mogą być wydobyte z źródła danych. Częstym zastosowaniem parametrów jest określenie warunków zapytania. W przypadku szczególnym parametrem może być same zapytanie. Przykładowe parametry: Dynamiczny tytuł raportu. Wartości do warunków w zapytaniach. Nazwa użytkownika, który uruchomił raport. Deklaracja dynamicznego tytułu raportu: <parameter name="reporttitle" class="java.lang.string"/> Przekazanie identyfikatora klienta do zapytania: <parameter name="customerid" class="java.lang.integer"/> Następnie taki parametr może zostać użyty w warunku zapytania w następujący sposób: SELECT FROM Orders WHERE CustomerID = $P{ CustomerId } 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}

ROZDZIAŁ 2. RAPORTOWANIE 8 Wyrażenia są potężną funkjonalnościa 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 dokonannie złączenie dwóch napisów: <textfieldexpression> $F{FirstName} + " " + $F{LastName} </textfieldexpression> Może to być bardziej skomplikowane wyrażenie: <textfieldexpression> $F{FirstName} + " " + $F{LastName} + " was hired on " + (new SimpleDateFormat("MM/dd/yyyy")).format($F{HireDate}) + "." </textfieldexpression> Zmienne są specjalnym obiektem zbudowanym w oparciu o wyrażenie. Jeżeli istnieje potrzeba wykorzystania danego wyrażenia więcej jak jeden raz to należy utworzyć zmienną. Zmienna może przechowywać wartość agregacji jednego z mierników. Jako funkcje agregacji można wykorzystać: count, sum, average, lowest, highest, variance, etc. Przykład deklaracji zmiennej dokonującej policzenia sumy: <variable name="quantitysum" class="java.lang.double" calculation="sum"> <variableexpression>$f{quantity}</variableexpression> </variable> Istnieje również szereg wbudowanych zmiennych: PAGE NUMBER numer aktualnej strony. COLUMN NUMBER numer aktualnej kolumny. PAGE COUNT liczba stron. Kompilacja Kompilacja jest to przekształcenie szablonu raportu w postaci pliku xml na postać binarną do formatu jasper. Wypełnienie Na tym etapie następuję podstawienie danych z źródła danych oraz parametrów. W ten sposób otrzymujemy postać raportu gotową do wyeksportowania.

ROZDZIAŁ 2. RAPORTOWANIE 9 Eksport Eksport raportu jest to proces wygnerowania 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, rtf. Pozycja Jaspersoft w raporcie Gartner-a [2] Rysunek 2.3: Magic Quadrant Gartnera dla Platform Business Intelligence na 2011 rok. Jaspersoft został doceniony przez analityków Gartnera o czym świadczy pojawienie się tego rozwiązania wśród graczy niszowych wśród platform Business Intelligence na rok 2011 2.3. Wedle 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

ROZDZIAŁ 2. RAPORTOWANIE 10 Source. Druga popularna platforma Open Source: Pentaho nie spełniła wszystkich warunków, aby zająć swoje miejsce wśród najlepszych rozwiązań Business Intelligence, aczkolwiek wedle analityków Gartnera jest to opcja warta do rozważenia. Mocne strony Jaspersoft Jaspersoft oferuje platformę Open Source z szerokim wachlarzem możliwości. Składa się ona z JasperServer, JasperReports, ireport, JasperETL. Klienci mają możliwość umieszczenia raportów w swoich aplikacjach. Największa zaletą jest niski koszt. TCO jest najniższy wśród wszystkich dostawców BI. Wedle opinii klientów koszt utrzymania tego rozwiązania jest poniżej średniej. Pomimo tego, że jest to rozwiązanie Open Source z niskim kosztem licencji planowany jest rozwój funkcjonalności, które nie są uwzględnione 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. Wysoki procent klientów JasperSoft zadeklarowało wdrożenie platformy w chmurze prywatnej lub publicznej. Jest to wynik wyższy niż konkurencyjnych rozwiązań. Ostrzeżenia Jaspersoft uważa się za lidera w rozwiązań Open Source. Dane firmy mówią o 13500 komercyjnych klientów co potwierdzają obroty firmy. Jednakże tylko 20 klientów spełnia kryteria wyznaczone przez raport Gartnera. Wdrożenia Jaspersoft dotyczą mniejszej wielkości firm 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 jest wdrażane w celach raportowych. Z tego powodu klienci twierdzą, że ta platforma jest mniej funkcjonalna niż rozwiązania konkurencyjne. Wsparcie techniczne oferowane przez firmę zostało ocenione nisko, pomimo tego, iż jest to kluczowy element strategii biznesowej firmy. Jaspersoft został nisko oceniony w łatwości użycia kompenentów oraz łatwości integracji elementów platformy. 2.3.2 IBM Cognos

Rozdział 3 Biblioteka W tym rozdziale zaprezentowano bibliotekę dla hierarchicznych raportów. Na wstępie przedstawiono wymagania stawianej takiej bibliotece z podziałem na wymagania użytkownika oraz twórcy raportów. Następnie omówiono przypadki użycia raportu. 3.1 Wymagania 3.1.1 Wymagania funkcjonalne Perspektywa użytkownika Użytkownik korzystający z raportu, powinien mieć możliwość oglądania tylko takich danych, które go w danej chwili interesują. Powinien mieć możliwość wprowadzania dynamicznych zmian w raporcie: sortowania, zamrażania kolumn oraz zmiany hierarchii grupowania. Powinien mieć również możliwość wyeksportowania danych do pliku w formacie csv lub xls. Zatem biblioteka winna obsługiwać następujące rodzaje ingerencji i typy prezentacji na raportach: sortowanie wierszy; zwijanie/rozwijanie danych; filtrowanie danych; różne typy kolumn: waluta, data, wartość boolowska, odsyłacz; dynamiczna zmiana hierarchii; eksport danych do pliku; 11

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ROZDZIAŁ 3. BIBLIOTEKA 28 Rysunek 3.10: Meta-model raportu mainclass). Każdy węzeł ścieżki powiązany jest z atrybutem meta-modelu klas: ReferenceAttribute. Wyjątkiem jest ostatni element, który jest typu SimpleReportColumn, czyli wskazuję na obiekt typu SimpleAttribute. Taki rodzaj kolumny jest potrzebny, ponieważ w modelu biznesowym mogą być cykle. Z czego wynika istnienie wielu ścieżek pomiędzy dwiema klasami. W

ROZDZIAŁ 3. BIBLIOTEKA 29 takim przypadku projektant raportu zostanie poproszony o wybranie jednej z tych ścieżek. Przykładowy model biznesowy opisany w sekcji 3.4.2 zawiera cykl pomiędzy klasami: Spotkanie, Doradca oraz Klient. 3.4.4 Przykładowy raport Na podstawie modelu biznesowego omówionego w sekcji 3.4.2 przedstawiono realizację raportu Spotkania zaprezentowanego w sekcji 3.3. Kolumna w raporcie Klasa Atrybut Region Klient region Oddział Klient oddzial Doradca Klient doradca Klient Klient nazwa Data spotkania Spotkanie data Temat Spotkanie temat Opis Spotkanie opis Tabela 3.3: Raport spotkania - realizacja Rysunek 3.11 przedstawia diagram obiektów dla fragmentu tego raportu. Obiekt klasy Report reprezentuję model. Powiązany jest on z klasą Spotkanie. Na rysunku widoczne są dwie kolumny raportu: temat oraz klient. Pierwsza jest typu ReportSimpleColumn i wskazuję na atrybut temat klasy Spotkanie, natomiast druga jest typu ReportReferenceColumn, ponieważ wskazuje na atrybut innej klasy niż klasa mainclass. Widoczna jest tutaj ścieżka od klasy Spotkanie do atrybutu nazwa z klasy Klient, która reprezentowana jest przy pomocy klas: ReportReferenceColumn oraz ReportSimpleColumn.

ROZDZIAŁ 3. BIBLIOTEKA 30 Rysunek 3.11: Diagram obiektów dla raportu Spotkania

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

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

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

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

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

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

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

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