0 - 3 DTP Modeli Procesa

DTP modeli procesa - 2010
Prikazivanje procesa
Procesi koje posmatramo su podsistemi (odreena pokrivanja) nekog poslovnog sistema. Pomou modela procesa predstavljamo (opisujemo) statiku strukturu poslovnog sistema. Modeli procesa opisuju poslovne procese, tanije aktivnosti koje ljudi obavljaju u vezi podataka, i koriste sa da opiu i realno, trenutnu strukturu poslovnog sistema (realnog sistema, skraeno RS), i strukturu novog sistem koji se projektuje (informacioni sistem, skraeno IS). Ovo poglavlje opisuje pravljenje dijagrama toka podataka, koji je jedan od najee korienih metoda pri modelovanju sistema. Ciljevi Potpuno shvatanje pravila i tehnikih okvira za metodu prikazivanja DTP (dijagrama toka podataka); Razumevanje procesa koji se koristi za pravljenje DTP (dijagrama toka podataka). Potpuno osposobljavanje za pravljenje DTP (dijagrama toka podataka). Poglavlje u kratkim crtama
Prikazivanje procesa................................................................................................................................. 1 Ciljevi .................................................................................................................................................. 1 Poglavlje u kratkim crtama ................................................................................................................. 1 Uvod .................................................................................................................................................... 3 Dijagram toka podataka ........................................................................................................................... 5 Posmatranje i prepoznavanje dijagrama toka podataka ...................................................................... 5 Elementi Dijagrama Toka Podataka .................................................................................................... 7 Proces .................................................................................................................................................. 7 Strukture interfejsova raunarski podranih DTP alata (CASE) ........................................................... 8 Sintaksa raunarski podranih DTP alata (CASE) ............................................................................... 10 Grafiki simboli Dijagrama Toka Podataka prilagoenje standarda .............................................. 11 Grafiki simboli Dijagrama Toka Podataka prilagoenje standarda ........................................... 12 Proces aktivnosti transformacije podataka ................................................................................... 13 Strukture i smisao simbola procesa u DTP Forma pogodna za predstavljanje postojeih sistema za analizu manuelnog procesa ......................................................................................................... 13 Strukture i smisao simbola procesa u DTP prema FAM Metodologiji DTP .................................. 14 Tokovi podataka prenos podataka .................................................................................................. 15 Primeri struktura formi toka podataka ............................................................................................. 15 Karakteristike forme toka podataka opta pravila u vezi toka podataka....................................... 16 Eksterni entitet .................................................................................................................................. 17
Popovi Marko
petak, 12. mart 2010
Karakteristike eksternog entiteta...................................................................................................... 17 Skladite Podataka ............................................................................................................................ 18 Forme predstavljanja skladita podataka ......................................................................................... 19 Forma skladita podataka pogodna za predstavljanje projektovanih sistema (IS) ........................... 19 Forma skladita podataka pogodna za predstavljanje projektovanih sistema (IS) ........................... 20 Forme pretstavljanja duplikata skladita podataka ....................................................................... 20 Dijagram konteksta ........................................................................................................................... 21 Smisao dijagrama konteksta .......................................................................................................... 22 Ciljevi i postupci projektovanja DTP analitiki i kompozicioni .............................................. 23 Dekompozicija DTP nivoi dijagrama toka podataka IS ............................................................ 23 Metoda izrade DTP primena dijagrama toka podataka za definisanje poslovnih procesa .... 24 Tok izrade DTP .................................................................................................................................... 26 Dijagram konteksta ......................................................................................................................... 26 Dijagram najvieg nivoa najvii nivo DTP (prvi nivo dijagrama, nivo 1 DTP) ...................... 26 Dijagrami 1. Nivoa ............................................................................................................................ 27 Dijagrami 2. nivoa ............................................................................................................................. 28 Rave i spojevi DTP-a (Splits and Joins) .......................................................................................... 28 Alternativni tokovi podataka ............................................................................................................. 28 Opis procesa.......................................................................................................................................... 29 Struktuiran jezik (Pseudokod) ........................................................................................................... 29 Grafovi odluka (Stabla odluke) ......................................................................................................... 31 Tabele odluka .................................................................................................................................... 32 Pravljenje dijagrama konteksta konkretne izrada (aktivnosti projektovanja) ................................. 33 Pravljenje dijagrama toka podataka konkretne izrada (aktivnosti projektovanja) .......................... 33 Fragmentacija (dekompozicija) dijagrama toka podataka ................................................................. 35 Pravljenje prvog nivoa dijagrama toka podataka .............................................................................. 38 Pravljenje prvog nivoa dijagrama toka podataka (i niih)................................................................. 39 Validacija dijagrama tokova podataka .............................................................................................. 41 Projektovanje IS Primena koncepta na e-prodaji Eproizvoda ..................................................... 45 Pravljenje dijagrama konteksta ......................................................................................................... 45 Pravljenje fragmenata dijagrama toka podataka ............................................................................... 46 Pravljenje DTP-a prvog nivoa ........................................................................................................... 47 Pravljenje dijagrama toka podataka prvog nivoa (i ispod) ................................................................ 49 DTP drugog nivoa za etrgovinu ...................................................................................................... 50
Popovi Marko
potvrda kupca ......................................................................................................................................... 50 Validacija dijagrama toka podataka .................................................................................................. 51 Rezime.................................................................................................................................................... 51 Sintaksa dijagrama toka podataka ..................................................................................................... 51 Pravljenje dijagrama toka podataka .................................................................................................. 51 Literatura ................................................................................................................................................ 52 Pitanja u vezi DTP za koje je odgovor moj sistem ........................................................................ 52 Skupovi DTP ....................................................................................................................................... 52
Uvod Posmatrano iz ugla teorije sistema, DTP je predstavljanje nekog sistema (modelovanje organizacije) u formi statike (relacione i klasifikacione) strukture ije su osnovne komponente etiri klase podsistema, odnosno aktivnosti: 1. Procesi aktivnosti transformacije podaka u okviru odreenog (fokusiranog) pokrivanja; 2. Tokovi podataka aktivnosti prenoenja podataka izmeu sistema (podsistema); 3. Skladita podataka aktivnosti smetanja (upisivanja), eliminisanja (brisanja), promena (auriranja), potraivanja (uitavanja), i uvanja (memorisanja) podataka; 4. Eksterni entiteti aktivnosti podsistema iz neposrednog okruenja posmatranog pokrivanja. Da bi se pritupilo predstavljanju nekog sistema (projektovanju organizacije) neophodno je raspolagati informacijama o posmatranom pokrivanju sistema obuhvatiti podatke o njemu. U okviru prethodnog teksta, u vezi obuhvatanja informacionih zahteva (u prethodnim poglavljima obraenog), govorilo se o aktivnostima prikupljanja podataka, kao to su intervju i JAD, i transformacije dobijenih podataka u primera sluaja (use case) odnosno studije sluaja (case study). U ovom delu teksta (poglavlju o DTP) govori o tome kako ove informacije i iz studije sluaja dalje mogu da se urede i pretvore u modele procesa. Model procesa je formalni nain predstavljanja funkcionisanja poslovnog sistema. On ilustruje procese ili aktivnosti u vezi podataka, koji prate poslovne aktivnosti, i kretanje podataka meu poslovnim aktivnostima. Model procesa se moe koristiti za dokumentaciju trenutnog sistema (odnosno, realnog sistema) ili kao projekat novog sistema, koji se razvija (informacioni sistem), bilo da je sistem kompjuterizovan ili ne (raunarski podran ili manuelan). Danas se u praksi koristi mnogo razliitih tehnika modelov biti usmeren na jednu od najee citiranih ehnika1: U ovom tekstu kao referentna metodologija dijagrama toka podataka ili DTP koriena je metodologija IDEF0 koju administracija (vlada) Sjedinjenih amerikih drava koristi iskljuivo, obzirom da su je preuzeli mnogi poslovni sistemi uz neznatne i formalne izmene. Namena DTP Metodologije je ureivanje postupka izrade dijagrama toka podataka kao tehnike koja slui za opis poslovnih procesa i prikazivanje tokova podataka meu tim procesima. U ovom poglavlju, prvo e biti opisana osnovna sintaksa i pravila pomou kojih se na jednoj strani ilustruje DTP. Onda e biti opisano kako da se kreiraju sloeniji dijagrami na vie strana (listova, ekrana).
1
FIPS 183: Integration Definition for Function Modeling (IDEF0), Federal Information Processing Standards Publications, Washington, D.C.: U.S. Department of Commerce, 1993.
petak, 12. mart 2010 3
Popovi Marko
Iako ime dijagram toka podataka implicira da se fokusira samo na podatke, to nije sluaj. Fokus je uglavnom na procesima ili aktivnostima koje se obavljaju u vezi podataka koji prate radne procese (fizike ili intelektualne). Modelovanje podataka, o kojem e biti govorai u tekstu (poglavlju o modelovanju podataka), prikazuje kako su organizovani podaci, koje procesi prave ili koriste. Modelovanje procesa, i stvaranje DTP-ova posebno, jedna je od najvanijih vetina potrebnih sistem analitiarima (analitiarima sistema, projektantima i inenjerima sistema). U ovom delu teksta (poglavlju) irati na logike modele procesa zbog ega je panja usmerena na formalne strukture koje opisuju procese bez navoenja kako se ti procesi fiziki izvravaju. Kada se posmatra logiki model procesa, ne moe se rei da li je proces kompjuterizovan ili ga manuelno obavlja ovek, da li se informacije prikupljaju u papirnoj formi ili preko interneta, ili da li se informacije stavljaju u kartoteku, upisuju u neke liste ili sveske, ili se skladite u datoteku ili veliku bazu podataka. Ovi detalji se definiu tokom faze dizajniranja (izvoakog ili aplikativnog projektovanja) kada se ovi logiki modeli prerauju u fizike modele, koji pruaju informacije potrebne za konanu izgradu informacionog sistema (to je u jednom od poglavlja koje slede u radu je Poglavlje ?8?: projektovanje sistema System design). Fokusiraj , analitiari se mogu usredsrediti na to kako bi biznis (poslovni sistem) trebao da radi bez preopirnih opisa implementacionih detalja. U ovom poglavlju, prvo e biti objanjeno kako da se posmatraju i prepoznaju DTPovi i bie objanjeni njihovi osnovni simboli. Onda e biti opisan proces, koji se sprovodi pri izradi DTP-ova, koji koristi informacije iz studija sluaja i dodatnih informacionih zahteva prikupljenih od korisnika.
Popovi Marko
Dijagram toka podataka

Posmatranje i prepoznavanje dijagrama toka podataka U literaturi je est primer sa administrativnim podsistemom neke lekarske ordinacije to emo i mi koristiti. Sledea slika (Slika 6-1) prikazuje jedan deo DTP-a za lekarsku ordinaciju. Ovaj dijagram je pretstavljen u nestandardizovanojformi. Posmatrajui ovaj dijagram, analitiar moe da shvati na koji nain se u ovoj ordinaciji zakazuje pregled. Pregledajmo malo ovaj dijagram pre nego se pree na itanje sledeeg paragrafa. Koliko je taj dijagram razumljiv?
eljeni termin pregleda
Pacijent
Ime pacijenta
1. RECEPCIJA
Proveravanje statusa pacijenta
Podaci o proverenom pacijentu
Ime pacijenta
Podaci o pacijentu
2. SEKRETAR
Kartoni pacijenata
mogui termin pregleda
3. SEKRETAR
Nalaenje mogueg termina pregleda
Rasporeivanje zakazivanja
mogui termin pregleda Ime pacijenta Podaci o otkazivanju

4. SEKRETAR
Podaci o zakazivanju
Lista zakazivanja
poniteno zakazivanje
Ponitavanje zakazivanja
Slika 6-1 Prijavnica lekarske ordinacije inenjerski grafik, nestandardizovane forme
Lako je prepoznati da je ovaj dijagram grafika forma studije sluaja zakazivanje pregleda kod lekara, koji opisuje kako pacijenti zakazuju, otkazuju i menjaju zakazane preglede. Veina ljudi pone da ita (posmatra i prepoznaje) dijagram toka podataka iz levog gornjeg ugla DTP-a, pa se zato veina projektanata trudi da prilagodi dijagrame tako da ponu ba u tom uglu, mada ovo nije uvek mogue. Prvi simbol (entitet) u levom gornjem uglu na slici 6-1 predstavlja Pacijenta (Eksterni entitet), dakle svakog pacijenta koji poseti lekarsku ordinaciju. Iz njega izlaze etiri strelice koje se na drugom kraju spajaju sa drugim entitetima, a ulazi jedna strelica. Ove strelice predstavljaju tokove podataka i one pokazuju da se etiri klase podataka alju od pacijenta kao izlazi (output), a jedna ka pacijentu kao ulazni podaci (input).
Popovi Marko petak, 12. mart 2010 5
Dok se prati strelica od "pacijenta" (koji pretstavlja eksterni entitet) do procesa "Proveravanje statusa pacijenata", lako je zamisliti sebe kao recepcionara koji sedi za prijemnim pultom i trai od pacijenta njegovo ime i upisuje ga u listu (svesku, protokol) kako bi naao njegov (odgovaraj ) karton. Proces "Proveravanje statusa pacijenta" ima pet strelica, ili pridruenih tokova protoka, iji je smer ili u ili iz ovog procesa. Podaci koji idu ka procesu su ulazni (inputi), a podaci koji idu od njega su izlazni (outputi) promenjeni ili napravljeni unutar tog procesa. Ponekad se informacije ne dobijaju od eksternih entiteta iz skladita podataka, koja sadre podatke (uskladitene informacije). Ako se obrati panja na dijagram, uoavaju se dva razliita grafika simbola (oznaenih kao: Kartoni pacijenata i Lista zakazivanja) koji reprezentuju skladita podataka realne ordinacije. Obzirom da za DTP nisu bitni naini fizike realizacije skladita, sva skladita podataka se pretstavljaju jedinstvenim simbolima (otvorenim pravougaonikom) kako je predstavljeno na sledeoj slici (slika 6-1.1)
eljeni termin pregleda
Pacijent
Ime pacijenta
1. RECEPCIJA
Proveravanje statusa pacijenta
Ime pacijenta
Podaci o pacijentu
Kartoni pacijenata 2. SEKRETAR
K1
3. SEKRETAR
Nalaenje mogueg termina pregleda
Rasporeivanje zakazivanja
Lista zakazivanja
Ime pacijenta Podaci o otkazivanju
4. SEKRETAR
L1
Ponitavanje zakazivanja
poniteno zakazivanje
Slika 6-1.1 Prijavnica lekarske ordinacije deo DTP za recepciju lekarske ordinacije
Obratimo panju na pravougaonik K1, koji je otvoren sa desne strane, sa naslovom "Kartoni pacijenata ". Ovo je skladite podataka koje sadri podatke (memorisane informacije) o pacijentima, i na slici se moe videti da ovo skladite prua informacije o pacijentu procesu "Proveravanje statusa pacijenata", to je prikazano strelicom od skladita podataka do procesa. Posmatranjem DTP, uoava se da se mogu razumeti ovi procesi itajui tokove podataka koji teku izmeu svih procesa i eksternih entiteta.
Popovi Marko
Jednostavno je shvatiti da proces "Proveravanje statusa pacijenta" koristi ime pacijenta dato od strane pacijenta kako bi preuzeo podatke o njemu iz skladita podataka "Kartoni pacijenata ( to je u manuelnoj realnosti KARTOTEKA sa Kartonima pacijenata). Odatle, prikupljene informacije mogu da se termina za zakazivanje. Proces "Rasporeivanje zakazivanja" koristi skup slobodnih termina iz skladita podataka "Lista zakazivanja (liste sa slobodnim terminima i teminima zakazanih pregleda, kako bi osoblju bilo eno termine pacijentu moda nee svi slobodni termini biti pogodni pacijentu, takoe neki pacijenti mogu da zahtevaj i ili dui pregled u zavisnosti od njihovih zdravstvenih problema. Informacije o pacijentu i odabran termin se zatim koriste da zakazivanje pregleda, koji se skladite u skladitu podataka "Lista zakazivanja". Na dijagramu se moe videti da postoji jedan proces za otkazivanje pregleda "Ponitavanje zakazivanja", ali nema procesa za promenu zakazanog pregleda. Ako se paljivo razmisli se da je proces za promenu zakazanog pregleda isti kao kada bi otkazali pregled i zakazali novi. Ovaj dijagram je primer DTP-a na jednoj stranici TP-ova su mnogo kompleksniji od prikazanog a toliko mnogo procesa da, ako bi pokuali da na jednoj stranici nacrtamo jedan DTP koji prikazuje sve procese, oni ne bi mogli da stanu na jednu stranu, pa se umesto toga prikazuju sa nizom DTP-ova (svaki nacrtan na posebnom papiru odnosno ekranu) koji predstavljaju ceo sistem. Elementi Dijagrama Toka Podataka Nakon to je napravljen globalan uvid u DTP, bie predstaljena sintaksa ili jezik iskazivanja DTP, koji obuhvata skup simbola i sintaksnih pravila. Postoje etiri simbola u DTP jeziku (proces, tok podataka, skladite podataka, kao i eksterni entitet), od kojih je svaki predstavljen drugim grafikim simbolom. U literaturi, postoje dva naj a naina 2 obeleavanja DTP skupova simbola , odnosno setova DTP grafikih primitiva prikazanih na sledeoj slici (Slika 6-2): 1. set (skup simbola) koji su razvili Kris Gane i Trish Sarson, 2. set (skup simbola) koji su razvili DeMarco, Coad i Yourdan Ni jedan nain nema apsolutnu prednost, neke organizacije koriste Gane i Sarson forme simbola, a druge koriste simbole koje su definisali DeMarco, Coad i Yourdan. Meutiml, najee su organizacije koje su uvele vlastite standardne simbole. U ovom tekstu (knjizi) najee ese koristiti jedna modifikacija ove dve sintakse, koja se koristi na fakultetu za Mendment u Novom Sadu pod nazivom FAM sintaksa, kao deo Metodologije za izradu seminarskih radova. Proces U optem sluaju radni proces je aktivnost ili funkcija koja se obavlja iz nekih specifinih poslovnih razloga. Obzirom da je na objekat posmatranja Informacioni sistem, za nas proces pretstavlja aktivnost ili funkciju u vezi informacija koje prate odvijanje radnih procesa. Procesi mogu biti manuelni (runa manipulacija sa podacima) ili automatizovani (kompjuterizovani podrani raunarskom obradom podataka. Svakom procesu se pridruuje
2
Chris Gane, Trish Sarson: Structured Systems Analysis: Tools and Techniques, Hnglcwood Cliffs, NJ, Prentice Hall, 1979; Tom DeMarco, Structured Analysis: System Specification, Englewood Cliffs, NJ, Prentice Hall, 1979; E. Yourdan, Larry L Constantine: Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, Englewood Cliffs, NJ, Prentice Hall, 1979.
Popovi Marko
naziv ili ime koje uobiajeno poinje sa glagolom a zavrava sa imenicom (npr. "Pronalaenje pacijenta", "Ispravljanje podataka o pacijentu"). Imena treba da budu kratka, ali da ipak sadre dovoljno informacija, tako da italac lako i tano razume ta ti procesi rade. U principu, svaki proces obavlja samo jednu aktiv rei, koje ukazuju na to da proces obavlja vie delatnosti.
DTP elementi i njihovi atributi struktura komponenata

podataka dijagrama toka
simboli koje su uveli
Gane i Sarson
Yourdan, DeMarco, i Coad
Proces
Broj klsifikaciona numeracija Naziv procesa ime klase aktivnosti (glagol) Opis procesa aktivnosti se upisuju u prateoj pseudokod dokumentaciji Najmanje po jedan ulazni i izlazni tok podataka
naziv procesa
kratak opis procesa
Naziv procesa
Tok podataka
Predstavlja veze izmeu procesa relacije Globalno opisuje prenoene podatke Detaljan opis strukture podataka je u reniku adresaru podataka Tok je vektor, ije su komponente: pravac, smer, i naziv toka Naziv toka podataka je naziv relacije (imenica) Naziv toka podataka Naziv toka podataka
Skladite podataka
Naziv skladita (imenica) Moe se navesti oznaka ili broj skladita (n0), n0 je mnemonik Struktura skladitenih podataka je opisana u renikuadresaru podataka Najmanje jedan ulazni tok podataka
n0 naziv skladita
podataka
Naziv skladita podataka
Eksterni entitet
Naziv eksternog entiteta ime klase eniteta (imenica) Opis eksternog entiteta je u renikuadresaru podataka
Naziv klase entiteta
Slika 6-2-1 Elementi dijagrama toka podataka najei primeri grafikih simbola i atributi komponenata DTP
Strukture interfejsova raunarski podranih DTP alata (CASE) Na osnovu literature, slika 6-2-1 prikazuje osnovne elemente procesa, a slika 6-2-2 kako se oni obino struktuiraju (sintaksno opisuju) i prikazuju u CASE alatima. Svaki proces ima jedinstven identifikacioni broj, ime i opis, koji se pojavljuju u studiji sluaja. Opisi moraju jasno i precizno da opisuju korake i detalje procesa, na kraju krajeva, oni se koriste kao vodi za programere koji treba da kompjuterizuju procese (ili piscima prirunika za nekompjuterizovane procese). Opisi procesa postaju detaljniji kako se saznaje vie informacija kroz fazu analize. Mnogi opisi procesa se piu kao jednostavne tekstualne izjave o tome ta se deava. Sloeniji procesi koriste vie formalnih tehnika kao to su struktuirani jezik, tabele odluka ili grafovi odluka, koje se pominju kasnije u tekstu.
Popovi Marko
Element dijagrama toka podataka
Tipine oznake u
komponente DTP
CASE alatima
Label (name) naziv_procesa (glagolska forma) Type (process class) klasa procesa, vrsta tranformacije podataka Alias (another name): drugi naziv aktivnosti, popularan naziv,... n0 klasifikaciona oznaka ili ifra
Gane i Sarson
DeMarco, Yourdan , i Coad

Naziv procesa
Proces
naziv procesa
kratak opis procesa
procesa
Description opis koraka aktivnosti u vezi podataka struktuirani jezik
Tok podataka
Skladite podataka
Eksterni entitet
Notes napomena Label (name): naziv_toka_podataka Type (flow): tok naziv forme prenoenih podataka: dokumenta, formulara , obrasca, potvrde, uplatnice, liste,.. Description opis toka (lista atributa: svojstvena obeleja) Alias (another name) popularan naziv dokumenta ili formulara , naziv podeme,... Notes: napomena Label (name) naziv_skladita_podataka Type (store): vrsta skladita podataka Primeri za Type: Di :ita datoteka, Kj : jta kartoteka, Km : mta evidencija, BPx : xto Skladite Podataka, MEy : yta matina evidencija,.. Description opis skladita podataka Alias (another name) n0 uobiajeno ime, popularan naziv, alternativni naziv Composition logika struktura podataka Primeri za Composition: naziv_skladita(klju skladita, lista_ostalih_atributa) Notes: napomena Label (name) naziv_eksternog_entiteta Entity type klasa entiteta (osoba, proces, eksterni sistem,...) Description detaljniji opis eksternog entiteta Alias (another name) alternativno ime, drugi naziv, pseudonim, popularan naziv Notes napomena
Naziv toka podataka
Naziv toka podataka
n0 naziv skladita
podataka
Slika 6-2-2 Elementi dijagrama toka podataka sa najee korienim i tipinim oznakama u CASE alatima
Popovi Marko
Sintaksa raunarski podranih DTP alata (CASE) CASE alati tipina polja za Tok Podataka: Label (name): naziv_toka_podataka Type (flow): tok naziv dokumenta, formulara , obrasca, potvrde, uplatnice, liste,... Description: opis toka (lista atributa: svojstvena obeleja) Alias (another name): popularan naziv dokumenta ili formulara , naziv podeme,... Notes: napomena CASE alati tipina polja za Proces: Label (name): naziv_procesa glagolska forma Type (process): proces, tranformacije podataka Primer za Type: manipulacije sa personalnim podacima, ulaz,promena, izlaz,brisanje Description: opis koraka aktivnosti u vezi podataka Alias (another name): drugi naziv aktivnosti, popularan naziv,... Input/Output (Ulaza /Izlaza) : navoenje broja ulaznih /izlaznih tokova (nijedan, jedan ili vie) Notes: napomena CASE alati tipina polja za skladite podataka: Label (name): naziv_skladita_podataka Type (store): skladite podataka Primeri za Type: datoteka, kartoteka, evidencija, Baza Podataka, matina evidencija Description: opis skladita podataka Alias (another name): uobiajeno ime, popularan naziv,... Composition: logika struktura Primeri zapisa za Composition: key=klju skladita (niz kljunih atribura), attribute list =niz ili lista ostalih atributa (a1, a2,..., an ) Notes: napomena CASE alati tipina polja za Eksterni Entitet: Label (name): naziv_eksternog_entiteta Type (entity): entitet (osoba, proces, eksterni sistem,...) Description: opis eksternog entiteta Alias (another name): drugo ime, pseudonim, popularan naziv,... Notes: napomena (kratak opis koji jednoznano ukazuje na entitet)
Popovi Marko
10
Grafiki simboli Dijagrama Toka Podataka prilagoenje standarda U praksi se pokazalo najpogodnije korienje unije navedena dva standarda, stim da da su modifikovani neki simboli, kao to je prikazano na sledeoj slici (Slika 6-2-3).
Element DTP komponenta dijagrama toka podataka
simboli koje se koriste na FAM
Modifikovani skup simbola koje su uveli DeMarco,
-standard Gane i Sarson

Za opis realnog (postojeeg) sistema
Yourdan , i Coad
Za opis informacionog sistema (projektovanog IS)
n0 numeracija procesa
proces
Broj klasifikaciona numeracija procesa (n0 ) Naziv procesa ime klase aktivnosti (gerundiv glagolska imenica)
n0
lokacija
Naziv procesa
Naziv procesa
tok podataka
Naziv toka podataka Ime relacije(imenica) Strelica pokazuje ulazne i izlazne veze sa procesom
Naziv toka podataka
Naziv toka podataka
skladite podataka
Naziv skladita ime (imenica) Vrsta skladita (za postojei sistem) mnemonik m0 m0 naziv skladita
podataka Naziv skladita podataka
eksterni entitet
Naziv eksternog entiteta ime klase eniteta (imenica)
Slika 6-2-3 Elementi dijagrama toka podataka prema FAM standardu za prikaz DTP realnog (postojeeg) sistema i (logike statike) strukture projektovanog sistema (IS)
Popovi Marko
11
Grafiki simboli Dijagrama Toka Podataka prilagoenje standarda DTP simboli su objekti dijagrama toka podataka (DTP). Da bi ti objekti bili to pogodniji za grafiku prezentaciju u okviru nastave na FAM (Fakultetu za Menadment u Novom Sadu) su definisane sledee standardne forme DTP simbola (FAM standard ):
Element DTP komponenta dijagrama toka podataka

Svaki proces ima: Broj klasifikaciona numeracija procesa (n0 ) Naziv procesa ime klase aktivnosti (gerundiv glagolska imenica) Opis procesa aktivnosti se opisuju pseudokodom Jedan ili vie izlaznih tokova podataka Uglavnom jedan ili vie ulaznih tokova podataka Svaki tok podataka ima: Naziv toka podataka Ime relacije(imenica) Strelica pokazuje ulazne i izlazne veze sa procesom Opis prenoenih podataka logika struktura podataka koja se navodi u renikuadresaru podataka ili u legendi dijagrama Svako skladite podataka relnog (postojeeg) sistema ima: Vrsta skladita mnemonik Primeri za vrstu skladita: Di :ita datoteka, Kj : jta kartoteka, Km : mta evidencija, BPx : xta Baza Podataka, MEy : yta matina evidencija,.. Naziv skladita ime (imenica) Jedan ili vie ulaza izlaza moe biti: nijedan, jedan ili vie Opis skladitenih podataka se navodi u Legendi (reniku adresaru podataka) Svako skladite podataka projektovanog sistema ima: Naziv skladita ime (imenica) Jedan ili vie ulaza izlaza moe biti: nijedan, jedan ili vie Opis skladitenih podataka se navodi u Legendi (reniku adresaru podataka) Svaki eksterni entitet ima: Naziv eksternog entiteta ime klase eniteta (imenica) Opis eksternog entiteta
simboli koje se koriste na FAM
-standard FAM
n0 numeracija procesa
Naziv procesa
Naziv toka podataka
n0 naziv skladita
podataka
Slika 6-2-4 Elementi dijagrama toka podataka prema FAM standardu za prikaz DTP realnog (postojeeg) sistema i (logike statike) strukture projektovanog sistema (IS)
Proces aktivnosti transformacije podataka Procesi koje posmatramo su podsistemi (odreena pokrivanja) nekog poslovnog sistema. Pomou modela procesa predstavljamo (opisujemo) statiku strukturu poslovnog sistema. Modeli procesa opisuju poslovne procese, tanije aktivnosti koje ljudi obavljaju u vezi podataka, i koriste sa da opiu i realno, trenutnu strukturu poslovnog sistema (realnogsistema), i strukturu novog sistem koji se projektuje (informacioni sistem). Ovo poglavlje opisuje pravljenje dijagrama toka podataka, koji je jedan od najee korienih metoda pri modelovanju sistema. U DTP simbol procesa predstavlja homomrofni model aktivnosti kojima se transformiu podaci ili se manipulie sa podacima skladitenje, distribuiranje, formatizacija,... U sintaksi DTP, pravougaonik je grafika forma procesa. Svaki taj pravougaonik (oblik simbola procesa) ima jedinstven identifikacioni broj (klasifikaciono struktuiran broj u gornjoj liniji pravouganika) i jednoznaan naziv u formi gerundiva (glagolske imenice ili ba glagola koji ukazuje na funkciju procesa radi ovo izvrava ove aktivnosti) upisanog u sredini prostor pravougaonika. Gornje polje pravougaonika se koristi za naziv lokacije izvrenja procesa ili radnog mesta (ljudi) odgovornih za taj proces. Semantiki, procesi su crne kutije ne znamo ta je u njima sve dok se ne dokomponuju, ili dok se ne predstave pseudokodom na najniem nivou dekompozicije. Procesima se ulazni tokovi podataka transformiu u izlazne tokovi podataka ulaznim podacima se manipulie za proizvoenje izlaznih podataka. Izuzetno, u veoma retkim sluajevima, moe biti jedno bez drugog (samo ulaz ili izlaz), kada implicitno podrazumeva (interno) skladite, interna pobuda (triger) ili terminalni entitet. Svaki proces karakterie: Broj ili ifra ili klasifikaciona oznaku procesa (n0) Naziv procesa ime klase aktivnosti (gerundiv ili glagolska imenica) Jedan ili vie izlaznih tokova podataka; Jedan ili vie ulaznih tokova podataka Opis procesa aktivnosti koje se odvijaju sa podacima se opisuju pseudokodom, koji je izvan DTP (u reniku adresaru podataka) ili je u priologu DTP; Strukture i smisao simbola procesa u DTP Forma pogodna za predstavljanje postojeih sistema za analizu manuelnog procesa Za pretstavljanje manuelne obrade podataka, pogodna forma takvog procesa je simbol koji su uveli Gane i Sarson. Prema njihovoj sintaksi, na sledeim slikama prikazane su: opta struktura grafikog simbola procesa (slika 6-*-1), i jedan primer procesa u vezi odreivanja kreditne sposobnosti nekog klijenta (slika 6-*-2)
Identifikator procesa Tok Ulaznih Podataka
n0 =1
mesto odvijanja
Tok Izlaznih Podataka
Naziv procesa (primer:

Provera kreditne sposobnosti)
slika 6-*-1: opta struktura grafikog simbola procesa simbol koji su uveli Gane i Sarson
Popovi Marko
13
ifra ili klasifikaciona oznaka procesa
Gde/Ko ovo radi sa podacima
Identifikaoni podaci o potraiocu kredita
1.3
Prodajno
Provera kreditne sposobnosti
Podaci o kreditnoj sposobnosti
Aktivnosti koje se odvijaju sa podacima
slika 6-*-2: jedan primer simbola procesa u vezi odreivanja kreditne sposobnosti nekog klijenta koji, na osnovu sintakse koju su uveli Gane i Sarson pogodan je za prikaz postojeeg (realnog) sistema Strukture i smisao simbola procesa u DTP prema FAM Metodologiji DTP
Tok Ulaznih Podataka
n0 =klasifikaciona
oznaka procesa
Tok Izlaznih Podataka
Naziv procesa
(primer: Provera kreditne sposobnosti)
slika 6-*-3: Strukture i smisao simbola procesa u DTP prema FAM Metodologiji DTP
Popovi Marko
14
Tokovi podataka prenos podataka U sutini, tok podataka odraava jednosmernu i jedinstvenu relaciju izmeu dva procesa. Sa druge strane, u optem sluaju, izmeu dva procesa ima vie relacija sa odgovarajuim (razliitim) logikim strukturama tokova podataka. Posmatrajmo jedan jednostavan primer tokova podataka izmeu procesa uplatilac (procesa ili klijenta koji vri neku uplatu) i blagajna (procesa ili blagajnika koji prima uplate). U tom primeru se moe uoiti vie vrsta tokova podataka, a radi pojednostavljenja uoiemo u jednom smeru tok uplatnica (podaci koji prate aktivnosti uplaivanja), i u drugom smeru potvrda (podaci koji prate aktivnosti potvrivanja izvrenog uplaivanja). Logike strukture ta dva toka su veoma sline, i mogu se predstaviti sledeom pojednostavljenom logikom strukturom toka (atributima relacije uplaivanje): naziv_uplatioca, vreme_uplate, iznos_uplate, naziv_primaoca_uplate, mesto_uplate,... Logike strukture tokova se se navode u dokumentaciji koja je pridruena DTP, i nije neposredno u okviru DTP. Dokumentacija o logikim strukturama podataka je ili u formi legende ili skladita podataka o podacima za koji se obino koristi termin renik-adresar podataka. U skladu sa logikom strukturom, tokovi podataka se mogu klsaifikovati kao: Elementarni-prenosi se jedan podatak (na primer: matini broj kartona pacijenta, JMBG, broj indeksa studenta,...), ili Sloeni logiki ureen niz podataka, koji je nosilac kolekcije od nekoliko informacija (na primer, informacije o pacijentu, podaci o studentu, opi robe,..,.). Prenoenje elementarnih podataka je najee kod upita o uskladitenim podacima, kada se prenosi samo kljuni podatak procesu za upravljanje skladitem podataka. U optem sluaju, i gotovo uvek, prenose se sloeni podaci nizovi logiki ureenih podataka. Da bi bio lako itljiv, u DTP se tok podataka opisuje jednostavnim simbolom sa dve komponente: 1. strelica koja opisuje relaciju i smer toka toka, i 2. naziv koji ukazuje na ime logike strukture toka. Naziv toka se navodi kao imenica koja jasno ukazuje na klasu (vrstu) prenoenih podataka. Primeri su uplatnica_kolarine, podaci_o_pacijentu, faktura, i td. Tokovi podataka su povezne komponete koje dre sve procesa u okviru nekog sistema (skladite podata i eksterni entitet su u stvari isto procesi), sa strelicom koja pokazuje pravac i smer u ili van procesa. Tokovi podataka prikazuju sve one podatke to ulaze u svaki proces i sve one podatke to izlaze iz svakog procesa, to taj proces daje. Svaki proces mora imati bar jedan izlazni tok podataka, jer ako nema izlaza, proces ne radi nita. Isto tako, svaki proces obino mora da ima najmanje jednan ulazni tok podataka, jer je teko, u stvari proizvede izlazna informacija bez ulaznih informacija. Ulazni tok ima i proces koji zapoinje odvijanje u nekom trenutku ima ilazni tok od tajmera (procesa koji alje podatke u vezi vremena). Primeri struktura formi toka podataka Na sledeim slikama (slika 6-*-5, slika 6-*-6) su navedene dve osnovne strukture formi toka podataka Naziv_klase_prenoenih_podataka slika 6-*-5: Forme pretstavljanja toka podataka u DTP
LEGENDA opis logike strukture toka

Naziv toka: Prenoeni_podaci Atributi toka: atribut1, atribut2,..., atributn slika 6-*-6: Pretstavljanje logike strukture toka podataka u formi legende Karakteristike forme toka podataka opta pravila u vezi toka podataka Da bi se lake pravili DTP-ovi, korisno je imati u vidu sledee karakteristike forme toka podataka koji se mogu shvatiti kao opta pravila u vezi toka podataka: Tokovi podataka opisuju prenos podataka (nosilaca informacija) prema ili od procesa (ili entiteta). Strelice moraju poinjati ili se zavravati u procesima. Neprihvatljiv je direktan tok podataka izmeu dva skladita podataka ili direktno pristupanje podacima iz eksternog entiteta u skladite podataka to se mora uraditi preko nekog procesa; Strelice se imenuju dodeljuje im se naziv (koji odgovara smislu prenoenih podataka, i koji se ispisuje iznad strelice; Dvosmerne strelice se ne koriste, jer se razlikuju strukture i smisao podataka za svaki smer proticanja podataka; Entiteti su ili poiljaoci ili primaoci za izlazne ili ulazne podatke entiteti su za tok podataka: izvori ili ua; osnivai ili korisnici; poetne ili krajnje stanice; Iz eksternih entiteta tokovi podataka moraju ulaziti u procese; Tokovi podataka koji ulaze u eksternie entitete moraju dolaziti iz procesa; Procesi i skladita podataka, oboje, moraju imati i ulaze i izlaze; Ulazi u skladita podataka jedino dolaze iz procesa. Izlazi iz skladita podataka jedino odlaze u procese.
Popovi Marko
16
Eksterni entitet Eksterni ili spoljni entitet je uvek neki proces, koji se nalazi izvan posmatranog sistema u neposrednom okruenju posmatranog pokrivanja sistema, i u interakciji je sa posmatranim pokrivanjem sistema. Karakteristini primeri eksternih entiteta su osoba (aktivnost koju izvrava neka osoba), organizacija (aktivnost koju izvrava neka organizacija), ili neki drugi podsistem Za primer pokrivanja sistema administracija lekarske ambulante, eksterni entiti mogu biti: pacijent, lekar, organ dravne uprave, raunovodstveni sistem,i td. Svaki eksterni entitet ima ime i opis. Kljuna stvar koju treba da zapamtite o eksternim entiteta je da se nalaze izvan posmatranog sistema, ali mogu, mada ne moraju, biti deo sistema (organizacije) iji je deo i posmatrano pokrivanje. Uobiajena greka je da se ljudi koji su deo sistema prikau kao eksterni entiteti. Ljudi koji izvravaju procese su deo procesa i nisu van sistema (npr. slubenici za unos podataka, primaoci narudbine,...). Osoba koja obavlja proces se esto opisuje u opisu procesa, ali nikad na samom DTP-u. Meutim, ljudi koji koriste informacije iz sistema da bi izvrili druge procese ili odluuju koje informacije e ui u sistem pretstavljaju se kao eksterni entiteti (na primer, menaderi). Karakteristike eksternog entiteta Osnovne karakteristike eksternog entiteta, kao komponente DTP, su: Eksterni eniteti su objekti iz okruenja sistema (klijenti, maine, organizacije, firme,...). Za entitete se koriste mnogi sinonimi, spoljni izvori/primaoci, dobavljai, klijenti, i drugi. Entiteti unose podatke (nosioce informacija) u IS ili ih primaju iz IS. Naziv Eksternog Entiteta pretstavlja tip ili klasu objekata a ne primer ili pojedinani sluaj. Naziv Eksternog Entiteta se upisuje u oblik (krug ili elipsa). Kada se modeluje sloen sistem, svakom eksternom entitetu se dodeljuje jedinstveni broj ili mnemonik (skraenica od prvih slova naziva klase entziteta). Duplikati Eksternih Entiteta veoma esto se ucrtavaju u DTP, da se izbegnu presecanja tokova, ili da bi dijagram (DTP) bio itljiviji. Eksterni eniteti predstavlja spoljni izvor i/ili primaoc podataka koji je u neposrednom okruenju posmanog sistema Naziv entiteta
(imenica) Granica sistema
Oznaka kopije
Jedinstveni identifikator #n
Granica sistema
#n
entitet
kopija entiteta Kopija simbola

Eksterni enitet -simbol originala
Eksterni enitet
-simbol originala
slika 6-*-5: Forme pretstavljanja originala i duplikata eksternog entiteta
Popovi Marko
17
Skladite Podataka U optem sluaju, skladite podataka je proces rukovanja sa podacima (uskladitenim nosiocima informacija) i pridrueni mu skup uskladitenih podataka. Radi jednostavnosti, u okviru DTP skladite podataka se predstavlja kao logika struktura podataka skup ureenih qtributa. Fizike strukture skladita podataka, (kao to su datoteke ili baze podataka) se praktino odreuju kasnije prilikom modeliranja podataka (kreiranja fizikog modela). Kao i kod procesa, svako skladite podataka ima opisno ime (imenica), identifikacioni broj, kao i opis koji se navodi u prilogu DTP bez ukazivanja na nain realizacije skladita. Logike strukture skladita podataka su polazna taka za model podataka i glavna veza izmeu modela procesa i modela podataka (modeliranje podataka je ). Tokovi podataka koji dolaze iz skladita podataka ukazuju na podatke (nosioce informacija) koji se preuzimaju iz skladita podataka, a tokovi podataka koji idu u skladite podataka ukazuju na podatke (nosioce informacija) koji se dodaju u skladite podataka, ili da se zapisi u skladitu podataka menjaju. U sluajevima u kojima isti proces i uva podatke i preuzima podatke iz skladita podataka, postoji iskuenje da se nacrta jedant tok podataka sa strelicama na oba kraja. Meutim, da bi tokovi bili jasniji, neophodno je nacrtati dva odvojena toka podataka jer se za proces ti podaci razlikuju. Poces auriranja podataka u skladitu obuhvata dve aktivnosti preuzimanje postojeeg zapisa (uitavanje starih podataka), i predavanje promenjenih zapisa (upisivanje auriranih podataka). Te ktivnosti dva smera toka podataka sa identinom logikom strukturom ali sa razliitim nazivima tokova podataka i njima odgovarajuih atributa. Te razliitosti obino su minimalne i realizuju se tako to se nazivima tokova i njihovih atributa dodaje razliit prefiks ili postfiks, kao to su na primr: za nazive tokove stara_uplatnica i nova_uplatnica, uplatnica_pre i uplatnica_posle, ugovor_stari i ugovor_novi, ugovor_stari i ugovor_novi,... za nazive atributa tokova stari_datum i novi_datum, stari_datum i novi_datum, stari_iznos i novi_iznos, iznos_stari i iznos_novi, iznos_pre i iznos_posle, pre_iznos i posle_iznos i td. Sva skladita podataka moraju da imaju najmanje jedan ulazni tok unoenja podataka dodavanje novih zapisa, inae skladite je prano ne sadre nikakve podatke. Ponekad se u DTP postojeeg sistema nae nepotrebno strano skladite, koje je napravljeno i odravane od strane nekog drugog informacionog sistema -tada tom skladitu i nije mesto nepripadajuem DTP. Isto tako, skladita podataka moraju da imaju najmanje jedan izlazni tok za korienje podataka (iznoenih, uitanih). Skladite nema smisla ako nee biti korieno.
Popovi Marko
18
Forme predstavljanja skladita podataka U okviru Metodoloje FAM, uvedene su dve forme predstavljanja skladita podataka: 1. Forma pogodna za predstavljanje postojeih sistema (RS), 2. Forma pogodna za predstavljanje projektovanih sistema logikih struktura projektovanih IS. Forma skladita podataka pogodna za predstavljanje projektovanih si stema (IS) Forma pogodna za predstavljanje postojeih sistema odgovara grafikom simbolu koji su uveli Gane i Sarson, koja je detaljnije opisana na sledeoj slici (slika 6-*-6)
Tip skladita podataka Naziv skladita podataka
Ulazni_podaci Izlazni_podaci
D1 Skladite_podataka
Jedinstveni identifikator
slika 6-*-6: Forme pretstavljanja postojeih skladita podataka za predstavljanje realnih (ve postojeih) sistema prema sintaksi Gane i Sarson U okviru postojeih sistema, postje neke lokacije gde su podaci smeteni u trajna ili privremena skladita podataka. U DTP koji pretstavljaju postojee sisteme, najee se razlikuju sledei tipovi skladita podataka: D raunarski podaci sa direktnim pristupom (DB, datoteke sa indeks sekvencijalnim i random pristupom,..); T raunarski podaci sa sekvencijalnim pristupom (datoteke na magnetnim trakama,..); M manuelne evidencije, e.g. arhivski ormari, kartoteke, knjige (sveske) evidencije, i sluno. P trenutne ili prolazne datoteke podataka, odnosno privremene programske datoteke, (tranzitna skladita podataka) O trenutne manuelna skladita podataka kao to su: potansko sandue, fahovi, e mail, ...
Popovi Marko
19
Forma skladita podataka pogodna za predstavljanje projektovanih sistema (IS) Forma pogodna za predstavljanje projektovanih sistema odgovara grafikom simbolu koji su uveli Yourdan, DeMarco, i Coad, koja je prikazana na sledeoj slici (slika 6-*-7). Pri pretstavljajnju projektovanih sistema (IS) ne navodi se tip skladita, ve samo simbol skladita sa upisanim imenom nazivom logike strukture skladita. Logika struktura skladita se navodi ili u legendi ili u renikuadresaru podataka. Na sledeoj slici je naveden simbol skladita i njemu odgovarajua logika struktura atributa. Naziv_skladita slika 6-*-7: Forme skladita podataka za predstavljanje projektovanih sistema (IS) Po pravilu, opis logike strukture skladita podataka se navodi u posebnom dokumentu a ne neposredno u okviru DTP. Jedan od naina pojanjavanja grafike prezentacije skladita podataka je pomou legende, kao to je prikazano na sledeoj slici (slika 6-*-8), ili u renikuadresaru podataka.
LEGENDA opis logike strukture skladita podataka

Oznaka skladita: Naziv_skladita Kljuni atributi skladita: kljuni_atribut1, kljuni_atribut2,..., kljuni_atributk, Nekljuni atributi skladita: atribut1, atribut2,..., atributn, slika 6-*-8: Forme logike strukture skladita podataka za predstavljanje projektovanih sistema (IS) Forme pretstavljanja duplikata skladita podataka Veoma esto se u DTP ucrtavaju duplikati. Skladita podataka se mogu ponovljeno pojaviti (duplikati) u DTP, iz isti razloga kao i duplikati Eksternih Entiteta, sa ciljem ili da se izbegnu presecanja tokova, ili je potrebno da dijagram (DTP) bude sreeniji i itljiviji. Na sledeoj slici (slika 6-*-9)navedene su forme predstavljanja dupikata skladita podataka Oznaka duplikata (kopije) skladita podataka
K1 naziv skladita
(a) za
Naziv skladita
(b) za
realni sistema (postojei RS)
informacioni sistem za (projektovani IS)
slika 6-*-9: Forme pretstavljanja duplikata skladita podataka
Popovi Marko
20
Dijagram konteksta Dijagram konteksta opisuje neposredno okruenje posmatranog sistema i to na najviem nivou uoptenosti. Sinonimi za dijagram konteksta su kontekstni ili kontekstualni dijagram. Za dijagram konteksta sistema se uobiajeno koriste samo sledea tri simbola: 1. Posmatrani sistem simbol procesa kao crna kutija samo sa nazivom upisanim u pravougaoni simbol, 2. Tokovi podataka strelice koje ulaze u posmatrani sistem ili izlaze iz posmatranog sistema, i 3. Eksterni entiteti posmatranog sistema procesi iz neposrednog okruenja posmatranog sistema. Posmatrano pokrivanje (posmatrani sistem ili organizacija) dijagramom konteksta se predstavlja integralno kao crna kutija koja implicitno sadri sve relevantne interne procese. Dijagram konteksta je najvii (najapstraktniji, najgeneralniji) nivo DTP. Namena dijagrama konteksta je da opie granice posmatranog pokrivanja prikazujui relacije posmatranog pokrivanja sa entitetima iz njegovog neposrednog okruenja, odraavajui strukture interakcije posmatranog pokrivanja sa sistemima iz njegovog neposrednog okruenja (eksternim entitetima).
Tokovi ulaznih podataka
tx
Entitet # x Entitet # y
n0 lokacija sistema
Tokovi Izlaznih Podataka
ta ty,1
tz,1
Entitet # z
Naziv posmatranog realnog sistema
Entitet # a
ty,2
Entitet # y
tz,2
Entitet # z
slika 6-*-9: Dijagram konteksta kada se posmatra postojei sistem (okruenje realne organizacije)
Tokovi ulaznih podataka Tokovi Izlaznih Podataka
tx
Entitet # x Entitet # y
n0 klasifikaciona numeracija
ta
Entitet # a
ty,1
Naziv sistema
ime posmatranog projektovanog sistema (kao crna kutija)
ty,2
Entitet # y
tz
Entitet # z
tb
Entitet # b
slika 6-*-10: Dijagram konteksta kada se posmatra projektovani sistem (okruenje IS)
Popovi Marko
21
Smisao dijagrama konteksta

Bilo da se radi o analizi realnog sistema (postojeeg poslovnog procesa u kojem se aktivnosti obavljaju i runo i raunarski podrano kompjuterizovano) ili se projektuje novi informacioni sistem (raunarski podran), dijagram konteksta je prvi DTP. Kao to ime sugerie, dijagram konteksta prikazuje neposredno okruenje kontekst kojem pripada posmatrani sistem ili poslovni proces. Svi modeli procesa imaju samo jedan dijagram konteksta.
JBMG kandidata
n0 prizemlje FAM
JBMG
kandidat matina evidencija kandidat

N0 indeksa kandidata
Odbijanje lanstva
upisivanje u biblioteku FAM
matina evidencija
lanska karta
kandidat
slika =.?. 1: dijagram konteksta postojeeg podsitema upisivanje u biblioteku FAM
Dijagram konteksta poslovnog procesa reprezentuje sve njegove poslovne podprocese samo kao jedan integralni proces (sistem) i prikazuje protok podataka do i od eksternih entiteta. Skladita podataka se obino ne nalaze na dijagramu konteksta, osim ako su "vlasnitvo" sistema ili procesa van posmatranog sistema, pa simbol skladita (umesto oznake ekternog entiteta koji manipulie skladitem piodataka) ima znaaja ili olakava analizu realnog sistema. Na primer, postojei informacioni podsistem, koji koristi fakultetska biblioteka, koji zapisuje ko je pozajmio knjige, verovatno bi proverio fakultetsku bazu podataka (aktivnosti studentske slube o studentima matina evidencija) da bi se videlo da li je student uopte upisan na fakultet (slika =.?. 1). U ovom dijagramu konteksta, fakultetska skladite podataka o studentima bi mogla da bude prikazana na dijagramu konteksta zato to se nalazi van bibliotekog sistema, ali je koristi (slika =.?. 2). Mnoge analitiari ili projektanti ne bi prikazali ovu bazu podataka o studentima entitet pod nazivom "Informacioni sistem studentske slube" ili kao to je na gornjem dijagramu (slika =.?. 1).kao podsistem sa nazivom matina evidencija.
JBMG kandidata
n0 prizemlje FAM
JBMG N0 indeksa
kandidat
Odbijanje lanstva
upisivanje u biblioteku FAM
K matina evidencija
studenata FAM
lanska karta
kandidat
kandidat
slika =.?. 2: varijacija dijagram konteksta postojeeg podsitema upisivanje u biblioteku FAM
Uopteno posmatrajui, u okviru (unutar) DTP, posmatrajui pojedinano, svaki proces se pretstavlja svojim dijagramom konteksta, stim da u tom sluaju postoje tri klase eksternih entiteta koji komuniciraju sa posmatranim procesom: skladita podataka (u stvari specifimni procesi za rukovanje podacima), drugi procesi, i eksterni entiteti pokrivanja (stvarni eksterni entiteti).
Ciljevi i postupci projektovanja DTP analitiki i kompozicioni

Postoje dva cilja formiranja (projektovanja) DTP: 1. Analiza postojeeg sistema sistema jeste za koji emo koristiti termin realni sistem ili skraeno RS, 2. Projektovanje novog sisteme budueg ili informacionog sitema za koji emo koristiti skraenu oznaku IS, Za oba cilja, prvo se definiu dijagrami konteksta, i nakon toga se prelazi na struktuiranje DTP. Kada je cilj analiza postojeeg sistema, na osnovu pojedinanih primera sluaja (engleski use cases) iz studije sluaja (case study) formiraju se DTP-ovi, stim da se aktivnosti preslikavaju u procese. Potom se iterativno vri sinteza pojedinanih DTP-ova i generalizacija procesa (okrupnjavanje aktivnosti) u podsisteme vieg nivoa optosti sve dok se doe do onoliko DTP-ova koliko ima eksternih entiteta u dijagramu konteksta RS (ovo je iskustveni kriterijum). Za oba sluaja, procesi projektovanja se razlikuju samo po smeru (obrnuti su redosledi) aktivnosti. Obzirom da je najvaniji zadatak projektanta projektovanje novog sisteme (IS), teite panje ovog teksta e biti usmereno na formiranje DTP za IS.
Dekompozicija DTP nivoi dijagrama toka podataka IS

Osnovni namena (zadatak) izrade DTP je model procesa posmatranog sistema (modela IS). U prvom koraku modelovanja IS kreiraju se dva dijagrama: dijagram konteksta i DTP najvieg nivoa (sa procesima koji se odnose na eksterne entitete IS) koji uopteno opisuju ciljni sistem i daju minimalne i potrebne odgovore na pitanja o nameni sistema. Ovakav DTP je integralan ali je preterano uopten i bez detalja koji su neophodni za projekat dovoljan za realizaciju. Ovaj inicijalni dijagram (najvii nivoi DTP) je potrebno dekomponovati, klasifikovati na detaljnije opise (od gore na dole), ime se dobijaju sve jasniji i pregledniji detalji delova modela IS kako bi se on mogao implementirati. Svaki sloeni proces na najviem nivou diagrama, predstavljen jedinstvenim grafikim blokom, treba dekomponovati (razbiti) na vie podprocesa komponenata polaznog procesa. Tako e vii nivo DTP sistema (roditeljski sistem) biti dekomponovan na nii nivo koji pretstavljaju pripadajui podprocesi dekomponovanog sistema vieg nivoa dijagrama DTP. Minimalna struktura grafikog simbola procesa (pravougaonog bloka) sadri jedinstven identifikacioni broj i naziv procesa. Ovaj jedinstven identifikacioni broj posmatranog procesa je sa prefiksom roditeljskog bloka koji pretstavlja proces na viem nivou apstrakcije, odnosno prefiks mu je broj optijeg procesa kome pripada posmatrani proces. Radi jednostavnosti, zanemaruje se numeracija procesa navedenog u kontekstualnom dijagramu. Dijagram procesa na najviem nivou apstrakcije mi emo oznaavati kao prvi nivo. Meutim, u literaturi, dijagram procesa na najviem nivou apstrakcije se esto oznaava kao nulti nivo DTP jer se ne navode prefiksi za brojeve procesa, ve se procesi numeriu
prirodnim brojevima (0, 1, 3, i tako dalje). Prema tome, ako su na najviem nivou DTP etiri procesa, oni se predstavljaju na sledei nain prikazan na sledeoj slici (slika =.?. 3). DTP nultog nivoa (prvi nivo numerisanja procesa) 1
Naziv_procesa_1
2
Naziv_procesa_2
3
Naziv_procesa_3
4
Naziv_procesa_4
slika =.?. 3 : DTP najvieg nivoa (prvog nivoa) DTP nultog nivoa (prvi nivo numerisanja procesa) 1
Naziv_procesa_1
2
Naziv_procesa_2
3
Naziv_procesa_3
4
Naziv_procesa_4
Procesi u DTP prvog nivoa (procesi nieg nivoa za roditeljski proces: Naziv_procesa_3 3.1
procesa_a
3.2
procesa_b
3.3
procesa_c
3.4
procesa_d
3.5
procesa_d
slika =.?. 3 : Procesi u DTP prvog nivoa (nii nivo procesa za roditeljski proces Naziv_procesa_3 Svaki grafiki blok Procesa na drugom nivou dekompozicije moe se dekomponovati na trei nivo, a potom trei na etvrti nivo, i tako dalje. Dekompozicija prestaje kada se svi blokovi procesa mogu opisati jednim pasusom na srpskom jeziku (narodski jednostavno i bez fraziranja i komplikovanja), kao Opis Elementarnog procesa (kao prosta aktivnost), kako bi se procesi mogli opisati formalno kao Funkcionalni Opis (Function Description), na primer pseudokodom ili sa flow-chart koji se moe realizvati jednim programskim blokom sa desetak operacija nad podacima. Sve to je sistem sloeniji to je potrebna njegova dekompozicija do sve nieg nivoa.
Metoda izrade DTP primena dijagrama toka podataka za definisanje poslovnih procesa
DTP ova (dijagrama toka podataka). Prvi DTP daje pregled celokunog sistema sa globalnim procesima, a dekompozicijom procesa sa dodatnim DTP-ovima obezbeuje se sve vie detalja o svakom podsistemu celog poslovnog procesa (delu sistema). Dakle, jedan vrlo vaan princip u procesu projektovanja DTP-a (prikazivanja dijagrama toka podataka) je dekompozicija
poslovnih procesa u niz DTP-ova, gde svaka komponenta tog niza predstavlja detalja na niem nivou apstraktnosti (nii nivo DTP). Slika 6-3 uopteno pokazuje kako se jedan poslovni proces dekomponuje u nekoliko nivoa DTP-a.
tok zu
Nivo 1. DTP
tok x
sektor U
tok w
sektor V
entitet A
proces U
tok y tok nu tok b
proces V
tok zi
entitet B
K1 skladite podataka
sektor T
tok a
tok ni
proces T
Nivo 2. DTP
za proces 2
tok b
2.1 sluba U proces D

tok h tok j
tok nu
D1 skladite podataka
2.2
tok ni
sluba
tok g
2.3
sluba
tok a tok y
proces E
proces F
Nivo 3. DTP
za proces 2.2
tok h1
2.2.1
poslovi
K
tok g1 tok g
proces K
tok h tok q tok h2
2.2.2
poslovi
tok r tok s tok g2
proces L
tok nu
2.2.3
poslovi
K1 skladite podataka
tok ni
proces M
Slika 6-3 Veze meu nivoima dijagrama toka podataka DTP realnog sistema
Popovi Marko
25
Tok izrade DTP

Dijagram konteksta
Prvi DTP u projektima svih poslovnih procesa, bilo da se radi o sistemu u kojem se procesi obavljaju runo ili kompjuterizovano, je dijagram konteksta (videti sliku 6-3). Kao to ime sugerie, dijagram konteksta prikazuje neposredno okruenje kontekst kojem pripada posmatrani sistem ili poslovni proces. Svi modeli procesa imaju samo jedan dijagram konteksta. Dijagram konteksta prikazuje sve poslovne procese kao samo jedan proces (sistem kao crnu kutiju) i prikazuje poslovno najbitnije protoke podataka do i od eksternih entiteta. Skladita podataka se obino ne nalaze na dijagramu konteksta. Neki projektanti IS u dijagramu konteksta kao eksterni entitet navode simbol skladita da bi eksplicitnije ukazali na eksterni entitet koji karakterie skladite podataka koje je "vlasnitvo" sistema ili procesa van posmatranog sistema. Na primer, informacioni sistem, koji koristi fakultetska biblioteka i koji zapisuje ko je pozajmio knjige, verovatno bi proverio fakultetsku bazu podataka (matinu evidenciju) o studentima da bi video da li je student uopte upisan na fakultet. U ovom dijagramu konteksta, fakultetsko skladite podataka o studentima bi trebalo da bude prikazana na dijagramu konteksta zato to se nalazi van bibliotekog sistema, ali koristi je. Mnoge analitiari ili projektanti ne bi prikazale ovo kao skladite eksterni entitet pod nazivom "Informacioni sistem biblioteke".
Dijagram najvieg nivoa najvii nivo DTP (prvi nivo dijagrama, nivo 1 DTP)
Nakon uraenog dijagrama konteksta, s TP se zove dijagram prvog nivoa, ili 1. nivo DTP-a (videti sliku 6-3). Dijagram 1. nivoa prikazuje sve procese nakon prve dekompozicije, tako to su procesi na prvom nivou numerisanja (tj. procese sa brojevima od 1 do 9), skladita podataka, eksterni entiteti i tokovi podataka meu njima. Svrha 0. nivoa DTP-a je da prikae sve glavne procese sa visokih nivoa sistema i kako su oni meusobno povezani. Svi modeli procesa imaju jedan i samo jedan DTP 0.nivoa. Drugi kljuni princip u stvaranju nizova DTP-a je balansiranje. Balansiranje znai obezbeivanje da se sve informacije predstavljene na DTP-u na jednom nivou predstave tano i em nivou DTP-a. To ne znai da su podaci identini, nego da su prikazani na odgovaraj . Postoji suptilna razlika u znaenju izmeu ova dva principa koja uskoro postati oigledna, ali za sada, hajde da uporedimo dijagram konteksta i 0. nivo DTP-a na slici 6-3, da vidite kako su ova dva dijagrama izbalansirana. U ovom sluaju, vidimo da su eksterni entiteti (A i B) identini u oba dijagrama toka podataka i da se tokovi podataka od i ka eksternim entitetima koji se pojavljuju na dijagramu konteksta (X, Y, Z) nalaze i na dijagramu 0. nivoa. Prvi nivo DTP-a zamenjuje jedan proces u dijagramu konteksta (uvek numerisan sa 0) sa tri procesa (1, 2, 3), dodaje skladite podataka (D1) i dvs dodatns toks podataka, koji nisu u dijagramu konteksta (tok podataka B iz procesa 1 ka procesu 2; tok podataka od procesa 2 ka procesu 3). Ove tri procesa i dva toka podataka nalaze se u okviru procesa 0. Nisu prikazani na dijagramu konteksta zato to su oni interne komponente procesa 0. Dijagram konteksta namerno skriva neke od sloenosti sistema da itaocu bilo lake da razume. Tek kada italac razume dijagram konteksta analitiar "otvara" proces 0 da pokae njegove interne operacije
dekomponovanjem diagrama konteksta u prvi nivo DTP-a, koji pokazuje vie detalja u vezi procesa i tokova podataka unutar sistema. Dijagrami 1. Nivoa Na isti nain na koji dijagram konteksta namerno skriva neke od sloenosti sistema, tako je i na 0. nivou DTP-a. Prvi nivo DTP-a pokazuje samo interakciju procesa na visokom nivou. Svaki proces na prvom nivou DTP-a moe se dekomponovati u precizniji nivo DTP-a, koji se zove dijagram drugog nivoa, ili na nivou 2 DTP-a, koji pokazuje u vie detalja kako se procesi odvijaju. DTP ilustrovan na Slici 6-1 je 2. nivo DTP-a. U principu, svi modeli procesa imaju onoliko dijagrama nivoa 2 koliko ima procesa na dijagramu prvog nivoa; svaki proces na DTP-u prvog nivoa se dekomponuje na svoj DTP 2. nivoa, tako da bi dijagram prvog nivoa na slici 6-3 imao tri dijagrama 2. nivoa (jedan za proces 1, jedan za proces 2 i jedan za proces 3). Radi jednostavnosti, mi smo odabrali da prikaemo samo jedan DTP 2. nivoa na ovoj slici, DTP za proces 2. Procesi u nivou 2 DTP-a su numerisani na osnovu procesa ije su dekomponente. U ovom primeru, mi smo dekomponovali proces 2, tako da su procesi u nivou 2 DTP-a numerisani sa: 2.1, 2.2 i 2.3. Procesi 2.1, 2.2 i 2.3 su deca (children) procesa 2, i proces 2 je roditelj (parent) procesa 2.1, 2.2 i 2.3. Ovo troje dece procesa potpuno i kompletno ine proces 2. Skup dece i roditelj su identini, oni su samo razliiti naini gledanja na istu stvar. Kada se roditelj proces dekomponije u procese decu, njegova deca moraju u potpunosti da obavljaju sve njegove funkcije na isti nain na koji iseena parad pite zajedno ine celu pitu. Iako parad ne moraju biti iste veliine, skup kriki je identian celoj piti, nita se ne gubi pri seenju pite. Jo jednom, veoma je vano da se obezbedi da su izbalansirani nivo 1 i nivo 2 DTP-a. Prvi nivo DTP-a pokazuje da proces 2 pristupa skladitu podataka D1, ima jednog tok podataka unosa (B) i ima dva izlazna toka podataka (A i Y). Provera prvog DTP-a pokazuje isto skladite i tokove podataka. Opet vidimo da su tri nova toka podataka dodata (G, H, J) na ovom nivou. Ovi tokovi podataka se nalaze unutar procesa 2 i samim tim nisu dokumentovani u prvom nivou DTP-a. Tek kada dekomponujemo ili otvorimo proces 2, preko 1. nivoa DTP-a vidimo da oni postoje. DTP drugog nivoa preciznije prikazuje koji proces koristi tok podataka B (Proces 2.1), a koji proizvodi izlazni tok podataka A i Y (proces 2.3). Imajte na umu, meutim, da nivo 2 DTP-a ne pokazuje odakle ovi tokovi podataka dolaze ili gde idu. Da biste pronali izvor toka podataka "B", na primer, moramo da se prebacimo na nivo 1 DTP-a, koji pokazuje da tok podataka B dolazi iz spoljnog entiteta B. Isto tako, ako pratimo tok podataka od A do DTP-a prvog nivoa , vidimo da ide u proces 3, ali mi jo uvek ne znam tano koji proces u okviru procesa 3 ga i koristi (na primer, proces 3.1, 3.2). Da bi utvrditi taan izvor, morali bi da ispitamo DTP 2. nivoa procesa 3. Ovaj primer pokazuje jednu manu dekompozicije DTP-a na vie stranica. Da biste pronali taan izvor i odredite tokova podataka, esto morate da pratite tok podataka kroz nekoliko DTP-ova na razliitim stranicama. Nekoliko alternativa ovom pristupu dekomponovanja DTP-a je predloeno, ali nijedna se ne koristi tako esto kao "tradicionalni" pristup. Naj je da se prikau i izvori i odredita tokova podataka ka i od eksternih entiteta (kao i skladita podataka) na niem nivou DTP-a. Kako ide u ili iz skladita podataka i eksternih entiteta, umesto sa druge stranice DTP-a, ovo moe mnogo da olaka itanje DTP-ova sa vie strana. Mi verujemo da je ovo bolji pristup, tako da na predavanjima prikazujemo spoljne entitete na svim DTP-ovima, ukljuuj dijagram 2. nivoa i ispod.
Popovi Marko
27
Dijagrami 2. nivoa Poslednji prikaz na slici 6-3 pokazuj je, dijagram 3. nivoa ili nivo 3 DTP-a za proces 2.2. Ovaj DTP prikazuje da je 2.2 dekomponovan na tri procesa (2.2.1, 2.2.2, i 2.2.3). Dijagram 2. nivoa za proces 2.2 prikazuje interakciju sa skladitem podataka D1, koja se ponovo javlja u nivou 3 DTP-a u procesu 2.2.3. Isto tako, nivo 3 DTP-a za 2.2 prikazuje jedan ulazni tok podataka (H) i jedan izlazni tok podataka (G), koje smo, takoe, videli na nivou 3 dijagrama toka podataka, kao i nekoliko novih tokova podataka (Q, R, S, H1, H2, G1, G2). Dakle dva DTP-a su izbalansirana. Ponekad je teko setiti se koji nivo DTP-a je koji. Moe vam zapamtite da je broj nivoa jednak broju taki (.) uveanom za jedan u numerisanim procesima na DTP-u. Na primer: 1.2 je numeracija procesa drugog nivoa (1.2 DTP 2. nivoa), 2.1.3 je numeracija procesa treeg nivoa (2.1.3 DTP 3. nivoa), i tako dalje. Rave i spojevi DTP-a (Splits and Joins) Tokovi podataka H1 i H2 na DTP-u nivoa 2, na slici 6-3 ilustruju ravanje (engleski: split) toka podataka H, u kojem je ovaj tok razdvojen na svoje sastavne delove. Za sloene (viestruke) relacije izmeu procesa, neki tokovi podataka se zapravo sastoje od mnogo razliitih elemenata podataka, kao recimo ime pacijenta, adresa pacijenta, vreme zakazanog pregleda i lekar. Rava u ovoj slici moe da se koristi da prikae da se ovaj deo podataka (na primer, ime pacijenta i adresa pacijenta) koristi u procesu 2.2.1, a drugi deo (na primer, lekar i vreme zakazanog pregleda) u procesu 2.2.3. Za razliku od dekompozicije procesa, ne postoji obaveza da tokovi podaka u ravama budu meusobno iskljuivi, niti da ukljuuju sve iz toka podataka roditelja. Tako, na primer, ime pacijenta i adresa pacijenta mogu otii u jedan proces, a ime pacijenta moe otii u drugi. Ili, kao na slici 6-1 iste informacije se mogu koristiti u dva ili vie procesa, a rava je najjednostavniji nain da se skrene tok podataka. Razlog za ravanje je taj to nam u viem nivou DTP-a nije bilo vano koji se delovi toka podataka gde koriste. Bilo je dovoljno j : "H" (ili "Informacije o pacijentu") na viem nivou. Kako prelazimo na nie nivoe, meutim, moramo biti precizniji o tokovima podataka na isti nain na koji smo postali precizniji o procesima. Tok podataka G na istom DTP-u ilustruje spoj (engleski: join). U ovom sluaju, odvojeni delovi toka podataka G (G1 i G2) udruuju se i formiraju zajedniki tok podataka. U naem primeru lekarske ordinacije, G1 moe biti informacije o pacijentu (ime, adresa),a G2 moda informacije o zakazanom pregledu (npr. vreme zakazanog pregleda, lekar). Ove tokove podataka proizvode razliiti procesi na najniem nivou DTP-a, ali se prikazuju kao jedan tok podataka "Informacije o zakazanom pregledu" na viem nivou DTP-a. Alternativni tokovi podataka Pretpostavimo da proces stvara dva razliita toka podataka pod razliitim okolnostima. Na primer, proces kontrole kvaliteta mogao bi da proizvede dve klase informacija: 1. kvalitetan i odobren proizvod, ili 2. neispravan proizvod, ili va zahtev za autorizaciju kreditne kartice mogao bi da proizvede "odobren" ili "odbijen" rezultat. Kako prikazujemo ove alternativne putanje u DTP-u? Odgovor je da prikazujemo oba toka i koristi se opis procesa da se objasni da su oni alternative jedan drugom. Na samom DTP-u nita ne pokazuje da su tokovi podataka meusobno iskljuivi. Na primer, proces 2.1 na DTP-u 2. nivoa proizvodi dva izlazna toka podataka (H i J). Bez itanja tekstualnog opisa procesa 2.1, ne znamo da li su ovi tokovi stvoreni istovremeno ili su meusobno iskljuivi.
Popovi Marko
28
Opis procesa
Svrha opisa procesa je da objasni ono to proces ini i prui dodatne informacije koje DTP ne prua. Dok se kreemo kroz ivotni ciklus projektovanja sistema (Systems Development Life Cycle ili SDLC), postepeno prelazimo sa tekstualnih opisa i zahteva na puno preciznije opise koji se na kraju mogu prevesti u precizne programske jezike sluajeva, proces je jednostavan dovoljno da definisanje zahteva, studija sluaja i DTP sa jednostavnim tekstualnim opisom daju dovoljno detalja za fazu dizajna. Ponekad, meutim, proces je dovoljno sloen da je bolje napraviti detaljniji opis logike koja se odvija unutar samog procesa. Tri najee tehnike koje se koristi za opisivanje sloenije logike procesa su: struktuiran jezik, grafovi odluka, tabele odluka. Za veoma sloene procese mogu da se koriste kombinacije struktuiranog jezika i bilo grafova odluka ili tabela odluka. Struktuiran jezik (Pseudokod) Tumaenje pojma i termina pseudokod Pseudokoda (naziv je izvededen od rei pseudo= i code= ) je zgusnuti i neformalni visoko-nivoski opis algoritma procesa transformacije podataka (raunarskog programa) koji konvencionalno koristi strukturu nekih programskih jezika, ali u kome su izostavljeni detaljlji koji nisu od znaaja za razumevanje algoritma, kao to su podprogrami (subrutine), deklarisanje varijabli, upravljanje memoriskim prostorom i sistemski specifini kodovi. Programski jezik je proiren sa opisima detalja pomou govornog jezika, gde je to pogodno, ili sa matematikim izrazima (formalno matematikim notacijama formulama). Pseudokod forma programa se moe lako konvertovati u realne programske naredbe. Pseudokod se ne moe ni kompajlovati ni izvesti jer ne postoje realna pravila za formate i sintaksu. To je prosto jedan korak ali vaan korak u pravljenju (programiranju, kodiranju) finalnog koda programa. Dobiti od pseudokoda su to se njime omoguava da se projektanti skoncentriu na algoritme ali da se ne brinu o sintaksnim detaljima specifinog programskog jezika (o kome brinu programeri koderi). U sutini, projektant IS moe pisati pseudokod bez poznavanja bilo kog programskog jezika. Namena pseudokoda je da ga ovek (ljudi) mogu lake itati nego konvencionalne programske jezike (kao to su Pascal, BASIC. C, Java, Lisp, ALGOL), i da bude kompaktan (zgusnutiji) i programski nezavisan opis kljunih principa algoritma. Ne postoji zvanian standard za sintaksu pseudokoda, tako program u pseudokodu ne moe direktno da se izvede na raunarau. Blokovi koda, na primer kod koji je unutar neke petlje, moe se opisati jednom reenicom govornog jezika. Sintaksne forme pseudokoda Blok-dijagram (flow chart) se moe smatrati grafikom alternativom za pseudokod. Pseudokod je slian, ali ne bi trebalo da se pobrkaju, sa skeleton programima (kosturom struktuiranim programima) koji se mogu kompajlovati (prevesti) bez problema i bez greke. Kako pseudokod zavisi od pisca to se on pie razliitim stilovima, u dijapazonu od imitacija realnog programskog jezika (prevedene naredbe na govorni jezik) kao jedan ekstrem, do opisa koji su slini literarnoj prozi (prianje pria o tome TA E RADITI PROGRAM) kao suprotan ekstrem.
Popovi Marko
29
Struktuiran jezik je samo formalan nain pisanja uputstva koji opisuju korake procesa. Struktuiran jezik jako potsea na programski jezik, jer on predstavlja prvi korak ka programu (ili protokolu, ako se radi o runom radu), koj obavlja proces. Struktuiran jezik koristi kratke reenice koje jasno opisuju ta se radi i sa kojim podacima. Postoji mnogo verzija struktuiranog jezika zato to ne postoje formalni standardi, svaka organizacija ima svoju vrstu struktuiranog jezika. Slika 6-4 prikazuj naredbi struktuiranog jezika. Izvrne naredbe su jednostavne naredbe koje izvravaju neku radnju. AKO (IF) naredbe kontroliu radnje koje se izvode pod razliitim uslovima, dok je DOK (FOR ili WHILE) naredba ciklinog obavljanja nekih radnji sve dok se ne postigne zadati uslov ili odreeno stanje. Konano, USD (U Sluaju Da; engleski: CASE) naredba je napredni oblik AKO naredbe koja se koristi ako ima nekoliko meusobno iskljuivih grana. Na primer, studija sluaja za zakazivanje predmeta o kojoj smo govorili na slici 5-1i koju smo koristili za kreiranje DTP-a koji je prikazan na slici 6-1, govori ta se deava u procesu "Proveravanje statusa pacijenta" ako pacijent jeste novi pacijent ili ako pacij . DTP po sebi ne objanjava ovo. Stoga, opis procesa u procesu 1.1 DTP-a mora da obezbedi potrebne dodatne informacije. Slika 6-5 pokazuje kako bi to bilo izraeno u struktuisanom jeziku.
este naredbe Akcione naredbe izvrne aktivnosti AKO naredba (IF) za odreeni uslov (AKO uslov) definisanje radnji koje se obavljaju kada je zadovoljen uslov (ONDA uraditi) i kada nije zadovoljen ulov (INAE uraditi) DOK naredba (FOR ili WHILE) definisanje ponavljajuih radnji sa podacima sve dok je zadovoljen neki uslov USD naredba (CASE) definisanje alternativa Primer Profit = zarada trokovi Generii stanje skladita Dodaj podatke o proizvodu u skladite AKO kupac nije u skladitu kupaca ONDA dodaj podatke o kupcu u skladite INAE ubaci podatke o kupovini kupca u skladite podataka o svim kupovinama DOK ima kupaca u bazi RADI Generii novu liniju u izvetaju o kupcima Upisi ukupni profit od kupovine kupca USD U Sluaju Da prihod < 10000, porez = 10% prihod < 20000, porez = 20% prihod < 30000, porez = 30% prihod < 40000, porez = 40% INAE porez = 38%
(U Sluaju Da)
Slika 6-4 Struktuiran jezik 1.1 Proveravanje statusa pacijenta /* Opis procesa svrha ovog procesa je da moemo da zakaemo pregled pacijenta samo ako status pacijenta to dozvoljava.*/ AKO pacijent = nov_pacijent ONDA Izvri proces dodavanje_novog_pacijenta INAE AKO pacijent ima neplaene raune, if uslov (dugovanje > 0); ONDA Poalji pacijenta na alter za uplatu
Slika 6-5 Primer struktuiranog jezika
Popovi Marko
30
Pokazaemo jedan jednostavan primer koji ukazuje razlike izmeu pseudokoda i stvarnog programskog koda (PHP) prikazan je na sledeoj slici (Slika 6-5-1)
Programski kod (pisan u PHP): <?php if (je_ispravan($brojKK)) { izvrsi_transakciju($brojKK, $ n0_nalog); } else { prikazi_gresku(); } ?> Pseudokod: Ispitivanja Ako je ispravan (je_ispravan) broj kreditne kartice (brojKK) tada izvri transakciju na osnovu njenog broja i naloga (n0_nalog) inae prikai poruku o nastaloj greci kraj Ispitivanja
Slika 6-5-1: Primer razlike izmeu pseudokoda i stvarnog programskog koda (php)
Korienje pseudokoda U strunim knjigama i naunim publikacijama koje se odnose na raunarske i numerike nauke (computer science and numerical science), termin pseudokod obino se koristi za opise algoritama, takav da ga mogu razumeti svi programeri, ak i ako svi ne poznaju iste programske jezike. U knjigama, obino mu se pridruuje uvodno objanjenje o specifinim konvencijama koje se koriste (vae) za psudolod. Nivo detaljnosti nekog od tih jezika moe u nekim sluajevima moe biti sa pristupm koji odgovara formalizovanim jezicima opte namene (formalized general-purpose languages). Na primer Knuthova prva knjiga The Art of Computer Programming opisuje algoritme u poluspecifikacionom asemblerskom jeziku za nepostojee mikroprocesore (fully specified assembly language for non existent microprocessor). Programer koji treba da napravi (isprogramira) neki specifian algoritam, naroito ako je neiskusan, obino e zapoeti sa pseudokod opisom, a potom prosto prevesti taj opis ciljni programski jezik i modifikovati ga da bi bio usklaen sa ostatkom programa. Programeri takoe mogu zapoeti sa pseudokod skicom koda na papiru pre nego to ponu pisanje u stvarnom programskom jeziku, to odgovara pristup topdown struktuiranja. Grafovi odluka (Stabla odluke) Grafovi odluka su grafiki nain opisa logike koja se nalazi u AKO naredbi struktuiranog jezika. Grafovi odluka su korisni samo kada postoji veliki broj ugnedenih AKO naredbi, tj. ako imamo AKO naredbu, koja je unutar druge AKO naredbe, koja je unutar tree AKO naredbe. Slika 6-6 pokazuje jednostavan graf odluka za prvi korak u procesu zakazivanja pregleda. Svaki krug je taka odluke, koja predstavlja pitanje (AKO naredbu). Taka odluke ima skup ishoda koj se granaju u razliitim pravcima koji vode na druge take odluke. Na slici 6-6, imamo seriju da/ne pitanja gde svako ima po dve grane, ali mi moemo izgraditi i grafove odluke koji imaju vie od dve grane u svakom trenutku odluke komplikovanijih pitanja (npr., razliite iznose prihoda koji dovode do razliitih poreskih stopa) i u ovom sluaju take odluke su sline CASE naredbi u sluaju struktuiranog jezika. Grafovi odluka su vizuelni. Nekim ljudima je lake da koriste grafove odluke, dok ostali radije koriste naredbe struktuiranog jezika a ljudi lake razume grafove odluka nego struktuiran jezik, ako imamo tri do etiri take odluke. Ako imamo vie od etiri take odluke, crtanje grafova odluka na jednoj strani moe da postane teko, tako da za sloenije logike, mi koristimo tabele odluke.
Popovi Marko
31
Izvrenje procesa 2 dodavanje novog pacijenta
da
Upuivanje pacijenta u raunovodstvo da pacijent regulie plaanje Raspored pregleda odreivanje termina pregleda pacijenta
Novi pacijent ?
da ne
Pacijent ima dugovanja ? ako pacijent nije platio neki prethodni raun?
ne
SLIKA 6-6 Graf odluka za proveru statusa pacijenta
Tabele odluka Tabele odluka se koriste za veoma sloene procese koji imaju vie pravila odluka. Slika 6-7a pokazuje potpunu tabelu odluivanja za isti proces. Gornji levi deo tabele odluka pokazuje uslove koji treba da budu testirani (nov pacijent i rauni), a donji levi pokazuje radnju koja treba da se obavi (izvri proces 2, zakai pregled i uputi pacijenta u kancelariju). Uslovi i mere su povezani pravilima. Gornji desni deo navodi pravila i sve e vrednosti koje se mogu javiti kada se testiraju uslovi (da ili ne). Donji desni deo tabele pokazuje koje se radnje izvravaju za svako pravilo ( "X", znai da se akcija izvrava, a prazano polje ukazuje na to da se akcija ne izvodi). Pravilo 1, na primer, tvrdi da kada je uslov 1 "da" (nov pacij ) onda se akcija A1 vri (obavlja proces 2). Ako paljivo pogledate primetiete da se pravilo 3 nikad ne koristi, iz prostog razloga to ne moemo imati neplaene raune pacijenta kojeg nikad nismo videli. Drugi uslov nije potreban da bi se odluilo A1. Slika 6-7b pokazuje uproenu tabelu odluka koja reorganizuje pravila da bi smanjila tabelu i detaljnije prikazala da se uslov C2 ne ispituje kada je uslov C1 da (to je prikazano praznim poljem pored C2 u koloni pravilo 1). i ljudi se tabele odluka ine komplikovanijim za razumevanje od grafova odluka ili struktuiranog jezika, ali su mnogo preciznije kada je u pitanju komplikovanija logika procesa. Tabele odluka je najbolje koristiti kada postoji pet ili vie odvojenih uslova koji treba da budu razmotreni.
Uslovi C1: Novi pacijent C2: Neplaeni rauni Pravilo 1 da ne x x x Pravilo 2 ne ne Pravilo 3 da da Pravilo 4 ne da
Akcije (naredbe)
A1: Izvri proces 2 dodaj novog pacijenta A2: Zakai pregled A3: Poalji pacijenta na alter za uplatu
SLIKA 6-7-a : Kompletna tabela odluka; (a)
Popovi Marko
32
Uslovi C1: Novi pacijent C2: Neplaeni rauni
Pravilo 1 da
Pravilo 2 ne ne
Pravilo 3 ne ne
Akcije (naredbe)
A1: Izvri proces 2 dodaj novog pacijenta A2: Zakai pregled A3: Poalji pacijenta na alter za uplatu x x x
SLIKA 6-7-b : Redukovana tabela odluka (b)
Pravljenje dijagrama konteksta konkretne izrada (aktivnosti projektovanja) Dijagram konteksta definie nain na koji je poslovni proces ili raunarski sistem u interakciji sa njegovom okolinom, pre svega sa eksternim entitetima. Da bi se kreirao dijagram konteksta, jednostavno se nacrta simbol jednog procesa za poslovni proces ili direktno povezati sa skladitima podataka u spoljnom sistemu. Takva spoljna skladita podataka mogu biti navedena kao samo skladite podataka to i jeste, ili jednostavno kao eksterni entitet koji nosi naziv sistema koji rukuje tim skladitem podataka. Nijedno od skladita podataka unutar procesa posmatranog sistema koje stvara proces ili sam sistem nije ukljueno u dijagramu konteksta, . Pravljenje dijagrama toka podataka konkretne izrada (aktivnosti projektovanja) Dijagrami toka podataka poinju sa informacijama prikupljenim iz studija sluaja i definicije zahteva. Iako se studije sluaja prave saradnjom korisnika i projektanata, DTP-ove uglavnom prave projektantski (analitiarski) timovi, pa ih tek onda pregledaju korisnici. Uopteno govorei, set DTP-ova koji ine model procesa jednostavno integriu individualne studije sluaja (i dodaju procese definisane u zahtevima, koji se nisu pojavili u studijama sluaja). Projektanti uzimaju studije sluaja i zapisuju ih kao DTP-ove. Zato to DTP ima pravila i simbole koji moraju da se ispotuju, projektanti nekad moraju da prilagode studije sluaja, kako bi mogli da ih predstave u DTP-u. Najee promene su u nazivima sluajeva koji postaju procesi i ulaza i izlaza tokova podataka. Jo jedna esta promena je objedinjavanje manjih ulaza i izlaza iz studija sluaja u vee tokove podataka u DTP-u (npr. spajanje ime pacijenta, adresa pacijenta, broj telefona pacijenta u jedan tok informacije o pacijentu). Projektantski timovi esto koriste alatke za modelovanje procesa ili CASE alate za prikaz modela procesa. Prosti alati kao Visio, su samo zgodni alati za crtanje koji rade crtee bez kontrole, kao powerpoint, tako da ne proveravaju sintaksu i znaenje DTP elemenata. Drugi alati kao to je BPWin razumeju DTP i mogu da vre nekoliko provera sintakse, kako bi se lake uoilo da li je DTP, bar donekle, taan. Potpun CASE alat kao to je VAW (Visible Analyst Workbench), prua mnoge mogunosti za kontrolisano modelovanje procesa. CASE alati tee da budu vrlo kompleksni, kao takvi su od velike pomoi, ali esto kotaju vie nego to doprinose projektovanju.
Popovi Marko
33
Pravljenje modela procesa koji ima vie nivoa DTP-a obino podrazumeva pet koraka. Prvo, tim gradi dijagram konteksta koji pokazuje sve spoljne entitet , ovi DTP fragmenti su organizovani u nivo 0 DTP-a. etvrto, tim razvija nivo 1 DTP-ova, na osnovu koraka u svakom sluaju, da bolje objasni kako oni rade. U nekim sluajevima, ovi DTP-ovi prvog nivoa su dalje raslojeni na DTP-ove drugog, treeg, etvrtog nivoa DTP-a, i tako dalje. Peto, tim potvruje skup DTP-ova da bi se uverili da su potpuni i tani.
Slika 6-8: Upisivanje procesa u DTP pomou kompjuterske alatke za projektovanje sistema (iz literature alat ERVIN) Slika 6-9 prikazuje dijagram konteksta koji opisuje informacioni sistem pacijenta, od kojeg je uzet DTP 1. nivoa za proces zakazivanja pregleda na slici 6-1. Interesantno je uporeenje ove dve slike. Trebalo bi uoiti da dijagrami imaju isti eksterni entitet: pacijent. Svi ulazi i izlazi na nivou 1 DTP-a su takoe prisutni u dijagramu konteksta, iako je "ime pacijenta" u prvom nivou DTP-a navedeno kao vii nivo toka podataka "informacije o pacijentu," koji bi prikljuio ime pacijenta, kao i mnotvo drugih informacija kao to su zdravstveno osiguranje i ostale informacije. Nekoliko drugih eksternih entiteta je prikazano (npr. lekar, osiguravajua kompanija), kao i drugi tokovi podataka (na primer, raun, informacij ), jer ih ima i u drugim studijama sluaja.
Popovi Marko
34
Fragmentacija (dekompozicija) dijagrama toka podataka Fragment DTP-a je jedan deo DTP-a koji e se na kraju spojiti sa ostalim fragmentima DTP-a kako bi zajedno formirali kompletan DTP. U ovom koraku svaka studija sluaja se pretvara u jedan DTP fragment.
ID pacijenta 0 promena ID ambulanta raspored
pacijent
mogunost elja ponitenje raun uplata kartoni
lekar
informacioni sistem o pacijentima
salda
faktura
isplata
Zdravstveno osiguranje
Slika 6-9 Dijagram konteksta za informacioni sistem o pacijentima u lekarskoj ordinaciji
Legenda nazivi i znaenje tokova podataka

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ID pacijenta podaci o pacijentu Promena ID promenjeni podaci o pacijentu Mogunost lista termina moguih zakazivanja pregleda elja eljeni termin pregleda ponitenje ponitavanje zakazanog pregleda, otkaz pregleda raun faktura ili formular uplatnice za pacijenta uplatazvanina uplatnica od pacijenta, potvrda pacijentovog izvrenog plaanja faktura faktura za zdravstveno (socijalno) osiguranje isplata raun od zdravstvenog osiguranja potvrda uplate zdravstvenog osiguranja raspored izvetaj o zakazivanjima kartoni izvetaji o pacijentima salda finansiski izvetaji
Popovi Marko
35
nacrtati DTP fragment za svaku studiju sluaja podatke date na vrhu sluaja: ime, ID broj, i glavne ulaze i izlaze. Informacije o glavnim koracima koji ine svaki sluaj se zanemaruju u ovom trenutku e). Slika 6-10 prikazuje studiju sluaja i DTP fragment koji je nastao iz nje. Opet, neke suptilne ali vane promene se esto koriste pri konvertovanju studije sluaja u DTP. Dve naj je imena procesa i dodavanje tokova podataka. Ne postoje formalna pravila za imenovanje studija sluaja, ali postoje formalna pravila za imenovanje procesa u DTP-u. Sva imena procesa moraju poeti sa glagolom (videti sliku 62). Nisu sva imena naih sluajeva struktuirana na taj nain, pa ih je ponekad potrebno promeniti. Takoe je vano imati konzistentan nain kod imenovanja procesa. Na primer, DTP na slici 6-10 je napisan sa stanovita ordinacije lekara, a ne pacijenta. Sva imena procesa i opisi su pisani kao aktivnosti koje zaposleni u ordinaciji obavljaju. To je ustaljen nain dizajniranja procesa, tako da to ponekad zahteva neke dodatne promene u imenu. Druga esta promena je dodavanje tokova podataka. Studije sluajeva se piu da bi se opisala interakcija sistema sa korisnikom. Obino ne opisuju kako sistem dobija podatke, tako da studija sluaja esto izostavlja podatke proitane iz skladita podataka. Kada pravite DTP fragmente, vano je da se uverite da su sve informacije koje korisnik dobija iz skladita podataka. Najlaki nain da ovo uradite je da prvo kreirate DTP avnih ulaza i izlaza na vrhu studije sluaja, a zatim se uverite da svi izlazi imaju dovoljno ulaza da ih naprave. Ne postoje formalna pravila koja pokrivaju raspored procesa, tokova podataka, skladita podataka, i eksternih entiteta u DTP-u. Njih moete postaviti gde god hoete na stranici; ali, poto zapadne kulture itaju od gore ka dole i s leva na desno, analitiari sistema se trude da stave procese u sredinu DTP fragmenta, tako da glavni ulazi idu sa leve ili gornje strane u proces, a izlazi sa desne ili donje strane iz procesa. Skladita podataka su uglavnom ispod procesa.
pacijent
Informacija o promeneni podataka o pacijentu ID i podaci o pacijentu podaci o pacijentu K1 KARTOTEKA Podaci o pacijentima
informacije o pacijentu
2.
kartoteka
Auriranje podataka o pacijentima
(b) Jedan deo DTP

Slika 6-10 jedan deo DTP za lekarsku ordinaciju kontekst procesa na osnovu II bloka use case
Popovi Marko
36
blok 1.
Naziv studije: ambulanta broj sluaja: 2 Kratak opis sluaja: auriranje podataka o pacijentu Pobuda: dolazi novi pacijent ili se menjaju podaci o starom pacijentu Tip pobude: spoljna ili unutranja ili vremenska
blok 2.
Vani ulazi
Opis ulaza
Informacije o pacijentu
-------------------
Vani izlazi
Izvor podataka pacijent
------------------------
Opis izlaza
podaci o pacijentu
--------------------
odredite podataka kartoteka

--------------------
Informacija o promeneni podataka o pacijentu

-------------------
pacijent
------------------------------------------------------------------------------------------------------------------------------------------
ID i podaci o pacijentu
-------------------------------------
kartoteka
----------------------------------------------blok 3.
Glavni koraci
(a)
Informacije
Primer sluaja (use case)

pacijent
Informacija o promeneni podataka o pacijentu ID i podaci o pacijentu podaci o pacijentu K1 KARTOTEKA Podaci o pacijentima
informacije o pacijentu
2.
kartoteka
(b) Jedan deo DTP

Slika 6-10 delimian DTP za lekarsku ordinaciju odnosi se na deo primera sluaja Na sledeoj slici (Slika 6-11 pokazan je jedan od naina na koji mogue nacrtati DTP fragment. Postoji mnogo pravilnih naina da se nacrta ovaj dijagram.
Ime pacijenta Promena ili ponitenje mogunost elja zakazano
recepcija ambulante
pacijent
Zakazivanje termina pregleda
podaci o pacijentu K1 KARTOTETKA Podaci o pacijentima K2
mogunost zakazivanja
zakazano
AGENDA Lista termina pregleda
Slika 6-11 DTP fragment za lekarsku ordinaciju prikazuje jedan nain (kontekstualni) na koji je mogue nacrtati DTP fragment.
Legenda nazivi i znaenje tokova i skladita podataka (za sliku 6-11)

Ime pacijenta ime i prezime pacijenta, broj zdravstvenog kartona ili knjiice Promena ili ponitenje datumi otkazanog i promenjenog termina pregleda Mogunost lista slobodnih termina za pregled elja eljeni termin pregleda Zakazano - odreeni termin pregleda podaci o pacijentu podaci o pacijentu u zdravstvenim kartonima AGENDA Lista termina pregleda KARTOTETKA kartonui sa podacima o pacijentima Pravljenje prvog nivoa dijagrama toka podataka Kada postavite i nacrtate sve fragmente DTP-a (jedan za svaki od glavnih studija sluaja), moete jednostavno da ih ukombinujete u jedan DTP i time dobijate 0. nivo DTP-a. Kao to je ranije pomenuto, ne postoje formalizovana pravila za raspored elemenata na DTPu a pokuava da stavi proces koji je hronoloki prvi u gornjem levom uglu dijagrama i nastave dalje od vrha do dna, s leva na desno (npr. Slika 61 a pokuava da smanji broj ukrtanja linija tokova podataka ili da obezbede da se ukrtaju pod pravim uglom kako bi bilo manje zabune (na liniji koja preseca mnogi nacrtaju malu grbu koja oznaava da se tokovi ne spajaju, nego prelaze
Popovi Marko
38
jedan preko drugog). Smanjenje broja tokova podataka koji prelaze jedan preko drugog je izazov. Ponavljanje (kopiranje) je kamen temeljac dobrog dizajna DTP-a. ak i iskusni analitiari retko savreno nacrtaju DTP jeva, oni ga nacrtaju jednom da bi razumeli model procesa, tokova podataka, skladita podataka, kao i eksterne entitete, a onda crtaju drugi put na sveem listu papira (ili novoj datoteci) da bi lake razumeli i da bi smanjili broj tokova podataka koji prelaze jedan preko drugog. esto se DTP crta mnogo puta pre nego to je zavren. Slika 6-12 kombinuje DTP fragmente sa slika 6-9 i 6-10 sa DTP fragmentima druga dva sluaja (proces 3, napravi obraun i proces 4, pripremi izvetaje za menadment). Odvojite trenutak da ispitatate sliku 6-12 i pronaete DTP fragmente iz slika 6-10 i 6-11 sadrane u njemu. Pravljenje prvog nivoa dijagrama toka podataka (i niih) Tim sada poinje da stvara DTP nieg nivoa za svaki proces na prvom nivou DTP-a za koji je potreban nivo 2 DTP-a. Svaki od primera sluaja (studija sluaja) se pretvara u sopstveni DTP. Proces za kreiranje prvog nivoa DTP-a je da se preuzmu koraci koji piu u primerima sluaja (use case) i da se preslikaju u DTP, slino kao i za i nivo DTP-a. Obino, svaki korak u studije sluaja postaje proces na nivou 1 DTP-a, pri emu ulazi i izlazi postaju ulazni i izlazni tokovi podataka, mada su ponekad potrebne i sitne promene da bi se od neformalnog opisa u studiji sluaja dobili formalni modeli procesa, kao to je dodavanje ulaznih tokova podataka koji nisu bili prikazani u studiji sluaja. I zato to su analitiari sada poinju dublje da razmiljaju o tome kako informacionog sistema, oni ponekad malo promene korake u studijama sluaja da bi uinili proces jednostavnijim za upotrebu. Uz tradicionalni pristup kreiranju DTP-a, izvori i odredita nisu dati na prvom nivou DTP-a (i nie) za ulaze koji dolaze od i do eksternih entiteta (ili drugih procesa izvan ovog (posmatranog) procesa). Ali, izvor i odredite tokova podataka skladita podataka i tokova koji idu u procese u okviru ovog DTP-a ukljueni su (odnosno, od jednog koraka na drugi u istoj studiji sluaja, na primer "Informacije o pacijentu", korak od 1.1 do 1.2 na slici 6-1 0 DTP-a. Problem sa ovim pristupom je to to da bi se zaista razumeo nivo 1 DTP-a, morate pogledati nazad na nivo 0 DTP-a. Za male sisteme koji imaju samo jedan ili dva DTP-a prvog nivoa, to nije veliki problem. Ali, za velike sisteme koji imaju vie nivoa DTP-a, problem raste, u cilju razumevanja destinaciji toka podataka na nivou 3 DTP-a, morate da proitate DTP drugog nivoa, DTP 1. nivoa i 0. nivo DTP-a, ako je odredite neki drugi sistem, onda morate da traite u niim nivoima DTP-a za taj sistem. Ukljuivanje spoljnih entiteta u prvi i nie nivoe DTP-a dramatino se pojednostavljuje itljivost DTP-a, sa vrlo malo mana. Slaemo se da je -ovi nisu standardizovani, svaka organizacija ih koristi malo drugaije. . U idealnom sluaju, trudili bi smo se da baze podataka u prikazujemo na istom mestu na stranici . Mi pokuavamo da nacrtamo ulazne tokove podataka tako da dolaze sa leve ivice stranice, a
Popovi Marko
39
izlazne tokove podataka ostavljamo na desnoj ivici. Na primer, pogledajte DTP 1. nivoa na slici 6-3.
obraun Raun_1 Ime pacijenta Promena ili ponitenje mogunost elja zakazano 1 recepcija ambulante
pacijent
podatak o pacijentu_1 Informacija o pacijentu
podatak o pacijentu_3
K1
KARTOTETKA L2 zakazani
podatak o pacijentu_ 4
moguna zakazivanja AGENDA lista zakazanog
zakazano
podatak o pacijentu_3
2 kartoteka
blagajna
obraunavanje
izvetaj o pacijentu zakazano finansiski izvetaj
knjigovodstvo
Priprema izvetaja
obraunski podaci
podaci o uplati
raun_3 raun_2
podaci o isplati
lekar
K3 glavna knjiga
osiguranje
Slika 6-12: DTP prvog nivoa za sistem lekarske ordinacije
Popovi Marko
40
Jedno vano pitanje je kako nacrtati male tokove tokovima podataka na nivou 1 DTP-a. Na primer, DTP drugogog nivoa moe da pokae ulazni tok podataka Informacije o pacijentu, dok pojedinani koraci u studiji sluaja koriste (koji postaju procesi na nivou 2 DTP-a) del (za ulazni tok podataka) i spojeva (za izlazne tokove podataka). Prvi nivo DTP-a na slici 6-3 prikazuje "H" kao ulaz za proces 2.2, dok drugi nivo DTP-a pokazuje kako "H" ulazi u DTP ali se rava na dva dela ( "H1", koji koristi proces 2.2.1, i "H2", koji koristi proces 2.2.2). Ista slika prikazuje i spajanje: G na DTP-u prvog nivoa kao proizvod spajanja "G1 "i" G2 "u DTP-u 2. nivoa. Jedan od naj pri dizajnu je znati kada dekomponovati DTP 2. nivoa u nie nivoe. Dekompozicija DTP-a se moe svesti do gotovo svakog nivoa, na primer, moemo razloiti proces 1,2 na DTP-u prvog nivoa na procese 1.2.1, 1.2.2, 1.2.3, i tako dalje na DTP-u drugog nivoa. Ovo se moe ponoviti do bilo kog nivoa detalja, tako da je mogue imati etvrti nivo ili ak peti nivo DTP-a. Ne postoji jednostavan odgovor za "idealan" nivo dekompozicije, jer to zavisi od sloenosti sistema ili poslovnih procesa koji se modeluju. U principu, procese dekomponujemo u niem nivou DTP-a samo kad je taj proces dovoljno sloen da bi dodatna dekompozicija pomogla da se bolje obj je da treba da postoji najmanje tri procesa i ne vie od sedam do devet procesa na svakom DTP-u, tako da ako razloite proces i na novom nivou dobijete sa samo dva procesa, verovatno ni ne treba da ga razlaete. Nema potrebe dekomponovati proces u novi nivo da bi dobili samo dva procesa, bolje je samo prikazati ta dva procesa na prethodnom nivou. Isto tako, DTP sa vie od devet procesa korisnicima postaje teak za itanje i razumevanje, jer je veoma kompleksan i naguvan. Neke od tih procesa treba objediniti i objasniti na niim nivoima DTP-a. Model procesa j koji se planira, ako se koristi struktuiran nain projektovanja (tj, ako se ne koristi Rapid Application Development [RAD]), ili ako e sistem biti izgraena od strane eksternih ugovaraa. Bez kompletnih nivoa detalja, moe biti teko da se u ugovoru odredi tano ta sistem treba da radi. Ako se koristi RAD pristup, koji podrazumeva puno interakcije sa korisnicima i veoma esto prototipovima, manja je mo se prikloniti niskom nivou detalja, j dizajn razvijati kroz interakciju sa korisnicima. V ide samo do drugog nivoa. Ne postoji obaveza da se svi delovi sistema moraju dekomponovati na isti nivo DTPa. Neki delovi sistema mogu biti veoma sloeni i zahtevati mnogo nivoa, dok ostali delovi sistema mogu biti jednostavniji i zahtevati manje. Validacija dijagrama tokova podataka Nakon to ste napravili skup DTP-ova, vano je da proverite njihov kvalitet. Slika 613 prikazuje brzi potsetnik za identifikaciju naj . Postoje dva fundamentalno razliita tipa problema koji se javljaju u DTP-ovima: sintaksne i semantike greke. Sintaksa se odnosi na strukturu DTP-a i da li DTP-ovi slede pravila DTP jezika. Sintaksne greke se mogu posmatrati i kao gramatike greke koje je napravio analitiar dok je stvarao DTP. Semantika se odnosi na znaenje DFDs i da li su tano opisuJu poslovnih procesa se modelira. Semantike greke se mogu posmatrati kao i nesporazumi analitiara pri prikupljanju, analiziranje i izvetavanju o sistemu.
Popovi Marko
41
, analitiari moraju paljivo i mukotrpno da pregledaju ba svaki proces, eksterni entitet, tok podataka i skladita podataka na svim DTP-ovima rukom da bi proverili da li su dosledna gledita, dekompozicije i balans.
Unutar DTP-a Proces
Tok podataka
Skladite podataka
Eksterni entitet Izmeu DTP-a Dijagram konteksta Gledite Dekompozicija Balans
Svaki proces ima jedinstveno ime(koje je glagol), broj i kratak opis Svaki proces ima bar jedan ulazni tok podataka Svaki proces ima bar jedan izlazni tok podataka Izlazni tokovi podataka uglavnom imaju drugaija imena od ulaznih tokova podataka (izuzetak je kod skladita podataka, gde se pretpostavlja da se isti podaci i upisuju i itaju) Ima od 3 do 7 procesa po DTP-u Svaki tok podataka ima jedinstveno ime (koje je imenica) i kratak opis Svaki tok podataka povezan je sa bar jednim procesom Podaci teku samo u jednom smeru (nema dvosmernih strelica) Minimalni broj ukrtenih tokova podataka Svako skladite podataka ima jedinstveno ime (koje je imenica), broj i kratak opis Svako skladite podataka ima bar jedan ulazni tok (koji oznaava dodavanje ili izmenu podataka u skladitu) Svako skladite podataka ima bar jedan izlazni tok (koji oznaava iitavanje podataka iz tog skladita) Svaki eksterni entitet ima jedinstveno ime (koje je imenica) i opis Svaki eksterni entitet ima bar jedan ulazni i bar jedan izlazni tok podataka Svaki set DTP-ova mora imati samo jedan dijagram konteksta Postoji konzistentno gledite za ceo set DTP-ova Svaki procese je u potpunosti opisan procesima u DTP deci Svaki tok podataka, svako skladite podataka i svaki eksterni entitet prikazan na viem nivou DTP-a, mora biti prikazan i na niim nivoima koji ga dekomponuju Nijedno skladite podataka ili tok podataka se ne pojavljuju na DTP-u nieg nivoa, ako se ne pojavljuju i na viem nivou Korisnika validacija Simluranje procesa Ispitajte DTP najnieg nivoa Paljivo ispitajte nazive
Semantika Primerena reprezentacija Konzistentna dekompozicija Konzistentna terminologija
Slika 6-13 / tabela: Lista kontrole kvaliteta DTP-a
ksne greke koje analitiari poetnici prave pri kreiranju DTP-a su u krenju zakona o odranju podataka3. Prvi deo tog zakona navodi da: Podatak u mirovanju ostaje u mirovanju sve dok ga ne pokrene proces. Drugim reima, podaci se ne mogu kretati bez procesa. Podaci ne mogu da idu ili dolaze iz skladita podataka, ili eksternih entiteta bez procesa koji bi ih gurnuli ili povukli. Drugi deo Zakona navodi da: Procesi ne mogu da unite ili stvore podatke. Drugim reima, podaci samo ulaze ili naputaju sistem putem eksternih entiteta. Proces ne moe unititi ulazne podatke; svi procesi moraju imati izlaz. Nacrtan proces bez izlaza se ponekad
3
Ovaj zakon je razvio Prof. Dale Goodhue na Dordija univerzitetu

petak, 12. mart 2010 42
Popovi Marko
naziva grekom "crna rupa". Isto tako, proces ne moe da kreira nove podatke; moe samo da transformie podatke iz jednog oblika u drugi, ali ne moe da proizvede izlazne podatake bez ulaza. Crtanje procesa bez ulaza se ponekad naziva "udo" greka (jer se izlazni podaci pojave udom). Postoji jedan izuzetak4 u delu zakona o ulazima, ali je tako redak da analitiara nikad na njega ne naie. Slika 6-14 prikazuje neke uobiajene greke u sintaksi. obraun
raun Ime pacijenta 1 recepcija ambulante
pacijent
Promena ili ponitenje mogunost elja
zakazano
Eksterni entitet ne moe direktno pristupiti skladitu K1 KARTOTETKA Skladite bez izlaza podaci o pacijentu
zakazano sinonim, isti naziv izlaznog i ulaznog toka podataka

zakazano
L2 AGENDA Skladite bez ulaza lista zakazanog
2 kartoteka
Proces nema izlaznih podataka

izvetaj o pacijentu zakazano finansiski izvetaj
knjigovodstvo
3
uplate
blagajna
obraunavanje
Proces nema ulaznih podataka

K1 glavna knjiga
podaci o fakturi i isplati
ne sme biti dvosmerni tok podataka osiguranje
lekar
Tok nema veze sa procesima sistema
Slika 6-14: este greke sintaksne greke u DTP
Izuzetak je temporalni proces koji pokree okida baziran na internom satu. Svaki put kada odreeni period proe proces proizvodi izlaz. Ovaj proces nema ulaza zato to je sat interni element procesa.
petak, 12. mart 2010 43
Popovi Marko
oju sistema. Semantike greke su mnogo tee za pronalaenje i ispravku, jer zahtevaju dobro razumevanje poslovnih procesa. Pa ak i tada, ono to se moe identifikovati kao greka moe zapravo biti neshvatanje osobe koja vri proveru modela. Postoje tri korisne provere kako bi osigurali da su modeli semantiki ispravni (vidi grafikon 6-13). Prvi potvrdi ispravnost modela prolazei kroz model (tj. model se predstavi korisnic -a na isti nain na koji su igrali ulogu u studijama sluaja. Korisnici se pretvaraju da izvravaju procese upravo onako kako je opisano u DTP-u. Zapoinju u p , kako bi dobili traene izlaze. Onda prelaze na drugi proces i tako dalje. Jedna od malo suptilnijih formi semantike greke javlja se kada proces pravi izlaz na osnovu nedovoljno ulaznih informacija. Na primer, u cilju stvaranja vode (H20), moramo da imamo i vodonik (H) i kiseonik (O). Isto vai i za raunarske sisteme, tako da izlazi procesa mogu biti samo kombinacija i transformacije njegovih ulaza. Pretpostavimo, na primer, elimo da zabeleimo narudbinu, trebalo bi nam ime klijenta i potanska adresa, koliina i cene E-proizvoda koje kupac naruuje. Nama trebaju informacije iz skladita podataka o korisnicima (na primer, adresa) i podaci iz skladita podataka e-prodavnice (npr. cena). Mi ne moemo nacrtati proces koji proizvodi izlazni tok podataka za narudbinu bez ulaza iz ova dva skladita podataka. Igranje uloga uz striktno pridravanje ulaza i izlaza na modelu je jedan od najboljih naina da naete ovu vrstu greke. Druga provera , svi procesi treba da budu na istom nivou detalja, to nije isto to i isti broj nivoa. Na primer, pretposta : (1) ui u auto; (2) startuj motor; (3) vozi. Jo jedan nivo detalja bi bio: (1) otkljuaj auto; (2) sedi u auto, (3) vei sigurnosni pojas i tako dalje. Jo jedan nivo bi bio: (1) izvadi klju iz depa, (2) ubacite klju u kljuaonicu; (3) okreni klju, i tako dalje. Nijedan od njih nije nasledno bolji od drugih, ali u neobinim okolnostima, obino je najbolje da se obezbedi da svi procesi na samom dnu modela pruaju isti nivo detalja. este greke su: sinonimi naziva, tok podataka izmeu entiteta, skladitu nedostaje ulazni ili izlazni tok podataka, procesu nedostaje ulazni ili izlazni tok podataka, dvosmerni tok podataka, tok podataka neposredno izmeu eksternih entiteta (tok nema veze sa procesima sistema Obino, svaki korak u studije sluaja postaje proces na nivou 1 DTP-a, pri emu ulazi i izlazi postaju ulazni i izlazni tokovi podataka, mada su ponekad potrebne i sitne promene da bi se od neformalnog opisa u stu informacionog sistema, oni ponekad malo promene korake u studijama sluaja da bi uinili proces jednostavnijim za upotrebu. Isto tako, vano je da se osigura da je terminologija usklaena u celom modelu. Isti element moe imati razliite nazive u razliitim delovima organizacije, tako da "narudbenica" kod jedne osobe moe biti "narudbina muterije". Isto tako, isti termin moe imati razliita znaenja, na primer, "datum isporuke" moe da znai jednu stvar prodavcu koji uzima narudbinu n datum), a neto drugo do magacioneru u skladitu (na primer, stvarni datum isporuke). Reavanje ovih razlika pre nego to je zavren model je vano kako bi svako ko ita modela ili koristi informacioni sistem izgraen od modela ima podjednako razumevanje.
Projektovanje IS Primena koncepta na eprodaji Eproizvoda

Pravljenje dijagrama konteksta Projektantski tim je poeo kreiranjem dijagrama konteksta e-prodaje E-proizvoda (softvera, e-knjiga, muzike ili CD-ova, i slinog). Proitali su gornji deo tri glavne studije sluaja na slici 5-6 da bi pronali glavne ulaze i izlaze. Prvi sluaj (obuhvatanje zahteva za E-proizvode) sadri etiri glavna ulaza od korisnika i dva skladita podataka. Skladita podataka su unutar sistema, tako da nisu dokumentovana u dijagramu konteksta. Ovaj sluaj , jedan izlaz za posebnu bazu podataka za narudbenice i jedan za bazu u prodavnici. Baze podataka za narudbenice je eksterna internet sistemu, pa je dokumentovana u dijagramu konteksta, ali kao sistem. Baza podataka unutar prodavnice je neto sloenija. Nije strogo interna internet sistemu e, ali je deo ovog projekta razvoja sistema, pa se moe rei da je u okviru "sistema" iroko tumaivi. Bud e studija sluaja za upravljanje sistema prodavnice biti deo internet sistema, i zato to bazu podataka prodavnice koristi samo internet sistem, projektantski tim je odluio da e se ovo skladite podataka smatrati kao interno skladite internet sistema. Slika 6-15 prikazuje nekompletan dijagram konteksta nakon razmatranja samo prve studije sluaja. Tim pre studije sluaja. Odvojite trenutak i dovrite dijagram konteksta na slici 6-15 dodavaj je iz preostale dve studije sluaja. Slika 6-16 prikazuje konaan dijagram konteksta koji je razvio projektni tim.
zahtev pretrage
e-prodaja
sistem za specijalne narudbine
kupac
Pronaeni materijal traenje informacija informacija o ponudi lista ponuda zahtev (narudbina) informacije o korisniku isporueni materijal specijalan zahtev
Slika 6-15: Dijagram konteksta pokrivanja prodaja uobiajenih materijala nekompletan Dijagram konteksta sistema eprodaje
Popovi Marko
45
D1: Podaci o proizvodima

podaci o proizvodu zahtev pretrage
D2: Stanje zaliha

podaci o zalihama promena zaliha eksterni marketing materijal informacije dobavljaa zahtev dobavljau
dobavlja
kupac
Pronaeni materijal traenje informacija informacija o proizvodu lista ponuda zahtev (narudbina) informacije o korisniku
e-prodaja
interni marketing materijal izvetaji
isporueni materijal
IS marketinga
specijalan zahtev nalog otpremi
potvrda isporuke
opomena otpremi
IS specijalnih narudbina
IS otpreme (interno skladite)
Slika 6-16: Dijagram konteksta sistema e prodaje Dijagram konteksta na slici 6-16 je veoma zaguen (pretrpan), posebno u okolini eksternog entiteta kupac. Neki analitiari bi moda u ovom sluaju pokuali da sjedine neke od ovih tokove podataka u tok podataka vieg nivoa (snop). Na primer, dva izlazna toka podataka koji predstavljaju odgovore na ove zahteve (tj. E-proizvodi koji odgovaraju pretrazi, informacije o E-proizvodu, reklamni materijal) mogu da budu upakovana u jedan tok podataka nazvan "odgovor pretrage". snopova ini dijagram konteksta jednostavnijim. Meutim, to zahteva da i DTP prvog nivoa koriste te iste snopove i na kraj da odreeni DTP drugog nivoa ili nieg koristi rave i spojeve, kako su ovi snopovi prikazani kao da su ulazni za DTP, a specifini elementi unutar njih se koriste u procesima DTP-a. Takva upotreba ravi i spojeva nivoima. To je stvar odabira za koji nema tanog odgovora na pitanje ta je ispravno, a ta nije. Mi smo odabrali da ne grupiemo ove tokove podataka na dijagramu konteksta da bi izbegli sloenost ravi i spojeva kasnije. Pravljenje fragmenata dijagrama toka podataka bi bio da se napravi jedan DTP fragment za svaku studiju sluaja. Ovo je uinjeno crtanjem procesa u sredini stranice, vodei rauna o tome da su brojevi procesa i naziv sa spajanjem svih ulaznih i izlaznih tokova podataka na njega. Za
Popovi Marko
46
razliku od dijagrama konteksta, DTP fragment ukljuuje tokove podataka sa eksternim entitetima i unutranjim i eksternim skladitima podataka. studije sluaja za crtanje DTP fragmenta, tim bi shvatio da fali jedan ulaz. Proces je imao izlazni tok podataka koji se zvao informacije o E-proizvodu koje je slao eksternom entitetu korisnik. Meutim, nije bilo ulaznog toka podataka koji obezbeuje te informacije. Dakle, tim e ga dodati DTP-u (i odgovarajuoj studiji sluaja). Slika 6-17 prikazuje DTP fragment za prvu studiju sluaja. Ako uporedite Slika 6-17 sa slikom 6-16 e izgledaju gotovo isto, iz prostog razloga to je prvi korak u stvaranju dijagrama kontekst isti kao i za stvaranje DTP fragmenata, osim to DTP fragment obuhvata interne podataka prodavnice. DTP fragmenti za druga dva sluaja su podjednako jednostavni. Postoji vie dobrih naina da se nacrtaju oba. Pravljenje DTP-a prvog nivoa e bio da se napravi DTP nultog nivoa spajanjem DTP fragmenata, to je prolo bez dodatnih izmena. Projektant je jednostavno uzeo DTP fragmente i nacrtao ih zajedno na jedan komad papira. Iako je ponekad izazov organizovati sve DTP fragmente na jednom komadu papira, to je pre svega mehanika veba (Slika 6-19). U ovom sluaju, proktanti su pokuali da pozicioniraju spoljne entitete na slina mesta na ovom DTP-u kao na dijagramu konteksta na slici 6-16, jer se tako lake razumeju ova dva dijagrama. D1: Podaci o proizvodima
podaci o proizvodu zahtev pretrage
D1: Stanje zaliha

podaci o zalihama
D3: marketing podaci

marketing materijal
kupac
Pronaeni materijal traenje informacija informacija o proizvodu lista ponuda zahtev (narudbina) informacije o korisniku isporueni materijal
1
Obuhvat zahteva
specijalan zahtev
nalog otpremi
Slika 6-17: DTP kontekstualni fragment pokrivanja obuhvat zahteva internet nabavku
Popovi Marko
47
D1: Podaci o proizvodima

podaci o proizvodu informacije dobavljaa

marketing materijal
dobavlja
2
Auriranje marketing materijala
marketing materijal marketing izvetaji
marketing materijal dobavljaa
IS marketinga a) DTP ragment auriranje marketing podataka D4: Podaci o otpremi

Zahtev za otpremu potvrda otpreme promene zaliha
3
proces otpremanje
nalog otpremi potvrda isporuke opomena otpremi
D2: Stanje zaliha
b) DTP ragment auriranje marketing podataka Slika 6-18: Ostala dva DTP fragmenta za eprodaju
Popovi Marko
48
Pravljenje dijagrama toka podataka prvog nivoa (i ispod)

informacije dobavljaa marketing materijal marketing izvetaji
2
Auriranje marketing materijala
informacija o proizvodu D1: Podaci o proizvodima podaci o proizvodu
dobavlja
marketing materijal dobavljaa
IS marketinga
marketing podatak
zahtev pretrage
kupac
Pronaeni materijal traenje informacija informacija o ponudi lista ponuda zahtev (narudbina) informacije o korisniku isporueni materijal specijalan zahtev
1
Obuhvat zahteva
marketing materijal D3: marketing podaci
podaci o zalihama nalog za otpremu
D2: Stanje zaliha D4: Podaci o otpremi

Zahtev za otpremu potvrda otpreme
IS za specijalne narudbine
3
proces otpremanja
nalog otpremi potvrda isporuke opomena otpremi
promene zaliha
IS otpreme (interno skladite) Slika 6-19: Prvi nivo DTP e-trgovine E-proizvodima -ovi prvog nivoa za one procese od koji moe biti od koristi. Analitiari su poeli sa prvom studijom sluaja (uzimanje zahteva kupca) i poeli su da crtaju DTP-ove za pojedinane korake koje je sadrala studija. Prva tri koraka u studiji sluaja bila su jednostavna, ali kao i inae, ekipa je morala da izabere imena i brojeve
Popovi Marko
49
za procese i da dodaje ulazne tokove podataka iz skladita podataka koji se nisu pojaljivali u studiji sluaja. Poslednja etiri koraka u studiji sluaja zahtevala su neka promiljanja. Pretpostavimo da nam je poznata studija sluaja e kupovine (softvera, e-knjiga, i Eproizvoda ija studija sluaja se esto pominje u literaturi). Poslednja etiri koraka su odabir jednog ili vie E-proizvoda, odjava uz evidentiranje podataka o klijentu, kao i zahtevi obinih i specijalnih narudbina. Pri razmiljanju o tome kako je to uraeno na drugim Web lokacijama, projektant je odluio da koristi pristup korpe za kupovinu (shopping car E-proizvode u virtuelnu korpu za kupovinu i eventualno nastaviti potragu za drugim E-proizvodima, pre odjave. Stavljanje E-proizvoda u korpu za kupovinu bi bio jedan proces, i odjavljivanje bi bio drugi proces. Proces odjavljivanja bi takoe ukljuivao slanje obinih i specijalnih narudbi, pre nego se oni stave u posebne procese. Njihova verzija DTP-a prvog nivoa za prvu studiju sluaja je prikazana na slici 6-20. DTP drugog nivoa za etrgovinu
zahtev pretrage Pronaeni materijal traenje informacija podaci o proizvodu marketing materijal
1.1
opis1
Odabir materijala
kupac
opis2
D1: podaci o proizvodima
1.2
Davanje informacija o materijalu
marketing materijal

podaci o zalihama
ID materijala raspoloivo u skladitu narudbina isporuka
1.3
pronalaenje materijala u skladitu
D2: stanje zaliha
1.4
Formiranje korpe kupca, i dostavljanje materijala kupcu specifikacija isporuke specifikacija rauna
D4: isporueni proizvodi
struktura isporuke
1.5
Provera i potvrda dostavljanog materijala
specijalan zahtev
potvrda kupca o korisniku
Slika 6-20 DTP drugog nivoa za proces 1, obuhvat zahteva
Popovi Marko
50
pominjanja korpe kao skladita podataka, ali oigledno nam je potrebno da negde sauvamo koji su E-proizvodi izabrani. Bilo bi sasvim logino da se ukljui drugo skladita podataka koje bi se zvalo D5: Korpa za kupovinu koja prima izlaz iz procesa 1.4 i alje ulaz u proces 1.5. Ovo skladite podataka je privremeno skladite podataka koje sadri podatke samo dok kupac ne zavri kompletiranje narudbine, ili dok ne napusti transakciju. Kada se kupac odjavi, privremeno skladite (korpa za kupovinu) se brie. Po nekada, ne ukljuuju se privremena skladita podatka koja ne preive transakciju na DTP-ovima. Ali opet, ni to ne bi bilo pogreno, samo nije uobiajeno. Umesto toga, mi prikaemo da proces 1.4 alje podatke procesu 1.5 preko toka podataka. rocesa na ovom prvom nivou DTP-a sa kritinog znaaja u toku faze dizajniranja za razvoj modela podataka i kreiranje korisnikog interfejsa i programa. Validacija dijagrama toka podataka Konaan skup DTP-ova prvo overava (proverava) projektantski tim, a zatim ga overavaju korisnici na finalnom JAD sastanku. Nekoliko manjih izmena je identifikovano. Kada je sistem definisan na papiru, projektni tim fomira DTP pomou odgovarajueg CASE (automatizovane projektantske alatke).
Rezime
Sintaksa dijagrama toka podataka etiri simbola se koriste u dijagramima toka podataka (proces, tok podataka, skladite podataka, kao i eksterni entitet). Proces je aktivnost obavlja neku radnju. Svaki proces ima naziv (poinje sa glagolom), opis i broj koji pokazuje gde se nalazi u odnosu na druge procese i decu procese. Svaki proces mora imati najmanje jedan izlaz, i obino ima najmanje jedan ulaz. Tok podataka je podatak ili objekat i ima naziv (imenica) i opis i poinje ili se zavrava na procesu (ili oboje). Skladite podataka je papir ili raunarska datoteke i ima broj, ime (imenica), a najmanje jedan ulazni tok podataka i jedan izlazni tok podataka (osim ako skladite podataka nije stvorio proces van dijagrama toka podataka [DTP]). Spoljanji entitet je entitet ili organizacija (sistem) izvan opsega posmatranog sistema i ima naziv (imenica) i opis. Svaki set DTP-ova poinje sa dijagramom konteksta i ima brojne DTP-ove prvog, drugog itd, nivoa. Svaki element na DTP-u vieg nivoa (npr. tok podataka, skladite podataka, eksterni entitet) mora da se pojavljuje i na DTP-ovima nieg nivoa inae nisu izbalansirani. Tok podataka moe da se rava i spaja na bilo kom nivou seta DTP-a, ali je ovo, uglavnom, uobiajeno na niim nivoima. Pravljenje dijagrama toka podataka Dijagrami tokova podataka se prave koristei studije sluaja. Prvo, tim pravi dijagram konteksta koji prikazuje sve eksterne entitete i tokove podataka koji ulaze i izlaze iz posmatranog sistema. Zatim, tim pravi fragmente DTP-a za svaku studiju sluaja, koji prikazuju kako studija sluaja razmenjuje tokove podataka sa eksternim entitetima i skladitima podataka. Tree, ovi DTP fragmenti se organizuju u DTP nultog nivoa. etvrto,
Popovi Marko
51
tim razvija DTP-ove drugog nivoa na bazi koraka u studiji sluaja, unutar svake studije sluaja, da bi detaljnije objasnili kako funkcioniu. Zatim, projektanti proveravaju DTP setove, da bi bili sigurni da su kompletni i tani i da nemaju ni sintaksnih ni semantikih greaka. Analitiari retko naprave valjan DTP iz prvog pokuaja, pa je iteracija jako vana da bi bili itki i dijagrami koji staju na jednu stranicu, ali i oni koji se proteu na nekoliko stranica.
Literatura
1. Dennis A., Wixon B.:SYSTEMS ANALYSIS DESIGN, John Wiley & Sons Inc.,2003, ISBN 0-471-07322-9 2. C.Ashworth & M.Goodland: SSADM A Practical Approach, McGraw-Hill, 1990. 3. D.E.Avison & G.Fitzgerald: Information Systems Development, Blackwell, 1991 4. David A. Marca: SADT. Structured Analysis and Design Technique, McGraw-Hill, 1988. 5. Philip L. Weaver: Practical SSADM, Pitman, 1993 Pitanja u vezi DTP za koje je odgovor moj sistem 1. Objasniti grafiku i tekstualnu notaciju koji se koriste u Dijagramima Toka Podataka (DTP) . 2. Koji su principi modelovanja Dijagramima Toka Podataka (DTP)? 3. Za ta je korisno modelovanje Dijagramima Toka Podataka (DTP)? 4. Prouiti svoj vlastiti realni sistem i nacrtati model DTP za svoj sistem. Skupovi DTP U praksi koriste se razliiti skupovi DTP za opisivanje ciljnog sistema (IS koji se projektuje) na razliite naine, polazei od realnog sistema (za koji se projektuje IS) da bi se specificirao zahtevani sistem (IS koji se projektuje) : ta sistem sada radi -analiza RS (realnog sistema) tj. postojei sistem ili organizacija Kako on radi - DTP RS , logiki projekat postojeeg sistema ta treba da radi -projekat IS, zahtevani logiki DTP Kako treba da radi -dizajn IS, zahtevana fizika struktura IS.
Popovi Marko
52

0 - 3 DTP Modeli Procesa

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

0 - 3 DTP Modeli Procesa

Uploaded by

Copyright:

Available Formats

DTP modeli procesa - 2010

petak, 12. mart 2010

DTP modeli procesa - 2010

petak, 12. mart 2010

DTP modeli procesa - 2010

DTP modeli procesa - 2010

petak, 12. mart 2010

DTP modeli procesa - 2010

Dijagram toka podataka

Podaci o proverenom pacijentu

Podaci o proverenom pacijentu

Nalaenje mogueg termina pregleda

mogui termin pregleda Ime pacijenta Podaci o otkazivanju

Slika 6-1 Prijavnica lekarske ordinacije inenjerski grafik, nestandardizovane forme

DTP modeli procesa - 2010

eljeni termin pregleda

Podaci o proverenom pacijentu

Podaci o proverenom pacijentu

mogui termin pregleda

Nalaenje mogueg termina pregleda

mogui termin pregleda

Ime pacijenta Podaci o otkazivanju

petak, 12. mart 2010

DTP modeli procesa - 2010

petak, 12. mart 2010

DTP modeli procesa - 2010

DTP elementi i njihovi atributi struktura komponenata

simboli koje su uveli

simboli koje su uveli

Yourdan, DeMarco, i Coad

kratak opis procesa

Naziv skladita podataka

Naziv klase entiteta

Naziv klase entiteta

petak, 12. mart 2010

DTP modeli procesa - 2010

Element dijagrama toka podataka

simboli koje su uveli

simboli koje su uveli

DeMarco, Yourdan , i Coad

kratak opis procesa

Naziv toka podataka

Naziv toka podataka

Naziv skladita podataka

Naziv klase entiteta

Naziv klase entiteta

petak, 12. mart 2010

DTP modeli procesa - 2010

petak, 12. mart 2010

DTP modeli procesa - 2010

Element DTP komponenta dijagrama toka podataka

simboli koje se koriste na FAM

Modifikovani skup simbola koje su uveli DeMarco,

-standard Gane i Sarson

Naziv toka podataka

Naziv toka podataka

Naziv klase entiteta

Naziv klase entiteta

petak, 12. mart 2010

DTP modeli procesa - 2010

Element DTP komponenta dijagrama toka podataka

simboli koje se koriste na FAM

Naziv toka podataka