plik

Rozdział 7

Projektowanie aplikacji w modelu
klient/serwer

Narzędzia Silverrun, wykorzystywane w przykładowych projektach z rozdziału 6,
7 i 8, są jednym z wielu produktów tego rodzaju, z których korzystać mogą
programiści używający Delphi. Wybór narzędzi Silverrun podyktowany był
wyłącznie preferencjami autora i nie oznacza rekomendacji firmy Borland dla tego
produktu.

W rozdziale 6 „Projektowanie baz danych w modelu klient-serwer” wymieniono
pięć procesów (albo etapów) tworzenia aplikacji do obsługi bazy danych. Poniżej
przypominamy listę tych procesów:

Zdefiniowanie przeznaczenia i funkcji aplikacji.

Zaprojektowanie bazy danych i

procesów aplikacji, niezbędnych do

zaimplementowania żądanych funkcji.

Przekształcenie projektu w

aplikację poprzez stworzenie bazy danych

i obiektów programu.

Testowanie aplikacji pod kątem zgodności z predefiniowanym przeznaczeniem

i zakresem realizowanych funkcji.

Instalacja aplikacji w docelowym środowisku pracy.

Rozdział 6 dotyczył przede wszystkim tych elementów powyższych procesów,
które związane były z projektowaniem baz danych. W niniejszym rozdziale
skupimy się na ich związkach z projektowaniem aplikacji. Projektowanie baz
danych i projektowanie aplikacji są ściśle ze sobą powiązane, dlatego trudno jest
jednoznacznie rozgraniczyć oba procesy. Ogół procesów projektowania aplikacji
do obsługi bazy danych można przedstawić w postaci tabeli o dwóch kolumnach
i pięciu wierszach. Jedna kolumna odpowiada projektowaniu bazy danych, druga -
projektowaniu aplikacji. Poszczególne wiersze reprezentują pięć formalnie
zdefiniowanych procesów, wymienionych powyżej. Można oczywiście posłużyć
się inną, odpowiednią analogią; należy jednak mieć na względzie fakt ścisłego
powiązania projektowania bazy danych i projektowania aplikacji.

Podejmiemy teraz dyskusję w punkcie, w którym przerwaliśmy ją w rozdziale 6.
W dalszej części niniejszego rozdziału znajdzie się omówienie pięciu formalnie
zdefiniowanych procesów projektowania aplikacji do obsługi baz danych.

216

Część I

UWAGA:

Istnieje wiele popularnych metodologii tworzenia aplikacji w modelu klient-
serwer. Metodologie te obejmują nie tylko modelowanie baz danych i programów,
lecz także cały proces definiowania i tworzenia wydajnych aplikacji do obsługi baz
danych klient-serwer. Wśród przykładów takich metod wymienić można metodę
Rational-Booch oraz metodę SAFE firmy Sybase. Mimo że omówienie tego
rodzaju metodologii wykracza poza zakres niniejszej książki, nie należy
rezygnować z zapoznania się z nimi. Problemy, związane z projektowaniem
aplikacji typu klient-serwer, nie kończą się na zagadnieniach dotyczących
interfejsu komunikacji z użytkownikiem. Wykraczają nawet poza zagadnienia
tworzenia baz danych lub ustalania relacji między obiektami. Najlepsi projektanci
systemów typu klient-serwer pracują w oparciu o ściśle zdefiniowaną metodologię,
obejmującą tworzenie, testowanie i przygotowanie aplikacji do użytku.
Niniejsza książka poświęcona jest, z

konieczności, przede wszystkim

modelowaniu baz danych i aplikacji. Zasady modelowania, zawarte w książce,
stanowią wybór najlepszych składników popularnych technik modelowania baz
danych i aplikacji, uzupełniony wnioskami z praktycznych doświadczeń autora.
Książka ma charakter bardziej praktyczny niż teoretyczny. Czytelnicy powinni
świadomie wybierać te metody, które im najbardziej odpowiadają. Jeśli okaże się,
że stosowanie określonej metodologii modelowania prowadzi do szybszego
tworzenia lepszych aplikacji, należy oczywiście taką metodologię wdrożyć i jej
przestrzegać.

Projektowanie bazy danych i procesów aplikacji

Po zdefiniowaniu podstawy systemu bazy danych przychodzi czas na stworzenie
procesów, koniecznych do zaimplementowania kluczowych funkcji aplikacji. Baza
danych pełni rolę fundamentu, na którym budowane są pozostałe elementy
aplikacji. Przed rozpoczęciem fazy tworzenia aplikacji, należy zatem - w miarę
możliwości - doprowadzić projekt bazy danych do ostatecznej postaci. Wszelkie
zmiany w bazie danych, dokonane już po stworzeniu aplikacji, mogą doprowadzić
do konieczności przeprojektowania lub przepisania obszernych fragmentów
programu.

Kilka uwag na temat tworzenia oprogramowania

Przed przystąpieniem do właściwego omówienia procesu projektowania aplikacji,
proponujemy zapoznanie się z kilkoma ogólnymi uwagami, dotyczącymi tworzenia
oprogramowania. Mają one charakter komentarza, pomogą jednak uzyskać
bardziej kompletny obraz całego procesu i ulokować w

nim poszczególne

czynności.

Projektowanie aplikacji w modelu klient/serwer

217

Nie istnieje „jedynie słuszna” droga tworzenia wszelkich aplikacji. Nie istnieje też
jeden system, odpowiedni do tworzenia wszelkiego rodzaju oprogramowania.
Podobnie jak dobry kucharz, który czasem dodaje ingrediencje „na wyczucie”,
a czasami według przepisu, autor aplikacji sam musi zadecydować, kiedy
postępować zgodnie z wiedzą książkową, a kiedy złamać niektóre reguły. Należy
zatem wypracować indywidualny sposób postępowania, dostosowany do potrzeb
i umiejętności twórcy oprogramowania oraz do charakteru tworzonych przezeń
aplikacji.

Tworzenie oprogramowania uważane jest dość powszechnie za dyscyplinę
naukową. Zgodnie z opinią niektórych jest to dyscyplina z pogranicza nauki
i sztuki, o dominującym pierwiastku naukowym. W

istocie, absolwenci

informatyki uzyskują tytuł magistra albo magistra inżyniera, a nie magistra sztuki.
Mimo to wiele przemawia za tym, by w tworzeniu oprogramowania dopatrywać
się nie dyscypliny naukowej, a raczej sztuki lub rzemiosła. Różnica między sztuką
a rzemiosłem sprowadza się do użyteczności uzyskanego produktu - efekty pracy
rzemieślniczej służą celom praktycznym, ich wartość nie kończy się na walorach
artystycznych.

Aby uzyskać pożądany rezultat twórca oprogramowania musi - podobnie jak
stolarz albo garncarz - przestrzegać pewnych reguł. Garncarz wie, że aby efekt
jego pracy nie rozpadł się, musi zastosować odpowiedni rodzaj gliny. Stolarz musi
sprawdzać, czy poszczególne elementy są proste i czy zachowane zostały
odpowiednie kąty. Reguły postępowania związane są jednak tylko z prawami
fizyki. Garncarz może stworzyć niemal dowolną formę naczynia nie łamiąc przy
tym żadnych zasad swego rzemiosła. Stolarz także może zbudować dowolny
przedmiot i

nadal pozostać dobrym stolarzem. Proces, realizowany przez

rzemieślnika, niezależnie od tego, czy wymaga użycia własnych rąk, młotka, igły,
czy narzędzi samodzielnie wytworzonych, nie ma sam w sobie większego
znaczenia. Istotą rzemiosła jest produkt, przedmiot, a nie środki użyte do jego
wytworzenia. Nie ma zatem „jedynie słusznej” drogi lepienia garnków. Nie
istnieje szczegółowa lista czynności, które rzemieślnik zawsze wykonuje, tworząc
przedmioty. Jakość produktu świadczy o umiejętnościach rzemieślnika; to samo
można powiedzieć o tworzeniu oprogramowania.

Dzisiejszy przemysł oprogramowania przypomina w pewnym stopniu przemysł
meblarski z

połowy dziewiętnastego stulecia. Meble wytwarzano wówczas

pojedynczo, w

warsztatach, w

których pracowali wysoko wykwalifikowani

rzemieślnicy. Każdy rzemieślnik budował swój mebel od początku do końca.
Meble były wytwarzane przy pomocy ręcznych narzędzi, z precyzją, która
stanowiła dla rzemieślnika powód do dumy - tak że umieszczał on swoje nazwisko
na każdym meblu. Inskrypcja ta była swego rodzaju osobistą gwarancją jakości.

Wraz z nadejściem rewolucji przemysłowej okazało się, że klej i nity wypierają
rzemiosło. Niska cena wyparła wysoką jakość. Wytwarzanie mebli odbywało się

218

Część I

teraz w oparciu o ciągły, zmechanizowany proces. Nie mogło być już mowy
o „tworzeniu” mebli - były one po prostu produkowane. Rzemieślników zastąpili
robotnicy na taśmie montażowej.

Niemal we wszystkich gałęziach przemysłu dominuje obecnie tendencja do
wytwarzania w oparciu o linie montażowe. Ma ona zarówno pozytywne, jak
i negatywne następstwa. To prawda, że większość produktów można obecnie
wytworzyć taniej niż kiedyś. Jaka jest jednak rzeczywista cena, którą przychodzi
nam płacić? Czy rzeczywiście otrzymujemy te same produkty taniej, czy może
uzyskujemy taniej tańsze produkty? I czy zanik prawdziwego rzemiosła podniósł
czy obniżył cenę produktów o najwyższej jakości?

Jaki związek mają powyższe rozważania z tworzeniem oprogramowania do obsługi
baz danych? Wystarczy przypomnieć, że rewolucja przemysłowa rozpoczęła się od
zredukowania rzemiosła do zwykłej, ręcznej pracy, którą wykonać mógł  każdy,
niezależnie od kwalifikacji. Właściwą pracę pozostawiono maszynom.
Doprowadziło to do obniżenia jakości produktów i niemal całkowitej eliminacji
nowatorstwa. Przemysł oprogramowania może spotkać ten sam los. Opinie
mówiące,  że istnieją „właściwe” i „niewłaściwe” sposoby tworzenia aplikacji,
w istocie  odbierają rzemieślnikowi prawo do sygnowania swoich produktów
własnym nazwiskiem. Zabijają kreatywność i ograniczają pole dla innowacji.
A przecież tworzenie oprogramowania powinno być przyjemnością. Powinno być
rzeczywiście procesem twórczym. Dlatego - zadaniem autora - nie ma „jedynie
słusznego” sposobu tworzenia oprogramowania, podobnie jak nie ma „jedynie
słusznego” sposobu lepienia naczyń albo obróbki drewna. Nie da się stworzyć
stałej listy kroków, których zrealizowanie doprowadzi każdorazowo do powstania
dobrej aplikacji. Rzemiosło tworzenia oprogramowania nie sprowadza się do
pisania programów „dobrze”, lecz do pisania dobrych programów.

Tworząc programy do obsługi baz danych, dobrze jest mieć na względzie
powyższe uwagi. Niniejszy i poprzedni rozdział celowo nie mają postaci opisu
kolejnych etapów, które należy szczegółowo realizować przy tworzeniu aplikacji.
Zasady tworzenia aplikacji, prezentowane w tej książce, są wyłącznie sugestiami.
Należy stosować te z nich, które okażą się przydatne dla Czytelnika, a pominąć te,
których przydatność stanie pod znakiem zapytania.

Wybór typu aplikacji

Pierwszym krokiem w projektowaniu procesów, tworzących aplikację, powinien
być wybór typu tworzonego programu. Aplikacje można podzielić na dwie
zasadnicze grupy: systemy przetwarzania transakcji i systemy wspomagania
decyzji. Najogólniej mówiąc, systemy wspomagania decyzji wykorzystywane są
przez kadrę kierowniczą i pozwalają uzyskać szersze spojrzenie na część danych
firmy. Systemy przetwarzania transakcji odpowiadają za wprowadzanie

Projektowanie aplikacji w modelu klient/serwer

219

i przetwarzanie tych danych. Aplikacje wspomagające decyzje muszą z reguły
tylko odczytywać dane. Systemy przetwarzania transakcji muszą zarówno
odczytywać, jak i zapisywać dane. Z uwagi na tę fundamentalną różnicę między
dwoma typami aplikacji, przed przystąpieniem do dalszych czynności konieczne
jest dokonanie wyboru jednego z nich.

Prezentacja procesów operacyjnych w formie graficznej

Przebieg każdego procesu aplikacji należy przedstawić w formie graficznej, jako
punkt wyjścia wykorzystując modele stworzone w fazie projektowania bazy
danych. Co najmniej kilka narzędzi CASE oferuje mechanizmy wspomagające
modelowania procesów aplikacji. W istocie wiele z tych narzędzi umożliwia
zbudowanie modeli aplikacji na modelach typu E-R i relacyjnych modelach
danych, opracowanych podczas projektowania obiektów bazy danych. Niektóre
narzędzia oferują możliwość bezpośredniej współpracy z Delphi. Należą do nich
programy Silverrun RDM i PowerDesigner (poprzednia nazwa - S-Designor)
AppModeler for Delphi. Należy pamiętać, że do modelowania elementów aplikacji
nie trzeba koniecznie używać narzędzi typu CASE. Niezależnie od przyjętej drogi
tworzenia modeli, należy dążyć do zrealizowania za ich pośrednictwem kilku
podstawowych zadań:

Zdefiniowania wszystkich formularzy, potrzebnych w aplikacji.

Zdefiniowania wszystkich raportów i

innych dokumentów wyjściowych,

generowanych przez aplikację.

Skojarzenia tych elementów z elementami danych, obecnymi w poprzednio

stworzonych modelach.

Zdefiniowania przejść między formularzami i

raportami oraz między

procesami.

Zdefiniowania wszelkich oddzielnych (nie należących do żadnego formularza

ani raportu), pomocniczych fragmentów programu, niezbędnych do
funkcjonowania aplikacji.

Rysunki 7.1 i 7.2 ilustrują kilka różnych modeli procesów aplikacji.

Projektowanie aplikacji w modelu klient/serwer

221

bywa różna w zależności od stosowanego narzędzia. Na przykład, program
Silverrun RDM wygeneruje zbiory atrybutów Delphi, których można później użyć
w aplikacji. Z kolei AppModeler for Delphi wygeneruje całą aplikację, w tym
formularze, raporty i kod pomocniczy. Na tej podstawie można dalej uzupełniać
aplikację.

Projektowanie hierarchii formularzy i raportów

Jeżeli zostało określone jakie formularze i raporty są wymagane prze aplikację,
pierwszym krokiem w budowie aplikacji będzie zaprojektowanie oddzielnych
hierarchii formularzy i raportów. Pozwoli to na wykorzystanie wsparcia jakie daje
Delphi dla dziedziczenia formularzy. To znaczy, że można utworzyć formularze
jako ogólne klasy - wywodząc jedne z drugich. Na przykład można zdefiniować
główny formularz w aplikacji, a następnie na jego podstawie (poprzez mechanizm
dziedziczenia) tworzyć pozostałe. Jeżeli następnie okaże się konieczna zmiana
jakiejś własności we wszystkich formularzach aplikacji, będzie można to wykonać
dokonując zmiany tylko w jednym miejscu. Powyższe uwagi odnoszą się również
do hierarchii raportów.

Wyszukanie przydatnych, niezależnie opracowanych elementów programu

Po ewentualnym wygenerowaniu szkieletu aplikacji należy podjąć próbę
wyszukania wszelkich bibliotek pomocniczych i

niezależnie opracowanych

elementów programu, które mogłyby okazać się przydatne. Jedną z popularnych
bibliotek, z której autor korzysta często w swoich aplikacjach, napisanych
w Delphi, jest Orpheus Visual Component Library firmy Turbo Power Software.
Wśród innych bibliotek wymienić należy Asynch Professional tej samej firmy.
Autorzy aplikacji, pracujący w większych zespołach, powinni skontaktować się
z kierownikami innych projektów lub menedżerami zasobów firmy i uzyskać
informacje o bibliotekach pomocniczych, które być może opracowano już
wcześniej, przy okazji poprzednich projektów. Decyzję o potrzebie zastosowania
określonych bibliotek pomocniczych dobrze jest podejmować na etapie wyboru
procesów, z którymi będą skojarzone formularze oraz tych, z którymi będą
skojarzone fragmenty programu nie komunikujące się z użytkownikiem. Zbytnie
odwlekanie decyzji o zastosowaniu biblioteki pomocniczej może w pewnym
momencie wstrzymać cały projekt w oczekiwaniu na zakup lub dostarczenie
odpowiednich narzędzi.

Ustalenie kolejności prac

Kolejnym etapem powinno być ustalenie kolejności prac nad poszczególnymi
formularzami i pomocniczymi fragmentami programu. Na planowaną kolejność
może mieć wpływ kilka czynników. Klient może na przykład wymagać

222

Część I

dostarczenia pewnych części aplikacji przed pozostałymi. Umowa może nakładać
na autora obowiązek tworzenia aplikacji w postaci niezależnych modułów,
instalowanych i wdrażanych oddzielnie. Klient może również zażyczyć sobie
wstępnych prezentacji określonych modułów. Ponadto obecność niektórych części
aplikacji może być warunkiem koniecznym dla funkcjonowania pozostałych jej
fragmentów. Przed przystąpieniem do tworzenia modułu kontrolującego wpływy
należności, konieczne będzie uruchomienie modułu księgi przychodów
i rozchodów. Wreszcie może się okazać, że przyjęcie określonej kolejności
tworzenia elementów programu usprawni dalszą pracę nad aplikacją, i tak na
przykład rozpoczęcie pracy od przygotowania głównego formularza aplikacji
umożliwi uruchamianie kolejno testowanych fragmentów za pośrednictwem
głównego menu.

Opracowanie kalendarza prac

Opracowywanie kalendarza prac nad projektem graniczy z czarną magią. Jest to
złożony proces, podlegający niezliczonym czynnikom. Komplikują go dodatkowo
wszelkie ograniczenia, narzucane przez kierownictwo i uwarunkowania pracy
zespołowej. Tematowi ustalania kalendarza prac nad projektem poświęcono wiele
osobnych książek. Z

uwagi na niemal nieograniczoną liczbę czynników

wpływających na opracowywanie kalendarza prac, pominiemy to zagadnienie
w niniejszej książce.

Tworzenie aplikacji

Następnym etapem jest już właściwe tworzenie aplikacji, zgodnie z ustaloną
kolejnością i kalendarzem prac. Sztuka pisania dobrze ustrukturalizowanego tekstu
programu wykracza poza zakres niniejszej książki. Należy podkreślić, że ostatnio
znacznie zmniejszyło się znaczenie tekstu programu, a to za sprawą narzędzi
programowania wizualnego, takich jak Delphi. Obecnie duże znaczenie
przywiązuje się do projektowania formularzy, któremu poświęcona będzie kolejna
sekcja.

Projektowanie formularzy

Sposób projektowania formularzy zależy w dużej mierze od typu tworzonej
aplikacji i typu formularzy w ramach tej aplikacji. W aplikacjach do obsługi bazy
danych w

modelu klient-serwer występują z

reguły trzy podstawowe typy

formularzy: formularze wspomagające decyzje, formularze przetwarzania
transakcji i formularze wprowadzania danych. Między wymienionymi typami
występują istotne różnice. Tym bardziej należy podkreślić konieczność
zdefiniowania typu formularza jeszcze przed przystąpieniem do projektowania go.

Projektowanie aplikacji w modelu klient/serwer

223

Zebrane poniżej uwagi można potraktować jako ogólne wskazówki projektowania
formularzy. Wiele z

nich ma charakter subiektywny i

Czytelnicy powinni

świadomie wybrać te spośród nich, które uznają za pomocne. Wskazówki
podzielono na cztery grupy. Pierwsza grupa dotyczy wszystkich formularzy, druga
- formularzy wspomagających decyzje, trzecia - formularzy przetwarzania
transakcji, wreszcie ostatnia - formularzy wprowadzania danych.

Należy zdecydować się na określony motyw graficzny aplikacji. Decyzja

o wyborze motywu powinna zapaść możliwie wcześnie. Wybrany motyw
będzie decydował o postaci graficznej wszystkich formularzy, wchodzących
w skład aplikacji. W świecie oprogramowania dla środowiska Windows
rozpowszechnione są co najmniej trzy popularne motywy, obowiązujące
odpowiednio w programach Corel PerfectOffice, Lotus SmartSuite i Microsoft
Office. Decydując się na motyw Corel PerfectOffice, autor aplikacji nadaje jej
wygląd zbliżony do programów Quattro Pro i WordPerfect. Motyw SmartSuite
zapewnia podobieństwo do programów Lotus 1-2-3 i WordPro. Z kolei wybór
motywu Microsoft Office oznacza naśladownictwo programów Word i Excel.
Na rysunkach 7.3, 7.4 i 7.5 przedstawiono wymienione tutaj przykłady
interfejsów użytkownika.

Rysunek 7.3.
Interfejs Corel
PerfectOffice.

Projektowanie aplikacji w modelu klient/serwer

225

niepotrzebnych funkcji to oczywista strata czasu autora aplikacji. Autor
programu powinien zawsze postawić się na miejscu użytkownika i spróbować
określić, jakie funkcje byłyby dla niego przydatne, a jakie - nie. Zbyt często
o zakresie funkcji aplikacji decydują specyficzne cechy języka programowania
lub dostępność atrakcyjnych elementów interfejsu. Funkcje aplikacji powinny
wynikać z potrzeb użytkownika.

Stworzenie oddzielnej hierarchii formularzy i

raportów umożliwi

wykorzystanie mechanizmu dziedziczenia formularzy, dostępnego w Delphi.
Należy zdefiniować formularz najwyższy w hierarchii, którego cechy będą
dziedziczone przez wszystkie formularze potomne. Jeśli w przyszłości zajdzie
potrzeba zmiany jakiegoś elementu wszystkich formularzy aplikacji, to być
może uda się ograniczyć zmiany wyłącznie do formularza nadrzędnego. Ta
sama zasada dotyczy hierarchii raportów. Większość raportów będzie zapewne
powstawać w

oparciu o

komponenty typu

QuickReport

, dostępne

standardowo w Delphi, dlatego wskazane jest utworzenie również hierarchii dla
formularzy raportów.

Bardzo istotne jest zachowanie wewnętrznej i

zewnętrznej spójności

w aplikacji. Spójność wewnętrzna obowiązuje w odniesieniu do różnych
formularzy tej samej aplikacji. Wewnętrzną spójność wspiera zastosowanie
przedefiniowanej hierarchii formularzy, wspomnianej w poprzednim punkcie.
Spójność zewnętrzna obowiązuje w odniesieniu do innych aplikacji. Właśnie
dlatego decyzja o

wyborze motywu interfejsu powinna zapadać jak

najwcześniej. Czcionki, kolory tła, wielkości elementów, lokalizacja pasków
narzędzi, itp. powinny odpowiadać nieformalnym standardom, przyjętym
w innych aplikacjach Windows, przeznaczonych do powszechnego użytku.

Należy budować formularze typu SDI, a nie MDI. Swego czasu preferowane

były formularze typu MDI (ang. multiple-document interface). Obecnie jednak
polityka firmy Microsoft uległa zmianie i zaleca się zachowanie zgodności
z konwencją SDI (ang. single-document interface). Jest to oczywiście bardzo
ogólne zalecenie i

bez wątpienia można wymienić wiele argumentów,

przemawiających za aplikacjami MDI. Jednak światowe trendy skłaniają -
przynajmniej na razie - do stosowania interfejsu SDI.

Informacje, należące do różnych klas, nie powinny pojawiać się na jednym

formularzu. Na przykład faktury i polecenia przelewu nie powinny być
wyświetlane w tym samym oknie. Formularz powinien być jak najprostszy.
Zazwyczaj należy unikać umieszczania na formularzu danych z więcej niż
jednego dokumentu źródłowego.

Należy korzystać ze standardowych pól dialogowych systemu Windows. Nie

ma sensu tworzenie własnych pól dialogowych do otwierania i zachowywania
plików, skoro system Windows oferuje gotowe pola. W środowisku Delphi

226

Część I

standardowe pola dialogowe Windows zostały „opakowane” w łatwe do
zastosowania komponenty, które wystarczy po prostu umieścić na formularzu.
W miarę możliwości należy zatem stosować te gotowe komponenty, co skróci
czas tworzenia programu i

ograniczy zużycie zasobów systemowych.

Komponenty, reprezentujące pola dialogowe, znaleźć można na stronie

Dialogs

palety komponentów Delphi.

Kolor tła formularzy powinien być neutralny (taki jak np. clBtnFace, który

standardowo odpowiada szarości). Należy natomiast unikać jaskrawych barw.
Zapewnia to formularzom profesjonalny wygląd, mniej męczy wzrok
i gwarantuje poprawną prezentację na większości kart graficznych i monitorów.

Jeśli aplikacja może pracować w różnych trybach, to do przekazania informacji

o aktualnie aktywnym trybie pracy należy wykorzystać paski narzędzi i grupy
przycisków typu

SpeedButton

. Przykładowo kliknięcie na przycisku

Dodaj

może spowodować przejście aplikacji w tryb dodawania, z kolei kliknięcie
przycisku

Raport

- przejście w tryb generowania raportu. Grupę przycisków

typu

SpeedButton

tworzy się, nadając niezerową wartość atrybutowi

GroupIndex

szeregu przycisków. W takim przypadku wskazane jest również

nadanie wartości

False

atrybutowi

AllowAllUp

. Tak zdefiniowany

przycisk po kliknięciu pozostanie wciśnięty, dopóki użytkownik nie kliknie
innego przycisku w tej samej grupie. W ten sposób zachowywały się przyciski
w starszych urządzeniach elektronicznych, np. radiach samochodowych. Jeśli
aplikacja może znajdować się w jednym z kilku wykluczających się trybów
pracy, to pogrupowane przyciski służą zarówno do zmiany trybu, jak i do
przekazania informacji o aktualnym trybie pracy. Możliwe jest programowe
„naciśnięcie” przycisku - należy nadać wartość

True

atrybutowi Down

odpowiedniego komponentu

SpeedButton

Miejsca na ekranie, w które użytkownik musi trafić wskaźnikiem myszy,

powinny być odpowiednio duże. Duże przyciski i pola wyboru sprawiają, że
użytkownikowi łatwiej jest poruszać się po aplikacji. Obsługa formularzy
pełnych mikroskopijnych kontrolek jest bardzo uciążliwa.

Każdy przycisk na formularzu powinien mieć swój odpowiednik w postaci

opcji menu. Należy również utworzyć pozycje menu, odpowiadające
poleceniom, które nie są dostępne wprost z formularzy. Dla osób, które ponad
korzystanie z myszy przedkładają obsługę programu z klawiatury, będzie to
istotnym ułatwieniem i przyczyni się do przyspieszenia pracy. Skojarzenie
klawiszy skrótów z opcjami menu aplikacji pozwoli na stosowanie jej razem
z programami do sterowania komputera za pomocą głosu; programy takie
zamieniają bowiem mówione polecenia na zdefiniowane uprzednio sekwencje
i kombinacje klawiszy.

Projektowanie aplikacji w modelu klient/serwer

227

Z najczęściej stosowanymi poleceniami w menu powinny być skojarzone

klawisze skrótów. Można również zdefiniować klawisz skrótu, który nie będzie
związany z żadną widoczną pozycją menu. Należy w tym celu utworzyć
tymczasową pozycję w menu, skojarzyć ją z żądanym klawiszem skrótu, po
czym w procedurze obsługi zdarzenia

OnClick

wpisać fragment programu,

wywoływany tym klawiszem. Następnie w oknie

Object Inspector

należy

przypisać atrybutowi

Visible

nowej pozycji wartość

False

. Spowoduje to,

że podczas wykonywania programu pozycja menu będzie niewidoczna. Mimo
to zdefiniowany klawisz skrótu pozostanie aktywny.

Najważniejsze pola formularza powinny być opatrzone etykietami ze

zdefiniowanym klawiszem skrótu. Klawisz skrótu dla etykiety definiuje się
w ramach atrybutu

Caption

komponentu

TLabel

- przed jednym ze znaków

w tekście etykiety należy wpisać dodatkowo znak

Wskazuje on, że następny

znak ma pojawić się jako podkreślony, a odpowiedni klawisz - pełnić rolę
skrótu do etykiety. Atrybut

FocusControl

etykiety powinien wskazywać na

komponent, który ma zostać uaktywniony po naciśnięciu klawisza skrótu.

Wszelkie kontrolki nawigacyjne powinny na wszystkich formularzach aplikacji

znajdować się w tym samym miejscu. Jeśli na jednym formularzu komponent

DBNavigator

umieszczony będzie u dołu, a na innym - u góry, to

użytkownik poczuje się zdezorientowany, a

aplikacja będzie sprawiała

wrażenie niekonsekwentnie zaprojektowanej. Kontrolki pełniące te same lub
podobne funkcje powinny na wszystkich formularzach znajdować się w tym
samym miejscu.

Do opisywania wszystkich przycisków należy stosować jednolitą czcionkę.

Interfejs użytkownika nie może być krzykliwy. Ewentualne trudności
z

odczytaniem etykiet i

opisów świadczą o

źle zaprojektowanej formie

graficznej aplikacji. Użytkownicy o wiele łatwiej zaakceptują zbyt duże
przyciski niż natłok kontrolek, zajmujących każdy wolny centymetr
kwadratowy ekranu.

Wiele osób uważa, że czcionki bezszeryfowe (takie jak Arial) są bardziej

czytelne niż szeryfowe (np. Times New Roman).

Należy jak najszerzej korzystać z mechanizmu podpowiedzi (ang. hints).

Podpowiedzi są niewielkimi (najczęściej żółtymi) etykietami, które pojawiają
się na ekranie, gdy użytkownik zatrzyma na chwilę wskaźnik myszy nad jakimś
istotnym elementem na ekranie. Podpowiedzi informują użytkownika o funkcji
danej kontrolki (w szczególności - przycisku paska narzędzi), nie zmuszając go
do jej uaktywniania.

Aplikacja powinna być wyposażona w system pomocy. Profesjonalne aplikacje

Windows zawierają kompletną bazę dokumentów pomocy, połączonych
odnośnikami do pokrewnych tematów. Formularze powinny być ponadto

228

Część I

wyposażone w system pomocy kontekstowej. Realizuje się go, nadając
odpowiednie wartości atrybutom

HelpContext

formularza i jego kontrolek.

Gdy użytkownik zażąda pomocy w chwili, gdy dana kontrolka jest aktywna,
system Windows automatycznie odnajdzie odpowiedni temat w

bazie

dokumentów pomocy. Więcej informacji na temat tworzenia plików pomocy
Windows znaleźć można w rozdziale 13 "Ostateczne poprawki".

Aplikacja powinna również zawierać formularz z informacjami o programie

(typu

AboutBox

), obejmujący nazwę programu, numer wersji i ewentualnie

nazwę firmy (producenta). Można także umieścić na nim numer telefonu
pomocy technicznej, informację o

prawach autorskich i

aktualne dane

wykorzystaniu zasobów Windows. Nazwę produktu, numer wersji

i informację o prawach autorskich należy dołączyć do aplikacji, korzystając
z zasobu VERSIONINFO. Zagadnienie dołączania takich danych do aplikacji
Delphi omówiono dokładniej w rozdziale 13.

Aplikację należy wyposażyć w pasek narzędzi. Stanowi on istotny element

wszystkich, wymienionych wcześniej, standardowych motywów interfejsu
użytkownika i

stosowany jest w

większości nowoczesnych aplikacji dla

Windows. Delphi oferuje dwa standardowe komponenty, służące do tworzenia
pasków narzędzi:

TToolBar

TCoolBar

. Paski narzędzi można również

tworzyć ręcznie, umieszczając przyciski

TSpeedButton

na komponencie

TPanel

Należy uwzględnić w

aplikacji pasek stanu. Można z

powodzeniem

wykorzystać komponent

StatusBar

, który reprezentuje standardowy pasek

stanu w systemie Windows 95.

StatusBar

dostępny jest na stronie Win32

palety komponentów Delphi.

Na formularzach, zawierających pola do wprowadzania danych, należy

zdefiniować pole domyślne (nadając jego atrybutowi

TabOrder

wartość

Aby zgromadzić dużą liczbę kontrolek na stosunkowo niewielkiej powierzchni

ekranu, należy zastosować komponenty typu

TabControl

PageControl

Jest to rozwiązanie zalecane obecnie dla aplikacji działających w środowisku
Windows 95. W programach firmy Borland korzystano z niego już od kilku lat.

Z aplikacją należy skojarzyć charakterystyczną ikonę. Ikona ta pojawiać się

będzie w oknie Eksploratora Windows i na liście aplikacji, wyświetlanej po
naciśnięciu klawiszy ALT+TAB. Dlatego powinna być rozpoznawalna
i ułatwiać odnalezienie aplikacji pośród innych programów. Aby skojarzyć
ikonę z aplikacją Delphi, należy skorzystać z opcji menu

Project\Options\

Application

Formularze powinny być projektowane z

myślą o

najniższej spośród

stosowanych przez użytkowników rozdzielczości ekranu. Jest to na ogół

Projektowanie aplikacji w modelu klient/serwer

229

rozdzielczość VGA, a zatem można bezpiecznie założyć, że formularz musi
funkcjonować przy rozdzielczości 640x480. Najlepszym rozwiązaniem jest
przełączenie własnego systemu na rozdzielczość 640x480 na czas
projektowania formularzy. Formularze o

zbyt dużych rozmiarach,

zaprojektowane dla większych rozdzielczości, na ekranie VGA zostaną po
prostu obcięte.

Na wszystkich formularzach należy używać jednolitej wielkości czcionki.

Wszystkie formularze powinny być zaprojektowane na takim samym systemie -
albo z wybraną małą czcionką o rozmiarze 96 dpi, albo z dużą czcionką
120

dpi. W

ramach jednej aplikacji nie należy stosować formularzy

zaprojektowanych przy różnych wielkościach czcionki systemowej. Należy
także zwrócić uwagę, że automatyczne dostosowanie formularza do większej
czcionki daje na ogół lepszy efekt niż jego automatyczne pomniejszenie,
mające na celu dostosowanie do mniejszej czcionki. Dlatego formularze
zaprojektowane czcionką 96 dpi będą zwykle wyglądały poprawnie po
zainstalowaniu w

systemie z

czcionką 120 dpi, natomiast formularze

zaprojektowane w czcionce systemowej 120 dpi nie prezentują się dobrze po
zainstalowaniu aplikacji w systemie z małymi czcionkami. Aby wyłączyć
automatyczne skalowanie formularzy należy nadać atrybutowi

Scaled

wartość

False

(domyślnie przyjmowana jest wartość

True

). Z kolei jeśli

formularz ma być automatycznie skalowany - co jest zalecanym rozwiązaniem -
należy nadać wartość

False

atrybutowi

AutoScroll

. Również temu

atrybutowi nadawana jest domyślnie wartość

True

, mimo że powoduje to

konflikt z mechanizmem automatycznego skalowania.

Aplikacja powinna być tak zaprojektowana, aby w większości przypadków

sposób jej obsługi był oczywisty. Użytkownik nie powinien być zmuszany do
zbyt częstego sięgania po podręcznik lub pomoc dostępną w programie.

Projektowane formularze powinny być jak najwcześniej prezentowane

klientom, którzy zweryfikują koncepcję komunikacji z

użytkownikiem,

zaproponowaną przez autora programu. Do takich prezentacji można
z powodzeniem wykorzystać środowisko Delphi. Praktyka dowodzi, że
możliwe jest nawet projektowanie formularzy przy aktywnym współudziale
przyszłych użytkowników.

Formularze wspomagające podejmowanie decyzji

Z formularzy wspomagających podejmowanie decyzji korzystają na ogół osoby
dysponujące stosunkowo szerokim zakresem władzy w ramach danej instytucji.
Z drugiej strony umiejętności tych użytkowników w zakresie obsługi komputera
plasują się zwykle poniżej poziomu umiejętności pozostałych użytkowników.
Omawiana grupa pełni określoną rolę w procesie decyzyjnym, dlatego potrzebuje
programów wspomagających właśnie podejmowanie decyzji. Zgodnie z zasadą

230

Część I

prezentowaną w

książce Scotta Adamsa The Dilbert Principle, poziom

umiejętności obsługi komputera jest odwrotnie proporcjonalny do pozycji
w strukturze kierowniczej. Dlatego formularze wspomagające decyzje powinny
być proste, a

jednocześnie przekazywać jak najwięcej dobrze dobranych

informacji. Zaprojektowanie takiego formularza nie jest banalnym zadaniem.
Poniżej zebrano kilka sugestii:

Formularz powinien zajmować prawie cały ekran. Typowy menedżer ceni sobie

uproszczoną i bardzo przejrzystą prezentację danych. Użytkownicy, należący
do tej grupy, stosunkowo rzadko uruchamiają jednocześnie więcej niż jedną
aplikację Windows. Dlatego zaleca się wykorzystanie całej dostępnej
powierzchni ekranu.

Należy unikać umieszczania na formularzu dużej ilości danych szczegółowych

i zestawień tabelarycznych. Formularz powinien być prosty. Menedżer chce
znać wyłącznie fakty - podane w sposób prosty i estetyczny, jednak bez
zbędnych ozdobników. Nie ma sensu prezentowanie dużych ilości danych
transakcyjnych, gdyż zazwyczaj nie interesują one użytkowników omawianego
typu formularzy.

Do prezentacji wzajemnych zależności danych należy jak najszerzej stosować

wykresy. Niektórzy użytkownicy uważają wykresy za najefektywniejszy środek
do zbiorczej prezentacji dużych ilości danych. Jeśli użytkownik gotów jest
zrezygnować z surowych wartości liczbowych na rzecz prezentacji graficznej,
należy bez wahania stosować wykresy, które nadają aplikacji bardzo
profesjonalne oblicze, a jednocześnie nie wymagają dużego nakładu pracy ze
strony autora programu. Użycie wykresów nie powinno jednak zamykać
dostępu do właściwych, surowych danych, tak aby nie było konieczne
odczytywanie wartości liczbowych z wykresu. Dostęp do właściwych danych
wykresu można zrealizować korzystając z

komponentów typu

DecisionCube

, dostępnych w Delphi.

Jeśli aplikacja ma tylko odczytywać dane, a nie zezwala na zapis, to

formularza powinny zniknąć wszelkie listy i

elementy, wspomagające

wprowadzanie danych. W

aplikacjach, przeznaczonych wyłącznie do

przeglądania danych, nie należy stosować narzędzi do ich wprowadzania
(takich jak kontrolki

DBListBox

lub

DBLookupComboBox

). Można je

zastąpić komponentami typu

DBText

lub nawet

TLabel

, które zużywają

mniej zasobów systemowych, a równie dobrze nadają się do prezentacji
danych.

Dostęp do danych powinien być kontrolowany z poziomu serwera bazy danych

lub serwera sieciowego - należy unikać mechanizmów kontrolnych,
wbudowanych w samą aplikację. Użytkownicy, szczególnie wywodzący się

Projektowanie aplikacji w modelu klient/serwer

231

z kadry kierowniczej, nie najlepiej reagują na komunikaty informujące o braku
uprawnień i dostępu do określonej funkcji programu.

Z aplikacji należy usunąć (lub skutecznie w niej ukryć) wszelkie funkcje, do

których użytkownicy nie mają dostępu. Oznacza to, że należy zrezygnować
z nieaktywnych (wyświetlanych w

kolorze szarym) opcji menu oraz

przycisków. Ich obecność może zdezorientować niedoświadczonych
użytkowników. Jeśli w aplikacji, wspomagającej podejmowanie decyzji, któraś
z opcji jest niedostępna dla użytkownika, to należy ją całkowicie usunąć albo
nadać jej atrybutowi

Visible

wartość

False

. Spowoduje to ukrycie opcji.

Formularze interaktywne

Formularze interaktywne spotyka się niemal tak często, jak formularze do
wspomagania decyzji. Formularze interaktywne są standardowym narzędziem
wprowadzania, edycji i usuwania danych. Ich typowy użytkownik dysponuje
szerszymi umiejętnościami w

zakresie obsługi komputera niż użytkownicy

wywodzący się z kadry kierowniczej. Z formularzy interaktywnych korzystają
pracownicy administracyjni, operatorzy komputerów i - ogólnie - urzędnicy.

Oto wybrane wskazówki, dotyczące konstruowania formularzy interaktywnych:

Należy rozważyć możliwość uzupełnienia bądź zastąpienia przycisków

komponentu

DBNavigator

standardowymi przyciskami. Komponent ten

oferuje dużo możliwości i jest prosty w użyciu, brakuje mu jednak kilku
podstawowych funkcji, takich jak mechanizm wyszukiwania danych
i możliwość przypisywania wbudowanym przyciskom etykiet i

klawiszy

skrótów. W rozdziale 27, pokazano, w jaki sposób stworzyć można wzorzec
komponentu, zastępującego kontrolkę

DBNavigator

Kontrolki należy pogrupować, tak aby ułatwić obsługę formularza. Położenie

kontrolek powinno sprzyjać logicznemu i zgodnemu z intuicją wyborowi.
Elementy logicznie ze sobą powiązane należy umieszczać w bezpośrednim
sąsiedztwie. Skojarzone pola wyboru i przyciski powinny znajdować się obok
siebie. Takie rozmieszczenie kontrolek sprzyja szybkiemu poznaniu formularza
i pozwala uniknąć wielu błędów obsługi.

232

Część I

WSKAZÓWKA:

W charakterze lektury uzupełniającej, poświęconej ujednoliconemu interfejsowi
Windows, polecić można książkę It's Time To Clean Your Windows: Designing
Guis that Work, autorstwa Wilberta O. Galitza (John Wiley & Sons, ISBN 0-471-
60668-5). Zawiera ona szereg szczegółowych zaleceń, dotyczących czytelnego
i

funkcjonalnego rozmieszczania kontrolek. Wśród poruszanych zagadnień

znalazło się także zastosowanie fiszek (obiektów typu

TabControl

konfiguracja czcionek i

wiele innych problemów, dotyczących graficznego

interfejsu użytkownika.

Z przyciskami poleceń i polami do wprowadzania danych należy skojarzyć

klawisze skrótów. Dla osób, które chętnie korzystają z klawiatury, klawisze
skrótów są nieodzownym elementem interfejsu użytkownika. O wyborze
klawiszy powinny decydować funkcje skojarzonych kontrolek, a nie ich
położenie na formularzu. Przyciski mają pierwszeństwo przed etykietami. Jeśli
na przykład w górnej części formularza znajduje się pole, którego etykieta
rozpoczyna się literą D, a u dołu znajduje się przycisk

Dodaj

, to klawisz skrótu

ALT+D należy skojarzyć z

przyciskiem, a

nie z

etykietą. Jest bardziej

prawdopodobne, że użytkownik zechce użyć klawisza do uaktywnienia
przycisku niż że będzie chciał w ten sposób przejść do pola na początku
formularza.

Kolejność przechodzenia między kontrolkami klawiszem TAB powinna być

przemyślana i logiczna. Formularz należy zaprojektować w ten sposób, aby
klawisz TAB przenosił użytkownika między kolejnymi kontrolkami,
w logicznym porządku, od lewej do prawej strony i z góry na dół.

W razie potrzeby należy wykorzystać atrybut

Kind

komponentów

TBitBtn

i zdefiniować przyciski

Cancel

(Anuluj). Przycisk

staje się

automatycznie domyślnym przyciskiem formularza - jego atrybut

Default

przyjmuje wartość

True

. Oznacza to, że po zakończeniu edycji bieżącego

rekordu użytkownik będzie mógł nacisnąć ENTER; a do anulowania edycji
będzie można użyć klawisza ESC.

Przyciski poleceń można zastąpić lub uzupełnić dodatkowym menu,

pojawiającym się na ekranie po naciśnięciu prawego klawisza myszy.
Niektórzy użytkownicy bardzo chętnie korzystają z tego rodzaju menu.
Wprowadzenie omawianego udogodnienia w aplikacjach Delphi jest niezwykle
proste.

Formularze do wprowadzania danych

Formularze tego rodzaju używane są zazwyczaj do żmudnej czynności, jaką jest
wprowadzanie danych do bazy. W tym przypadku kluczową rolę odgrywa

Projektowanie aplikacji w modelu klient/serwer

233

szybkość obsługi, mniej ważna jest natomiast estetyka formularza, dostępność
podpowiedzi i tym podobne udogodnienia. Omawiane formularze są zwykle dość
oszczędnie zaprojektowane i

zawierają tylko najistotniejsze elementy. Ich

użytkownikiem jest na ogół operator, skupiający swą uwagę przede wszystkim na
dokumentach źródłowych, a

nie na ekranie. W

obsłudze formularzy do

wprowadzania danych szczególną rolę odgrywa klawiatura, korzystanie z myszy
wymaga bowiem spoglądania na monitor.

Poniższa lista zawiera wskazówki, które być może okażą się pomocne przy
projektowaniu formularzy do wprowadzania danych:

W polach tekstowych należy używać czcionki pogrubionej, o stałej szerokości

znaków. Czcionki o stałej szerokości znaków są bardziej czytelne, choć
z drugiej strony zajmują więcej miejsca na ekranie. Jeśli kluczowym kryterium
przy projektowaniu formularza jest szybkość, należy używać czcionki
nieproporcjonalnej. Czytelność napisów zwiększa także pogrubienie czcionki.

Z formularza należy usunąć zbędne przyciski i pola. Na formularzu nie ma

miejsca na kontrolki, które nie będą wykorzystywane przy szybkim
wprowadzaniu danych. Na przykład, jeśli wiadomo, że użytkownik nigdy nie
będzie zmuszony do wyszukiwania numeru konta, to należy usunąć
z formularza przycisk, wywołujący tę funkcję. Te same elementy, które
w zwykłych formularzach stanowią cenne udogodnienia, przy wprowadzaniu
dużej ilości danych będą tylko przeszkadzać.

Komponenty

DataSet

, powiązane z kontrolkami na formularzu, powinny być

kojarzone ze sobą przy wykorzystaniu mechanizmu typu nadrzędny/podrzędny
(master/detail), dostępnego w Delphi. Nie należy wymagać od użytkownika
uaktywniania przycisku lub wykonywania jakiejkolwiek innej czynności celem
przejrzenia danych podrzędnych, skojarzonych z pozycją nadrzędną. Tabele
powinny być skojarzone za pośrednictwem odpowiednich atrybutów, tak aby na
ekranie następowała ich automatyczna synchronizacja.

Klawisze skrótów powinny być tak dobrane, aby ich naciśnięcie nie wymagało

akrobatycznych wyczynów. Klawisze należy dobierać na podstawie częstości
użycia, a nie położenia skojarzonych z nimi elementów. Jeśli dwóm kontrolkom
odpowiada ten sam, łatwy do skojarzenia klawisz, to należy go przypisać
kontrolce częściej używanej, a nie koniecznie tej, która występuje na
formularzu jako pierwsza. Rzadko używanej kontrolce należy przypisać inny
klawisz skrótu.

Standardowym przyciskiem powinien być przycisk

Dodaj

, a

nie

W przeciwieństwie zwykłych formularzy do przetwarzania danych
transakcyjnych, omawiane formularze przeznaczone są w zasadzie wyłącznie
do dodawania rekordów. Dodanie kilku kolejnych rekordów odbędzie się

234

Część I

znacznie szybciej, jeśli domyślnym przyciskiem na formularzu będzie właśnie
Dodaj, powodujący dopisanie danych do bazy.

Formularze do wprowadzania danych powinny być jak najmniejsze. Umożliwia

to okresowe zmiany ich położenia na ekranie, a to z kolei odciąża wzrok
operatora. Operatorzy, wprowadzający dane, będą spoglądać przede wszystkim
na dokumenty źródłowe, dlatego okno formularza na ekranie powinno po
otwarciu przyjąć standardowy rozmiar (a nie otwierać się jako maksymalnie
powiększone).

Projektowanie raportów

Temat projektowania raportów omawia szczegółowo Rozdział 19. Poniżej zebrano
szereg ogólnych wskazówek, dotyczących tego zagadnienia:

Gdy tylko jest to możliwe, raporty należy projektować przy wykorzystaniu

komponentów

QuickReport

, dostępnych w

Delphi. W

porównaniu

z wszelkimi zewnętrznymi narzędziami do tworzenia raportów, komponenty

QuickReport

są prostsze w konfiguracji i użyciu, gdyż stanowią integralną

część aplikacji. Aby wygenerować raport w

oparciu o

komponent

QuickReport

nie trzeba opuszczać głównego programu i uruchamiać

zewnętrznego narzędzia.

Raporty o dużym stopniu komplikacji, których nie da się zrealizować przy

użyciu komponentów

QuickReport

, należy w miarę możliwości tworzyć

graficznym edytorze raportów. Popularne programy tego rodzaju to

ReportSmith, R&R SQL Report Writer for Windows i Crystal Reports.
Narzędzia graficzne umożliwiają użytkownikom wykorzystanie raportów,
dostarczanych z aplikacją, jako podstawy do tworzenia własnych - nie wymaga
to modyfikowania programu źródłowego aplikacji.

Jeśli wykorzystywana platforma systemowa dopuszcza stosowanie procedur

pamiętanych, to właśnie w nich (a więc na serwerze) powinna być realizowana
większość czynności, związanych z generowaniem raportu. W prawidłowo
zaprojektowanej aplikacji typu klient-serwer większość działań wykonuje
serwer bazy danych. Użycie procedur pamiętanych ułatwia ponadto testowanie
mechanizmów raportu, odpowiedzialnych za pobieranie danych z bazy. Testy
takie można wykonać poza środowiskiem do graficznego projektowania
raportu. Wreszcie wykorzystanie procedur pamiętanych zapewnia oddzielenie
funkcji pobierania danych od funkcji ich prezentacji, a to z kolei ułatwia
ewentualną zmianę narzędzia do projektowania raportów albo pobieranie
danych raportu bezpośrednio przez aplikację.

Jeśli raporty generowane są przez procedury pamiętane, to wywołania tych

procedur należy rejestrować na serwerze bazy danych. Można to zrealizować

Projektowanie aplikacji w modelu klient/serwer

235

przy użyciu usług śledzenia danych i operacji serwera (o ile dany serwer
oferuje takie usługi) albo samodzielnie stworzyć podprogramy, rejestrujące
wywołania. Aktualizacja rejestru operacji serwera odbywa się w takim
wypadku zarówno przed, jak i po wykonaniu procedury. Rejestrowanie
wywołań pozwala uzyskać cenne informacje o wydajności generowania
raportów, a

także o

częstotliwości i

czasie sporządzania poszczególnych

raportów przez użytkowników. Poniżej przedstawiono polecenie utworzenia
przykładowej procedury rejestrującej. Polecenie zapisane jest w dialekcie
Transact-SQL (używanym w systemach Sybase i Microsoft SQL Server):

CREATE PROCEDURE reportlog @StartEnd char(6),@ReportName

➥

char(30) as

insert into REPORTLOG
select @StartEnd, getdate(), suser_name(), @ReportName

Przygotowaną procedurę można wywoływać w następujący sposób:

/*
Zarejestruj pocz

ątek procedury raportu

*/
exec reportlog 'STARTED','MAINTENANCE REPORT BY WORK TYPE'
/*

Wykonaj właściwą procedurę

*/
...
/*

Zarejestruj zakończenie procedury raportu

*/
exec reportlog 'ENDED', 'MAINTENANCE REPORT BY WORK TYPE'

WSKAZÓWKA:

Niektóre systemy zarządzania bazami danych oferują gotowe mechanizmy
monitorowania procedur pamiętanych. Mechanizm dostępny np. w systemie
Sybase SQL Server pozwala uzyskać w zasadzie te same informacje, jakich
dostarcza prezentowana powyżej procedura.

W nagłówku strony raportu należy umieścić wewnętrzną nazwę raportu,

aktualną datę i godzinę oraz identyfikator użytkownika, sporządzającego raport.
Informacja o dacie i godzinie pozwala odróżnić poszczególne wersje raportu
i określić jego wiek, jeśli między sporządzeniem raportu a jego analizą upłynął
dłuższy czas. Wewnętrzna nazwa raportu umożliwia z kolei zlokalizowanie
jego "tekstu źródłowego", jeśli zajdzie konieczność wprowadzenia modyfikacji.
Identyfikator użytkownika informuje, do kogo należy się zwrócić celem
przedyskutowania ewentualnych problemów. Na rysunku 7.6 przedstawiono
prawidłowo zaprojektowany nagłówek raportu.

236

Część I

W nagłówku strony należy także wyszczególnić wszystkie kryteria, jakie

zastosowano przy umieszczaniu danych w

raporcie. Jeśli użytkownik

wprowadził graniczne daty albo inne kryteria wpływające na zawartość raportu,
to powinny one znaleźć się w nagłówku. Kryteria zadane przez użytkownika
mogą spowodować pominięcie części danych w raporcie. Jeśli nagłówek nie
będzie zawierał wystarczających informacji, to odbiorca raportu może
dopatrywać się pomyłki lub wyciągnąć błędne wnioski z analizy. Problem ten
jest odczuwalny zwłaszcza w sytuacji, gdy między sporządzeniem raportu
a jego analizą upływa dłuższy czas. Nagłówek, widoczny na Rysunku 7.6,
zawiera kryteria doboru danych do raportu.

Nagłówki powinny być zapisywane czcionką proporcjonalną, a dane - czcionką

o stałej szerokości. Czcionki proporcjonalne poprawiają estetykę raportu
i pozwalają w pełni wykorzystać możliwości nowoczesnych drukarek, którymi
dysponuje obecnie większość użytkowników. Odróżniają ponadto raporty
sporządzone przy użyciu współczesnych systemów, działających w oparciu
o komputery PC, od odpowiednich dokumentów wygenerowanych przez starsze
systemy komputerowe poprzedniej generacji. Niestety, czcionki proporcjonalne
nie nadają się do zapisywania danych tabelarycznych, gdyż nie pozwalają na
wyrównywanie kolumn. Cyfra 1 może w druku okazać się węższa niż np. 5. Do
zapisu danych liczbowych w kolumnach należy zatem stosować czcionki
o stałej szerokości. Jako przykłady czcionek proporcjonalnych, odpowiednich
do użycia w nagłówku, wymienić można Arial i Times New Roman. Z kolei
typową czcionką o stałej szerokości, używaną w głównej części raportu, jest
Courier New.

Rysunek 7.6.
Prawidłowo
zaprojektowany
raport.

Projektowanie aplikacji w modelu klient/serwer

237

Jeśli w raporcie mają znaleźć się napisy podkreślone, to należy zastosować

odpowiedni atrybut czcionki, a nie jakiekolwiek inne środki zastępcze. Wiele
edytorów raportów umożliwia uzupełnianie tekstu elementami graficznymi,
takimi jak linie i prostokąty. Wykorzystanie tych możliwości do uzyskania
podkreślenia niepotrzebnie zwiększa zapotrzebowanie na pamięć drukarki
i czas generowania raportu. Linie traktowane są bowiem jako elementy
graficzne.

Inną powszechną praktyką, wywodzącą się z czasów drukarek wierszowych, jest

uzyskiwanie efektu podkreślenia przy pomocy znaku _. Rozwiązanie to
pochłania dodatkowe wiersze, gdyż podkreślenie drukowane jest
w rzeczywistości w oddzielnej linijce, poniżej właściwego napisu. Ponadto
w przypadku zastosowania czcionki proporcjonalnej trudno jest uzyskać żądaną
długość linii, dokładnie odpowiadającą szerokości kolumny.

Liczby o charakterze wartości (kwoty, ilości, itp.) należy wyrównywać do

prawej strony. Liczby, które pełnią rolę identyfikatorów (numery faktur, itp.),
powinny być wyrównane do lewej.

Do wyróżnienia niektórych elementów raportu wykorzystać można

zaawansowane funkcje formatowania wydruku, takie jak cieniowanie
i pogrubienie czcionki. Nie ma powodu, aby rezygnować z możliwości
oferowanych przez współczesne drukarki. Ich pełne wykorzystanie poprawi
estetykę raportu. Drukarki stosowane powszechnie jeszcze kilka lat temu nie
dysponowały wieloma funkcjami, które w dzisiejszych urządzeniach tego typu
uznawane są za standardowe. Należy jednak zwrócić uwagę na dostosowanie
postaci graficznej raportu do rzeczywistych możliwości drukarki używanej
przez klienta.

Projektowane raporty należy jak najwcześniej prezentować klientom, którzy

zweryfikują koncepcję merytoryczną i graficzną, zaproponowaną przez autora
aplikacji. Raporty mogą być - podobnie jak formularze Delphi - projektowane
przy aktywnym współudziale przyszłych użytkowników. Pozwala to zmniejszyć
ryzyko nieporozumień i uniknąć ewentualnych przeróbek.

Testowanie aplikacji pod kątem zgodności z zakładanym
przeznaczeniem i zakresem funkcji

Tematowi testowania aplikacji i kontroli jakości oprogramowania można by
poświęcić oddzielne opracowanie. Poniżej zaprezentowano jedynie niewielki zbiór
sugestii, dotyczących testowania tworzonych aplikacji:

Zgłaszanie wszelkich anomalii, wykrytych podczas testowania i użytkowania

aplikacji, powinno odbywać się zgodnie z formalną, zdefiniowaną uprzednio
procedurą. Powszechnie stosuje się w tym celu specjalne formularze, a nawet

238

Część I

niewielkie aplikacje. Każde zgłoszenie powinno być opatrzone numerem
i zawierać opis czynności, które należy wykonać, aby wywołać anomalię.
Należy też każdorazowo zaznaczać rodzaj zgłoszenia (informacja o błędzie,
sugestia lub zapytanie) oraz zapisywać odpowiedź autora (autorów) programu
na zgłoszenie.

Należy przygotować mechanizm prostego i sprawnego rozsyłania uaktualnień

i poprawionych wersji programu. Jedna ze sprawdzonych metod opiera się na
zastosowaniu niewielkiej aplikacji, która uruchamiana jest automatycznie
z folderu Autostart systemu Windows na komputerze użytkownika. Aplikacja
taka porównuje datę i godzinę utworzenia pliku wykonywalnego na lokalnym
dysku z datą i godziną pliku na serwerze sieciowym lub serwerze dostępnym
przez linie komutowane. Jeśli lokalna wersja okaże się nieaktualna, to program
automatycznie zastąpi ją nową wersją.

Wszystkie wersje aplikacji powinny być numerowane. Aplikacja powinna na

żądanie wyświetlać numer wersji. Poboczny numer wersji należy zwiększać
wraz z każdym rozesłanym uaktualnieniem, nawet jeśli ma ono jedynie
charakter poprawki, niwelującej wykryty błąd. Jak już wcześniej wspomniano,
numer wersji należy dołączać do aplikacji, korzystając z

zasobu

VERSIONINFO (zob. rozdział 13).

Należy zawsze postawić pytanie, czy aplikacja realizuje funkcje zgodne

z pierwotnie zakładanym przeznaczeniem. Oto przykład poprawnie
postawionego pytania: "Czy aplikacja efektywnie wspomaga zarządzanie
wynajmowanymi nieruchomościami?".

Cechy stworzonej aplikacji należy porównać z pierwotnie zdefiniowanymi

wymaganiami operacyjnymi, funkcjonalnymi i technicznymi. Należy upewnić
się, czy funkcje, które ostatecznie zostały uwzględnione w

aplikacji,

odpowiadają kluczowym funkcjom, określonym w oryginalnej specyfikacji.

W miarę możliwości należy przygotować oddzielny komputer w konfiguracji

identycznej z tą, w której aplikacja ma działać. Aplikacja powinna zostać
wstępnie zainstalowana i przetestowana w takim systemie. Szczególną uwagę
należy zwrócić na zastosowanie w testowym komputerze procesora, pamięci
operacyjnej i dyskowej oraz karty graficznej, odpowiadających stosowanym na
komputerach klientów. Podobnie wskazane jest użycie tych samych systemów
operacyjnych. Jeśli użytkownik korzysta z Windows NT, to aplikację należy
testować w systemie Windows NT; jeśli użytkownik pracuje w Windows 95,
aplikacja powinna być testowana właśnie w tym systemie. Celowe jest również
uruchamianie wraz z testowana aplikacją wszelkich programów, stosowanych
intensywnie przez przyszłych użytkowników. Pozwoli to wykryć ewentualne
niezgodności.

Projektowanie aplikacji w modelu klient/serwer

239

Należy starannie przetestować działanie więzów bazy danych. Testowanie

powinno obejmować próbę wprowadzenia niepoprawnych danych do bazy.
Jeśli testowane więzy narzucają maksymalne i

minimalne wartości

dopuszczalnych danych, to konieczne jest przetestowanie zarówno górnego, jak
i dolnego ograniczenia. Innym istotnym testem jest próba usunięcia wierszy,
zawierających klucze zależne. Należy także sprawdzić, czy baza danych nie
zezwoli na wprowadzenie dwóch identycznych wartości do kolumn, które
powinny zawierać wartości unikalne. Inny test polega na niewypełnieniu pól
formularza, które wymagają wpisania wartości.

Testowaniu powinny zostać poddane mechanizmy pracy współbieżnej. Jeśli

aplikacja ma obsługiwać 20 użytkowników, pracujących jednocześnie, to
należy ją przetestować w sytuacji, gdy równolegle pracuje 30 lub 40
użytkowników. Osoby testujące powinny próbować jednocześnie aktualizować
zawartość tego samego wiersza; testy powinny też obejmować próbę usunięcia
wiersza, który w danej chwili jest poddawany edycji przez innego użytkownika.
Konieczne jest przetestowanie mechanizmów blokowania bazy danych,
gwarantujących, że zmiany wprowadzane równolegle przez wielu
użytkowników nie zostaną utracone i

będą pojawiać się w

bazie

w odpowiednim czasie.

Jeśli aplikacja funkcjonuje w oparciu o serwer bazy danych albo sieciowy

system operacyjny, konieczne jest przetestowanie mechanizmów kontroli
dostępu. Prawidłowo powinien działać mechanizm blokujący dostęp po
kilkakrotnym błędnym podaniu hasła. Poszczególni użytkownicy muszą
dysponować prawami dostępu, umożliwiającymi im korzystanie
z przewidzianych dla nich funkcji aplikacji. W ramach testu należy podjąć
próbę złamania praw dostępu na każdym ze zdefiniowanych poziomów
uprawnień. Testy powinny też obejmować próbę usunięcia i zmiany wierszy
przez osobę, zalogowaną jako użytkownik bez właściwych uprawnień.

Przed udostępnieniem aplikacji klientom powinny ją przetestować osoby nie

związane z projektem oraz współpracownicy autorów programu.

Jeśli aplikacja będzie szerzej rozpowszechniana, to jej wersje "beta" powinny

być testowane przez specjalnie wyznaczoną grupę użytkowników. Testy takie
należy przeprowadzać zanim aplikacja zostanie publicznie udostępniona.

Należy przeprowadzić testy praktycznej przydatności aplikacji dla

użytkowników o różnym stopniu zaawansowania. Może się okazać, że aplikacja
działa poprawnie, ale jest zbyt trudna w obsłudze. Tego rodzaju problemy
można wykryć, udostępniając aplikację do testów użytkownikom
o zróżnicowanych umiejętnościach i doświadczeniu.

Ostatnie słowo przy ocenie przydatności aplikacji należy zawsze do

użytkownika.

240

Część I

Instalowanie aplikacji

Przygotowanie aplikacji do zainstalowania omawia szczegółowo Rozdział
29.Poniższe sugestie mogą pomóc w opracowaniu ogólnego planu instalacji:

Jak już wspomniano, przed pierwszą właściwą instalacją należy przygotować

oddzielny komputer, możliwie wiernie oddający środowisko końcowego
użytkownika, i dokonać na nim próbnej instalacji.

Należy unikać ingerencji w

system użytkownika, a w szczególności

nieuzasadnionych zmian jakichkolwiek parametrów konfiguracyjnych.

Przed zainstalowaniem aplikacji należy zapoznać się z

docelowym

środowiskiem systemowym i zdecydować, czy konieczne jest uzupełnienie go
o dodatkowy sprzęt lub oprogramowanie. Na przykład, jeśli aplikacja
komunikuje się z systemem zarządzania bazą danych za pośrednictwem
protokołu TCP/IP, to na komputerach klientów musi być zainstalowana obsługa
tego protokołu. Czasami ocenę i

uzupełnienie docelowego środowiska

przeprowadzać trzeba we współpracy z administratorem sieci.

Instalację aplikacji i wszelkich plików pomocniczych powinien realizować

oddzielny program instalacyjny. Do tworzenia takich programów wykorzystać
można narzędzie InstallShield Express, dostarczane w pakiecie Delphi i opisane
szerzej w rozdziale 29.