Magacinsko Poslovanje

Magacinsko poslovanje

Sažetak:

U radu je opisan proces projektovanja i implementacije aplikacije magacinskog poslovanja. Postupak projektovanja je izveden UML metodologijom koja je u radu detaljno objašnjena i predstavljena kroz sve faze. U radu je dat poseban osvrt na dva kompletna slučaja korišćenja: prijemnica i otpremnica.

U okviru rada dat je opis višeslojne arhitekture aplikacije, razvojnog alata Visual Studio-a 2003 i baze MS SQL 2000. Objašnjen je način implementacije svakog sloja ponaosob..

Ključne reči:UML, distribuiran, LAN, višeslojna 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 note

Also 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

Veljko Pakević Magainsko poslovanje

SADRŽAJ

1 UVOD......................................................................................................................................4

1.1 UVOD U MAGACINSKO POSLOVANJE............................................................................4

2 UML........................................................................................................................................5

2.1 ŠTA JE UML.................................................................................................................52.2 MODELIRANJE SISTEMA NOVI VS. STARI NAČIN...........................................................62.3 UML KOMPONENTE......................................................................................................7

2.3.1 Class dijagram..........................................................................................................72.3.2 Use Case dijagram.................................................................................................102.3.3 State dijagram.........................................................................................................122.3.4 Sequence dijagram.................................................................................................132.3.5 Collaboration dijagram..........................................................................................142.3.6 Activity dijagram....................................................................................................152.3.7 Component dijagram..............................................................................................172.3.8 Deployment dijagram.............................................................................................19

3 MAGACINSKO POSLOVANJE JEZIKOM UML-A.....................................................20

3.1 SLUČAJ KORIŠĆENJA: PRIJEMNICA..............................................................................213.1.1 Unos prijemnice......................................................................................................22

3.1.1.1 Sekvencni dijagram- Unos prijemnice...............................................................233.1.1.2 Kolaboracioni dijagram- Unos prijemnice.........................................................243.1.1.3 Dijagram Aktivnosti- Unos prijemnice..............................................................25

3.1.2 Ažuriranje prijemnice.............................................................................................263.1.2.1 Sekvencni dijagram- Ažuriranje prijemnice......................................................273.1.2.2 Kolaboracioni dijagram- Ažuriranje prijemnice................................................283.1.2.3 Dijagram aktivnosti- Ažuriranje prijemnice......................................................29

3.1.3 Brisanje prijemnice.................................................................................................303.1.3.1 Sekvencni dijagram- Brisanje prijemnice..........................................................313.1.3.2 Kolaboracioni dijagram- Brisanje prijemnice....................................................323.1.3.3 Dijagram aktivnosti- Brisanje prijemnice..........................................................33

3.1.4 Dijagram klasa- Prijemnica...................................................................................343.1.5 Dijagram Stanja.....................................................................................................35

3.2 SLUČAJ KORIŠĆENJA: OTPREMNICA U MALOPRODAJU...............................................363.2.1 Unos otpremnice u maloprodaju............................................................................37

3.2.1.1 Sekvencni dijagram- Unos Otpremnice.............................................................383.2.1.2 Kolaboracioni dijagram- Unos Otpremnice.......................................................393.2.1.3 Dijagram aktivnosti- Unos Otpremnice.............................................................40

3.2.2 Ažuriranje otpremnice u maloprodaju...................................................................413.2.2.1 Sekvencni dijagram- Ažuriranje Otpremnice....................................................423.2.2.2 Kolaboracioni dijagram- Ažuriranje Otpremnice..............................................433.2.2.3 Dijagram aktivnosti- Ažuriranje Otpremnice....................................................44

3.2.3 Brisanje otpremnice u maloprodaju.......................................................................453.2.3.1 Sekvencni dijagram- Brisanje Otpremnice........................................................463.2.3.2 Kolaboracioni dijagram- Brisanje Otpremnice..................................................473.2.3.3 Dijagram aktivnosti- Brisanje Otpremnice........................................................48

3.2.4 Dijagram klasa- Otpremnica..................................................................................49

2


3.3 DEPLOYMENT DIAGRAM.............................................................................................50

4 RAZVOJ APLIKACIJE.....................................................................................................51

4.1 RAZVOJNI ALATI.........................................................................................................514.1.1 Microsoft Visual Studio 2003.................................................................................444.1.2 Microsoft SQL Server 2000....................................................................................44

4.2 ARHITEKTURA APLIKACIJE.........................................................................................444.2.1 Prezentacioni sloj...................................................................................................44

4.2.1.1 Forme.................................................................................................................564.2.3 Business Sloj...........................................................................................................584.2.4 Brokeri....................................................................................................................614.2.5 Baza podataka........................................................................................................61

5 DATA WAREHOUSING I OLAP.....................................................................................63

5.1 Datamart.................................................................................................................635.2 Data minig..............................................................................................................63

6 VIZIJA..................................................................................................................................66

7 ZAKLJUČAK......................................................................................................................67

8 LITERATURA.....................................................................................................................68

3


I UVOD

I.1 UVOD U MAGACINSKO POSLOVANJE

U svetu velike konkurencije, gde razlika između proizvoda kako u kvalitetu tako i u karakteristikama nestaje, svaki kupac je zlata vredan. Borba između kompanija svakim danom jača, 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 tržištu zahteva postaju lideri tržišta – koji diktiraju standarde i postavljaju pravila igre.

Magacinsko poslovanje je namenjeno magacioneru koji isključivo evidentira kartice robe ili materijala u magacinu. Vrši se unos, ažuriranje i listanje osnovnih (matičnih) podataka potrebnih za vođenje magacinskog poslovanja, kao i svih ulazno/izlaznih promena. Moguće je definisati sve potrebne vrste ulazno/izlaznih dokumenata, a obezbeđena je njihova kontrola i korekcija. U aplikaciji se vode kartice artikala i izrađuju lager liste. Pretraživanje podataka se vrši na više načina: po šifri, po nazivu, po dobavljaču. Izveštaji 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 objašnjeno 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 trećoj glavi: Magacinsko poslovanje jezikom UML-a.

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

U petoj glavi dat je zaključak.

4


II UML

II.1 Šta je UML

Povećanjem kompleksnosti poslovnih procesa, računarski sistemi za njihovo praćenje i upravljanje svakim danom postaju sve kompleksniji. Oni često obuhvataju veći broj računara, različite programe, velike mreže računara koji su na velikim udaljenostima, međusobno pove-zane baze i ogromne, ogromne količine podataka. Postavlja se pitanje kako uspešno upravljati tako komplikovanim sistemima?Ključ je u dizajniranju procesa tako da ih klijenti, projektanti, programeri i svi drugi koji su uključeni u priču razvoja programa lako mogu da razumeju. Upravo UML omogućava takav vid organizacije.Ukoliko i dalje neko nije siguran u potrebu za kvalitetnim projektovanjem programa neka zamisli sledeću situaciju. Na primer: klijent odlazi u građevinsku kompaniju i traži da mu izgrade kuću od 2000 kvadratnih metara sa 5 soba i 2 kupatila i kaže POČNITE ODMAH. Kako vi budete gradili tako ćemo mi crtati plan. Naravno niko ne bi gradio kuću na ovaj način. Međutim na žalost ovakav vid razvoja programa je najčešći. Baš kao što bi klijent najpre otišao u arhitektonski biro i tamo napravio detaljan plan kuće koju želi da izgradi, tako bi trebalo razvijati i programe. Jedan od tih načina je i UML.UML je nastao 1997 kao metod za dizajn programa uz pomoć dijagrama. Napravljen je od stanje najboljih stručnjaka koji se bave objektno-orjentisanim projektovanjem. To je definitivno najznačajnija stvar koja se desila software-skoj industriji u poslednjih par godina. Svaka druga inženjerska disciplina ima svoj standardni metod vođenja dokumentacije. Električari imaju šeme, arhitekte i građevinari nacrte. Software-ska industrija sada ima svoj način UML.Neke od prednosti korišćenja UML-a:

Software-ski sistemi će biti profesionalno isprojektovani i dokumentovane pre nego što se počne sa kodiranjem. Na taj način se unapred zna šta će se dobiti kao rezultat.

Kako je sistem prvo isprojektovan, korišćenje istog koda je veoma učestalo kao i njegova efikasnost, samim tim se smanjuje cena programiranja.

Logičke rupe i problemi su primećeni već u fazi projektovanja. Smanjuje se broj iznenađenja prilikom programiranja.

UML omogućava 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 pretraživanjem koda i razmišljanjem zašto je to tako urađeno. Samim tim se značajno smanjuju troškovi održavanja.

Ukoliko se javi potreba za zamenom programera ili uvođenjem novih, UML crteži će mu omogućiti brže uključivanje u sistem.

Ukoliko se javi potreba za komunikacijom sa trećim osobama u vezi projekta, zahvaljući UML dokumentaciji to će biti puno brže i efikasnije.

U jednoj rečenici: Korišćenje UML-a dovodi do smanjena troškova, stvaranja boljeg i efikasnijeg software-a i poboljšanja odnosa između svih strana koje učestvuju u procesu.

5


II.2 Modeliranje sistema Novi vs. Stari način

Proces razvoja sistema uključuje veliki broj ljudi. Najpre klijente, osoba koja ima problem koji treba rešiti. Projektanta koji vrši projektovanje i programera koji na osnovu dokumentacije razvija software koji će rešiti problem kupca. Neophodnost učestvovanja više ljudi u razrešenju problema, prouzrokovana je kompleksnošću današnjih sistema. Znanje se mora specijalizovati, jedna osoba ne može da zna sve činjenice vezane za poslovanje, da razume problem, projektuje rešenje, programira program.

Slika 2.2.1: Waterfall metoda razvoja programa

Stari način projektovanja, poznat kao Waterfall, obuhvata sledeće faze koje se izvršavaju jedna za drugom (Slika 2.2.1):analizu, projektovanje, programiranje i razvoj. Samo kada je prethodna faza kompletirana može se početi sa sledećom. Ako analitičar završi i preda projekat projektantu koji kada završi preda programeru, male su šanse da ova tri učesnika tima rade zajedno i razmenjuju bitne informacije.

Novi način projektovanja UML, zahteva konstantnu povezanost između učesnika u svim fazama projekta. Analitičar i projektant unapred postavlju solidnu bazu za programera. Sa druge strane programer deli svoja zapažanja sa analitičarom i projektantom, zajedno menjaju projekat, ojačavaju kod. Kao rezultat povećava se međusobno razumevanje, tim ugrađuje nove ideje i gradi jači sistem.

6


II.3 UML komponente

UML se sastoji od nekoliko grafičkih elemenata koji zajedno čine dijagrame. Zbog toga što je jezik, UML ima određena pravila za kombinovanje tih elemenata. Svrha dijagrama je prezentacija višestrukih pogleda na sistem. Skup tih višestrukih pogleda se naziva model. Zadatak modela je da opiše čemu sistem služi. On ne govori kako implementirati sistem [4].

UML se sastoji od 8 bazičnih dijagrama:1. Class dijagram2. Use Case dijagram3. State dijagram4. Sequence dijagram5. Activity dijagram6. Collaboration dijagram7. Componenet dijagram8. Deployment dijagram

Projektovanje programa je aktivnost čoveka. Bez jasnog razumevanja sistema, proces je podležan velikom broju potencijalnih grešaka. Insistirajući na jasnom setu dijagrama, UML pruža standard koji omogućava analitičarima da izgrade sliku koja će biti jasna klijentima, programerima i svim drugim učesnicima u procesu razvoja. Neophodno je u projektu imati sve nabrojane dijagrame zbog toga što svaki od njih na svoj način opisuje drugi pogled na sistem.U nastavku će svaki od nabrojanih dijagram biti detaljnije objašnjen.

II.3.1 Class dijagram

Stvari se prirodno svrstavaju u kategorije (računari, automobili, drveće...). Te kategorije ustvari predstavljaju klase. Dakle klasa je kategorija ili grupa stvari koje imaju slične osobine i ponašanja. Klas dijagram predstavlja pogled na sistem koji najviše koriste programeri. UML klasni dijagram se najčešće sastoji od nekoliko klasa povezanih međusobno 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 početnih slova reči 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 može da ima. Klasa može da ima 0 ili više atributa u sebi. Pravilo imenovanja atributa je isto kao i kod klasa, sve malim slovima izuzev početnih slova u reči. Lista atributa se nalazi ispod imena klase od koga je odvojena horizontalnom linijom. Pored samog imena atributa u dijagramu može se navesti kog je tipa atribut i koja je njegova inicijalna vrednost (Slika 2.3.1.2).

7


Slika 2.3.1.2: Klasa sa dva atributa

Pored atributa klasa se može sastojati i od operacija. Operacija je nešto što klasa može da uradi ili nešto što joj moguće 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 (nabrajajući 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 pažnju na imenice koje koriste da bi opisali elemente svog posla. Te imenice će u fazi projektovanja postati klase. Takođe treba obratiti pažnju na glagole i prideve vezane za te imenice, oni će u budućem modelu postati operacije i atributi.

Kao što je napomenuto na početku ovog dela, sastavni deo Class dijagrama su klase koje su međusobno 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 između 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

8


Asocijacija kao tip veze može biti kompleksnija uključivanjem više od dve klase u relaciju. Ponekad veza između dve klase mora biti ispraćena nekim pravilom. To pravilo se najčešće stavlja dodavanjem ograničenja pored linije koja predstavlja vezu klasa (Slika 2.3.1.5).

Slika 2.3.1.5: primer složenije asocijacije

Specijalan vid asocijacije je Multiplicity koja pokazuje broj objekata jedne klase koji su u relaciji sa određenim brojem elemenata u drugoj klasi. Jedna klasa može biti u relaciji sa drugom:

Jedan prema jedan – 1..1 Jedan prema više – 1..n Jedan prema jedan ili više – 1..1,n Jedan prema nula ili jedan – 1..0,1 Jedan prema određeni interval – 1..1-100 Jedan prema tačno određenom setu mogućnosti (jedan prema 5 ili 8)

Nasleđivanje i Generalizacija. Jedna klasa (izvedena klasa) može naslediti atribute i operacije od druge klase. Ta druga- roditeljska klasa je opštija od izvedene. Postojanje izvedene klase zavisi od postojanja glavne, ukoliko glavna postoji postoji i izvedena, obrnuto ne važi. U UML notaciji nasleđivanje se obeležava 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 nasleđivanja.

Agregacija. Ponekad se klasa sastoji od nekoliko komponenti klasa. Ovaj specifični 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.).

9


Slika 2.3.1.7: Agregacija

Veoma često prilikom identifikovanja klasa dolazi se do slučaja, da neke klase nisu vezane za nadređenu klasu ali njihovo ponašanje može biti opisano sa istim operacijama. Tada je moguće ponašanje implementirati samo za jednu od klasa i koristiti ga za sve ostale klase uz pomoć Interfejsa. Interfejs predstavlja skup operacija koje specificiraju neki aspekt ponašanja klase. U UML notaciji interfejs se obeležava slično kao klasa, u obliku pravougaonika, ali on nema atribute samo operacije. Da bi se razdvojio interfejs od klase obično se pre imena stavlja stereotip <<interface>> (Slika 2.3.1.8).

Slika 2.3.1.8: Interface

II.3.2 Use Case dijagram

Use Case dijagram predstavlja opis ponašanja sistema kako ga korisnik vidi, za razliku od prethodno opisanog klas dijagrama koji predstavlja statičan pogled na klase Use Case dijagram pokazuje kako se sistem i njegove klase menjaju tokom vremena. Kako je klas dijagram odlična stvar da stimuliše klijenta da govori o sistemu sa njegove ili njene tačke gledišta, use case dijagram je odlična stvar da stimuliše potencijalnog korisnika da govori sa njegove tačke gledišta. Use case pomaže da se razbije led.

Prvi razgovori sa klijentima obično se završavaju sa identifikovanjem učesnika i pravljenjem grubih use case-ova. Tek kasniji razgovori omogućavaju opisivanje sistema detaljnije i veoma često proizvode nove use case-ove.

Sam use case predstavlja kolekciju scenarija o korišćenju sistema. Svaki scenario predstavlja sekvencu događaja. 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 nešto što će biti korisno ili actor-u koji je pokrenu ili nekom drugom.

10


U samoj notaciji UML-a use case se predstavlja uz pomoć elipse, dok se actor-i predstavljaju uz pomoć čiča-Gliša. Sa leve strane se nalazi actor koji inicira, a sa desne strane onaj koji prima rezultate. Obično 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 između njih (Slika 2.3.2.1).

Slika 2.3.2.1: Primer use case-a

Use case je moguće ponovo iskoristiti. Postoj dva načina za to (Slika 2.3.2.2):

inclusion, korišćenje 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 između klasa, isprekidana linija sa strelicom na vrhu koja je uperena na zavisnu klasu. Samo je potrebno iznad linije dodati stereotip <<include>>.

extension, kreiranje novog use case-a dodavanjem koraka iz drugog use case-a. Isti način notacije kao i kod inclusion samo se iznad linije dodaje stereotip <<extends>>.

Slika 2.3.2.2: Primer include i extended

11


II.3.3 State dijagram

Karakteristika sistema je da menjaju ponašanje tokom vremena. Kako dolazi do međusobne interakcije sistema sa korisnikom, a moguće i sa drugim sistemom, objekti koji čine sistem doživljavaju 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 može da bude tokom tranzicije iz jednog u drugo stanje i prikazuje početnu tačku i krajnju tačku 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 početna tačka, dok sa krugom sa tačkom 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 može imati tri opisa: entry- šta se dešava kada sistem ulazi u stanje, exit- šta se dešava kada sistem napusti stanje, do- šta se dešava 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 previše komplikovana da bi bila predstavljena sa zaokruženim pravougaonikom. Takva stanja obično se predstavljaju stanjima u stanju, ta stanja koja se nalaze unutar drugih se nazivaju se podstanja (Slika 2.3.3.3).

12


Slika 2.3.3.3: Primer stanja sa pod stanjem

II.3.4 Sequence dijagram

U prethodnoj tački bio je objašnjen State dijagram koji se fokusira na stanja objekata. Međutim pored stanja neophodno je pratiti i komunikaciju između objekata. U UML se za to koriste sekvencni dijagrami, koji prikazuju komunikaciju između objekata tokom vremena. Ključna ideja je stavljanje interakcija, koje se odvijaju između objekata, u specifične sekvence, koje obuhvataju vreme od početka do kraja interakcije.

Sekvencni dijagrami se sastoje od 3 osnovna elementa:

Objekti- se predstavljaju na klasičan način – u obliku pravougaonika. Oni se na dijagramu ređaju sa desna na levo u redosled koji će učiniti 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 dužina zavisi od dužine akcije (Slika 2.3.4.1).

2.3.4.1: Notacija za obeležavanje klase u sekvencnom dijagramu

Poruke. Poruka predstavlja komunikaciju između objekata, Ona se u dijagramu stavlja između životne linije prvog i drugog objekata. Objekat može i sam sebi poslati poruku. Postoje tri različita izgleda strelice u zavisnosti o tipa poruke (Slika 2.3.4.2).

Slika 2.3.4.2: Vrste poruka

13


Vreme. Sekvencni dijagram predstavlja vreme vertikalno. Vreme počinje od vrha dijagrama i teče ka dole. Poruka koja se nalazi višlje na dijagramu desila se ranije, nego poruka koja je bliže dnu (Slika 2.3.4.3).

Slika 2.3.4.3: Primer sekvencnog dijagrama

Use case dijagram može prikazivati samo jedan slučaj korišćenja (scenario), ili može biti opšti i uključivati sve slučajeve korišćenja. Tako i sekvencni dijagrami mogu biti pojedinačni ili opšti. Opšti sekvencni dijagrami pružaju mogućnost prikaza if uslova ili while ciklusa. U UML notaciji if uslov se obeležava 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

II.3.5 Collaboration dijagram

Kolaboracioni dijagram isto kao i sekvencni, pokazuje interakciju između 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?

14


Sekvencni i kolaboracioni dijagram su vrlo slični. Njihova semantika je ista, prikazuju iste informacije i moguće je prevesti sekvencni u kolaboracioni i obrnuto. Međutim glavna razlika između njih je u tome što je sekvencni prilagođen 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 obično predstavlja šta objekat koji prima poruku, treba da izvrši. Pored teksta poruke se nalaze obično i redni brojevi koji odgovaraju redosledu sekvenci (Slika 2.3.5.1).

Slika 2.3.5.1: Primer kolaboracionog dijagrama

II.3.6 Activity dijagram

Dijagram aktivnosti najviše podseća slike algoritama. On se sastoji od koraka (zvanih aktivnosti), tačaka odluke i grananja. Veoma je koristan za pokazivanje šta se dešava u poslovnim procesima ili operacijama.

Pre svega dijagrami aktivnosti se prave da bi se lakše shvatilo šta se dešava tokom procesa. Oni na neki način 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 označava početak), u dnu se nalazi prazan krug sa tačkom koji označava 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š sledeće elemente:

15


Grananja. Grananje se prikazuje u obliku dijamanta, do koga dolazi strelica koja pokreće grananje, a iz njega izlaze dve grane u zavisnosti da li je uslov ispunjen ili ne. Obično 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 dešava da se neka aktivnost podeli na dva odvojena dela koja se izvršavaju u isto vreme (konkurentno), da bi se na kraju izvršenja obe slile ponovo u jednu. To deljenje aktivnosti na dva dela se obeležava sa za-debljanom linijom u koju ulazi strelica iz početne aktivnosti. Iz zadebljane linije izlaze dve stre-lice koje predstavljaju novonastale aktivnosti i opet se završavaju u zadebljanoj liniji iz koje izlazi jedna strelica označavajući da je konkurentni rad završen (Slika 2.3.6.3).

Slika 2.3.6.3: Konkurentno izvršavanje aktivnosti

Signali. Tokom sekvence aktivacije, moguće 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

16


II.3.7 Component dijagram

U prethodnim tačkama bili su prikazani dijagrami koji prikazuju konceptualne entitete. Sledeće dve tačke će se baviti realnim entitetima: software-skim komponentama. Software-ske komponente su fizički delovi sistema. Oni se nalaze u računaru, ne u glavi projektanta [7].Postavlja se pitanje kakva je veza između komponente i klase? Klasa predstavlja apstrakciju seta atributa i operacija, sa druge strane komponentu treba posmatrati kao programsku implementaciju klase. Jedna komponenta može biti implementacija više klasa.Komponente i njihove relacije se projektuju:

Da bi klijent mogao da vidi kako će izgledati struktura završenog sistema Programeri dobijaju strukturu po kojoj mogu da rade Osoba zadužena za pisanje tehničke dokumentacije i pomoći (Help-a) može lakše

razumeti o čemu piše Olakšava ponovno korišćenje 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 može pozivati opcije, koje su inače skrivene enkapsulacijom. Interfejs je skup operacija koji specificira ponašanje klase, praktično skup operacija koje klasa predstavlja drugim klasama. Sa aspekta projektanta interfejs komponenti je isto što interfejs kod klasa. Moguće je zameniti jednu komponentu sa drugom ako ta druga komponenta koristi isti interfejs kao prethodna, isto tako moguće je ponovo iskoristiti komponentu ali za neki drugi proizvod. Prilikom projektovanja najčešće se susreće 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. Izvršne komponente: koje nastaju kao rezultata rada sistema.

Današnji svet software-skog inženjerstva je zasnovan na timskom radu, svi učesnici u projektu moraju da rade sa različitim 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 važno imati sliku, mesto na kome su pobrojane sve komponente i veze među njima. Upravo je to zadatak dijagrama komponenti (Slika 2.3.7.1).

Slika 2.3.7.1 Primer dijagrama komponenti za muzički player

17


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 tiče predstavljanja interfejsa i komponente čiji je to interfejs to je moguće uraditi na dva načina: nacrtati interfejs u obliku pravougaonika sa svim pripadajućim informacijama o interfejsu i isprekidanom strelicom od komponente do interfejsa označiti vezu, ili prikazati interfejs u obliku kružića koji je punom linijom spojen sa pripadajućom komponentom (Slika 2.3.7.3).

Slika 2.3.7.3: Dva načina prikaza interfejsa i relacije sa komponentom

II.3.8 Deployment dijagram

Ovo je poslednji dijagram koji se koristi u UML. Njegov zadatak je da prikaže fizičku arhitekturu računarski zasnovanog sistem. Dakle sa UML dijagramom se kreće 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 neće imati na čemu da se izvršava, zato je nacrt hardware-ske organizacije sistema bitan. Baš zbog toga UML nudi alat koji svojim simbolima kreira jasnu sliku kao okruženje treba da izgleda (Slika 2.3.8.1)

18


Slika 2.3.8.1: Dijagram razvoja: primer kućnog računara

Prilikom crtanja dijagram treba znati da je osnovni hardware element nod, generičko ime za bilo koji tip računarskog resursa. Postoje dve vrste nodova:

Processor- nod koji može da izvrši komponentuDevice- nod koji ne može da izvršava, on obično 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 obeležiti kom tipu pripada. Ako je nod deo paketa onda pre imena treba navesti kom paketu pripada. Linija koja se nalazi između dva noda predstavlja konekciju.

Slika 2.3.8.2: Simbol za nod

19


III MAGACINSKO POSLOVANJE JEZIKOM UML -

a

Aplikacija magacinsko poslovanje ima zadatak da vodi evidenciju o svoj robi koja se nalazi u magacinima. U zavisnosti od robe koja se skladišti, moguća je potreba posebnih uslova skladištenja robe, što treba da bude primenjeno u samoj aplikaciji magacinskog poslovanja.

Prilikom analize potreba utvrđeno je da sistem magacinskog poslovanja treba da raspolaže sledećim dokumentima:

Prijemnica, uz pomoć koje se roba koju dostavlja dobavljač uvodi u sistem Povratnica dobavljaču Interna otpremnica, dokument koji omogućava prenos robe iz jednog u drugi magacin Interna prijemnica, dokument koji omogućava 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. Omogućava da roba

iz proizvodnje, pređe u magacin gotovih proizvoda Otpremnica kupcu, ovim dokumentom se artikli otpremaju kupcu Povratnica od kupca, omogućava povratak robe od kupca i njen prijem u odgovarajući

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

količinom tereti maloprodaju Povratnica iz maloprodaje, prijem robe iz maloprodaje

20


III.1 Slučaj korišćenja: Prijemnica

Na slici 3.1.1 data je slučaj korišćenja: “Prijemnica“. Sam slučaj se sastoji od tri slučaja korišćenja:

Unos prijemnice Ažuriranje prijemnice Brisanje prijemnice

Izbor Dobavljaca

Izbor RobeAzuriranje Prijemnice

<<extend>>

<<extend>>

Brisanje Prijemnice

Unos Prijemnice

<<extend>>

<<extend>>

Magacioner

Slika 3.1.1: Slučaj korišćenja: Prijemnica

21


III.1.1 Unos prijemnice

Ovaj slučaj korišćenja predstavlja postupak uvođenja robe koja je stigla od dobavljača 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 odgovarajuće opcije u glavnom

programu. Forma koja se otvora ima omogućene samo dve opcije: dugme “Novi“ i dugme “Učitaj“. Klikom na dugme “Novi“ forma se prebacuje u režim 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. Sledeći korak je izbor dobavljača klikom na dugme: “Izbor Dobavljača“, otvara se odgovarajuća forma (extend (Izbor Dobavljača)). Korisnik bira željenog dobavljača i vraća se u program, sistem puni polje “Dobavljač“ izabranim dobavljačem.

4. Korisnik prelazi na donji deo forme koje je predstavljena gridom. Klikom na dugme “+“ polja za unos količine i robe postaju dostupna. Najpre se bira roba klikom na dugme: “Izbor Robe“. Otvara se odgovarajuća forma (extend (Izbor Robe)) gde korisnik bira željenu robu i vraća se nazad na glavnu formu.

5. U polje “Količina“ unosi se pristigla količina, a sistem proverava da li je uneti broj veći od nule.

6. Korisnik i sistem izvršavaju 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 spušta podatke u bazu.

Alternativni tok – Nekorektan datum

1. Korisnik u polje: “Datum Dokumenta“, unosi pogrešan datum. Pod pogrešnim datumom podrazumeva se ili ne korektan format datuma ili datum koji je manji od datuma poslednjeg proknjiženog dokumenta tog tipa za ulogovani magacin. Sistem se vraća na korak 2.

2. Polje Datum Dokumenta“je prazno, ukoliko korisnik ostavi polje: Datum Dokumenta“ prazno, sistem će ispisati odgovarajuću 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 odgovarajuću poruku i vratiti korisnika na korak 3.

Alternativni tok – Nekorektan izbor robe i količine

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

2. Ukoliko korisnik unese u polje “Količina“ vrednost manju od 0, sistem će dati odgova-rajuću poruku i vratiti korisnika na korak 5.

Preduslovi

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

22

Specijalistički rad – Distribuirani informacioni sistem magacinskog poslovanja BIS

3.1.1.1 Sekvencni dijagram- Unos prijemnice

Slika 3.1.1.1.1: Unos Prijemnice (Sequence Diagram)

23


3.1.1.2 Kolaboracioni dijagram- Unos prijemnice

Slika 3.1.1.2.1: Unos Prijemnice (Collaboration Diagram)

24


3.1.1.3 Dijagram Aktivnosti- Unos prijemnice

Slika 3.1.1.3.1: Unos Prijemnice (Activity Diagram)

25


III.1.2 Ažuriranje prijemnice

Ukoliko zbog bilo kog razloga je došlo do greške ili promene podataka prilikom unosa prijemnice potrebno je izvršiti ažuriranje. Osnovni tok:

1. Korisnik startuje formu “Prijemnica“, izborom odgovarajuće opcije u glavnom programu. Forma koja se otvori ima omogućene samo dve opcije: dugme “Novi“ i dugme “Učitaj“. Ovog puta korisnik bira dugme: “Učitaj dokument“. Klikom na dugme otvara se nova forma gde korisnik može da izabere željeni dokument. Klikom na enter forma se zatvara, a sistem učitava podatke o unetom dokumentu.

2. Korisnik može promeniti datum dokumenta, inicijalno u tom polju se nalazi originalni datum

3. U sledećem koraku moguće je promeniti dobavljača klikom na dugme: “Izbor Dobavljača“, otvara se odgovarajuća forma (extend (Izbor Dobavljača)). Korisnik bira željenog dobavljača i vraća se u program, sistem puni polje “Dobavljač“ izabranim dobavljačem.

4. Korisnik prelazi na donji deo forme koje je predstavljena gridom. Klikom na dugme “+“ polja za unos količine i robe postaju dostupna. Najpre se bira roba klikom na dugme: “Izbor robe“. Otvara se odgovarajuća forma (extend (Izbor Robe)) gde korisnik bira željenu robu i vraća se nazad na glavnu formu.

5. U polje “Količina“ unosi se pristigla količina, a sistem proverava da li je uneti broj veći od nule.

6. Klikom na dugme “-“ vrši se brisanje reda sa učitanim podacima o robi.7. Korisnik i sistem izvršavaju korake 4, 5, 6 sve dok je potrebno menjati podatke o robi8. Klikom na dugme ažuriraj, korisnik daje zahtev da se podaci snime, sistem proverava

da li su uneti podaci u redu i ažurira postojeći slog u bazi.Alternativni tok – Nekorektan datum

1. Korisnik u polje “Datum Dokumenta“, unosi pogrešan datum. Pod pogrešnim datumom se podrazumeva ili ne korektan format datuma ili datum koji je manji od datuma poslednjeg proknjiženog dokumenta tog tipa za ulogovani magacin. Sistem ga vraća na korak 2.

2. Polje datum je prazno, ukoliko korisnik ostavi polje: “Datum Dokumenta“ prazno, sistem će ispisati odgovarajuću poruku i vratiti korisnika na korak 2

Alternativni tok – Polje dobavljač prazno1. Polje “Dobavljač“ je prazno, ukoliko korisnik ostavi polje: “Dobavljač“ prazno,

sistem će ispisati odgovarajuću poruku i vratiti korisnika na korak 3.Alternativni tok – Nekorektan izbor robe i količine


2. Ukoliko korisnik unese u polje “Količina“ vrednost manju od 0, sistem će dati odgovarajuću poruku i vratiti korisnika na korak 5.

3. Ukoliko korisnik briše 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 odgovarajuću poruku.

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

26


3.1.2.1 Sekvencni dijagram- Ažuriranje prijemnice

Slika 3.1.2.1.1: Ažuriranje Prijemnice (Sequence Diagram)

27


3.1.2.2 Kolaboracioni dijagram- Ažuriranje prijemnice

Slika 3.1.2.2.1: Ažuriranje Prijemnice (Collaboration Diagram)

28


3.1.2.3 Dijagram aktivnosti- Ažuriranje prijemnice

Slika 3.1.2.3.1: Ažuriranje Prijemnice (Activity Diagram)

29


III.1.3 Brisanje prijemnice

Slučaj korišćenja: “Brisanje prijemnice“, opisuje ponašanje sistema ukoliko dođe do potrebe za poništavanjem odnosno brisanjem celokupnog dokumenta.

Osnovni tok:

1. Korisnik startuje formu “Prijemnica“, izborom odgovarajuće opcije u glavnom programu. Forma koja se otvori ima omogućene samo dve opcije: dugme “Novi“ i dugme “Učitaj“. Ovog puta korisnik bira dugme: “Učitaj dokument“. Klikom na dugme učitaj, otvara se nova forma gde korisnik može da izabere željeni dokument. Klikom na enter forma se zatvara, a sistem učitava podatke o unetom dokumentu.

2. Klikom na dugme “Obriši“, korisnik daje zahtev da se podaci obrišu, sistem proverava mogućnost brisanja i briše postojeći slog u bazi.

Alternativni tok – Dokument je proknjižen

1. Sistem proverava da li je izabrani dokument već proknjižen na finansijskom nivou i ukoliko jeste daje odgovarajuću poruku.

Alternativni tok – Količina 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 odgovarajuću poruku.

Preduslovi


30


3.1.3.1 Sekvencni dijagram- Brisanje prijemnice

Slika 3.1.3.1.1: Brisanje Prijemnice (Sequence Diagram)

31


3.1.3.2 Kolaboracioni dijagram- Brisanje prijemnice

Slika 3.1.3.2.1: Brisanje Prijemnice (Collaboration Diagram)

32


3.1.3.3 Dijagram aktivnosti- Brisanje prijemnice

33


Slika 3.1.3.3: Brisanje Prijemnice (Activity Diagram)

III.1.4 Dijagram klasa- Prijemnica

34


Slika 3.1.4.1: Prijemnica (Class Diagram)

III.1.5 Dijagram Stanja

35


Slika 3.1.5.1: Prijemnica (State Diagram)

36


III.2 Slučaj korišćenja: Otpremnica u maloprodaju

Na slici 3.2.1 dat je slučaj korišćenja: “Otpremnica u maloprodaju“. Sam slučaj sastoji se od 3 slučaja korišćenja:

Unos otpremnice u maloprodaju Ažuriranje otpremnice u maloprodaju Brisanje otpremnice u maloprodaju

Izbor Robe

Izbor Maloprodaje

Brisanje Otpremnice

Azuriranje Otpremnice

Unos Otpremnice

Magacioner

<<extend>>

<<extend>>

<<extend>>

<<extend>>

Slika 3.1.1: Slučaj korišćenja: Otpremnica u maloprodaju

37


III.2.1 Unos otpremnice u maloprodaju

Slučaj korišćenja: “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 povećava stanje robe u maloprodaji. Nakon slanja roba izlazi iz sistema i ne vrši se njeno dalje praćenje (barem ne aplikacijom magacinsko poslovanje).Osnovni tok:

1. Korisnik startuje formu “Otpremnica u Maloprodaju“, izborom odgovarajuće opcije u glavnom programu. Forma koja se otvori ima omogućene samo dve opcije: dugme “Novi“ i dugme “Učitaj“. Klikom na dugme “Novi“ forma se prebacuje u režim 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. Sledeći korak je izbor maloprodaje klikom na dugme: “Izbor Maloprodaje“, otvara se odgovarajuća forma (extend (Izbor Maloprodaje)). Korisnik bira željenu maloprodaju i vraća se u program, sistem puni polje “Maloprodaja“ izabranom maloprodajom.


5. U polje “Količina“ unosi se količina 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 izvršavaju 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 spušta podatke u bazu.

Alternativni tok – Nekorektan datum1. Korisnik u polje “Datum dokumenta“, unosi pogrešan datum. Pod pogrešnim

datumom se podrazumeva ili ne korektan format datuma ili datum koji je manji od datuma poslednjeg proknjiženog dokumenta tog tipa za ulogovani magacin. Sistem ga vraća na korak 2.

2. Polje “Datum dokumenta“ je prazno, ukoliko korisnik ostavi polje: “Datum dokumenta“ prazno, sistem će ispisati odgovarajuću poruku i vratiti korisnika na korak 2

Alternativni tok – Polje “Maloprodaja“ je prazno1. Polje “Maloprodaja“ je prazno, ukoliko korisnik ostavi polje: “Maloprodaja“ prazno,

sistem će ispisati odgovarajuću poruku i vratiti korisnika na korak 3.Alternativni tok – Nekorektan izbor robe i količine


2. Ukoliko korisnik unese u polje “Količina“, količinu koja će eventualnim snimanjem otpremnice u bazu, dovesti stanje robe u minus sistem će dati odgovarajuću poruku i vratiti korisnika na korak 5.


38


3.2.1.1 Sekvencni dijagram- Unos Otpremnice

Slika 3.2.1.1.1: Unos Otpremnice (Sequence Diagram)

39


3.2.1.2 Kolaboracioni dijagram- Unos Otpremnice

Slika 3.2.1.2.1: Unos Otpremnice (Collaboration Diagram)

40


3.2.1.3 Dijagram aktivnosti- Unos Otpremnice

Slika 3.2.1.3.1: Unos Otpremnice (Activity Diagram)

41


III.2.2 Ažuriranje otpremnice u maloprodaju

Ova opcija omogućava ažuriranje već postojeće otpremnice u maloprodaju, ukoliko je došlo do greške prilikom unosa podataka.

Osnovni tok:

1. Korisnik startuje formu “Otpremnica u maloprodaju, “ izborom odgovarajuće opcije u glavnom programu. Forma koja se otvori ima omogućene samo dve opcije: dugme “Novi“ i dugme “Učitaj“. Ovog puta korisnik bira dugme: “Učitaj dokument“. Klikom na dugme učitaj, otvara se nova forma gde korisnik može da izabere željeni dokument. Klikom na enter forma se zatvara, a sistem učitava podatke o unetom dokumentu.

2. Korisnik može promeniti datum dokumenta, inicijalno u tom polju se nalazi originalni datum

3. U sledećem koraku moguće je promeniti maloprodaju klikom na dugme: “Izbor maloprodaje“, otvara se odgovarajuća forma (extend (Izbor Maloprodaje)). Korisnik bira željenu maloprodaju i vraća se u program.


5. U polje “Količina“ unosi se količina robe koju je potrebno otpremiti u maloprodaju6. Klikom na dugme “-“ vrši se brisanje reda sa učitanim podacima o robi.7. Korisnik i sistem izvršavaju korake 4, 5, 6 sve dok je potrebno menjati podatke o robi8. Klikom na dugme ažuriraj, korisnik daje zahtev da se podaci snime, sistem proverava

da li su uneti podaci u redu i ažurira postojeći slog u bazi.

Alternativni tok – Nekorektan datum

1. Korisnik u polje “Datum dokumenta“, unosi pogrešan datum. Pod pogrešnim datumom se podrazumeva ili ne korektan format datuma ili datum koji je manji od datuma poslednjeg proknjiženog dokumenta tog tipa za ulogovani magacin. Sistem ga vraća na korak 2.

2. Polje “Datum dokumenta“je prazno, ukoliko korisnik ostavi polje: “Datum dokumenta“ prazno, sistem će ispisati odgovarajuću poruku i vratiti korisnika na korak 2

Alternativni tok – Polje “Maloprodaja“ prazno

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

Alternativni tok – Nekorektan izbor robe i količine

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

2. Ukoliko korisnik unese u polje “Količina“ vrednost koja će dovesti stanje robe u magacinu ispod 0, sistem će dati odgovarajuću poruku i vratiti korisnika na korak 5.


42


3.2.2.1 Sekvencni dijagram- Ažuriranje Otpremnice

Slika 3.2.2.1.1: Ažuriranje Otpremnice (Sequence Diagram)

43


3.2.2.2 Kolaboracioni dijagram- Ažuriranje Otpremnice

Slika 3.2.2.2.1: Ažuriranje Otpremnice (Collaboration Diagram)

44


3.2.2.3 Dijagram aktivnosti- Ažuriranje Otpremnice

Slika 3.2.2.3.1: Ažuriranje Otpremnice (Activity Diagram)

45


III.2.3 Brisanje otpremnice u maloprodaju

Ukoliko je potrebno u potpunosti poništiti “Otpremnicu u Maloprodaju“ koristi se ovaj slučaj korišćenja.

Osnovni tok:

1. Korisnik startuje formu “Otpremnica u maloprodaju“, izborom odgovarajuće opcije u glavnom programu. Forma koja se otvori ima omogućene samo dve opcije: dugme “Novi“ i dugme “Učitaj“. Ovog puta korisnik bira dugme: “Učitaj dokument“. Klikom na dugme učitaj, otvara se nova forma gde korisnik može da izabere željeni dokument. Klikom na enter forma se zatvara, a sistem učitava podatke o unetom dokumentu.

2. Klikom na dugme “Obriši“, korisnik daje zahtev da se podaci obrišu, sistem proverava mogućnost brisanja i briše postojeći slog u bazi.

Alternativni tok – Dokument je proknjižen

1. Sistem proverava da li je izabrani dokument već proknjižen na finansijskom nivou i ukoliko jeste daje odgovarajuću poruku.

Preduslovi


46


3.2.3.1 Sekvencni dijagram- Brisanje Otpremnice

Slika 3.2.3.1.1: Brisanje Otpremnice (Sequence Diagram)

47


3.2.3.2 Kolaboracioni dijagram- Brisanje Otpremnice

Slika 3.2.3.2.1: Brisanje Otpremnice (Collaboration Diagram)

48


3.2.3.3 Dijagram aktivnosti- Brisanje Otpremnice

Slika 3.2.3.3.1: Brisanje Otpremnice (Activity Diagram)

49


III.2.4 Dijagram klasa- Otpremnica

Slika 3.2.4.1: Otpremnica (Class Diagram)

50


III.3 Deployment dijagram

Slika 3.3.1: Šematski prikaz mreže

Aplikacija Poslovanje Magacina je informacioni sistem koji veći deo rada zasniva na lokalnoj mreži, ali je poželjno da se komunikacija između centara odvija preko WWW protokola. Na taj način omogućeno je korišćenje aplikacije od strane udaljenih klijenata preko Interneta. Na slici 3.4.1 nalazi se šematski prikaz mreže, a na slici 3.4.2 dat je deployment dijagram.

Slika 3.3.2: Deployment Diagram

51


IV RAZVOJ APLIKACIJE

Informacioni sistem magacinskog poslovanja razvijan je na savremen i modularan način. Kao razvojni alat korišćen je Microsoft Visual Studio 2003 i programski jezik Visual Basic.NET (VB.NET). Baza podataka u koju se smeštaju podaci je MS SQL server. Prilikom razvoja aplikacije akcenat je stavljen na brzinu rad, optimizaciju koda i stabilnost. Veliki broj radnih sati je utrošen na testiranje kako pojedinačnih modula tako i celog sistema.

IV.1 Razvojni alati

IV.1.1 Microsoft Visual Studio 2003

Visual Studio .NET je u potpunosti integrisano razvojno okruženje. Dizajnirano je tako da pisanje koda, ispravljanje grešaka i kompajliranje u gotove sklopove bude što jednostavnije. Ovo u praksi znači da Visual Studio .NET daje jako sofisticiranu aplikaciju sa različitim interfejsima dokumenata u kojim se može uraditi sve što je povezano sa razvojem koda. Visual Studio .NET nudi [13]:

Program za editovanje koda kojima se može pisati kako VB.NET tako i C# i C++ kod. Editor je veoma sofisticiran koji je upoznat sa sintaksom koda u kojem se piše aplikacija. To znači kako programer kuca kod editor uređuje: uvlači linije, boji ključne reči, povlači sintaksne greške. Takođe poseduje i IntelliSense: kako se kuca kod prikazuju se imena klasa, polja i metoda (Slika 5.1.1.1).

52


Slika 5.1.1.1: IntelliSense u akciji

Editor dizajna omogućava u projektu vizuelno stavljanje kontrola i podešavanje svojstava. Visual Studio .NET automatski dodaje kod u izvorne datoteke za instanciranje dodatih kontrola i promenu vrednosti svojstva.

Kompajliranje iz okruženja umesto pokretanja kompajlera iz komandne linije, dovoljno je pozvati odgovarajuću komandu iz menija Visual Studio .NET-a. Kompajleru će biti prosleđeni svi relevantni parametre uključujući koje sklopove treba referencirati i koje tipove sklopova treba uključiti.

Integrisana MSDN pomoć - Visual Studio .NET omogućava pozivanje odgovarajućeg MSDN dokumenta pritiskom na dugme F1. Ukoliko se kursor nalazi na nekoj ključnoj reči u prozoru za pomoć biće prikazani svi relevantni podaci.

Prilikom razvoja projekta Informacioni sistem magacinskog poslovanja korišćen je Visual Basic. NET (VB.NET) programski jezik. VB.NET praktično osim sintakse nema mnogo dodirnih tačaka sa svojim prethodnikom Visual Basic-om 6.0 koji se ne može ni kompajlirati kao VB.NET kod. Praktično on se može smatrati potpuno novim jezikom.

VB.NET je jezik koji ima dve posebno značajne strane:

Reč je o programskom jeziku koji je zamišljene i napravljen za korišćenje u Microsoft-ovo radnom okviru . NET Framework-a.

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

Važno je napomenuti da je VB.NET poseban programski jezik. Iako je napravljen da generiše kod koji je usmeren u .NET okruženju VB.NET nije njegov integralni deo. Postoje neke funkcije koje radni okvir .NET podržava, a programski jezik VB.NET ne podržava. Radni okvir .NET je razvijen sa ciljem da obezbedi okruženje iz koga se može programirati bilo kakva aplikacija namenjena operativnom sistemu Windows (mada su se pojavili i projekti kao što je Mono koji omogućavaju izvršavanje .NET aplikacija i pod Linux-om)

Slika 5.1.1.2 Arhitektura Frameworka

53


Centralni deo radnog okvira .NET-a predstavlja njegovo izvršno okruženje koje se naziva Common Language Runtime (CLR) ili .NET Runtime (Slika 5.1.1.2). Za kod koji se izvršava pod kontrolom CLR komponente se često naziva kontrolisani (managed) kod [14].

.NET sledi logiku JAVA programskog jezika koji koristi virtuelnu mašinu. Ekvivalent Virtuelnoj mašini je upravo CLR. Međutim da bi se neki kod izvršavao pod CLR-om neophodno je da izvorni kod prođe kroz dve etape:

Kompajliranje izvornog koda u Microsoft Intermediate Language (MS-IL). Kompajliranje IL koda u konkretan platformski kod koji izvršava komponenta CLR.

Dvostruko kompajliranje koda na prvi pogled je bezrazložno, međutim upravo ovo omogućava brojne prednosti:

Nezavisnost u pogledu platforme. Datoteka koja sadrži instrukcije bajkoda može se koristiti na bilo kojoj platformi jer se poslednja faza kompajliranja vrši prilikom izvršavanja aplikacije. Drugim rečima kompajliranjem u IL u radnom okviru .NET-u dobijena je nezavisnost u pogledu platforme na isti način na koji kompajliranje Java bajtkoda omogućava platformska nezavisnost programskog jezika Java.

Poboljšanje performansi. Iako se .NET okvir može porediti sa programskim jezikom Java, među jezik IL je efikasniji jer on uvek kompajlira u pravo vreme (Just- in-Time, JIT) dok se Java bajtkod uvek interpretira. Na taj način 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.

Jezička interoperabilnost. Pored platformske nezavisnosti, IL omogućava i jezičku. Jednostavno rečeno, projekat bilo pisan u VB.NET-u kompajlira se uvek u među jezik IL. Tako dobijen kod je u potpunosti interoperabilan sa kodom koji je izvorno bio napisan bili u C# ili u C++.

IV.1.2 Microsoft SQL Server 2000

Današnje poslovanje zahteva savremeno rešenje za rad sa bazama podataka. Performanse i mogućnost proširenja i nadogradnje su naravno osnova sistema. Ipak, pravi značaj dolazi sa mogućnošću da se analizom sirovih podataka dobiju strateške odluke u vođenju posla i u potpunosti iskoriste prednosti koje daje elektronska trgovina. Tu mogućnost 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 funkcionišu na nivou velikih poslovnih sistema. Nosilac važnih rekorda merenja u oblasti skalabilnosti i brzine, SQL Server 2000 je baza podataka u potpunosti prilagođena poslovanju preko Weba kojoj je pridodata snažna podrška za XML i mogućnost obavljanja upita preko Interneta izvan granica koje postavlja Firewall zaštita (Slika 5.1.2.1) [15].

54


Slika 5.1.2.1: Microsoft SQL Server

IV.2 Arhitektura aplikacije

Informacioni sistem magacinskog poslovanja je mešavina Windows i Web aplikacije. Akcenat je stavljen na Windows deo, odnosno Windows forme u kojim se obavlja veći deo manipulacije podataka, dok deo koji se čine Web forme služi za pregled stanja po magacinima i mesečne analize. Na ovaj način je omogućena brza manipulacija podacima, korišćenje barkod čitača prilikom unosa podataka, a sa druge strane mogućnost sagledavanja podataka sa bilo koje tačke na svetu.

Dvostruki prezentacioni sloj je zahtevao specifičnu arhitekturu aplikacije. Na samom početku 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 omogućiti da aplikacija radi sa različitim bazama podataka. Inicijalno to je MS SQL server, ali u zavisnosti od obima poslovanja u budućnosti to može biti i Oracle. Pored toga baza se nalazi samo na jednom server u okviru samo jednog distribuiranog centra.

55


Slika 5.2.1: Arhitektura Aplikacije

Kako bi aplikacija uspešno odgovorila na sve postvaljenje zahteve, bilo je neophodno jasno identifikovati i podeliti slojeve (Slika 5.2.1). Informacioni sistem magacinskog poslovanja se sastoji od sledećih slojeva:

Prezentacioni Business Brokeri Baza podatka

IV.2.1 Prezentacioni sloj

Prezentacioni sloj je okrenut korisnicima, to je deo aplikacije koji služi za komunikaciju sa korisnicima i praktično jedini deo koji se vidi sa korisničke strane. Aplikacija je rađena u potpunoj filozofiji tankog klijenta, tako da se kao na Windows formama nalazi samo kod neophodan za manipulaciju kontrolama i za pozive validacija.

56


4.2.1.1 Forme

Windows Client projekat (u okviru koga se nalaze sve Windows forme) je glavni klijentski deo sistema, sadrži korisnički interfejs koji preko Web servisa vrši interakciju sa serverskim delom sistema i sa njim čini kompletan sistem. Korisnički interfejs je namenjen familiji Windows operativnih sistema, a radi što manjeg opterećenja klijenta i lakše implementacije za ostale platforme namenjeno je da sadrži samo osnovnu funkcionalnost potrebnu za funkcionisanje logike korisničkog interfejsa (Listing 5.2.1.1.1). Tako bi se gotovo sve funkcije vezane za funkcionisanje poslovne logike sistema nalazile na serveru, što bi olakšalo isporuku i održavanje sistema kao i značajnu nezavisnost klijenta od servera (decoupling, decoupled) što olakšava implementaciju klijenata za druge platforme. Pored toga ovaj projekat sadrži osnovna podešavanja vezana za klijentski deo sistema, klase raznih namena, kao i centralizaciju pristupa Web servisu.

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 pomoćnih 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 sadrži funkcije za jednostavan poziv i prikaz MessageForme AssemblyResources, klasa koja izvlači stringove i druge objekte iz resursa za trenutni

jezik. MenuTreeBuilder, klasa koja generiše osnovni meni. Login, klasa za proveru prijave korisnika SplashForm, uvodna forma LoginForm, forma za prijavu korisnika Settings, klasa koja sadrži podešavanja koje se koriste u toku rada sistema, sama

podešavanja se čuvaju u .ini fajlu. SystemCheck, klasa koja vrši proveru konfiguracije korisničkog računara SystemInformation, klasa koja vrši detekciju konfiguracije korisničkog računara i

čuva podatke u svojim atributima

Na slikama 4.2.1.1.1 do 4.2.1.1.4 dati su primeri Windows formi.

57

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 IfEnd Sub


Slika 4.2.1.1.1: Forma za unos Partnera

Slika 4.2.1.1.2: Forma za pregled Magacinske kartice

58


Slika 4.2.1.1.3: Forma za unos Otpremnice kupcu

Slika 4.2.1.1.4: Forma za unos grupni pregled dokumenata

IV.2.2 Business Sloj

Biznis sloj je jezgro celog sistema. Sadrži poslovne objekte i funkcije koje se koriste u različitim delovima sistema. U njemu su implementirani sigurnosni mehanizmi, poslovna pravila i podešavanja 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 kaširanja optimizuju i ubrzavaju njihovo korišćenje kao i kontrola izvršenja funkcija koja trajno menjaju sistem.

59


Prilikom pravljenja poslovnog sloja išlo se logikom jedna tabela, jedna klasa. Dakle za svaku tabelu sistema postoji odgovarajući poslovni objekat koji sadrži sve validacije, potpunu logiku. Ukoliko je potrebno izmeniti neko pravilo te izmene se vrše samo na ovom sloju. Svaki od poslovnih objekata pristupa bazi podatak preko odgovarajućeg brokera, koji je vezan za određenu tabelu. Ukoliko je potrebno izvršiti snimanje/ažuriranje/brisanje podataka iz više tabela pod jednom transakcijom, startovanje i završavanje transakcije se obavlja upravo u ovom sloju (Listing 4.2.3.1).

60


Listnig 4.2.3.1: Primer Biznis objekta

61

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 regionEnd class


Unutar poslovnog sloja pored odgovarajućih biznis objekata za svaku od tabela nalaze se još sledeće klase:

ClientLoginInfo, sadrži atribute korisnika koji želi da se prijavi na sistem ClientSecurityInfo, sadrži podatke koje klijent mora poslati serveru da bi mogao da

izvrši bilo koju funkciju nad sistemom SessionKey, javni ključ koji se koristi u sigurnosnim mehanizmima Settings, čuva podešavanja vezana za sigurnost

IV.2.3 Brokeri

Projekat brokeri čini skup klasa koje služe za komunikaciju sa bazom. Njihov zadatak je izvlačenje, unos, brisanje i ažuriranje podataka. Za svaku od tabela u bazi podataka postoji posebna klasa koja služi za rada upravo i samo sa njom. Prilikom određivanje zadataka koje treba da ispuni aplikacija jedan od najbitnijih je bila nezavisnost od baze podatak. Sistem treba da ima mogućnost rada sa bili kojom bazom uz što manje izmene. Ova modularnosti je postignu implementacijom osnovnih klasa koje služe za pristup DBMS-u (broker, konekcija, transakcija) i konkretnim klasama koje predstavljaju implementaciju pristupa za tačno određenu bazu. Na taj način preko jedinstvenog interfejsa na osnovu parametra koji određuje koja se baza koristi, poslovni objekat dobija konkretnu implementaciju brokera. Ova funkcionalnost je za sada implementirana za MS SQL Server, a ukoliko se pokaže potreba biće implementirana i za druge baze.

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

IDatabaseBroker, definiše osnovni interfejs za brokera IDatabaseConnection, interfejs za konekciju IDatabaseTransaction, interfejs za transakciju DataAccessExceptionBase, klasa za osnovnu grešku koja se može dogoditi u radu sa

bazom Environment, klasa koja izvlači podešavanja 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 podešavanja u sistemu instancira konkretnog brokera za konkretni DBMS (Slika 5.2.4.1).

IV.2.4 Baza podataka

Informacioni sistem magacinskog poslovanja koristi MS SQL Server kao bazu podataka. Firma je Microsoft partner i aplikacija je rađena u potpunosti u Microsoft-ovoj tehnologiji tako da je i MS SQL server bilo prirodno rešenje za smeštanje podatak. Međutim kako je već u prethodnim tačkama navedeno, jedan od osnovnih zahteva je bila što veća nezavisnost aplikacije od konkretnog tipa baze, što je uslovilo potpuno premeštanje logike upita sa baze na kod. Izuzev stored procedure-a (Listing 5.2.5.1) za unos, izmenu i brisanje podatak sve

62


ostale nemaju svoju implementaciju na MS SQL serveru već u kodu u odgovarajućem brokeru. Na ovaj način dovoljno je implementirati broker (prilagoditi upite) za novi tip baze i aplikacija je spremna za rad na novoj bazi.

Listing 4.2.5.1 Primer stored procedure za ažuriranje tabele Mesto

63

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)ASIF @FORCE=1BEGINUPDATE MESTOSET KOD_ZEMLJE=@KOD_ZEMLJE, NAZIV=@NAZIV, OPIS=@OPIS, PTT=@PTTWHERE (MESTO_ID=@ORIGINAL_MESTO_ID)ENDELSEBEGINUPDATE MESTOSET KOD_ZEMLJE=@KOD_ZEMLJE, NAZIV=@NAZIV, OPIS=@OPIS, PTT=@PTTWHERE (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)ENDRETURN


V DATA WAREHOUSING I OLAP

Skladištenje podataka ili Data Warehousing jeste proces integracije podataka u jedan repozitorijum iz kojeg krajnji korisnici mogu sprovoditi ad-hock analize podataka i praviti izveštaje. Zbog velike količine podataka skladišta podataka imaju tendenciju da postanu ogromna, što je uslovilo potrebu za visokim performansama hardverskog i softverskog obezbedjenja.Glavni posao leži u analizi izvornih podataka i procesa, tj moraju se poznavati procesi za transakcionu obradu podataka, sa ciljem zapisivanja poslovnih pravila bez grešaka. Skladište podataka je baza podataka za procese podrške odlučivanju u kojoj su podaci:

Subjektno orjentisani – odslikavaju poslovne procese Integrisani – baza podataka konsoliduje podatke iz različitih 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ć postojećim podacima.

5.1 DATAMART

Datamart je subjektivno orjentisani pogled na skladište podataka. On sadrži značajno manje podataka od „skladišta podataka“ i predstavlja objekt analitičkog procesiranja od strane korisnika. Datamartovi su subjektivno orjentisane multidimenzione baze podataka sa životnim ciklusom od tri godine. Mnogi datamartovi su podskup velikih skladišta podataka.Operator može da koristi OLAP alate i napravi izveštaj od informacije iz jedne tabele u datamartu koristeći bilo koju kolonu kao selekcioni kriteijum.

5.2 OLAP SISTEMI

Interaktivno analitičko procesiranje (on line analitical procesing - OLAP) namenjeno je on line analizama i izveštajima, za razliku od produkcionih sistema namenjenih ažuriranju podataka i obradi transakcija ( on line transaction procesing - OLTP). Donosiocima odluka su potrebni odgovori na pitanja koji direktno utiču na njihovu mogućnost da budu kompetentni na današnjem brzo promenljivom tržištu. U tu svrhu se koriste OLAP sistemi. Osnovni elemnti OLAP sistema su:

Baza podataka, koja služi kao osnova za anlizu OLAP server, za upravljanje i manipulaciju podacima Interfejs sistem, prema korisniku i prema drugim aplikacijama Alati za administriranje

Za korišćenje OLAP složene procedure potrebno je transakcione podatke prebaciti u posebnu bazu podataka. OLAP pristup mora od hardvera da poseduje poseban računar, tzv. OLAP server, na koji se povezuju relacione baze podataka, eksterni izvori podtaka i ostali interni podaci, koji su podržani grafičkim interfejsima.OLAP serveri koriste višedimenzionalne strukture za čuvanje podataka i veza izmedju njih. Višedimenzionalne strukture se naljbolje vizuelizuju kao kocke podataka i kao kocke u

64


kockamapodataka. Svaka strana kocke se naziva dimenzijom, svaka ćelija kocke sadrži agregirane podatke koji su u vezi sa dimenzijom.

Postoje sledeće arhitekture OLAP sistema: Višedimenzionalani OLAP (MOLAP) Relacioni OLAP (ROLAP) Hibridni OLAP (HOLAP)

MOLAP i ROLAP se razlikuju po načinu fizičkog čuvanja podataka.Višedimenzioni OLAP – MOLAP baza podataka ima ograničene fizičke veličine skupa podataka sa kojima mogu da barataju. Da bi se izvršila bilo kakkva analiza podataka moraju se prvo učitati podaci u višedimanzione strukture. Prednost MOLAP sistema je što obezbedjuje odlične performanse sistema kada se radi sa već sračunatim podacima.Relacioni OLAP – ROLAP sistemi pristupaju podacima direktno iz skladišta podataka i rade sa relacionim bazama podataka. Ovi sistemi mogu da rade sa velikim skupovima podataka. Čim se odredi izvor podataka , korisnik može započeti analizu. Kod ROLAP sistema nhe postoje ograničenja što se tiče dimenzija sistema.Možda najbolje rešenje predstavlja HOLAP, čiji alati mogu pristupati i relacionim i višedimenzionim bazama podataka. Cilj korišćenja HOLAP alata jeste da se iskoriste prednosti MOLAP alata. Pri tome se ne može reći da je HOLAP prosti zbir MOLAP-a i ROLAP-a. To je zapravo ROLAP koji ima mogćnost izvršavanja vrlo složenih SQL naredbi.Kreiranje OLAP kocni korišćenjem Cube Wizard-a integrisanog u Microsoft Query vrši se na osnovu predhodno definisanih upita nad skladištem podataka. U magacinskom poslovanju za kreiranje OLAP kocke koristićemo tabelu Stavka magacinskog dokumenta, a od kolona uzimamo Naziv robe, Ulaz, Izlaz i Stanje. Proces kreiranje kocke se odvija koroz sledeće korake:

1. Po strartovanju MS Query-a izabere se tip baze podataka (u ovom slučalu SQL) i pronadje odgovarajuća baza podataka. Izabere se tabela i kolone na osnovu kojih će se vršiti kreiranje kocke.

2. Zatim i z menija odabiramo Create OLAP Cube3. Ovo predstavlja prvi korak u formiranju OLAP kocke gde se odredjuju polja koja

formiraju sumarne podatke i matematičke operacije koje će se izvršavati nad tim apoljima. Polja koja se ne koriste za sumarne podatke predstavljaju kandidate za dimenzije kocke.

4. U ovom koraku se vrši formiranje hierarhije dimenzija. Hierarhija dimenzija treba da omogući više nivoa detaljnosti, u zavisnosti od potreba korisnika.

5. Vršimo čuvanje kocke (odabirom Save As iz menija).Na osnovu ovako kreirane OLAP kocke vrši se kreiranje pivot tabele za pristup podacima pomoću Microsoft Exel-a.Iz menija Data u Microsoft Exel-u biramo Import data, i otvaramo predhodno kreiranu OLAP kocku. Na osnovu ove kocke vrši se formiranje pivot tabele.

65


Slika 5.1: Pivot tabela

Zatim se na osnovu formirane pivot tabele koja je prikazana na slici 5.1 vrši kreiranje grafika, odnosno kreira se grafički prikaz pivot tabele. Grafički prikaz pivot tabele prikazan je na slici 5.2.

Slika 5.2: Grafički prikaz pivot tabele

66


5.3 DATA MINING

Data mining je relativno nova tehnika analize podataka. Veoma je različita od upita i izveštaja, kao i od višedimenzionih analiza, po tome što koristi tehniku otkrivanja. Za razliku od upita, izveštaja i višedimenzionih analiza gde je korisnik morao da kreira i izvršava upite, data mining traži odgovore na pitanja koja predhodno ne moraju biti postavljena.Data mining se najtipičnije koristi za statističke analize podataka i otkrivanje znanja. Za prikaz Data Mining-a koristićemo SQL Server 2005. U integrisanom delu koji se naziva Bussines Intelligence Development Studio možemo koristiti Data Mining Wizard. U prvom koraku moramo da pokrenemo Analisis Services Project. Pošto 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 izvršiti ceo preojekat. Desnim klikom na Data Source pokrećemo 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 izvšimo analizu. Wizard se pokreće na identičan način kao i kod definisanja Data Sourca. U Solution Exploreru možemo kreirati i tzv. kocke podataka na osnovu kojih se kasnije formira pivot tabela i grafik. U Mining Structures meniju se pokreće glavni wizard preko koga takodje možemo 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 možemo da preskočimo tako što ćemo kliknuti na Next.3. Na strani Select the Data Mining Technique, možemo 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 izveštaji. Potrebno je na istoj strani definisati i jedinstveni kljič koji je karakterističan za tabelu.

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

67


Na ekranu nam se prikazuje tabela za koju smo kreirali model i klikom na tabove iznad možemo videti grafik i pivot tabelu.

VI VIZIJA

U savremenom poslovanju sve više se koriste WWW protokoli, tj razvijaju se aplikacije koje su WEB orjentisane. Za budući razvoj aplikacije Magacinskog Poslovanja planira se dodatak koji će upravo biti zasnovan na WEB servisima. Osnovni razlog ove dodatne implementacije jeste povezivanje centara i korišćenje 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 omogućavati preko brze internet konekcije (ADSL ili Wireles)Osnovni problem ovakvog načina poslovanja jeste zaštita podataka. Protokoli za prenos su nastali u prijateljski nastrojenoj sredini, što je Internet odavno prestao da bude. Samim tim se razvijaju i brojne zaštite koje omogućavaju sigurnosnu razmenu podataka na internetu. Najpoznatija zaštita jeste SSL (Secure Socet Layer) poznata po ikonici katanca koja se pojavljuje u Browseru.

68


VII ZAKLJUČAK

Poslovni sistemi već duži vremenski period su izuzetno složeni. Povećanjem konkurencije, napuštanjem granica zemlje i ciljanjem na globalni nivo – svetsko tržište, sistemi postaju razuđeni, distribuirani. Informacioni sistem koji ima zadatak da prati sve delatnosti sistema mora raditi na različitim lokacijama, u različitim platformama kako Web tako Windows, Linux, na različitim tipovima baza. Pored toga sistem mora imati više različitih pogleda, sa jedne strane treba da omogući prost i brz unos podataka od strane radnika/prodavaca, a sa druge strane različitim nivoima menadžera treba da obezbedi mogućnosti za složene analize tržišta, predviđanje poslovanja u budućem periodu i različite šta-ako analize. Sve ovo iziskuje složene i glomazne sisteme koje je izuzetno teško projektovati i pratiti. Na svu sreću UML tu može puno pomoći.

UML se nametnuo kao standard za projektovanje software-skih rešenja. Zahvaljujući bogatstvu jezika, moguće je pratiti razvoj projekta od apstraktne ideje analitičara, preko konkretnih klasa, aktivnosti pa sve do fizičkog rasporeda računara i mreže. Pored toga zahvaljujući analizi smanjuje se vreme izrade (programiranja) proizvoda, većina problema se identifikuju i rešavaju pre samog kodiranja, programeri na samom početku imaju sliku kako koji deo treba da izgleda, a održavanje proizvoda i uvođenje novih ljudi u razvoj više ne predstavlja noćnu moru.

Ukoliko kod nekoga još postoje nedoumice da li je u opšte potrebno projektovanje, analiza pre samog proces programiranja neka se samo zapita da li bi majstorima dozvolio da počnu sa gradnjom kuće bez detaljnog arhitektonskog plana. Ista analogija može se primeniti i na razvoj software-a.

69


VIII 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] Hitchhiker’s Guide to SQL Server 2000 Reporting Services, Peter Blackburn, Villiam

R. Vaughn – Addison – Wesley 2005[11] Projektovanje skladišta 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 analitičkih baza podataka – dr. Alimpije Veljović, dr. Angelina

Njeguš

70

http://en.wikipedia.org/wiki/UML

http://www.rational.com/uml/

http://www.UML.org/

Documents

Magacinsko Poslovanje