Dokumentacja projektowa systemu informatycznego

1

KittyTeam

SYSTEM INFORMATYCZNY OBSŁUGI

BIURA PODRÓŻY

Dokumentacja projektowa

Warszawa, 2010

Dokumentacja projektowa systemu informatycznego

2

Spis treści

1. Wstęp

2. Diagram klas

2.1. Diagram klas;

2.2. Definicje;

3. Projekt bazy danych

3.1. Model konceptualny;

3.2. Definicje;

4. Optymalizacja systemu
5. Interfejsy użytkownika
6. Protokoły komunikacyjne
7. Diagramy wdrożeniowe

7.1. Diagram komponentów;
7.2. Diagram rozlokowania;

8. Harmonogram implementacji
9. Plan testów
10. Podsumowanie

Status dokumentu

Zespół wytwórczy 9/2010/GB w składzie

Kierownik projektu / Zamawiający

Paulina Turlewicz

Zamawiający / Tester akceptacyjny

Piotr Szela

Analityk / Projektant

Piotr Surma

Analityk / Tester wewnętrzny

Maciej Zarzycki

Projektant / Tester wewnętrzny

Karol Pawłowski

Zmiany w stosunku do wersji poprzedniej

Wersja pierwsza.

Dokumentacja projektowa systemu informatycznego

3

1. Wstęp

Niniejszy dokument stanowi podsumowanie fazy projektowej systemu informatycznego dla biura

podróży „Husajn”. Dzięki niemu można odpowiedzied na pytanie: Jak system ma byd
zaimplementowany? Stanowi uściślenie ustaleo wykonanych w fazie analizy. Dzięki temu uzyskujemy
pełen obraz systemu poprzez pełne zdefiniowanie klas oraz struktury bazy danych, a także
graficznych interfejsów istotnych z punktu widzenia użytkownika koocowego. Przez to uzyskujemy
pełen obraz systemu od warstw najniższych po najwyższe, jednoznacznie wskazujące sposób
implementacji.

2. Diagram klas

Diagram klas fazy analizy przedstawiał uproszczony, poglądowy zbiór klas, na które składa się

system. Poniższy diagram jest uściśleniem poprzedniego. Nie tylko przedstawia relacje pomiędzy
klasami:



Asocjacje;



Agregacje;



Kompozycje;



Generalizacje;

ale także wszystkie wymagane zmienne i funkcje składowe (metody). W diagramie, celem
zachowania czytelności nie przedstawiono akcesorów do zmiennych składowych (getterów i
setterów), które będą implementowane w zależności od potrzeb oraz możliwości języka
programowania.

2.1. Diagram klas

Na kolejnych stronach przedstawiony jest uściślony diagram klas.

6

Dokumentacja projektowa systemu informatycznego

2.2. Definicje



Klasa JednostkaOrganizacyjna jest klasą abstrakcyjną, z której dziedziczą wszystkie klasy
konkretne elementów systemu. To właśnie klasy, które z niej dziedziczą bezpośrednio będą
stanowid najwyższą warstwę architektury – warstwę interfejsu. Zawiera ona tylko jedno pole
– id jednostki;



Klasami pochodnymi są:

o Strona, która przechowuje tylko najważniejsze informacje dotyczące strony WWW

(adresy serwerów DNS, informacje dotyczące domeny);

o Zarzad, która zawiera metody związane w przeglądaniem raportów i statystyk oraz

zarządzania pracownikami;

o Biuro przechowująca przede wszystkim dane adresowe biura i możliwośd ich edycji;
o Centrala składająca się z metody ulozOferte(), dzięki której możliwe jest tworzenie

ofert na wycieczki oraz z metod służących do komunikacji z podwykonawcami;

o Podwykonawca zawierająca dane adresowe i kontaktowe podwykonawcy,

informacje dotyczące działalności i daty zawarcia umowy oraz dane do przelewów;
Metody służą do komunikacji z centralą (wymiana danych) oraz akceptacji pobranych
zamówieo;



Z klasy Podwykonawcy dziedziczą klasy wyspecjalizowane w danych działalnościach
usługodawców:

o Hotel przechowuje terminy rezerwacji dla danej oferty, standard pokojów oraz liczba

zarezerwowanych pokojów;

o Restauracja zawiera dane dotyczące wyżywienia na wycieczce, w tym liczbę posiłków

dziennie dla ilu osób;

o Przewodnik to klasa, która zawiera datę początku pracy przewodnika na wycieczce,

ilośd godzin oraz liczbę osób, które przewodnik może mied w grupie;

o Ubezpieczenie informuje o wykupionym pakiecie oraz wartości ubezpieczenia;
o Transport przechowuje dane dotyczące typu i klasy środka transportu, terminów

wyjazdu oraz liczbie miejsc siedzących i stojących;



Najważniejszą z punktu widzenia działalności biura podróży jest klasa Oferta. Spośród
składowych przechowuje identyfikator wycieczki (zgodny z tym, który zapisany jest w bazie
danych), jej cenę oraz terminy. Metody służące do dodawania, modyfikacji, usunięcia, bądź
przekazania do realizacji przez podwykonawców są wykorzystywane wyłącznie przez centralę
z jednym wyjątkiem. Biuro może przygotowad ofertę specjalną (na zamówienie), ale Centrala
musi ją potwierdzid. Każdy natomiast może wyszukad ofertę, pobrad jedną z nich po ID, bądź
kolejną po ID.



Nieodłączną klasą jest Zamówienie. Jej obiekt zostaje powołany w momencie kupna
wycieczki i przechowuje informacje dotyczące ilości zarezerwowanych miejsc oraz informacje
dotyczące sposobu płatności. Metody pozwalają na zamówienie, odwołanie zamówienia lub
jego modyfikację;



Sama płatnośd wykorzystuje klasę Płatnośd do zlecenia przelewu lub jego anulowania.
Anulowanie następuje jednak tylko poprzez zamówienia złożone przez stronę internetową
(zgodnie z założeniami z wcześniejszych faz). Przechowywana jest data dokonania płatności,
jej kwota oraz informacja o potwierdzeniu przez bank.

7

Dokumentacja projektowa systemu informatycznego



W systemie wyróżniono klasę abstrakcyjną Osoba, która zawiera identyfikator osoby z bazy
danych, jej dane osobowe i kontaktowe oraz metody służące do dodania osoby, modyfikacji
jej danych i usunięcia, a także metodę zwracającą datę urodzenia na podstawie numeru
PESEL. Dziedziczą z niej następujące klasy pochodne:

o Klient, którą rozszerzono o informację, czy klient życzy sobie wystawiania faktur VAT

dotyczących swoich zamówieo;

o Pracownik z informacjami o jednostce, w której pracuje oraz o stanowisku pracy, a

także z datą zatrudnienia;



W relacji kompozycji z klasą Pracownik jest klasa Wypłata zawierająca pola o kwocie wypłaty
i dacie przelewu oraz metodę zlecającą przelew;



Klasa Raport jest związana z klasą Zarząd. Dzięki niej możliwe jest generowanie raportów i
statystyk;



StatusZamówienia łączy Ofertę, Podwykonawców i Centralę. Dzięki niej odbywa się
wzajemna komunikacja i wymiana informacji. Pomocną w realizacji asocjacji Podwykonawca
-> StatusZamówienia jest klasa RealizowaneZamowienie, która łączy konkretnego
usługodawcę z konkretnym zamówieniem;



Podobną funkcję pełni klasa ZłożoneZamówienie w relacji Klient -> Zamówienie. Przypisuje
ono zamówienia poszczególnym klientów, którzy je kupili;

Warto zwrócid uwagę, że dla jednej oferty może byd przydzielonych wiele obiektów klas

podwykonawców (np. zakwaterowanie może odbywad się w wielu hotelach na różnych etapach
podróży). Przez to implementacja relacji zachodzących między Ofertą, a Podwykonawcami może
zostad zrealizowana za pomocą tablic obiektów bądź list. Ponadto z punktu widzenia projektowanego
systemu usługi zapewniane przez podwykonawców są częścią oferty, stąd relacje między nimi to
agregacje lub kompozycje.

3. Projekt bazy danych

3.1. Model konceptualny

Na poniższym schemacie przedstawiono model konceptualny bazy danych.

8

Dokumentacja projektowa systemu informatycznego

9

Dokumentacja projektowa systemu informatycznego

3.2. Definicje



Encja Adres jest encją abstrakcyjną i nie jest generowana. Zawiera podstawowe dane
adresowe, jak np. nazwa ulicy z numerem budynku i lokalu oraz kod i poczta. Dziedziczą z niej
inne encje abstrakcyjne: Osoba i jednostkaOrganizacyjna;



Osoba również nie jest generowana, uzupełnia ona Adres o imię, nazwisko, pesel oraz nip, a
także o swój id (klucz główny);



jednostkaOrganizacyjna uzupełnia Adres o identyfikator jednostki (klucz główny);



Z encji jednostkaOrganizacyjna dziedziczy encja Biuro, która zawiera klucz główny idBiura;



Z tej samej encji dziedziczy także podwykonawca. Jest to także encja abstrakcyjna, która do
odziedziczonych pól dodaje swój id (klucz główny), typ działalności, datę zawarcia umowy z
podwykonawcą oraz dane kontaktowe do przedstawiciela danego podwykonawcy;



5 klas uściślających podwykonawcę to Hotel, Restauracja, Przewodnik, Ubezpieczenia i
Transport. Dodają one pola opisujące daną działalnośd zgodnie z założeniami systemu. Pola
tych encji są analogiczne do pól klas o tych samych nazwach na diagramie klas;



Z encji Osoba dziedziczą Pracownik przechowująca dane o jednostce i stanowisku oraz dacie
zatrudnienia, a także Klient z informacją o chęci otrzymywania faktur VAT za zamówione
usługi;



W relacji jeden-do-wielu z encją Klient jest encja Zamówienia. Encja ta posiada swój klucz
główny oraz informacje dotyczące ilości osób zamawiających i sposobu płatności;



Z kolei w relacji jeden-do-wielu z encją Zamówienia jest encja Płatności. Ona zawiera
szczegóły dotyczące transakcji, takie jak data i kwota oraz potwierdzenie banku;



Najważniejszą z punktu widzenia systemu jest encja Oferta. Sama przechowuje cenę oraz
terminy wycieczki, a także swój klucz główny. Znajduje się ona w relacji jeden-do-wielu z
encją Zamówienia oraz w relacji wiele-do-wielu z encjami uściślającymi poszczególnych
podwykonawców. Dzięki temu z każdym typem podwykonawcy zostanie utworzona
intersekcja, która umożliwi dopasowanie wielu podwykonawców danej dziedziny z jedną
ofertą.

Struktura bazy danych przedstawiona w ten sposób minimalizuje stopieo redundancji, co w
znacznym stopniu ułatwia zarządzanie i podnosi wydajnośd. Dodatkowo projektowana baza znajduje
się w trzeciej postaci normalnej.

4. Optymalizacja systemu

Nieprawidłowa implementacja może doprowadzid do powstania systemu o zbyt niskiej

efektywności. Celem optymalizacji projektu wykorzystujemy wiele czynności i mechanizmów
poprawiających efektywnośd. Przede wszystkim, tam gdzie to możliwe wybieramy typy danych o
minimalnej, niezbędnej wartości. Kiedy wymagane są tylko dwa stany wartości, wystarczającym
będzie typ logiczny (boolean). Niestety, nie wszystkie języki programowania pozwalają na używanie
zmiennych o takim typie.

10

Dokumentacja projektowa systemu informatycznego

Na etapie implementacji niezbędnym okazuje się używanie funkcji wplatanych (inline). Dzięki

temu kod zachowuje czytelnośd, bo funkcja ma swoją definicję, ale przez kompilator jej wywołanie
zamieniane jest z jej instrukcjami. Przez to ograniczamy ilośd przeniesieo sterowania, co korzystnie
wpływa na wydajnośd. Niestety, podobnie jak w powyższym przypadku, nie wszystkie języki
umożliwiają używanie funkcji wplatanych. Dlatego znaczna częśd projektowanego systemu
implementowana będzie w języku C++.

Częstą funkcją używaną przy wyszukiwaniu ofert będzie funkcja sortowania. W zależności od

kryteriów wyszukiwania, ilośd danych do sortowania może byd zmienna. Dlatego zaimplementowana
będzie funkcja, która w przypadku małej ilości informacji używad będzie sortowania przez
wstawianie. Mimo, iż złożonośd tego algorytmu jest kwadratowa, to znakomicie sprawdza się przy
sortowaniu małej liczby wartości. Dla dużych zbiorów danych używany będzie algorytm o niższej
złożoności, np. algorytm sortowania przez scalanie.

W „wąskich gardłach” systemu wykorzystany będzie język assembler celem podniesienia

wydajności. Jednym z takich wąskich gardeł jest wybór wszystkich podwykonawców dla danej oferty
wycieczki. Podwykonawców może byd bowiem wielu. W przypadku strony internetowej w
krytycznych punktach stosowany będzie program na serwerze w języku C wywoływany z poziomu
języka skryptowego strony. Wynik działania programu zostanie przekazany językowi strony (np. PHP).
Języki skryptowe stron są dośd wolne, gdyż podlegają interpretacji, a doświadczenia inny serwisów
internetowych mówią, że programy w C znacznie podnoszą wydajnośd.

Celem przyspieszenia wyszukiwania w bazie danych zastosowane będą indeksy, w tym indeksy

wyszukiwania pełnotekstowego (fulltext indexes). Dzięki temu wydajnośd wyszukiwania w bazie
danych znacznie wzrośnie. Niestety, nie wszystkie silniki wspierają wyszukiwanie pełnotekstowe.

Niezwykle ważnym mechanizmem jest mechanizm cache. W przypadku strony internetowej

użytkownik często wraca do danej podstrony lub do danego wyszukiwania. Jeśli dane się nie zmieniły,
serwer nie musi na nowo przetwarzad żądania. Dzięki temu działania języka strony WWW można
znacznie ograniczyd lub w niektórych przypadkach nawet całkowicie wykluczyd. Kiedy następuje
nowe żądanie, serwer zapisuje wygenerowany kod HTML w katalogu cache, po czym wysyła go do
przeglądarki użytkownika. Kiedy klient ponownie zażąda tej samej strony, nastąpi przesłanie jej z
katalogu cache. Dzięki temu nie trzeba ponownie łączyd się z bazą danych, pobierad rekordów,
przetwarzad ich, nie jest uruchamiany system szablonów, ani nie są wykonywane inne obliczenia.

Warto także rozdzielid jeden „duży” serwer na kilka mniejszych realizujących specjalne zadania.

Warto na przykład wydzielid z serwera WWW taki, który przechowywałby pliki. Dzięki temu działałby
niezależnie od serwera obliczeniowego. Ruch plików (np. obrazki na stronie) generuje poważne
obciążenie, stąd odizolowanie go od obliczeo jest bardzo sensowne.

Zaprezentowane wyżej mechanizmy optymalizacji zapewniają znaczny skok wydajności systemu.

Dobór odpowiednich algorytmów często znaczy więcej niż moc obliczeniowa samej maszyny.

11

Dokumentacja projektowa systemu informatycznego

5. Interfejsy użytkownika

a) Strona www

Strona WWW ma byd prawidłowo wyświetlana pod wszystkimi czołowymi przeglądarkami

internetowymi (Internet Explorer >=7, Mozilla Firefox >=3, Opera >=10, Google Chrome >=3). Strona
wykonana zgodnie ze standardami W3C (łącza w dokumentacji specyfikacji).

Użytkownik strony ma do dyspozycji gotowy katalog - na jego podstawie klient na głównej stronie

może wyszukad wycieczkę wpisując gdzie i kiedy chce jechad. W momencie logowania oraz na etapie
płatności strona wykorzystuje transmisję szyfrowaną.

12

Dokumentacja projektowa systemu informatycznego

b) Aplikacja biura

Każde biuro terenowe to jedno konto w systemie - ma swój identyfikator i przesyła dane jako

oddział. Firma (zleceniodawca) zdecydowała się bowiem prowadzid statystyki całego konkretnego
biura, a nie każdego pracownika z osobna.

W menu znajduje się możliwośd wyboru aktualnej oferty firmy, panel służący do zamawiania

wycieczek oraz do tworzenia oferty indywidualnej, a także panel transakcyjny. Pracownik wprowadza
w nim potwierdzenia rezerwacji wycieczek po otrzymaniu płatności. Nie zabrakło możliwości
filtrowania ofert po wybranych kryteriach (cel podróży, cena, zakwaterowanie, wyżywienie, itp) –
podobnie jak ma to miejsce na stronie internetowej.

13

Dokumentacja projektowa systemu informatycznego

c) Interfejs podwykonawcy

Podobnie jak to miało miejsce w przypadku aplikacji biura, każdy podwykonawca ma swoje konto

w systemie, przez co jest rozpoznawany przez aplikację. Każdy z usługodawców może mied nieco inny
panel, zgodny z typem działalności jaką prowadzi. Na przykład właściciel firmy transportowej nie
będzie posiadał pól odnośnie możliwości zakwaterowania czy ubezpieczenia.

W opcji rezerwacji środków własnych podwykonawca może sprawdzid jakie usługi rezerwuje u

nich centrala firmy. Wtedy podwykonawca może sprawdzid poprawnośd wprowadzonych informacji i
w zależności od nich podjąd pewne kroki. Może zażądad dodatkowych danych, bądź potwierdzid i
wykonad powierzoną mu pracę.

Sekcja zarządzanie turystami pozwala na wymianę danych klientów, celem dokonania rezerwacji

biletów bądź pokojów, a nawet informacje specjalne jak chociażby uczulenia klienta (celem
wykluczenia z posiłków czynników uczulających).

14

Dokumentacja projektowa systemu informatycznego

d) Interfejs zarządu

Celem szczególnym budowy interfejsu dla zarządu spółki było jego szczególne uproszczenie.

Dlatego zrezygnowaliśmy tu z budowy opartej na kontach, zamieniając ją na ogólny interfejs dla
wszystkich użytkowników. Mogliśmy to wykonad między innymi dlatego, że członkowie zarządu
głównie przeglądają informacje w sowim panelu (takie jak raporty i statystyki), a nie wprowadzają
zmian. Osoby zarządzające pracownikami (dział HR) ma jednak swój klucz, który daje im możliwośd
edycji pracowników (zatrudnienie, zmiana danych, zwolnienie). Jest to chroniona częśd aplikacji dla
zarządu.

Program dla zarządu na bieżąco wykonuje kopie zapasowe i snapshoty aplikacji w sposób

zautomatyzowany, celem odtworzenia stanu po nieprawidłowym użyciu. Program nie pozwala na
opuszczenie interfejsu bez potwierdzenia wprowadzonych zmian (ukazuje wtedy pełną listę zmian) i
wylogowania z aplikacji.

Aplikacja zarządu z założenia miała byd minimalistyczna. Liczba sytuacji, w której pracownik

wprowadza dane jest zredukowana do niezbędnego minimum. Symbole graficzne zostały zastąpione
dużymi, intuicyjnymi ikonami oraz zastosowano rozszerzony system potwierdzeo.

15

Dokumentacja projektowa systemu informatycznego

e) Aplikacja centrali

Każdy pracownik centrali ma własne konto w systemie. Zmiany wprowadzone przez centralę są

krytyczne z punktu widzenia działalności firmy, dlatego ważne jest śledzenie zmian oraz osób
odpowiadających za te zmiany.

W oknie finalizacji pracownik centrali może akceptowad oferty indywidualne nadesłane przez

biura terenowe. Kliknięcie w każdą ofertę przenosi do okna ze szczegółami oferty, w tym danymi o
podwykonawcach i wszystkich klientach, którzy złożyli zamówienie. Dzięki temu możliwe jest
śledzenie wpłat i wystawianie ewentualnych upomnieo o płatnościach, bądź ich anulowanie. Możliwe
jest także wysłanie zapytania do podwykonawcy (dane osoby kontaktowej są przechowywane w
bazie danych), celem omówienia szczegółów realizacji usługi.

Niezwykle istotnym jest panel tworzenia ofert. Pracownik układa w nim zakres wycieczki

uwzględniając aktualne trendy na rynku, możliwości dostarczenia usług przez podwykonawców, a
także inne subiektywne cechy. Może dodawad szczególne atrakcje, zdjęcia (każdy pracownik ma
dostęp do ogólnej bazy multimediów związanych z różnymi zakątkami świata). Pracownicy wyżsi
stażem ustalają ceny, rabaty i inne promocje. Tak utworzona oferta trafia do bazy danych i może byd
wyszukana przez klientów na stronie internetowej oraz przez pracownika biura w swojej aplikacji.
Dopuszcza się jednak nieznaczne opóźnienia związane z architekturą i ustaleniami optymalizacyjnymi
systemu, np. cache’owanie (szczególnie jeśli chodzi o stronę internetową).

W panelu finansowym dokonuje się przelewów dla podwykonawców, sprawdza płatności od

klientów i inne dane związane z finansami.

16

Dokumentacja projektowa systemu informatycznego

6. Protokoły komunikacyjne

W celu zapewnienia łączności i wymiany danych między jednostkami i urządzeniami stosowane

są protokoły komunikacyjne. Jest to zbiór ścisłych reguł i kroków postępowania. W sieci lokalnej
korzysta się z transmisji FastEthernet, natomiast w komunikacji z odległym hostem (poprzez sied
Internet) wykorzystuje się protokoły modelu TCP/IP. Z punktu widzenia użytkownika, nie jest istotne
jaki protokół w danej chwili jest wykorzystywany, jednak mając na uwadze konkretne problemy
projektowe w danych segmentach aplikacji, wyróżniamy niżej wymienione protokoły.

a) http – dzięki niemu możliwe jest przesyłanie hipertekstu (stron sieci Web) z serwera do

klienta. Można także przesyład żądania klienta. Jest to główny protokół, na którym oparty jest
interfejs Web dla użytkownika;

b) https – analogiczny protokół, używany celem szyfrowania transmisji między hostami; w

systemie wykorzystywany przy przesyłaniu wrażliwych danych, takich jaki dane logowania czy
informacje w momencie dokonywania płatności;

c) ftp – protokół transmisji plików; częśd plików może zostad udostępniona do pobrania przez

klientów, np. materiały reklamowe, broszury oraz multimedia;

d) pop3 i smtp – protokoły wykorzystywane przez pocztę elektroniczną;

7. Diagramy wdrożeniowe

7.1. Diagram komponentów

a) Strona i biuro

Komponenty dla strony internetowej i aplikacji biura są do siebie podobne. W obu sytuacjach

mamy do czynienia z szyfrowaniem podczas przesyłania „delikatnych” danych. Do wyboru jest
szyfrowanie RSA i DES. Także przy bazie danych, mimo użycia bazy firmy Oracle, system ma byd
kompatybilny z bazą firmy Microsoft.

Przy wyborze oferty korzysta się z katalogu ofert. Natomiast płatnośd i zamówienie wchodzą w

skład jednego komponentu – transakcji.

Przy aplikacji biura wyróżniono oddzielny komponent na graficzny interfejs użytkownika. GUI

bowiem ma byd niezależne od samej aplikacji. Dzięki temu obydwa komponenty będzie można
rozwijad oddzielnie – zmiana jednego nie będzie pociągała za sobą zmiany drugiego. Ułatwia to
modyfikowanie

interfejsu

zgodnie

z

oczekiwaniami

osób

korzystających

z

niego.

17

Dokumentacja projektowa systemu informatycznego



Strona internetowa



Biuro

18

Dokumentacja projektowa systemu informatycznego

b) Centrala oraz podwykonawcy

Podobnie jak w przypadku wyżej, także tutaj wydzielono komponent graficznego interfejsu

użytkownika. Aplikacja ma dostęp do katalogu ofert, ale przede wszystkim komponent ofert daje
możliwośd ich dodawania i modyfikacji. Umożliwia także akceptację ofert indywidualnych
nadesłanych przez biura.

Na diagramie uwzględniono także rolę podwykonawców w systemie. Zaznaczono możliwośd

wzajemnej komunikacji oraz organizowania finansów. Odpowiada za nią komponent transakcji.
Realizuje ponadto transakcje do zamówieo klientów, w tym płatności, sprawdzanie ich poprawności i
ewentualne wystawianie upomnieo.

Także na tym diagramie uwzględniono, że częśd systemu centrali ma byd nie tylko kompatybilna z

bazą danych firmy Oracle, ale także z systemem Microsoft SQL Server.

19

Dokumentacja projektowa systemu informatycznego

c) Zarząd

Zmianą w diagramie komponentów dla zarządu są dodane komponenty pracownik i raport.

Generowany raport może byd przeglądany bezpośrednio w aplikacji. Komponent pracownik
dostarcza możliwości dodania, zmiany, usunięcia, bądź zlecenia wypłaty.

Również tutaj graficzny interfejs jest wydzielony z aplikacji.

7.2. Diagram rozlokowania

Diagramy rozlokowania zwane są też ogólnie diagramami wdrożeniowymi. Umożliwiają opis

fizycznej alokacji poszczególnych komponentów aplikacji – na przykład w serwerowniach głównych,
serwerowniach zapasowych, czy też miejscach użytkowania aplikacji na urządzeniach statycznych i
urządzeniach mobilnych.

20

Dokumentacja projektowa systemu informatycznego

a) Obsługa klienta

Komputer klienta łączy się z serwerem obsługi poprzez stos protokołów TCP/IP. Komunikacja

między serwerami firmy odbywa się poprzez FastEthernet.

Klient może się zarejestrowad oraz przeglądad oferty stworzone przez centralę. Po wybraniu

satysfakcjonującej go wycieczki może ją zamówid poprzez odpowiedni formularz. Wszystkie zmiany
zapisywane są w bazie danych. Komputer centrali i serwer obsługi klienta są połączone z centralną
bazą danych.

21

Dokumentacja projektowa systemu informatycznego

b) Biuro

Pracownik biura może łączyd się bazą danych centrali firmy poprzez zbiór protokołów TCP/IP.

Może wyszukad oferty oraz zamówid ofertę, która podoba się klientowi. Może także, w zależności od
potrzeb złożyd specjalne zamówienie.

Pracownik może także drukowad oferty klientowi celem zapoznania się z nimi w domu. Gdy się

zdecyduje, możliwe jest wydrukowanie paragonu na drukarce, która połączona jest z systemem.
Wykorzystywany jest także program księgowy GTSubiekt.

22

Dokumentacja projektowa systemu informatycznego

c) Podwykonawcy

Podwykonawcy również komunikują się poprzez TCP/IP. Dane przez nich aktualizowane zapisują

się w bazie danych dotyczących ich zasobów, natomiast sami pobierają zamówienia i informacje o
klientach.

Każde żądanie przechodzi jednak przez serwer centrali celem zapewnienia poprawności i

spójności wymienianych danych.

23

Dokumentacja projektowa systemu informatycznego

d) Transakcje

W transakcjach pośredniczy serwer banku. Artefakt banku na schemacie pełni rolę poglądową,

gdyż każdy bank może inaczej implementowad swój system.

e) Zarząd

Komputery zarządu stoją w siedzibie firmy, dlatego komunikacja odbywa się przez FastEthernet.

Zarząd nie ma dostępu do systemu z zewnątrz.

24

Dokumentacja projektowa systemu informatycznego

8. Harmonogram implementacji

Budowa systemu informatycznego dla biura podróży Husajn została podzielona na następujące

etapy:

Implementacja bazy danych

Czerwiec 2010

Fizyczne lokowanie serwerów i łącz

Czerwiec – lipiec 2010

Implementacja modelu (MVC) – podstawowych klas modelu

Lipiec – wrzesieo 2010

Implementacja pozostałych elementów systemu, łączenie

Sierpieo – październik 2010

Implementacja interfejsów użytkownika

Listopad 2010

Testy wewnętrzne

Listopad 2010

Wdrożenie

Pocz. grudnia 2010

Testy, zapełnianie bazy danych, tworzenie ofert

Grudzieo 2010

Start komercyjny

Początek 2011

9. Plan testów

a) Testowanie bazy danych

Tworzona baza danych zostanie przetestowana pod względem bezpieczeostwa oraz dbałości o

niski poziom redundancji (nadmiarowości) przechowywanych danych. Dostęp do wglądu w bazę
danych powinien mied tylko pracownik działu IT, który ma również możliwośd łatwej edycji zawartych
w niej rekordów. W celu zabezpieczenia przed nieumyślnym skasowaniem danych sprawdzamy
funkcjonalnośd i działanie modułu umożliwiającego tworzenie kopii zapasowych. Moduł ten ma
wbudowaną funkcję autowywoływania przed każdą próbą edycji danych. Kopię można ustawid na
wykonywanie backupu całościowego lub przyrostowego. Naszym zadaniem jest zbadanie wszystkich
możliwości obejśd tego modułu oraz miejsc w poszczególnych aplikacjach, które łączą się z bazą
danych, aby zapisane dane dostępowe do bazy były niedostępne do ewentualnego podglądu.

Wykorzystane zostanie także narzędzie do automatyzowania procesu wykonywania zapytao

testowych. W ten sposób system zarządzania bazą danych zostanie „zasypany” dużą liczbą zapytao.
Dzięki temu zbadamy nie tylko poprawnośd, ale także odpornośd systemu na duży ruch.

b) Testowanie aplikacji przeznaczonych dla pracowników

Dzięki aplikacji przeznaczonej dla pracownika, ma on możliwośd dodania oferty, przyjęcia

zamówienia. Testując sprawdzamy odpornośd formularzy na wprowadzane dane. Ewentualne błędy,
przy automatycznym zapisie do bazy danych, mogłyby spowodowad duże konsekwencje. Badamy
odpornośd na wprowadzanie danych specyficznych, bądź danych, które w dane pole wprowadzone
byd nie powinne. Tego typu testy dotyczą każdej aplikacji. Należy ponadto sprawdzid, czy dane
przesyłane między biurem a centralą nie ulegają zniekształceniu bądź przekłamaniu. Tutaj także
okazuje się pomocna aplikacja do automatyzowania procesu testowania.

25

Dokumentacja projektowa systemu informatycznego

c) Testowanie aplikacji internetowej dla klientów

Klient ma możliwośd zamówienia oferty przez Internet. Jest to aplikacja najbardziej narażona na

ataki z zewnątrz, ponieważ jest dostępna dla praktycznie wszystkich użytkowników. Podobnie jak
przy aplikacji pracowniczej sprawdzaliśmy aplikację w przypadkach wprowadzania złośliwych danych,
które mogą spowodowad incydenty bezpieczeostwa.

Aplikacja WWW jest narażona na specyficzne ataki, chociażby wstrzyknięcia kodu HTML, JS w

formularz i zapisanie ich w bazie. Atak typu XSS (Cross Site Scripting) może dad początek phishingowi
poprzez podmianę strony bądź przekserowanie na stronę osoby atakującej. Sprawdzając każde pole
formularza zabezpieczamy klientów przez kradzieżą tożsamości internetowej, a nawet danych
dotyczących karty płatniczej.

Należy zwrócid uwagę na ataki CSRF (Cross Site Request Forgery), które mogą doprowadzid do

nieświadomego przesyłania przez użytkownika do serwera żądania spreparowanego przez osoby o
wrogich zamiarach. Trzeba sprawdzid mechanizm potwierdzeo przy zamówieniach oraz poprawnośd
generowania tokenów (transparentnych dla użytkownika) przy każdorazowym żądaniu strony. Należy
ograniczyd metodę GET do przesyłania wrażliwych danych.

Trzeba ponadto sprawdzid podatnośd aplikacji Web na ataki Session Poisoning oraz Session

Fixation. Mogą one doprowadzid do przejęcia bądź uszkodzenia sesji użytkownika, a co za tym idzie
uzyskania dostępu do jego konta.

Szczególnie krytycznym z punktu widzenia aplikacji internetowej byłby błąd SQL Injection. Na

przetestowanie strony pod kątem podatności na niego należy przeznaczyd wiele czasu i możliwości.
Trzeba wykorzystad narzędzia wspomagające testy i automatyzujące tworzenie szkodliwych żądao.

Ponadto trzeba się upewnid, że wszystkie pliki, które nie mają byd bezpośrednio dostępne dla

użytkownika znajdują się poza katalogiem public_html serwera.

d) Testowanie modułu przelewów

Moduł przelewów jest jedną ze składowych aplikacji internetowej przeznaczonej dla klientów

oraz podwykonawców. Naszym zadaniem w tej fazie testów jest przetestowanie zabezpieczeo oraz
reakcje na różne dane, które zostaną wpisane nieprawidłowo. Należy także sprawdzid, czy system
banku prawidłowo reaguje na żądania projektowanego systemu, czy nie ma przekłamao w kwotach
przelewów ani przy rozpoznawaniu użytkownika zlecającego przelew.

e) Testowanie aplikacji dla podwykonawców

Natychmiastowy kontakt z podwykonawcą jest niezbędny do wykonywania koniecznych zadao

przy realizacji poszczególnych zamówieo. Sprawdzenie automatyzacji działania oraz zabezpieczenie
kanałów komunikacyjnych jest w tym wypadku głównym zadaniem. Musimy sprawdzid co się stanie
przy wyczerpaniu środków do realizacji zadania z jednej lub drugiej strony.

26

Dokumentacja projektowa systemu informatycznego

Należy także sprawdzid reakcje na dane niestandardowe oraz potencjalnie niebezpieczne. Trzeba

przetestowad moduł odpowiedzialny za komunikację, czy nie ma zmian w przesyłanych informacjach
oraz czy podwykonawcy mają dostęp tylko do tych danych, do których udzielono im dostępu.

10. Podsumowanie

Niniejszy dokument podsumowuje fazy przedimplementacyjne ściśle definiując i opisując

projektowany system. Każde zagadnienie zostało przeanalizowane, a dostarczone diagramy w sposób
intuicyjny i jednoznaczny przedstawiają system z różnych punktów widzenia. Każdy komponent
systemy został przeanalizowany, a wnioski zapisane. Dzięki temu system jest gotowy do
implementacji, nie pozostawiając niejednoznaczności i niedomówieo w kwestii jego budowy i
wymagao funkcjonalnych, niefunkcjonalnych i dziedzinowych.

Zostały omówione także fazy postimplementacyjne, w tym wszystkie protokoły jakie zostaną

użyte do komunikacji między wszystkimi komponentami. Przeanalizowano także fizyczną budowę i
opis fizycznej alokacji poszczególnych komponentów aplikacji – na przykład w serwerowniach
głównych, serwerowniach zapasowych, czy też miejscach użytkowania aplikacji na urządzeniach
statycznych i urządzeniach mobilnych.

Przygotowano także plan testów, które zostaną wykonane przez wdrożeniem systemu.

Sprawdzają one podatnośd na niestandardowe użycie oraz potencjalne incydenty bezpieczeostwa.