pobierz plik referatu - Politechnika ÅlÄska

Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008 

www.bdas.pl 

Rozdział 9 

Wymagania funkcjonalne interfejsu użytkownika dla 

frameworków tworzenia aplikacji bazodanowych 

Streszczenie. W rozdziale opisano podstawowe wymagania funkcjonalne 

odnoszące się do warstwy prezentacji aplikacji bazodanowych. Zestaw 

wymagań funkcjonalnych stworzono w oparciu o doświadczenia związane 

z użytkowaniem interfejsu graficznego aplikacji ERP: IFS Applications, 

Microsoft Dynamics NAV oraz generatorów aplikacji: MSE Magic 

eDeveloper, Centura, Oracle Forms Developer. Jako alternatywne 

rozwiązanie wspomagające tworzenie aplikacji Java wskazano autorską 

bibliotekę EALib. Przedstawiona biblioteka rozszerza możliwości biblioteki 

Borland dbSwing dostarczając szkielet programistyczny umożliwiający 

szybsze tworzenie aplikacji bazodanych. 

1 Wstęp 

Uniwersalne środowiska tworzenia aplikacji – takie jak Microsoft Visual Studio, Borland 

C++ Builder, czy też rozwiązania oparte o Eclipse (Borland JBuilder, IBM WebSphere 

Development Studio) – umożliwiają tworzenie różnego typu aplikacji: programów 

narzędziowych, poprzez edytory tekstu i grafiki, aplikacje multimedialne, gry, aplikacje 

sieciowe, aplikacje biznesowe i inne. Wykorzystanie tego typu narzędzi do tworzenia 

aplikacji bazodanowych – często od zera – korzystając z dostępnych w środowisku 

deweloperskim obiektów i kreatorów, jest bardzo pracochłonne. Uproszczenie procesu 

tworzenia tego typu aplikacji można uzyskać przez zastosowanie bibliotek lub całych 

frameworków (szkieletów) programistycznych dedykowanych dla aplikacji bazodanowych 

(Borland dbSwing, JGoodies, Oracle ADF, JBoss Seam). Jeszcze większą efektywność 

tworzenia aplikacji oferują specjalizowane generatory aplikacji bazodanowych (MSE 

Magic eDeveloper, Centura, PowerBuilder, Oracle Developer Suite/Oracle Forms 

Developer, środowisko Microsoft Dynamics NAV C/SIDE i inne). Rozwiązania te 

umożliwiają bardzo szybką implementację podstawowych funkcjonalności 

charakterystycznych dla systemów bazodanowych (obsługa podstawowych operacji na 

danych, wyszukiwanie, system bezpieczeństwa). Podstawowe obiekty, które można 

tworzyć w systemach tego typu obejmują: tabele, formularze (tabelaryczne oraz kartoteki, 

w tym obsługa formularzy złożonych, np. relacji 1:N), raporty, moduły programowe 

dziedzinowej logiki przetwarzania (zwanej dalej logiką biznesową), programy 

Jacek Frączek 

Politechnika Śląska, Instytut Informatyki, ul. Akademicka 16, 44-100 Gliwice, Polska 

email: jacek.fraczek@polsl.pl 

(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008


J. Frączek 

www.bdas.pl 

importu/eksportu danych, menu. Podstawową wadą generatorów aplikacji bazodanowych 

jest fakt, że są to rozwiązania płatne. 

Przedstawiona w niniejszym rozdziale biblioteka EALib wspomaga szybkie i efektywne 

tworzenie aplikacji bazodanowych. Opisywane rozwiązanie oparto na bibliotece Borland 

dbSwing, której komponenty pozwalają powiązać kontrolki wizualne z obiektami warstwy 

dostępu do danych [8]. Bazując na klasach biblioteki dbSwing utworzono nowe klasy 

o wzbogaconej funkcjonalności. Opisywane rozwiązanie jest wynikiem prac własnych oraz 

kilkuletniego wysiłku osób współtworzących poszczególne elementy rozwiązania 

w ramach realizowanych tematów prac dyplomowych magisterskich [1,2,3,4,5]. 

Przed przedstawieniem zrealizowanego projektu opisano wymagania jakie powinien 

spełniać framework tworzenia aplikacji bazodanowych. W części tej zebrano osobiste 

doświadczenia związane z użytkowaniem interfejsu graficznego rozbudowanych aplikacji 

ERP: IFS Applications, Microsoft Dynamics NAV oraz opisano rozwiązania oferowane 

przez generatory aplikacji: MSE Magic eDeveloper, Centura, Oracle Forms Developer. 

2 Wymagania dotyczące warstwy prezentacji aplikacji bazodanowych 

Framework programistyczny dla tworzenia desktopowych aplikacji bazodanowych 

realizowanych przy użyciu uniwersalnych języków programowania (Java, C/C++/C#, 

Pascal) powinien oferować gotowe rozwiązania dla następujących obszarów aplikacyjnych: 

− klasa okna głównego aplikacji, 

− klasa formatki podstawowej, 

− klasy (lub szablony) umożliwiające szybką realizację najczęściej występujących 

formatek: 

− kartoteka (np. kartoteka pojedynczego pracownika), 

− lista (np. lista wykaz kont księgowych), 

− kartoteka z listą: 

− obsługa danych pozostających w relacji 1:N (np., dane wydziału wraz 

z listą jego pracowników), 

− obsługa danych pozostających w relacji M:N (np., grupy użytkowników 

i przypisani do nich użytkownicy), 

− klasa słownika, 

− jednolite mechanizmy obsługi odczytu i edycji danych, 

− zintegrowane mechanizmy filtrowania i wyszukiwania danych, 

− możliwość automatycznej aktualizacji aplikacji, 

− zintegrowany system bezpieczeństwa. 

Zastosowanie konkretnego szkieletu programistycznego może wymagać spełnienia 

dodatkowych wymagań, a w szczególności: 

− odpowiedniego wypełnienia treścią plików konfiguracyjnych frameworka, 

− istnienia struktur metadanych w bazie danych (np. do przechowywania informacji 

o konfiguracji formatek aplikacji), 

− określonej budowy obiektów warstwy przechowywania danych (np. przy stosowaniu 

mechanizmów tzw. optymistycznego blokowania). 

Podane w dalszych rozdziałach cechy i funkcjonalności szczegółowe fameworku są 

pewną propozycją. W szczególności projektanci szkieletu programistycznego mogą przyjąć 

inne założenia i wdrożyć rozwiązania odmienne od zaproponowanych. Przedstawione 

propozycje dotyczą frameworku służącego do realizacji aplikacji desktopowych, 

110 



Wymagania funkcjonalne interfejsu użytkownika dla frameworków tworzenia aplikacji bazodanowych 

aczkolwiek może on stanowić podstawę dla realizacji projektów aplikacji WWW. 

Rozwiązania związane z systemem użytkowników, konfiguracją aplikacji, szablonami 

podstawowych typów formatek są wspólne dla dowolnego typu aplikacji. 

2.1 Klasa głównego okna aplikacji 

www.bdas.pl 

Okno główne aplikacji bazodanowej zawiera z reguły następujące elementy (rys.1): 

− belkę tytułową, której może towarzyszyć krótki pasek narzędziowy (podobnie jak 

w Microsoft Office 2007), 

− pasek lub wstążki menu (menu + główny pasek narzędziowy) – obsługa 

podstawowych funkcji aplikacji: 

− aplikacja: zaloguj do systemu, wyloguj z systemu, zmień hasło, konfiguracja 

aplikacji, zakończ, 

− nawigacja między rekordami: pierwszy, następny, poprzedni, ostatni rekord, 

− obsługa danych: odczyt danych (odświeżenie), wycofanie dokonanych zmian, 

zapis danych, dodaj nowy rekord, kopiuj rekord 1 , usuń rekord, 

− panel wyszukiwania, 

− inne: wywołanie domyślnej formatki szczegółów, wywołanie domyślnego 

raportu, przeniesienie danych do archiwum, itp., 

− okno nawigatora – umożliwiające wybór operacji (formatek) z rozwijalnego menu 

(IFS Applications, Microsoft Dynamics NAV – okno nawigatora ma postać paska 

nawigatora Outlook), 

− obszar roboczy – w którym otwierane są formatki aplikacji; wśród możliwości 

realizacji obsługi formatek w obszarze roboczym można wyróżnić zastosowanie: 

− okien wewnętrznych (MDI), 

− zakładek z formatkami, 

− pasek statusu – wyświetlający dodatkowe informacje, takie jak: status połączenia z 

bazą danych, tryb pracy formatki (do odczytu, do modyfikacji), status danych 

(zmodyfikowane), ilość dostępnej pamięci, itp. 

Framework powinien w odpowiedni sposób reagować na zdarzenia: 

− otwarcia aplikacji: 

− odczyt konfiguracji aplikacji (np. położenie i rozmiar okna głównego), 

− próby zamknięcia aplikacji: 

− zapewnienie uzyskania potwierdzenia zapisania (lub anulowania zapisu) 

wszystkich niezatwierdzonych danych, 

− zapis konfiguracji systemu (np. rozmiaru i położenia okna aplikacji, otwartych 

formatek), itp. 

Konfiguracja aplikacji może obejmować: 

− wybór języka pracy aplikacji, 

− w przypadku aplikacji umożliwiających pracę z wieloma podmiotami gospodarczymi 

– wybór firmy (organizacji, wspólnoty mieszkaniowej), na danych której chcemy 

pracować, 

1 Kopiowanie rekordów reprezentujących dane strukturalne może wymagać wykonania bardziej 

złożonej procedury (np. kopiowanie nagłówka faktury, powinno skopiować również jej wiersze) – 

tego typu sytuacje powinny być realizowane przez odpowiednie rozszerzenia podstawowej 

funkcjonalności frameworku. 

111 



J. Frączek 

www.bdas.pl 

− ustalenie wyglądu aplikacji (skórka, ustalenie koloru obramowania, wnętrza, 

czcionki dla etykiet i zawartości pól wymaganych), 

− informacja o konfiguracji pozycji menu wstążek, zapis informacji o ostatnio 

używanych opcjach, 

− zapis informacji o rozmiarze i położeniu okna aplikacji przy ponownym 

uruchomianiu aplikacji, 

− zapis informacji o stanie aplikacji – informacje o rozmiarze i położeniu otwartych 

formatek aplikacji, które należy wyświetlić przy ponownym uruchamianiu aplikacji. 

Rys. 1. Ekran aplikacji zrealizowanej przy zastosowaniu biblioteki EALib 

2.2 Klasa formatki podstawowej 

Formatka podstawowa zapewnia obsługę standardowych funkcji związanych z obsługą 

formatki oraz podstawowych operacji bazodanowych. Operacje bazodanowe dotyczą 

znajdujących się na formatce kontrolek wizualnych (pól edycyjnych, tabel) powiązanych 

z obiektami bazy danych. W przypadku jawnego zatwierdzania danych przez użytkownika 

formatka podstawowa powinna umożliwiać obsługę następujących funkcji/przycisków 

(rys.1): 

− [Anuluj] – zamknięcie z wycofaniem niezapisanych zmian, 

− [Zastosuj] - zapis zmian bez zamknięcia okna, 

− [OK] - zapis zmian i zamknięcie okna, 

− [X] na belce tytułowej - zamknięcie okna, a jeżeli była zmiana, to zapytanie 

o zachowanie zmian (opcja dostępna również przez naciśnięcie przycisku ). 

112 




www.bdas.pl 

Framework powinien zapewniać dodatkowo: 

− obsługę procesu wstawiania danych: 

− automatyczne wyświetlenie wartości domyślnych, 

− automatyczne sprawdzenie warunku podania wartości dla pól wymaganych – 

w przypadku, gdy nie podano pola, pojawia się dialog: Pole [nazwa pola, np. 

z etykiety] jest wymagane. Proszę podać wartość pola. 

− automatyczne sprawdzenie warunku podania danych w odpowiednim formacie 

– w przypadku, gdy podano wartość niezgodną z wymaganym formatem pola, 

pojawia się dialog: Pole [nazwa pola, np. z etykiety] wymaga podania danych 

w formacie [format]. Proszę podać dane w prawidłowym formacie., 

− automatyczna weryfikacja więzów integralności, 

− obsługę procesu modyfikacji danych – podobnie jak w przypadku wstawiania danych 

– automatyczna obsługa weryfikacji pól wymaganych, formatów danych oraz 

więzów integralności, 

− obsługę procesu usuwania danych – automatyczna obsługa weryfikacji więzów 

integralności, 

− zapis konfiguracji formatki: 

− rozmiar i położenie formatki, 

− widoczność, rozmieszczenie pól (pozycja w tabeli), możliwość edycji, wartości 

domyślne pól formularzy oraz kolumn tabel, 

− możliwość przypisania do danej formatki: 

− domyślnej formatki szczegółów, 

− domyślnego raportu. 

2.3 Klasy (lub szablony) realizacji standardowych formatek aplikacji 

Framework powinien umożliwiać szybką implementację najczęściej pojawiających się 

w aplikacjach typów formatek: 

− kartoteka – wyświetlenie danych pojedynczego rekordu wraz z opisami 

pochodzącymi ze skojarzonych słowników, 

− lista – wyświetlenie tabeli z listą rekordów, 

− kartoteka z listą – wyświetlenie szczegółowych danych pojedynczego rekordu oraz 

lity rekordów z nim skojarzonych (rys.1): 

− obsługa danych pozostających w relacji 1:N, 

− obsługa danych pozostających w relacji M:N. 

− klasa słownika – wyświetlenie listy wartości słownika: 

− przekazanie wartości wybranej do pola wywołującego słownik, 

− zapewnienie możliwości wyboru kilku wartości, 

− przyciski [OK] – zatwierdzenie wyboru, [Anuluj] – rezygnacja z wyboru 

wartości (podobnie jak i zamknięcie formatki słownika przez przycisk [X]) 

Kwestią do rozważania jest umożliwienie edycji pozycji słownika, przy wyborze wartości. 

W systemach takich jak IFS Applications, Microsoft Dynamics NAV jest to dopuszczalne. 

2.4 Mechanizmy obsługi odczytu i edycji danych 

W obecnych na rynku systemach komercyjnych spotyka się różne rozwiązania w zakresie 

sposobu obsługi odczytu, edycji i zatwierdzania wykonanych przez użytkownika zmian: 

113 



J. Frączek 

www.bdas.pl 

− sposób otwarcia formatki 2 : 

− formatka pusta (domyślne w aplikacjach IFS Applications, Oracle Forms), 

− formatka wypełniona danymi (aplikacje Magic, Microsoft Dynamics Nav), 

− tryb otwarcia formatki: 

− w trybie tylko do odczytu, w celu edycji danych należy przełączyć się do trybu 

edycji, (Magic), 

− w trybie do edycji (IFS Applications, Microsoft Dynamics Nav), 

− sposób zatwierdzenia danych i zapisu zmian do bazy danych: 

− natychmiast po ich modyfikacji przez użytkownika (Magic, Microsoft 

Dynamics Nav), 

− po jawnym wskazaniu opcji zapisu przez użytkownika (IFS Applications, 

Oracle Forms), 

− sygnalizacja możliwości usunięcia danych (kontrola więzów integralności): 

− wyświetlenie odpowiedniego komunikatu w przypadku, gdy usunięcie danych 

nie jest możliwe, 

− sposób pracy ze słownikami: 

− umożliwienie/zabronienie edycji oraz usuwania danych ze słownika przy 

wywołaniu słownika, 

− umożliwienie wprowadzenia nowych danych do słownika przy wywołaniu 

słownika. 

Przy rozpatrywaniu zachowania się aplikacji należy rozważyć sposób reakcji aplikacji na 

zdarzenie równoczesnej modyfikacji danych przez więcej niż jednego użytkownika. 

Framework powinien wspierać obsługę wielodostępu, np. poprzez automatyczną 

sygnalizację zdarzenia tego typu (wyświetlenie odpowiedniego komunikatu) oraz 

akceptację zmian wprowadzonych tylko przez jednego z użytkowników. W celu realizacji 

powyższego założenia framework może wymagać np. określonej budowy obiektów w bazie 

danych (np. w przypadku zastosowania metody nazywanej optymistycznym blokowaniem 

(ang. optimistic locking) – dodanie do tabel kolumny znacznika czasowego). 

2.5 Filtrowanie i wyszukiwanie danych 

Dla każdej z zaprojektowanych formatek, framework powinien automatycznie dodawać 

możliwość definicji (tworzenia, modyfikacji, usunięcia) przez użytkownika dodatkowych 

warunków filtrowania danych. Z formatką można skojarzyć następujące rodzaje filtrów: 

− filtr „systemowy” – przechowujący warunki podane przez twórcę aplikacji (powinien 

on być nieedytowalny), 

− filtry użytkownika – nowe filtry zdefiniowane przez użytkownika na własne 

potrzeby, utworzone filtry tego rodzaju można udostępnić innym użytkownikom. 

Jeden z filtrów jest określony jako filtr domyślny i jest używany przy otwieraniu formatki. 

Użytkownik aplikacji powinien mieć możliwość szybkiego wyboru i zastosowania 

dostępnych filtrów, dlatego też proponuje się umieszczenie listy filtrów na pasku 

narzędziowym (rys.2). 

Dialog definicji warunków filtrowania powinien umożliwiać zdefiniowanie 

szczegółowych kryteriów jakie powinny spełniać wyświetlane dane – zarówno pod 

2 W niektórych systemach istnieje możliwość indywidualnego skonfigurowania każdej z formatek, 

przez określenie czy ma się otwierać z danymi. 

114 




względem zakresu danych jak i porządku ich sortowania. Jako typowe rozwiązania w tym 

obszarze można wskazać: 

− uniwersalny dialog definicji warunków filtrowania wyświetlający nazwy wszystkich 

pól występujących na formatce z możliwością przypisania każdemu z tych pól 

kryterium filtrowania 3 (rozwiązanie stosowane w aplikacjach IFS Applications, 

Microsoft Dynamics NAV) (rys.3), 

− dialog (lub para dialogów OD i DO) imitujący bieżącą formatkę aplikacji, w którego 

polach wpisuje się warunki filtrowania (rozwiązanie stosowane w aplikacjach 

Magic). 

Dla użytkowników zaawansowanych można udostępnić możliwość definicji filtru przez 

bezpośrednią specyfikację fraz SQL WHERE oraz ORDER BY. 

www.bdas.pl 

Rys. 2. Panel filtrów paska narzędziowego aplikacji zrealizowanej z użyciem biblioteki 

EALib. 

Rys. 3. Uniwersalny dialog definicji warunków filtrowania danych (w wersji angielskiej) 

3 Należy wziąć pod uwagę, że nie zawsze wyświetlane na formatce dane bezpośrednio pochodzą 

z tabel z bazy danych, np. wyświetlane w pojedynczym polu imię i nazwisko pracownika mogą tak 

naprawdę pochodzić z 2 kolumn w bazie danych. 

115 



J. Frączek 

www.bdas.pl 

W przypadku formatek (zwłaszcza zawierających tabele – jak dla formatek typu lista) 

powinna być dostępna opcja filtrowania danych poprzez prostą specyfikację warunku 

filtrowania (rys.2). Po wpisaniu warunku oraz wyborze przycisku filtrowana powinno 

nastąpić zawężenie liczby wyświetlanych rekordów do zbioru spełniającego zadane 

kryterium. Zadane warunki filtrowania dotyczą aktualnie wybranego pola formularza lub 

też aktualnie wybranej kolumny. Ponowne zastosowanie opcji filtrowania powinno dalej 

zawęzić zakres wyświetlanych danych. Użycie opcji wyczyszczenia filtru powinno 

przywrócić pierwotny widok danych (jak po wyborze filtru z listy). 

2.6 Pole tekstowe z listą wartości 

Pole tekstowe z przyciskiem wywołującym listę wartości (słownik) powinno mieć 

funkcjonalność podobną do kontrolki typu combobox, z tym, że rozwijaną listę opcji 

zastępuje standardowa formatka słownika. Dla pól typu data należy również zapewnić 

możliwość podłączenia kalendarza. Ciekawą opcją jest możliwość wpisania części wartości 

do pola i automatyczne sugerowanie (uzupełnianie) dalszej części wartości przez system 

(na podstawie wartości przechowywanych w słowniku). 

2.7 Tabela 

Cechy kontrolki typu tabela: 

− podświetlenie co drugiego wiersza tabeli wybranym kolorem, 

− podświetlenie komórek tabeli spełniających określone warunki (np. kwota



www.bdas.pl 

formatki, lub wyborze opcji odświeżenia danych) lub zatwierdzone dane (po wyborze opcji 

zapisu). Chwilą, w której następuje odświeżenie zawartości formatki może być: 

− zdarzenie aktywacji okna formatki (wybór/przejście na daną formatkę), 

− czas zdefiniowany parametrem aplikacji (okres odświeżania, np. 60s). 

Odświeżanie danych na formatkach może być również sterowane zdarzeniami, które 

zachodzą w systemie. 

2.11 Skróty klawiaturowe 

Należy dążyć do zgodności przyjętych skrótów z popularnymi aplikacjami, takimi jak 

Microsoft Office. Szkielet programistyczny powinien obsługiwać przynajmniej klawisze: 

− – zamknięcie formatki, 

− – wybór domyślnej akcji, 

Możliwe jest obsługa innych skrótów, takich jak – zapis zmian. 

Definicja przycisków w konfiguracji frameworku powinna skutkować respektowaniem 

przyjętych ustawień we wszystkich formatkach aplikacji. 

2.12 Automatyczna aktualizacja aplikacji 

Framework powinien udostępniać narzędzia pozwalające na określenie witryny WWW, 

z której można pobrać nowsze wersje aplikacji. Proces pobierania oraz instalacji poprawek 

powinien być konfigurowalny (np. możliwość włączenia oraz automatycznego pobierania 

poprawek – analogicznie jak w przypadku Windows Update). Zaleca się przynajmniej 

implementację funkcji informowania użytkownika o pojawieniu się nowej wersji aplikacji. 

2.13 Zintegrowany system bezpieczeństwa 

Podstawowe cechy systemu bezpieczeństwa można ująć w następujących wymaganiach: 

− identyfikacja oraz autoryzacja użytkowników: 

− zarządzanie hasłami, 

− możliwość integracji z usługami katalogowymi (LDAP, Active Directory), 

− obsługa grup użytkowników: 

− hierarchie grup (grupa może zawierać wiele innych grup oraz użytkowników, 

odwołania cykliczne nie są dozwolone), 

− możliwość integracji z usługami katalogowymi (LDAP, Active Directory), 

− definiowanie i kontrola uprawnień: 

− rodzaj uprawnień: 

− uprawnienia pozytywne, 

− uprawnienia negatywne, 

− uprawnienia do obiektów typu: 

− funkcje systemu, 

− pozycje menu (można powiązać z funkcjami systemu), 

− pola na formatce (też: kolumny wyświetlanych tabel), 

− uprawnienia do danych: 

− operacje: odczyt, wstawianie, aktualizacja, usuwanie, 

− zakres dostępnych danych (np. do określonego wydziału). 

117 



J. Frączek 

2.14 Formatki danych zlokalizowanych 

Wśród powszechnie występujących formatek słowników można wskazać słowniki: 

ustawień międzynarodowych, walut, krajów i jednostek. Cechy słowników: 

− słowniki wyświetlają dane zgodnie z ustawieniami regionalnymi języka 

użytkownika. 

− można ograniczyć liczbę pozycji wyświetlaną przez słowniki przy pracy z aplikacją 

do listy rzeczywiście używanych wartości (oznaczenie pozycji słownika flagą 

"używane w aplikacji" – rozwiązanie stosowane w IFS Applications). 

www.bdas.pl 

3 Biblioteka EALib 

W środowisku JBuilder (do wersji 2006) obecna jest biblioteka dbSwing dostarczająca – 

oparte na klasach Swing [6,7] – rozbudowane kontrolki automatycznie synchronizujące 

swój stan ze stanem obiektów bazy danych (dostępnej przez protokół JDBC)[8]. 

W przypadku umieszczanych na formatkach kontrolek wizualnych – takich jak pola 

edycyjne (JdbTextField), tabele (JdbTable), rozwijalne listy (JdbComboBox), etykiety 

(JdbLabel) – programista specyfikuje tylko kolumnę(y) źródła danych (QueryDataSet), 

które z kolei skojarzone jest z zapytaniem SQL odczytującym zawartość obiektu (tabeli, 

perspektywy) z bazy danych. Programista nie musi specyfikować poleceń SQL 

wstawiających (insert), modyfikujących (update), czy też usuwających (delete) rekordy 

z bazy danych – operacje te są realizowane automatycznie poprzez obiekty biblioteki 

dbSwing. 

Biblioteka EALib rozszerza możliwości klas dbSwing. W szczególności biblioteka 

zawiera następujące klasy: 

− klasa formatki podstawowej (JInternalFrameEA), 

− klasa formatki bazodanowej (JInternalFrameEAjb), 

− klasy słowników (JDialogLOV, JDialogTreeLOV), 

− klasa paska narzędziowego (JToolBarEAjb) z obsługą nawigacji po danych oraz 

obsługą filtrów, 

− klasa tabeli (JdbTableEA) o dużych możliwościach konfiguracji sposobu 

wyświetlania obiektu przez programistę oraz użytkownika, wraz z klasami edytorów 

i klasami sterującymi wyświetlaniem różnych typów danych, warunkowym 

wyświetlaniem koloru wybranych komórek tabeli i wyświetlaniem podsumowań, 

− klasa drzewa (JdbTreeEA) z zaimplementowaną obsługą źródeł danych, 

− klasa pola edycyjnego (JdbTextFieldEA) z obsługą zmian kolorów pola (np. 

w przypadku pola wymaganego, lub w przypadku pojawienia się błędu), 

− klasy pól edycyjnych z podpiętym słownikiem (JdbTextFieldWithLOV, 

JdbTextFieldWithLOVDate), 

− klasy obsługi konfiguracji okna aplikacji i formatek (StartupFrameConfig) oraz 

tabel (TableColumnConfig), 

− klasa dialogu (JDialogEA), 

− klasy weryfikujące wprowadzane wartości: InputVerifierForNumber, 

InputVerifierForBigDecimal, InputVerifierForDouble, InputVerifierForLong, 

InputVerifierForDate, InputVerifierForTime, InputVerifierForTimeFromLong 

(dla czasu przechowywanego w postaci sekund), 

118 




www.bdas.pl 

− klasa źródła danych (QueryDataSetEA) z możliwością obsługi relacji 1:N, przy 

automatycznym generowaniu unikalnych identyfikatorów przez bazę danych, 

mechanizmem zapisu i odświeżania zbiorów klas powiązanych relacjami, 

− obsługa formatek danych zlokalizowanych: krajów, jednostek miar, walut, 

− klasy eksportu danych do plików CSV oraz Excel (XLS). 

3.1 Przykład zastosowania biblioteki EALib 

Do realizacji formatki z rys.4 posiadającej pełną funkcjonalność związaną z edycją oraz 

wyszukiwaniem danych, należy napisać następujący kod: 

package pl.com.entapp.bpr; 

import com.ealib.gui.*; 

// oraz dodatkowe, wymagane deklaracje importu pakietów 

public class OperationStandardsList 

extends JInternalFrameEAjb { 

//deklaracja tabeli oraz obiektu obsługującego przewijanie danych 

TableScrollPane tableScrollPane1 = new TableScrollPane(); 

JdbTableEA tableOperationsStandards = new JdbTableEA(); 

//domyślny konstruktor 

public OperationStandardsList() { 

//specyfikacja wewnętrznego identyfikatora formatki, tytułu 

//oraz źródła danych 

super(FormId.OPERATION_STANDARDS_LIST.getId(), 

msgs.getString("OperationStandards.listFormLabel"), 

DMBPR.getDataModule().get_qds_operation_standards()); 

try { 

//konstrukcja elementów formatki 

jbInit(); 

} 

catch (Exception exception) { 

exception.printStackTrace(); 

} 

} 

//ustalenie konfiguracji kolumn tabeli 

tableBPROperationsStandards.setCustomColumnsDef( 

CommonCustomColumnDef.bprOperationStandards); 

//konstrukcja elementów formatki 

private void jbInit() throws Exception { 

//specyfikacja źródła danych tabeli formatki 

//funkcja getMainQDS wskazuje, że źródło podano w konstruktorze 

tableBPROperationsStandards.setDataSet(this.getMainQDS()); 

} 

} 

//ustalenie rozmiaru formatki i wyświetlenie tabeli 

this.setPreferredSize(new Dimension(700, 500)); 

tableScrollPane1.getViewport().add(tableBPROperationsStandards); 

this.getContentPane().add(tableScrollPane1, 

java.awt.BorderLayout.CENTER); 

119 



J. Frączek 

www.bdas.pl 

Rys. 4. Formatka z listą rekordów zrealizowana z wykorzystaniem biblioteki EALib 

4 Zakończenie 

Zastosowanie biblioteki EALib w znaczny sposób przyśpiesza tworzenie desktopowych 

aplikacji bazodanowych Java. Biblioteka EALib spełnia większość, spośród wymienionych 

w rozdziale wymagań, które powinien spełniać framework wspomagający tworzenie 

aplikacji. Wyjątkiem są tu: brak pełnej, zaproponowanej funkcjonalności zintegrowanego 

systemu bezpieczeństwa, brak obsługi informowania użytkowników o zmianach 

równocześnie, interakcyjnie edytowanych danych, brak mechanizmów automatycznej 

aktualizacji aplikacji. 

Firma Borland oraz spadkobierca rozwiązania JBuilder – firma CodeGear w najnowszej 

wersji środowiska JBuilder 2007 – w całości opartego na edytorze Eclipse – nie zawarła 

bibliotek dbSwing. De facto biblioteka ta od dłuższego czasu nie jest rozwijana. Błędne 

działanie niektórych komponentów dbSwing i niedoskonałości oryginalnej biblioteki 

zostały zastąpione i wzbogacone funkcjami biblioteki EALib. Lata doświadczeń 

związanych z użytkowaniem biblioteki EALib (w tym i wdrożenie komercyjnego systemu 

zarządzania procesami technologicznymi i produkcją ManagerPro) wskazują, że jest ona 

dobrym rozwiązaniem dla systemów o małej i średniej skali, pracującymi na danych 

o niezbyt dużym rozmiarze. Biblioteka umożliwia realizację aplikacji pracujących 

w architekturze klient-serwer. 

W przygotowywanej nowej wersji JDK7.0 planowane jest zawarcie specjalistycznego 

API dedykowanego do realizacji aplikacji Swing [11]. Szczególną uwagę należy zwrócić 

na projekty specyfikacji: JSR-295 Beans Binding [9] oraz JSR-296 Swing Application 

Framework [10]. Pierwszy z nich umożliwia powiązanie własności wizualnych kontrolek 

Swing (bardziej ogólnie – obiektów spełniających specyfikację JavaBeans) z własnościami 

innych obiektów aplikacji. W szczególności, łącząc API JSR-295 z mechanizmami 

mapowania obiektowo-relacyjnego (np. EJB3.0), możliwa jest bezpośrednia synchronizacja 

stanu kontrolek interfejsu graficznego z obiektami reprezentującymi encje bazy danych. Jak 

120 




www.bdas.pl 

zapewniają autorzy API JSR-295, będzie je można wykorzystać już z JDK5.0. Z kolei JSR- 

296 Swing Application Framework definiuje uniwersalny szablon tworzenia aplikacji 

opartych na komponentach Swing. Wykorzystanie możliwości obu pakietów przyspieszy 

tworzenie złożonych aplikacji Swing o dowolnej, wielowarstwowej architekturze. W chwili 

obecnej możliwe jest zastosowanie referencyjnych bibliotek obu specyfikacji. Ze względu 

jednak na fakt, że specyfikacje te nie wciąż podlegają zmianom, ich zastosowanie do 

tworzenia aplikacji jest utrudnione. 

Literatura 

1. Majewski D.: Moduł elektronicznej karty pracy dla systemu zarządzania procesami 

produkcyjnymi. Praca magisterska dyplomowa. Instytut Informatyki Politechniki Śląskiej, 

Gliwice, 2007. 

2. Andrzejewski T.: Moduł zarządzania raportami dla systemu zarządzania przedsiębiorstwem. 

Praca magisterska dyplomowa. Instytut Informatyki Politechniki Śląskiej, Gliwice, 2007. 

3. Kaczmarski J.: Moduł obsługi magazynu i obsługi zamówień dla systemu zarządzania 

przedsiębiorstwem. Praca magisterska dyplomowa. Instytut Informatyki Politechniki Śląskiej, 

Gliwice, 2006. 

4. Wilczek B.: System Organizacji i Monitorowania Procesów Produkcyjnych. Praca magisterska 

dyplomowa. Instytut Informatyki Politechniki Śląskiej, Gliwice, 2006. 

5. Matuszek M.: Java based Application for Company’s Own Cost Analysis for ERP Systems: 

Rekord.ERP and Symfonia. Praca magisterska dyplomowa. Instytut Informatyki Politechniki 

Śląskiej, Gliwice, 2006. 

6. Marinilli M.: Professional Java User Interfaces. John Wiley & Sons Ltd, 2006. 

7. Robinson M., Vorobiev P.: Swing. Second Edition. Manning Publications Co., 2003. 

8. JBuilder 2005. Developing Database Applications. Borland Software Corporation, 2004. 

9. JSR-295 Beans Binding, http://jcp.org/en/jsr/detail?id=295, dostęp: 08.02.2008. 

10. JSR-296 Swing Application Framework, http://jcp.org/en/jsr/detail?id=296, dostęp: 08.02.2008. 

11. Coward D., Reinhold M.: Mastering Mustang, Developing Dolphin. Prezentacja TS-3439. 

JavaOne Conference, 2006, http://developers.sun.com/learning/javaoneonline/2006/coreplatform 

/TS-3439.pdf, dostęp: 08.03.2008. 

121 



www.bdas.pl

pobierz plik referatu - Politechnika ÅlÄ ska

Create successful ePaper yourself

Delete template?

Save as template?

pobierz plik referatu - Politechnika ÅlÄska