Dokumentacja projektowa systemu informatycznego

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

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.

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.

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.

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.

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.

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ą.

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.

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).

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.

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.

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

oczekiwaniami

osób

korzystających

niego.

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.

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.

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.

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.

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.

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.

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.

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.

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.