FAKULTET ORGANIZACIONIH NAUKA
Laboratorija za informacione sisteme
STRUKTURNA SISTEMSKA
ANALIZA
(Materijal za interne kurseve. Sva prava zadržava Laboratorija za informacione sisteme)
Beograd, oktobar 2000.
1. U V O D
Strukturna sistemska analiza (SSA) je jedna potpuna metodologija za specifikaciju informacionog
sistema, odnosno softvera. Ona se na razli
č
ite na
č
ine može povezati sa metodama drugih faza u neku
specifi
č
nu metodologiju celokupnog razvoja IS. Tako na primer, ona može biti polazna osnova za metodu
Strukturnog projektovana programa, ili projektovanja logi
č
ke strukture baze podataka metodom
normalizacije, ili se može tretirati kao metodološki postupak dekompozicije nekog sistema na podsisteme
sa ciljem da se, nalaženjem modela podataka podsistema i njihovom integracijom, do
đ
e do potpunog
modela podataka posmatranog sistema. Upravo zbog mogu
ć
nosti njene raznovrsne primene, metoda SSA
se ovde tretira kao jedinstvena, samosvojna metoda, dok se u drugim materijalima pokazuje kako se ona
koristi u pojedinim koracima Standardne metodologije razvoja informacionih sistema.
Potpuna,
ta
č
na, formalna i jasna specifikacija IS, ili kako se to obi
č
no kaže, specifikacija zahteva
korisnika, zahteva koje budu
ć
i sistem treba da zadovolji, predstavlja bitan preduslov za uspešno dalje
projektovanje i implementaciju sistema. O
č
igledno je zbog
č
ega specifikacija IS treba da bude potpuna i
ta
č
na. Zahtev da specifikacija bude formalna iskazuje se zbog toga što je formalna specifikacija osnov za
"transformaciono" projektovanje i implementaciju, za atomatizovano generisanje baze podataka i
programa iz nje, odnosno za koriš
ć
enje CASE sistema. Zahtev da specifikacija bude jasna iskazuje se
zbog toga što u specifikaciji IS u velikoj meri u
č
estvuju korisnici sitema, neinformati
č
ari, pa jezik
specifikacije mora biti i njima prihvatljiv. Originalna SSA
č
iji su tvorci Yourdon i njegovi saradnici
(DeMarco i drugi) poseduje veoma jednostavne, grafi
č
ke, pa samim tim i jasne koncepte. Ovde su svi ovi
koncepti zadržani, a strožija formalizacija je dodata samo za opis strukture tokova i skladišta podataka, da
bi se obezbedio specifi
č
an transformacioni razvoj IS koji Standardna metodologija zagovara.
Kao što je ve
ć
ranije re
č
eno, specifikacija IS treba da prikaže (potpuno, ta
č
no, formalno i jasno)
šta budu
ć
i informacioni sistem treba da radi. Veoma je bitno odmah ista
ć
i da specifikacija IS prikazuje
ŠTA
IS treba da da, a ne i
KAKO
to treba da ostvari. O
č
igledno je da prerano definisanje "kako", odnosno
davanje nekih projektantskih rešenja u okviru specifikacije, ograni
č
ava kasniji mogu
ć
i izbor
(optimizaciju) na
č
ina implementacije sistema. Odgovor na pitanje "
kako
" daje se za konkretno okruženje,
za definisanu tehnologiju i organizaciju u kojoj se sistem implementira. Da specifikacija ne bi sadržala
tehnološki i organizaciono ograni
č
ena rešenja, obi
č
no se kaže da ona treba da opiše funkcionisanje IS u
"idealnoj tehnologiji", gde prakti
č
no nikakva ograni
č
enja ne postoje. Ako je specifikacija ovako zadata,
onda je, pre prelaska na dalje projektovanje, neophodno da se definišu sva ograni
č
enja koja name
ć
e
okolina u kojoj se sistem implementira.
Zbog toga specifikacija IS treba da poseduje slede
ć
a dva dela:
(
I
)
funkcionalnu specifikaciju u kojoj se opisuje budu
ć
i IS u "idealnoj tehnologiji" i
(
II
) nefunkcionalnu specifikaciju koja definiše sva ograni
č
enja implementacione okoline.
SSA u potunosti obuhvata samo funkcionalne specifikacije, dok nefunkcionalne samo delimi
č
no
pokriva prikazuju
ć
i tokove podataka u novoimplementiranom sistemu. Ostali deo nefunkcionalnih
specifikacija obi
č
no predstavlja samo nabrajanje zahtevanih performansi budu
ć
eg IS i ograni
č
enja
implementacione okoline.
SSA posmatra informacioni sistem kao funkciju (proces obrade) koja, na bazi ulaznih, generiše
izlazne podatke. Ulazni podaci se dovode u proces obrade, a izlazni iz njega odvode preko tokova
podataka. Tok podataka se tretira kao vod ili kao pokretna traka kroz koji stalno teku ili koja stalno nosi
podatke na najrazli
č
itijim nosiocima - papirni dokumenti, niz poruka koje
č
ovek unosi preko tastature
terminala, "paket" informacija dobijen preko neke telekomunikacione linije ili sli
č
no. Imaju
ć
i u vidu
zahtev da specifikacija treba da se oslobodi svih implementacionih detalja od interesa su samo sadržaj i
struktura ulaznog toka, a ne i medijum nosilac toka.
2
SPOLJNI_
OBJEKAT_1
PROCES_A
1.
TOK_PODATAKA_6
PROCES_B
2.
SKLADI[TE_PODATAKA
SPOLJNI_
OBJEKAT_2
TOK_PODATAKA_2
TOK_PODATAKA_3
TOK_PODATAKA_5
TOK_PODATAKA_4
TOK_PODATAKA_1
Slika 1. Osnovni koncepti DTP
2. DIJAGRAMI TOKA PODATAKA
U prethodnom delu su definisani osnovni koncepti dijagrama toka podataka (Slika 1). Dijagram
toka podatka (DTP) predstavlja model sistema koji sadrži
č
etiri osnovne komponente: procese obrade
podataka (aktivne komponente sistema), objekte okruženja (interfejse) sa kojima sistem komunicira,
skladišta podataka koje procesi koriste i/ili ažuriraju i tokove podataka koji povezuju ostale komponente
sistema u celinu.
Osnovne karakteristike DTP-a su:
- jasna grafi
č
ka specifikacija, pogodna za komunikaciju sa korisnikom,
- istovremeno jasan i detaljan opis sistema, primenom metode apstrakcije tako da se sistem na
višim nivoima apstrakcije opisuje uopšteno, a na nižim detaljno.
2.1. Pravila kreiranja (sintaksa) dijagrama toka podataka
Pri kreiranju dijagrama tokova podataka moraju se poštovati slede
ć
a pravila:
(
I
) Kao što je re
č
eno, tok podataka se može zamisliti kao pokretna traka u fabrici, ili cev kojom do
skladišta podataka, procesa ili spoljneg objekta teku struktuirani podaci (razli
č
ita dokumenta, formulari,
tekstovi, knjige,
č
asopisi i sli
č
no). Tok podataka ostvaruje vezu izme
đ
u ostalih komponenti sistema i na
DTP-u se predstavlja imenovanim, orijentisanom linijom.
(
II
) Tok podataka mora da ima izvor i ponor. Bilo koja druga komponeneta DTP može da bude izvor
ili ponor. Me
đ
utim, za jedan tok, bilo izvor, bilo ponor (bilo oba) mora da bude proces. Drugim re
č
ima,
tokovima se ne mogu neposredno povezati dva skladišta, dva interfejsa, ili skladište i interfejs. Na slici 2 i
slici 3 prikazani su primeri ovih nedozvoljenih situacija, za koje se mogu dati slede
ć
i komentari:
- Nekoreketni delovi DTP-a na slikama 2a i 2c su istovremeno i nelogi
č
ni, jer u realnom
sistemu spoljni objekti nemaju direktan pristup skladištima podataka, ve
ć
to obavljaju procesi
sistema. Slike 2b i 2d pretstavljaju korektne reprezentacije situacija sa slika 2a i 2c,
respektivno.
- Direktno povezivanje interfejsa, objekata van sistema, nekim tokom podataka (Slika 3) nije
dozvoljena, jer pretstavlja opis odnosa objekata van posmatranog sistema, pa nije od interesa.
Ako bi takva veza bila od interesa, odnosno ostvarivala se preko posmatranog sistema, tada bi
se morao definisati proces u posmatranom sistemu koji takvu vezu uspostavlja.
4
SPOLJNI
OBJEKAT
SPOLJNI
OBJEKAT
SKLADI[TE_PODATAKA
SKLADI[TE_DOKUMENTA
(a)
(c)
DOKUMENT
SPOLJNI
OBJEKAT
SPOLJNI
OBJEKAT
SKLADI[TE_PODATAKA
SKLADI[TE_DOKUMENTA
(b)
DOKUMENT
ZAVOENJE_
DOKUMENTA
(d)
IZRADA_
IZVE[TAJA
IZVE[TAJ
Slika 2. Primer nekorektnih i korektnih DTP
KUPAC
FAKTURA_KUP
IZRADA_
FAKTURE_KUP
1.
VREMENSKI_
NALOG_KUP
PROVERA_
UPLATE_KUPCA
SDK
POSLATA_FAKTURA_KUP
PLA]ENA_FAKTURA_KUP
VIRMANSKI_NALOG_KUPCA
Slike 3. Primer nekorektnog DTP
(
III
) Svaki tok podatka na DTP-u mora imati ime, koje treba da odražava zna
č
enje podataka koje on
nosi. Da bi se ostvarila
č
itljivost i razumljivost DTP-a, ova imena treba da budu prirodna, a ne neka
specifi
č
na, kodirana, preterano skra
ć
ena imena. Izuzetak su tokovi koji idu ka, odnosno od skladišta
5
INTERFEJS 1
TOK A
PROCES 1
PROCES 2
INTERFEJS 1
TOK A
PROCES 1
PROCES 2
TOK A
(a)
(b)
Slika 6. Grananje tokova
(
V
) Proces obrade podataka je aktivna komponenta sistema koja vrši tranformaciju strukture i sadržaja
ulaznog (ili ulaznih) tokova u izlazni (ili izlazne) tok podataka. Svaki proces ima naziv i oznaku. Naziv
procesa treba da precizno ozna
č
ava funkciju koju on obavlja. Nepisano pravilo kaže da, ako analiti
č
ar nije
u stanju da dodeli ime procesu to samo zna
č
i da ne razume funkciju koju proces obavlja. Brojna oznaka
procesa služi za referenciranje procesa. O na
č
inu dodeljivanja brojne oznake govori
ć
e se u odeljku o
dekompoziciji procesa.
(
VI
) Svaki proces mora da ima barem jedan ulazni i barem jedan izlazni tok podataka. Proces bez
ulaznog toka generisao bi izlaz niiz
č
ega, a proces bez izlaznog toka je nesvrsishodan.
(
VII
) Po pravilu, svako skladište tako
đ
e treba da ima barem jedan ulazni i barem jedan izlazni tok.
Me
đ
utim, dozvoljava se da skladište nema ulazni tok, podrazumevaju
ć
i da se formira i ažurira u nekom
drugom sistemu (mada bi ga tada, možda, logi
č
nije bilo prikazati kao tok od nekog interfejsa), odnosno da
nema izlazni tok, podrazumevaju
ć
i da posmatrani sistem formira i ažurira skladište koje se koristi u
nekom drugom sistemu.
(
VIII
) Svaki interfejs mora da ima barem jedan, bilo ulazni, bilo izlazni tok podataka, ina
č
e bi bio
izolovan od ostalog dela sistema.
(
IX
) Da bi se DTP-ovi lakše crtali, odnosno izbeglo nepotrebno presecanje linija, dozvoljava se da se
jedno skladište ili interfejs, na jednoj slici višestruko ponove. Primer je dat na Slici 7, gde je ponovljeno
skladište DOSIJE_STUDENTA.
7
