Roz07.pdf

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 iprocesów aplikacji, niezbędnych do

zaimplementowania żądanych funkcji.

Przekształcenie projektu waplikację 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ć zzapoznania 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, zkoniecznoś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 iulokować wnim 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. Wistocie, 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 iczy 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 inadal 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 zpołowy dziewiętnastego stulecia. Meble wytwarzano wówczas

pojedynczo, wwarsztatach, wktó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 iinnych dokumentów wyjściowych,

generowanych przez aplikację.

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

stworzonych modelach.

Zdefiniowania przejść między formularzami iraportami 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.

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: