1 Dokumentacja projektowa systemu informatycznego
KittyTeam
SYSTEM INFORMATYCZNY OBSA
UGI
BIURA PODRÓŻY
Dokumentacja projektowa
Warszawa, 2010
2 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.
3 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.
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ądz

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

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ądz
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ądz
potwierdzid i
wykonad powierzonÄ… mu pracÄ™.
Sekcja zarządzanie turystami pozwala na wymianę danych klientów, celem dokonania rezerwacji
biletów bądz
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ądz
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óz
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ądz
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  paz
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ądz
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ądz
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Ä…dz
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ądz
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.