Dokumentacja analityczna systemu informatycznego

1

KittyTeam

SYSTEM INFORMATYCZNY OBSŁUGI

BIURA PODRÓŻY

Dokumentacja analityczna

Warszawa, 2010

Dokumentacja analityczna systemu informatycznego

2

Spis treści

1. Wstęp

2. Architektura systemu

2.1. Określenie architektury;

2.2. Własności architektury;

3. Analiza – podejście obiektowe

3.1. Diagram klas;

3.2. Diagram czynności (aktywności);

3.3. Diagram sekwencji;

3.4. Diagram stanów;

4. Analiza – podejście strukturalne

4.1. Diagram przepływu danych;

5. 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 analityczna systemu informatycznego

3

1. Wstęp

Niniejszy dokument stanowi podsumowanie fazy analizy systemu informatycznego dla biura

podróży „Husajn”. W pierwszej części definiuje architekturę systemu, a w kolejnych za pomocą
diagramów metodyki obiektowej i strukturalnej analizuje system. Dzięki temu uzyskujemy jasny i
zrozumiały mechanizm projektowania znacznie ułatwiający tworzenie systemu od podstaw.

2. Architektura systemu

2.1. Określenie architektury

Jeśli z architektury wyróżnimy samo przetwarzanie danych i dostęp do nich, uzyskamy

pewien centralny punkt (usługodawcę) i klientów korzystających z jego zasobów (usługobiorców).
Punktem skupiającym jest centrala, która stanowi dostęp do bazy danych, na której opiera się
system. Wszystkie dołączone interfejsy korzystają z tych samych metod (lecz polimorficznych) do
operowania na bazie. W tym kontekście używana jest zatem architektura SOA (Services Oriented
Architecture).

Architekturę systemu można również podzielid w kontekście warstw systemu. W

omawianym przypadku mamy do czynienia z architekturą trójwarstwową typu klient-serwer, gdzie
interfejs użytkownika, przetwarzanie danych i składowanie danych są rozwijane w postaci osobnych
modułów. Architektura tego typu pozwala aktualizowad lub zastępowad poszczególne moduły
niezależnie od siebie, w miarę jak zmieniają się warunki techniczne.

Najwyższą warstwą jest warstwa prezentacji (interfejsu), której rolą jest komunikacja między

maszyną, a człowiekiem. To ona odbiera polecenia od użytkownika oraz przedstawia mu wyniki w
zrozumiałej dla niego formie. Niżej znajduje się warstwa logiki biznesowej, która odbiera żądania i
wykonuje akcje, a także zwraca wyniki akcji. Najniżej znajduje się warstwa danych, gdzie wszystkie

Dokumentacja analityczna systemu informatycznego

4

informacje są odbierane, zachowywane, a w razie potrzeby wydobywane i przekazywane do warstwy
wyższej.

2.2. Własności architektury



Efektywnośd – krytyczne operacje znajdują się w niewielkiej liczbie podsystemów aby
zminimalizowad komunikację; przykładem jest przygotowywanie ofert (lub
akceptacja ofert specjalnych), które wykonuje tylko centrala. Oferty stanowią
bowiem główny mechanizm usługowy przedsiębiorstwa. Pozostałe jednostki mogą
jedynie wyświetlad przygotowane lub zaakceptowane oferty;



Zabezpieczenie – najbardziej krytyczne elementy ukryte są w warstwie wewnętrznej.
Pracownicy nietechniczni mają do niej dostęp jedynie przez swój interfejs, który
umożliwia jedynie dostęp do danych niezbędnych na danym stanowisku. Bezpośredni
dostęp do bazy ma jedynie dział IT;



Bezpieczeostwo – operacje dotyczące bezpieczeostwa nie mogą byd wykonywane w
warstwach wyższych; za bezpieczeostwo odpowiada dział IT mając bezpośredni
dostęp do krytycznych elementów systemu; do ich zadao należy pielęgnacja i

Dokumentacja analityczna systemu informatycznego

5

aktualizacja oprogramowania, tworzenie kopii zapasowych, wprowadzenie systemów
autoryzacji dla pracowników oraz wykonywanie (bądź zlecanie wykonywania)
audytów bezpieczeostwa i testów penetracyjnych;



Dostępnośd – celem zapewnienia dostępności należy zapewnid komponenty
nadmiarowe. Oczywiście bez nich system w warunkach idealnych pracowałby
prawidłowo, niemniej jednak nie wolno polegad na „warunkach idealnych”;



Zdatnośd do pielęgnacji – między innymi podział na warstwy gwarantuje
drobnoziarnistośd, dzięki której system składa się z samodzielnych komponentów;
dzięki pierwszemu podziałowi można modyfikowad aplikacje poszczególnych
jednostek organizacyjnych równolegle: zmiana dla jednej jednostki nie pociąga za
sobą zmian dla pozostałych;

3. Analiza – podejście obiektowe

3.1. Diagram klas

Na następnej stronie przedstawiono uproszczony diagram klas przedstawiający wzajemne

relacje pomiędzy poszczególnymi elementami systemu. Diagram o konkretne metody zostanie
rozwinięty w kolejnej fazie projektowania systemu.



Klasa JednostkaOrganizacyjna jest klasą abstrakcyjną, z której dziedziczą wszystkie
klasy konkretne elementów systemu. Zawiera ona podstawowe wspólne cechy i akcje
dla wszystkich aktorów systemu. To właśnie klasy, które z niej dziedziczą
bezpośrednio będą stanowid najwyższą warstwę architektury – warstwę interfejsu;



Kolejną klasą abstrakcyjną jest Osoba, z której dziedziczą Pracownik i Klient. Dzięki
tym dwóm klasom możliwa jest autoryzacja, logowanie działao konkretnych osób i
powiązywanie ich z zamówieniami, a także składowanie danych niezbędnych do
realizacji zamówieo;



Z klasą Pracownik związana jest klasa Wypłata będąca z nią w relacji kompozycji.
Wyplata bowiem dotyczy konkretnego pracownika i nie może jako taka bez niego
istnied;



Niezwykle ważną z punktu widzenia systemu jest Oferta. Stanowi abstrakcję usługi
oferowanej przez biuro, a wraz z klasami Zamówienie (agregacja) i Płatnośd
(kompozycja) jest częścią logiki biznesowej, stąd znajduje się w drugiej warstwie
architektonicznej;



Pozostałą częścią logiki biznesowej jest StatusZamówienia wraz ze swoją klasą
asocjacyjną RealizowaneZamówienie. Łączy ona ofertę, centralę i podwykonawców.
Centrala składa zamówienie na realizację oferty przez podwykonawcę, a
podwykonawca pobiera zgłoszenie i niezbędne dane dotyczące oferty;

Dokumentacja analityczna systemu informatycznego

6

Dokumentacja analityczna systemu informatycznego

7

3.2. Diagram czynności (aktywności)

Diagram aktywności służy do modelowania czynności i zakresu odpowiedzialności elementów

bądź użytkowników systemu. Opisuje działania związane w wieloma obiektami, pomiędzy którymi
może występowad komunikacja przy wykonywaniu czynności.

a) Składanie zamówienia;

Pierwszy z niżej zamieszczonych diagramów prezentuje poszczególne kroki przy składaniu

zamówienia przez klienta. Proces rozpoczyna się wyświetleniem oferty, którą wybiera klient, po czym
przechodzi się przez etapy złożenia zamówienia, płatności i kooczy na rezerwacji środków
podwykonawców. Diagram uwzględnia fakt niepełnej lub nieprawidłowej płatności przez klienta oraz
wystawienie odpowiedniego upomnienia.

b) Zamówienie specjalne;

Dokumentacja analityczna systemu informatycznego

8

Zgodnie z założeniami systemu pracownik biura może wystąpid o zamówienie specjalne,

którego nie ma w standardowym katalogu ofert udostępnionym przez centralę. Dzieje się tak, gdy
mówimy o wycieczkach na zamówienie, wyprawach szkolnych i innych tego typu zamówieniach.
Takie zamówienie, mimo iż układane przez biuro terenowe, również musi przejśd przez centralę
celem rezerwacji środków podwykonawców, takich jak transport, zakwaterowanie. Poniższy diagram
przedstawia kolejne czynności tego procesu.

Dokumentacja analityczna systemu informatycznego

9

c) Realizacja zadao zarządu;

System zapewnia osobom z zarządu i kadr dostęp do danych pracowników. Można dodawad nowych lub edytowad bądź usuwad istniejących. Za

pomocą interfejsu, zarząd może także ustalad wartośd wypłat dla poszczególnych pracowników. Jedną z najistotniejszych z punktu widzenia władz firmy są
raporty i statystyki, na podstawie których realizowane są nowe strategie firmy. Poniższy diagram prezentuje wszystkie czynności, które wykonywane są
przez zarząd.

Dokumentacja analityczna systemu informatycznego

10

d) Tworzenie ofert przez centralę;

Centrala ma bardzo ważne zadania. Najważniejszym jest tworzenie ofert na podstawie

dostępności podwykonawców i aktualnych trendów na rynku. Centrala po stworzeniu ofert
rezerwuje środki u podwykonawców oraz zapewnia im płatnośd. Po zaksięgowaniu wpłaty klienta
zamówienie jest przekazywane do realizacji.

Centrala także odpowiada na zamówienia specjalne. Sprawdza dostępnośd podwykonawców

na dane zamówienie i przekazuje im je.

Dokumentacja analityczna systemu informatycznego

11

e) Czynności podwykonawcy;

Poniższy diagram prezentuje czynności jakie wykonuje podwykonawca gdy otrzyma

zamówienie. Kiedy jest to wymagane, pobierana jest lista uczestników wycieczki. Centrala musi
ponadto otrzymad potwierdzenie realizacji zamówienia przez usługodawcę. Model biznesowy
przedsiębiorstwa zakłada, że podwykonawca realizuje swoje zadanie po otrzymaniu przedpłaty.
Poniższy diagram uwzględnia to wymaganie.

Dokumentacja analityczna systemu informatycznego

12

f) Zadania należące do kompetencji działu IT;

Dział IT dba o bezpieczeostwo systemu, jego aktualnośd i dostępnośd. Poniższe diagramy

przedstawiają sekwencję czynności, które realizuje zespół techników.



Modyfikacja systemu;

Dokumentacja analityczna systemu informatycznego

13



Tworzenie kopii zapasowych i bezpośrednia praca na bazie danych;

Dokumentacja analityczna systemu informatycznego

14

3.3. Diagram sekwencji;

Diagram sekwencji służy do modelowania dynamicznych aspektów systemu. Uwypukla on

szczególnie perspektywę czasu, dzięki czemu pozwala określid kolejnośd występowania komunikatów
w czasie.

a) Złożenie zamówienia przez klienta;

Oczywistym jest, że płatnośd musi nastąpid po złożeniu zamówienia, a zamówienie dotyczy

konkretnej oferty. Poniższy diagram przedstawia kolejnośd, w jakiej klient wybiera ofertę i dokonuje
zakupu wycieczki korzystając ze swojego interfejsu (strona sieci Web).

b) Złożenie zamówienia przez biuro;

Podobnie wygląda złożenie zamówienia za pośrednictwem biura terenowego. Można jednak

pominąd system bankowy, gdyż zakłada się, że klient płaci gotówką, a pracownik przyjmujący
płatnośd jest w stanie potwierdzid otrzymanie wpłaty.

Dokumentacja analityczna systemu informatycznego

15

c) Ustalanie ofert przez centralę;

Głównym zadaniem centrali jest ustalenie oferty. Pracownik, który ją układa, zapisuje wynik

swojej pracy do bazy danych. System może ją odrzucid, gdy uwzględnia wymagania niefunkcjonalne i
wymagania dziedzinowe, które dotyczą systemu. Do odrzucenia może dojśd na skutek
nieodpowiedniego dobrania środka transportu do celu podróży (pojazd kołowy -> podróże
zamorskie), dłuższy czas podróży niż pobytu, itp.

Dokumentacja analityczna systemu informatycznego

16

d) Komunikacja z podwykonawcami;

Poniższy schemat przedstawia rozłożenie w czasie komunikacji z podwykonawcami.

Oczywistym jest, że najpierw dane dotyczące zapotrzebowania muszą byd zapisane w bazie danych, a
następnie podwykonawca za pomocą swojego interfejsu może je pobrad. Jeśli jest to wymagane,
pobierane są też dane dotyczące klientów (przypadki tego typu wyszczególniono w dokumentacji
specyfikacji).

e) Wynagrodzenie dla podwykonawcy;

Poniższy diagram przedstawia sekwencję kroków zlecenia przelewu dla podwykonawcy za

konkretną usługę (przewóz, zakwaterowanie, wyżywienie, itp.).

Dokumentacja analityczna systemu informatycznego

17

f) Uaktualnienie danych odnośnie posiadanych środków;

Z podobnych sekwencji składa się uaktualnienie przez podwykonawcę informacji o środkach,

które może zapewnid. Dane muszą byd uaktualniane, gdyż centrala na ich podstawie tworzy oferty.

g) Modyfikacja danych pracowniczych;

Są to sekwencje wykonywane przez zarząd. W swoim interfejsie mogą dodad, zmodyfikowad

lub usunąd dane dotyczące pracownika. Zmiana musi byd potwierdzona odpowiednim komunikatem.

Dokumentacja analityczna systemu informatycznego

18

h) Generowanie raportów;

Dane dotyczące raportu muszą zostad zwrócone z bazy danych, więc nie będzie

wystarczającym w tym przypadku zwrócenie tylko komunikatu odnośnie realizacji akcji. Raport jest
tworzony w drugiej warstwie architektonicznej, a wyświetlany w warstwie prezentacji.

3.4. Diagram stanów

Diagram ten pokazuje przede wszystkim możliwe stany obiektu oraz przejścia, które

powodują zmianę tego stanu. Tym samym tworzony jest cykl życia obiektu, który może byd tym
istotniejszy w procesie wytwarzania oprogramowania, im więcej jest możliwych stanów obiektu.

a) Stany systemu przy zamawianiu wycieczki przez klienta;

Użytkownik może wielokrotnie wyświetlad kolejne oferty, zmieniając soje wymagania.

System musi byd na to przygotowany. Ponadto należy uwzględnid możliwośd rezygnacji klienta nawet
po uiszczeniu opłaty. Wtedy system ma zlecid zwrot zapłaconej kwoty (byd może potrąconej o
zaliczkę).

Dokumentacja analityczna systemu informatycznego

19

b) Zamawianie przez pracownika biura;

Różnicą w stosunku do poprzedniego przypadku jest to, że pracownik może wprowadzad

zamówienie i przyjmowad opłatę równolegle. Tu nie mamy do czynienia z możliwością zwrotu
zapłaconej kwoty po rezygnacji klienta, gdyż prawo zapewnia klientowi możliwośd rezygnacji z usługi
w ciągi 10 dni, ale jeśli produkt zamówiony był na odległośd. Tutaj klient jest w siedzibie biura i
fizycznie podpisuje umowę. Stąd brak tutaj stanu Anulowane.

c) Finalizowanie przez centralę;

Centrala w momencie zebrania odpowiedniej liczby uczestników wycieczki finalizuje ją

potwierdzając usługi u podwykonawców.

Dokumentacja analityczna systemu informatycznego

20

d) Tworzenie ofert;

Centrala w momencie ustalania oferty może współbieżnie wybierad odpowiednie parametry

usługi oraz organizowad podwykonawców. Niekiedy te dwa stany mogą byd zależne od siebie, ale w
ogólności przyjmuje się, że można je zrównoleglid.

e) Stany aplikacji zarządu;

Wszystkie czynności związane z obsługą pracowników można zrównoleglid. Dopiero zapis

zmian wykonuje się sekwencyjnie.

Dokumentacja analityczna systemu informatycznego

21

4. Analiza – podejście strukturalne

4.1. Diagram przepływu danych (DPD, DFD);

Diagramy te ilustrują jak dane przepływają od jednego do drugiego procesu i są

przekształcane w miarę swojej wędrówki przez cały ciąg. Dane wejściowe przepływają przez te
przekształcenia do chwili wytworzenia z nich danych wyjściowych.

a) Klient

Pierwszy z diagramów przedstawia cały cykl życia oferty od jej utworzenia przez centralę,

przez jej kupno przez klienta, aż do realizacji przez podwykonawców.

Dokumentacja analityczna systemu informatycznego

22

b) Biuro

Kolejny diagram przedstawia analogiczną sytuację, ale z punktu widzenia biura. Tu również

wychodzi się od oferty, poprzez zamówienie i jego realizację.

c) Zespół IT

Prace zespołu IT rozpoczynają się zawsze od autoryzacji. Jest to szczególnie ważne, gdyż ma

on dostęp do krytycznych elementów systemu.

Dokumentacja analityczna systemu informatycznego

23

d) Zarząd;

Jak można zauważyd akcje realizowane przez zespół IT i zarząd/kadry są niezależne od

pozostałych komponentów. Natomiast powodzenie akcji realizowanych przez klienta i biuro zależy od
centrali.

5. Podsumowanie

Dzięki analizie systemu informatycznego można ustalid jego architekturę. Ma to kluczowe

znaczenie w procesie projektowania, gdyż od dobrego zdiagnozowania architektury zależy późniejsza
łatwośd pielęgnacji systemu, a także jego niezawodnośd i bezpieczeostwo.

Projektowany przez KittyTeam system informatyczny obsługi biura podróży „Husajn” został

przeanalizowany zgodnie z podejściem obiektowym i strukturalnym. Wcześniej jednak dokonano
zdiagnozowania jego architektury. Dzięki rozróżnieniu różnych punktów widzenia system można
łatwiej zaprojektowad, jest prostszy i łatwiejszy w modyfikacji. Klientowi zależało na łatwości
wprowadzania zmian, gdyż jego wchodząca na rynek firma nie ma dużego doświadczenia w
organizacji wycieczek, a co za tym idzie system w ciągu najbliższych miesięcy od wdrożenia może
przechodzid wiele modyfikacji.