0_3 dtp modeli procesa

DTP modeli procesa - 2010

Popović Marko petak, 12. mart 2010 1

Prikazivanje procesa

Procesi koje posmatramo su podsistemi (odreĊena pokrivanja) nekog poslovnog

sistema. Pomoću modela procesa predstavljamo (opisujemo) statiĉku strukturu poslovnog

sistema. Modeli procesa opisuju poslovne procese, taĉnije aktivnosti koje ljudi obavljaju u

vezi podataka, i koriste sa da opišu i realno, trenutnu strukturu poslovnog sistema (realnog

sistema, skraćeno RS), i strukturu novog sistem koji se projektuje (informacioni sistem,

skraćeno IS). Ovo poglavlje opisuje pravljenje dijagrama toka podataka, koji je jedan od

najĉešće korišćenih metoda pri modelovanju sistema.

Ciljevi

Potpuno shvatanje pravila i tehniĉkih 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 računarski podržanih DTP alata (CASE) ........................................................... 8

Sintaksa računarski podržanih DTP alata (CASE) ............................................................................... 10

Grafički simboli Dijagrama Toka Podataka –prilagođenje standarda .............................................. 11

Grafički simboli Dijagrama Toka Podataka –prilagođenje standarda ........................................... 12

Proces –aktivnosti transformacije podataka ................................................................................... 13

Strukture i smisao simbola procesa u DTP – Forma pogodna za predstavljanje postojećih 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 –opšta pravila u vezi toka podataka ....................................... 16

Eksterni entitet .................................................................................................................................. 17



Karakteristike eksternog entiteta...................................................................................................... 17

Skladište Podataka ............................................................................................................................ 18

Forme predstavljanja skladišta podataka ......................................................................................... 19

Forma skladišta podataka pogodna za predstavljanje projektovanih sistema (IS) ........................... 19

Forma skladišta podataka pogodna za predstavljanje projektovanih sistema (IS) ........................... 20

Forme pretstavljanja „duplikata“ skladišta podataka ....................................................................... 20

Dijagram konteksta ........................................................................................................................... 21

Smisao dijagrama konteksta .......................................................................................................... 22

Ciljevi i postupci projektovanja DTP – analitički 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 najvišeg nivoa –najviši nivo DTP (prvi nivo dijagrama, nivo 1 DTP) ...................... 26

Dijagrami 1. Nivoa ............................................................................................................................ 27

Dijagrami 2. nivoa ............................................................................................................................. 28

Raĉve 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 nižih)................................................................. 39

Validacija dijagrama tokova podataka .............................................................................................. 41

Projektovanje IS –Primena koncepta na e-prodaji E–proizvoda ..................................................... 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 e–trgovinu ...................................................................................................... 50



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 statiĉke (relacione i klasifikacione) strukture ĉije su

osnovne komponente ĉetiri klase podsistema, odnosno aktivnosti:

1. Procesi –aktivnosti transformacije podaka u okviru odreĊenog (fokusiranog) pokrivanja;

2. Tokovi podataka –aktivnosti prenošenja podataka izmeĊu sistema (podsistema);

3. Skladita podataka –aktivnosti smeštanja („upisivanja“), eliminisanja („brisanja“),

promena („ažuriranja“), potraživanja („uĉitavanja“), i ĉuvanja

(„memorisanja“) podataka;

4. Eksterni entiteti –aktivnosti podsistema iz neposrednog okruženja 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 obraĊenog), govorilo se o aktivnostima prikupljanja podataka, kao

što su intervju i JAD, i transformacije dobijenih podataka u primera sluĉaja (use case)

odnosno studije sluĉaja (case study). U ovom delu teksta (poglavlju o DTP) govori o

tome kako ove informacije i iz studije sluĉaja dalje mogu da se urede i pretvore u modele

procesa.

Model procesa je formalni naĉin predstavljanja funkcionisanja poslovnog sistema.

On ilustruje procese ili aktivnosti u vezi podataka, koji prate poslovne aktivnosti, i kretanje

podataka meĊu poslovnim aktivnostima. Model procesa se može 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 (raĉunarski podržan ili

manuelan).

Danas se u praksi koristi mnogo razliĉitih tehnika modelov

biti usmeren na jednu od najĉešće citiranih ehnika1:

U ovom tekstu kao referentna metodologija dijagrama toka podataka ili DTP korišćena je

metodologija IDEF0 koju administracija (vlada) Sjedinjenih ameriĉkih država koristi

iskljuĉivo, obzirom da su je preuzeli mnogi poslovni sistemi uz neznatne i formalne izmene.

Namena DTP Metodologije je ureĊivanje postupka izrade dijagrama toka podataka

kao tehnike koja služi za opis poslovnih procesa i prikazivanje tokova podataka meĊu tim

procesima. U ovom poglavlju, prvo će biti opisana osnovna sintaksa i pravila pomoću kojih se

na jednoj strani ilustruje DTP. Onda će biti opisano kako da se kreiraju složeniji dijagrami na

više 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.



Iako ime dijagram toka podataka implicira da se fokusira samo na podatke, to nije

sluĉaj. Fokus je uglavnom na procesima ili aktivnostima koje se obavljaju u vezi podataka

koji prate radne procese (fiziĉke 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 najvažnijih veština potrebnih sistem analitiĉarima (analitiĉarima sistema,

projektantima i inženjerima sistema).

U ovom delu teksta (poglavlju) irati na logiĉke modele procesa –zbog

ĉega je pažnja usmerena na formalne strukture koje opisuju procese bez navoĊenja kako se ti

procesi fiziĉki izvršavaju. Kada se posmatra logiĉki model procesa, ne može se reći 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 skladište u datoteku ili veliku bazu podataka. Ovi detalji se definišu

tokom faze dizajniranja (izvoĊaĉkog ili aplikativnog projektovanja) kada se ovi logiĉki

modeli preraĊuju u fiziĉke modele, koji pružaju informacije potrebne za konaĉnu izgradu

informacionog sistema (što je u jednom od poglavlja koje slede –u radu je Poglavlje ?8?:

projektovanje sistema –System design). Fokusiraj , analitiĉari se

mogu usredsrediti na to kako bi biznis (poslovni sistem) trebao da radi bez preopširnih opisa

implementacionih detalja.

U ovom poglavlju, prvo će biti objašnjeno kako da se posmatraju i prepoznaju DTP-

ovi i biće objašnjeni njihovi osnovni simboli. Onda će biti opisan proces, koji se sprovodi pri

izradi DTP-ova, koji koristi informacije iz studija sluĉaja i dodatnih informacionih zahteva

prikupljenih od korisnika.



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. Sledeća slika (Slika 6-1) prikazuje jedan deo DTP-a za lekarsku

ordinaciju. Ovaj dijagram je pretstavljen u nestandardizovanojformi. Posmatrajući ovaj

dijagram, analitiĉar može da shvati na koji naĉin se u ovoj ordinaciji zakazuje pregled.

Pregledajmo malo ovaj dijagram pre nego se preĊe na ĉitanje sledećeg paragrafa. Koliko je taj

dijagram razumljiv?

Slika 6-1 Prijavnica lekarske ordinacije –inženjerski grafik, nestandardizovane forme

Lako je prepoznati da je ovaj dijagram grafiĉka forma studije sluĉaja „zakazivanje

pregleda kod lekara“, koji opisuje kako pacijenti zakazuju, otkazuju i menjaju zakazane

preglede. Većina ljudi poĉne da ĉita (posmatra i prepoznaje) dijagram toka podataka iz levog

gornjeg ugla DTP-a, pa se zato većina projektanata trudi da prilagodi dijagrame tako da poĉnu

baš u tom uglu, mada ovo nije uvek moguće. 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).

Pacijent Ţeljeni termin pregleda

mogući termin pregleda

4. SEKRETAR

Poništavanje

zakazivanja

3. SEKRETAR

RasporeĎivanje

zakazivanja

Ime

pacijenta

Podaci o

pacijentu

mogući termin

pregleda

Podaci o

zakazivanju

Ime

pacijenta

Podaci o

otkazivanju

poništeno zakazivanje

Podaci o proverenom pacijentu

Ime

pacijenta

Kartoni

pacijenata

Lista zakazivanja

Podaci o

zakazivanju


2. SEKRETAR

Nalaţenje

mogućeg

termina

pregleda

1. RECEPCIJA

Proveravanje

statusa

pacijenta



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 traži od pacijenta njegovo ime i upisuje ga u listu (svesku, protokol) kako

bi našao njegov (odgovaraj ) karton.

Proces "Proveravanje statusa pacijenta" ima pet strelica, ili pridruženih 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 skladišta podataka, koja

sadrže podatke (uskladištene informacije). Ako se obrati pažnja na dijagram, uoĉavaju se dva

razliĉita grafiĉka simbola (oznaĉenih kao: Kartoni pacijenata i Lista zakazivanja) koji

reprezentuju skladišta podataka realne ordinacije. Obzirom da za DTP nisu bitni naĉini fiziĉke

realizacije skladišta, sva skladišta podataka se pretstavljaju jedinstvenim simbolima

(otvorenim pravougaonikom) kako je predstavljeno na sledećoj slici (slika 6-1.1)

Slika 6-1.1 Prijavnica lekarske ordinacije –deo DTP za „recepciju“ lekarske ordinacije

Obratimo pažnju na pravougaonik K1, koji je otvoren sa desne strane, sa naslovom

"Kartoni pacijenata ". Ovo je skladište podataka koje sadrži podatke (memorisane

informacije) o pacijentima, i na slici se može videti da ovo skladište pruža informacije o

pacijentu procesu "Proveravanje statusa pacijenata", što je prikazano strelicom od skladišta

podataka do procesa. Posmatranjem DTP, uoĉava se da se mogu razumeti ovi procesi ĉitajući

tokove podataka koji teku izmeĊu svih procesa i eksternih entiteta.

Pacijent Ţeljeni termin pregleda

mogući termin pregleda

4. SEKRETAR

Poništavanje

zakazivanja

3. SEKRETAR

RasporeĎivanje

zakazivanja

Ime

pacijenta

Podaci o

pacijentu

mogući termin

pregleda

Podaci o

zakazivanju

Ime

pacijenta

Podaci o

otkazivanju

poništeno zakazivanje


Ime

pacijenta

Podaci o

zakazivanju


2. SEKRETAR

Nalaţenje

mogućeg

termina

pregleda

1. RECEPCIJA

Proveravanje

statusa

pacijenta

K1 Kartoni pacijenata

L1 Lista zakazivanja



Jednostavno je shvatiti da proces "Proveravanje statusa pacijenta" koristi ime

pacijenta dato od strane pacijenta kako bi preuzeo podatke o njemu iz skladišta podataka

"Kartoni pacijenata“ ( što je u manuelnoj realnosti KARTOTEKA sa Kartonima pacijenata).

Odatle, prikupljene informacije mogu da se termina za

zakazivanje. Proces "RasporeĊivanje zakazivanja" koristi skup slobodnih termina iz skladišta

podataka "Lista zakazivanja“ (liste sa slobodnim terminima i teminima zakazanih pregleda,

kako bi osoblju bilo eno termine pacijentu –možda neće svi

slobodni termini biti pogodni pacijentu, takoĊe neki pacijenti mogu da zahtevaj i ili duži

pregled u zavisnosti od njihovih zdravstvenih problema. Informacije o pacijentu i odabran

termin se zatim koriste da zakazivanje pregleda, koji se skladište u skladištu podataka "Lista

zakazivanja".

Na dijagramu se može videti da postoji jedan proces za otkazivanje pregleda

"Poništavanje zakazivanja", ali nema procesa za promenu zakazanog pregleda. Ako se

pažljivo 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

pokušali 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, biće predstaljena sintaksa ili jezik

iskazivanja DTP, koji obuhvata skup simbola i sintaksnih pravila. Postoje ĉetiri simbola u

DTP jeziku (proces, tok podataka, skladište podataka, kao i eksterni entitet), od kojih je svaki

predstavljen drugim grafiĉkim simbolom. U literaturi, postoje dva naj a naĉina

obeležavanja DTP skupova simbola 2, odnosno setova DTP grafiĉkih primitiva prikazanih na

sledećoj 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 naĉin nema apsolutnu prednost, neke organizacije koriste Gane i Sarson

forme simbola, a druge koriste simbole koje su definisali DeMarco, Coad i Yourdan.

MeĊutiml, najĉešće su organizacije koje su uvele vlastite „standardne simbole“. U ovom

tekstu (knjizi) najĉešće ćese koristiti jedna modifikacija ove dve sintakse, koja se koristi na

fakultetu za Mendžment u Novom Sadu –pod nazivom FAM sintaksa, kao deo Metodologije

za izradu seminarskih radova.

Proces U opštem sluĉaju radni proces je aktivnost ili funkcija koja se obavlja iz nekih

specifiĉnih 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“ (ruĉna manipulacija sa podacima) ili „automatizovani“

(kompjuterizovani –podržani raĉunarskom obradom podataka. Svakom procesu se pridružuje

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.



naziv ili ime koje uobiĉajeno poĉinje sa glagolom a završava sa imenicom (npr. "Pronalaženje

pacijenta", "Ispravljanje podataka o pacijentu"). Imena treba da budu kratka, ali da ipak

sadrže dovoljno informacija, tako da ĉitalac lako i taĉno razume šta ti procesi rade. U

principu, svaki proces obavlja samo jednu aktiv

reĉi, koje ukazuju na to da proces obavlja više delatnosti.

DTP elementi i njihovi

atributi

–struktura komponenata dijagrama toka

podataka

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 pratećoj

pseudokod dokumentaciji

Najmanje po jedan ulazni i izlazni tok

podataka

Tok podataka

Predstavlja veze izmeĊu procesa –relacije

Globalno opisuje prenošene podatke

Detaljan opis strukture podataka je u reĉniku–

adresaru podataka

Tok je vektor, ĉije su komponente: pravac,

smer, i naziv toka

–Naziv toka podataka je naziv relacije

(imenica)

Skladište podataka Naziv skladišta – (imenica)

Može se navesti oznaka ili broj skladišta (n0),

–n0 je mnemonik

Struktura skladištenih podataka je opisana u

reĉniku–adresaru podataka

Najmanje jedan ulazni tok podataka

Eksterni entitet

Naziv eksternog entiteta –ime klase eniteta

(imenica)

Opis eksternog entiteta je u reĉniku–adresaru

podataka

Slika 6-2-1 Elementi dijagrama toka podataka – najĉešći primeri grafiĉkih simbola i atributi komponenata DTP

Strukture interfejsova računarski podržanih DTP alata (CASE)

Na osnovu literature, slika 6-2-1 prikazuje osnovne elemente procesa, a slika 6-2-2

kako se oni obiĉno struktuiraju (sintaksno opisuju) i prikazuju u CASE alatima. Svaki proces

ima jedinstven identifikacioni broj, ime i opis, koji se pojavljuju u studiji sluĉaja. 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 priruĉnika za

nekompjuterizovane procese). Opisi procesa postaju detaljniji kako se saznaje više

informacija kroz fazu analize. Mnogi opisi procesa se pišu kao jednostavne tekstualne izjave o

tome šta se dešava. Složeniji procesi koriste više formalnih tehnika kao što su struktuirani

jezik, tabele odluka ili grafovi odluka, koje se pominju kasnije u tekstu.

n0 naziv procesa

kratak opis procesa

n0 naziv skladišta

podataka

Naziv

procesa

Naziv klase entiteta

Naziv toka podataka Naziv toka podataka

Naziv skladišta

podataka

Naziv klase

entiteta



Element dijagrama

toka podataka

komponente

DTP

Tipiĉne oznake u

CASE alatima simboli koje su uveli

Gane i Sarson


DeMarco,

Yourdan , i Coad

Proces

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

procesa

Description –opis koraka aktivnosti u

vezi podataka struktuirani jezik

Notes – napomena

Tok

podataka

Label (name): naziv_toka_podataka

Type (flow): tok –naziv forme prenošenih podataka: dokumenta,

formulara , obrasca, potvrde,

uplatnice, liste,..

Description –opis toka (lista atributa:

svojstvena obeležja)

Alias (another name) –popularan

naziv dokumenta ili formulara ,

naziv podšeme,...

Notes: napomena

Skladište

podataka

Label (name) –

naziv_skladišta_podataka

Type (store): vrsta skladišta podataka Primeri za Type:

Di :i–ta datoteka,

Kj : j–ta kartoteka,

Km : m–ta evidencija,

BPx : x–to Skladište Podataka,

MEy : y–ta matiĉna evidencija,..

Description –opis skladišta podataka

Alias (another name) – n0 uobiĉajeno

ime, popularan naziv, alternativni

naziv

Composition –logiĉka struktura

podataka Primeri za Composition:

naziv_skladišta(ključ skladišta,

lista_ostalih_atributa)

Notes: napomena

Eksterni

entitet

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

Slika 6-2-2 Elementi dijagrama toka podataka – sa najĉešće korišćenim i tipiĉnim oznakama

u CASE alatima

n0 naziv procesa

kratak opis procesa

n0 naziv skladišta

podataka

Naziv

procesa

Naziv klase entiteta

Naziv toka podataka Naziv toka podataka

Naziv skladišta

podataka

Naziv klase

entiteta



Sintaksa računarski podržanih DTP alata (CASE)

CASE alati –tipiĉna 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 obeležja)

Alias (another name): popularan naziv dokumenta ili formulara , naziv podšeme,...

Notes: napomena

CASE alati –tipiĉna 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) : navoĊenje broja ulaznih /izlaznih tokova (nijedan,

jedan ili više)

Notes: napomena

CASE alati –tipiĉna polja za skladište podataka:

Label (name): naziv_skladišta_podataka

Type (store): skladište podataka

Primeri za Type: datoteka, kartoteka, evidencija, Baza Podataka, matiĉna

evidencija

Description: opis skladišta podataka

Alias (another name): uobiĉajeno ime, popularan naziv,...

Composition: logiĉka struktura

Primeri zapisa za Composition:

key=ključ skladišta (niz kljuĉnih atribura),

attribute list =niz ili lista ostalih atributa (a1, a2,..., an )

Notes: napomena

CASE alati –tipiĉna 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 jednoznaĉno ukazuje na entitet)



Grafički simboli Dijagrama Toka Podataka –prilagođenje standarda

U praksi se pokazalo najpogodnije korišćenje unije navedena dva standarda, stim da

da su modifikovani neki simboli, kao što je prikazano na sledećoj slici (Slika 6-2-3).

Element DTP

–komponenta

dijagrama toka

podataka

simboli koje se koriste na FAM

-standard Gane i Sarson Za opis realnog

(postojećeg) sistema

Modifikovani skup simbola koje

su uveli DeMarco,

Yourdan , i Coad

Za opis informacionog

sistema (projektovanog

IS)

proces Broj –klasifikaciona

numeracija procesa (n0 )

Naziv procesa –ime klase

aktivnosti (gerundiv –

glagolska imenica)

tok podataka Naziv toka podataka –Ime

relacije(imenica)

Strelica pokazuje „ulazne“ i

„izlazne“ veze sa

procesom

skladište

podataka Naziv skladišta

–ime (imenica)

Vrsta skladišta (za postojeći

sistem)

–mnemonik m0

eksterni entitet Naziv eksternog entiteta

–ime klase eniteta (imenica)

Slika 6-2-3 Elementi dijagrama toka podataka prema FAM standardu –za prikaz DTP realnog

(postojećeg) sistema i (logiĉke statiĉke) strukture projektovanog sistema (IS)

m0 naziv skladišta

podataka

Naziv toka podataka

Naziv klase

entiteta

n0 –numeracija procesa

Naziv procesa

Naziv toka podataka

Naziv skladišta

podataka

Naziv klase

entiteta

n0 lokacija

Naziv procesa



Grafički simboli Dijagrama Toka Podataka –prilagođenje standarda

DTP simboli su objekti dijagrama toka podataka (DTP). Da bi ti objekti bili što

pogodniji za grafiĉku prezentaciju u okviru nastave na FAM (Fakultetu za Menadžment u

Novom Sadu) su definisane sledeće standardne forme DTP simbola (FAM standard ):

Element DTP

–komponenta dijagrama toka podataka

simboli koje se koriste na FAM

-standard FAM

Svaki proces ima:

Broj –klasifikaciona numeracija procesa (n0 )

Naziv procesa –ime klase aktivnosti (gerundiv –

glagolska imenica)

Opis procesa –aktivnosti se opisuju pseudokodom

Jedan ili više izlaznih tokova podataka

Uglavnom jedan ili više ulaznih tokova podataka

Svaki tok podataka ima:

Naziv toka podataka –Ime relacije(imenica)

Strelica pokazuje „ulazne“ i „izlazne“ veze sa procesom

Opis prenošenih podataka –logiĉka struktura

podataka koja se navodi u reĉniku–adresaru

podataka ili u legendi dijagrama

Svako skladište podataka relnog (postojećeg) sistema

ima:

Vrsta skladišta –mnemonik

Primeri za vrstu skladišta:

Di :i–ta datoteka,

Kj : j–ta kartoteka,

Km : m–ta evidencija,

BPx : x–ta Baza Podataka,

MEy : y–ta matiĉna evidencija,..

Naziv skladišta –ime (imenica)

Jedan ili više ulaza

izlaza može biti: nijedan, jedan ili više

Opis skladištenih podataka se navodi u Legendi (reĉniku

–adresaru podataka)

Svako skladište podataka projektovanog sistema ima:

Naziv skladišta –ime (imenica)

Jedan ili više ulaza

izlaza može biti: nijedan, jedan ili više

Opis skladištenih podataka se navodi u Legendi (reĉniku

–adresaru podataka)

Svaki eksterni entitet ima:

Naziv eksternog entiteta –ime klase eniteta (imenica)

Opis eksternog entiteta

Slika 6-2-4 Elementi dijagrama toka podataka prema FAM standardu –za prikaz DTP realnog

(postojećeg) sistema i (logiĉke statiĉke) strukture projektovanog sistema (IS)

n0 naziv skladišta

podataka

Naziv toka podataka

n0 –numeracija procesa

Naziv procesa

Naziv klase

entiteta

Naziv skladišta

podataka



Proces –aktivnosti transformacije podataka

Procesi koje posmatramo su podsistemi (odreĊena pokrivanja) nekog poslovnog

sistema. Pomoću modela procesa predstavljamo (opisujemo) statiĉku strukturu poslovnog

sistema. Modeli procesa opisuju poslovne procese, taĉnije aktivnosti koje ljudi obavljaju u

vezi podataka, i koriste sa da opišu 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 najĉešće korišćenih

metoda pri modelovanju sistema.

U DTP simbol procesa predstavlja homomrofni model aktivnosti kojima se

transformišu podaci ili se manipuliše sa podacima –skladištenje, distribuiranje,

formatizacija,... U sintaksi DTP, pravougaonik je grafiĉka forma procesa. Svaki taj

pravougaonik (oblik simbola procesa) ima jedinstven identifikacioni broj (klasifikaciono

struktuiran broj u gornjoj liniji pravouganika) i jednoznaĉan naziv u formi gerundiva

(glagolske imenice ili baš glagola –koji ukazuje na funkciju procesa „radi ovo –izvršava ove

aktivnosti“) upisanog u središni prostor pravougaonika. Gornje polje pravougaonika se koristi

za naziv lokacije izvršenja procesa ili radnog mesta (ljudi) odgovornih za taj proces.

Semantiĉki, procesi su „crne kutije“ –ne znamo šta je u njima sve dok se ne

dokomponuju, ili dok se ne predstave pseudokodom na najnižem nivou dekompozicije.

Procesima se ulazni tokovi podataka transformišu u izlazne tokovi podataka –ulaznim

podacima se manipuliše za proizvoĊenje izlaznih podataka. Izuzetno, u veoma retkim

sluĉajevima, može biti jedno bez drugog (samo ulaz ili izlaz), kada implicitno podrazumeva

(interno) skladište, interna pobuda (triger) ili terminalni entitet.

Svaki proces karakteriše:

Broj ili šifra ili klasifikaciona oznaku procesa (n0)

Naziv procesa –ime klase aktivnosti (gerundiv ili glagolska imenica)

Jedan ili više izlaznih tokova podataka;

Jedan ili više ulaznih tokova podataka

Opis procesa –aktivnosti koje se odvijaju sa podacima se opisuju pseudokodom, koji

je izvan DTP (u reĉniku adresaru podataka) ili je u priologu DTP;

Strukture i smisao simbola procesa u DTP – Forma pogodna za predstavljanje postojećih 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 sledećim slikama prikazane

su: opšta struktura grafiĉkog simbola procesa (slika 6-*-1), i jedan primer procesa u vezi

odreĊivanja kreditne sposobnosti nekog klijenta (slika 6-*-2)

slika 6-*-1: opšta struktura grafiĉkog simbola procesa simbol koji su uveli Gane i Sarson

n0 =1 mesto odvijanja

Naziv procesa (primer:

Provera kreditne sposobnosti)

Identifikator

procesa

Tok Ulaznih Podataka Tok Izlaznih Podataka



slika 6-*-2: jedan primer simbola procesa u vezi odreĊivanja kreditne sposobnosti nekog

klijenta koji, na osnovu sintakse koju su uveli Gane i Sarson –pogodan je za

prikaz postojećeg (realnog) sistema

Strukture i smisao simbola procesa u DTP –prema FAM Metodologiji DTP

slika 6-*-3: Strukture i smisao simbola procesa u DTP –prema FAM Metodologiji DTP

Aktivnosti koje se

odvijaju sa podacima

1.3 Prodajno

Provera kreditne

sposobnosti

Šifra ili klasifikaciona

oznaka procesa Gde/Ko ovo radi

sa podacima

Identifikaoni podaci

o potraţiocu kredita Podaci o kreditnoj

sposobnosti

n0 =klasifikaciona oznaka procesa

Naziv procesa

(primer: Provera kreditne sposobnosti)

Tok Ulaznih Podataka Tok Izlaznih Podataka



Tokovi podataka –prenos podataka

U suštini, tok podataka odražava jednosmernu i jedinstvenu relaciju izmeĊu dva

procesa. Sa druge strane, u opštem sluĉaju, izmeĊu dva procesa ima više relacija sa

odgovarajućim (razliĉitim) logiĉkim strukturama tokova podataka. Posmatrajmo jedan

jednostavan primer tokova podataka izmeĊu procesa uplatilac (procesa ili klijenta koji vrši

neku uplatu) i blagajna (procesa ili blagajnika koji prima uplate). U tom primeru se može

uoĉiti više vrsta tokova podataka, a radi pojednostavljenja uoĉićemo u jednom smeru tok

uplatnica (podaci koji prate aktivnosti uplaćivanja), i u drugom smeru potvrda (podaci koji

prate aktivnosti potvrĊivanja izvršenog uplaćivanja). Logiĉke strukture ta dva toka su veoma

sliĉne, i mogu se predstaviti sledećom pojednostavljenom logiĉkom strukturom toka

(atributima relacije uplaćivanje): naziv_uplatioca, vreme_uplate, iznos_uplate,

naziv_primaoca_uplate, mesto_uplate,... Logiĉke strukture tokova se se navode u

dokumentaciji koja je pridružena DTP, i nije neposredno u okviru DTP. Dokumentacija o

logiĉkim strukturama podataka je ili u formi legende ili skladišta podataka o podacima –za

koji se obiĉno koristi termin reĉnik-adresar podataka.

U skladu sa logiĉkom strukturom, tokovi podataka se mogu klsaifikovati kao:

Elementarni-prenosi se jedan podatak (na primer: matiĉni broj kartona pacijenta, JMBG,

broj indeksa studenta,...), ili

Složeni –logiĉki ureĊen niz podataka, koji je nosilac kolekcije od nekoliko informacija

(na primer, informacije o pacijentu, podaci o studentu, opi robe,..,.).

Prenošenje elementarnih podataka je najĉešće kod upita o uskladištenim podacima,

kada se prenosi samo kljuĉni podatak procesu za upravljanje skladištem podataka.

U opštem sluĉaju, i gotovo uvek, prenose se složeni podaci –nizovi logiĉki ureĊenih

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 logiĉke strukture toka.

Naziv toka se navodi kao imenica koja jasno ukazuje na klasu (vrstu) prenošenih

podataka. Primeri su uplatnica_školarine, podaci_o_pacijentu, faktura, i td.

Tokovi podataka su „povezne komponete“ koje drže sve procesa u okviru nekog

sistema (skladište

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 ništa. Isto tako, svaki proces obiĉno

mora da ima najmanje jednan ulazni tok podataka, jer je teško, u stvari

proizvede izlazna informacija bez ulaznih informacija. Ulazni tok ima i proces koji zapoĉinje

odvijanje u nekom trenutku ima ilazni tok od tajmera (procesa koji šalje podatke u vezi

vremena).

Primeri struktura formi toka podataka

Na sledećim slikama (slika 6-*-5, slika 6-*-6) su navedene dve osnovne strukture

formi toka podataka

slika 6-*-5: Forme pretstavljanja toka podataka u DTP

Naziv_klase_prenošenih_podataka



LEGENDA –opis logičke strukture toka Naziv toka: Prenošeni_podaci

Atributi toka: atribut1, atribut2,..., atributn

slika 6-*-6: Pretstavljanje logičke strukture toka podataka u formi legende

Karakteristike forme toka podataka –opšta pravila u vezi toka podataka

Da bi se lakše pravili DTP-ovi, korisno je imati u vidu sledeće karakteristike forme

toka podataka –koji se mogu shvatiti kao opšta pravila u vezi toka podataka:

Tokovi podataka opisuju prenos podataka (nosilaca informacija) prema ili od procesa

(ili entiteta).

Strelice moraju poĉinjati ili se završavati u procesima.

Neprihvatljiv je direktan tok podataka izmeĊu dva skladišta podataka ili direktno

pristupanje podacima iz eksternog entiteta u skladište podataka –to se mora uraditi

preko nekog procesa;

Strelice se imenuju –dodeljuje im se naziv (koji odgovara smislu prenošenih 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 „pošiljaoci“ ili „primaoci “ za izlazne ili ulazne podatke –entiteti su za tok

podataka: izvori ili ušća; osnivaĉi ili korisnici; poĉetne 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 skladišta podataka, oboje, moraju imati i ulaze i izlaze;

Ulazi u skladišta podataka jedino dolaze iz procesa.

Izlazi iz skladišta podataka jedino odlaze u procese.



Eksterni entitet

Eksterni ili spoljni entitet je uvek neki proces, koji se nalazi izvan posmatranog

sistema –u neposrednom okruženju posmatranog pokrivanja sistema, i u interakciji je sa

posmatranim pokrivanjem sistema. Karakteristiĉni primeri eksternih entiteta su osoba

(aktivnost koju izvršava neka osoba), organizacija (aktivnost koju izvršava neka organizacija),

ili neki drugi podsistem Za primer pokrivanja sistema „administracija lekarske ambulante“,

eksterni entiti mogu biti: pacijent, lekar, organ državne uprave, raĉunovodstveni sistem,i td.

Svaki eksterni entitet ima ime i opis. Kljuĉna 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.

Uobiĉajena greška je da se ljudi koji su deo sistema prikažu kao eksterni entiteti.

Ljudi koji izvršavaju procese su deo procesa i nisu van sistema (npr. službenici za unos

podataka, primaoci narudžbine,...). Osoba koja obavlja proces se ĉesto opisuje u opisu

procesa, ali nikad na samom DTP-u. MeĊutim, ljudi koji koriste informacije iz sistema da bi

izvršili druge procese ili odluĉuju koje informacije će ući u sistem pretstavljaju se kao

eksterni entiteti (na primer, menadžeri).

Karakteristike eksternog entiteta

Osnovne karakteristike eksternog entiteta, kao komponente DTP, su:

Eksterni eniteti su objekti iz okruženja sistema (klijenti, mašine, organizacije, firme,...).

Za entitete se koriste mnogi sinonimi, „spoljni izvori/primaoci“, dobavljaĉi, 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 pojedinaĉni

sluĉaj. Naziv Eksternog Entiteta se upisuje u oblik (krug ili elipsa). Kada se modeluje

složen sistem, svakom eksternom entitetu se dodeljuje jedinstveni broj ili mnemonik

(skraćenica 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

okruženju posmanog sistema

slika 6-*-5: Forme pretstavljanja „originala“ i „duplikata“ eksternog entiteta

Granica

sistema

#n

kopija

entiteta

#n

entitet

Naziv

entiteta

(imenica) Jedinstveni

identifikator

Granica

sistema

Eksterni enitet -simbol originala

Kopija simbola

Eksterni enitet

-simbol originala

Oznaka

kopije



Skladište Podataka

U opštem sluĉaju, skladište podataka je proces rukovanja sa podacima (uskladištenim

nosiocima informacija) i pridruženi mu skup uskladištenih podataka. Radi jednostavnosti, u

okviru DTP skladište podataka se predstavlja kao logiĉka struktura podataka –skup ureĊenih

qtributa. Fiziĉke strukture skladišta podataka, (kao što su datoteke ili baze podataka) se

praktiĉno odreĊuju kasnije prilikom modeliranja podataka (kreiranja fiziĉkog modela). Kao i

kod procesa, svako skladište podataka ima opisno ime (imenica), identifikacioni broj, kao i

opis koji se navodi u prilogu DTP –bez ukazivanja na naĉin realizacije skladišta. Logiĉke

strukture skladišta podataka su polazna taĉka za model podataka i glavna veza izmeĊu modela

procesa i modela podataka (modeliranje podataka je ).

Tokovi podataka koji dolaze iz skladišta podataka ukazuju na podatke (nosioce

informacija) koji se preuzimaju iz skladišta podataka, a tokovi podataka koji idu u skladište

podataka ukazuju na podatke (nosioce informacija) koji se dodaju u skladište podataka, ili da

se „zapisi“ u skladištu podataka menjaju.

U sluĉajevima u kojima isti proces i ĉuva podatke i preuzima podatke iz skladišta

podataka, postoji iskušenje da se nacrta jedant tok podataka sa strelicama na oba kraja.

MeĊutim, da bi tokovi bili jasniji, neophodno je nacrtati dva odvojena toka podataka –jer se

za proces ti podaci razlikuju. Poces ažuriranja podataka u skladištu obuhvata dve aktivnosti –

preuzimanje postojećeg zapisa (uĉitavanje „starih“ podataka), i predavanje promenjenih

zapisa (upisivanje „ažuriranih“ podataka). Te ktivnosti dva smera toka podataka sa

identiĉnom logiĉkom strukturom ali sa razliĉitim nazivima tokova podataka i njima

odgovarajućih atributa. Te razliĉitosti obiĉno su minimalne i realizuju se tako što se nazivima

tokova i njihovih atributa dodaje razliĉit 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 skladišta podataka moraju da imaju najmanje jedan ulazni tok „unošenja“

podataka –dodavanje novih zapisa, inaĉe skladište je prano –ne sadrže nikakve podatke.

Ponekad se u DTP postojećeg sistema naĊe nepotrebno „strano“ skladište, koje je napravljeno

i održavane od strane nekog drugog informacionog sistema -tada tom skladištu i nije mesto

„nepripadajužem“ DTP. Isto tako, skladišta podataka moraju da imaju najmanje jedan izlazni

tok za korišćenje podataka („iznošenih“, „uĉitanih“). Skladište nema smisla ako neće biti

korišćeno.



Forme predstavljanja skladišta podataka

U okviru Metodoloje FAM, uvedene su dve forme predstavljanja skladišta podataka:

1. Forma pogodna za predstavljanje postojećih sistema (RS),

2. Forma pogodna za predstavljanje projektovanih sistema –logiĉkih struktura

projektovanih IS.

Forma skladišta podataka pogodna za predstavljanje projektovanih si stema (IS)

Forma pogodna za predstavljanje postojećih sistema odgovara grafiĉkom simbolu

koji su uveli Gane i Sarson, koja je detaljnije opisana na sledećoj slici (slika 6-*-6)

slika 6-*-6: Forme pretstavljanja „postojećih“ skladišta podataka –za predstavljanje realnih

(već postojećih) sistema prema sintaksi Gane i Sarson

U okviru postojećih sistema, postje neke lokacije gde su podaci smešteni u trajna ili

privremena skladišta podataka. U DTP koji pretstavljaju postojeće sisteme, najĉešće se

razlikuju sledeći tipovi skladišta podataka:

D –raĉunarski podaci sa direktnim pristupom (DB, datoteke sa indeks sekvencijalnim i

random pristupom,..);

T– raĉunarski podaci sa sekvencijalnim pristupom (datoteke na magnetnim

trakama,..);

M – manuelne evidencije, e.g. arhivski ormari, kartoteke, knjige (sveske) evidencije, i

sluĉno.

P –trenutne ili prolazne datoteke podataka, odnosno privremene programske datoteke,

(tranzitna skladišta podataka)

O –trenutne manuelna skladišta podataka kao što su: poštansko sanduĉe, fahovi, e–

mail, ...

Ulazni_podaci

Tip

skladišta

podataka

Naziv skladišta

podataka

Jedinstveni

identifikator

D1 Skladište_podataka Izlazni_podaci



Forma skladišta podataka pogodna za predstavljanje projektovanih sistema (IS)

Forma pogodna za predstavljanje projektovanih sistema odgovara grafiĉkom simbolu

koji su uveli Yourdan, DeMarco, i Coad, koja je prikazana na sledećoj slici (slika 6-*-7).

Pri pretstavljajnju projektovanih sistema (IS) ne navodi se tip skladišta, već samo

simbol skladišta sa upisanim imenom –nazivom logiĉke strukture skladišta. Logiĉka struktura

skladišta se navodi ili u legendi ili u reĉniku–adresaru podataka. Na sledećoj slici je naveden

simbol skladišta i njemu odgovarajuća logiĉka struktura atributa.

slika 6-*-7: Forme skladišta podataka –za predstavljanje projektovanih sistema (IS)

Po pravilu, opis logiĉke strukture skladišta podataka se navodi u posebnom

dokumentu a ne neposredno u okviru DTP. Jedan od naĉina pojašnjavanja grafiĉke

prezentacije skladišta podataka je pomoću legende, kao što je prikazano na sledećoj slici

(slika 6-*-8), ili u reĉniku–adresaru podataka.

LEGENDA –opis logičke strukture skladišta podataka Oznaka skladišta: Naziv_skladišta

Kljuĉni atributi skladišta: ključni_atribut1, ključni_atribut2,..., ključni_atributk,

Nekljuĉni atributi skladišta: atribut1, atribut2,..., atributn,

slika 6-*-8: Forme logiĉke strukture skladišta podataka –za predstavljanje projektovanih

sistema (IS)

Forme pretstavljanja „duplikata“ skladišta podataka

Veoma ĉesto se u DTP ucrtavaju duplikati. Skladišta 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 sreĊeniji i ĉitljiviji. Na

sledećoj slici (slika 6-*-9)navedene su forme predstavljanja dupikata skladišta podataka

slika 6-*-9: Forme pretstavljanja „duplikata“ skladišta podataka

Naziv_skladišta

K1 naziv skladišta

Oznaka duplikata

(kopije) skladišta podataka

Naziv skladišta

(a) za realni sistema (postojeći RS) (b) za informacioni sistem za (projektovani IS)



Dijagram konteksta

Dijagram konteksta opisuje neposredno okruženje posmatranog sistema i to na

najvišem nivou uopštenosti. Sinonimi za dijagram konteksta su kontekstni ili kontekstualni

dijagram. Za dijagram konteksta sistema se uobiĉajeno koriste samo sledeća 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 okruženja posmatranog

sistema.

Posmatrano pokrivanje (posmatrani sistem ili organizacija) dijagramom konteksta se

predstavlja integralno kao „crna kutija“ koja implicitno sadrži sve relevantne interne procese.

Dijagram konteksta je najviši (najapstraktniji, najgeneralniji) nivo DTP. Namena dijagrama

konteksta je da opiše granice posmatranog pokrivanja –prikazujući relacije posmatranog

pokrivanja sa entitetima iz njegovog neposrednog okruženja, odražavajući strukture

interakcije posmatranog pokrivanja sa sistemima iz njegovog neposrednog okruženja

(eksternim entitetima).

slika 6-*-9: Dijagram konteksta –kada se posmatra postojeći sistem (okruženje realne

organizacije)

slika 6-*-10: Dijagram konteksta –kada se posmatra projektovani sistem (okruženje IS)

n0 lokacija sistema

Naziv

posmatranog

realnog

sistema

Tokovi

ulaznih

podataka

Entitet # x

Entitet # y

Entitet # z

tx

tz,1

ty,1

Tokovi

Izlaznih

Podataka

Entitet # a

Entitet # y

Entitet # z

ty,2

ta

tz,2

n0 –klasifikaciona numeracija

Naziv sistema –ime posmatranog

projektovanog sistema

(kao crna kutija)

Tokovi

ulaznih

podataka

Tokovi

Izlaznih

Podataka

Entitet # x

Entitet # y

Entitet # z

Entitet # a

Entitet # y

Entitet # b

tx

tz

ty,1

ty,2

ta

tb



Smisao dijagrama konteksta Bilo da se radi o analizi realnog sistema (postojećeg poslovnog procesa u kojem se

aktivnosti obavljaju i ruĉno i raĉunarski podržano –kompjuterizovano) ili se projektuje novi

informacioni sistem (raĉunarski podržan), dijagram konteksta je prvi DTP. Kao što ime

sugeriše, dijagram konteksta prikazuje neposredno okruženje –kontekst kojem pripada

posmatrani sistem ili poslovni proces. Svi modeli procesa imaju samo jedan dijagram

konteksta.

slika =.?. 1: dijagram konteksta postojećeg 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. Skladišta podataka se obiĉno ne nalaze na dijagramu konteksta, osim ako

su "vlasništvo" sistema ili procesa van posmatranog sistema, pa simbol skladišta (umesto

oznake ekternog entiteta koji manipuliše skladištem piodataka) ima znaĉaja ili olakšava

analizu realnog sistema. Na primer, postojeći informacioni podsistem, koji koristi fakultetska

biblioteka, koji zapisuje ko je pozajmio knjige, verovatno bi proverio fakultetsku bazu

podataka (aktivnosti studentske službe o studentima –matična evidencija) da bi se videlo da

li je student uopšte upisan na fakultet (slika =.?. 1). U ovom dijagramu konteksta, fakultetska

skladište podataka o studentima bi mogla da bude prikazana na dijagramu konteksta zato što

se nalazi van biblioteĉkog sistema, ali je koristi (slika =.?. 2). Mnoge analitiĉari ili projektanti

ne bi prikazali ovu bazu podataka o studentima

entitet pod nazivom "Informacioni sistem studentske službe" ili kao što je na gornjem

dijagramu (slika =.?. 1).kao podsistem sa nazivom –matična evidencija.

slika =.?. 2: varijacija dijagram konteksta postojećeg podsitema „upisivanje u biblioteku

FAM“

n0 prizemlje FAM

upisivanje u

biblioteku

FAM

JBMG

kandidata

kandidat

matična

evidencija

Odbijanje

članstva kandidat

JBMG

matična

evidencija

N0 indeksa

kandidata

Članska

karta

kandidat

n0 prizemlje FAM

upisivanje u

biblioteku

FAM

JBMG

kandidata

kandidat

Odbijanje

članstva kandidat

JBMG

N0 indeksa

Članska

karta

kandidat

K matična evidencija

studenata FAM



Uopšteno posmatrajući, u okviru (unutar) DTP, posmatrajući pojedinaĉno, svaki

proces se pretstavlja svojim dijagramom konteksta, stim da u tom sluĉaju postoje tri klase

eksternih entiteta koji komuniciraju sa posmatranim procesom: skladišta podataka (u stvari

specifimni procesi za rukovanje podacima), drugi procesi, i eksterni entiteti pokrivanja

(stvarni eksterni entiteti).

Ciljevi i postupci projektovanja DTP – analitički i

kompozicioni

Postoje dva cilja formiranja (projektovanja) DTP:

1. Analiza postojećeg sistema –sistema „jeste“ za koji ćemo koristiti termin realni sistem

ili skraćeno RS,

2. Projektovanje novog sisteme –„budućeg“ ili informacionog sitema za koji ćemo koristiti

skraćenu oznaku IS,

Za oba cilja, prvo se definišu dijagrami konteksta, i nakon toga se prelazi na

struktuiranje DTP.

Kada je cilj analiza postojećeg sistema, na osnovu pojedinaĉnih „primera sluĉaja“

(engleski use cases) iz studije sluĉaja (case study) formiraju se DTP-ovi, stim da se aktivnosti

preslikavaju u procese. Potom se iterativno vrši sinteza pojedinaĉnih DTP-ova i generalizacija

procesa (okrupnjavanje aktivnosti) u podsisteme višeg nivoa opštosti –sve dok se doĊe do

onoliko DTP-ova koliko ima eksternih entiteta u dijagramu konteksta RS (ovo je iskustveni

kriterijum).

Za oba sluĉaja, procesi projektovanja se razlikuju samo po smeru (obrnuti su

redosledi) aktivnosti. Obzirom da je najvažniji zadatak projektanta projektovanje novog

sisteme (IS), težište pažnje 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 najvišeg nivoa (sa procesima koji se odnose na eksterne entitete IS) –koji uopšteno

opisuju ciljni sistem i daju minimalne i potrebne odgovore na pitanja o nameni sistema.

Ovakav DTP je „integralan“ ali je preterano uopšten i bez detalja koji su neophodni za

projekat dovoljan za realizaciju. Ovaj inicijalni dijagram (najviši 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 složeni proces na najvišem nivou diagrama, predstavljen jedinstvenim

grafiĉkim blokom, treba dekomponovati („razbiti“) na više podprocesa –komponenata

polaznog procesa. Tako će viši nivo DTP sistema („roditeljski sistem“) biti dekomponovan na

niži nivo –koji pretstavljaju pripadajući podprocesi dekomponovanog sistema višeg nivoa

dijagrama DTP.

Minimalna struktura grafiĉkog simbola procesa (pravougaonog bloka) sadrži

jedinstven identifikacioni broj i naziv procesa. Ovaj jedinstven identifikacioni broj

posmatranog procesa je sa prefiksom „roditeljskog bloka“ koji pretstavlja proces na višem

nivou apstrakcije, odnosno prefiks mu je broj opštijeg procesa kome pripada posmatrani

proces. Radi jednostavnosti, zanemaruje se numeracija procesa navedenog u kontekstualnom

dijagramu. Dijagram procesa na najvišem nivou apstrakcije mi ćemo oznaĉavati kao prvi

nivo. MeĊutim, u literaturi, dijagram procesa na najvišem nivou apstrakcije se ĉesto oznaĉava

kao nulti nivo DTP jer se ne navode prefiksi za brojeve procesa, već se procesi numerišu



prirodnim brojevima (0, 1, 3, i tako dalje). Prema tome, ako su na najvišem nivou DTP ĉetiri

procesa, oni se predstavljaju na sledeći naĉin prikazan na sledećoj slici (slika =.?. 3).

slika =.?. 3 : DTP najvišeg nivoa (prvog nivoa)

slika =.?. 3 : Procesi u DTP prvog nivoa (niži nivo procesa za „roditeljski proces“

Naziv_procesa_3

Svaki grafiĉki blok Procesa na drugom nivou dekompozicije može se dekomponovati

na treći nivo, a potom treći 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

može realizvati jednim programskim blokom sa desetak operacija nad podacima.

Sve što je sistem složeniji to je potrebna njegova dekompozicija do sve nižeg 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 obezbeĊuje se sve više detalja

o svakom podsistemu celog poslovnog procesa (delu sistema). Dakle, jedan vrlo važan princip

u procesu projektovanja DTP-a (prikazivanja dijagrama toka podataka) je dekompozicija

DTP nultog nivoa (prvi nivo numerisanja procesa)

1 Naziv_procesa_1

2 Naziv_procesa_2

4 Naziv_procesa_4

3 Naziv_procesa_3

Procesi u DTP prvog nivoa (procesi niţeg nivoa za „roditeljski proces“: Naziv_procesa_3

3.1 procesa_a

3.2 procesa_b

3.4 procesa_d

3.3 procesa_c

3.5 procesa_d

DTP nultog nivoa (prvi nivo numerisanja procesa)

1 Naziv_procesa_1

2 Naziv_procesa_2

4 Naziv_procesa_4

3 Naziv_procesa_3



poslovnih procesa u niz DTP-ova, gde svaka komponenta tog niza predstavlja detalja na

nižem nivou apstraktnosti (niži nivo DTP). Slika 6-3 uopšteno pokazuje kako se jedan

poslovni proces dekomponuje u nekoliko nivoa DTP-a.

Slika 6-3 Veze meĊu nivoima dijagrama toka podataka –DTP realnog sistema

2.2.1 poslovi K

proces K

2.2.2 poslovi L

proces L

2.2.3 poslovi M

proces M

tok h1

tok h2

tok h

tok q

tok r

tok s

tok g1

tok g2

tok g

Nivo 3. DTP za proces 2.2

K1 skladište podataka

N

tok nu

tok ni

entitet A

2 sektor T

proces T

1 sektor U

proces U

3 sektor V

proces V

K1 skladište podataka

N

entitet B

tok nu

tok ni

tok y tok b

tok zi

tok zu

tok a

tok x

Nivo 1. DTP tok w

Nivo 2. DTP za proces 2

2.1 služba U

proces D

D1 skladište podataka

N

tok b

tok nu

tok ni

tok h

tok g 2.2 služba E

proces E

2.3 služba V

proces F

tok j

tok a

tok y



Tok izrade DTP

Dijagram konteksta

Prvi DTP u projektima svih poslovnih procesa, bilo da se radi o sistemu u kojem se

procesi obavljaju ruĉno ili kompjuterizovano, je dijagram konteksta (videti sliku 6-3). Kao što

ime sugeriše, dijagram konteksta prikazuje neposredno okruženje –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.

Skladišta podataka se obiĉno ne nalaze na dijagramu konteksta. Neki projektanti IS u

dijagramu konteksta kao eksterni entitet navode simbol skladišta –da bi eksplicitnije ukazali

na eksterni entitet koji karakteriše skladište podataka koje je "vlasništvo" 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 (matiĉnu

evidenciju) o studentima da bi video da li je student uopšte upisan na fakultet. U ovom

dijagramu konteksta, fakultetsko skladište podataka o studentima bi trebalo da bude prikazana

na dijagramu konteksta zato što se nalazi van biblioteĉkog sistema, ali koristi je. Mnoge

analitiĉari ili projektanti ne bi prikazale ovo kao skladište eksterni entitet

pod nazivom "Informacioni sistem biblioteke".

Dijagram najvišeg nivoa –najviši nivo DTP (prvi nivo

dijagrama, nivo 1 DTP)

Nakon uraĊenog 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), skladišta podataka, eksterni entiteti i tokovi podataka meĊu njima. Svrha 0. nivoa

DTP-a je da prikaže sve glavne procese sa visokih nivoa sistema i kako su oni meĊusobno

povezani. Svi modeli procesa imaju jedan i samo jedan DTP 0.nivoa.

Drugi kljuĉni princip u stvaranju nizova DTP-a je balansiranje. Balansiranje znaĉi

obezbeĊivanje da se sve informacije predstavljene na DTP-u na jednom nivou predstave taĉno

i em nivou DTP-a. To ne znaĉi da su podaci identiĉni, nego da su prikazani na

odgovaraj . Postoji suptilna razlika u znaĉenju izmeĊu ova dva principa koja

uskoro postati oĉigledna, 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 sluĉaju, vidimo da su

eksterni entiteti (A i B) identiĉni 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 skladište 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 složenosti sistema da ĉitaocu bilo lakše da razume. Tek kada ĉitalac

razume dijagram konteksta analitiĉar "otvara" proces 0 da pokaže njegove interne operacije



dekomponovanjem diagrama konteksta u prvi nivo DTP-a, koji pokazuje više detalja u vezi

procesa i tokova podataka unutar sistema.

Dijagrami 1. Nivoa

Na isti naĉin na koji dijagram konteksta namerno skriva neke od složenosti 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 može se dekomponovati u precizniji nivo DTP-a,

koji se zove dijagram drugog nivoa, ili na nivou 2 DTP-a, koji pokazuje u više 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

prikažemo 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

identiĉni, oni su samo razliĉiti naĉini gledanja na istu stvar. Kada se roditelj proces

dekomponije u procese decu, njegova deca moraju u potpunosti da obavljaju sve njegove

funkcije na isti naĉin na koji iseĉena parĉad pite zajedno ĉine celu pitu. Iako parĉad ne moraju

biti iste veliĉine, skup kriški je identiĉan celoj piti, ništa se ne gubi pri seĉenju pite.

Još jednom, veoma je važno da se obezbedi da su izbalansirani nivo 1 i nivo 2 DTP-a. Prvi

nivo DTP-a pokazuje da proces 2 pristupa skladištu podataka D1, ima jednog tok podataka

unosa (B) i ima dva izlazna toka podataka (A i Y). Provera prvog DTP-a pokazuje isto

skladište 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, meĊutim, da

nivo 2 DTP-a ne pokazuje odakle ovi tokovi podataka dolaze ili gde idu. Da biste pronašli

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 taĉno koji proces u

okviru procesa 3 ga i koristi (na primer, proces 3.1, 3.2). Da bi utvrditi taĉan izvor, morali bi

da ispitamo DTP 2. nivoa procesa 3.

Ovaj primer pokazuje jednu manu dekompozicije DTP-a na više stranica. Da biste

pronašli taĉan izvor i odredište tokova podataka, ĉesto morate da pratite tok podataka kroz

nekoliko DTP-ova na razliĉitim stranicama. Nekoliko alternativa ovom pristupu

dekomponovanja DTP-a je predloženo, ali nijedna se ne koristi tako šesto kao "tradicionalni"

pristup. Naj je da se prikažu i izvori i odredišta tokova podataka ka i od eksternih

entiteta (kao i skladišta podataka) na nižem nivou DTP-a. Kako ide u

ili iz skladišta podataka i eksternih entiteta, umesto sa druge stranice DTP-a, ovo može mnogo

da olakša ĉitanje DTP-ova sa više strana. Mi verujemo da je ovo bolji pristup, tako da na

predavanjima prikazujemo spoljne entitete na svim DTP-ovima, ukljuĉuj dijagram 2.

nivoa i ispod.



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 skladištem

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,

takoĊe, 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 teško setiti se koji nivo DTP-a je koji. Može vam zapamtite da

je broj nivoa jednak broju taĉki (.) uvećanom 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 trećeg nivoa (2.1.3 DTP 3. nivoa), i tako dalje.

Račve i spojevi DTP-a (Splits and Joins)

Tokovi podataka H1 i H2 na DTP-u nivoa 2, na slici 6-3 ilustruju raĉvanje (engleski:

split) toka podataka H, u kojem je ovaj tok razdvojen na svoje sastavne delove. Za složene

(višestruke) relacije izmeĊu procesa, neki tokovi podataka se zapravo sastoje od mnogo

razliĉitih elemenata podataka, kao recimo ime pacijenta, adresa pacijenta, vreme zakazanog

pregleda i lekar. Raĉva u ovoj slici može da se koristi da prikaže 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 raĉvama budu meĊusobno iskljuĉivi, niti da ukljuĉuju sve iz toka

podataka roditelja. Tako, na primer, ime pacijenta i adresa pacijenta mogu otići u jedan

proces, a ime pacijenta može otići u drugi. Ili, kao na slici 6-1 iste informacije se mogu

koristiti u dva ili više procesa, a raĉva je najjednostavniji naĉin da se skrene tok podataka.

Razlog za raĉvanje je taj što nam u višem nivou DTP-a nije bilo važno koji se delovi

toka podataka gde koriste. Bilo je dovoljno j : "H" (ili "Informacije o

pacijentu") na višem nivou. Kako prelazimo na niže nivoe, meĊutim, moramo biti precizniji o

tokovima podataka na isti naĉin na koji smo postali precizniji o procesima.

Tok podataka G na istom DTP-u ilustruje spoj (engleski: join). U ovom sluĉaju,

odvojeni delovi toka podataka G (G1 i G2) udružuju se i formiraju „zajedniĉki“ tok podataka.

U našem primeru lekarske ordinacije, G1 može biti informacije o pacijentu (ime, adresa),a G2

možda informacije o zakazanom pregledu (npr. vreme zakazanog pregleda, lekar). Ove

tokove podataka proizvode razliĉiti procesi na najnižem nivou DTP-a, ali se prikazuju kao

jedan tok podataka "Informacije o zakazanom pregledu" na višem nivou DTP-a.

Alternativni tokovi podataka

Pretpostavimo da proces stvara dva razliĉita toka podataka pod razliĉitim 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 ništa ne pokazuje

da su tokovi podataka meĊusobno iskljuĉivi. 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 meĊusobno iskljuĉivi.



Opis procesa

Svrha opisa procesa je da objasni ono što proces ĉini i pruži dodatne informacije koje

DTP ne pruža. Dok se krećemo 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

sluĉajeva, proces je jednostavan dovoljno da definisanje zahteva, studija sluĉaja i DTP sa

jednostavnim tekstualnim opisom daju dovoljno detalja za fazu dizajna. Ponekad, meĊutim,

proces je dovoljno složen da je bolje napraviti detaljniji opis logike koja se odvija unutar

samog procesa. Tri najĉešće tehnike koje se koristi za opisivanje složenije logike procesa su:

struktuiran jezik, grafovi odluka, tabele odluka. Za veoma složene procese mogu da se koriste

kombinacije struktuiranog jezika i bilo grafova odluka ili tabela odluka.

Struktuiran jezik (Pseudokod)

Tumačenje pojma i termina pseudokod

Pseudokoda (naziv je izvededen od reĉi pseudo= i code= ) je zgusnuti i neformalni

visoko-nivoski opis algoritma procesa transformacije podataka (računarskog programa)

koji konvencionalno koristi strukturu nekih programskih jezika, ali u kome su izostavljeni

detaljlji koji nisu od znaĉaja za razumevanje algoritma, kao što su podprogrami (subrutine),

deklarisanje varijabli, upravljanje memoriskim prostorom i sistemski specifiĉni kodovi.

Programski jezik je proširen sa opisima detalja pomoću govornog jezika, gde je to pogodno,

ili sa matematiĉkim izrazima (formalno matematiĉkim notacijama –formulama). Pseudokod

forma programa se može lako konvertovati u realne programske naredbe.

Pseudokod se ne može ni kompajlovati ni izvesti jer ne postoje realna pravila za

formate i sintaksu. To je prosto jedan korak –ali važan korak– u pravljenju (programiranju,

kodiranju) finalnog koda programa. Dobiti od pseudokoda su što se njime omogućava da se

projektanti skoncentrišu na algoritme ali da se ne brinu o sintaksnim detaljima specifiĉnog

programskog jezika (o kome brinu programeri –koderi). U suštini, projektant IS može pisati

pseudokod bez poznavanja bilo kog programskog jezika.

Namena pseudokoda je da ga ĉovek (ljudi) mogu lakše ĉitati nego konvencionalne

programske jezike (kao što su Pascal, BASIC. C, Java, Lisp, ALGOL), i da bude kompaktan

(zgusnutiji) i programski nezavisan opis kljuĉnih principa algoritma. Ne postoji zvaniĉan

standard za sintaksu pseudokoda, tako program u pseudokodu ne može direktno da se izvede

na raĉunarau.

Blokovi koda, na primer kod koji je unutar neke petlje, može se opisati jednom

reĉenicom govornog jezika.

Sintaksne forme pseudokoda

Blok-dijagram (flow chart) se može smatrati grafiĉkom alternativom za pseudokod.

Pseudokod je sliĉan, ali ne bi trebalo da se pobrkaju, sa skeleton programima (kosturom

struktuiranim programima) koji se mogu kompajlovati (prevesti) bez problema i bez greške.

Kako pseudokod zavisi od „pisca“ to se on piše razliĉitim stilovima, u dijapazonu od

imitacija realnog programskog jezika (prevedene naredbe na govorni jezik) kao jedan

ekstrem, do opisa koji su sliĉni literarnoj prozi (priĉanje priĉa o tome –ŠTA ĆE RADITI

PROGRAM) kao suprotan ekstrem.



Struktuiran jezik je samo formalan naĉin pisanja uputstva koji opisuju korake

procesa. Struktuiran jezik jako potseća na programski jezik, jer on predstavlja prvi korak ka

programu (ili protokolu, ako se radi o ruĉnom radu), koj

obavlja proces. Struktuiran jezik koristi kratke reĉenice 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.

Izvršne naredbe su jednostavne naredbe koje izvršavaju neku radnju. „ AKO“ (IF) naredbe

kontrolišu radnje koje se izvode pod razliĉitim uslovima, dok je „DOK“ (FOR ili WHILE)

naredba cikliĉnog obavljanja nekih radnji sve dok se ne postigne zadati uslov ili odreĊeno

stanje. Konaĉno, „USD“ (U Sluĉaju Da; engleski: CASE) naredba je napredni oblik „AKO“

naredbe koja se koristi ako ima nekoliko meĊusobno iskljuĉivih grana.

Na primer, studija sluĉaja 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 dešava u

procesu "Proveravanje statusa pacijenta" ako pacijent jeste novi pacijent ili ako pacij

. DTP po sebi ne objašnjava ovo. Stoga, opis procesa u procesu 1.1 DTP-a

mora da obezbedi potrebne dodatne informacije. Slika 6-5 pokazuje kako bi to bilo izraženo u

struktuisanom jeziku. Ĉeste naredbe Primer

Akcione naredbe –izvršne aktivnosti Profit = zarada – troškovi

Generiši stanje skladišta

Dodaj podatke o proizvodu u skladište

AKO naredba (IF) –za odreĊeni uslov (AKO uslov)

definisanje radnji koje se obavljaju kada je zadovoljen

uslov (ONDA uraditi) i kada nije zadovoljen ulov

(INAČE uraditi)

AKO kupac nije u skladištu kupaca

ONDA dodaj podatke o kupcu u skladište

INAĈE ubaci podatke o kupovini kupca u skladište

podataka o svim kupovinama

DOK naredba (FOR ili WHILE) –definisanje

ponavljajućih radnji sa podacima sve dok je

zadovoljen neki uslov

DOK ima kupaca u bazi RADI

Generiši novu liniju u izveštaju o kupcima

Upisi ukupni profit od kupovine kupca

USD naredba (CASE) –definisanje alternativa

(U Sluĉaju Da)

USD –U Sluĉaju Da prihod < 10000, porez = 10%

prihod < 20000, porez = 20%



INAĈE porez = 38%

Slika 6-4 Struktuiran jezik

1.1 Proveravanje statusa pacijenta

/* Opis procesa –svrha ovog procesa je da možemo da zakažemo pregled pacijenta samo ako

status pacijenta to dozvoljava.*/

AKO pacijent = nov_pacijent

ONDA Izvrši proces dodavanje_novog_pacijenta

INAĈE

AKO pacijent ima neplaćene raĉune, if uslov (dugovanje > 0);

ONDA Pošalji pacijenta na šalter za uplatu

Slika 6-5 Primer struktuiranog jezika



Pokazaćemo jedan jednostavan primer koji ukazuje razlike izmeĊu pseudokoda i

stvarnog programskog koda (PHP) prikazan je na sledećoj 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 izvrši transakciju na osnovu njenog broja i naloga

(n0_nalog)

inače prikaţi poruku o nastaloj grešci

kraj Ispitivanja

Slika 6-5-1: Primer razlike izmeĊu pseudokoda i stvarnog programskog koda (php)

Korišćenje pseudokoda

U struĉnim knjigama i nauĉnim publikacijama koje se odnose na raĉunarske i

numeriĉke nauke (computer science and numerical science), termin pseudokod obiĉno se

koristi za opise algoritama, takav da ga mogu razumeti svi programeri, ĉak i ako svi ne

poznaju iste programske jezike. U knjigama, obiĉno mu se pridružuje uvodno objašnjenje o

specifiĉnim konvencijama koje se koriste (važe) za psudolod. Nivo detaljnosti nekog od tih

jezika može u nekim sluĉajevima može biti sa pristupm koji odgovara formalizovanim

jezicima opšte namene (formalized general-purpose languages). Na primer Knuth–ova prva

knjiga „The Art of Computer Programming“ opisuje algoritme u polu–specifikacionom

asemblerskom jeziku za nepostojeće mikroprocesore (fully –specified assembly language for

non –existent microprocessor). Programer koji treba da napravi (isprogramira) neki specifiĉan

algoritam, naroĉito ako je neiskusan, obiĉno će zapoĉeti sa pseudokod opisom, a potom prosto

„prevesti“ taj opis ciljni programski jezik i modifikovati ga da bi bio usklaĊen sa ostatkom

programa.

Programeri takoĊe mogu zapoĉeti sa pseudokod skicom koda na papiru pre nego što

poĉnu pisanje u stvarnom programskom jeziku, što odgovara pristup top–down struktuiranja.

Grafovi odluka (Stabla odluke)

Grafovi odluka su grafiĉki naĉin opisa logike koja se nalazi u „AKO“ naredbi

struktuiranog jezika. Grafovi odluka su korisni samo kada postoji veliki broj ugneždenih

„AKO“ naredbi, tj. ako imamo „AKO“ naredbu, koja je unutar druge „AKO“ naredbe, koja je

unutar treće „AKO“ naredbe. Slika 6-6 pokazuje jednostavan graf odluka za prvi korak u

procesu zakazivanja pregleda. Svaki krug je taĉka odluke, koja predstavlja pitanje („AKO“

naredbu). Taĉka odluke ima skup ishoda koj se granaju u razliĉitim pravcima koji vode na

druge taĉke odluke. Na slici 6-6, imamo seriju da/ne pitanja gde svako ima po dve grane, ali

mi možemo izgraditi i grafove odluke koji imaju više od dve grane u svakom trenutku odluke

komplikovanijih pitanja (npr., razliĉite iznose prihoda koji dovode do razliĉitih

poreskih stopa) i u ovom sluĉaju taĉke odluke su sliĉne „CASE“ naredbi u sluĉaju

struktuiranog jezika.

Grafovi odluka su vizuelni. Nekim ljudima je lakše da koriste grafove odluke, dok

ostali radije koriste naredbe struktuiranog jezika a ljudi lakše

razume grafove odluka nego struktuiran jezik, ako imamo tri do ĉetiri taĉke odluke. Ako

imamo više od ĉetiri taĉke odluke, crtanje grafova odluka na jednoj strani može da postane

teško, tako da za složenije logike, mi koristimo tabele odluke.



SLIKA 6-6 Graf odluka za proveru statusa pacijenta

Tabele odluka

Tabele odluka se koriste za veoma složene procese koji imaju više pravila odluka.

Slika 6-7a pokazuje potpunu tabelu odluĉivanja za isti proces. Gornji levi deo tabele odluka

pokazuje uslove koji treba da budu testirani (nov pacijent i raĉuni), a donji levi

pokazuje radnju koja treba da se obavi (izvrši proces 2, zakaži 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 izvršavaju za svako pravilo ( "X", znaĉi da se akcija izvršava, 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 vrši (obavlja

proces 2).

Ako pažljivo pogledate primetićete da se pravilo 3 nikad ne koristi, iz prostog

razloga što ne možemo imati neplaćene raĉune pacijenta kojeg nikad nismo videli. Drugi

uslov nije potreban da bi se odluĉilo A1. Slika 6-7b pokazuje uprošćenu

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 više odvojenih uslova

koji treba da budu razmotreni.

Uslovi Pravilo 1 Pravilo 2 Pravilo 3 Pravilo 4

C1: Novi pacijent da ne da ne

C2: Neplaćeni raĉuni ne ne da da

Akcije (naredbe)

A1: Izvrši proces 2

–dodaj novog pacijenta

x

A2: Zakaži pregled x

A3: Pošalji pacijenta na

šalter za uplatu

x

SLIKA 6-7-a : Kompletna tabela odluka; (a)

Raspored pregleda

–određivanje termina

pregleda pacijenta

Novi pacijent ?

da

da

Upućivanje pacijenta

u računovodstvo

–da pacijent reguliše

plaćanje

Izvršenje procesa 2

–dodavanje novog pacijenta

Pacijent ima dugovanja ?

–ako pacijent nije platio neki

prethodni račun?

ne

ne



Uslovi Pravilo 1 Pravilo 2 Pravilo 3

C1: Novi pacijent da ne ne

C2: Neplaćeni raĉuni ne ne

Akcije (naredbe) A1: Izvrši proces 2

–dodaj novog pacijenta

x

A2: Zakaži pregled x

A3: Pošalji pacijenta na

šalter za uplatu

x

SLIKA 6-7-b : Redukovana tabela odluka (b)

Pravljenje dijagrama konteksta –konkretne izrada (aktivnosti projektovanja)

Dijagram konteksta definiše naĉin na koji je poslovni proces ili raĉunarski 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 skladištima podataka u spoljnom sistemu. Takva spoljna skladišta

podataka mogu biti navedena kao samo skladište podataka što i jeste, ili jednostavno kao

eksterni entitet koji nosi naziv sistema koji rukuje tim skladištem podataka. Nijedno od

skladišta podataka unutar procesa posmatranog sistema koje stvara proces ili sam sistem nije

ukljuĉeno u dijagramu konteksta,

.

Pravljenje dijagrama toka podataka –konkretne izrada (aktivnosti projektovanja)

Dijagrami toka podataka poĉinju sa informacijama prikupljenim iz studija sluĉaja i

definicije zahteva. Iako se studije sluĉaja prave saradnjom korisnika i projektanata, DTP-ove

uglavnom prave projektantski (analitiĉarski) timovi, pa ih tek onda pregledaju korisnici.

Uopšteno govoreći, set DTP-ova koji ĉine model procesa jednostavno integrišu individualne

studije sluĉaja (i dodaju procese definisane u zahtevima, koji se nisu pojavili u studijama

sluĉaja). Projektanti uzimaju studije sluĉaja i zapisuju ih kao DTP-ove. Zato što DTP ima

pravila i simbole koji moraju da se ispoštuju, projektanti nekad moraju da prilagode studije

sluĉaja, kako bi mogli da ih predstave u DTP-u. Najĉešće promene su u nazivima sluĉajeva

koji postaju procesi i ulaza i izlaza tokova podataka. Još jedna ĉesta promena je

objedinjavanje manjih ulaza i izlaza iz studija sluĉaja u veće 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

crteže bez kontrole, kao powerpoint, tako da ne proveravaju sintaksu i znaĉenje DTP

elemenata. Drugi alati kao što je BPWin „razumeju“ DTP i mogu da vrše nekoliko provera

sintakse, kako bi se lakše uoĉilo da li je DTP, bar donekle, taĉan. Potpun CASE alat kao što je

VAW (Visible Analyst Workbench), pruža mnoge mogućnosti za kontrolisano modelovanje

procesa. CASE alati teže da budu vrlo kompleksni, kao takvi su od velike pomoći, ali ĉesto

koštaju više nego što doprinose projektovanju.



Pravljenje modela procesa koji ima više nivoa DTP-a obiĉno 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 sluĉaju, da bolje objasni kako oni rade.

U nekim sluĉajevima, ovi DTP-ovi prvog nivoa su dalje raslojeni na DTP-ove drugog, trećeg,

ĉetvrtog nivoa DTP-a, i tako dalje. Peto, tim potvrĊuje skup DTP-ova da bi se uverili da su

potpuni i taĉni.

Slika 6-8: Upisivanje procesa u DTP pomoću 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

uporeĊenje ove dve slike. Trebalo bi uoĉiti da dijagrami imaju isti eksterni entitet: pacijent.

Svi ulazi i izlazi na nivou 1 DTP-a su takoĊe prisutni u dijagramu konteksta, iako je "ime

pacijenta" u prvom nivou DTP-a navedeno kao viši nivo toka podataka "informacije o

pacijentu," koji bi prikljuĉio ime pacijenta, kao i mnoštvo drugih informacija kao što su

zdravstveno osiguranje i ostale informacije. Nekoliko drugih eksternih entiteta je prikazano

(npr. lekar, osiguravajuća kompanija), kao i drugi tokovi podataka (na primer, raĉun,

informacij ), jer ih ima i u drugim studijama sluĉaja.



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

sluĉaja se pretvara u jedan DTP fragment.

Slika 6-9 Dijagram konteksta za informacioni sistem o pacijentima u lekarskoj ordinaciji

Legenda –nazivi i znaĉenje tokova podataka 1. ID pacijenta –podaci o pacijentu

2. Promena ID –promenjeni podaci o pacijentu

3. Mogućnost –lista termina mogućih zakazivanja pregleda

4. ţelja –željeni termin pregleda

5. poništenje –poništavanje zakazanog pregleda, otkaz pregleda

6. račun –faktura ili formular uplatnice za pacijenta

7. uplata–zvaniĉna uplatnica od pacijenta, potvrda pacijentovog izvršenog plaćanja

8. faktura –faktura za zdravstveno (socijalno) osiguranje

9. isplata –raĉun od zdravstvenog osiguranja –potvrda uplate zdravstvenog osiguranja

10. raspored –izveštaj o zakazivanjima

11. kartoni –izveštaji o pacijentima

12. salda –finansiski izveštaji

pacijent

Zdravstveno

osiguranje

lekar

ID pacijenta

račun

promena ID

mogućnost

poništenje

ţelja

uplata

faktura isplata

kartoni

raspored

salda

0 ambulanta

informacioni

sistem o

pacijentima



nacrtati DTP fragment za svaku studiju sluĉaja

podatke date na vrhu sluĉaja: ime, ID broj, i glavne ulaze i izlaze. Informacije o glavnim

koracima koji ĉine svaki sluĉaj se zanemaruju u ovom trenutku e).

Slika 6-10 prikazuje studiju sluĉaja i DTP fragment koji je nastao iz nje.

Opet, neke suptilne ali važne promene se ĉesto koriste pri konvertovanju studije sluĉaja u

DTP. Dve naj je imena procesa i dodavanje tokova podataka. Ne

postoje formalna pravila za imenovanje studija sluĉaja, ali postoje formalna pravila za

imenovanje procesa u DTP-u. Sva imena procesa moraju poĉeti sa glagolom (videti sliku 6-

2). Nisu sva imena naših sluĉajeva struktuirana na taj naĉin, pa ih je ponekad potrebno

promeniti. TakoĊe je važno imati konzistentan naĉin kod imenovanja procesa. Na primer,

DTP na slici 6-10 je napisan sa stanovišta ordinacije lekara, a ne pacijenta. Sva imena procesa

i opisi su pisani kao aktivnosti koje zaposleni u ordinaciji obavljaju. To je ustaljen naĉin

dizajniranja procesa, tako da to ponekad zahteva neke dodatne promene u imenu.

Druga ĉesta promena je dodavanje tokova podataka. Studije sluĉajeva se pišu da bi se opisala

interakcija sistema sa korisnikom. Obiĉno ne opisuju kako sistem dobija podatke, tako da

studija sluĉaja ĉesto izostavlja podatke proĉitane iz skladišta podataka. Kada pravite DTP

fragmente, važno je da se uverite da su sve informacije koje korisnik dobija iz skladišta

podataka. Najlakši naĉin da ovo uradite je da prvo kreirate DTP avnih

ulaza i izlaza na vrhu studije sluĉaja, a zatim se uverite da svi izlazi imaju dovoljno ulaza da

ih naprave.

Ne postoje formalna pravila koja pokrivaju raspored procesa, tokova podataka,

skladišta podataka, i eksternih entiteta u DTP-u. Njih možete postaviti gde god hoćete na

stranici; ali, pošto zapadne kulture ĉitaju od gore ka dole i s’ leva na desno, analitiĉari 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. Skladišta podataka su uglavnom

ispod procesa.

Slika 6-10 jedan deo DTP za lekarsku ordinaciju –kontekst procesa na

osnovu II bloka use case

(b) Jedan deo DTP

pacijent

podaci o pacijentu

K1 KARTOTEKA

Podaci o

pacijentima

ID i podaci o

pacijentu

informacije

o pacijentu

2. kartoteka

Aţuriranje podataka o

pacijentima

Informacija

o promeneni

podataka o

pacijentu



Slika 6-10 delimičan DTP za lekarsku ordinaciju –odnosi se na deo primera sluĉaja

Na sledećoj slici (Slika 6-11 pokazan je jedan od naĉina na koji moguće nacrtati DTP

fragment. Postoji mnogo pravilnih naĉina da se nacrta ovaj dijagram.

blok 1.

Naziv studije: ambulanta broj sluĉaja: 2

Kratak opis sluĉaja: ažuriranje podataka o pacijentu

Pobuda: dolazi novi pacijent ili se menjaju podaci o starom pacijentu

Tip pobude: spoljna ili unutrašnja ili vremenska

blok 2.

Vaţni ulazi Vaţni izlazi Opis ulaza Izvor podataka Opis izlaza odredište podataka

Informacije podaci

o pacijentu pacijent o pacijentu kartoteka ------------------- ------------------------ -------------------- --------------------

Informacija o promeneni

podataka o pacijentu pacijent ------------------- ------------------------ -------------------- --------------------

ID i podaci o pacijentu kartoteka ------------------- ------------------------ -------------------- --------------------

------------------- ------------------------ -------------------- --------------------

blok 3.

Glavni koraci Informacije

(a) Primer slučaja (use case)

(b) Jedan deo DTP

pacijent

podaci o pacijentu K1 KARTOTEKA

Podaci o

pacijentima

ID i podaci o

pacijentu

informacije

o pacijentu

2. kartoteka

Aţuriranje podataka o

pacijentima

Informacija

o promeneni

podataka o

pacijentu



Slika 6-11 DTP fragment za lekarsku ordinaciju –prikazuje jedan naĉin (kontekstualni) na

koji je moguće nacrtati DTP fragment.

Legenda –nazivi i znaĉenje tokova i skladišta podataka (za sliku 6-11) Ime pacijenta –ime i prezime pacijenta, broj zdravstvenog kartona ili knjiţice

Promena ili poništenje –datumi otkazanog i promenjenog termina pregleda

Mogućnost –lista slobodnih termina za pregled

Ţelja –ţeljeni termin pregleda

Zakazano - odreĎeni 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

sluĉaja), možete 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 DTP-

u a pokušava da stavi proces koji je hronološki prvi u

gornjem levom uglu dijagrama i nastave dalje od vrha do dna, s leva na desno (npr. Slika 6-

1 a pokušava da smanji broj ukrštanja linija tokova

podataka ili da obezbede da se ukrštaju pod pravim uglom kako bi bilo manje zabune (na liniji

koja preseca mnogi nacrtaju malu grbu koja oznaĉava da se tokovi ne spajaju, nego prelaze

pacijent mogućnost

Promena ili

poništenje

ţelja

zakazano

1 recepcija ambulante

Zakazivanje termina

pregleda

zakazano

Ime pacijenta

K1 KARTOTETKA

Podaci o

pacijentima

podaci o

pacijentu

mogućnost

zakazivanja

K2 AGENDA

Lista termina

pregleda



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

analitiĉari retko savršeno nacrtaju DTP jeva, oni ga nacrtaju jednom

da bi razumeli model procesa, tokova podataka, skladišta podataka, kao i eksterne entitete, a

onda crtaju drugi put na svežem listu papira (ili novoj datoteci) da bi lakše razumeli i da bi

smanjili broj tokova podataka koji prelaze jedan preko drugog. Ĉesto se DTP crta mnogo puta

pre nego što je završen.

Slika 6-12 kombinuje DTP fragmente sa slika 6-9 i 6-10 sa DTP fragmentima druga

dva sluĉaja (proces 3, napravi obraĉun i proces 4, pripremi izveštaje za menadžment).

Odvojite trenutak da ispitatate sliku 6-12 i pronaĊete DTP fragmente iz slika 6-10 i 6-11

sadržane u njemu.

Pravljenje prvog nivoa dijagrama toka podataka (i nižih)

Tim sada poĉinje da stvara DTP nižeg nivoa za svaki proces na prvom nivou DTP-a

za koji je potreban nivo 2 DTP-a. Svaki od primera sluĉaja (studija sluĉaja) se pretvara u

sopstveni DTP. Proces za kreiranje prvog nivoa DTP-a je da se preuzmu koraci koji pišu u

primerima sluĉaja (use case) i da se „preslikaju“ u DTP, sliĉno kao i za i nivo DTP-a.

Obiĉno, svaki korak u studije sluĉaja 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 sluĉaja dobili formalni modeli procesa, kao

što je dodavanje ulaznih tokova podataka koji nisu bili prikazani u studiji sluĉaja. I zato što su

analitiĉari sada poĉinju dublje da razmišljaju o tome kako

informacionog sistema, oni ponekad malo promene korake u studijama sluĉaja da bi uĉinili

proces jednostavnijim za upotrebu.

Uz tradicionalni pristup kreiranju DTP-a, izvori i odredišta nisu dati na prvom nivou

DTP-a (i niže) za ulaze koji dolaze od i do eksternih entiteta (ili drugih procesa izvan ovog

(posmatranog) procesa). Ali, izvor i odredište tokova podataka skladišta podataka i tokova

koji idu u procese u okviru ovog DTP-a ukljuĉeni su (odnosno, od jednog koraka na drugi u

istoj studiji sluĉaja, 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 više nivoa DTP-a, problem

raste, u cilju razumevanja destinaciji toka podataka na nivou 3 DTP-a, morate da proĉitate

DTP drugog nivoa, DTP 1. nivoa i 0. nivo DTP-a, ako je odredište neki drugi sistem, onda

morate da tražite u nižim nivoima DTP-a za taj sistem.

Ukljuĉivanje spoljnih entiteta u prvi i niže nivoe DTP-a dramatiĉno se

pojednostavljuje ĉitljivost DTP-a, sa vrlo malo mana. Slažemo se da je

-ovi nisu

standardizovani, svaka organizacija ih koristi malo drugaĉije.

-

.

U idealnom sluĉaju, trudili bi smo se da baze podataka u prikazujemo na istom mestu

na stranici - - . Mi

pokušavamo da nacrtamo ulazne tokove podataka tako da dolaze sa leve ivice stranice, a



izlazne tokove podataka ostavljamo na desnoj ivici. Na primer, pogledajte DTP 1. nivoa na

slici 6-3.

Slika 6-12: DTP prvog nivoa za sistem lekarske ordinacije

pacijent

mogućnost

Promena ili

poništenje

ţelja

zakazano


Zakazivanje termina

pregleda

zakazano

Ime pacijenta

K1 KARTOTETKA

podatak o

pacijentu_3 mogućna

zakazivanja

L2 AGENDA

Račun_1 obračun

3 blagajna

obračunavanje

2 kartoteka

Aţuriranje podataka

o pacijentima

lekar osiguranje

K3 glavna knjiga

izveštaj o pacijentu

zakazano

finansiski izveštaj

obračunski

podaci

podaci

o uplati račun_2

račun_3 podaci o

isplati

zakazani lista

zakazanog

podatak o

pacijentu_3

podatak o

pacijentu_1

Informacija

o pacijentu

podatak o

pacijentu_

4

4 knjigovodstvo

Priprema

izveštaja



Jedno važno pitanje je kako nacrtati male tokove

tokovima podataka na nivou 1 DTP-a. Na primer, DTP drugogog nivoa može da pokaže

ulazni tok podataka „Informacije o pacijentu“, dok pojedinaĉni koraci u studiji sluĉaja 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 raĉva 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

niže nivoe. Dekompozicija DTP-a se može svesti do gotovo svakog nivoa, na primer,

možemo razložiti 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 može ponoviti do bilo kog nivoa detalja, tako da je moguće

imati ĉetvrti nivo ili ĉak peti nivo DTP-a.

Ne postoji jednostavan odgovor za "idealan" nivo dekompozicije, jer to zavisi od

složenosti sistema ili poslovnih procesa koji se modeluju. U principu, procese

dekomponujemo u nižem nivou DTP-a samo kad je taj proces dovoljno složen da bi dodatna

dekompozicija pomogla da se bolje obj je da treba da

postoji najmanje tri procesa i ne više od sedam do devet procesa na svakom DTP-u, tako da

ako razložite proces i na novom nivou dobijete sa samo dva procesa, verovatno ni ne treba da

ga razlažete. 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 više od devet

procesa korisnicima postaje težak za ĉitanje i razumevanje, jer je veoma kompleksan i

nagužvan. Neke od tih procesa treba objediniti i objasniti na nižim nivoima DTP-a.

Model procesa j

koji se planira, ako se koristi struktuiran naĉin projektovanja (tj, ako se ne koristi „Rapid

Application Development“ [RAD]), ili ako će sistem biti izgraĊena od strane eksternih

ugovaraĉa. Bez kompletnih nivoa detalja, može biti teško da se u ugovoru odredi taĉno š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 DTP-

a. Neki delovi sistema mogu biti veoma složeni 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, važno je da proverite njihov kvalitet. Slika 6-

13 prikazuje brzi potsetnik za identifikaciju naj . Postoje dva fundamentalno

razliĉita tipa problema koji se javljaju u DTP-ovima: sintaksne i semantiĉke greške. Sintaksa

se odnosi na strukturu DTP-a i da li DTP-ovi slede pravila DTP jezika. Sintaksne greške se

mogu posmatrati i kao gramatiĉke greške koje je napravio analitiĉar dok je stvarao DTP.

Semantika se odnosi na znaĉenje DFDs i da li su taĉno opisuJu poslovnih procesa se

modelira. Semantiške greške se mogu posmatrati kao i nesporazumi analitiĉara pri

prikupljanju, analiziranje i izveštavanju o sistemu.

-



-

, analitiĉari moraju

pažljivo i mukotrpno da pregledaju baš svaki proces, eksterni entitet, tok podataka i skladišta

podataka na svim DTP-ovima rukom da bi proverili da li su dosledna gledišta, dekompozicije

i balans.

Unutar DTP-a

Proces 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 drugaĉija imena od ulaznih tokova podataka

(izuzetak je kod skladišta podataka, gde se pretpostavlja da se isti podaci i upisuju i ĉitaju)

Ima od 3 do 7 procesa po DTP-u

Tok podataka 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 ukrštenih tokova podataka

Skladište

podataka

Svako skladište podataka ima jedinstveno ime (koje je imenica), broj i kratak opis

Svako skladište podataka ima bar jedan ulazni tok (koji oznaĉava dodavanje ili izmenu

podataka u skladištu)

Svako skladište podataka ima bar jedan izlazni tok (koji oznaĉava išĉitavanje podataka iz tog

skladišta)

Eksterni entitet Svaki eksterni entitet ima jedinstveno ime (koje je imenica) i opis

Svaki eksterni entitet ima bar jedan ulazni i bar jedan izlazni tok podataka

IzmeĎu DTP-a

Dijagram

konteksta

Svaki set DTP-ova mora imati samo jedan dijagram konteksta

Gledište Postoji konzistentno gledište za ceo set DTP-ova

Dekompozicija Svaki procese je u potpunosti opisan procesima u DTP “deci”

Balans Svaki tok podataka, svako skladište podataka i svaki eksterni entitet prikazan na višem nivou

DTP-a, mora biti prikazan i na nižim nivoima koji ga dekomponuju

Nijedno skladište podataka ili tok podataka se ne pojavljuju na DTP-u nižeg nivoa, ako se ne

pojavljuju i na višem nivou

Semantika

Primerena

reprezentacija

Korisniĉka validacija

Simluranje procesa

Konzistentna

dekompozicija

Ispitajte DTP najnižeg nivoa

Konzistentna

terminologija

Pažljivo ispitajte nazive

Slika 6-13 / tabela: Lista kontrole kvaliteta DTP-a

ksne greške koje analitiĉari poĉetnici prave pri

kreiranju DTP-a su u kršenju zakona o održanju podataka3.

Prvi deo tog zakona navodi da: „Podatak u mirovanju ostaje u mirovanju sve dok ga

ne pokrene proces“. Drugim reĉima, podaci se ne mogu kretati bez procesa. Podaci ne mogu

da idu ili dolaze iz skladišta podataka, ili eksternih entiteta bez procesa koji bi ih gurnuli ili

povukli.

Drugi deo Zakona navodi da: „Procesi ne mogu da unište ili stvore podatke“. Drugim

reĉima, podaci samo ulaze ili napuštaju sistem putem eksternih entiteta. Proces ne može

uništiti ulazne podatke; svi procesi moraju imati izlaz. Nacrtan proces bez izlaza se ponekad

3 Ovaj zakon je razvio Prof. Dale Goodhue na Džordžija univerzitetu



naziva greškom "crna rupa". Isto tako, proces ne može da kreira nove podatke; može samo da

transformiše podatke iz jednog oblika u drugi, ali ne može da proizvede izlazne podatake bez

ulaza. Crtanje procesa bez ulaza se ponekad naziva "ĉudo" greška (jer se izlazni podaci pojave

ĉudom). Postoji jedan izuzetak4 u delu zakona o ulazima, ali je tako redak da

analitiĉara nikad na njega ne naiĊe. Slika 6-14 prikazuje neke uobiĉajene greške u sintaksi.

Slika 6-14: Ĉeste greške –sintaksne greške u DTP

4 Izuzetak je temporalni proces koji pokreće okidaĉ baziran na internom satu. Svaki put kada odreĊeni period

proĊe proces proizvodi izlaz. Ovaj proces nema ulaza zato što je sat interni element procesa.

pacijent

mogućnost

Promena ili

poništenje

ţelja

zakazano


Zakazivanje termina

pregleda

zakazano –sinonim,

isti naziv izlaznog

i ulaznog toka

podataka

zakazano

Ime pacijenta

K1 KARTOTETKA

Skladište bez izlaza

Eksterni entitet ne

moţe direktno

pristupiti skladištu

L2 AGENDA

Skladište bez ulaza

račun obračun

3 blagajna

obračunavanje

3 knjigovodstvo

Proces nema

ulaznih

podataka

2 kartoteka

Proces nema

izlaznih podataka

lekar osiguranje

K1 glavna knjiga

izveštaj o pacijentu

zakazano

finansiski izveštaj

uplate

podaci o fakturi i

isplati

ne sme biti

dvosmerni tok

podataka

lista

zakazanog

Tok nema veze sa procesima sistema

podaci o

pacijentu



oju sistema.

Semantiĉke greške su mnogo teže za pronalaženje i ispravku, jer zahtevaju dobro

razumevanje poslovnih procesa. Pa ĉak i tada, ono što se može identifikovati kao greška može

zapravo biti neshvatanje osobe koja vrši proveru modela. Postoje tri korisne provere kako bi

osigurali da su modeli semantiĉki ispravni (vidi grafikon 6-13).

Prvi

potvrdi ispravnost modela „prolazeći“ kroz model (tj. model se predstavi korisnic

-a na isti

naĉin na koji su igrali ulogu u studijama sluĉaja. Korisnici se pretvaraju da izvršavaju procese

upravo onako kako je opisano u DTP-u. Zapoĉinju u p

, kako bi dobili tražene izlaze. Onda prelaze na drugi proces i

tako dalje.

Jedna od malo suptilnijih formi semantiĉke greške 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 važi i za raĉunarske sisteme, tako da izlazi

procesa mogu biti samo kombinacija i transformacije njegovih ulaza. Pretpostavimo, na

primer, želimo da zabeležimo narudžbinu, trebalo bi nam ime klijenta i poštanska adresa,

koliĉina i cene E-proizvoda koje kupac naruĉuje. Nama trebaju informacije iz skladišta

podataka o korisnicima (na primer, adresa) i podaci iz skladišta podataka e-prodavnice (npr.

cena). Mi ne možemo nacrtati proces koji proizvodi izlazni tok podataka za narudžbinu bez

ulaza iz ova dva skladišta podataka. Igranje uloga uz striktno pridržavanje ulaza i izlaza na

modelu je jedan od najboljih naĉina da naĊete ovu vrstu greške.

Druga provera

- , svi procesi

treba da budu na istom nivou detalja, što nije isto što i isti broj nivoa. Na primer,

pretposta

: (1) uĊi u auto; (2) startuj motor; (3) vozi. Još jedan nivo detalja bi bio: (1) otkljuĉaj

auto; (2) sedi u auto, (3) veži sigurnosni pojas i tako dalje. Još jedan nivo bi bio: (1) izvadi

kljuĉ iz džepa, (2) ubacite kljuĉ u kljuĉaonicu; (3) okreni kljuĉ, i tako dalje. Nijedan od njih

nije nasledno bolji od drugih, ali u neobiĉnim okolnostima, obiĉno je najbolje da se obezbedi

da svi procesi na samom dnu modela pružaju isti nivo detalja.

Ĉeste greške su: sinonimi naziva, tok podataka izmeĊu entiteta, skladištu nedostaje

ulazni ili izlazni tok podataka, procesu nedostaje ulazni ili izlazni tok podataka, dvosmerni tok

podataka, tok podataka neposredno izmeĊu eksternih entiteta (tok nema veze sa procesima

sistema

Obiĉno, svaki korak u studije sluĉaja 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 sluĉaja da bi uĉinili

proces jednostavnijim za upotrebu.

Isto tako, važno je da se osigura da je terminologija usklaĊena u celom modelu. Isti

element može imati razliĉite nazive u razliĉitim delovima organizacije, tako da

"narudžbenica" kod jedne osobe može biti "narudžbina mušterije". Isto tako, isti termin može

imati razliĉita znaĉenja, na primer, "datum isporuke" može da znaĉi jednu stvar prodavcu

koji uzima narudžbinu n datum), a nešto drugo do magacioneru u skladištu (na

primer, stvarni datum isporuke). Rešavanje ovih razlika pre nego što je završen model je

važno kako bi svako ko ĉita modela ili koristi informacioni sistem izgraĊen od modela ima

podjednako razumevanje.



Projektovanje IS –Primena koncepta na e-prodaji E–proizvoda

Pravljenje dijagrama konteksta

Projektantski tim je poĉeo kreiranjem dijagrama konteksta e-prodaje E-proizvoda

(softvera, e-knjiga, muzike ili CD-ova, i sliĉnog). Proĉitali su gornji deo tri glavne studije

sluĉaja na slici 5-6 da bi pronašli glavne ulaze i izlaze. Prvi sluĉaj (obuhvatanje

zahteva za E-proizvode) sadrži ĉetiri glavna ulaza od korisnika i dva skladišta podataka.

Skladišta podataka su unutar sistema, tako da nisu dokumentovana u dijagramu konteksta.

Ovaj sluĉaj , jedan izlaz za posebnu bazu podataka

za narudžbenice i jedan za bazu u prodavnici. Baze podataka za narudžbenice je eksterna

internet sistemu, pa je dokumentovana u dijagramu konteksta, ali kao sistem.

Baza podataka unutar prodavnice je nešto složenija. Nije strogo interna internet

sistemu e, ali je deo ovog projekta razvoja sistema, pa se

može reći da je u okviru "sistema" široko tumaĉivši. Bud će studija sluĉaja za

upravljanje sistema prodavnice biti deo internet sistema, i zato što bazu podataka prodavnice

koristi samo internet sistem, projektantski tim je odluĉio da će se ovo skladište podataka

smatrati kao interno skladište internet sistema. Slika 6-15 prikazuje nekompletan dijagram

konteksta nakon razmatranja samo prve studije sluĉaja.

Tim pre studije sluĉaja. Odvojite trenutak i dovršite dijagram

konteksta na slici 6-15 dodavaj je iz preostale dve studije sluĉaja. Slika 6-16

prikazuje konaĉan dijagram konteksta koji je razvio projektni tim.

Slika 6-15: Dijagram konteksta pokrivanja „prodaja uobiĉajenih materijala“ – nekompletan

Dijagram konteksta sistema e–prodaje

e-prodaja zahtev pretrage

PronaĊeni materijal

traţenje informacija

lista ponuda

zahtev (narudţbina)

informacije o korisniku

isporuĉeni materijal

informacija o ponudi specijalan

zahtev

sistem za

specijalne

narudţbine

kupac



Slika 6-16: Dijagram konteksta sistema e –prodaje

Dijagram konteksta na slici 6-16 je veoma zagušen (pretrpan), posebno u okolini

eksternog entiteta kupac. Neki analitiĉari bi možda u ovom sluĉaju pokušali da sjedine neke

od ovih tokove podataka u tok podataka višeg 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. MeĊutim, to zahteva da i DTP prvog nivoa koriste te iste snopove i na kraj

da odreĊeni DTP drugog nivoa ili nižeg koristi raĉve i spojeve, kako su ovi

snopovi prikazani kao da su ulazni za DTP, a specifiĉni elementi unutar njih se koriste u

procesima DTP-a. Takva upotreba raĉvi i spojeva

nivoima. To je stvar odabira za koji nema taĉnog odgovora na pitanje –šta je ispravno, a šta

nije. Mi smo odabrali da ne grupišemo ove tokove podataka na dijagramu konteksta da bi

izbegli složenost raĉvi i spojeva kasnije.

Pravljenje fragmenata dijagrama toka podataka

bi bio da se napravi jedan DTP fragment za svaku studiju sluĉaja. Ovo

je uĉinjeno crtanjem procesa u sredini stranice, vodeći raĉuna o tome da su

brojevi procesa i naziv sa spajanjem svih ulaznih i izlaznih tokova podataka na njega. Za

e-prodaja

zahtev pretrage


traženje informacija

lista ponuda

zahtev (narudžbina)



informacija o proizvodu

specijalan

zahtev

kupac

dobavljač

eksterni

marketing

materijal

interni

marketing

materijal

informacije

dobavljaĉa

podaci o

proizvodu

D1: Podaci o proizvodima D2: Stanje zaliha

podaci o

zalihama

IS

marketinga

IS specijalnih

narudţbina

promena

zaliha

izveštaji

IS otpreme

(interno skladište)

nalog

otpremi

potvrda

isporuke

zahtev

dobavljaĉu

opomena

otpremi



razliku od dijagrama konteksta, DTP fragment ukljuĉuje tokove podataka sa eksternim

entitetima i unutrašnjim i eksternim skladištima podataka.

studije sluĉaja 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. MeĊutim, nije bilo ulaznog toka podataka koji obezbeĊuje te

informacije. Dakle, tim će ga dodati DTP-u (i odgovarajućoj studiji sluĉaja).

Slika 6-17 prikazuje DTP fragment za prvu studiju sluĉaja. 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 sluĉaja su podjednako jednostavni. Postoji više dobrih

naĉina da se nacrtaju oba.

Pravljenje DTP-a prvog nivoa

e bio da se napravi DTP nultog nivoa spajanjem DTP fragmenata, što

je prošlo 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 mehaniĉka vežba (Slika 6-19). U ovom sluĉaju,

proktanti su pokušali da pozicioniraju spoljne entitete na sliĉna mesta na ovom DTP-u kao na

dijagramu konteksta na slici 6-16, jer se tako lakše razumeju ova dva dijagrama.

Slika 6-17: DTP kontekstualni fragment pokrivanja „obuhvat zahteva“ internet nabavku

1

Obuhvat zahteva

zahtev pretrage



lista ponuda




informacija o proizvodu

specijalan

zahtev

kupac

marketing

materijal podaci o

proizvodu

D1: Stanje zaliha

podaci o

zalihama

IS specijalnih

narudţbina

IS otpreme


nalog

otpremi

D3: marketing podaci D1: Podaci o proizvodima



a) DTP ragment –ažuriranje marketing podataka

b) DTP ragment –ažuriranje marketing podataka

Slika 6-18: Ostala dva DTP fragmenta za e–prodaju

marketing

materijal

dobavljaĉa

2

Aţuriranje marketing

materijala

dobavljač

marketing

materijal podaci o

proizvodu

D3: marketing podaci

marketing

materijal

IS marketinga

marketing

izveštaji

informacije

dobavljaĉa

D1: Podaci o proizvodima

D4: Podaci o otpremi

D2: Stanje zaliha

nalog

otpremi

potvrda

isporuke opomena

otpremi

IS otpreme


3 proces

otpremanje

Zahtev za

otpremu

potvrda

otpreme

promene

zaliha



Pravljenje dijagrama toka podataka prvog nivoa (i ispod)

Slika 6-19: Prvi nivo DTP e-trgovine E-proizvodima

-ovi prvog nivoa za one procese od koji može

biti od koristi. Analitiĉari su poĉeli sa prvom studijom sluĉaja (uzimanje zahteva kupca) i

poĉeli su da crtaju DTP-ove za pojedinaĉne korake koje je sadržala studija. Prva tri koraka u

studiji sluĉaja bila su jednostavna, ali kao i inaĉe, ekipa je morala da izabere imena i brojeve

1

Obuhvat

zahteva

zahtev pretrage



lista ponuda




informacija o ponudi

specijalan

zahtev

kupac

IS za

specijalne

narudţbine

marketing

materijal

podaci o

proizvodu


D1: Podaci o proizvodima

informacija

o proizvodu

2

Aţuriranje

marketing

materijala

marketing

materijal

dobavljaĉa

dobavljač

informacije

dobavljaĉa

marketing

materijal

IS

marketinga marketing

izveštaji

marketing

podatak

D2: Stanje zaliha

podaci o

zalihama

D4: Podaci o otpremi

Zahtev za

otpremu

potvrda

otpreme

nalog za

otpremu

3

proces otpremanja

promene

zaliha

nalog

otpremi

potvrda

isporuke

opomena

otpremi

IS otpreme




za procese i da dodaje ulazne tokove podataka iz skladišta podataka koji se nisu pojaljivali u

studiji sluĉaja.

Poslednja ĉetiri koraka u studiji sluĉaja zahtevala su neka promišljanja.

Pretpostavimo da nam je poznata studija sluĉaja e –kupovine (softvera, e-knjiga, i E-

proizvoda ĉija studija sluĉaja se ĉesto pominje u literaturi). Poslednja ĉetiri koraka su odabir

jednog ili više E-proizvoda, odjava uz evidentiranje podataka o klijentu, kao i zahtevi obiĉnih

i specijalnih narudžbina. Pri razmišljanju o tome kako je to uraĊeno na drugim Web

lokacijama, projektant je odluĉio 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 takoĊe ukljuĉivao

slanje obiĉnih i specijalnih narudžbi, pre nego se oni stave u posebne procese. Njihova verzija

DTP-a prvog nivoa za prvu studiju sluĉaja je prikazana na slici 6-20.

DTP drugog nivoa za e–trgovinu

Slika 6-20 DTP drugog nivoa za proces 1, “obuhvat zahteva“

1.1

Odabir materijala

1.2

Davanje informacija

o materijalu

1.5

Provera i potvrda

dostavljanog

materijala

1.3

pronalaţenje

materijala u

skladištu

1.4

Formiranje korpe kupca, i

dostavljanje materijala kupcu

opis1

D1: podaci o proizvodima opis2

marketing

materijal


D2: stanje zaliha

podaci o

zalihama

struktura

isporuke

specijalan

zahtev IS specijalnih

narudţbina

zahtev pretrage



kupac

potvrda kupca

o korisniku

podaci o proizvodu

marketing materijal

specifikacija raĉuna

ID materijala

raspoloživo u

skladištu

narudžbina

isporuka

specifikacija

isporuke

D4: isporučeni proizvodi



-

pominjanja korpe kao skladišta podataka, ali oĉigledno nam je potrebno da negde saĉuvamo

koji su E-proizvodi izabrani. Bilo bi sasvim logiĉno da se ukljuĉi drugo skladišta podataka

koje bi se zvalo D5: Korpa za kupovinu koja prima izlaz iz procesa 1.4 i šalje ulaz u proces

1.5. Ovo skladište podataka je privremeno skladište podataka koje sadrži podatke samo dok

kupac ne završi kompletiranje narudžbine, ili dok ne napusti transakciju. Kada se kupac

odjavi, privremeno skladište (korpa za kupovinu) se briše. Po nekada, ne ukljuĉuju se

privremena skladišta podatka koja ne prežive transakciju na DTP-ovima. Ali opet, ni to ne bi

bilo pogrešno, samo nije uobiĉajeno. Umesto toga, mi prikažemo da proces 1.4 šalje podatke

procesu 1.5 preko toka podataka.

rocesa na ovom prvom nivou DTP-a

sa -

kritiĉnog znaĉaja u toku faze dizajniranja –za razvoj

modela podataka i kreiranje korisniĉkog interfejsa i programa.

Validacija dijagrama toka podataka

Konaĉan 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 pomoću odgovarajućeg CASE

(automatizovane projektantske alatke).

Rezime

Sintaksa dijagrama toka podataka

Ĉetiri simbola se koriste u dijagramima toka podataka (proces, tok podataka,

skladište podataka, kao i eksterni entitet). Proces je aktivnost obavlja neku radnju. Svaki

proces ima naziv (poĉinje 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 obiĉno ima

najmanje jedan ulaz. Tok podataka je podatak ili objekat i ima naziv (imenica) i opis i poĉinje

ili se završava na procesu (ili oboje). Skladište podataka je papir ili raĉunarska datoteke i ima

broj, ime (imenica), a najmanje jedan ulazni tok podataka i jedan izlazni tok podataka (osim

ako skladište podataka nije stvorio proces van dijagrama toka podataka [DTP]). Spoljašnji

entitet je entitet ili organizacija (sistem) izvan opsega posmatranog sistema i ima naziv

(imenica) i opis. Svaki set DTP-ova poĉinje sa dijagramom konteksta i ima brojne DTP-ove

prvog, drugog itd, nivoa. Svaki element na DTP-u višeg nivoa (npr. tok podataka, skladište

podataka, eksterni entitet) mora da se pojavljuje i na DTP-ovima nižeg nivoa inaĉe nisu

izbalansirani. Tok podataka može da se raĉva i spaja na bilo kom nivou seta DTP-a, ali je ovo,

uglavnom, uobiĉajeno na nižim nivoima.

Pravljenje dijagrama toka podataka

Dijagrami tokova podataka se prave koristeći studije sluĉaja. 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 sluĉaja, koji

prikazuju kako studija sluĉaja razmenjuje tokove podataka sa eksternim entitetima i

skladištima podataka. Treće, ovi DTP fragmenti se organizuju u DTP nultog nivoa. Ĉetvrto,



tim razvija DTP-ove drugog nivoa na bazi koraka u studiji sluĉaja, unutar svake studije

sluĉaja, da bi detaljnije objasnili kako funkcionišu. Zatim, projektanti proveravaju DTP

setove, da bi bili sigurni da su kompletni i taĉni i da nemaju ni sintaksnih ni semantiĉkih

grešaka. Analitiĉari retko naprave valjan DTP iz prvog pokušaja, pa je iteracija jako važna da

bi bili ĉitki i dijagrami koji staju na jednu stranicu, ali i oni koji se protežu 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 grafiĉku 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. Prouĉiti „svoj vlastiti realni sistem“ i nacrtati model DTP za „svoj“ sistem.

Skupovi DTP

U praksi koriste se razliĉiti skupovi DTP za opisivanje ciljnog sistema (IS koji se

projektuje) na razliĉite naĉine, polazeći 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. postojeći sistem ili organizacija

Kako on radi - DTP RS , logiĉki projekat postojećeg sistema

Šta treba da radi -projekat IS, zahtevani logiĉki DTP

Kako treba da radi -dizajn IS, zahtevana fiziĉka struktura IS.

0_3 dtp modeli procesa

Documents

vreme zakazanog

mogui termin

iz prostog

izlazi postaju

eljeni termin

zakazivanje

stvarnog programskog

strelica pokazuje