magacinsko-poslovanje.doc

Sadraj

Veljko Pakevi Magainsko poslovanje

Magacinsko poslovanje

Saetak:

U radu je opisan proces projektovanja i implementacije aplikacije magacinskog poslovanja. Postupak projektovanja je izveden UML metodologijom koja je u radu detaljno objanjena i predstavljena kroz sve faze. U radu je dat poseban osvrt na dva kompletna sluaja korienja: prijemnica i otpremnica.

U okviru rada dat je opis vieslojne arhitekture aplikacije, razvojnog alata Visual Studio-a 2003 i baze MS SQL 2000. Objanjen je nain implementacije svakog sloja ponaosob..

Kljune rei:

UML, distribuiran, LAN, vieslojna arhitekutra, .NET, Web service, VPN.

Warehouse business

Abstract:

This work describes process of projecting and implementation aplication of warehouse business. Procedure of projecting is performed UML methodology which is detailed describe in work and represented thru each phase. In work was given specific attention on two complete use cases: reception note and dispatch noteAlso it is given description of n-tier architecture of application, development tool Visual Studio.NET 2003 and data base MS SQL 2000. It is describe the implementation way of every tier each with special point on Web service technologies.

Key words:

UML, distributed, LAN, n-tier architecture, .NET, Web services, VPN

SADRAJ1 Uvod41.1Uvod u Magacinsko poslovanje42 UML52.1ta je UML52.2Modeliranje sistema Novi vs. Stari nain62.3UML komponente72.3.1Class dijagram72.3.2Use Case dijagram102.3.3State dijagram122.3.4Sequence dijagram132.3.5Collaboration dijagram142.3.6Activity dijagram152.3.7Component dijagram172.3.8Deployment dijagram193 Magacinsko poslovanje jezikom UML-a20213.1Sluaj korienja: Prijemnica

223.1.1Unos prijemnice

233.1.1.1 Sekvencni dijagram- Unos prijemnice

3.1.1.2 Kolaboracioni dijagram- Unos prijemnice243.1.1.3 Dijagram Aktivnosti- Unos prijemnice253.1.2Auriranje prijemnice263.1.2.1 Sekvencni dijagram- Auriranje prijemnice273.1.2.2 Kolaboracioni dijagram- Auriranje prijemnice283.1.2.3 Dijagram aktivnosti- Auriranje prijemnice29303.1.3Brisanje prijemnice

313.1.3.1 Sekvencni dijagram- Brisanje prijemnice

323.1.3.2 Kolaboracioni dijagram- Brisanje prijemnice

333.1.3.3 Dijagram aktivnosti- Brisanje prijemnice

3.1.4Dijagram klasa- Prijemnica343.1.5Dijagram Stanja353.2Sluaj korienja: Otpremnica u maloprodaju363.2.1Unos otpremnice u maloprodaju373.2.1.1 Sekvencni dijagram- Unos Otpremnice383.2.1.2 Kolaboracioni dijagram- Unos Otpremnice393.2.1.3 Dijagram aktivnosti- Unos Otpremnice40413.2.2Auriranje otpremnice u maloprodaju

423.2.2.1 Sekvencni dijagram- Auriranje Otpremnice

433.2.2.2 Kolaboracioni dijagram- Auriranje Otpremnice

3.2.2.3 Dijagram aktivnosti- Auriranje Otpremnice443.2.3Brisanje otpremnice u maloprodaju453.2.3.1 Sekvencni dijagram- Brisanje Otpremnice463.2.3.2 Kolaboracioni dijagram- Brisanje Otpremnice473.2.3.3 Dijagram aktivnosti- Brisanje Otpremnice483.2.4Dijagram klasa- Otpremnica493.3Deployment diagram504 Razvoj aplikacije514.1Razvojni alati51444.1.1Microsoft Visual Studio 2003

444.1.2Microsoft SQL Server 2000

444.2Arhitektura aplikacije

444.2.1Prezentacioni sloj

4.2.1.1 Forme564.2.3Business Sloj584.2.4Brokeri614.2.5Baza podataka615 DATA WAREHOUSING I OLAP635.1Datamart635.2Data minig636 VIZIJA667 ZAKLJUAK678 LITERATURA68

1 UVOD

1.1 UVOD U MAGACINSKO POSLOVANJE

U svetu velike konkurencije, gde razlika izmeu proizvoda kako u kvalitetu tako i u karakteristikama nestaje, svaki kupac je zlata vredan. Borba izmeu kompanija svakim danom jaa, a veoma esto uspeh zavisi samo od trenutka, od prave informacije u pravo vreme. Kompanije koje imaju bolje informacije, kompanije koje znaju ta se u svakom trenutku na tritu zahteva postaju lideri trita koji diktiraju standarde i postavljaju pravila igre.

Magacinsko poslovanje je namenjeno magacioneru koji iskljuivo evidentira kartice robe ili materijala u magacinu. Vri se unos, auriranje i listanje osnovnih (matinih) podataka potrebnih za voenje magacinskog poslovanja, kao i svih ulazno/izlaznih promena. Mogue je definisati sve potrebne vrste ulazno/izlaznih dokumenata, a obezbeena je njihova kontrola i korekcija. U aplikaciji se vode kartice artikala i izrauju lager liste. Pretraivanje podataka se vri na vie naina: po ifri, po nazivu, po dobavljau. Izvetaji o prometu se rade po ulazno/izlaznim dokumentima i danima.

Rad se sastoji od 5 glava i literature.

U prvoj glavi Uvod dat je opis funkcionisanja aplikacije Magacinskog Poslovanja.

Druga glava bavi se UML-om. U okviru nje objanjeno je ta je UML i koje su osnovne gradivne komponente.

Konkretan proces primene UML-a na primeru dva magacinska dokumenta: prijemnice i otpremnice dat je u treoj glavi: Magacinsko poslovanje jezikom UML-a.

Razvojem aplikacije bavi se etvrta glava koja opisuje nain implemenatacije aplikacije, razvo-jne alate, arhitekturu aplikacije.

U petoj glavi dat je zakljuak.

2 UML

2.1 ta je UML

Poveanjem kompleksnosti poslovnih procesa, raunarski sistemi za njihovo praenje i upravljanje svakim danom postaju sve kompleksniji. Oni esto obuhvataju vei broj raunara, razliite programe, velike mree raunara koji su na velikim udaljenostima, meusobno pove-zane baze i ogromne, ogromne koliine podataka. Postavlja se pitanje kako uspeno upravljati tako komplikovanim sistemima?

Klju je u dizajniranju procesa tako da ih klijenti, projektanti, programeri i svi drugi koji su ukljueni u priu razvoja programa lako mogu da razumeju. Upravo UML omoguava takav vid organizacije.

Ukoliko i dalje neko nije siguran u potrebu za kvalitetnim projektovanjem programa neka zamisli sledeu situaciju. Na primer: klijent odlazi u graevinsku kompaniju i trai da mu izgrade kuu od 2000 kvadratnih metara sa 5 soba i 2 kupatila i kae PONITE ODMAH. Kako vi budete gradili tako emo mi crtati plan. Naravno niko ne bi gradio kuu na ovaj nain. Meutim na alost ovakav vid razvoja programa je najei. Ba kao to bi klijent najpre otiao u arhitektonski biro i tamo napravio detaljan plan kue koju eli da izgradi, tako bi trebalo razvijati i programe. Jedan od tih naina je i UML.

UML je nastao 1997 kao metod za dizajn programa uz pomo dijagrama. Napravljen je od stanje najboljih strunjaka koji se bave objektno-orjentisanim projektovanjem. To je definitivno najznaajnija stvar koja se desila software-skoj industriji u poslednjih par godina. Svaka druga inenjerska disciplina ima svoj standardni metod voenja dokumentacije. Elektriari imaju eme, arhitekte i graevinari nacrte. Software-ska industrija sada ima svoj nain UML.

Neke od prednosti korienja UML-a:

Software-ski sistemi e biti profesionalno isprojektovani i dokumentovane pre nego to se pone sa kodiranjem. Na taj nain se unapred zna ta e se dobiti kao rezultat.

Kako je sistem prvo isprojektovan, korienje istog koda je veoma uestalo kao i njegova efikasnost, samim tim se smanjuje cena programiranja.

Logike rupe i problemi su primeeni ve u fazi projektovanja. Smanjuje se broj iznenaenja prilikom programiranja.

UML omoguava da se vidi celokupna slika sistema,

Kada je potrebno napraviti modifikacije sistema, to je izuzetno jednostavno uraditi jer je ceo sistem dokumentovan. Nema potreba za dugotrajnim pretraivanjem koda i razmiljanjem zato je to tako uraeno. Samim tim se znaajno smanjuju trokovi odravanja.

Ukoliko se javi potreba za zamenom programera ili uvoenjem novih, UML crtei e mu omoguiti bre ukljuivanje u sistem.

Ukoliko se javi potreba za komunikacijom sa treim osobama u vezi projekta, zahvaljui UML dokumentaciji to e biti puno bre i efikasnije.

U jednoj reenici: Korienje UML-a dovodi do smanjena trokova, stvaranja boljeg i efikasnijeg software-a i poboljanja odnosa izmeu svih strana koje uestvuju u procesu.

2.2 Modeliranje sistema Novi vs. Stari nain

Proces razvoja sistema ukljuuje veliki broj ljudi. Najpre klijente, osoba koja ima problem koji treba reiti. Projektanta koji vri projektovanje i programera koji na osnovu dokumentacije razvija software koji e reiti problem kupca. Neophodnost uestvovanja vie ljudi u razreenju problema, prouzrokovana je kompleksnou dananjih sistema. Znanje se mora specijalizovati, jedna osoba ne moe da zna sve injenice vezane za poslovanje, da razume problem, projektuje reenje, programira program.

Slika 2.2.1: Waterfall metoda razvoja programa

Stari nain projektovanja, poznat kao Waterfall, obuhvata sledee faze koje se izvravaju jedna za drugom (Slika 2.2.1):analizu, projektovanje, programiranje i razvoj. Samo kada je prethodna faza kompletirana moe se poeti sa sledeom. Ako analitiar zavri i preda projekat projektantu koji kada zavri preda programeru, male su anse da ova tri uesnika tima rade zajedno i razmenjuju bitne informacije.

Novi nain projektovanja UML, zahteva konstantnu povezanost izmeu uesnika u svim fazama projekta. Analitiar i projektant unapred postavlju solidnu bazu za programera. Sa druge strane programer deli svoja zapaanja sa analitiarom i projektantom, zajedno menjaju projekat, ojaavaju kod. Kao rezultat poveava se meusobno razumevanje, tim ugrauje nove ideje i gradi jai sistem.

2.3 UML komponente

UML se sastoji od nekoliko grafikih elemenata koji zajedno ine dijagrame. Zbog toga to je jezik, UML ima odreena pravila za kombinovanje tih elemenata. Svrha dijagrama je prezentacija viestrukih pogleda na sistem. Skup tih viestrukih pogleda se naziva model. Zadatak modela je da opie emu sistem slui. On ne govori kako implementirati sistem [4].

UML se sastoji od 8 bazinih dijagrama:

1. Class dijagram

2. Use Case dijagram

3. State dijagram

4. Sequence dijagram

5. Activity dijagram

6. Collaboration dijagram

7. Componenet dijagram

8. Deployment dijagram

Projektovanje programa je aktivnost oveka. Bez jasnog razumevanja sistema, proces je podlean velikom broju potencijalnih greaka. Insistirajui na jasnom setu dijagrama, UML prua standard koji omoguava analitiarima da izgrade sliku koja e biti jasna klijentima, programerima i svim drugim uesnicima u procesu razvoja. Neophodno je u projektu imati sve nabrojane dijagrame zbog toga to svaki od njih na svoj nain opisuje drugi pogled na sistem.

U nastavku e svaki od nabrojanih dijagram biti detaljnije objanjen.

2.3.1 Class dijagram

Stvari se prirodno svrstavaju u kategorije (raunari, automobili, drvee...). Te kategorije ustvari predstavljaju klase. Dakle klasa je kategorija ili grupa stvari koje imaju sline osobine i ponaanja. Klas dijagram predstavlja pogled na sistem koji najvie koriste programeri. UML klasni dijagram se najee sastoji od nekoliko klasa povezanih meusobno relacijama. Sama klasa na dijagramu je predstavljena uz pomo pravougaonika [5]. U gornjem delu pravougaonika se nalazi ime klase, koje po notaciji je napisano malim slovima izuzev poetnih slova rei koje su predstavljene velikim slovom (Slika 2.3.1.1).

Slika 2.3.1.1: Pravougaonikom se reprezentuje klasa

Sastavni deo klase su i atributi. Atribut je svojstvo klase koje opisuje skup vrednosti koje to svojstvo moe da ima. Klasa moe da ima 0 ili vie atributa u sebi. Pravilo imenovanja atributa je isto kao i kod klasa, sve malim slovima izuzev poetnih slova u rei. Lista atributa se nalazi ispod imena klase od koga je odvojena horizontalnom linijom. Pored samog imena atributa u dijagramu moe se navesti kog je tipa atribut i koja je njegova inicijalna vrednost (Slika 2.3.1.2).

Slika 2.3.1.2: Klasa sa dva atributa

Pored atributa klasa se moe sastojati i od operacija. Operacija je neto to klasa moe da uradi ili neto to joj mogue uraditi nad njom. I kod operacija se primenjuje ista notacija imenovanja. Ispod liste nabrojanih atributa, odvojeno horizontalnom linijom, nalazi se lista operacija. Pored imena operacije, se mogu jo opisati parametrima (nabrajajui ih unutar zagrada iza imena klase) koje operacija koristi i tipom povratne vrednosti kao rezultat rada klase (Slika 2.3.1.3).

Slika 2.3.1.3: Klasa sa listom operacija

Prilikom razgovora sa klijentima, treba obratiti panju na imenice koje koriste da bi opisali elemente svog posla. Te imenice e u fazi projektovanja postati klase. Takoe treba obratiti panju na glagole i prideve vezane za te imenice, oni e u buduem modelu postati operacije i atributi.

Kao to je napomenuto na poetku ovog dela, sastavni deo Class dijagrama su klase koje su meusobno u relaciji, postoji nekoliko vidova relacija:

Associations. Kada su dve klase konceptualno vezane jedna za drugu, takav vid veze se naziva asocijacija. Na UML dijagramima asocijacija se predstavlja linijom izmeu dve klase, sa nazivom asocijacije na vrhu (Slika 2.3.1.4). Kada je jedna klasa asocirana sa drugom, svaka od njih ima neku ulogu. Nazivi tih uloga mogu biti napisani pored imena klase koja igra tu ulogu.

Slika 2.3.1.4. Primer asocijacije

Asocijacija kao tip veze moe biti kompleksnija ukljuivanjem vie od dve klase u relaciju. Ponekad veza izmeu dve klase mora biti ispraena nekim pravilom. To pravilo se najee stavlja dodavanjem ogranienja pored linije koja predstavlja vezu klasa (Slika 2.3.1.5).

Slika 2.3.1.5: primer sloenije asocijacije

Specijalan vid asocijacije je Multiplicity koja pokazuje broj objekata jedne klase koji su u relaciji sa odreenim brojem elemenata u drugoj klasi. Jedna klasa moe biti u relaciji sa drugom:

Jedan prema jedan 1..1

Jedan prema vie 1..n

Jedan prema jedan ili vie 1..1,n

Jedan prema nula ili jedan 1..0,1

Jedan prema odreeni interval 1..1-100

Jedan prema tano odreenom setu mogunosti (jedan prema 5 ili 8)

Nasleivanje i Generalizacija. Jedna klasa (izvedena klasa) moe naslediti atribute i operacije od druge klase. Ta druga- roditeljska klasa je optija od izvedene. Postojanje izvedene klase zavisi od postojanja glavne, ukoliko glavna postoji postoji i izvedena, obrnuto ne vai. U UML notaciji nasleivanje se obeleava linijom koja ide od roditeljske klase do izvedene, kod roditeljske klase se nalazi prazan trougao (Slika 2.3.1.6).

Slika 2.3.1.6: Primer nasleivanja.

Agregacija. Ponekad se klasa sastoji od nekoliko komponenti klasa. Ovaj specifini tip relacije je agregacija. Agregacija se predstavlja kao hijerarhija na ijem vrhu se nalazi klasa, a ispod nje komponente. Linija koja spaja komponente sa klasom ima u sebi prazan dijamant (Slika 2.3.1.7.).

Slika 2.3.1.7: Agregacija

Veoma esto prilikom identifikovanja klasa dolazi se do sluaja, da neke klase nisu vezane za nadreenu klasu ali njihovo ponaanje moe biti opisano sa istim operacijama. Tada je mogue ponaanje implementirati samo za jednu od klasa i koristiti ga za sve ostale klase uz pomo Interfejsa. Interfejs predstavlja skup operacija koje specificiraju neki aspekt ponaanja klase. U UML notaciji interfejs se obeleava slino kao klasa, u obliku pravougaonika, ali on nema atribute samo operacije. Da bi se razdvojio interfejs od klase obino se pre imena stavlja stereotip (Slika 2.3.1.8).

Slika 2.3.1.8: Interface

2.3.2 Use Case dijagram

Use Case dijagram predstavlja opis ponaanja sistema kako ga korisnik vidi, za razliku od prethodno opisanog klas dijagrama koji predstavlja statian pogled na klase Use Case dijagram pokazuje kako se sistem i njegove klase menjaju tokom vremena. Kako je klas dijagram odlina stvar da stimulie klijenta da govori o sistemu sa njegove ili njene take gledita, use case dijagram je odlina stvar da stimulie potencijalnog korisnika da govori sa njegove take gledita. Use case pomae da se razbije led.

Prvi razgovori sa klijentima obino se zavravaju sa identifikovanjem uesnika i pravljenjem grubih use case-ova. Tek kasniji razgovori omoguavaju opisivanje sistema detaljnije i veoma esto proizvode nove use case-ove.

Sam use case predstavlja kolekciju scenarija o korienju sistema. Svaki scenario predstavlja sekvencu dogaaja. Svaka sekvenca se inicira od strane korisnika, drugog sistema, dela hardware-a ili prolaska vremena. Entitet koji inicira sekvencu se nazva actor. Rezultat sekvence mora biti neto to e biti korisno ili actor-u koji je pokrenu ili nekom drugom.

U samoj notaciji UML-a use case se predstavlja uz pomo elipse, dok se actor-i predstavljaju uz pomo ia-Glia. Sa leve strane se nalazi actor koji inicira, a sa desne strane onaj koji prima rezultate. Obino se ispod slike actor-a navodi njegovo ime. Samo ime use case-a se upisuje u samu elipsu ili ispod nje. Linija koja povezuje actor-a sa elipsom predstavlja komunikaciju izmeu njih (Slika 2.3.2.1).

Slika 2.3.2.1: Primer use case-a

Use case je mogue ponovo iskoristiti. Postoj dva naina za to (Slika 2.3.2.2):

inclusion, korienje koraka jednog use case-a kao deo koraka u nekom drugom use case-u. Da bi se predstavio inclusion koristi se ista notacija kao kod predstavljanja zavisnosti izmeu klasa, isprekidana linija sa strelicom na vrhu koja je uperena na zavisnu klasu. Samo je potrebno iznad linije dodati stereotip .

extension, kreiranje novog use case-a dodavanjem koraka iz drugog use case-a. Isti nain notacije kao i kod inclusion samo se iznad linije dodaje stereotip .

Slika 2.3.2.2: Primer include i extended

2.3.3 State dijagram

Karakteristika sistema je da menjaju ponaanje tokom vremena. Kako dolazi do meusobne interakcije sistema sa korisnikom, a mogue i sa drugim sistemom, objekti koji ine sistem doivljavaju neophodne promene kao bi se prilagodili interakciji. Ukoliko neko eli da modeluje sistem, mora imati mehanizme koji e pratiti promene sistema. Taj mehanizam u UML-u se zove State dijagram.

UML State dijagram predstavlja stanja u kojima objekat moe da bude tokom tranzicije iz jednog u drugo stanje i prikazuje poetnu taku i krajnju taku sekvence koja menja stanje. Bitno je napomenuti da State dijagram prati stanje samo jednog objekta.

Stanja u State dijagramu se predstavljaju sa zaobljenim pravougaonikom, tok simbol transakcije stanja punom linijom sa strelicom. Punim krugom se predstavlja poetna taka, dok sa krugom sa takom u sredini krajnja (Slika 2.3.3.1).

Slika 2.3.3.1: Stanja u State dijagramu

Sam zaobljeni pravougaonik se stoji od tri dela (Slika 2.3.3.2). U gornjem se nalazi naziv stanja (ovaj podatak obavezno mora biti unet) u sredini se nalazi podatak o stanju promenjive, dok je u donjem delu informacija o aktivnosti. Aktivnosti moe imati tri opisa: entry- ta se deava kada sistem ulazi u stanje, exit- ta se deava kada sistem napusti stanje, do- ta se deava sa sistemom kada je u stanju.

Slika 2.3.3.2: Prikaza stanja na primeru pravljenja tosta

Nekada su stanja u kojima se nalazi sistem previe komplikovana da bi bila predstavljena sa zaokruenim pravougaonikom. Takva stanja obino se predstavljaju stanjima u stanju, ta stanja koja se nalaze unutar drugih se nazivaju se podstanja (Slika 2.3.3.3).

Slika 2.3.3.3: Primer stanja sa pod stanjem

2.3.4 Sequence dijagram

U prethodnoj taki bio je objanjen State dijagram koji se fokusira na stanja objekata. Meutim pored stanja neophodno je pratiti i komunikaciju izmeu objekata. U UML se za to koriste sekvencni dijagrami, koji prikazuju komunikaciju izmeu objekata tokom vremena. Kljuna ideja je stavljanje interakcija, koje se odvijaju izmeu objekata, u specifine sekvence, koje obuhvataju vreme od poetka do kraja interakcije.

Sekvencni dijagrami se sastoje od 3 osnovna elementa:

Objekti- se predstavljaju na klasian nain u obliku pravougaonika. Oni se na dijagramu reaju sa desna na levo u redosled koji e uiniti da dijagram izgleda to jednostavnije. Iz svakog pravougaonika izlazi na dole isprekidana linija koja se zove ivotna linija objekta. Na te isprekidanim linije postavljaju se uski pravougaonici koji se zovu aktivatori. Aktivator predstavlja startovanje operacije koju objekat ima u sebi. Njegova duina zavisi od duine akcije (Slika 2.3.4.1).

2.3.4.1: Notacija za obeleavanje klase u sekvencnom dijagramu

Poruke. Poruka predstavlja komunikaciju izmeu objekata, Ona se u dijagramu stavlja izmeu ivotne linije prvog i drugog objekata. Objekat moe i sam sebi poslati poruku. Postoje tri razliita izgleda strelice u zavisnosti o tipa poruke (Slika 2.3.4.2).

Slika 2.3.4.2: Vrste poruka

Vreme. Sekvencni dijagram predstavlja vreme vertikalno. Vreme poinje od vrha dijagrama i tee ka dole. Poruka koja se nalazi vilje na dijagramu desila se ranije, nego poruka koja je blie dnu (Slika 2.3.4.3).

Slika 2.3.4.3: Primer sekvencnog dijagrama

Use case dijagram moe prikazivati samo jedan sluaj korienja (scenario), ili moe biti opti i ukljuivati sve sluajeve korienja. Tako i sekvencni dijagrami mogu biti pojedinani ili opti. Opti sekvencni dijagrami pruaju mogunost prikaza if uslova ili while ciklusa. U UML notaciji if uslov se obeleava sa kockastim zagradama, a zadovoljen While ciklus sa zvezdicom ispred kockaste zagrade (Slika 2.3.4.4).

Slika 2.3.4.4: Primer sekvencnog dijagrama sa uslovima

2.3.5 Collaboration dijagram

Kolaboracioni dijagram isto kao i sekvencni, pokazuje interakciju izmeu objekata, u obliku poruka koja putuju od jednog do drugog. Na prvi pogled se ini da sekvencni i kolaboracioni dijagram prikazuju istu stvar, da li je to zaista tako?

Sekvencni i kolaboracioni dijagram su vrlo slini. Njihova semantika je ista, prikazuju iste informacije i mogue je prevesti sekvencni u kolaboracioni i obrnuto. Meutim glavna razlika izmeu njih je u tome to je sekvencni prilagoen vremenskoj dimenziji a kolaboracioni prostornoj.U samoj notaciji UML-a poruke su predstavljene strelicama usmerenim od jednog ka drugom objektu. Tekst pored strelice pokazuje koja je poruka u pitanju. Ona obino predstavlja ta objekat koji prima poruku, treba da izvri. Pored teksta poruke se nalaze obino i redni brojevi koji odgovaraju redosledu sekvenci (Slika 2.3.5.1).

Slika 2.3.5.1: Primer kolaboracionog dijagrama

2.3.6 Activity dijagram

Dijagram aktivnosti najvie podsea slike algoritama. On se sastoji od koraka (zvanih aktivnosti), taaka odluke i grananja. Veoma je koristan za pokazivanje ta se deava u poslovnim procesima ili operacijama.

Pre svega dijagrami aktivnosti se prave da bi se lake shvatilo ta se deava tokom procesa. Oni na neki nain predstavljaju nadogradnju State dijagrama. Dijagrami stanja pokazuju stanja objekata i prezentuju aktivnosti strelicama. Dijagrami aktivnosti stavljaju akcenat na aktivnostima.

U UML notaciji svaka aktivnost se predstavlja sa elipsom. Tranzicija sa jedne na drugu aktivnost se predstavlja strelicom, dok na vrhu svakog dijagrama aktivnosti nalazi se pun krug (koji oznaava poetak), u dnu se nalazi prazan krug sa takom koji oznaava kraj (Slika 2.3.6.1)

Slika 2.3.6.1. ema dijagrama aktivnosti

Pored simbola za aktivnosti i strelica koje predstavljaju tranziciju sa jednog na drugi objekat, dijagram aktivnosti obuhvata jo sledee elemente:

Grananja. Grananje se prikazuje u obliku dijamanta, do koga dolazi strelica koja pokree grananje, a iz njega izlaze dve grane u zavisnosti da li je uslov ispunjen ili ne. Obino se na linijama koje izlaze iz dijamanta ispisuje vrednost uslova koji treba da ispuni grananje da bi tok podatak krenuo na tu stranu (Slika 2.3.6.2).

Slika 2.3.6.2: Prikaz grananja u dijagramu aktivnosti

Konkurentne putanje. Prilikom projektovanja aktivnosti veoma se esto deava da se neka aktivnost podeli na dva odvojena dela koja se izvravaju u isto vreme (konkurentno), da bi se na kraju izvrenja obe slile ponovo u jednu. To deljenje aktivnosti na dva dela se obeleava sa za-debljanom linijom u koju ulazi strelica iz poetne aktivnosti. Iz zadebljane linije izlaze dve stre-lice koje predstavljaju novonastale aktivnosti i opet se zavravaju u zadebljanoj liniji iz koje izlazi jedna strelica oznaavajui da je konkurentni rad zavren (Slika 2.3.6.3).

Slika 2.3.6.3: Konkurentno izvravanje aktivnosti

Signali. Tokom sekvence aktivacije, mogue je poslati signal. Kada se primi, signal prouzrokuje aktivnost. U UML notaciji simbol za slanje je signala je konveksni pentagon, a za primanje konkavan (Slika 2.3.6.4).

Slika 2.3.6.4: Notacija za primanje i slanje signala

2.3.7 Component dijagram

U prethodnim takama bili su prikazani dijagrami koji prikazuju konceptualne entitete. Sledee dve take e se baviti realnim entitetima: software-skim komponentama. Software-ske komponente su fiziki delovi sistema. Oni se nalaze u raunaru, ne u glavi projektanta [7].

Postavlja se pitanje kakva je veza izmeu komponente i klase? Klasa predstavlja apstrakciju seta atributa i operacija, sa druge strane komponentu treba posmatrati kao programsku implementaciju klase. Jedna komponenta moe biti implementacija vie klasa.

Komponente i njihove relacije se projektuju:

Da bi klijent mogao da vidi kako e izgledati struktura zavrenog sistema

Programeri dobijaju strukturu po kojoj mogu da rade

Osoba zaduena za pisanje tehnike dokumentacije i pomoi (Help-a) moe lake razumeti o emu pie

Olakava ponovno korienje istog koda

Kada se radi sa komponentama, neophodno je raditi i sa njihovim interfejsima. Interfejs je lice objekata za spoljni svet. Samo preko interfejsa drugi objekat moe pozivati opcije, koje su inae skrivene enkapsulacijom.

Interfejs je skup operacija koji specificira ponaanje klase, praktino skup operacija koje klasa predstavlja drugim klasama. Sa aspekta projektanta interfejs komponenti je isto to interfejs kod klasa. Mogue je zameniti jednu komponentu sa drugom ako ta druga komponenta koristi isti interfejs kao prethodna, isto tako mogue je ponovo iskoristiti komponentu ali za neki drugi proizvod. Prilikom projektovanja najee se susree sa tri tipa komponenti:

Razvojne komponente: one ine osnovu za sva dalja programiranja (DLL-ovi, JavaBeen ili ActiveX kontrole).

Izveden komponente: komponente koje se razvijaju na bazi razvojnih komponenti.

Izvrne komponente: koje nastaju kao rezultata rada sistema.

Dananji svet software-skog inenjerstva je zasnovan na timskom radu, svi uesnici u projektu moraju da rade sa razliitim komponentama. Te komponente mogu biti rezultat njihovog rada ili jednostavno deo paketa, kupljene komponente ili ak komponente koje dolaze uz operativni sistem. Zbog toga je veoma vano imati sliku, mesto na kome su pobrojane sve komponente i veze meu njima. Upravo je to zadatak dijagrama komponenti (Slika 2.3.7.1).

Slika 2.3.7.1 Primer dijagrama komponenti za muziki player

Sam dijagram komponenti sastoji se od komponenti, interfejsa i relacija. Osnovni deo dijagrama je komponenta koja se simbolizuje pravougaonikom sa dva dodatna pravougaonika sa leve strane (Slika 2.3.7.2). Ime komponente se upisuje u osnovnom pravougaoniku, a ukoliko je komponenta deo paketa, ime paketa se navodi u kockastim zagradama iznad imena komponente.

Slika 2.3.7.2: Notacija za komponentu

to se tie predstavljanja interfejsa i komponente iji je to interfejs to je mogue uraditi na dva naina: nacrtati interfejs u obliku pravougaonika sa svim pripadajuim informacijama o interfejsu i isprekidanom strelicom od komponente do interfejsa oznaiti vezu, ili prikazati interfejs u obliku kruia koji je punom linijom spojen sa pripadajuom komponentom (Slika 2.3.7.3).

Slika 2.3.7.3: Dva naina prikaza interfejsa i relacije sa komponentom

2.3.8 Deployment dijagram

Ovo je poslednji dijagram koji se koristi u UML. Njegov zadatak je da prikae fiziku arhitekturu raunarski zasnovanog sistem. Dakle sa UML dijagramom se kree od pojmova koji postoji samo u analizi, preko komponenti koje su deo programa, sve do hardware-a koji postoji u stvarnom svetu.

Hardware je izuzetno bitna stavka prilikom stvaranja nekog sistema, jer bez njega sistem nee imati na emu da se izvrava, zato je nacrt hardware-ske organizacije sistema bitan. Ba zbog toga UML nudi alat koji svojim simbolima kreira jasnu sliku kao okruenje treba da izgleda (Slika 2.3.8.1)

Slika 2.3.8.1: Dijagram razvoja: primer kunog raunara

Prilikom crtanja dijagram treba znati da je osnovni hardware element nod, generiko ime za bilo koji tip raunarskog resursa. Postoje dve vrste nodova:

Processor- nod koji moe da izvri komponentu

Device- nod koji ne moe da izvrava, on obino predstavlja interfejs koji je u nekoj vezi sa spoljnim svetom.

Sam nod se u UML notaciji se predstavlja kao kocka (2.3.8.2). Nod ima ime koje se uz pomo stereotipa obeleiti kom tipu pripada. Ako je nod deo paketa onda pre imena treba navesti kom paketu pripada. Linija koja se nalazi izmeu dva noda predstavlja konekciju.

Slika 2.3.8.2: Simbol za nod

3 MAGACINSKO POSLOVANJE JEZIKOM UML - aAplikacija magacinsko poslovanje ima zadatak da vodi evidenciju o svoj robi koja se nalazi u magacinima. U zavisnosti od robe koja se skladiti, mogua je potreba posebnih uslova skladitenja robe, to treba da bude primenjeno u samoj aplikaciji magacinskog poslovanja.

Prilikom analize potreba utvreno je da sistem magacinskog poslovanja treba da raspolae sledeim dokumentima:

Prijemnica, uz pomo koje se roba koju dostavlja dobavlja uvodi u sistem

Povratnica dobavljau

Interna otpremnica, dokument koji omoguava prenos robe iz jednog u drugi magacin

Interna prijemnica, dokument koji omoguava zaprimanje robe u magacin iz drugog magacina

Otpremnica u proizvodnju, ovim dokumentom roba se alje u proizvodnju

Prijemnica iz proizvodnje, koristi se magacinu gotovih proizvoda. Omoguava da roba iz proizvodnje, pree u magacin gotovih proizvoda

Otpremnica kupcu, ovim dokumentom se artikli otpremaju kupcu

Povratnica od kupca, omoguava povratak robe od kupca i njen prijem u odgovarajui magacin

Otpremnica u maloprodaju, dokument koji skida robu sa stanja magacina i tom koliinom tereti maloprodaju

Povratnica iz maloprodaje, prijem robe iz maloprodaje

Sluaj korienja: Prijemnica

Na slici 3.1.1 data je sluaj korienja: Prijemnica. Sam sluaj se sastoji od tri sluaja korienja:

Unos prijemnice

Auriranje prijemnice

Brisanje prijemnice

Slika 3.1.1: Sluaj korienja: Prijemnica

3.1.1 Unos prijemnice

Ovaj sluaj korienja predstavlja postupak uvoenja robe koja je stigla od dobavljaa u sistem, konkretno u prijemni magacin. Prijemnica predstavlja prvi korak, jednostavno ono to se ne nalazi na prijemnici ne nalazi se u sistemu.

Osnovni tok:

1. Korisnik startuje formu: Prijemnica, izborom odgovarajue opcije u glavnom programu. Forma koja se otvora ima omoguene samo dve opcije: dugme Novi i dugme Uitaj. Klikom na dugme Novi forma se prebacuje u reim novog sloga i automatski se puni sa trenutno ulogovanim magacinom, tipom i brojem dokumenta.

2. Korisnik unosi datum dokumenta, inicijalno u tom polju se nalazi upisan datum poslednjeg dokumenta.

3. Sledei korak je izbor dobavljaa klikom na dugme: Izbor Dobavljaa, otvara se odgovarajua forma (extend (Izbor Dobavljaa)). Korisnik bira eljenog dobavljaa i vraa se u program, sistem puni polje Dobavlja izabranim dobavljaem.

4. Korisnik prelazi na donji deo forme koje je predstavljena gridom. Klikom na dugme + polja za unos koliine i robe postaju dostupna. Najpre se bira roba klikom na dugme: Izbor Robe. Otvara se odgovarajua forma (extend (Izbor Robe)) gde korisnik bira eljenu robu i vraa se nazad na glavnu formu.

5. U polje Koliina unosi se pristigla koliina, a sistem proverava da li je uneti broj vei od nule.

6. Korisnik i sistem izvravaju korake 4 i 5 sve dok ima ne unete robe.

7. Klikom na dugme Snimi, korisnik daje zahtev da se podaci snime, a sistem proverava da li su uneti podaci u redu i sputa podatke u bazu.

Alternativni tok Nekorektan datum

1. Korisnik u polje: Datum Dokumenta, unosi pogrean datum. Pod pogrenim datumom podrazumeva se ili ne korektan format datuma ili datum koji je manji od datuma poslednjeg proknjienog dokumenta tog tipa za ulogovani magacin. Sistem se vraa na korak 2.

2. Polje Datum Dokumentaje prazno, ukoliko korisnik ostavi polje: Datum Dokumenta prazno, sistem e ispisati odgovarajuu poruku i vratiti korisnika na korak 2.Alternativni tok Polje dobavlja prazno

1. Polje Dobavlja je prazno, ukoliko korisnik ostavi polje: Dobavlja prazno, sistem e ispisati odgovarajuu poruku i vratiti korisnika na korak 3.

Alternativni tok Nekorektan izbor robe i koliine

1. Polje Roba je prazno, ukoliko korisnik ostavi polje: Roba prazno, sistem e ispisati odgovarajuu poruku i vratiti korisnika na korak 4.

2. Ukoliko korisnik unese u polje Koliina vrednost manju od 0, sistem e dati odgova-rajuu poruku i vratiti korisnika na korak 5.

Preduslovi

1. Korisnik mora biti ulogovan na sistem i imati pravo da startuje izabranu formu.3.1.1.1 Sekvencni dijagram- Unos prijemnice

Slika 3.1.1.1.1: Unos Prijemnice (Sequence Diagram)

3.1.1.2 Kolaboracioni dijagram- Unos prijemnice

Slika 3.1.1.2.1: Unos Prijemnice (Collaboration Diagram)

3.1.1.3 Dijagram Aktivnosti- Unos prijemnice

Slika 3.1.1.3.1: Unos Prijemnice (Activity Diagram)

3.1.2 Auriranje prijemnice

Ukoliko zbog bilo kog razloga je dolo do greke ili promene podataka prilikom unosa prijemnice potrebno je izvriti auriranje.

Osnovni tok:

1. Korisnik startuje formu Prijemnica, izborom odgovarajue opcije u glavnom programu. Forma koja se otvori ima omoguene samo dve opcije: dugme Novi i dugme Uitaj. Ovog puta korisnik bira dugme: Uitaj dokument. Klikom na dugme otvara se nova forma gde korisnik moe da izabere eljeni dokument. Klikom na enter forma se zatvara, a sistem uitava podatke o unetom dokumentu.

2. Korisnik moe promeniti datum dokumenta, inicijalno u tom polju se nalazi originalni datum

3. U sledeem koraku mogue je promeniti dobavljaa klikom na dugme: Izbor Dobavljaa, otvara se odgovarajua forma (extend (Izbor Dobavljaa)). Korisnik bira eljenog dobavljaa i vraa se u program, sistem puni polje Dobavlja izabranim dobavljaem.

4. Korisnik prelazi na donji deo forme koje je predstavljena gridom. Klikom na dugme + polja za unos koliine i robe postaju dostupna. Najpre se bira roba klikom na dugme: Izbor robe. Otvara se odgovarajua forma (extend (Izbor Robe)) gde korisnik bira eljenu robu i vraa se nazad na glavnu formu.

5. U polje Koliina unosi se pristigla koliina, a sistem proverava da li je uneti broj vei od nule.

6. Klikom na dugme - vri se brisanje reda sa uitanim podacima o robi.

7. Korisnik i sistem izvravaju korake 4, 5, 6 sve dok je potrebno menjati podatke o robi

8. Klikom na dugme auriraj, korisnik daje zahtev da se podaci snime, sistem proverava da li su uneti podaci u redu i aurira postojei slog u bazi.


1. Korisnik u polje Datum Dokumenta, unosi pogrean datum. Pod pogrenim datumom se podrazumeva ili ne korektan format datuma ili datum koji je manji od datuma poslednjeg proknjienog dokumenta tog tipa za ulogovani magacin. Sistem ga vraa na korak 2.

2. Polje datum je prazno, ukoliko korisnik ostavi polje: Datum Dokumenta prazno, sistem e ispisati odgovarajuu poruku i vratiti korisnika na korak 2Alternativni tok Polje dobavlja prazno

1. Polje Dobavlja je prazno, ukoliko korisnik ostavi polje: Dobavlja prazno, sistem e ispisati odgovarajuu poruku i vratiti korisnika na korak 3.



2. Ukoliko korisnik unese u polje Koliina vrednost manju od 0, sistem e dati odgovarajuu poruku i vratiti korisnika na korak 5.

3. Ukoliko korisnik brie red sa robom koja je ve bila snimljena u bazu, sistem proverava da li se brisanjem stanje robe dovodi u minus i ukoliko se to desi sistem daje odgovarajuu poruku.

Preduslovi

1. Korisnik mora biti ulogovan na sistem i imati pravo da startuje izabranu formu.

3.1.2.1 Sekvencni dijagram- Auriranje prijemnice

Slika 3.1.2.1.1: Auriranje Prijemnice (Sequence Diagram)

3.1.2.2 Kolaboracioni dijagram- Auriranje prijemnice

Slika 3.1.2.2.1: Auriranje Prijemnice (Collaboration Diagram)

3.1.2.3 Dijagram aktivnosti- Auriranje prijemnice

Slika 3.1.2.3.1: Auriranje Prijemnice (Activity Diagram)

3.1.3 Brisanje prijemnice

Sluaj korienja: Brisanje prijemnice, opisuje ponaanje sistema ukoliko doe do potrebe za ponitavanjem odnosno brisanjem celokupnog dokumenta.

Osnovni tok:

1. Korisnik startuje formu Prijemnica, izborom odgovarajue opcije u glavnom programu. Forma koja se otvori ima omoguene samo dve opcije: dugme Novi i dugme Uitaj. Ovog puta korisnik bira dugme: Uitaj dokument. Klikom na dugme uitaj, otvara se nova forma gde korisnik moe da izabere eljeni dokument. Klikom na enter forma se zatvara, a sistem uitava podatke o unetom dokumentu.

2. Klikom na dugme Obrii, korisnik daje zahtev da se podaci obriu, sistem proverava mogunost brisanja i brie postojei slog u bazi.

Alternativni tok Dokument je proknjien

1. Sistem proverava da li je izabrani dokument ve proknjien na finansijskom nivou i ukoliko jeste daje odgovarajuu poruku.

Alternativni tok Koliina robe odlazi u minus

1. Ukoliko neka od roba koje se nalaze na izabranom dokumentu, prilikom brisanja dovode stanje robe u minus. Sistem zaustavlja brisanje i daje odgovarajuu poruku.

Preduslovi


3.1.3.1 Sekvencni dijagram- Brisanje prijemnice

Slika 3.1.3.1.1: Brisanje Prijemnice (Sequence Diagram)

3.1.3.2 Kolaboracioni dijagram- Brisanje prijemnice Slika 3.1.3.2.1: Brisanje Prijemnice (Collaboration Diagram)

3.1.3.3 Dijagram aktivnosti- Brisanje prijemnice

Slika 3.1.3.3: Brisanje Prijemnice (Activity Diagram)

3.1.4 Dijagram klasa- Prijemnica

Slika 3.1.4.1: Prijemnica (Class Diagram)

3.1.5 Dijagram Stanja

Slika 3.1.5.1: Prijemnica (State Diagram)

Sluaj korienja: Otpremnica u maloprodaju

Na slici 3.2.1 dat je sluaj korienja: Otpremnica u maloprodaju. Sam sluaj sastoji se od 3 sluaja korienja:

Unos otpremnice u maloprodaju

Auriranje otpremnice u maloprodaju

Brisanje otpremnice u maloprodaju

Slika 3.1.1: Sluaj korienja: Otpremnica u maloprodaju

3.1.6 Unos otpremnice u maloprodaju

Sluaj korienja: Unos otpremnice u maloprodaju opisuje rad sa sistemom kada je potrebno izabranu robu poslati u maloprodaju. Ovim postupkom se smanjuje stanje robe u magacinu, ali se poveava stanje robe u maloprodaji. Nakon slanja roba izlazi iz sistema i ne vri se njeno dalje praenje (barem ne aplikacijom magacinsko poslovanje).

Osnovni tok:

1. Korisnik startuje formu Otpremnica u Maloprodaju, izborom odgovarajue opcije u glavnom programu. Forma koja se otvori ima omoguene samo dve opcije: dugme Novi i dugme Uitaj. Klikom na dugme Novi forma se prebacuje u reim novog sloga i automatski se puni sa trenutno ulogovanim magacinom, tipom i brojem dokumenta.

2. Korisnik unosi datum dokumenta, inicijalno u tom polju se nalazi upisan datum poslednjeg dokumenta.

3. Sledei korak je izbor maloprodaje klikom na dugme: Izbor Maloprodaje, otvara se odgovarajua forma (extend (Izbor Maloprodaje)). Korisnik bira eljenu maloprodaju i vraa se u program, sistem puni polje Maloprodaja izabranom maloprodajom.


5. U polje Koliina unosi se koliina robe koja e se otpremiti u eljenu maloprodaju, a sistem proverava da li je uneti broj dovodi stanje u magacinu za izabranu robu u minus.

6. Korisnik i sistem izvravaju korake 4 i 5 sve dok se u formu ne unese sva potreban roba.

7. Klikom na dugme snimi, korisnik daje zahtev da se podaci snime, a sistem proverava da li su uneti podaci u redu i sputa podatke u bazu.


1. Korisnik u polje Datum dokumenta, unosi pogrean datum. Pod pogrenim datumom se podrazumeva ili ne korektan format datuma ili datum koji je manji od datuma poslednjeg proknjienog dokumenta tog tipa za ulogovani magacin. Sistem ga vraa na korak 2.

2. Polje Datum dokumenta je prazno, ukoliko korisnik ostavi polje: Datum dokumenta prazno, sistem e ispisati odgovarajuu poruku i vratiti korisnika na korak 2Alternativni tok Polje Maloprodaja je prazno

1. Polje Maloprodaja je prazno, ukoliko korisnik ostavi polje: Maloprodaja prazno, sistem e ispisati odgovarajuu poruku i vratiti korisnika na korak 3.



2. Ukoliko korisnik unese u polje Koliina, koliinu koja e eventualnim snimanjem otpremnice u bazu, dovesti stanje robe u minus sistem e dati odgovarajuu poruku i vratiti korisnika na korak 5.

Preduslovi


3.2.1.1 Sekvencni dijagram- Unos Otpremnice

Slika 3.2.1.1.1: Unos Otpremnice (Sequence Diagram)

3.2.1.2 Kolaboracioni dijagram- Unos Otpremnice

Slika 3.2.1.2.1: Unos Otpremnice (Collaboration Diagram)

3.2.1.3 Dijagram aktivnosti- Unos Otpremnice

Slika 3.2.1.3.1: Unos Otpremnice (Activity Diagram)

3.1.7 Auriranje otpremnice u maloprodaju

Ova opcija omoguava auriranje ve postojee otpremnice u maloprodaju, ukoliko je dolo do greke prilikom unosa podataka.

Osnovni tok:

1. Korisnik startuje formu Otpremnica u maloprodaju, izborom odgovarajue opcije u glavnom programu. Forma koja se otvori ima omoguene samo dve opcije: dugme Novi i dugme Uitaj. Ovog puta korisnik bira dugme: Uitaj dokument. Klikom na dugme uitaj, otvara se nova forma gde korisnik moe da izabere eljeni dokument. Klikom na enter forma se zatvara, a sistem uitava podatke o unetom dokumentu.

2. Korisnik moe promeniti datum dokumenta, inicijalno u tom polju se nalazi originalni datum

3. U sledeem koraku mogue je promeniti maloprodaju klikom na dugme: Izbor maloprodaje, otvara se odgovarajua forma (extend (Izbor Maloprodaje)). Korisnik bira eljenu maloprodaju i vraa se u program.


5. U polje Koliina unosi se koliina robe koju je potrebno otpremiti u maloprodaju

6. Klikom na dugme - vri se brisanje reda sa uitanim podacima o robi.

7. Korisnik i sistem izvravaju korake 4, 5, 6 sve dok je potrebno menjati podatke o robi

8. Klikom na dugme auriraj, korisnik daje zahtev da se podaci snime, sistem proverava da li su uneti podaci u redu i aurira postojei slog u bazi.


1. Korisnik u polje Datum dokumenta, unosi pogrean datum. Pod pogrenim datumom se podrazumeva ili ne korektan format datuma ili datum koji je manji od datuma poslednjeg proknjienog dokumenta tog tipa za ulogovani magacin. Sistem ga vraa na korak 2.

2. Polje Datum dokumentaje prazno, ukoliko korisnik ostavi polje: Datum dokumenta prazno, sistem e ispisati odgovarajuu poruku i vratiti korisnika na korak 2Alternativni tok Polje Maloprodaja prazno

1. Polje Maloprodaja je prazno, ukoliko korisnik ostavi polje: Maloprodaja prazno, sistem e ispisati odgovarajuu poruku i vratiti korisnika na korak 3.



2. Ukoliko korisnik unese u polje Koliina vrednost koja e dovesti stanje robe u magacinu ispod 0, sistem e dati odgovarajuu poruku i vratiti korisnika na korak 5.

Preduslovi


3.2.2.1 Sekvencni dijagram- Auriranje Otpremnice

Slika 3.2.2.1.1: Auriranje Otpremnice (Sequence Diagram)

3.2.2.2 Kolaboracioni dijagram- Auriranje Otpremnice

Slika 3.2.2.2.1: Auriranje Otpremnice (Collaboration Diagram)

3.2.2.3 Dijagram aktivnosti- Auriranje Otpremnice

Slika 3.2.2.3.1: Auriranje Otpremnice (Activity Diagram)

3.1.8 Brisanje otpremnice u maloprodaju

Ukoliko je potrebno u potpunosti ponititi Otpremnicu u Maloprodaju koristi se ovaj sluaj korienja.

Osnovni tok:

1. Korisnik startuje formu Otpremnica u maloprodaju, izborom odgovarajue opcije u glavnom programu. Forma koja se otvori ima omoguene samo dve opcije: dugme Novi i dugme Uitaj. Ovog puta korisnik bira dugme: Uitaj dokument. Klikom na dugme uitaj, otvara se nova forma gde korisnik moe da izabere eljeni dokument. Klikom na enter forma se zatvara, a sistem uitava podatke o unetom dokumentu.

2. Klikom na dugme Obrii, korisnik daje zahtev da se podaci obriu, sistem proverava mogunost brisanja i brie postojei slog u bazi.

Alternativni tok Dokument je proknjien

1. Sistem proverava da li je izabrani dokument ve proknjien na finansijskom nivou i ukoliko jeste daje odgovarajuu poruku.

Preduslovi


3.2.3.1 Sekvencni dijagram- Brisanje Otpremnice

Slika 3.2.3.1.1: Brisanje Otpremnice (Sequence Diagram)

3.2.3.2 Kolaboracioni dijagram- Brisanje Otpremnice

Slika 3.2.3.2.1: Brisanje Otpremnice (Collaboration Diagram)

3.2.3.3 Dijagram aktivnosti- Brisanje Otpremnice

Slika 3.2.3.3.1: Brisanje Otpremnice (Activity Diagram)

3.1.9 Dijagram klasa- Otpremnica

Slika 3.2.4.1: Otpremnica (Class Diagram)

3.2 Deployment dijagram

Slika 3.3.1: ematski prikaz mreeAplikacija Poslovanje Magacina je informacioni sistem koji vei deo rada zasniva na lokalnoj mrei, ali je poeljno da se komunikacija izmeu centara odvija preko WWW protokola. Na taj nain omogueno je korienje aplikacije od strane udaljenih klijenata preko Interneta. Na slici 3.4.1 nalazi se ematski prikaz mree, a na slici 3.4.2 dat je deployment dijagram.

Slika 3.3.2: Deployment Diagram

4 RAZVOJ APLIKACIJEInformacioni sistem magacinskog poslovanja razvijan je na savremen i modularan nain. Kao razvojni alat korien je Microsoft Visual Studio 2003 i programski jezik Visual Basic.NET (VB.NET). Baza podataka u koju se smetaju podaci je MS SQL server. Prilikom razvoja aplikacije akcenat je stavljen na brzinu rad, optimizaciju koda i stabilnost. Veliki broj radnih sati je utroen na testiranje kako pojedinanih modula tako i celog sistema.

Razvojni alati

4.1.1 Microsoft Visual Studio 2003

Visual Studio .NET je u potpunosti integrisano razvojno okruenje. Dizajnirano je tako da pisanje koda, ispravljanje greaka i kompajliranje u gotove sklopove bude to jednostavnije. Ovo u praksi znai da Visual Studio .NET daje jako sofisticiranu aplikaciju sa razliitim interfejsima dokumenata u kojim se moe uraditi sve to je povezano sa razvojem koda. Visual Studio .NET nudi [13]:

Program za editovanje koda kojima se moe pisati kako VB.NET tako i C# i C++ kod. Editor je veoma sofisticiran koji je upoznat sa sintaksom koda u kojem se pie aplikacija. To znai kako programer kuca kod editor ureuje: uvlai linije, boji kljune rei, povlai sintaksne greke. Takoe poseduje i IntelliSense: kako se kuca kod prikazuju se imena klasa, polja i metoda (Slika 5.1.1.1).

Slika 5.1.1.1: IntelliSense u akciji

Editor dizajna omoguava u projektu vizuelno stavljanje kontrola i podeavanje svojstava. Visual Studio .NET automatski dodaje kod u izvorne datoteke za instanciranje dodatih kontrola i promenu vrednosti svojstva.

Kompajliranje iz okruenja umesto pokretanja kompajlera iz komandne linije, dovoljno je pozvati odgovarajuu komandu iz menija Visual Studio .NET-a. Kompajleru e biti prosleeni svi relevantni parametre ukljuujui koje sklopove treba referencirati i koje tipove sklopova treba ukljuiti.

Integrisana MSDN pomo - Visual Studio .NET omoguava pozivanje odgovarajueg MSDN dokumenta pritiskom na dugme F1. Ukoliko se kursor nalazi na nekoj kljunoj rei u prozoru za pomo bie prikazani svi relevantni podaci.

Prilikom razvoja projekta Informacioni sistem magacinskog poslovanja korien je Visual Basic. NET (VB.NET) programski jezik. VB.NET praktino osim sintakse nema mnogo dodirnih taaka sa svojim prethodnikom Visual Basic-om 6.0 koji se ne moe ni kompajlirati kao VB.NET kod. Praktino on se moe smatrati potpuno novim jezikom.

VB.NET je jezik koji ima dve posebno znaajne strane:

Re je o programskom jeziku koji je zamiljene i napravljen za korienje u Microsoft-ovo radnom okviru . NET Framework-a.

To je jezik koji se bazira na modernoj objektnoj orjentisanoj tehnologiji.

Vano je napomenuti da je VB.NET poseban programski jezik. Iako je napravljen da generie kod koji je usmeren u .NET okruenju VB.NET nije njegov integralni deo. Postoje neke funkcije koje radni okvir .NET podrava, a programski jezik VB.NET ne podrava. Radni okvir .NET je razvijen sa ciljem da obezbedi okruenje iz koga se moe programirati bilo kakva aplikacija namenjena operativnom sistemu Windows (mada su se pojavili i projekti kao to je Mono koji omoguavaju izvravanje .NET aplikacija i pod Linux-om)

Slika 5.1.1.2 Arhitektura Frameworka

Centralni deo radnog okvira .NET-a predstavlja njegovo izvrno okruenje koje se naziva Common Language Runtime (CLR) ili .NET Runtime (Slika 5.1.1.2). Za kod koji se izvrava pod kontrolom CLR komponente se esto naziva kontrolisani (managed) kod [14].

.NET sledi logiku JAVA programskog jezika koji koristi virtuelnu mainu. Ekvivalent Virtuelnoj maini je upravo CLR. Meutim da bi se neki kod izvravao pod CLR-om neophodno je da izvorni kod proe kroz dve etape:

Kompajliranje izvornog koda u Microsoft Intermediate Language (MS-IL).

Kompajliranje IL koda u konkretan platformski kod koji izvrava komponenta CLR.

Dvostruko kompajliranje koda na prvi pogled je bezrazlono, meutim upravo ovo omoguava brojne prednosti:

Nezavisnost u pogledu platforme. Datoteka koja sadri instrukcije bajkoda moe se koristiti na bilo kojoj platformi jer se poslednja faza kompajliranja vri prilikom izvravanja aplikacije. Drugim reima kompajliranjem u IL u radnom okviru .NET-u dobijena je nezavisnost u pogledu platforme na isti nain na koji kompajliranje Java bajtkoda omoguava platformska nezavisnost programskog jezika Java.

Poboljanje performansi. Iako se .NET okvir moe porediti sa programskim jezikom Java, meu jezik IL je efikasniji jer on uvek kompajlira u pravo vreme (Just- in-Time, JIT) dok se Java bajtkod uvek interpretira. Na taj nain kod IL ne postoji gubitak performansi. Pored toga umesto cela aplikacija kompajlira odjedanput (to bi prouzrokovalo jo slabiji odziv), JIT kompajler svaki deo koda kompajlira onda koda se taj deo poziva.

Jezika interoperabilnost. Pored platformske nezavisnosti, IL omoguava i jeziku. Jednostavno reeno, projekat bilo pisan u VB.NET-u kompajlira se uvek u meu jezik IL. Tako dobijen kod je u potpunosti interoperabilan sa kodom koji je izvorno bio napisan bili u C# ili u C++.

4.1.2 Microsoft SQL Server 2000

Dananje poslovanje zahteva savremeno reenje za rad sa bazama podataka. Performanse i mogunost proirenja i nadogradnje su naravno osnova sistema. Ipak, pravi znaaj dolazi sa mogunou da se analizom sirovih podataka dobiju strateke odluke u voenju posla i u potpunosti iskoriste prednosti koje daje elektronska trgovina. Tu mogunost daje Microsoft SQL Server 2000 koji objedinjuje u jednom paketu bazu podataka i alate za analizu. Ovaj sistem otvara vrata brzom razvoju aplikacija nove generacije koje funkcioniu na nivou velikih poslovnih sistema. Nosilac vanih rekorda merenja u oblasti skalabilnosti i brzine, SQL Server 2000 je baza podataka u potpunosti prilagoena poslovanju preko Weba kojoj je pridodata snana podrka za XML i mogunost obavljanja upita preko Interneta izvan granica koje postavlja Firewall zatita (Slika 5.1.2.1) [15].

Slika 5.1.2.1: Microsoft SQL Server4.2 Arhitektura aplikacije

Informacioni sistem magacinskog poslovanja je meavina Windows i Web aplikacije. Akcenat je stavljen na Windows deo, odnosno Windows forme u kojim se obavlja vei deo manipulacije podataka, dok deo koji se ine Web forme slui za pregled stanja po magacinima i mesene analize. Na ovaj nain je omoguena brza manipulacija podacima, korienje barkod itaa prilikom unosa podataka, a sa druge strane mogunost sagledavanja podataka sa bilo koje take na svetu.

Dvostruki prezentacioni sloj je zahtevao specifinu arhitekturu aplikacije. Na samom poetku doneta je odluka da se i Windows i Web deo programira zajedno kao jedna aplikacija, odnosno da se koriste iste metode. Pored toga trebalo je omoguiti da aplikacija radi sa razliitim bazama podataka. Inicijalno to je MS SQL server, ali u zavisnosti od obima poslovanja u budunosti to moe biti i Oracle. Pored toga baza se nalazi samo na jednom server u okviru samo jednog distribuiranog centra.

Slika 5.2.1: Arhitektura Aplikacije

Kako bi aplikacija uspeno odgovorila na sve postvaljenje zahteve, bilo je neophodno jasno identifikovati i podeliti slojeve (Slika 5.2.1). Informacioni sistem magacinskog poslovanja se sastoji od sledeih slojeva:

Prezentacioni

Business

Brokeri

Baza podatka

4.2.1 Prezentacioni sloj

Prezentacioni sloj je okrenut korisnicima, to je deo aplikacije koji slui za komunikaciju sa korisnicima i praktino jedini deo koji se vidi sa korisnike strane. Aplikacija je raena u potpunoj filozofiji tankog klijenta, tako da se kao na Windows formama nalazi samo kod neophodan za manipulaciju kontrolama i za pozive validacija.

4.2.1.1 Forme

Windows Client projekat (u okviru koga se nalaze sve Windows forme) je glavni klijentski deo sistema, sadri korisniki interfejs koji preko Web servisa vri interakciju sa serverskim delom sistema i sa njim ini kompletan sistem. Korisniki interfejs je namenjen familiji Windows operativnih sistema, a radi to manjeg optereenja klijenta i lake implementacije za ostale platforme namenjeno je da sadri samo osnovnu funkcionalnost potrebnu za funkcionisanje logike korisnikog interfejsa (Listing 5.2.1.1.1). Tako bi se gotovo sve funkcije vezane za funkcionisanje poslovne logike sistema nalazile na serveru, to bi olakalo isporuku i odravanje sistema kao i znaajnu nezavisnost klijenta od servera (decoupling, decoupled) to olakava implementaciju klijenata za druge platforme. Pored toga ovaj projekat sadri osnovna podeavanja vezana za klijentski deo sistema, klase raznih namena, kao i centralizaciju pristupa Web servisu.

Private Sub VRadnik_JMBG (ByVal sender As System.Object, ByVal e As System.EventArgs) Handles txtRadnik_JMBG.Validated

Dim V As ClientServices.PPWebService.ValidationResult

V = WebService.Radnik_VJmbg (Me.dsMain, SecurityInfo)

If Not V.Success Then

Msg.Show(V.Messages(0).MessageText, V.Messages(0).MessageType

End If

End Sub

Lisitng 4.2.1.1.1 Primer poziva validacije na klijentu

Pored skupa klase koje predstavljaju same forme (prijemnicu, otpremnicu...) ovaj projekat se sastoji od nekoliko pomonih formi i klasa:

MainForm, glavna forma u aplikaciji

SplashForm, uvodna forma

LoginForm, forma za prijavu korisnika

MessageForm, forma za prikaz raznih poruka korisniku

Msg, klasa koja sadri funkcije za jednostavan poziv i prikaz MessageForme

AssemblyResources, klasa koja izvlai stringove i druge objekte iz resursa za trenutni jezik.

MenuTreeBuilder, klasa koja generie osnovni meni.

Login, klasa za proveru prijave korisnika

SplashForm, uvodna forma

LoginForm, forma za prijavu korisnika

Settings, klasa koja sadri podeavanja koje se koriste u toku rada sistema, sama podeavanja se uvaju u .ini fajlu.

SystemCheck, klasa koja vri proveru konfiguracije korisnikog raunara

SystemInformation, klasa koja vri detekciju konfiguracije korisnikog raunara i uva podatke u svojim atributima

Na slikama 4.2.1.1.1 do 4.2.1.1.4 dati su primeri Windows formi.

Slika 4.2.1.1.1: Forma za unos Partnera

Slika 4.2.1.1.2: Forma za pregled Magacinske kartice

Slika 4.2.1.1.3: Forma za unos Otpremnice kupcu

Slika 4.2.1.1.4: Forma za unos grupni pregled dokumenata

4.2.2 Business Sloj

Biznis sloj je jezgro celog sistema. Sadri poslovne objekte i funkcije koje se koriste u razliitim delovima sistema. U njemu su implementirani sigurnosni mehanizmi, poslovna pravila i podeavanja vezana za serverski deo sistema. Implementacija svake funkcije kojoj pristupa klijent se nalazi u ovom modulu. Pored ovoga, ovde se nalazi logika pristupa podacima koji se trajno uvaju u bazi podataka i preko mehanizma kairanja optimizuju i ubrzavaju njihovo korienje kao i kontrola izvrenja funkcija koja trajno menjaju sistem.

Prilikom pravljenja poslovnog sloja ilo se logikom jedna tabela, jedna klasa. Dakle za svaku tabelu sistema postoji odgovarajui poslovni objekat koji sadri sve validacije, potpunu logiku. Ukoliko je potrebno izmeniti neko pravilo te izmene se vre samo na ovom sloju. Svaki od poslovnih objekata pristupa bazi podatak preko odgovarajueg brokera, koji je vezan za odreenu tabelu. Ukoliko je potrebno izvriti snimanje/auriranje/brisanje podataka iz vie tabela pod jednom transakcijom, startovanje i zavravanje transakcije se obavlja upravo u ovom sloju (Listing 4.2.3.1).Namespace Business

Public Class bizRadnik

#Region " Basic functions "

Function getRednike() As System.Data.DataSet

Dim Broker As Brokers.IbroRadnik

Broker = Brokers.BrokerFactory.GetBrokerRadnik

Return Broker.getRadnike()

End Function

Public Function SaveData(ByRef Data As System.Data.DataSet) As BISC.Validation.ValidationResult

Dim V As New BISC.Validation.ValidationResult

V = Me.validateALL(Data, boolUpdQE)

If Not V.Success Then

Return V

End If

Dim conn As Data.IDbConnection

Dim tran As Data.IDbTransaction

conn = Connections.ConnectionFactory.GetConnection

conn.Open()

Try

Dim Broker As Brokers.IbroRadnik

Broker = Brokers.BrokerFactory.GetBrokerRadnik

Broker.SaveData(Data.Tables("Radnik"), conn, tran)

tran.Commit()

conn.Close()

Catch ex As DataAccess.DataAccessExceptionBase

tran.Rollback()

conn.Close()

End Try

Return V

End Function

#Region "Validation"

Public Function validateALL(ByVal ds As DataSet) As BISC.Validation.ValidationResult

Dim V As BISC.Validation.ValidationResult

Dim TV As BISC.Validation.ValidationResult

V = New BISC.Validation.ValidationResult(True)

TV = Me.Validate_Ime(ds)

If Not TV.Success Then

V.Success = False

V.Messages.Add(TV.Messages.Item(I))

End If

TV = Me.Validate_JMBG(ds)

If Not TV.Success Then

V.Success = False

V.Messages.Add(TV.Messages.Item(I))

End If

Return V

End function

#End region

End class

Listnig 4.2.3.1: Primer Biznis objekta

Unutar poslovnog sloja pored odgovarajuih biznis objekata za svaku od tabela nalaze se jo sledee klase:

ClientLoginInfo, sadri atribute korisnika koji eli da se prijavi na sistem

ClientSecurityInfo, sadri podatke koje klijent mora poslati serveru da bi mogao da izvri bilo koju funkciju nad sistemom

SessionKey, javni klju koji se koristi u sigurnosnim mehanizmima

Settings, uva podeavanja vezana za sigurnost

4.2.3 Brokeri

Projekat brokeri ini skup klasa koje slue za komunikaciju sa bazom. Njihov zadatak je izvlaenje, unos, brisanje i auriranje podataka. Za svaku od tabela u bazi podataka postoji posebna klasa koja slui za rada upravo i samo sa njom. Prilikom odreivanje zadataka koje treba da ispuni aplikacija jedan od najbitnijih je bila nezavisnost od baze podatak. Sistem treba da ima mogunost rada sa bili kojom bazom uz to manje izmene. Ova modularnosti je postignu implementacijom osnovnih klasa koje slue za pristup DBMS-u (broker, konekcija, transakcija) i konkretnim klasama koje predstavljaju implementaciju pristupa za tano odreenu bazu. Na taj nain preko jedinstvenog interfejsa na osnovu parametra koji odreuje koja se baza koristi, poslovni objekat dobija konkretnu implementaciju brokera. Ova funkcionalnost je za sada implementirana za MS SQL Server, a ukoliko se pokae potreba bie implementirana i za druge baze.

Unutra brokera nalaze se tri grupe klasa. Prava implementira osnovne klase i interfejse za rad sa DBMS-om:

IDatabaseBroker, definie osnovni interfejs za brokera

IDatabaseConnection, interfejs za konekciju

IDatabaseTransaction, interfejs za transakciju

DataAccessExceptionBase, klasa za osnovnu greku koja se moe dogoditi u radu sa bazom

Environment, klasa koja izvlai podeavanja vezana za bazu podataka

BrokerFactoryBase, apstraktna klasa za generalizaciju konkretnih brokera

Druga grupa klasa implementira gore navedene klase za MS SQL bazu:

ISqlServerBroker, osnovni interfejs za brokera

SqlServerBrokerBase, apstraktna klasa osnovnog brokera

SqlServerConnectionService, klasa za rad sa konekcijama

Poslednju grupu ini skup klasa koje ini konkretne implementacije brokera za MS SQL server bazu i klasa BrokerFactory, klasa koja na osnovu podeavanja u sistemu instancira konkretnog brokera za konkretni DBMS (Slika 5.2.4.1).

4.2.4 Baza podataka

Informacioni sistem magacinskog poslovanja koristi MS SQL Server kao bazu podataka. Firma je Microsoft partner i aplikacija je raena u potpunosti u Microsoft-ovoj tehnologiji tako da je i MS SQL server bilo prirodno reenje za smetanje podatak. Meutim kako je ve u prethodnim takama navedeno, jedan od osnovnih zahteva je bila to vea nezavisnost aplikacije od konkretnog tipa baze, to je uslovilo potpuno premetanje logike upita sa baze na kod. Izuzev stored procedure-a (Listing 5.2.5.1) za unos, izmenu i brisanje podatak sve ostale nemaju svoju implementaciju na MS SQL serveru ve u kodu u odgovarajuem brokeru. Na ovaj nain dovoljno je implementirati broker (prilagoditi upite) za novi tip baze i aplikacija je spremna za rad na novoj bazi.

CREATE PROCEDURE updMESTO

( @KOD_ZEMLJE char(3),

@NAZIV varchar(50),

@OPIS text,

@PTT char(5),

@ORIGINAL_MESTO_ID int,

@ORIGINAL_KOD_ZEMLJE char(3),

@ORIGINAL_NAZIV varchar(50),

@ORIGINAL_PTT char(5),

@FORCE bit)

AS

IF @FORCE=1

BEGIN

UPDATE MESTO

SET

KOD_ZEMLJE=@KOD_ZEMLJE,

NAZIV=@NAZIV,

OPIS=@OPIS,

PTT=@PTT

WHERE

(MESTO_ID=@ORIGINAL_MESTO_ID)

END

ELSE

BEGIN

UPDATE MESTO

SET

KOD_ZEMLJE=@KOD_ZEMLJE,

NAZIV=@NAZIV,

OPIS=@OPIS,

PTT=@PTT

WHERE

(MESTO_ID=@ORIGINAL_MESTO_ID) AND

(KOD_ZEMLJE=@ORIGINAL_KOD_ZEMLJE OR KOD_ZEMLJE IS NULL AND @ORIGINAL_KOD_ZEMLJE IS NULL) AND

(NAZIV=@ORIGINAL_NAZIV OR NAZIV IS NULL AND @ORIGINAL_NAZIV IS NULL) AND

(PTT=@ORIGINAL_PTT)

END

RETURN

Listing 4.2.5.1 Primer stored procedure za auriranje tabele Mesto

5 DATA WAREHOUSING I OLAP

Skladitenje podataka ili Data Warehousing jeste proces integracije podataka u jedan repozitorijum iz kojeg krajnji korisnici mogu sprovoditi ad-hock analize podataka i praviti izvetaje. Zbog velike koliine podataka skladita podataka imaju tendenciju da postanu ogromna, to je uslovilo potrebu za visokim performansama hardverskog i softverskog obezbedjenja.

Glavni posao lei u analizi izvornih podataka i procesa, tj moraju se poznavati procesi za transakcionu obradu podataka, sa ciljem zapisivanja poslovnih pravila bez greaka.

Skladite podataka je baza podataka za procese podrke odluivanju u kojoj su podaci:

Subjektno orjentisani odslikavaju poslovne procese

Integrisani baza podataka konsoliduje podatke iz razliitih sistema koji koriste razne vrste razne vrste kodovanja, mernih jedinica i obezbedjuje konzistentnost podataka

Vremenski zavisni - svi podaci su u vezi sa nekim vremenskim trenutkom na osnovu kojeg se podaci mogu i porediti

Nepromenljivi podaci se dodaju ve postojeim podacima.5.1 DATAMART

Datamart je subjektivno orjentisani pogled na skladite podataka. On sadri znaajno manje podataka od skladita podataka i predstavlja objekt analitikog procesiranja od strane korisnika.

Datamartovi su subjektivno orjentisane multidimenzione baze podataka sa ivotnim ciklusom od tri godine. Mnogi datamartovi su podskup velikih skladita podataka.

Operator moe da koristi OLAP alate i napravi izvetaj od informacije iz jedne tabele u datamartu koristei bilo koju kolonu kao selekcioni kriteijum.

5.2 OLAP SISTEMI

Interaktivno analitiko procesiranje (on line analitical procesing - OLAP) namenjeno je on line analizama i izvetajima, za razliku od produkcionih sistema namenjenih auriranju podataka i obradi transakcija ( on line transaction procesing - OLTP). Donosiocima odluka su potrebni odgovori na pitanja koji direktno utiu na njihovu mogunost da budu kompetentni na dananjem brzo promenljivom tritu. U tu svrhu se koriste OLAP sistemi.

Osnovni elemnti OLAP sistema su: Baza podataka, koja slui kao osnova za anlizu

OLAP server, za upravljanje i manipulaciju podacima

Interfejs sistem, prema korisniku i prema drugim aplikacijama

Alati za administriranjeZa korienje OLAP sloene procedure potrebno je transakcione podatke prebaciti u posebnu bazu podataka. OLAP pristup mora od hardvera da poseduje poseban raunar, tzv. OLAP server, na koji se povezuju relacione baze podataka, eksterni izvori podtaka i ostali interni podaci, koji su podrani grafikim interfejsima.OLAP serveri koriste viedimenzionalne strukture za uvanje podataka i veza izmedju njih. Viedimenzionalne strukture se naljbolje vizuelizuju kao kocke podataka i kao kocke u kockamapodataka. Svaka strana kocke se naziva dimenzijom, svaka elija kocke sadri agregirane podatke koji su u vezi sa dimenzijom.

Postoje sledee arhitekture OLAP sistema:

Viedimenzionalani OLAP (MOLAP)

Relacioni OLAP (ROLAP)

Hibridni OLAP (HOLAP)

MOLAP i ROLAP se razlikuju po nainu fizikog uvanja podataka.

Viedimenzioni OLAP MOLAP baza podataka ima ograniene fizike veliine skupa podataka sa kojima mogu da barataju. Da bi se izvrila bilo kakkva analiza podataka moraju se prvo uitati podaci u viedimanzione strukture. Prednost MOLAP sistema je to obezbedjuje odline performanse sistema kada se radi sa ve sraunatim podacima.

Relacioni OLAP ROLAP sistemi pristupaju podacima direktno iz skladita podataka i rade sa relacionim bazama podataka. Ovi sistemi mogu da rade sa velikim skupovima podataka. im se odredi izvor podataka , korisnik moe zapoeti analizu. Kod ROLAP sistema nhe postoje ogranienja to se tie dimenzija sistema.Moda najbolje reenje predstavlja HOLAP, iji alati mogu pristupati i relacionim i viedimenzionim bazama podataka. Cilj korienja HOLAP alata jeste da se iskoriste prednosti MOLAP alata. Pri tome se ne moe rei da je HOLAP prosti zbir MOLAP-a i ROLAP-a. To je zapravo ROLAP koji ima mognost izvravanja vrlo sloenih SQL naredbi.Kreiranje OLAP kocni korienjem Cube Wizard-a integrisanog u Microsoft Query vri se na osnovu predhodno definisanih upita nad skladitem podataka.

U magacinskom poslovanju za kreiranje OLAP kocke koristiemo tabelu Stavka magacinskog dokumenta, a od kolona uzimamo Naziv robe, Ulaz, Izlaz i Stanje.

Proces kreiranje kocke se odvija koroz sledee korake:

1. Po strartovanju MS Query-a izabere se tip baze podataka (u ovom slualu SQL) i pronadje odgovarajua baza podataka. Izabere se tabela i kolone na osnovu kojih e se vriti kreiranje kocke.

2. Zatim i z menija odabiramo Create OLAP Cube

3. Ovo predstavlja prvi korak u formiranju OLAP kocke gde se odredjuju polja koja formiraju sumarne podatke i matematike operacije koje e se izvravati nad tim apoljima. Polja koja se ne koriste za sumarne podatke predstavljaju kandidate za dimenzije kocke.

4. U ovom koraku se vri formiranje hierarhije dimenzija. Hierarhija dimenzija treba da omogui vie nivoa detaljnosti, u zavisnosti od potreba korisnika.

5. Vrimo uvanje kocke (odabirom Save As iz menija).

Na osnovu ovako kreirane OLAP kocke vri se kreiranje pivot tabele za pristup podacima pomou Microsoft Exel-a.

Iz menija Data u Microsoft Exel-u biramo Import data, i otvaramo predhodno kreiranu OLAP kocku. Na osnovu ove kocke vri se formiranje pivot tabele.

Slika 5.1: Pivot tabela

Zatim se na osnovu formirane pivot tabele koja je prikazana na slici 5.1 vri kreiranje grafika, odnosno kreira se grafiki prikaz pivot tabele. Grafiki prikaz pivot tabele prikazan je na slici 5.2.

Slika 5.2: Grafiki prikaz pivot tabele

5.3 DATA MINING

Data mining je relativno nova tehnika analize podataka. Veoma je razliita od upita i izvetaja, kao i od viedimenzionih analiza, po tome to koristi tehniku otkrivanja. Za razliku od upita, izvetaja i viedimenzionih analiza gde je korisnik morao da kreira i izvrava upite, data mining trai odgovore na pitanja koja predhodno ne moraju biti postavljena.

Data mining se najtipinije koristi za statistike analize podataka i otkrivanje znanja.

Za prikaz Data Mining-a koristiemo SQL Server 2005. U integrisanom delu koji se naziva Bussines Intelligence Development Studio moemo koristiti Data Mining Wizard. U prvom koraku moramo da pokrenemo Analisis Services Project. Poto je projekat kreiran, potrebno je definisati Data Sorce, odnosno bazu na kojoj ce biti vezan projekat. U desnom delu ekrena se nalazi Solution Explorer preko koga mozemo izvriti ceo preojekat. Desnim klikom na Data Source pokreemo wizard preko koga se povezujemo na eljnu bazu podataka, potrebno je testirati konekciju kako bi bili sigurni da je uspostavljena veza. Zatim moramo kreirati Data Source View, tj. pogled na bazu podataka kako bi mogli a izvimo analizu. Wizard se pokree na identian nain kao i kod definisanja Data Sourca.

U Solution Exploreru moemo kreirati i tzv. kocke podataka na osnovu kojih se kasnije formira pivot tabela i grafik.

U Mining Structures meniju se pokree glavni wizard preko koga takodje moemo kreirati pivot tabelu i grafik. Kreiranje Mining Modela se sastoji iz nekoliko koraka, i to:

1. Desni klik na Mining Model u Solution Exploreru i biramo opciju New Mining Model.

2. Stranu na kojoj je dat opis moemo da preskoimo tako to emo kliknuti na Next.

3. Na strani Select the Data Mining Technique, moemo videti listu aktivnih algoritama preko kojih emo se konektovati na server. Biramo Microsoft Decision Trees algoritam.

4. Na strani Specify Table Types page biramo tabelu iz koje nam trebaju podaci.5. Specify the Training Data strana odredjuje kolone nad kojima e se zasnivati izvetaji. Potrebno je na istoj strani definisati i jedinstveni klji koji je karakteristian za tabelu.

Slika 5.2: Lista kolona izabrane tabele6. Ostalo je jo da se navede ime modela, i Mining model je kreiran.

Na ekranu nam se prikazuje tabela za koju smo kreirali model i klikom na tabove iznad moemo videti grafik i pivot tabelu.6 VIZIJA

U savremenom poslovanju sve vie se koriste WWW protokoli, tj razvijaju se aplikacije koje su WEB orjentisane. Za budui razvoj aplikacije Magacinskog Poslovanja planira se dodatak koji e upravo biti zasnovan na WEB servisima. Osnovni razlog ove dodatne implementacije jeste povezivanje centara i korienje aplikacije od strane udaljenih klijenata preko Interneta. Na slici 6.1 se nalazi deployment dijagram.

Slika 6.1: Deployment Diagram

Povezivanje udaljenih korisnika e se omoguavati preko brze internet konekcije (ADSL ili Wireles)

Osnovni problem ovakvog naina poslovanja jeste zatita podataka. Protokoli za prenos su nastali u prijateljski nastrojenoj sredini, to je Internet odavno prestao da bude. Samim tim se razvijaju i brojne zatite koje omoguavaju sigurnosnu razmenu podataka na internetu. Najpoznatija zatita jeste SSL (Secure Socet Layer) poznata po ikonici katanca koja se pojavljuje u Browseru. 7 ZAKLJUAKPoslovni sistemi ve dui vremenski period su izuzetno sloeni. Poveanjem konkurencije, naputanjem granica zemlje i ciljanjem na globalni nivo svetsko trite, sistemi postaju razueni, distribuirani. Informacioni sistem koji ima zadatak da prati sve delatnosti sistema mora raditi na razliitim lokacijama, u razliitim platformama kako Web tako Windows, Linux, na razliitim tipovima baza. Pored toga sistem mora imati vie razliitih pogleda, sa jedne strane treba da omogui prost i brz unos podataka od strane radnika/prodavaca, a sa druge strane razliitim nivoima menadera treba da obezbedi mogunosti za sloene analize trita, predvianje poslovanja u buduem periodu i razliite ta-ako analize. Sve ovo iziskuje sloene i glomazne sisteme koje je izuzetno teko projektovati i pratiti. Na svu sreu UML tu moe puno pomoi.

UML se nametnuo kao standard za projektovanje software-skih reenja. Zahvaljujui bogatstvu jezika, mogue je pratiti razvoj projekta od apstraktne ideje analitiara, preko konkretnih klasa, aktivnosti pa sve do fizikog rasporeda raunara i mree. Pored toga zahvaljujui analizi smanjuje se vreme izrade (programiranja) proizvoda, veina problema se identifikuju i reavaju pre samog kodiranja, programeri na samom poetku imaju sliku kako koji deo treba da izgleda, a odravanje proizvoda i uvoenje novih ljudi u razvoj vie ne predstavlja nonu moru.

Ukoliko kod nekoga jo postoje nedoumice da li je u opte potrebno projektovanje, analiza pre samog proces programiranja neka se samo zapita da li bi majstorima dozvolio da ponu sa gradnjom kue bez detaljnog arhitektonskog plana. Ista analogija moe se primeniti i na razvoj software-a.8 LITERATURA[1] UML Resource Page, http://www.UML.org, 10.2005

[2] Mastering UML with Rational Rose 2002, Wendy Boggs, Sybex 2001

[3] Unified Modeling Language,http://www.rational.com/uml/, 09.2005

[4] Unified Modeling Language, Wikipedia, http://en.wikipedia.org/wiki/UML , 10.2005

[5] UML Guide, Grandy Booch, James Rumbaugh, Ivar Jacobson, Addison Wesley 1999

[6] Unified Modeling Language Specification, OMG 1999

[7] Professional SQL Server 2000 Programming, Robert Vieira - Wrox 2000[8] Profesionalno programiranje ADO.NET, Bipin Joshi, Paul Dickinson, Claudio Ferracchiati, Kevin Hoffman Wrox 2002

[9] Microsoft Solutions Framework Essentials Microsoft 2002[10] Hitchhikers Guide to SQL Server 2000 Reporting Services, Peter Blackburn, Villiam R. Vaughn Addison Wesley 2005[11] Projektovanje skladita podataka, Chris Todman Hewlett Packard 2001

[12] Test Driven Development in Microsoft. NET, James W. Newkirk, Alexei A. Vorontsov Microsoft 2004[13] Use Case Medeling, Kurt Bittner, Ian Spence Addison Wesley 2003[14] Osnove relacionih i analitikih baza podataka dr. Alimpije Veljovi, dr. Angelina NjeguPAGE 3

_1119624441.vsd

Ethernet

WWW Server

SQL Server

Baza podataka

Klijent 1

Klijent 2

Klijent n

Udaljeni klijent n

Udaljeni klijent 1

Internet

Firewall

LAN

magacinsko-poslovanje.doc

Documents