plik

Dokumentacja analityczna systemu informatycznego

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.