10.Rozdziaę 09, !EDUKACJA, Programowanie
[ Pobierz całość w formacie PDF ]
Rozdział 9
Pierwsze kroki
Mając już utworzone obiekty bazy danych, jesteśmy gotowi do projektowania
i tworzenia aplikacji RENTMAN. Rozdział siódmy: „Projektowanie aplikacji
w modelu klient/serwer” zawiera liczne pomysły, z którymi warto się zapoznać
przed dalszą pracą.
Rozpocznijmy od przypomnienia pięciu faz tworzenia aplikacji. Jak pisaliśmy
w rozdziale ósmym: tworzenie każdego programu składa się z następujących
etapów:
analiza;
projekt;
budowanie;
testowanie;
eksploatacja, konserwowanie.
W poprzednim rozdziale przebyliśmy etapy analizy, projektowania i budowy bazy
danych projektu RENTMAN. Wniniejszej części będziemy analizować
i projektować aplikację, by w końcu rozpocząć fazę kodowania. Podstawą procesu
tworzenia programu będą obiekty bazy danych utworzonej w rozdziale ósmym.
Konstruowanie podstawy: baza danych RENTMAN
W tym miejscu baza danych powinna już być zaprojektowana i utworzona,
w przeciwnym razie musimy cofnąć się do poprzedniej części oraz utworzyć bazę
danych RENTMAN - podstawę, na której będziemy budować resztę programu.
Zakończenie tworzenia bazy danych przed przystąpieniem do dalszej pracy jest
ważne, albowiem zmiany w strukturze bazy po napisaniu aplikacji wymagają
przebudowy odpowiedniej części programu.
Określanie rodzaju budowanej aplikacji
Jak pamiętamy z rozdziału siódmego, pierwszym krokiem budowania programu
obsługi baz danych jest określenie rodzaju projektowanej aplikacji. Istnieją dwa
podstawowe wybory: systemy przetwarzania transakcji w czasie rzeczywistym
278
Część II
(OLTP- O
nline Transaction Processing Systems
) i systemy wspierania decyzji
(DSS- D
ecision Support Systems
). Ostatnie mają dać menedżerom ogląd z lotu
ptaka informacji o przedsiębiorstwie, natomiast pierwsze umożliwiają zmiany
i manipulowanie danymi. W programach DSS dane są dostępne jedynie w trybie
„do odczytu”, natomiast wsystemach OLTP informacje można zarówno
odczytywać, jak i zapisywać do bazy danych. Ta różnica powoduje, że już
w momencie startu należy zdawać sobie sprawę z tego, jaki rodzaj programu
będziemy budować.
RENTMAN jest aplikacją przetwarzającą transakcje. Użytkownicy muszą mieć
możliwość dodawania, zmieniania i usuwania danych. System ten nie spełnia więc
kryteriów wyróżniających programy DSS. Z drugiej strony, pewne informacje
udostępniane za pośrednictwem aplikacji będą używane przez zarządzających
Allodium w procesie podejmowania decyzji. Dlatego, jak w większości systemów
klient/serwer, RENTMAN będzie hybrydą, zawierającą kluczowe elementy
zarówno OLTP, jak i DSS. Dla swoich celów będziemy budować aplikację
RENTMAN jako system OLTP, zawierający wiele elementów DSS.
Utworzyć obiekty programu na podstawie procesów aplikacji
Przy użyciu modeli reguł przetwarzania, opisywanych w rozdziale ósmym, należy
przeanalizować każdą regułę, w celu określenia wszystkich niezbędnych do
implementacji obiektów aplikacji (zazwyczaj są to formularze i raporty). Możemy,
na przykład, wydedukować, że będą nam potrzebne sposoby wprowadzania
informacji dokażdego zbioru danych zdefiniowanego wmodelu reguł
przetwarzania. Musimy pamiętać o korelacji między zbiorami danych w modelach
i odpowiednimi tabelami w naszym fizycznym projekcie. Podobnie istnieje prosty
związek pomiędzy tabelami w bazach danych i formularzami programu. Będziemy
prawdopodobnie potrzebować więcej niż jednego formularza do obsługi każdej
tabeli. Może to być na przykład prosty formularz do wprowadzania danych,
służący użytkownikom do dodawania nowych rekordów, czy rozbudowany
formularz do obsługi tabeli, umożliwiający wyszukiwanie, dodawanie, zmiany
i kasowanie wierszy tabeli.
Nie należy się przejmować pojawiającymi się wzwiązku zbrakiem
doświadczenia, wątpliwościami co do właściwego wyboru formularzy i raportów.
Decyzje na tym etapie są zaledwie punktem wyjścia. Głównym zadaniem na
przyszłość jest określenie możliwości rozwoju programu. Trzeba sobie w pełni
zdawać sprawę z zawiłości konstruowania aplikacji. Charakterystyczną cechą
każdej implementacji, którą stworzymy, jest potrzeba dokonania w niej zmian.
Po określeniu wszystkich formularzy, raportów oraz innych obiektów
skojarzonych zodpowiednimi elementami modelu, warto opatrzyć go
odpowiednimi komentarzami. Postępując wten sposób, ułatwiamy sobie
Pierwsze kroki
279
wyobrażenie podstawowych obiektów aplikacji. Rysunek 9.1 ilustruje model
procesu wynajmu (lease), zawierający przypisy o obiektach niezbędnych do jego
implementacji.
Zauważmy, że obiekty aplikacji RENTMAN są nazywane zgodnie ze
wskazówkami dotyczącymi nazewnictwa zawartymi w rozdziale 4, „Konwencje”.
Stosowane nazwy wskazują na specyficzny typ każdego formularza. Wskazane jest
również odróżniać sterowalne formularze tabelaryczne (ang.
control grid forms
)
od regularnych formularzy tabelarycznych (ang.
regular grid forms
), a te z kolei
od podstawowych formularzy do wprowadzania/aktualizacji danych i tych, które
są przeznaczone do szybkiego wprowadzania informacji. Na pytanie, co to są
sterujące formularze siatkowe, odpowiemy szczegółowo nieco później, natomiast
już teraz możemy powiedzieć, że komponentu Delphi
DBCtrlGrid
używa się do
wyświetlania wielu rekordów na jednym formularzu. Różnią się od formularzy
służących do wyświetlania wielu rekordów za pomocą komponentu
DBGrid
.
Umiejętność właściwego doboru detali, takich jak decyzja o wyborze właściwego
komponentu do budowy odpowiedniego formularza, zdobywa się poprzez
praktykę. Programiści, latami budujący aplikacje klient/serwer, potrafią łatwo
określać takie szczegóły implementacji na bardzo wczesnym etapie budowania
programu.
Rysunek 9.1.
Model procesu
wynajmu (lease)
programu
RENTMAN,
zawierający
przypisy
o obiektach.
Będziemy chcieli posiadać możliwość rozpoznawania niezbędnych obiektów
aplikacji wkażdym zmodeli reguł przetwarzania. Wprzypadku programu
RENTMAN mamy dwa główne procesy, które będziemy szczegółowo analizować:
proces wynajmu (
lease
) oraz proces konserwacji (
maintenance
). Wcześniej każdy
280
Część II
model procesu analizowany był pod kątem możliwości znalezienia równoważnika
w aplikacji, teraz klasyfikujemy wszystkie zidentyfikowane obiekty jako raporty,
formularze lub nieinteraktywne procedury wspierające (czyli bloki kodu niezbędne
do poprawnego działania programu, ale nie związane bezpośrednio z interfejsem
użytkownika). Każdy zidentyfikowany obiekt powinien należeć do jednego
z trzech typów (dla naszych celów traktujemy wykresy jako raporty). Spróbujmy
zatem możliwie najlepiej odgadnąć, jakie typy obiektów możemy zbudować ( na
przykład formularze do szybkiego wprowadzania danych, szczegółowy raport
w formie wykazu, itp.) oraz odpowiednio je nazwać.
Zapamiętajmy, że niektóre obiekty są z góry określone. Na przykład, każda
aplikacja potrzebuje pewnego rodzaju podstawowego formularza i głównego okna
interfejsu. Podobnie każda tablica w aplikacji wymaga formularza do dodawania,
modyfikacji i usuwania rekordów. Tablica 9.1 przedstawia podstawową listę
formularzy i raportów programu RENTMAN.
Tablica 9.1. Podstawowe formularze i raporty programu RENTMAN.
Nazwa
Cel
Rodzaj obiektu
Opis
fmRSYSMAN0
przetwarzanie
transakcji
formularz SDI
Główna menu
systemu
fmRCALEDT0
wprowadzanie
danych
formularz szybkiego
wprowadzania danych
(quick-entry)
formularz
wprowadzania
i edycji danych ze
zbioru CALL
fmRCALGRD0
przetwarzanie
transakcji
sterowalny formularz
tabelaryczny (control
grid form)
formularz
tabelaryczny do
przeglądania listy
zbioru CALL
fmRWORMDE0
przetwarzanie
transakcji
formularz (master-
detail)
kombinowany
formularz do
analizy listy prac
fmRWORGRD0
przetwarzanie
transakcji
formularz tabelaryczny
(grid form)
formularz listy prac
fmREMPENT0
wprowadzanie
danych
formularz szybkiego
wprowadzania danych
(quick-entry)
formularz do
szybkiego
wprowadzania
danych
o pracownikach
fmREMPGRD0
przetwarzanie
dh
formularz tabelaryczny
(idf )
formularz
tbl
d
Pierwsze kroki
281
Nazwa
Cel
Rodzaj obiektu
Opis
danych
(grid form)
tabelaryczny do
przeglądania
i edycji listy
pracowników
fmRWKTGRD0
przetwarzanie
danych
formularz tabelaryczny
(grid form)
formularz
tabelaryczny do
przeglądania
i edycji rodzajów
pracy
fmRWKTENT0
wprowadzanie
danych
formularz szybkiego
wprowadzania danych
(quick-entry)
formularz do
szybkiego
wprowadzania
danych o rodzaju
pracy
fmPROCGD0
przetwarzanie
danych
sterowalny formularz
tabelaryczny (control
grid form)
Sterowalny
formularz
tabelaryczny tabeli
WŁAŚCIWOŚCI
(PROPERTY)
fmRTENCGD0
przetwarzanie
danych
sterowalny formularz
tabelaryczny (control
grid form)
Sterowalny
formularz
tabelaryczny tabeli
NAJEMCY
(TENANT)
fmRLEAGRD0
przetwarzanie
danych
formularz tabelaryczny
(grid form)
formularz
tabelaryczny tabeli
DZIERŻAWA
(LEASE)
rpRLEAPRT0
raport
formularz raportu (form
report)
oficjalny raport
dotyczący
wynajmu
rpRWORD0
raport
formularz raportu (form
report)
formularz listy prac
przydzielonych
pracownikom
rpRTSKLST0
raport
szczegółowy raport
(detail report)
raport o bieżących
zadaniach
pracowników
[ Pobierz całość w formacie PDF ]