Univerzitet u Istonom Sarajevu

Saobraajno-tehniki fakultet Doboj

Tema: Dijagram toka podataka i informacija za podsistem kalkulacije cijena u hotelskom sistemu
- Seminarski rad Predmet: Projektovanje informacionih sistema

Profesor: dr Ljubia Preradovi Asistent: Mladen Vidi, dipl.mat.

Studenti: Jovica Ili 341/06 Danijela Lazarevi 371/06

Doboj, 2007

1. Uvod
Potrebno je napraviti podsistem kalkulacije cijena za hotelski sistem, ali prije toga moramo se upoznati sa osnovnim pravno-tehnikim i tokovnim dijelovima vezanim za kalkulacije. U osnovi, dobijamo fakturu dobavljaa sa svim potrebnim stavkama. Na fakturi dobavljaa se nalaze artikli za koje je potrebno napraviti ulaz tj. kalkulaciju po datoj fakturi. Nakon pravljenja kalkulacije, istu je potrebno arhivirati i upisati na skladite tj. poveati stanje skladita za tu kalkulaciju, ali vodei rauna i o drugim artiklima koji se nalaze na istom, a isto tako i o njihovim trenutnim cijenama. to znai da na skladitu moemo imate iste artikle ali po razliitoj cijeni. Takoe je potrebno da odtampamo kalkulaciju. to se tie artikala, u tu grupu spada sve ono to moemo da prodamo u hotelu ali namee se jo jedno pitanje a to je usluga koju pruamo u hotelu kao to je noenje, telefoniranje, koritenje pogodnosti koje nisu ukljuenje u cijenu noenja (smjetaja) a radi se npr. o masai i drugim slinim stvarima. Za njih nemamo fakturu dobavljaa, kao propratni dokument, i ne moemo da pravimo kalkulaciju cijena (moemo da napravimo neku internu kalkulaciju u kojoj emo rei koliko te usluge kotaju) i ne moemo da ih imamo na skladitu kao stvarno fiziko stanje ali moemo da ih fakturiemo tj. naplaujemo kao uslugu. Tako da nam usluga moe stajati u artiklima sa unapred formiranom cijenom ili da cijenu formiramo u trenutku fakturisanja. Naravno bitno je dodati jednu stavku a to je da prilikom fakturisanja usluge moramo urauniti i porez to nije sluaj sa artiklima jer gledajui hotel kao maloprodajni objekat cijene na njegom skladitu su sa uraunatim porezom. Potrebno je obezbjediti da se stavke kalkulacija u trenutku pravljenja a isto tako i nakon njega, mogu ispravljati u sluaju greke, inae to vai i za ostale dijelove kalkulacije. Za ispravljanje kalkulacije, nakon upisa (knjienja kalkulacije), potrebno je obezbijediti programski mehanizam da se upisana kalkulacija ne moe ispravljati ako je bilo koji artikal sa iste prodat tj. napravljen izlaz.

2. Zadatak
Dat je spisak funkcija i entiteti koji su kljuni u sistemu crteom. Student treba da napravi u elektronskom formatu rad koji sadri dijagram toka podataka (DTP) kao model SSA koji opisuje odreeni kontekst funkcijonisanja hotelskog informacionog sistema. DTP koji se realizuje treba da ukae na meupovezanost pojedinih podsistema ili funkcija sistema, yavisno od nivoa na kojem objanjava funkcionisanje (pod)sistema. Treba nacrtati i relacioni model podataka ukoliko je to mogue iz datog opisa sistema, a ako razvojni softver koji je koriten za realizaciju istih podrava neophodno je nacrtati i modele podataka (ERD).Rad treba da sadri kreirane modele, objanjenja tih modela i eventualnu diskusiju da li je moglo neto da se rijei drugaije. Po formi rad bi trebao da bude 6-10 stranica, sa svim formalnim elementima koje ima seminarski rad.

Kalkulacija cena

Unos/Izmena Kalkulacije cene

Sifarnik elemenata kalkulacije

Unos/Izmena Stavki kalkulacije cene

Izvestaj o prometu po knjiznim kodovima razbijen po elementima kalkualacije

Zakljucivanje kalkulacije

Promovisanje kalkulisane cene u cenovnik

Stampa kalkulacije cene

Kreirati i obrazloiti DTP koji modeluje tok informacija u ovom sistemu. Za ovako skiciran sistem osmisliti i model podataka, i nacrtati relacioni model.

3. Postupak rjeavanja problema

Gore definisani zadatak emo rijeiti upotrebom metologije SSA (strukturna sistem analiza) i specifine metode za modelovanje funkcija DTP (dijagram toka podataka) i specifine metode za modelovanje podataka ERD (entitet-relicija dijagram). Za praktinu realizaciju rjeenja koristiemo case alat Case Studio.

3.1. Strukturna sistem analiza (SSA)

Strukturna sistemska analiza (SSA) je jedna potpuna metodologija za specifikaciju informacionog sistema, odnosno softvera. Ona se na razliite naine moe povezati sa metodama drugih faza u neku specifinu metodologiju cijelokupnog razvoja IS. Tako na primjer, ona moe biti polazna osnova za metodu Strukturnog projektovanja programa, ili projektovanja logike strukture baze podataka metodom normalizacije, ili se moe tretirati kao metodoloki postupak dekompozicije nekog sistema na podsisteme sa ciljem da se, nalaenjem modela podataka podsistema i njihovom integracijom, doe do potpunog modela podataka posmatranog sistema. Potpuna, tana, formalna i jasna specifikacija IS, ili kako se to obino kae, specifikacija zahtjeva korisnika, zahtjeva koje budu i sistem treba da zadovolji, predstavlja bitan preduslov za uspjeno dalje projektovanje i implementaciju sistema. Oigledno je zbog ega specifikacija IS treba da bude potpuna i tana. Zahtjev da specifikacija bude formalna iskazuje se zbog toga to je formalna specifikacija osnova za "transformaciono" projektovanje i implementaciju, za atomatizovano generisanje baze podataka i programa iz nje, odnosno za korienje CASE sistema. Zahtev da specifikacija bude jasna iskazuje se zbog toga to u specifikaciji IS u velikoj mjeri uestvuju korisnici sitema, neinformatiari, pa jezik specifikacije mora biti i njima prihvatljiv. Originalna SSA iji su tvorci Yourdon i njegovi saradnici (DeMarco i drugi) poseduje veoma jednostavne, grafike, pa samim tim i jasne koncepte. Ovde su svi ovi koncepti zadrani, a stroija formalizacija je dodata samo za opis strukture tokova i skladita podataka, da bi se obezbjedio specifian transformacioni razvoj IS koji Standardna metodologija zagovara. Specifikacija IS treba da prikae (potpuno, tano, formalno i jasno) ta budui informacioni sistem treba da radi. Veoma je bitno odmah istai da specifikacija IS prikazuje TA IS treba da da, a ne i KAKO to treba da ostvari. Oigledno je da prerano definisanje "kako", odnosno davanje nekih projektantskih rjeenja u okviru specifikacije, ograniava kasniji mogui izbor (optimizaciju) naina implementacije sistema. Odgovor na pitanje "kako" daje se za konkretno okruenje, za definisanu tehnologiju i organizaciju u kojoj se sistem implementira. Da specifikacija ne bi sadrala tehnoloki i organizaciono ograniena reenja, obino se kae da ona treba da opie funkcionisanje IS u "idealnoj tehnologiji", gde praktino nikakva ogranienja ne postoje. Ako je specifikacija ovako zadata, onda je, prije prelaska na dalje projektovanje, neophodno da se definiu sva ogranienja koja namee okolina u kojoj se sistem implementira.

3.2. Dijagram toka podataka (DTP)

Dijagram toka podatka (DTP) predstavlja model sistema koji sadri etiri osnovne komponente: procese obrade podataka (aktivne komponente sistema), objekte okruenja (interfejse) sa kojima sistem komunicira, skladita podataka koje procesi koriste i/ili auriraju i tokove podataka koji povezuju ostale komponente sistema u cjelinu. Osnovne karakteristike DTP-a su: jasna grafika specifikacija, pogodna za komunikaciju sa korisnikom, istovremeno jasan i detaljan opis sistema, primjenom metode apstrakcije tako da se sistem na viim nivoima apstrakcije opisuje uopteno, a na niim detaljno.

Slika 1. Dijagram toka podataka

Dijagram toka podataka (Slika 1) ima sledee grafike simbole: krug ili elipsa pretstavlja funkciju ili proces obrade podataka, pravougaonik predstavlja interfejs, usmjerena linija predstavlja tok podataka, dvije paralelne linije ("otvoreni" pravougaonik) predstavlja skladite podataka

3.3. Model podataka (ERD)

Model podataka je intelektualno sredstvo za opis statikih karakteristika sistema, opis karakteristika sistema u nekom stacionarnom stanju. Stacionarno stanje nekog sistema karakterie se skupom zavisnosti koje postoje izmedju objekata sistema. Ove zavisnosti se, u modelu podataka, mogu predstaviti bilo strukturom podataka, bilo skupom ogranienja na vrijednosti podataka. Pored toga, neophodno je definisati i skup operacija modela podataka, da bi se preko njih, u modelima procesa, mogla da opie i dinamika realnog sistema. Zbog toga svaki model podataka poseduje tri osnovne komponente: Strukturu modela, odnosno skup koncepata za opis objekata sistema njihovih atributa i njihovih meusobnih veza. Ogranienja - semantika ogranienja na vrednosti podataka koja u svakom stacionarnom stanju moraju biti zadovoljena. Ova ogranienja se obino nazivaju pravilima integriteta modela podataka. Operacije nad konceptima strukture, pod definisanim ogranienjima, preko kojih je mogue opisati dinamiku sistema u modelima procesa.

4. Praktina realizacija

4.1. Dijagram toka podataka za proces Unos/Izmjena kalkulacije cijena i Unos/Izmjena stavki kalkulacije cijena

Slika 2. Unos/Izmjene kalkulacije cijena i stavki kalkulacije

Prilikom unosa kalkulacije, fukcija Unos kalkulacije uzima elemente kalkulacije iz istoimenog skladita nakon ega se vri pozivanje funkcije za unos stavki kalkulacije. Kada su stavke unete vri se zakljuivanje kalkulacije. Funkcija izmjena ne zakljuene kalkulacije vri promjenu kalkulacije i trai njenu potvrdu koju operater potvruje ili ne. Poziva se funkcija za izmjenu stavki kalkulacije i kada se ona odradi vri se zakljuivanje kalkulacije. Treba naglasiti da se mogu samo mijenjati kalkulacije koje nemaju potvrdu o zakljuivanju. Ukoliko se kalkulacija zakljui, izmjene na njoj se vie ne mogu vriti.

4.2. Dijagram toka podataka za proces promovisanje kalkulisane cijene u cijenovnik

Slika 3. Promovisanje kalkulisane cene u cenovnik

Ova funkcija uzima uzima kalkulisanu cenu iz kalkulacije i skladiti je u cenovnik.

4.3. Dijagram toka podataka za proces tampanje kalkulacije cena

Slika 4. tampanje kalkucije cijena

Funkcija tampa kalkulacije cijena uzima kalkulaciju i tampa je.

4.4. Dijagram toka podataka za proces ifarnik elemenata kalkulacije

Slika 5. Unos u ifarnik elemenata kalkulacije

Pomou funkcije unos u ifarnik elemanata kalkulacije se unose imenovani a isto tako se pomou funkcije izmena ifarnika elementa kalkulacije mogu vriti promene nad istima.

4.5. Dijagram toka podataka za proces izvjetaj o prometu

Slika 6. Izvjetaj o prometu

Izvjetaj o prometu po knjinim kodovima razbijen po elementima kalkulacije cena uzima zaduzenja boravka za odreeni period a isto tako informacije o boravku, ifarnik elemenata kalkulacije i knjine kodove i pravi pomenuti izvjetaj te ga zatim tampa.

5. Relacioni model baze podataka projektovanog podsistema

Na slijedeoj slici je prikazan relacioni model baze podataka podsistema kalkulacije cijena hotelskog poslovanja. Ovaj relacioni model je dobijen na osnovu razrade DTP dijagrama projektovanog sistema i na osnovu spiska tabela koje su navedene u zadatku.

Slika 7. Relacioni model baze podataka podsistema kalkulacije cena

10

6. Zakljuak
Ovako projektovan dijagram toka podataka za kalkulaciju cijena i formirani relacijski model za isti, nije striktno vezan samo za hotelsko poslovanje, ve se moe primjeniti i u bilo kom drugom poslovnom segmentu gde se ista primjenjuje. Moda je bitno napomenuti da u drugim objektima prodajnog ili uslunog karatera, cijena na skladitu stoji bez uraunatog poreza (kakav je sluaj u veleprodajama) dok u maloprodajnim objektima stoji sa uraunatim porezom, ali to ne remeti ovako koncipirani sistem. U naelu ovo je zahtjev inspekcijskih slubi koje rade u tom domenu. Sa ovako projektovanim sistemom moemo lako pratiti artikal od ulaza do izlaza i obratno u sluaju povrata od kupca i povrata dobavljau, to je veoma bitno zbog izlaznog odnosno ulaznog poreza na ta moramo da obratimo naruitu panju, jer su kazne za nepravilan obraun poreza veoma visoke. U ovom radu je pokuano da se to bolje prikae funkcionisanje kalkulacije cena kao dio informacionog sistema za rad u hotelima. Ovo je osnovni princip rada sa kalkulacijama cena hotela koji se odgovarajuom doradom i proirenjima moe primjeniti na nekom od stvarnih informacionih sistema hotela. Treba napomenuti da je sistem pravljen na osnovu imaginarnog hotela a ne stvarnog hotela i na osnovu informacija koje su nam bile dostupne prilikom izrade te je ovakav model predstavlja prototip za dio informacionog sistema hotela.

11

7. Literatura
1. dr Alempije Veljovi, Razvoj informacionih sistema i baze podataka, Beograd 2001. godina. 2. Help for BPwin. 3. Help for ERwin.

12