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.
220 Część I
Rysunek 7.1.
Przykładowy
wstępny model
aplikacji dla
projektu
RENTMAN.
Rysunek 7.2.
Inny przykładowy
model aplikacji.
Wygenerowanie aplikacji
Jeśli stosowane narzędzie CASE umożliwia generowanie tekstu programu,
odpowiadającego stworzonym modelom, celowe jest skorzystanie z takiej funkcji.
Narzędzie wygeneruje wówczas przynajmniej część aplikacji na podstawie
opracowanych modeli. Oszczędność czasu, jaką można w ten sposób uzyskać,
 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óz
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.
zdecydować się na określony motyw graficzny aplikacji. Decyzja
Należy
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.
224 Część I
Rysunek 7.4.
Interfejs Microsoft
Office.
Rysunek 7.5.
Interfejs Lotus
SmartSuite.
Oczywistym powodem, dla którego zaleca się zachowanie zgodności
z obowiązującymi standardami interfejsów, jest powszechna ich znajomość wśród
użytkowników. Dzięki niej skróci się czas potrzebny na opanowanie nowej
aplikacji. Ponadto, zachowując podobieństwo do programów największych
producentów, aplikacja sprawia wrażenie  bardziej profesjonalnej .
należy wprowadzać zbędnych funkcji. Zalew bezużytecznych informacji
Nie
powoduje, że użytkownik niepotrzebnie traci czas. Wprowadzanie w programie
 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.
budować formularze typu SDI, a nie MDI. Swego czasu preferowane
Należy
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 z
ródłowego.
korzystać ze standardowych pól dialogowych systemu Windows. Nie
Należy
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, znalez
ć można na stronie Dialogs
palety komponentów Delphi.
tła formularzy powinien być neutralny (taki jak np. clBtnFace, który
Kolor
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ć wskaz
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.
przycisk na formularzu powinien mieć swój odpowiednik w postaci
Każdy
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
najczęściej stosowanymi poleceniami w menu powinny być skojarzone
Z
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.
opisywania wszystkich przycisków należy stosować jednolitą czcionkę.
Do
Interfejs użytkownika nie może być krzykliwy. Ewentualne trudności
z odczytaniem etykiet i opisów świadczą o z
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.
osób uważa, że czcionki bezszeryfowe (takie jak Arial) są bardziej
Wiele
czytelne niż szeryfowe (np. Times New Roman).
jak najszerzej korzystać z mechanizmu podpowiedzi (ang. hints).
Należy
Podpowiedzi są niewielkimi (najczęściej żółtymi) etykietami, które pojawiają
się na ekranie, gdy użytkownik zatrzyma na chwilę wskaz
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 znalez
ć 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
o 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 i 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.
formularzach, zawierających pola do wprowadzania danych, należy
Na
zdefiniować pole domyślne (nadając jego atrybutowi TabOrder wartość 0).

Aby zgromadzić dużą liczbę kontrolek na stosunkowo niewielkiej powierzchni
ekranu, należy zastosować komponenty typu TabControl i 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.
aplikacją należy skojarzyć charakterystyczną ikonę. Ikona ta pojawiać się
Z
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.
wszystkich formularzach należy używać jednolitej wielkości czcionki.
Na
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.
aplikacja ma tylko odczytywać dane, a nie zezwala na zapis, to
Jeśli
z 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.
aplikacji należy usunąć (lub skutecznie w niej ukryć) wszelkie funkcje, do
Z
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:
rozważyć możliwość uzupełnienia bądz
zastąpienia przycisków
Należy
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.
przyciskami poleceń i polami do wprowadzania danych należy skojarzyć
Z
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ół.
razie potrzeby należy wykorzystać atrybut Kind komponentów TBitBtn
W
i zdefiniować przyciski OK i Cancel (Anuluj). Przycisk OK 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 z
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.
formularza należy usunąć zbędne przyciski i pola. Na formularzu nie ma
Z
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 OK.
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 z
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:
tylko jest to możliwe, raporty należy projektować przy wykorzystaniu
Gdy
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ć
w 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 z
ródłowego aplikacji.
wykorzystywana platforma systemowa dopuszcza stosowanie procedur
Jeśli
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ę.
raporty generowane są przez procedury pamiętane, to wywołania tych
Jeśli
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.
nagłówku strony raportu należy umieścić wewnętrzną nazwę raportu,
W
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 z
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
Rysunek 7.6.
Prawidłowo
zaprojektowany
raport.
nagłówku strony należy także wyszczególnić wszystkie kryteria, jakie
W
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 znalez
ć 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.
 Projektowanie aplikacji w modelu klient/serwer 237
w raporcie mają znalez
ć się napisy podkreślone, to należy zastosować
Jeśli
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.
o charakterze wartości (kwoty, ilości, itp.) należy wyrównywać do
Liczby
prawej strony. Liczby, które pełnią rolę identyfikatorów (numery faktur, itp.),
powinny być wyrównane do lewej.
wyróżnienia niektórych elementów raportu wykorzystać można
Do
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ć odpowiedz
autora (autorów) programu
na zgłoszenie.
przygotować mechanizm prostego i sprawnego rozsyłania uaktualnień
Należy
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).
zawsze postawić pytanie, czy aplikacja realizuje funkcje zgodne
Należy
z pierwotnie zakładanym przeznaczeniem. Oto przykład poprawnie
postawionego pytania: "Czy aplikacja efektywnie wspomaga zarządzanie
wynajmowanymi nieruchomościami?".
stworzonej aplikacji należy porównać z pierwotnie zdefiniowanymi
Cechy
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.
miarę możliwości należy przygotować oddzielny komputer w konfiguracji
W
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
starannie przetestować działanie więzów bazy danych. Testowanie
Należy
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.
aplikacja funkcjonuje w oparciu o serwer bazy danych albo sieciowy
Jeśli
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ń.
udostępnieniem aplikacji klientom powinny ją przetestować osoby nie
Przed
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:
już wspomniano, przed pierwszą właściwą instalacją należy przygotować
Jak
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.
zainstalowaniem aplikacji należy zapoznać się z docelowym
Przed
ś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.