praca dyplomowa inŻynierska · data rozpoczęcia studiów: ... zastosowane technologie, metody...

Rok akademicki 2013/2014

Politechnika Warszawska

Wydział Elektroniki i Technik Informacyjnych

Instytut Informatyki

PRACA DYPLOMOWA INŻYNIERSKA

Jakub Sędek

Aplikacja do oceny kredytowej klientów banku

zrealizowana z wykorzystaniem środowiska

i narzędzi SAS

Opiekun pracy

dr inż. Andrzej Ciemski

Ocena: .....................................................

................................................................

Podpis Przewodniczącego

Komisji Egzaminu Dyplomowego

Kierunek: Informatyka

Specjalność: Inżynieria Systemów Informatycznych

Data urodzenia: 28 stycznia 1990 r.

Data rozpoczęcia studiów: 1 października 2009 r.

Życiorys

Nazywam się Jakub Sędek i urodziłem się 28 stycznia 1990 roku w Warszawie. Po

skończeniu szkoły podstawowej nr 124 im. Stanisława Jachowicza oraz gimnazjum

numer 104 zostałem przyjęty do XVIII LO im. Jana Zamoyskiego w Warszawie do

klasy o profilu matematyczno-fizycznym. W 2009 roku zdałem maturę i rozpocząłem

studia na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej na

kierunku Informatyka.

........................................................

Jakub Sędek

EGZAMIN DYPLOMOWY

Złożył egzamin dyplomowy w dniu ................................................................................. 20__ r

z wynikiem ...................................................................................................................................

Ogólny wynik studiów: ................................................................................................................

Dodatkowe wnioski i uwagi Komisji: .........................................................................................

......................................................................................................................................................

......................................................................................................................................................

STRESZCZENIE

Praca prezentuje projekt i implementację aplikacji umożliwiającej dokonywanie oceny

kredytowej osób starających się o kredyt w banku. Przedstawia proces budowy i oceny

modelu oceny kredytowej w oparciu o narzędzie SAS Enterprise Miner, drzewa

decyzyjne i bazę danych udzielonych kredytów klientom niemieckiego banku.

Praca opisuje także projekt aplikacji w języku UML przy użyciu diagramów

przypadków użycia, komponentów, klas i sekwencji. Definiuje wymagania

funkcjonalne i niefunkcjonalne stawiane aplikacji. Zawiera także opis implementacji

aplikacji opartej na wzorcu architektonicznym MVC i bibliotece graficznej SWING

oraz prezentuje jej działanie.

Słowa kluczowe: ocena kredytowa, MVC, SAS Enterprise Miner, SWING, drzewo

decyzyjne

The application for the credit scoring of bank customers using SAS

environment and tools

The thesis presents the design and implementation of an application that allows credit

scoring of persons applying for a loan at the bank. Shows the construction and the

evaluation process of credit scoring model based on the SAS Enterprise Miner tool,

decision trees and a database of loans granted to customers of the German bank.

The thesis also describes the application design in UML language using use case,

components, classes and sequence diagrams. Defines the functional and nonfunctional

requirements of the application. It also contains a description of the implementation

based on the MVC architectural pattern and SWING graphical library and presents its

running.

Keywords: credit scoring, MVC, SAS Enterprise Miner, SWING, decision tree

Spis treści

1. Wprowadzenie ....................................................................................................................... 1

1.1. Tematyka pracy ...................................................................................................... 1

1.2. Cel pracy ................................................................................................................ 2

1.3. Zawartość ............................................................................................................... 2

2. Zastosowane technologie, metody oraz narzędzia ............................................................. 4

2.1. Technologie ........................................................................................................... 4

2.1.1. MVC ............................................................................................................... 4

2.1.2. XML ................................................................................................................ 5

2.2. Metody ................................................................................................................... 6

2.2.1. SEMMA .......................................................................................................... 6

2.2.2. Drzewo decyzyjne ........................................................................................... 7

2.3. Narzędzia ............................................................................................................... 8

2.3.1. SAS Enterprise Miner ..................................................................................... 8

2.3.2. Eclipse IDE ..................................................................................................... 9

2.3.3. Eclipse WindowBuilder ................................................................................ 10

2.3.4. JUnit .............................................................................................................. 11

2.3.5. Javadoc .......................................................................................................... 11

3. Projekt i implementacja ..................................................................................................... 13

3.1. Model eksploracji danych .................................................................................... 13

3.1.1. Zbiór danych trenujących ............................................................................. 13

3.1.2. Partycjonowanie danych ............................................................................... 26

3.1.3. Drzewo decyzyjne ......................................................................................... 27

3.1.4. Ocena modelu ............................................................................................... 28

3.2. Analiza wymagań aplikacji .................................................................................. 30

3.2.1. Wymagania funkcjonalne ............................................................................. 30

3.2.2. Wymagania niefunkcjonalne ........................................................................ 31

3.3. Projekt aplikacji ................................................................................................... 31

3.3.1. Przypadki użycia ........................................................................................... 31

3.3.2. Diagram komponentów ................................................................................. 33

3.3.3. Diagramy klas ............................................................................................... 34

3.3.4. Diagramy sekwencji ..................................................................................... 38

3.4. Opis implementacji aplikacji ............................................................................... 40

3.4.1. Architektura i klasy pomocnicze .................................................................. 40

3.4.2. Kontroler ....................................................................................................... 42

3.4.3. Model ............................................................................................................ 45

3.4.4. Widok ............................................................................................................ 48

3.5. Testowanie aplikacji ............................................................................................ 50

3.5.1. Testy jednostkowe ........................................................................................ 50

3.5.2. Testy integracyjne ......................................................................................... 51

3.5.3. Testy systemowe ........................................................................................... 51

3.6. Przedstawienie funkcjonalności aplikacji ............................................................ 51

3.6.1. Wykonanie oceny kredytowej ...................................................................... 52

3.6.2. Konfiguracja aplikacji ................................................................................... 56

4. Podsumowanie ..................................................................................................................... 58

4.1. Weryfikacja wymagań ......................................................................................... 58

4.2. Dalsze kierunki rozwoju pracy ............................................................................ 60

Bibliografia .............................................................................................................................. 61

Spis rysunków, tabel i wydruków .......................................................................................... 63

1

1. Wprowadzenie

Cechą otaczającej nas rzeczywistości jest niepewność. Towarzyszy ona zwyczajnym

czynnościom życiowym, zawiera się w sferze marzeń, związana jest z działaniem

przedsiębiorstw, zjawiskami atmosferycznymi - ze wszystkim co nas otacza.

W związku z tym jesteśmy zmuszeni do tego, aby analizować przyczyny i możliwie

trafnie przewidywać skutki poszczególnych decyzji. Dotyczy to zarówno

przedsiębiorstw, które podejmując decyzje biznesowe, określają czy są w stanie

zachować konkurencyjność i utrzymać się na rynku, jak i poszczególnych osób

fizycznych, które podejmują określone decyzje życiowe.

1.1. Tematyka pracy

Przedmiotem niniejszej pracy jest prezentacja programu oceny ryzyka w sektorze

działalności bankowej. Jednym z rodzajów ryzyka, z jakim zmaga się ten obszar jest

udzielanie kredytów. Oferta kredytowa to istotne źródło dochodów banków oraz ich

rentowności. Pożyczkodawcy stosują różne wskaźniki opłacalności takiej działalności.

Ważna jest ocena zdolności kredytowej klienta (ang. credit scoring). Dzieli ona

klientów banku na grupę, której nie należy udzielać kredytu ze względu na zbyt duże

ryzyko oraz tych którym można zaoferować kredyt. Scoring1 kredytowy uzyskuje się na

podstawie opracowanego wcześniej modelu. Powinien być tak zbudowany, aby można

było łatwo uzyskać informacje potrzebne do jego zastosowania. Istotną jego cechą ma

być także wydajność - dla optymalizacji czasu i kosztów. Jego wyniki winny być

jednoznacznie interpretowalne i cechować się jak największą dokładnością.

Budowę takich modeli umożliwia rozwijająca się od pewnego czasu dziedzina

eksploracji danych (ang. data mining). Jest ona „(...) procesem odkrywania znaczących

nowych powiązań, wzorców i trendów przez przeszukiwanie dużych ilości danych

zgromadzonych w skarbnicach danych, przy wykorzystaniu metod rozpoznawania

wzorców, jak również metod statystycznych i matematycznych” [1].

1 Podjąłem decyzję o zastosowaniu słowa „scoring” w oparciu o jego powszechne użycie w polskiej

literaturze takiej jak artykuły SAS Institute, StatSoft i w branży bankowej (patrz słownik pojęć

kredytowych www.bik.pl dostęp 02.09.2014r.)

http://www.bik.pl/

2

Tworzenie modeli w oparciu o eksplorację danych opiera się więc na analizie

dotychczasowych doświadczeń banku. Historia kredytowa klientów stanowi punkt

wyjścia w poszukiwaniu określonych schematów na podstawie których można określić

prawdopodobieństwo spłaty zaciągniętych zobowiązań. Algorytmy analizy danych

skupiają się więc na wyborze takich cech związanych z pożyczką jak: wielkość, czas

trwania, dane klienta. Szukanie powiązań, wzorców i trendów odbywa się poprzez

wykorzystanie różnych metod. Wśród nich można wymienić: przygotowanie danych,

graficzną wizualizację, drzewa klasyfikacyjne, regresję logistyczną, sieci neuronowe

i inne.

1.2. Cel pracy

Przy wyborze tematu pracy kierowałem się chęcią praktycznego zastosowania technik

eksploracji danych. Moje zainteresowania w dziedzinie bankowości, jak również praca

przy tworzeniu portalu dla jednego z domów maklerskich zaowocowały stworzeniem

aplikacji do oceny kredytowej. Duże korporacje korzystają z kompleksowych systemów

typu CRM (ang. Customer Relationship Management - zarządzanie relacjami

z klientami), dlatego za cel postawiłem sobie stworzenie produktu przeznaczonego dla

niewielkich przedsiębiorstw. Firmy prowadzące działalność na mniejszą skalę nie są

w stanie pozwolić sobie na zamówienie wcześniej wspomnianego systemu, który jest

kosztowny. Chciałem także, aby moja aplikacja mogła rozwijać się wraz z rozwojem

firmy, dlatego cechuje się skalowalnością i integrowalnością. Stworzony program

autorski jest przyjazny w obsłudze i umożliwia sprawną wymianę modeli.

Do zbudowania modelu oceny kredytowej wybrałem narzędzie firmy SAS Institute -

SAS Enterprise Miner, gdyż uznałem, że rozwiązania środowiska SAS są wiodącymi

w dziedzinie analizy biznesowej. Drzewo decyzyjne posłużyło za metodę modelowania.

Do stworzenia aplikacji użyłem popularnego języka programowania Java. Program

powstał przy użyciu narzędzi programistycznych opartych o platformę Eclipse i został

zbudowany w architekturze MVC.

1.3. Zawartość

Pracę zawarłem w czterech rozdziałach. Pierwszym jest niniejszy wstęp. W drugim

rozdziale przedstawiłem narzędzia, technologie i metody stosowane w pracy. Czytelnik

znajdzie w nim informacje o architekturze MVC, języku XML, metodzie SEMMA,

3

drzewach decyzyjnych, środowisku SAS, platformie Eclipse i jej wtyczkach, narzędziu

do testowania aplikacji oraz jej dokumentowania.

Rozdział trzeci opisuje projekt i jego implementację. Rozpoczyna go przedstawienie

budowy modelu oceny kredytowej w jego poszczególnych etapach. Po nim

zaprezentowałem projekt aplikacji przy użyciu języka UML. Znajdują się tam diagramy

przypadków użycia, komponentów, klas i sekwencji. Kolejną częścią jest opis

implementacji poszczególnych części programu. Po nim następuje opis testowania

aplikacji oraz przykład wybranej sesji z użytkownikiem.

Ostatni rozdział jest podsumowaniem wyników pracy. Opisałem w nim to, co udało mi

się zrealizować według oczekiwań oraz zaprezentowałem możliwe dalsze kierunki

rozwoju tej pracy. Mam nadzieję, że sporządzona przeze mnie analiza przyczyni się do

dalszego rozwoju prostych narzędzi kontroli zdolności kredytowej w sektorze średnich

i małych firm.

4

2. Zastosowane technologie, metody oraz narzędzia

2.1. Technologie

2.1.1. MVC

MVC (ang. Model-View-Controller - Model-Widok-Kontroler) jest wzorcem

architektonicznym stosowanym w aplikacjach z graficznym interfejsem użytkownika.

Został zaprojektowany 1979 roku przez Trygve Reenskaug pracującego nad językiem

Smalltalk.

Zastosowanie tego wzorca ma miejsce w podziale aplikacji na trzy logiczne części.

Każda z nich spełnia wyznaczone zadania oraz komunikuje się z pozostałymi obiektami

w określony sposób. Pierwszą z nich jest widok, który odpowiedzialny jest za interakcje

z użytkownikiem - wyświetlaniem elementów interfejsu użytkownika. W zależności od

aplikacji i jej implementacji interfejs może przyjąć formę graficzną (GUI - Graphical

User Interface) lub tekstową (CLI - Command Line Interface) - widok linii komend. Do

widoku można także zaliczyć interfejs programowania aplikacji (API - Application

Programming Interface) [2].

Kolejnym elementem tej architektury jest model. W modelu implementowana jest

logika aplikacji i przechowywane są dane. Model zarządza również stanem, w jakim

znajduje się program, tzn. odpowiada na zapytania dotyczące aktualnego stanu i reaguje

na komunikaty modyfikujące go.

Ostatnim elementem MVC jest kontroler. Reaguje na zdarzenia generowane przez

użytkownika i decyduje o zmianie widoku lub modelu. Jego głównym zadaniem jest

kontrola wymiany informacji między widokiem, a modelem. Zabezpiecza on,

w wypadku równoległych zdarzeń, przed nieprzewidywalnymi zachowaniami i stanami

aplikacji.

Konsekwencją takiego podziału zadań między modelem, widokiem i kontrolerem jest

wymóg obustronnej komunikacji między kontrolerem, a widokiem. Widok musi mieć

możliwość bezpośredniego przekazywania zdarzeń kontrolerowi, a kontroler możliwość

odświeżenia i zmiany wyglądu widoku. Widok w rezultacie zna interfejs dostępu do

5

kontrolera. Kontroler zna interfejs do widoku i także do modelu, za pomocą którego

realizuje logikę przetwarzania danych. Jednak model wcale nie musi posiadać

informacji o kontrolerze. W klasycznej wersji wzorca MVC [3] mamy do czynienia

z pasywnym modelem, który nie posiada informacji o innych częściach aplikacji.

Informacje z modelu uzyskiwane są w wyniku rezultatu wywołań jego funkcji. O ile

w uzasadnionych przypadkach może zachodzić komunikacja od modelu do kontrolera,

o tyle nigdy nie może model bezpośrednio komunikować się z widokiem, ani widok

z modelem.

Efektem logicznego podziału aplikacji na trzy elementy są realne korzyści. Każda

z części realizuje paradygmat abstrakcji i hermetyzacji, a co za tym idzie, umożliwia

tworzenie słabych powiązań i ułatwia modyfikację i testowanie. Architektura umożliwia

także skalowalność poprzez fizyczne oddzielenie poszczególnych części. Przykładowo

można umieścić model na innej maszynie fizycznej lub na wielu maszynach fizycznych.

2.1.2. XML

XML (ang. Extensible Markup Language - rozszerzalny język znaczników) jest

językiem znaczników przeznaczonym do opisu dowolnego typu informacji. Został

opracowany w 1996 roku pod przewodnictwem Jona Bosaka [4]. Grupa pracująca nad

specyfikacją języka XML wyznaczyła sobie między innymi następujące cele:

programy używające dokumenty XML powinny być łatwe do napisania;

dokumenty XML powinny być czytelne dla użytkownika;

dokumenty XML powinny być łatwe w tworzeniu.

Jako metajęzyk2 umożliwia tworzenie nowych języków opisu. Definiuje reguły, według

których należy opisywać informację zawartą w dokumencie, ale sam nie proponuje,

żadnego, konkretnego języka opisu. Głównym mechanizmem języka XML są etykiety

(ang. tag) między którymi jest umieszczana przekazywana informacja. Etykiety

występują parami: etykieta otwierająca - poprzedza opisywaną informację, a etykieta

2 patrz [11] str. 8

1. <Producer> 2. <Name> SAS Enterprise Miner </Name> 3. <Version> 6.1 </Version> 4. </Producer>

Wydruk 2.1 Przykładowy fragment dokumentu XML generowany przez narzędzie SAS Enterprise Miner

6

zamykająca - następuje po tej informacji. Etykiety zawarte są w nawiasach trójkątnych -

w etykiecie zamykającej po nawiasie otwierającym następuje prawy ukośnik.

2.2. Metody

2.2.1. SEMMA

SEMMA jest akronimem używanym do opisu procesu eksploracji danych

opracowanym przez SAS Institute Inc. Pochodzi od angielskich słów Sample

(próbkowanie), Explore (eksploracja), Modify (modyfikacja), Model (modelowanie),

Assess (ocena). Choć w publikacjach uważa się SEMMA za metodę eksploracji danych,

SAS Institute definiuje ją raczej jako formę uporządkowania narzędzi analitycznych lub

część metody eksploracji danych [5]. SEMMA skupia się na zadaniu tworzenia i oceny

modelu, a nie na aspektach biznesowych (jak np. rozumienie procesów biznesowych

organizacji zlecającej przeprowadzenie takiego procesu).

SEMMA składa się z pięciu etapów [6]:

Próbkowanie - to etap, w którym importowane i wstępnie przygotowywane są

dane. Próba powinna być na tyle duża, aby zawierała wszystkie najważniejsze

cechy analizowanego zbioru i na tyle mała, aby mogła być sprawnie

analizowana. Ten etap zazwyczaj koczy się podziałem danych na zbiór uczący,

walidacyjny i testujący.

Eksploracja ma za zadanie przybliżyć analitykowi zależności, trendy i anomalie

występujące w danych przez co ma pomóc w lepszym ich zrozumieniu.

Przydatne są do tego szczególnie metody prezentacji graficznej i metody

statystyczne.

Modyfikacja, jako kolejna faza procesu SEMMA, umożliwia przygotowanie

danych do kolejnego etapu poprzez tworzenie, wybieranie i modyfikowanie

zmiennych. Zdecydowanie o sposobie radzenia sobie z brakami danych,

wartościami błędnymi, czy znaczących różnicach w zakresie wartości jest

niezbędne dla poprawnego działania niektórych modeli analitycznych i może

znacząco poprawić działanie pozostałych.

Modelowanie - to tworzenie modelu poprzez trenowanie przy użyciu

analitycznych narzędzi z zakresu statystyki i uczenia maszynowego. Do tego

7

procesu używane są takie techniki jak regresja logistyczna, drzewa decyzyjne,

sieci neuronowe i inne.

Ocena określa użyteczność i wiarygodność uzyskanych wyników. Na tym etapie

możliwe jest porównanie i wybranie skonstruowanych wcześniej modeli

i zastosowanie ich w konkretnym wdrożeniu systemowym.

SEMMA zakłada następowanie po sobie etapów w wymienionej kolejności. W celu

uzyskania zadowalających wyników, stosuje się iteracyjnie kilkakrotnie różne narzędzia

z jednego etapu, a inne etapy można pominąć. Rezultatem całego procesu powinien być

model lub ich grupa, przeznaczone do oceny nowych danych.

2.2.2. Drzewo decyzyjne

Drzewo decyzyjne jest zbiorem metod statystycznych służących do podejmowania

decyzji poprzez tworzenie acyklicznych grafów skierowanych,. W eksploracji danych

drzewa decyzyjne są popularnym narzędziem do określania prawdopodobieństwa

wystąpienia określonej wartości zmiennej celu. Do wyboru reguły podziału węzła

stosowane są różne algorytmy, a budowa drzewa może być poddana wielu parametrom.

Rysunek 2.1 Fragment drzewa decyzyjnego przewidującego zdolność kredytową klientów banku.

8

Zaletą drzew decyzyjnych jest czytelna interpretacja graficzna, prostota

w implementacji oraz wbudowane mechanizmy obsługi brakujących wartości

w zbiorach danych.

2.3. Narzędzia

2.3.1. SAS Enterprise Miner

SAS Enterprise Miner (EM) jest programem wchodzącym w skład systemu SAS

dostarczającego narzędzia z zakresu BI (ang. Business Intelligence - analityka

biznesowa), zarządzania danymi i metod analitycznych. EM wykonuje zadania

z zakresu eksploracji danych. Intuicyjny graficzny interfejs umożliwia sprawne

tworzenie modeli eksploracji danych w oparciu o metodę SEMMA. Proces tworzenia

modelu jest przedstawiany za pomocą grafu skierowanego, na którym kierunek

krawędzi obrazuje kierunek przepływu danych, a wierzchołki (nazywane dalej węzłami)

różne metody ich modyfikacji. Bogaty zestaw węzłów stwarza możliwość

rozwiązywania zadań ze wszystkich dziedzin eksploracji danych, a rozbudowany

zestaw atrybutów ułatwia precyzyjne stosowanie wybranych metod.

Rysunek 2.2 Przykładowy ekran aplikacji SAS Enterprise Miner 12.1

Aplikacja posiada także moduł reprezentacji graficznej wyników analiz. Modele

wytworzone w niej można włączyć w procesy tworzenia oprogramowania typu

CRM/ERP (ERP - ang. Enterprise Resource Planning - planowanie zasobów

9

przedsiębiorstwa) poprzez załadowanie ich do centralnego repozytorium danych

i dalsze wykorzystywanie w takich programach jak SAS Enterprise Guide, SAS Data

Integration Studio, czy SAS Model Manager. Po utworzeniu modeli dostępna jest opcja

wygenerowania kodu scoringowego w języku programowania SAS, C++ oraz Java.

2.3.2. Eclipse IDE

Eclipse jest platformą stworzoną w 2004 roku do tworzenia aplikacji typu gruby klient

(ang. rich client) napisaną w Javie. Na jej bazie powstało zintegrowane środowisko

programistyczne (IDE - Integrated Development Environment) do programowania

w Javie. Obecnie rozwijane jest przez Fundację Eclipse i udostępnione jest na zasadach

otwartego oprogramowania (ang. open source).

Platforma Eclipse została zaprojektowana i zbudowana w celu spełnienia następujących

wymagań [7]:

wspieranie budowania narzędzi do programowania;

nieograniczone wspieranie twórców oprogramowania;

wspieranie narzędzi obsługujących różne typy zawartości (np. HTML, Java, C,

XML, GIF);

ułatwienie integracji narzędzi różnych dostawców;

wspieranie środowiska z GUI (ang. Graphical User Interface - interfejs

graficzny) i bez niego;

działanie na szerokim zakresie systemów operacyjnych;

wykorzystanie popularności języka Java do pisania narzędzi.

Platforma Eclipse składa się z niewielkiego jądra (które z punktu widzenia architektury

nazywane jest Platformą Uruchomieniową - ang. Platform Runtime) i dwóch wtyczek

(ang. plug-ins), które tworzą podstawę Architektury Wtyczek (ang. Plug-in

Architecture). Na tej podstawie można budować środowiska IDE, narzędzia i aplikacje

z różnych dziedzin. Odbywa się to poprzez programowanie odpowiednich wtyczek, dla

których Platforma Eclipse jest punktem integracyjnym.

Najbardziej znanymi projektami opartymi o tą platformę są środowiska IDE.

Oprogramowanie zostało napisane dla znacznej większości języków programowania

(np. Java, PHP, C, C++, Perl). Dzięki zastosowanej Architekturze Wtyczek i licznym

10

wydanym wtyczkom3, można dowolnie konfigurować środowisko dostosowując je do

programowania w wielu językach i zarządzaniu różnymi procesami związanymi

z produkcją oprogramowania (jak np. tworzenie dokumentacji UML czy testowanie).

Rysunek 2.3 Przykładowy ekran z Eclipse Standard 4.4

W niniejszej pracy zostało użyte środowisko w wersji Eclipse Standard 4.4 (Luna

Release) dostosowane dla programistów Java. Wraz z tym środowiskiem używano

dodatkowo instalowanych wtyczek, które zostaną opisane w kolejnych podrozdziałach.

2.3.3. Eclipse WindowBuilder

Eclipse WindowBuilder jest oprogramowaniem służącym do tworzenia elementów GUI

w języku Java. Obsługuje bibliotekę SWT oraz Swing. Został wydany jako wtyczka do

Eclipse i rozwiązań bazujących na Eclipse [8].

Posiada wbudowany edytor typu WYSIWYG (ang. What You See Is What You Get -

otrzymujesz to co widzisz), pozwalający znacząco przyśpieszyć tworzenie GUI poprzez

automatyczną generację kodu z projektów tworzonych graficznie. Metoda przeciągnij

i upuść (ang. drag and drop) oraz listy dostępnych atrybutów elementów graficznych

umożliwiają intuicyjne i sprawne tworzenie skomplikowanych widoków. Niewątpliwą

zaletą aplikacji jest dynamiczne tworzenie widoku projektowania z kodu Java - zmiany

3 ponad półtora tysiąca wtyczek w oficjalnym serwisie http://marketplace.eclipse.org/ i wiele na

indywidualnych stronach projektów

http://marketplace.eclipse.org/

11

wprowadzone w generowanym kodzie są widoczne w edytorze graficznym, a edytor

graficzny wprowadza zmiany w kodzie edytowanej klasy bez usuwania zmian

wprowadzonych bezpośrednio w kodzie. Nie są dzięki temu tworzone dodatkowe pliki

konfiguracyjne, do których programista nie ma dostępu.

Rysunek 2.4 Przykładowy widok okna projektowania Eclipse WindowBuilder

2.3.4. JUnit

JUnit jest narzędziem do tworzenia powtarzalnych testów oprogramowania pisanego

w języku Java. Został stworzony przez Ericha Gamma i Kenta Becka. Pozwala w prosty

sposób tworzyć i organizować automatyczne testy. Jego zaletą jest oddzielenie kodu

aplikacji od kodu testów.

JUnit jest narzędziem zbudowanym w architekturze xUnit, która definiuje standardy

tworzenia platform testujących oprogramowanie pisane w różnych językach.

Funkcjonalność i struktura narzędzi xUnit została zaczerpnięta z napisanej w 1998 r.

platformy testującej SUnit, napisanej dla języka Smaltalk.

W prezentowanej aplikacji JUnit został użyty jako wtyczka Elipse IDE.

2.3.5. Javadoc

Javadoc to generator dokumentacji oprogramowania napisanego w języku Java.

Stworzony przez firmę Sun Microsystems, generuje dokumenty w formacie HTML

z odpowiednio sformatowanych komentarzy umieszczonych w kodzie.

12

Javadoc pozwala generować dokumentację dla klas, interfejsów, pakietów oraz różnych

plików dołączanych do oprogramowania. Elementem charakterystycznym dla

komentarzy interpretowanych przez to narzędzie są dwie gwiazdki po ukośniku

otwierającym komentarz blokowy języka Java. Javadoc umożliwia także dodawanie

specjalnych znaczników dokumentacyjnych rozpoczynających się od symbolu małpy

umożliwiających tworzenie odniesień w generowanej dokumentacji. Używanie

narzędzia Javadoc jest standardem w tworzeniu dokumentacji kodu Java i definiowaniu

interfejsu aplikacji i klas.

13

3. Projekt i implementacja

3.1. Model eksploracji danych

Każda aplikacja scoringowa, aby mogła poprawnie działać, potrzebuje modelu według

którego będzie dokonywany scoring. W dalszej części rozdziału przedstawiłem model

do oceny kredytowej klientów banku. Kolejno opisałem zbiór danych, który

odpowiednio zmodyfikowany służy do trenowania drzewa decyzyjnego. Proces

tworzenia modelu zakończyłem na przedstawieniu wyników osiągniętych przez drzewo

decyzyjne i sposobie zintegrowania go z aplikacją oceny kredytowej.

Do implementacji modelu eksploracji danych użyłem SAS Enterprise Miner 12.1

(wersja Workstation), który opisałem w rozdziale „2.3.1 SAS Enterprise Miner”.

Rysunek 3.1 Etapy budowy modelu przedstawione w programie SAS Enterprise Miner

3.1.1. Zbiór danych trenujących

Pierwszym etapem budowy modelu scoringowego jest określenie zbioru danych, który

posłuży do trenowania modelu. Do tego celu wybrałem zbiór „German Credit Data”

zwierający dane historyczne udzielonych 1000 pożyczek. Zbiór pochodzi z Niemiec

i zawiera 20 zmiennych charakteryzujących pożyczkobiorcę oraz jedną zmienną celu,

w której zawarta jest informacja o tym, czy pożyczka została spłacona, czy też nie. 700

rekordów jest oznaczonych jako pożyczka spłacona. Poniżej przeprowadzam wstępną

analizę danych ze zbioru, podejmując decyzję o odrzuceniu pewnych zmiennych.

W nawiasach zamieszczam oryginalne nazwy kolumn z bazy danych.

Wiek (AGE)

Zmienna określa wiek w latach. Wartości zmiennej zawierają się miedzy 19, a 75.

Średnia wartość to ok. 36 lat.

14

Rysunek 3.2 Wykres rozkładu zmiennej „Wiek"

Kwota kredytu (AMOUNT)

Zmienna określa kwotę, na jaką był zaciągnięty kredyt. Zbiór danych dotyczy klientów

niemieckiego banku sprzed roku 2002 (data zmiany waluty w Niemczech na euro), więc

podawana jest w markach niemieckich. Kwoty wahają się od 250 do 18424 DM,

a średnia kwota to 3271 DM. Warto zauważyć, że kwoty kredytów są niemalże unikalne

- najliczniejsza grupa jednakowych kwot ma 3 obserwacje.

Rysunek 3.3 Wykres rozkładu zmiennej „Kwota kredytu"; zakreskowana część słupka wyznacza pozytywne

obserwacje

15

Stan otwartych rachunków (CHECKING)

Zmienna określa ilość środków na otwartych rachunkach. Wartości zmiennej

przyporządkowują obserwację do jednego z wcześniej określonych przedziałów:

1 - poniżej 0DM;

2 - 0-200DM;

3 - powyżej 200DM;

4 - brak konta.

Rysunek 3.4 Wykres rozkładu zmiennej „Stan otwartych rachunków"

Wspólnik (COAPP)

Zmienna zawiera informację o tym, czy klient bierze pożyczkę wspólnie z inna osobą,

lub czy posiada żyranta. Dopuszczalne wartości:

1 - brak wspólnika;

2 - kredyt zaciągany z inną osobą;

3 - inna osoba poświadcza za kredytobiorcę.

Większość obserwacji (907 na 1000) przybiera wartość „1” - brak wspólnika.

16

Rysunek 3.5 Wykres rozkładu zmiennej „Wspólnik"

Liczba osób na utrzymaniu (DEPENDS)

Zmienna określa liczbę osób na utrzymaniu. W przedstawianym zbiorze obserwacje

przyjmują tylko dwie wartości: 1 i 2. Dominują pożyczki udzielane osobom, które same

się utrzymują - średnia wartość zmiennej to 1,155.

Rysunek 3.6 Wykres rozkładu zmiennej „Liczba osób na utrzymaniu"

Czas spłaty (DURATION)

Zmienna określa termin, w jakim ma zostać spłacona pożyczka. Wartości podane są

w miesiącach. Najkrótsza pożyczka została udzielona na czas 4 miesięcy; najdłuższa na

72 miesiące (6 lat). Średni okres trwania pożyczki to ok. 21 miesięcy. Wykres rozkładu

pokazuje, że największa liczba pożyczek została udzielona na okres roku (179

17

obserwacji) i dwóch lat (184 obserwacje). Znacząco wyższe od pozostałych są także

pożyczki udzielana na wielokrotność okresu trzech miesięcy.

Rysunek 3.7 Wykres rozkładu zmiennej „Czas spłaty"

Czas zatrudnienia (EMPLOYED)

Zmienna „czas zatrudnienia” wyznacza okres w jakim klient nieprzerwanie pracuje od

momentu objęcia pracy w jednej firmie do chwili obecnej. Wartości te nie definiują

całego okresu zatrudnienia w przypadku zmiany pracy. Zmienna przyjmuje jedną

z wcześniej ustalonych wartości:

1 - klient obecnie jest bezrobotny;

2 - klient pracuje jeden rok;

3 - klient pracuje 1-4 lata;

4 - klient pracuje 4-7 lat;

5 - klient pracuje powyżej 7 lat.

18

Rysunek 3.8 Wykres rozkładu zmiennej „Czas zatrudnienia"

Liczba otwartych kredytów (EXISTCR)

Zmienna zawiera informację o liczbie otwartych kredytów w banku udzielającym.

Zmienna zawiera wartości z przedziału 1-4 (zbiór dotyczy tylko klientów, wobec

których decyzja kredytowa była pozytywna - nie ma więc możliwości, aby liczba

kredytów w przypadku danego klienta przyjęła wartość 0). Średnia wartość zmiennej to

1,407.

Rysunek 3.9 Wykres rozkładu zmiennej „Liczba otwartych kredytów"

19

Zagraniczne zatrudnienie (FOREIGN)

Jest to zmienna, której znaczenie nie jest do końca pewne. Opis dostarczony z bazą

danych brzmi - „foreign worker” - „pracownik zagraniczny”. Oznacza to

najprawdopodobniej to, że klient jest zatrudniony za granicą. Rozkład zmiennej przy

takiej interpretacji jest jednak zaskakujący - 963 osoby posiadają pozytywną wartość tej

zmiennej, w tym 62 osoby bezrobotne (według zmiennej „Czas zatrudnienia”). Ze

względu na brak jednoznacznej i wiarygodnej interpretacji, zdecydowałem nie

uwzględnić jej na dalszych etapach tworzenia modelu.

Historia kredytowa (HISTORY)

Zmienna klasyfikuje klienta do jednej z wcześniej ustalonych grup oceny historii

kredytowej. Oto one, wraz z przypisaną im liczbą porządkową w analizowanym

zbiorze:

0 - brak zaciągniętych kredytów lub wszystkie spłacone należycie;

1 - wszystkie kredyty w tym banku spłacone należycie;

2 - kredyty spłacane należycie do teraz;

3 - opóźnienia w płatnościach rat kredytów w przeszłości;

4 - krytyczny stan spłat lub istniejące kredyty w innych bankach.

Rysunek 3.10 Wykres rozkładu zmiennej „Historia kredytowa"

20

Mieszkanie (HOUSING)

Zmienna określająca rodzaj mieszkania, w którym mieszka pożyczkobiorca. Przyjmuje

jedną z następujących wartości:

0 - wynajmowane;

1 - własne;

2 - darmowe.

Rysunek 3.11 Wykres rozkładu zmiennej „Mieszkanie"

Stosunek dochodu do raty (INSTALLP)

Powyższa zmienna przedstawia, jaki procent dochodu klienta jest równy określonej

racie. Wartość jest liczona od dochodu netto. Przyjmuje wartości całkowitoliczbowe

z przedziału 1-4. Ta cecha wskazuje na duże prawdopodobieństwo pogrupowania

wartości, ale ze względu na brak opisu w dokumentacji dołączonej do zbioru danych

eliminuję zmienną z dalszej analizy.

Praca (JOB)

Zmienna określa rodzaj wykonywanej pracy. Może przyjąć jedną z określonych

wartości:

1 - niezatrudniony lub niewykwalifikowany - zamiejscowy;

2 - niewykwalifikowany - miejscowy;

21

3 - wykwalifikowany lub urzędnik;

4 - dyrektor, samozatrudniony, wysoko wykwalifikowany lub oficer.

Rysunek 3.12 Wykres rozkładu zmiennej „Praca"

Stan cywilny (MARITAL)

Zmienna określa stan cywilny klienta. Przyjmuje jedną ze zdefiniowanych wartości:

1 - mężczyzna - rozwiedziony lub w separacji;

2 - kobieta - rozwiedziona, w separacji lub żonata;

3 - kawaler;

4 - mężczyzna - żonaty lub wdowiec;

5 - panna.

22

Rysunek 3.13 Wykres rozkładu zmiennej „Stan cywilny"

Inne plany ratalne (OTHER)

Zmienna zawiera informację o innych planach ratalnych podjętych przez klienta. Jej

wartości określają gdzie zostało podjęte zobowiązanie:

1 - bank;

2 - sklep;

3 - brak innych planów ratalnych.

Rysunek 3.14 Wykres rozkładu zmiennej „Inne plany ratalne"

23

Majątek (PROPERTY)

Zmienna określa rodzaj majątku zabezpieczającego kredyt. Zmienna przyjmuje

określone wartości:

1 - nieruchomość;

2 - oszczędności w kasie mieszkaniowej lub ubezpieczenie na życie;

3 - samochód lub inny majątek;

4 - brak majątku lub brak informacji.

Rysunek 3.15 Wykres rozkładu zmiennej „Majątek"

Przeznaczenie (PURPOSE)

Zmienna określa, z jakiego powodu jest brany kredyt. Przyjmuje jedną z określonych

wartości definiujących na co zostaną przeznaczone środki z kredytu:

0 - nowy samochód;

1 - używany samochód;

2 - meble lub inne wyposażenie domu;

3 - radio lub telewizor;

4 - artykuły gospodarstwa domowego;

5 - przeprowadzenie pewnych napraw;

6 - edukacja;

24

7 - sfinansowanie wakacji;

8 - przeprowadzenie szkolenia;

9 - cel biznesowy;

X - inny cel.

Jako jedyna zmienna wejściowa jest typu znakowego. Pozostałe są typu numerycznego.

Rysunek 3.16 Wykres rozkładu zmiennej „Przeznaczenie"

Czas zamieszkania (RESIDENT)

Zmienna zawiera informację o okresie zamieszkania. Ze względu na niepełną

dokumentację rodzajów grup wartości oraz niewielki wpływ na skuteczność modelu

zmienna nie zostanie uwzględniona w dalszych etapach budowania modelu.

Oszczędności (SAVINGS)

Zmienna określa jaką kwotę oszczędności klient posiada na rachunku

oszczędnościowym lub w obligacjach. Zmienna przyjmuje jedną z określonych

wartości:

1 - do 100DM;

2 - 100-500DM;

3 - 500-1000DM;

4 - powyżej 1000DM;

5 - nieznana kwota oszczędności lub brak rachunku oszczędnościowego.

25

Rysunek 3.17 Wykres rozkładu zmiennej „Oszczędności"

Telefon (TELEPHON)

Zmienna binarna określająca, czy klient posiada zarejestrowany na siebie numer

telefonu. Przyjmuje wartości:

1 - brak numeru telefonu;

2 - telefon zarejestrowany na nazwisko klienta.

Rysunek 3.18 Wykres rozkładu zmiennej „Telefon"

26

3.1.2. Partycjonowanie danych

Podział danych na odpowiednie podzbiory jest kolejnym etapem przygotowania

danych. W eksploracji danych stosuje się podział na trzy partycje: dane uczące,

walidacyjne i testujące. Zbiór uczący jest wykorzystywany do trenowania modelu -

w wypadku tego projektu do zbudowania drzewa decyzyjnego. Zgodnie z zależnościami

zawartymi w tym zbiorze podejmowane są decyzje o wyborze reguły podziału

kolejnych węzłów drzewa. Zbiór walidacyjny służy do przeprowadzenia oceny modelu.

W niektórych przypadkach dane walidacyjne są wykorzystywane do dopracowania

modelu - w drzewie decyzyjnym algorytm stwarza najlepsze poddrzewo. Celem

tworzenia danych testujących jest ostateczna ocena i porównanie wytrenowanych

modeli.

Zastosowałem podział na zbiór uczący i walidacyjny w proporcji 7 do 3. Pominąłem

zbiór danych testujących ze względu na posiadaną niewielką próbkę danych

wejściowych i niewielkie zastosowanie w projekcie danych testujących. Dzięki temu

uzyskałem duży zbiór danych uczących, który lepiej posłużył do trenowania modelu.

Dane zostały podzielone przy pomocy algorytmu partycjonowania warstwowego.

Algorytm dzieli dane wejściowe na warstwy ze względu na zmienną celu - według

pożyczek spłaconych i niespłaconych. Dane wewnątrz każdej warstwy mają równe

prawdopodobieństwo trafienia do każdego ze zbiorów danych. Algorytm zapewnia

odwzorowanie proporcji warstw w podzielonych zbiorach, co może zwiększyć trafność

modelu. Wynik działania algorytmu został przedstawiony w tabeli poniżej.

Zbiór Wartość zmiennej

celu

Liczba wystąpień Procent danego

zbioru

Dane wejściowe

zła 300 30

dobra 700 70

Dane testujące

zła 209 29,8999

dobra 490 70,1001

Dane walidacyjne

zła 91 30,2326

dobra 210 69,7674

Tabela 3.1 Podział danych wejściowych na zbiory według algorytmu podziału warstwowego

27

3.1.3. Drzewo decyzyjne

Tak przygotowane dane użyłem do zbudowania drzewa decyzyjnego. W drzewie

zastosowałem domyślne algorytmy podziału węzła. Wykorzystałem drzewo binarne,

o maksymalnej głębokości ograniczonej do sześciu poziomów. Algorytm wybrał cztery

zmienne, według których dokonywał podziałów: Stan otwartych rachunków

(CHECKING), Czas spłaty (DURATION), Oszczędności (SAVINGS), oraz Historia

kredytowa (HISTORY). Poniżej zaprezentowałem wykres wytrenowanego drzewa.

Rysunek 3.19 Drzewo decyzyjne od poziomu 0 do poziomu 2

28

Rysunek 3.20 Drzewo decyzyjne od poziomu 2 do poziomu 4 (prawe odgałęzienie)

Rysunek 3.21 Drzewo decyzyjne od poziomu 2 do poziomu 3 (lewe odgałęzienie)

3.1.4. Ocena modelu

Ostatnim etapem tworzenia modelu jest jego ocena i wygenerowanie odpowiedniego

kodu do integracji z aplikacją. Częstą metodą oceny modelu jest przedstawienie

wykresu przyrostu skumulowanego (ang. cumulative lift). Pokazuje on ile razy częściej

względem losowej próby w wybranym podzbiorze wystąpią pozytywne przypadki (w

29

wypadku oceny kredytowej - ile razy więcej klientów spłaci kredyt). Przyrost

skumulowany na poziomie 1 odpowiada losowemu wybieraniu przypadków z danego

zbioru danych. W prezentowanym przypadku lift na poziomie 10/7 (ok. 1,43) daje

pewność, że dane obserwacje będą pozytywne (70% pozytywnych obserwacji w zbiorze

wyjściowym pomnożone przez 10/7 daje 100%). Trenowane drzewo decyzyjne

osiągnęło przyrost dla pierwszego decyla danych walidacyjnych równy ok. 1,27.

Oznacza to, że ze zbioru 10% klientów wytypowanych przez model kredyt spłaci ok.

89%.

Rysunek 3.22 Wykres przyrostu skumulowanego dla danych trenujących i walidacyjnych

Ważnym wskaźnikiem użyteczności modelu jest także przebieg krzywej. W pierwszych

decylach krzywa powinna być relatywnie wysoko i gładko maleć wraz ze wzrostem

liczby uwzględnionych obserwacji. Wszelkie załamania krzywej przejawiające się np.

wzrostem przyrostu w środkowych decylach wskazują na nieużyteczność modelu4.

Krzywa dla przedstawionego modelu ma przebieg zgodny z oczekiwaniami i posiada

wysokie wartości dla pierwszej połowy zbioru, stopniowo malejąc dla pozostałych

obserwacji.

Po ocenie modelu i stwierdzeniu jego użyteczności pozostaje zapisanie go w formacie

odpowiednim do dalszego wykorzystania. SAS Enterprise Miner posiada możliwość

umieszczenia modelu w pakiecie i zarejestrowanie go na serwerze metadanych. Dzięki

takiemu rozwiązaniu możliwe jest przetwarzanie go innymi narzędziami środowiska

SAS i włączenie go w proces produkcyjny systemu typu CRM/ERP. Ja skorzystałem

z innej możliwości - wygenerowałem zbiór plików do skompilowania z programem

napisanym w języku Java. Pliki generowane przez SAS Enterprise Miner to:

4 [14] str. 28

30

JScore.xml - plik zawierający metadane funkcji scoringowej, takie jak dane

wejściowe i zwracane przez funkcję;

JscoreUserFormats.java - plik zawierający formaty zdefiniowane przez

użytkownika. Klasa JscoreUserFormats zawarta w pliku zawiera istotne

informacje w przypadku stosowania własnych algorytmów w procesie

budowania modelu;

metadata.xml - plik zawierający metadane plików - nazwy i typy wszystkich

generowanych plików;

Score.java - plik zawierającą klasę z interfejsem do klasy DS.class;

DS.class - plik zawierający skompilowaną klasę implementującą kod

scoringowy.

Pliki te zostały włączone w projekt i implementację aplikacji do oceny kredytowej

klientów banku, którą opisałem w pracy.

3.2. Analiza wymagań aplikacji

Początkiem pracy nad aplikacją jest zdefiniowanie zadań, jakie ma spełniać. Wyraża się

to przez zdefiniowanie wymagań funkcjonalnych i niefunkcjonalnych.

3.2.1. Wymagania funkcjonalne

Wymagania funkcjonalne opisują funkcje wykonywane przez projektowane

oprogramowanie. Poniżej znajdują się wymagania, które powinna realizować aplikacja

oceny kredytowej klientów banku.

1. Program powinien umożliwiać wykonanie oceny kredytowej klienta.

1.1. Program powinien zawierać interfejs pozwalający wprowadzić wybrane dane

klienta.

1.2. Program powinien określić prawdopodobieństwo zwrotu kredytu na podstawie

wprowadzonych danych.

2. Program powinien mieć możliwość konfiguracji poziomów ryzyka kredytowego.

2.1. Program powinien mieć możliwość zdefiniowania trzech grup ryzyka: wysokie

ryzyko, średnie ryzyko, niskie ryzyko.

3. Program powinien informować o błędach konfiguracji i wprowadzonych danych.

31

3.2.2. Wymagania niefunkcjonalne

Wymagania niefunkcjonalne określają jakość i granice wykonywania funkcji

określonych w wymaganiach funkcjonalnych.

1. Program powinien mieć możliwość wymiany modelu scoringowego bez potrzeby

wprowadzania znaczących zmian w kodzie programu.

2. Program powinien być skalowalny - posiadać pakiety możliwe do wykorzystania

w wypadku integracji z systemem CRM.

3. Program powinien posiadać intuicyjny interfejs w języku polskim.

4. Program powinien mieć możliwość uruchamiania na komputerach klasy PC

posiadających systemy operacyjne rodziny Windows, UNIX i Linux.

3.3. Projekt aplikacji

Projekt aplikacji opisałem przy użyciu języka UML. Przy wyborze tego narzędzia

kierowałem się jego powszechnym użyciem i tym, że zawiera bogaty i intuicyjny

zestaw narzędzi do opisu projektu.

Przedstawione diagramy zawierają finalny opis aplikacji - pominąłem etapy, na których

były dokonywane zmiany, gdyż nie są one istotne z punktu widzenia tej analizy.

3.3.1. Przypadki użycia

Diagramy przypadków użycia dokumentują wymagania dotyczące systemu z pozycji

użytkownika. Przedstawiają możliwe wykorzystanie programu. Niniejsza dokumentacja

zawiera dwa przypadki użycia uwzględniające odpowiednio wymagania funkcjonalne

numer 1 i 2. Wymaganie funkcjonalne numer 3, dotyczące informowania o błędach, nie

jest opisywane jako samodzielny przypadek użycia, ale zostało włączone w pozostałe.

Wykonanie oceny kredytowej

Ocena zdolności kredytowej wykonywana jest przez analityka kredytowego

w odpowiedzi na prośbę o przyznanie kredytu. Kredytobiorca zobowiązany jest

dostarczyć komplet danych przedstawionych za pośrednictwem analityka kredytowego

za pomocą programu.

32

Rysunek 3.23 Diagram przypadku użycia „Wykonanie oceny kredytowej"

Scenariusz główny:

1. Analityk kredytowy pobiera zestaw wymaganych danych przedstawionych przez

program od klienta.

2. Analityk kredytowy wprowadza dane otrzymane od klienta do programu.

3. Program dokonuje oceny kredytowej.

4. Program wyświetla prawdopodobieństwo zwrotu kredytu oraz grupę ryzyka do

której został zaliczony klient.

Scenariusz alternatywny - niekompletne dane:

1. Jak w scenariuszu głównym.

2. Analityk kredytowy wprowadza niekompletne dane do programu.

3. Program dokonuje oceny kredytowej jeśli jest to możliwe.

4. Program wyświetla wynik oceny kredytowej lub komunikat błędu.

Określenie przedziałów ryzyka kredytowego

Określanie przedziałów ryzyka kredytowego jest wykonywane przez analityka grup

ryzyka i umożliwia określenie, do jakiej grupy ryzyka kredytowego należy zaliczyć

danego klienta. W skład grup ryzyka kredytowego wchodzą: wysokie ryzyko, średnie

ryzyko, niskie ryzyko. Definiowanie grup ryzyka odbywa się poprzez określenie

wartości granicznych prawdopodobieństwa spłaty kredytu.

Rysunek 3.24 Diagram przypadku użycia „Określenie przedziałów ryzyka kredytowego"

Scenariusz główny:

1. Analityk grup ryzyka kredytowego wprowadza wartości graniczne

prawdopodobieństwa dla grup ryzyka kredytowego w pliku konfiguracyjnym.

33

2. Program, po ponownym uruchomieniu, dokonuje oceny kredytowej

z wprowadzonymi parametrami.

W przypadku wprowadzenia nieprawidłowych wartości, program po uruchomieniu

wyświetla odpowiedni komunikat błędu.

3.3.2. Diagram komponentów

Diagram komponentów przedstawia architekturę aplikacji na poziomie elementów,

które mogą być wymieniane niezależnie od siebie. Tak długo, jak interfejsy pozostają

niezmienione, zostaje zachowana funkcjonalność aplikacji.

Aplikacja składa się z trzech komponentów: widok, kontroler i model. Ich zadania

zostały opisane w rozdziale poświęconym architekturze MVC.

Rysunek 3.25 Diagram komponentów aplikacji

Kontroler i widok komunikują się ze sobą przy pomocy interfejsów o takich samych

nazwach. Kontroler komunikuje się z widokiem w celu przekazania mu niezbędnych

danych do wyświetlenia (metody „setPolaFormularza()” oraz „pokaz()”), w celu

przekazania komunikatu błędu (metody „wyswietlOstrzezenie()”

34

i „wyswietlBladKrytyczny()”) oraz w celu przekazania wyniku scoringu

(„wyswietlWynikScoringu()”). Widok komunikuje się z kontrolerem w odpowiedzi na

żądanie wykonania scoringu wygenerowane przez użytkownika. Użyta architektura

MVC z biernym modelem zakłada, że model nie komunikuje się z innymi częściami

systemu samoczynnie, lecz zwraca wartości wywołanych funkcji. Jego metody służą do

zdefiniowania zestawu pól wprowadzania danych („getMozliweArgumentyScoringu()”)

i wyliczenia scoringu („wyliczPrawdopodobienstwo()”).

3.3.3. Diagramy klas

Diagramy klas opisują strukturę klas i ich wzajemne powiązania. W przedstawianym

projekcie pokażę projekt budowy każdego z komponentów oraz klasy za pomocą

których realizowany jest przepływ danych między komponentami.

Kontroler

Komponent kontrolera pośredniczy między widokiem a modelem. Jego funkcją jest

również zainicjowanie całej aplikacji (metoda „start()”). Realizacja przypadku użycia

„Określenie przedziałów ryzyka kredytowego” wymaga użycia pliku konfiguracyjnego,

którego umiejscowienie w systemie określa pole prywatne głównej klasy kontrolera.

Rysunek 3.26 Diagram klas komponentu „kontroler”

Model

Model, zawierający logikę aplikacji, ma do spełnienia kilka zadań. Jak już

wspomniałem w rozdziale „3.1 Model eksploracji danych”, funkcja scoringowa jest

35

opisana plikiem metadanych zapisanym w formacie XML. W celu poznania zmiennych

wejściowych do tej funkcji należy odczytać je z tego pliku. Dodatkowo nazwy

zmiennych należy zamienić na takie, które będą czytelne i zrozumiałe dla użytkownika

- w tym celu do modelu dołączyłem słownik wszystkich danych wejściowych dla zbioru

danych opisanych w rozdziale „3.1.1 Zbiór danych trenujących”. Wreszcie model

odpowiedzialnych jest za scoring wprowadzonych danych. Wykonuje to poprzez

odwołanie się do wygenerowanej wcześniej klasy implementującej stworzony model.

Rysunek 3.27 Diagram klas dla komponentu „model"

Na przedstawionym diagramie klasa „ModelDoSkompilowanegoModelu” jest główną

klasą komponentu implementującą jego interfejs. Klasa „ParserJScoreXML” odczytuje

plik metadanych, a klasa „ParserSlownikaBazyDanych” przypisuje zmiennym

wejściowym funkcji scoringowej nazwy i opisy czytelne dla użytkownika.

36

Rysunek 3.28 Diagram klas dla komponentu „widok"

Widok

Widok spełnia dwa główne zadania. Umożliwia użytkownikowi wprowadzanie danych

oraz wyświetla wynik oceny kredytowej. Dodatkowo zapewnia wyświetlanie błędów -

tych które uniemożliwiają dalsze działanie aplikacji oraz tych, które informują

o niepoprawnym wprowadzeniu danych.

37

Klasa „OknoAplikacji” jest główną klasą tego komponentu implementującą jego

interfejs. Klasy „PanelWyswietlaniaWynikow” i „PanelWprowadzaniaDanych”

odpowiadają odpowiednio za wyświetlanie wyników i wprowadzanie danych. Są one

zaprojektowane specjalnie do wyświetlania w klasie „OknoAplikacji” i nie mogą istnieć

w oderwaniu od tej klasy. Klasa „WykresSlupkowy” zapewnia możliwość graficznego

przedstawienia wyniku oceny kredytowej. Klasa „OdczytywanieDanychFormularza”

jest implementacją klasy obsługi zdarzeń typowej dla użytej biblioteki SWING.

Dane

W projekcie zastosowałem dwie klasy do realizacji przepływu danych. Jedna

przekazuje informację o ocenie kredytowej z modelu do widoku („WynikScoringu”).

Rysunek 3.29 Diagram klas dla wyniku scoringu

Druga przechowuje dane dotyczące zmiennej wejściowej funkcji scoringowej

(„ArgumentFunkcjiScoringowej”). Klasa ta przechowuje takie informacje jak typ

zmiennej (realizowane przy pomocy dziedziczenia), jej wartość, nazwa, nazwa czytelna

dla użytkownika i opis. Zbiór obiektów tej klasy generowany jest w modelu i tam jest

uzupełniany o informacje opisowe. Następnie poprzez kontroler wędruje do widoku,

w którym uzupełniane są pola wartości argumentu. Na koniec zbiór jest przekazywany

z powrotem do modelu, gdzie jest używany do stworzenia oceny kredytowej.

38

Rysunek 3.30 Diagram klas dla argumentu funkcji scoringowej

3.3.4. Diagramy sekwencji

Diagramy sekwencji przedstawiają interakcje poszczególnych części systemu. Na

poniższych diagramach prezentuję sekwencje komunikatów dla przypadku użycia

„Wykonanie oceny kredytowej”.

Rysunek 3.31 ukazuje interakcje wewnątrz komponentu „widok”. Sekwencje wyzwala

aktor „Analityk kredytowy” wprowadzając dane do systemu. Zdarzenie rejestruje obiekt

klasy „PanelWprowadzaniaDanych” i zdarzenie przekazuje obiektowi

„OdczytywanieDanychFormularza”. Po pobraniu od obiektu „OknoAplikacji”

aktualnego wskazania na obiekt „PanelWprowadzaniaDanych”,

„OdczytywanieDanychFormularza” pobiera wskazania na pola wprowadzania danych.

Pobiera z nich wartości i tworzy z nich listę argumentów funkcji scoringowej.

Przekazuje ją obiektowi „OknoAplikacji”, który przesyła ją do komponentu

„Kontroler”. Obiekt „Kontroler” przesyła listę argumentów do modelu, gdzie dokonuje

się ocena kredytowa i wynik zwraca przez interfejs „Widok” do klasy „OknoAplikacji”

(rysunek Rysunek 3.32). „OknoAplikacji” wynik scoringu przekazuje do obiektu

„PanelWyswietlaniaWynikow”, który po narysowaniu wykresu słupkowego

przedstawia wynik aktorowi „Analityk kredytowy”.

39

Rysunek 3.31 Diagram sekwencji komponentu widok dla przypadku użycia „Wykonanie oceny kredytowej”

Rysunek 3.32 Diagram sekwencji komponentów dla przypadku użycia „Wykonanie oceny kredytowej”

40

3.4. Opis implementacji aplikacji

W niniejszym podrozdziale opisałem najważniejsze elementy implementacji aplikacji,

uzasadniając podjęcie konkretnych decyzji implementacyjnych. Całość implementacji

jest zgodna z projektem przedstawionym w poprzedniej części tego rozdziału oraz

uzupełniona o elementy niezbędne do prawidłowego i wydajnego funkcjonowania.

3.4.1. Architektura i klasy pomocnicze

Zgodnie z projektem architektura aplikacji jest zgodna z wzorcem MVC. Każdy

z komponentów, zgodnie z konwencją tworzenia oprogramowania w języku Java,

umieszczony jest w oddzielnym pakiecie. Oprócz pakietów „model”, „kontroler” oraz

„widok” na aplikację składa się pakiet „pomocnicze” i jedna klasa będąca w pakiecie

nadrzędnym.

Pakiety wzorca MVC zostaną omówione w kolejnych podrozdziałach. Pakiet

„pomocnicze” zawiera klasy używane w pozostałych pakietach - są to klasy do

realizacji przepływu danych między komponentami oraz pewnych operacji

pomocniczych do przekształcania danych. Wspomniane operacje nie są specyficzne dla

pojedynczego komponentu i dostęp do nich jest możliwy z każdego innego pakietu.

Takie rozwiązanie pozwala nie tworzyć silnych powiązań między poszczególnymi

pakietami wzorca.

Jedną z klas pakietu pomocnicze jest klasa „WynikScoringu”. Jest to prosta klasa

używana do przekazania wyniku oceny kredytowej z modelu do widoku. Zawiera dwa

pola: „prawdopodobieństwo” - określające prawdopodobieństwo spłaty kredytu

zawierające się w przedziale <0, 1> i „grupaRyzyka” będące typu wyliczeniowego

o nazwie „GrupaRyzyka”. Typ wyliczeniowy zaimplementowałem wewnątrz klasy

„WynikScoringu” ze względu na prostotę i czytelność kodu. „GrupaRyzyka” zawiera

trzy wartości zgodnie z przedstawionym projektem.

Pozostałymi klasami pakietu „pomocnicze” są: klasa abstrakcyjna

„ArgumentFunkcjiScoringowej”, a także dwie klasy pochodne od niej -

„ArgumentFunkcjiScoringowejNapis” i „ArgumentFunkcjiScoringowejNumeryczny”.

Klasy te przechowują dane dotyczące argumentów funkcji scoringowej i przemieszczają

się między komponentami w dwie strony - od modelu do widoku przenoszą informację

41

o nazwie i opisie argumentów i od widoku do modelu przenoszą informacje

o wartościach argumentów.

„ArgumentFunkcjiScoringowej” jest klasą abstrakcyjną, ponieważ każdy argument

funkcji scoringowej jest określonego typu i część logiki dla wszystkich argumentów jest

wspólna (co determinuje wybranie mechanizmu abstrakcji, a nie interfejsu). Wszystkie

argumenty zawierają opis i odpowiednią nazwę do wyświetlenia. Wszystkie zawierają

także nazwę zmiennej z bazy danych, która umożliwia funkcji scoringowej określić,

z którym obiektem mamy do czynienia. Różne są natomiast typy wartości argumentów.

Generowany kod modelów przyjmuje jeden z dwóch typów - numeryczny (typ

„double”) lub znakowy (typ „String”). Zastosowany mechanizm dziedziczenia pozwala

rozszerzyć dopuszczalne typy - wystarczy zaimplementować kolejną klasę

z odpowiednimi polami i metodami. Kod jest dzięki temu czytelniejszy, hermetyczny

i rozszerzalny.

Przykładem logiki stosowanej we wszystkich klasach argumentów funkcji scoringowej

jest kod odpowiedzialny za pobranie nazwy przez komponent widoku. Model ładuje do

argumentów odpowiednie nazwy do wyświetlenia, jednak może się zdarzyć, że dla

pewnego modelu nie będzie mógł zlokalizować słownika, lub słownik będzie niepełny.

Logiczne jest, że widok nie jest odpowiedzialny za znalezienie odpowiedniej nazwy

argumentu, ale klasa, która te argumenty opakowuje. Omawianą logikę implementuje,

metoda „getNazwaArgumentuDoWyswietlenia()”, która w razie braku załadowanej

nazwy poda identyfikator z bazy danych. Jest ona częścią klasy

„ArgumentFunkcjiScoringowej”.

Przykładem logiki abstrakcyjnej dla klasy „ArgumentFunkcjiScoringowej” jest podanie

wartości argumentu. Klasa abstrakcyjna wie, że jej implementacja musi posiadać

wartość, ale nie jest w stanie dostać się do pola, które tą wartość będzie przechowywało.

Dlatego wszystkie klasy pochodne muszą zaimplementować metodę „getWartosc()”.

Metoda abstrakcyjna „getWartosc()” zwraca obiekt typu „Object”, składając

odpowiedzialność na odpowiednie zrzutowanie wartości na logikę, które jej używa. Nie

jest to jednak istotne, bo metoda ta jest używana tylko do konwertowania obiektów

klasy „ArgumentFunkcjiScoringowej” na format danych przyjmowany przez funkcję

scoringową, która przyjmuje wskazania wartości typu „Object”.

42

„ArgumentFunkcjiScoringowej” zawiera również metody statyczne używane do

konwertowania zbiorników obiektów tej klasy. Wynika to z różnic między używanymi

kontenerami obiektów między komponentami i między modelem a funkcją scoringową.

Komponenty przekazują sobie informacje o argumentach za pomocą list z obiektami

typu „ArgumentFunkcjiScoringowej”. Jednak funkcja scoringowa oczekuje na wejściu

mapy, w której kluczem jest nazwa argumentu z bazy danych, a wartością jest

wskazanie typu „Object” na odpowiednią wartość argumentu (typ „double” lub

„String”). Umiejscowienie logiki konwersji w tej klasie ułatwia utrzymanie kodu

związanego z obsługą typów danych.

Poza pakietem „pomocnicze” oraz komponentami wzorca MVC w aplikacji znajduje się

jeszcze jedna klasa. Jest to „KlasaStartowa” zawierająca metodę statyczną „main()” od

której zaczyna się działanie programu. Jej zadaniem jest powołanie do życia

komponentów, podanie im odpowiednich wskazań do siebie i zasygnalizowanie

kontrolerowi, że może przeprowadzić odpowiednie czynności konfiguracyjne.

3.4.2. Kontroler

Kontroler jest częścią aplikacji, która odpowiada nie tylko za zarządzanie przepływem

danych między widokiem a modelem. Jako jedyny komponent posiadający wskazania

na pozostałe komponenty jest odpowiedzialny za zarządzanie pracą całej aplikacji. Do

jego zadań należy także odpowiednia inicjacja pozostałych komponentów.

Ze względu na niewielkie rozmiary kodu (mniej niż 200 linii łącznie z odstępami

i komentarzami) zdecydowałem się umieścić całą logikę komponentu w jednej klasie -

„KontrolerAplikacji”. W rezultacie w pakiecie „kontroler” znajduje się jeszcze tylko

jeden obiekt - interfejs „Kontroler”, który jest oczywiście implementowany przez

jedyną dostępną klasę.

Najciekawszą częścią klasy „KontrolerAplikacji” jest logika odpowiedzialna za

inicjowanie pozostałych komponentów. Składa się ona z trzech etapów:

1. ładowanie konfiguracji;

2. pobranie z modelu listy argumentów funkcji scoringowej;

3. zainicjowanie widoku.

43

Ładowanie konfiguracji

Konfiguracja aplikacji odbywa się przy pomocy pliku konfiguracyjnego. Powinien być

umieszczony w tym samym folderze co pliki wykonywalne programu i nosić nazwę

„plikKonfiguracyjny.txt”. W jego wnętrzu znajdują się rekordy w formacie „właściwość

= wartość” po jednym w linii. Poniżej znajduje się przykładowy wydruk pliku

konfiguracyjnego.

Parametry konfigurowane w tym pliku przedstawione są w tabeli poniżej.

Nazwa parametru Rodzaj Opis

JScoreXML napis Określa położenie pliku „JScore.xml”

wygenerowanego razem z modelem

scoringowym i zawierającym argumenty

funkcji scoringowej.

SlownikBazyDanych napis Określa położenie pliku słownika bazy danych.

Parametr opcjonalny.

OdciecieNiskiejGrupyRyzyka liczba Określa granicę wartości prawdopodobieństwa

między niską i średnią grupą ryzyka

kredytowego.

OdciecieSredniejGrupyRyzyka liczba Określa granicę wartości prawdopodobieństwa

między średnią i wysoką grupą ryzyka

kredytowego.

Tabela 3.2 Parametry pliku konfiguracyjnego aplikacji

Kontroler odczytuje rekordy pliku konfiguracyjnego sprawdzając ich poprawność.

W przypadku braku któregoś z koniecznych parametrów lub niemożności ich

odpowiedniej konwersji wyświetla za pomocą specjalnej funkcji widoku komunikat

błędu. Przy poprawnym odczytaniu wszystkich parametrów zapisuje je w odpowiednich

polach prywatnych klasy. Parametry „JScoreXML” i „SlownikBazyDanych” są

potrzebne przy pobraniu listy argumentów z modelu. Parametry odcięć podawane są

Wydruk 3.1 Przykładowa zawartość pliku konfiguracyjnego

1. JScoreXML = JScore.xml 2. ObciecieNiskiejGrupyRyzyka = 0.85 3. ObciecieSredniejGrupyRyzyka = 0.6 4. SlownikBazyDanych = slownikDMAGECR.txt

44

wraz z listą argumentów funkcji scoringowej do modelu w celu wygenerowania wyniku

scoringu.

Pobranie listy argumentów

Kolejnym etapem inicjowania aplikacji jest odwołanie się do modelu. Poprzez metodę

o nazwie „getMozliweArgumentyScoringu” przekazywane są do modelu dwa

parametry: „JScoreXML” i „SlownikBazyDanych”. Kontrakt tej metody zobowiązuje ją

do zwrotu listy argumentów funkcji scoringowej. Argument określający ścieżkę

położenia słownika jest opcjonalny - w przypadku błędnej ścieżki lub jej braku metoda

nie generuje wyjątku. Zwraca listę argumentów bez uzupełnionych informacji opisu

i bez specjalnej nazwy do wyświetlenia.

Argument „JScoreXML” jest podstawą do odczytania listy potrzebnych argumentów.

Ścieżka pliku musi być w nim poprawna, a plik musi mieć właściwą budowę.

W przypadku błędu metoda rzuca odpowiedni wyjątek. Z punktu widzenia kontrolera

nie jest istotne jaki to jest wyjątek - przechwytuje je wszystkie i wyświetla ogólny

komunikat o błędzie przetwarzania pliku argumentów funkcji scoringowej.

Zainicjowanie widoku

Po odczytaniu listy argumentów funkcji scoringowej można przystąpić do ostatniego

etapu inicjowania aplikacji. Jest nim uruchomienie widoku. Widok przekazany

w konstruktorze klasy nie jest w pełni gotowy - należy przekazać mu listę argumentów,

aby mógł odpowiednio wyświetlić formularz wprowadzania danych. Dodatkowo należy

wywołać metodę widoku - „pokaz()”, która sprawdza czy wszystkie wymagania

potrzebne do poprawnego wyświetlania zostały spełnione i rysuje okno aplikacji

w odpowiedni sposób. Metoda „pokaz()” może zwrócić wyjątek w przypadku braku

gotowości do wyświetlenia - kontroler wtedy przekazuje komunikat błędu

użytkownikowi i kończy działanie aplikacji.

Pozostała logika klasy

Realizacja kontroli przepływu danych między widokiem, a modelem jest w tym

projekcie trywialna. Nie występuje w aplikacji współbieżna komunikacja między

widokiem, a modelem, kontroler więc spełnia rolę prostego pośrednictwa z obsługą

wyjątków.

45

3.4.3. Model

Kolejnym komponentem aplikacji jest model. Zgodnie z przyjętym wzorcem

architektonicznym model jest pasywny, tzn. nie posiada referencji do pozostałych

komponentów aplikacji. Przez to komunikacja z pozostałą częścią programu zachodzi

tylko za pomocą zwracania wartości funkcji oraz poprzez rzucanie wyjątków.

Model spełnia dwie istotne zadania. Pierwszym z nich jest przygotowanie argumentów

funkcji scoringowej, drugim - wykonanie scoringu.

Argumenty funkcji scoringowej

Stworzenie listy argumentów funkcji scoringowej odbywa się dwuetapowo. Pierwszym

z nich jest pobranie informacji o tym, które argumenty przyjmuje funkcja scoringowa.

Ta informacja zawarta jest w pliku generowanym przez program SAS Enterprise Miner

razem z innymi plikami modelu. Plik domyślnie nazywa się „JScore.xml” i zawiera

informacje w formacie XML. Zawiera kilka sekcji z informacjami o:

wersji programu generującego kod modelu;

klasie, nazwie pakietu i deklaracji metody funkcji scoringowej;

argumentach funkcji scoringowej;

wyniku zwracanym przez funkcję scoringową.

Wydruk 3.2 Fragment pliku „JScore.xml" zawierający argumenty funkcji scoringowej

1. <Input count="4"> 2. <Variable index="0"> 3. <Name> CHECKING </Name> 4. <Type> double </Type> 5. </Variable> 6. <Variable index="1"> 7. <Name> DURATION </Name> 8. <Type> double </Type> 9. </Variable> 10. <Variable index="2"> 11. <Name> HISTORY </Name> 12. <Type> double </Type> 13. </Variable> 14. <Variable index="3"> 15. <Name> SAVINGS </Name> 16. <Type> double </Type> 17. </Variable> 18. </Input>

46

Celowo zaznaczam, że plik metadanych zawiera informację o argumentach i wyniku,

ponieważ jako argument funkcja scoringowa przyjmuje mapę i mapę zwraca w wyniku

działania. Może się w niej znaleźć dowolna liczba obiektów, jednak tylko niektóre będą

użyte.

Interesującym z punktu widzenia działania programu jest tylko fragment zawierający

argumenty funkcji scoringowej. Pozostałe części pliku metadanych są stałe.

Za analizę składniową pliku metadanych odpowiedzialana jest klasa

„ParserJScoreXML”. Do analizy składniowej wykorzystuje klasę „DOMParser”

z rodziny analizatorów składniowych „Apache Xerces”. Sprawdza zgodność pliku ze

standardem i spójność logiczną (np. czy jest tylko jedna sekcja „input”). Po odczytaniu

nazw i typów argumentów zwraca listę argumentów funkcji scorngowej.

Drugim etapem tworzenia listy argumentów jest uzupełnienie jej o informację ze

słownika. W słowniku znajdują się informację dotyczące tekstów wyświetlanych

w widoku. Dla każdego z argumentów funkcji scoringowej w słowniku są dwa rekordy

- rekord z czytelną nazwą oraz rekord z opisem. Rekordy słownika zapisane są

w formacie „nazwaArgumentu = nazwa do wyświetlenia” oraz „nazwaArgumentuopis =

opis argumentu w formacie HTML”. Poniżej zamieszczam fragment wydruku słownika

dla zmiennych bazy danych stosowanej w projekcie.

1. AGE = Wiek 2. AGEopis = <html>Wiek w latach</html> 3. AMOUNT = Kwota 4. AMOUNTopis = <html>Kwota kredytu</html> 5. CHECKING = Rachunek 6. CHECKINGopis = <html>Stan otwartych rachunków 1:

0<DM; 2: 0-200DM; 3: >200DM; 4: brak konta</html>

7. COAPP = Wspólnik 8. COAPPopis = <html>1: brak 2: współpożyczkobiorca 3:

żyrant</html> 9. DEPENDS = Utrzymanie

10. DEPENDSopis = <html>Liczba osób na utrzymaniu</html> 11. DURATION = Czas 12. DURATIONopis = <html>Czas trwania w miesiącach</html> 13. EMPLOYED = Zatrudnienie 14. EMPLOYEDopis = <html>Okres obecnego zatrudnienia 1: bezrobotny 2: <1 rok 3: 1-4 lata 4: 4-7 lat 5: >7 lat</html>

Wydruk 3.3 Fragment pliku słownika bazy danych

47

Słownik należy stworzyć w oparciu o opis stosowanej bazy danych. Za analizę

składniową i odpowiednie uzupełnienie listy argumentów funkcji scoringowej

odpowiada klasa „ParserSlownikaBazyDanych”.

Ocena kredytowa

Przeprowadzenie oceny kredytowej przez model dokonuje się na żądanie komponentu

„widok”, który przekazuje kontrolerowi wartości wprowadzone przez analityka

kredytowego. Kontroler wywołuje funkcję o nazwie „wyliczPrawdopodobieństwo”

z trzema argumentami: listą wartości i dwoma argumentami definiującymi przedziały

grup ryzyka kredytowego.

Pierwszym etapem wykonywania oceny kredytowej jest wywołanie funkcji

scoringowej. W tym celu należy przeprowadzić konwersję listy argumentów do mapy

zawierającej pary wartości: nazwa argumentu - wartość. Funkcja scoringowa

przeprowadza weryfikację poprawności wprowadzonych danych i scoring. Niestety

można zanalizować tylko logikę odpowiedzialną za poprawność wprowadzanych

danych - reszta logiki dostarczana jest w formie skompilowanej. Funkcja scoringowa

dostarcza mapę w rezultacie działania, w której interesujące z punktu widzenia aplikacji

są dwa rekordy. Jeden z nich to „EM_EVENTPROBABILITY” zawierający

prawdopodobieństwo spłaty kredytu podawane jako liczba rzeczywista z przedziału <0,

1>. Ten rekord będzie dalej przetwarzany w programie.

Drugim interesującym rekordem z mapy wynikowej funkcji scoringowej jest

„_WARN_”. Zawierają się w nim ostrzeżenia wygenerowane w czasie dokonywania

oceny. Niestety dostawca oprogramowania generującego funkcję scoringową nie podaje

dokumentacji dotyczącej rodzajów komunikatów ostrzeżeń. Ich format nie umożliwia

zorientowania się czego dotyczą (są to komunikaty znakowe, np. „U”, albo „M”).

Badając różne modele zorientowałem się, że komunikaty są generowane w przypadku

braku wystarczającej ilości danych lub ich niepoprawnych zakresach. W przypadku

modelu opartego na drzewie decyzyjnym komunikaty nie są generowane ze względu na

to, że drzewa decyzyjne posiadają wbudowane mechanizmy obsługi braków danych.

Ich ocena kredytowa jest sensowna dla niepełnego zestawu danych, choć oczywiście nie

tak wiarygodna jak dla pełnego zestawu danych.

Istnienie wartości dla klucza „_WARN_” w mapie wyniku funkcji scoringowej jest

ostrzeżeniem przed tym, że wynik działania może być niewiarygodny. Metoda

48

„wyliczPrawdopodobieństwo()” w takim przypadku generuje wyjątek informujący

użytkownika o potrzebie poprawienia danych wejściowych.

Pierwszy rekord, zawierający prawdopodobieństwo spłaty kredytu, służy do stworzenia

wyniku scoringu. W nowo utworzonym obiekcie klasy „WynikScoringu” umieszczane

jest prawdopodobieństwo oraz grupa ryzyka wyznaczona na podstawie podanych

wcześniej przedziałów.

3.4.4. Widok

Ostatnim omawianym komponentem aplikacji jest widok. Umożliwia wprowadzenie

danych, wyświetlenie wyników oceny kredytowej i wyświetlanie komunikatów błędów.

Widok zbudowany jest w oparciu o bibliotekę graficzną SWING. Główna klasa

komponentu - „OknoAplikacji” jest więc klasą pochodną od klasy „JFrame”. „JFrame”

definiuje podstawowe cechy wyświetlanego okna, jak kontrolowanie jego wymiarów

oraz reakcja na komunikat zamknięcia okna. Zawartość jest wyświetlana zgodnie

z polityką zarządcy układu (ang. layout manager) typu „BorderLayout”. Dzieli ekran na

pięć sektorów: północny, wschodni, południowy, zachodni i centralny. Sektory

północny i południowy mają stałą wysokość i zajmują pas przestrzeni na górze i dole

okna. Analogiczne sektory wschodni i zachodni mają stałą szerokość i zajmują pasy

przestrzeni z lewej i prawej strony okna.

W przedstawianej aplikacji użyłem tylko sektora zachodniego i centralnego. W sektorze

zachodnim umieściłem panel wprowadzania danych, a w sektorze centralnym panel

wyświetlania wyników. Dzięki temu formularz wprowadzania danych posiada stałą

szerokość zapewniającą poprawne wyświetlanie pól wprowadzania danych i ich

opisów. Przestrzeń sektora centralnego zajmuje panel wyświetlania wyników.

Wprowadzanie danych

Wprowadzanie danych realizowane jest przez obiekt klasy

„PanelWprowadzaniaDanych”. Po jego utworzeniu należy dla każdego dopuszczalnego

argumentu wywołać funkcję „dodajPoleFormularza()”, która dodaje odpowiednie pole

w formularzu. Biblioteka SWING posiada specjalne pola wprowadzania danych

umożliwiające w łatwy sposób zapewnić kontrolę poprawności danych. Klasa

„JFormattedTextField” umożliwia wprowadzanie wartości tylko w zdefiniowanym

formacie. Dzięki temu mam pewność, że użytkownik do pola numerycznego nie

49

wprowadzi wartości nie numerycznych. Odpowiedzialność dokładniejszego

sprawdzenia poprawności wprowadzonych danych spoczywa na modelu.

Metoda „dodajPoleFormularza()”, oprócz narysowania pól wprowadzania danych i ich

opisów, zachowuje odwołania do nich w odpowiednim formacie. Jest to niezbędne do

odczytywania danych z pól - do identyfikacji zmiennych musi przechowywać ich

nazwy z bazy danych.

Analityk kredytowy, po wprowadzeniu danych do odpowiednich pól formularza, wciska

przycisk „Oceń”. Sterowanie jest wtedy przekazywane do obiektu

„OdczytywanieDanychFormularza”. Obiekt pobiera od obiektu klasy

„PanelWprowadzaniaDanych” reprezentację pól wprowadzania danych w postaci

i mapy i konwertuje ją na listę argumentów funkcji scoringowej, odczytując ze

wszystkich pól ich wartości. Gotową listę przekazuje obiektowi klasy „OknoAplikacji”,

która dalej kieruje ją do kontrolera.

Wyświetlanie wyników

Wyświetlanie wyników realizuje klasa „PanelWyswietlaniaWynikow”. Wyświetla

prawdopodobieństwo spłaty kredytu w postaci tekstowej razem z grupą ryzyka

kredytowego.

Dodatkowo wynik oceny kredytowej jest przedstawiany w postaci graficznej. Klasa

„WykresSlupkowy” realizuje rysowanie wykresu słupkowego i ustalenie jego koloru

w zależności od grupy ryzyka kredytowego. Dla grupy wysokiego ryzyka jest to kolor

czerwony, dla grupy średniego ryzyka kolor żółty, dla grupy niskiego ryzyka kolor

zielony.

Okno błędów

Wymagana dla widoku jest implementacja mechanizmu wyświetlania błędów. Część

błędów jest wyświetlana jeszcze przed zainicjowaniem widoku (jak błąd pliku

konfiguracyjnego), więc musi on zapewniać specjalny mechanizm ich wyświetlania.

Idealnym do tego jest mechanizm okien dialogowych. W prosty sposób biblioteka

SWING umożliwia wyświetlenie jednego z zestawu zdefiniowanych okien z podaniem

odpowiednich parametrów. Dzięki temu inne okno jest wyświetlanie dla komunikatu

błędu krytycznego po którym następuje zamknięcie aplikacji i inne do wyświetlenia

ostrzeżenia. Widok okna błędu krytycznego przedstawiłem w rozdziale „3.6.2

Konfiguracja aplikacji”.

50

3.5. Testowanie aplikacji

Istotnym elementem procesu wytarzania aplikacji jest przeprowadzenie testów. Ich

celem jest wykrycie błędów, wskazanie miejsc wymagających poprawek, sprawdzenie

stabilności oprogramowania oraz zgodności z wymaganiami.

Dobrą praktyką stosowaną przy tworzeniu oprogramowania jest tworzenie testów

równolegle z implementowaniem programu. Do powstającego kodu aplikacji dołącza

się automatyczne testy od razu po napisaniu jego części5. Przynosi to dwojakie

korzyści. Po pierwsze pozwala sprawdzić, czy dany fragment kodu działa zgodnie

z oczekiwaniami. Po drugie pozwala na bieżąco sprawdzać, czy zmiany wprowadzane

w kodzie nie generują błędów w innych miejscach.

W przedstawianym projekcie rozplanowałem testy na trzy etapy. Pierwszym było

tworzenie testów jednostkowych wraz z implementowaniem funkcjonalności. Drugim

były testy integracyjne sprawdzające współdziałanie komponentów. Trzecim - testy

systemowe weryfikujące działanie całej aplikacji, pod kątem spełnienia postawionych

wymagań. Do automatycznego testowania użyłem narzędzia JUnit, w postaci wtyczki

do platformy Eclipse. Wykorzystałem także bibliotekę „EasyMock” do izolowania

części testowanej funkcjonalności oraz symulowania części aplikacji trudnych do

testowania. W poniższych podrozdziałach opisałem poszczególne etapy testowania,

wraz z uzasadnieniem podjętych wyborów, co do tego, co było sprawdzane.

3.5.1. Testy jednostkowe

Testy jednostkowe mają za zadanie sprawdzić działanie izolowanych fragmentów kodu

takich jak funkcje czy klasy. Zdecydowałem się stworzyć automatyczne testy do metod

realizujących nietrywialną logikę. Na tej podstawy wraz z implementowaniem kodu

powstały automatyczne testy do wszystkich klas komponentu „model” oraz do metod

przekształcania danych zawartych w pakiecie „pomocnicze”. Sprawdziłem prawidłowe

wykonanie i przypadki brzegowe dla metod klas: „ModelDoSkompilowanegoKodu”,

„ParserJScoreXML”, „ParserSlownikaBazyDanych” i „ArgumentFunkcjiScoringowej”.

Łącznie, dla wymienionych klas, stworzyłem 20 automatycznych testów

jednostkowych.

5 Niektóre metody programowania zalecają tworzenie testów przed implementowaniem funkcjonalności,

co ma skłonić programistę do implementowania tylko tego co niezbędne i, w rezultacie, zwiększyć jego

efektywność (patrz Extreme Programming - [16]).

51

3.5.2. Testy integracyjne

Testy integracyjne sprawdzają współdziałanie określonych części aplikacji.

Funkcjonalność komponentu „kontroler” koncentruje się wokół integrowania działania

modelu i widoku, dlatego uznałem, że testy integracyjne najskuteczniej sprawdzą jego

działanie. Ułożyłem trzy automatyczne testy sprawdzające ładowanie konfiguracji,

inicjowanie widoku, informowanie o błędach i wykonywanie oceny kredytowej. Ze

względu na zbyt dużą komplikację testowania graficznych elementów interfejsu

użytkownika, zdecydowałem się podmienić w tych testach komponent „widok” na

obiekt symulowany. Sprawdzanie widoku odłożyłem do testów systemowych.

3.5.3. Testy systemowe

Testy systemowe były ostatnim etapem sprawdzania poprawności działania aplikacji.

Plan testowania wyznaczyłem według projektu diagramów przypadków użycia -

najpierw przetestowałem funkcjonalność wykonywania oceny kredytowej, a następnie

konfiguracji grup ryzyka. Testy systemowe wykonywałem ręcznie, wprowadzając

przygotowany zbiór danych.

Testy systemowe wykazały poprawne funkcjonowanie programu i spełnienie wymagań

funkcjonalnych. W czasie testowania ujawnił się jednak pewien defekt działania dla

wykonywania oceny kredytowej. Aplikacja nie informowała o wprowadzeniu danych

spoza dopuszczalnego zakresu. Analiza implementacji wykazała, że odpowiedzialna

jest za to generowana automatycznie funkcja scoringowa. Zastosowany model oparty na

drzewie decyzyjnym posiada wbudowane mechanizmy obsługi wartości spoza zakresu

i nie informuje w tych przypadkach o błędach. Uznałem, że ze względu na brak

możliwości edycji kodu funkcji scoringowej dostarczanego w postaci skompilowanej,

pozostawię program w niezmienionej postaci. Funkcja scoringowa przedstawiała

wiarygodną ocenę kredytową, co minimalizowało koszty związane z nieprzewidzianym

działaniem aplikacji.

3.6. Przedstawienie funkcjonalności aplikacji

W ostatniej części tego rozdziału przedstawiłem przykładowe scenariusze

z użytkowania aplikacji. W pierwszej części opisałem dwa scenariusze zgodne

z przypadkiem użycia „Wykonanie oceny kredytowej”. W drugiej części pokazałem

działanie aplikacji przy różnych wartościach konfiguracji, co odpowiada przypadkowi

52

użycia „Określenie przedziałów ryzyka kredytowego” jak również wymaganiu

funkcjonalnemu numer 3 („Program powinien informować o błędach konfiguracji

i wprowadzonych danych.”).

Rysunek 3.33 Okno aplikacji przed wprowadzeniem danych

3.6.1. Wykonanie oceny kredytowej

Po uruchomieniu programu analityk kredytowy widzi gotowe okno do oceny

kredytowej. Z lewej strony okna znajduje się formularz wprowadzania danych wraz

z kompletnymi opisami do wprowadzania danych i przyciskiem „Oceń”. W prawej

części jest natomiast panel do prezentacji wyników: miejsce na wartość

prawdopodobieństwa spłacenia kredytu, miejsce na grupę ryzyka do której zostanie

zakwalifikowany klient oraz graficzną reprezentację wyniku w postaci wykresu

słupkowego. Przed wprowadzeniem danych wyniki jeszcze nie są pokazane - miejsca

53

na wartość prawdopodobieństwa i grupę ryzyka są puste, a wykres reprezentacji wyniku

nie jest narysowany (pokazuje wartość „0.0%”).

Dla zbudowanego modelu w części formularza znajdują się cztery pola do

wprowadzenia danych. Są to: stan otwartych rachunków, czas trwania kredytu, historia

kredytowa klienta, oszczędności klienta na koncie lub w obligacjach.

Do przedstawienia funkcjonalności wybrałem dwa przypadki ze zbioru wejściowego.

Pierwszym kredytobiorcą jest mężczyzna w wieku 25 lat starający się o kredyt

w kwocie 5152 DM na dwa lata na radio lub telewizor. Dane historyczne zawierają

informacje, że kredyt został przez niego spłacony. Drugą osobą zaciągającą kredyt jest

kobieta w wieku 24 lat starająca się o kredyt w kwocie 626 DM na rok również na radio

lub telewizor. Jednak w jej przypadku kredyt nie został spłacony. Obydwie obserwacje

zbioru wejściowego zaprezentowałem w tabeli poniżej.

Numer rekordu bazy

danych

478 549

Wiek (AGE) 25 (lat) 24 (lata)

Kwota kredytu (AMOUNT) 5152 (DM) 626 (DM)

Stan otwartych rachunków

(CHECKING)

3 (powyżej 200 DM) 1 (poniżej 0 DM)

Wspólnik (COAPP) 1 (kredyt brany samodzielnie) 1 (kredyt brany samodzielnie)

Liczba osób na utrzymaniu

(DEPENDS)

1 1

Czas spłaty (DURATION) 24 (miesiące) 12 (miesięcy)

Czas zatrudnienia

(EMPLOYED)

4 (4-7 lat) 3 (1-4 lat)

Liczba otwartych kredytów

(EXISTCR)

1 1

Historia kredytowa

(HISTORY)

2 (kredyty spłacane należycie

do teraz)

1 (brak zaciągniętych

kredytów lub wszystkie

spłacone należycie)

Mieszkanie (HOUSING) 2 (własne) 2 (własne)

54

Praca (JOB) 3 (pracownik

wykwalifikowany lub

urzędnik)

2 (pracownik miejscowy -

niewykwalifikowany)

Stan cywilny (MARITAL) 3 (kawaler) 2 (kobieta - rozwiedziona,

w separacji lub żonata)

Inne plany ratalne

(OTHER)

1 (bank) 1 (bank)

Majątek (PROPERTY) 3 (samochód lub inny

majątek)

1 (nieruchomość)

Przeznaczenie (PURPOSE) 3 (radio lub telewizor) 3 (radio lub telewizor)

Oszczędności (SAVINGS) 1 (do 100DM) 1 (do 100DM)

Telefon (TELEPHON) 1 (brak) 1 (brak)

Czy kredyt został spłacony

(GOOD_BAD)

tak nie

Tabela 3.3 Wybrane rekordy do prezentacji działania aplikacji

Z prezentowanego zbioru interesują nas tylko wspomniane wartości pobierane przez

aplikację. Dla obserwowanego mężczyzny analityk kredytowy wprowadza do programu

następujące wartości: rachunek - 3, czas - 24, historia - 2 i oszczędności - 1. Ocena

kredytowa klienta jest pozytywna - szansa na spłatę kredytu wynosi 86,76%, co

kwalifikuje go do niskiej grupy ryzyka. Ocena kredytowa jest wiarygodna, ponieważ

klient rzeczywiście spłacił kredyt.

55

Rysunek 3.34 Okno aplikacji dla oceny kredytowej klienta z 478 rekordu bazy danych

Dla drugiej wybranej obserwacji ze zbioru danych (kobieta - 24 lata) analityk

kredytowy wprowadza do programu następujące wartości: : rachunek - 1, czas - 12,

historia - 1 i oszczędności - 1. Ocena kredytowa jest negatywna - szansa na spłatę

kredytu wynosi zaledwie 29,41%. Program zaklasyfikował klienta do wysokiej grupy

ryzyka, co skłania analityka kredytowego do odmowy przyznania kredytu. Wynik

podany przez model zgadza się z informacjami znajdującymi się w bazie danych -

wiadomo, że klient nie spłacił kredytu.

56

Rysunek 3.35 Okno aplikacji dla oceny kredytowej klienta 549 rekordu bazy danych

3.6.2. Konfiguracja aplikacji

Ustawienie konfiguracji odbywa poprzez zmianę w edytorze tekstowym pliku

konfiguracyjnego. Za ustawienia wartości granicznych grup ryzyka kredytowego

odpowiadają właściwości „OdciecieNiskiejGrupyRyzyka”, która domyślnie ustawiona

jest na wartość „0.85” (85%) i właściwość „OdciecieSredniejGrupyRyzyka” domyślnie

ustawionej na „0.6” (60%). Po zmianie tych właściwości, uruchomieniu programu

i wprowadzeniu danych możemy zauważyć zmianę zakwalifikowania klienta o tych

samych cechach do grup ryzyka kredytowego.

57

Rysunek 3.36 Okna aplikacji dla różnej konfiguracji miejsc odcięcia grupy niskiego ryzyka

Niewłaściwa konfiguracja pliku, jego złe umiejscowienie lub nazwa powoduje

wyświetlenie błędu i uniemożliwia uruchomienie programu.

Rysunek 3.37 Okno błędu niewłaściwych ustawień pliku konfiguracyjnego

58

4. Podsumowanie

W ostatnim rozdziale niniejszej pracy zweryfikowałem zgodność poczynionych założeń

z osiągniętymi wynikami, opisałem zalety oraz wady przyjętych przeze mnie

rozwiązań, wskazałem przykładowe zastosowanie i przedstawiłem kierunki rozwoju

zaprezentowanej aplikacji.

4.1. Weryfikacja wymagań

W czasie analizy wymagań funkcjonalnych udało mi się wypracować trzy wymogi

stawiane tworzonej aplikacji. Pierwszy dotyczy wykonywania oceny kredytowej

klientów banku. Aplikacja zawiera następujące funkcjonalności: posiada intuicyjny

i konfigurowalny interfejs oraz prezentuje wyniki w sposób czytelny i jednoznaczny.

Dodatkowo zastosowany model pozwala dokonać oceny na podstawie niewielkiego

zestawu informacji pobieranej od klienta, co ułatwia i przyśpiesza proces podejmowania

decyzji kredytowej. Niestety, wadą zaprezentowanego modelu jest wiek danych

wybranych do jego trenowania. Wspomniany brak jest skutkiem niskiej dostępności do

takich danych - instytucje nie są skłonne udostępniać danych zgromadzonych w swoich

bazach danych. W ciągu kilkunastu lat, które minęły od zebrania zastosowanych

danych, wzorce zachowań kredytobiorców mogły ulec zmianie i model, wytrenowany

na tej bazie danych, może być mniej wiarygodny niż wykazała to analiza.

Drugie wymaganie funkcjonalne dotyczy określania przedziałów ryzyka kredytowego

przez „Analityka grup ryzyka”. Zostało ono całkowicie spełnione dzięki zastosowaniu

pliku konfiguracyjnego. Zewnętrzny plik jest łatwo edytowalny oraz umożliwia

sprawną zmianę konfiguracji w wielu instancjach programu. Takie rozwiązanie wspiera

proces opracowywania nowej polityki kredytowej banku.

Wyświetlanie odpowiednich błędów jest przedmiotem trzeciego wymagania

funkcjonalnego. Aplikacja posiada odpowiednie mechanizmy informowania o błędach

krytycznych i ostrzeżeniach. Informuje użytkownika o błędach konfiguracji

i uruchamiania aplikacji. Komponent widoku posiada zaimplementowany mechanizm

kontroli wprowadzania odpowiedniego typu danych. Komponent modelu sprawdza ich

poprawność logiczną i określa czy można na ich podstawie dokonać oceny kredytowej.

59

Co więcej, posiada mechanizmy wspierające obsługę danych niepoprawnych lub

niepełnych. Wadą złożenia odpowiedzialności za sprawdzanie poprawności

wprowadzonych danych na kod aplikacji wygenerowany przez oprogramowanie

zewnętrznego dostawcy jest niepełny zestaw komunikatów błędów takich jak

wprowadzenie wartości spoza dostępnego zakresu. W przypadku, gdy model stosuje

mechanizmy wspierające wykonywanie oceny kredytowej w oparciu o niepoprawne lub

niepełne dane, nie informuje o tym użytkownika, nawet gdy ten mógł wprowadzić takie

dane nie przez brak pełnej informacji o kliencie, ale poprzez nieuwagę.

Wymagania niefunkcjonalne postawione projektowanej aplikacji zostały spełnione.

Aplikacja umożliwia sprawną wymianę modeli oceny kredytowej bez potrzeby

wprowadzania zmian w kodzie. Wystarczy wymienić odpowiednie pliki i rekompilować

program. Rekompensuje to wady związane z koniecznością zastosowania danych

trenujących sprzed 2002 roku. Bank stosujący aplikację może z łatwością wymienić

zastosowany model na wytrenowany w oparciu o dane zebrane w ciągu swojej

działalności, znacząco podnosząc jego skuteczność.

Aplikacja jest skalowalna i integrowalna w systemami typu CRM dzięki

zastosowanemu wzorcowi architektonicznemu MVC. Ocena wykonywana przez nią

odbywa się w czasie rzeczywistym. Dzięki umieszczeniu modelu scoringowego razem

z programem jego wydajność zależy od parametrów maszyny na której jest

uruchamiany. Pozawala to uniknąć problemów związanych z nadmiernym obciążeniem

serwerów i ich utrzymaniem. Dzięki zastosowaniu technologii Java program może być

uruchomiony na prawie każdej maszynie klasy PC - około 97% komputerów

w przedsiębiorstwach korzysta z tej technologii [9].

Zaprezentowana praca i jej wynik - aplikacja do oceny kredytowej, ma pomóc małym

i średnim przedsiębiorstwom z sektora bankowego. Niewielkie koszty stworzenia

aplikacji według przedstawionego schematu i łatwość jej użycia dają możliwość

wykonywania profesjonalnej oceny kredytowej firmom, których nie stać na kosztowne

rozwiązania stosowane w tej branży jak kompleksowe systemy CRM. Jej cechy

umożliwiają także skuteczne rozwijanie programu wraz z rozbudową firmy poprzez

integrację z zamawianymi kompleksowymi systemami obsługi działalności firmy.

60

4.2. Dalsze kierunki rozwoju pracy

Niniejsza praca nie wyczerpuje wszystkich aspektów związanych z tą dziedziną

informatyki i bankowości. Przedstawione rozwiązanie może być dalej dopracowywane

i rozwijane. W trakcie pracy nad przedstawionym programem zauważyłem wiele

potencjalnych kierunków jej rozwoju.

Jednym z nich jest rozwój oprogramowania poprzez przeniesienie części

odpowiedzialnej za wykonywanie obliczeń na zewnętrzny serwer. Może to umożliwić

stosowanie bardziej skomplikowanych modeli scoringowych wymagających znacznych

mocy obliczeniowych. Dalszym etapem rozwoju może być zrealizowanie systemu

zarządzania modelami. Pomocne w tym mogą być narzędzia środowiska SAS do oceny

i integracji opracowanych modeli. Innym kierunkiem rozwoju pracy może być

opracowanie aplikacji dla urządzeń mobilnych, które dałyby możliwość oceny

kredytowej przeprowadzanej przez analityków działających poza placówkami banku.

61

Bibliografia

1. Daniel T. Larose, Odkrywanie wiedzy z danych. Wprowadzenie do eksploracji

danych, PWN, Warszawa 2006.

2. John Deacon, Model-View-Controller (MVC) Architecture. 2009.

http://www.jdl.co.uk/briefings/index.html#mvc (dostęp: 28.08.2014).

3. Steve Burbeck, Applications Programming in Smalltalk-80: How to use Model-

View-Controller (MVC), 1992, http://www.dgp.toronto.edu/~dwigdor/teaching/

csc2524/2012_F/papers/mvc.pdf (dostęp: 21.08.2014).

4. Tim Bray, Extensible Markup Language (XML), http://www.w3.org/TR/2006/REC-

xml11-20060816 (dostęp: 21.08.2014).

5. SAS Institute Inc, SEMMA, http://www.sas.com/technologies/analytics/datamining/

miner/semma.html (dostęp: 28.05.2006).

6. SAS Institute Inc, Getting Started with SAS Enterprise Miner 12.1, SAS Institute

Inc., 2012.

7. International Business Machines Corp, Eclipse Platform Technical Overview,

2006, https://www.eclipse.org/articles/Whitepaper-Platform-3.1/eclipse-platform-

whitepaper.pdf (dostęp: 25.08.2014).

8. The Eclipse Foundation, Eclipse WindowBuilder, 2014 , http://www.eclipse.org/

windowbuilder/ (dostęp: 25.08.2014).

9. Oracle, Dowiedz się więcej o technologii Java, https://www.java.com/pl/about/

(dostęp: 06.09.2014).

10. Wikipedia, MVC, http://pl.wikipedia.org/wiki/Model-View-Controller (dostęp:

22.08.2014).

11. Michael Morrison, HTML i XML, RM, Warszawa 2003.

12. Celina Olszak, Kamila Bartuś, Analiza i ocena wybranych modeli eksploracji

danych, http://ptzp.org.pl/files/konferencje/kzz/artyk_pdf_2009/092_Olszak_Bartus.pdf

(dostęp: 23.08.2014).

62

13. The Eclipse Foundation, Eclipsopedia, http://wiki.eclipse.org/Main_Page (dostęp:

25.08.2014).

14. SAS Institute Inc, Data Mining Using SAS® Enterprise Miner™: A Case Study

Approach, Third Edition, 2013.

15. Krzysztof Sacha, Inżynieria oprogramowani, PWN, Warszawa 2010.

16. Ronald E. Jeffries, XProgramming, 2014, http://xprogramming.com/index (dostęp:

08.09.2014).

17. Grzegorz Ignaciuk, Zastosowanie metod scoringowych w działalności bankowej,

statsoft.pl/czytelnia.html (dostęp: 25.08.2014).

18. Michael Berry, Gordon Linoff, Data mining techniques : for marketing, sales, and

customer relationship managment, Wiley Publishing Inc, Indiana 2004.

19. Grzegorz Migut, Janusz Wątroba, Scoring kredytowy, a modele data mining,

www.statsoft.pl/Portals/0/Downloads/scoring.pdf (dostęp: 25.08.2014).

63

Spis rysunków, tabel i wydruków

Rysunek 2.1 Fragment drzewa decyzyjnego przewidującego zdolność kredytową

klientów banku. ........................................................................................... 7

Rysunek 2.2 Przykładowy ekran aplikacji SAS Enterprise Miner 12.1 ........................... 8

Rysunek 2.3 Przykładowy ekran z Eclipse Standard 4.4 ................................................ 10

Rysunek 2.4 Przykładowy widok okna projektowania Eclipse WindowBuilder ........... 11

Rysunek 3.1 Etapy budowy modelu przedstawione w programie SAS Enterprise Miner

................................................................................................................... 13

Rysunek 3.2 Wykres rozkładu zmiennej „Wiek" ........................................................... 14

Rysunek 3.3 Wykres rozkładu zmiennej „Kwota kredytu"; zakreskowana część słupka

wyznacza pozytywne obserwacje .............................................................. 14

Rysunek 3.4 Wykres rozkładu zmiennej „Stan otwartych rachunków" ......................... 15

Rysunek 3.5 Wykres rozkładu zmiennej „Wspólnik" .................................................... 16

Rysunek 3.6 Wykres rozkładu zmiennej „Liczba osób na utrzymaniu" ........................ 16

Rysunek 3.7 Wykres rozkładu zmiennej „Czas spłaty" .................................................. 17

Rysunek 3.8 Wykres rozkładu zmiennej „Czas zatrudnienia" ....................................... 18

Rysunek 3.9 Wykres rozkładu zmiennej „Liczba otwartych kredytów" ........................ 18

Rysunek 3.10 Wykres rozkładu zmiennej „Historia kredytowa" ................................... 19

Rysunek 3.11 Wykres rozkładu zmiennej „Mieszkanie"................................................ 20

Rysunek 3.12 Wykres rozkładu zmiennej „Praca" ......................................................... 21

Rysunek 3.13 Wykres rozkładu zmiennej „Stan cywilny" ............................................. 22

Rysunek 3.14 Wykres rozkładu zmiennej „Inne plany ratalne" ..................................... 22

Rysunek 3.15 Wykres rozkładu zmiennej „Majątek" ..................................................... 23

Rysunek 3.16 Wykres rozkładu zmiennej „Przeznaczenie" ........................................... 24

Rysunek 3.17 Wykres rozkładu zmiennej „Oszczędności" ............................................ 25

Rysunek 3.18 Wykres rozkładu zmiennej „Telefon"...................................................... 25

Rysunek 3.19 Drzewo decyzyjne od poziomu 0 do poziomu 2 ...................................... 27

Rysunek 3.20 Drzewo decyzyjne od poziomu 2 do poziomu 4 (prawe odgałęzienie) ... 28

Rysunek 3.21 Drzewo decyzyjne od poziomu 2 do poziomu 3 (lewe odgałęzienie) ..... 28

Rysunek 3.22 Wykres przyrostu skumulowanego dla danych trenujących

i walidacyjnych .......................................................................................... 29

64

Rysunek 3.23 Diagram przypadku użycia „Wykonanie oceny kredytowej" .................. 32

Rysunek 3.24 Diagram przypadku użycia „Określenie przedziałów ryzyka

kredytowego" ............................................................................................. 32

Rysunek 3.25 Diagram komponentów aplikacji ............................................................. 33

Rysunek 3.26 Diagram klas komponentu „kontroler” .................................................... 34

Rysunek 3.27 Diagram klas dla komponentu „model" ................................................... 35

Rysunek 3.28 Diagram klas dla komponentu „widok" ................................................... 36

Rysunek 3.29 Diagram klas dla wyniku scoringu .......................................................... 37

Rysunek 3.30 Diagram klas dla argumentu funkcji scoringowej ................................... 38

Rysunek 3.31 Diagram sekwencji komponentu widok dla przypadku użycia

„Wykonanie oceny kredytowej” ................................................................ 39

Rysunek 3.32 Diagram sekwencji komponentów dla przypadku użycia „Wykonanie

oceny kredytowej” ..................................................................................... 39

Rysunek 3.33 Okno aplikacji przed wprowadzeniem danych ........................................ 52

Rysunek 3.34 Okno aplikacji dla oceny kredytowej klienta z 478 rekordu bazy danych

................................................................................................................... 55

Rysunek 3.35 Okno aplikacji dla oceny kredytowej klienta 549 rekordu bazy danych . 56

Rysunek 3.36 Okna aplikacji dla różnej konfiguracji miejsc odcięcia grupy niskiego

ryzyka ........................................................................................................ 57

Rysunek 3.37 Okno błędu niewłaściwych ustawień pliku konfiguracyjnego ................ 57

Tabela 3.1 Podział danych wejściowych na zbiory według algorytmu podziału

warstwowego ............................................................................................. 26

Tabela 3.2 Parametry pliku konfiguracyjnego aplikacji ................................................. 43

Tabela 3.3 Wybrane rekordy do prezentacji działania aplikacji ..................................... 54

Wydruk 2.1 Przykładowy fragment dokumentu XML generowany przez narzędzie SAS

Enterprise Miner .......................................................................................... 5

Wydruk 3.1 Przykładowa zawartość pliku konfiguracyjnego ........................................ 43

Wydruk 3.2 Fragment pliku „JScore.xml" zawierający argumenty funkcji scoringowej

................................................................................................................... 45

Wydruk 3.3 Fragment pliku słownika bazy danych ....................................................... 46

praca dyplomowa inŻynierska · data rozpoczęcia studiów: ... zastosowane technologie, metody...

Documents