dr Alempije V.

Veljovi

PRAKTIKUM
iz Projektovanja informacionih sistema

Beograd, 2005.
alempije@beotel.rs 1

alempije@beotel.rs

Budi ljubazan prema ljudima dok se penje, jer e ih sresti kad bude silazio Vil Durant

alempije@beotel.rs

Predgovor
Praktikum je dodatna literatura za predmet Projektovanje informacionih sistema(PIS) i predstavlja dodatno objanjenje za udbenik Objektno modeliranje informacionih sistema (1). Ovaj praktikim nastao je kao rezultat rada sa studentima. Naime, pokazalo se da studenti neshvataju da je seminarski rad elaborat koji ima odgovarajua poglavlja i da predstavlja prvi korak koji oni ine u pravcu izrade projekata vezanih za PIS. Autorova elja je da se shvati da to to se "isprogramira" mora sadrati tano definisana poglavlja. Kako je cilj da se dobije korisnika aplikacija to se izlazi iz okvira ovog praktikuma i definie se fiziki model baze podataka i pogled na korisniku aplikaciju koji su dati u praktikumu za analizu informacioih sistema(2). Na ovaj nain se studenti izlaze iz sveta programera i uvode u profesionalni svet projektanata informacionog sistema. U uvodnom izlaganju definiu se osnovni principi UML korienjem RatinalRous CASE alata. U sledeem poglavlju definiu se UML dijagrami kroz korienje CASE alata RationalRous. Prikazani primeri su rezultat izrade projekata za pojedina preduzea (pogledaj literaturu), diplomskih radova i kolskih primera korienih u nastavi. Primeri su namerno pojednostavljivani i predstavljeni kao informatika ostrva da bi studenti shvatili sutinu. Prvi primer odnosi se na poslove fakturisanja kroz primer EDIFACT fakture. U ovom primeru su prikazani minimalni zahtevi za seminarski rad iz predmeta Projektovanje infromacionih sistema. Drugi primer se odnosi na poslove praenja ispita. Opisuje se proces prijavljuja ispit korienjem UML dijagrama, na osnovu kojih se izadjuje plan polaganja ispita i na kraju prati realizacija plana ispita i obradjuju spiskovi za ispit. Trei primer odnosi se na poslove izrade tehnolokog procesa korienjem UML dijagrama i to za procese odravanje tehnolokih lokacija, izrada tehnolokog postupka, definisanje parametara i izrada tehnolokih izvetaja i pregleda. etvrti primer se odnosi na poslove cirkulacije u biblioteci korienjem UML dijagrama. Ona ukljuuje voenje evidencije o lanovima cirkulacije u biblioteci, zaduivanje i razduivanje lanova sa naslovima, opominjanje korisnika i rezervisanje. Svi ovi primeri mogu da budu uzor za izradu sopstvenih korisnikih aplikacija. Kako je ovo prvo izdanje ovakvog praktikuma to autor oekuje od buduih korisnika korisne sugestije i obeava da e drugo izdanje sadrat i neke druge primere.

alempije@beotel.rs

Autor

alempije@beotel.rs

Sadraj

1. Uvod............................................................................................9 2. Vizuelno modeliranje..................................................................11 3. Poslovi fakturisanja...................................................17 4. Poslova praenja ispita...............................................................26. 5. Poslovi izrade tehnolokog postupka..........................................43 6. Poslovi cirkulacije u biblioteci......................................................54

alempije@beotel.rs

alempije@beotel.rs

1. Uvod
U ovom praktikumu prikazan je na konkretnim primerima UML kao metod za opisivanje detalja arhitekture sistema korienjem CASE alata Rational Ruse. CASE alat Rational Rose je jedan od alata koji podrava razvoj aplikacija koristei UML. On omoguava kreiranje dijagrama sluajeva upotrebe, aktivnosti, sekvenci, saradnje, stanja, komponenti i razmetaja. Pomou inenjeringa i reinenjeringa CASE alat Rational Rose omoguava generisanje programskog koda u programskim jezicima C++, Java, Visual Basic i XML DTD. Takoe, postoje dodaci za ostale objektno-orjentisane programske jezike. Alat Rational Rose poseduje dodatne funkcionalnosti, kao to je razvoj Web aplikacija. Neke od novina koje donosi alat Rational Rose su: Modeliranje procesa, Dijagrami aktivnosti, Web modeliranje, Podrka za programski jezik Java i J2EE, Podrka za EJB, Podrka za XML DTD, Modeliranje podataka, Podrka za programski jezik ANSI C++, Podrka za SQL Server 2000 i Podrka za Sun Java Server Pages i Microsoft Active Server Pages. Izdvojio bih na samom poetku svoje miljenje o modeliranju procesa jer smatram da za modeliranje procesa mnogo bolje koristiti semantiki bogatiji standard IDEF0 prikazan u (2) i realizovan kroz CASE alat Bpwin.. Rational Rous ranijih verzija nije ima modelar podataka to je predstavljao veliki nedostatak a smatram da trenutni modelar moe da posluI samo kao prelazno reenje za korienje profesinalnijih modeara podataka kao to je Erwin koji realizovan korienjem standarda IDEF1X i prikazan je u (2). Ovaj praktikum je namenjena programerima, arhitektama softvera i analitiarima a pogotovo onima koji nemaju mnogo iskustva sa UML-om i nisu ukljueni svi aspekti UML-a.

alempije@beotel.rs

2. Vizuelno modelovanje
Modeli u svetu softvera su planovi za sistem. Planovi pomau da se isplanira izgradnja pre nego to se stvarno krene na izradu aplikacija.Rezlutat procesa modelovanja je mogunost da se prate poslovni zahtevi. Vizuelno modelovanje je proces uzimanja informacija sa modela i njihovo grafiko prikazivanje korienjem niza standardnih grafikih elemenata. Standardi su neophodni kako bi se izvukla bitna korist od modelovanja: komunikacija. Komunikacija izmeu korisnika, programera, analitiara, menadera i svih onih koji su ukljueni u projekat, je osnovna svrha vizuelnog modelovanja. Komunikaciju moete ostvariti korienjem nevizuelnih (tekstualnih) informacija, ali ipak ljudi mogu vizuelno mnogo lake prihvatati i uoavati stvari. Jedno od vanih pitanja u vizuelnom modelovanju je grafika notacija i koristi se za opis razliitih aspekata sistema. Ta notacija mora da bude poznata svim zainteresovanim grupama, u suprotnom model nee biti koristan. Do sada su mnogi predlagali koju notaciju koristiti za vizuelno modelovanje. Neke od popularnih notacija, koje imaju jaku podrku, su Buova notacija, OMT (eng. Object Modeling Technology) i UML. Rational Rose podrava ove tri notacije, meutim, UML je standard koji je usvojen od veine korisnika i grupa za standardizaciju kao to su ANSI i OMG (eng. Object Managment Group). UML notacija je posledica saradnje Grady Booch-a, dr James Rumbaugh-a, Ivar Jacobson-a, Rebecca Wirfs-Brock, Peter Yourdon-a i mnogih drugih. Na poetku treba definisati granice do kojih e se ii u modelovanju poslovnih procesa. Da li se modeluje itava organizacija ili samo jedno odeljenje? Koji tokovi poslovnih procesa su bitni za projekat ?. Granice sistema kao i tokove poslovnih procesa definisali smo korenjem IDEF0 standarda realizovanim u BPwin CASE alatu u (2). Kad se definie obim projekta, veoma je vano okupiti pravi tim. Potrebni su pojedinci koji poznaju poslovne procese, kao i pojedinci koji poznaju modelovanje poslovnih procesa. Uopteno, lanovi tima ne moraju da budu informatiari, ak je bolje da ne budu. Informatiari vrlo brzo kreu ka reenju, dizajnu sistema, ne analizirajui dovoljno poslovne procese. Obavezni lanovi tima su: Voa tima - On treba da poseduje dovoljno znanja i o poslovnim procesima i o modelovanju poslovnih procesa. On ili ona e biti zaduen za koordinaciju napora lanova tima i za odravanje pravca rada.

alempije@beotel.rs

Predstavnik(ci) poslovnih procesa-Oni su predstavnici razliitih delova organizacije koje modelujemo. Oni treba da su dosta upoznati sa tokovima poslovnih procesa, ukljuujui i probleme koji se u njima javljaju i dobit od tih tokova poslovnih procesa. Predstavnik(ci) menadmenta kompanije-Neko ko ima autoritet da odlui koji e delovi ili poslovni procesi biti modelovani. Oni mogu da pomognu timu da razume tokove poslovnih procesa iz perspektive menadmenta. Opisom poslovnih procesa korienjem BPwina dobjamo semantiki bogat model koji predstavlja dobru osnovu za korienje UML dijagrama. Model u Rose-u je slika sistema iz razliitih perspektiva. Takav model ukljuuje sve UML dijagrame, aktere, sluajeve upotrebe, objekte, klase, komponente i vorove razmetaja elemenata sistema.Ovakav model opisuje ta e sistem sadrati i kako e raditi, tako da inenjeri koji razvijaju sistem mogu taj model koristiti kao skicu za izradu sistema. Crte je dobra analogija za Rose model. Kao to za izgradnju kue postoje crte koji omoguavaju da vie lanova tima, koji gradi kuu, imaju poglede iz razliite perspektive na te nacrte (vodoinstalateri, elektriari itd.), tako se modelom u Rose-u omoguava, razliitim dijagramima, da lanovi tima koji sistem projektuju imaju pogled iz razliitih perspektiva (korisnik, dizajneri, menaderi projekta, inenjeri koji vre testiranje itd.). Rational Rose podrava osam razliitih tipova UML dijagrama: dijagrame sluajeva upotrebe, dijagrame aktivnosti, dijagrame sekvenci, dijagrame saradnje, dijagrame klasa, dijagrame stanja, dijagrame komponenti i dijagrame razmetaja. UML dijagrami prikazuju sistem iz vie uglova i za taj zadatak se koriste: dijagram sluajeva upotrebe (Use-Case Diagram) je grafika ilustracija funkcionalnosti sistema (statiki pristup) koja prikazuje uesnike (Actor) i njihove veze sa sluajevima upotrebe (use cases) tj. to je korisniki pogled funkcionisanja sistema (ta sistem radi a ne kako sistem funkcionie ). Sluajevi upotrebe i uesnici su specijalne vrste klasa i njihovih relacija; dijagram klasa (Class Diagram) prikazuje skup klasa, interfejsa i saradnja i njihovih relacija. Dijagram klasa je statiki struktura klasa u sistemu koje izmedju sebe uspostavljaju relacija tipa asocijacija (veza sa svakom drugom), zavisnosti (jedna klasa zavisi/koristi se od druge klase), specijalizacije (jedna klasa je specijalizacija druge klase, i paketa (grupisanje u jednu jedinicu tj. paketi); dijagram sekvenci (Sequence Diagram) opisuje vreme trajanja poruke i nain su na koji objekti u sistemu medjusobno komuniciraju, ostvarujui oekivano ponaanje. Dakle, prikazuje se vremenska komponenta i poruke koje se prosledjuju izmedju objekata u cilju izvrenja posmatrane operacije. Objekti su imenovane ili neimenovane instance klasa, ali mogu da budu i instance drugih stvari kao to su saradnja, komponente ili vorovi. Dijagram sekvenci je grafika ilustracija dinamike interakcije gde objekti komuniciraju preko sekvenci poruka tj. prikazuje dinamiku saradnju izmedju objekata u vremenu. Dijagram sekvenci se moe prevesti u kolaboracioi i obrnuto; dijagram saradnje (Collaboration Diagram) definie komunikaciju, pa i veze izmedju 10
alempije@beotel.rs

objekata neophodne za ostvarivanje posmatrane komunikacije. Dijagram saradnje pored objekata i veza prikazuje i poruke koje objekti medjusobno prosledjuju, ostvarujui na taj nain oekivano ponaanje. Dijagram saradnje opisuje strukturnu organizaciju objekata koji alju i prikazuju poruke. dijagram promene stanja (State Diagram) je konani automat koji sadri stanje, prelaze, dogadjaje, i aktivnosti. Dijagram promene stanja je dinamiki dijagram koji prikazuje sekvencu stanja kroz koje objekat prolazi tokom vremena (tokom ivotnog veka), a kao reakcija na spoljne ili unitranje pobude (vezan za samo jedan objekat i odredjenu operaciju unutar njega za odredjenu klasu); Opis stanja obuhvata aktivnosti koje se izvravaju u pojedinim stanjima, akcije koje se izvravaju pri prelasku iz jednog stanja u drugo, kao i poruke koje uslovljavaju promenu stanja posmatranog objekta. Kreiranjem dijagrama promene stanja prikazuju se reakcije sistema izazvane dogadjajima. Dijagram promene stanja se moe prevesti u dijagram aktivnosti koji se fokusira na tok kontroje (i obrnuto). dijagram aktivnosti (Activity Diagram) prikazuje sekvencijalan tok aktivnosti, a sastoji se od: stanja, akcija i prelaza i slui za prikaz dinamikog odvijanja poslovnih proces; Dijagram aktivnosti opisuje aktivnosti koje se izvravaju u okviru jedne operacije tj. predstavljaju sam algoritam operacija. Dijagram aktivnosti je specijalna vrsta dijagrama promene stanja kojim se prikazuje tok od aktivnosti do aktivnosti kroz sistem. dijagram komponenti (Component Diagram) prikazuje fiziku strukturu korisnikog softvera (izvorni kod, binarni i exe kod). Dijagram komponenti prikazuje organizaciju i zavisnost izmedju skupa komponenti. Dijagram komponenti je povezan sa dijagramom klasa zbog toga to svaka komponenta ukazuje na jednu ili vie klasa, interfejsa ili saradnja; dijagram razvoja (Deployment Diagram) prikazuje konfiguraciju vremena procesiranja i komponente u njemu. vor dijagrama razvoja obuhvata jednu ili vie komponenti. Dijagram razvoja se koristi za prikaz statikog pogleda na arhitekturu tj. na fiziku strukturu hardvera i softvera.

Izrada eme baze podataka u RationalRous-u

Modeliranje baze podataka preporuuje se da se izvodi paraleno sa objektnim modeliranjem. Kako smo u (2) izmodelirali i izgenerisali baze podataka korienjem CASE alata ERwin postupkom reverznim inenjeringom u RationalRose modeliraemo model podataka u istom. Da biste poeli proces, potrebno je da izaberete Tools > Data Modeler > Reverse Engineer. Nakon toga biete upitani da li se radi reverzni inenjering iz DDL izvornika ili iz baze podataka. Ako izaberete DDL, biete upitani za DBMS koji elite da koristite i ime fajla. Ako izaberete bazu podataka, biete upitani za informacije o konekciji prema bazi podataka. Sledee, izaberite stavku(e) koje elite da provuete kroz reverzni inenjering. Tabele i ogranienja e biti uvek ubaeni, ali moete da odaberete i druge elemente. Kada zavrite, kliknite Next. Rational Rose e automatski da kreira emu u Logical view. Unutar nje bie sve tabele, ogranienja i drugi elementi modela iz Vae baze podataka. Ako Rational Rose detektuje bilo

alempije@beotel.rs

11

kakav problem tokom reverznog inenjeringa, upisae taj problem u prozor Log. Rose e takoe kreirati novu komponentu u Componenet view. Komponenta e reprezentovati bazu podataka. Kada to radite, Rational Rose e kreirati komponente baze podataka u Component view i tabele i druge elemente baze podataka u emi u Logical view. Kada jednom izvrite reverzni inenjering baze podataka, moete generisati objektni model ili izvriti sinhronizaciju koristei metode koje su ranije objanjene.

Generisanje objektnog modela iz modela podataka

Jedna nova osobina Rational Rose je sposobnost da automatski generie objektni model iz modela podataka. Ova osobina je posebno praktina kada radite na projektu koji dobijate reverznim inenjeringom iz neke ve postojee baze podataka ili aplikacije. Naravno, ova osobina je korisna i za druge tipove projekata. Bilo kada, kada elite da proverite konzistentnost objektog modela i modela podataka, ili elite da iskoristite mogunost reverznog inenjeringa. Ova osobina je veoma korisna i od velike pomoi. Nemaju sve konstrukcije u modelu podataka znaenje u objektnom modelu. Indeksi, procedure smetanja i drugi elementi baze podataka ne mapiraju se u objektni model. Na sledeoj slici prikazan je spisak elemenata modela podataka i njima odgovarajuih elemenata objektnog modela. Element modela podataka ema Tabela Kolona Tabela sa samo primarnim i spoljnim kljuevima Tabela bez primarnih i spoljnih kljueva Identifikujua veza Neidentifikujua veza Kardinalnost Indeks Baza podataka Ogranienje Domen Element objektnog modela Paket Klasa Atribut Veza vie prema vie Veza vie prema asocijativnom klasom Kompozitna agregacija Asocijacija Kardinalnost nema nema nema nema vie sa

Kreiranje objektnog modela iz modela podataka vri se na sledei nain: 1. Desni-klik na emu i izaberite Data Modeler > Transorfm to Object Model. 2. Unesite ciljno ime paketa. Ciljni paket je ime paketa koji e da bude kreiran u Logical view kako bi sauvao nove objekte.

12

alempije@beotel.rs

3. Unesite prefiks. Prefiks e da bude dodat na imena svih tabela od kojih nastaju klase u objektnom modelu. 4. Izaberite Include Primary Key polje potvrde da bi kreirali atribute za kolone primarnih kljueva kao i za druge kolone. Ako nije selektovano, Rose e generisati atribute samo za kolone koje nisu primarni kljuevi.

Kreiranje modela podataka iz objektnog modela

Kada se generie model podataka, Rational Rose e traiti klase sa perzistentim atributima. Moete da podesite da klasa bude Persistent ili Transient u standardnom prozoru specifikacije klase na kartici Detail. Ako elite da generiete tabelu za klasu, podesite je na Persistent. Paket sa klasama postae ema u modelu podataka. Ako ve postoji ema sa istim imenom, Rose e dodati nove klase kao tabele u emi. Pri tome, nee se promeniti tabele u emi ako se klase u objektnom modelu promene. U stvari, promene e biti zabeleene u log tako da ih moete primeniti ako elite. U sledeoj tabeli prikazan je spisak elemenata objektnog modela i njima odgovarajuih elemenata modela podataka. Element objektnog modela Paket Perzistentna klasa Atribut Operacija Veza vie prema vie Kompozitna agregacija Asocijacija Kardinalnost Asocijativna klasa Element modela podataka ema Tabela Kolona nema Meutabela Identifikujua veza Neidentifikujua veza Kardinalnost Meutabela

Kreiranje modela podataka iz objektnog modela vri se na sledei nain: 1. Kreirate bazu podataka u Component view. 2. Desni-klik na bilo koji atribut u klasama za koji elite da postane primarni klju u generisanoj tabeli. Izaberite Data Modeler Part of Object Identity. Ako ne izaberete primarne kljueve Rational Rose e kreirati primarni klju kao kolonu sa imenom "<table name>ID>". 3. Desni-klik na paket u Logical view i izaberite Data Modeler > Transform to Data Model. 4. Unesite ciljno ime eme koje predstavlja ime eme koja e biti kreirana da bi sadrala nove elemente podataka. 5. Unesite ciljnu bazu podataka koja predstavlja naziv postojee baze podataka u Component pogledu. 6. Unesite prefiks koji e da se doda svakoj klasi koja kreira neku tabelu u bazi podataka. 7. Izaberite Create Indexes for Foreign Keys polje potvrde da se automatski kreiraju indeksi za

alempije@beotel.rs

13

preneene kljueve.

Generisanje baze podataka iz modela podataka

Bilo kad tokom procesa projektovanja, moete da generiete bazu podataka ili DDL izvornik (script) iz modela podataka. Rational Rose Vam da izaberete jednostavno generisanje DDL-a, ili pokretanje DDL-a da bi kreirali bazu podataka. Rational Rose ima pomo (wizards) koji Vas vode kroz sam proces kreiranja baze podataka. Da biste poeli, desni-klik na emu koju elite da generiete i izaberite opciju Data Modeler > Forward Engineering. Nakon toga izaberite elemente koje elite da generiete: Sledei korak, jeste unoenje imena DDL fajla koji kreirate. Ako elite da kreirate DDL, ali ne i da je pokrenete, kliknite Next. U suprotnom izaberite Execute polje potvrde. Unesite informacije o konekciji za DBMS i pritisnite test Connection dugme da bi proverili da li su uneeni parametri ispravni. Pritisnite Finish da bi zavrili proces. Rational Rose e generisati DDL i opciono ga pokrenuti. Ako se pojavi neka greka Rational Rose e je upisati u prozor Log. Sve tabele, kolone i relacije u emi bie generisane u DDL ili bazu podataka. Naredni primer prikazuje tabelu u Rational Rose modelu.

14

alempije@beotel.rs

3. Poslovi fakturisanja

Uvod
Na primeru procesa fakturisanja, prikazae se faze objektnog modeliranja informacionog sistema definisanog u (1). Ovaj primer predstavlja svojevrsan vodi kroz definisanje osnovnih elemenata projekta razvoja informacionog sistema korienjem objektno orijentisanih CASE alata (Rational Rous). Osnove vezane za poslove fakturisanja date su u (2). Ovo je primer sa minimalnim zahtevima za izradu seminarskog rada za predmet Projektovanje informacionih sistema Potrebno je uraditi sledee: Izrada dijagrama sluajeva upotrebe Izrada dijagrama aktivnosti Izrada konceptualnog modela Izrada dijagrama sekvenci Izrada potpunih dijagrama klasa Izrada eme baze podataka

Izrada dijagrama sluajeva upotrebe za poslove fakturisanja

U daljem radu koristiemo CASE alata RationalRose koji u potpunosti podrava UML notaciju za modelovanje dijagrama sluaja korienja. Model se ne sastoji samo od dijagrama ve i od detaljnog opisa sluaja upotrebe. Slede dijagrami sluajeva upotrebe i tekstualni opis sluajeva upotrebe fakturisanje.

alempije@beotel.rs

15

Referent prodaje

Izrada fakture <<include>> <<include>>

<<extend>>

<<include>>

Partner Radnik

Analiza fakturisanja <<include>>

Analiticar prodaje

Referent oznacavanja Nacin placanja

<<include>>

Predmet poslovanja

Slika 3.1. Dijagram sluajeva upotrebe za poslove fakturisanja

Sluajevi upotrebe: Partner, Nain plaanja, Radnik i Predmet poslovanja

Kratak opis: Voenje podataka o aurnosti sifarnika Partnera, Nain plaanja, Radnika i Predmet poslovanja. Uesnici: Referent oznaavanja i Referent prodaje Uslovi koji moraju biti zadovoljeni pre izvravanja: Uvek aurni ifarnici. Opis: Svaka aplikacija mora imati aurne ifarnika. Tu se vode podaci o partnerima, nainu plaanja, radnicima i predmetima poslovanja. Izuzeci: Nema. Uslovi koji moraju biti zadovoljeni posle izvravanja: Uredna i tana evidencija zapisa.

Sluaj upotrebe: Izrada fakture

Kratak opis: Potreba za slanjem robe izaziva izradu fakture.

16

alempije@beotel.rs

Uesnici: Referent prodaje Uslovi koji moraju biti zadovoljeni pre izvravanja: Moraju biti azurni sifarnici. Opis: Referent prodaje evidentira faktire koje se fakturisu, proveri tanost podataka i tampa potrebnu fakturu . Izuzeci: (tampa ne tampa fakturu) proveriti da li u tampau ima papira; Uslovi koji Uslovi koji moraju biti zadovoljeni posle izvravanja: Poslata informacija analitiaru prodaje.

Sluaj upotrebe: Analiza fakturisanja

Kratak opis: Analiza fakturisanja na osnovi poslatih faktura. Uesnici: Analiticar prodaje Uslovi koji moraju biti zadovoljeni pre izvravanja: Evidentirana naplata potrazivanja po fakturi. Opis: Analiza faktura je osnova za praenje poslovanja . Izuzeci: (naslov ne postoji) pogledati da li su dobro uneti podaci za pretragu

Izrada dijagrami aktivnosti za poslove fakturisanja

Svaki dijagram aktivnosti, poinje startnom aktivnou koja se predstavlja ispunjenim crnim krugom. Dijagram aktivnosti definisan je plivakim stazama, stanjem i tranzicijom. Plivake staze ili procesori su referent prodaje, referent oznaavanja i analitiar prodaje i one specificiraju odgovornosti za delove celokupne aktivnosti i nemaju neku duboku semantiku. Stanja pripadaju stazama, a tranzicije mogu prelaziti iz jedne staze u drugu. Na sledeoj slici prikazan je dijagram aktivnosti za poslove fakturisanja.

alempije@beotel.rs

17

Referent prodaje

Referent oznacavanja

Analiticar prodaje

Evidencija partnera Evidentiranje fakture Evidencija i oznacavanje predmeta poslovanja Evidencija nacina placanja Evidencija placanja

Evidencija jednica mera Fakturisanje predmeta poslovanja

Generisanje fakture Izrada izvestaja menadzmentu

Izrada izvestaja knjigovodstvu

Slika 3.2. Dijagram aktivnosti za proces fakturisanje

Izrada konceptualnog modela za poslove fakturisanja

Sutina konceptualnog modela je skeniranje realnog sistema u potrazi za klasama objekata i znaenjem njihovih meusobnih veza. Moe se rei da svaka koncept u konceptualnom modelu opisan je dodeljenim atributima i nekim elementarnim operacijama. Na sledeoj slici prikazan je konceptualni model za proces fakturisanja.

18

alempije@beotel.rs

Slika 3.3. Konceptualni model za proces fakturisanja Iidentifikovani su sledei koncepti u konkretnom problemu realnog sistema: Sifarnici (Partner, Radnik, JednicaMere, NacinPlacanja i PredmetPoslovanja), Faktura, StavkaPlacanja i FakturaPredmetPoslovanja.

Izrada dijagrama sekvenci za poslove fakturisanja

Kod sekvencijalnih dijagrama naglasak je na vremenski redosled odvijanja poruka izmeu objekata razliitih klasa. Dakle, sekvencijalni dijagrami se crtaju na vremenskoj osi, i predstavljaju specifikaciju vremenski zahteva u pogledu ta sistem treba da radi u realnom vremenu. Vremenskim redosledom poruka u sekvencijalnom dijagramu opisae se logika odvijanja poslova fakturisanja za sluajeve upotrebe izrada fakture i analiza fakturisanja. Dakle, videe se ta podsistem treba da radi u realnom vremenu da bi obavio svoju funkciju predstavljenu sluajom upotrebe. Na sledeoj slici prikazan je dijagram sekvenci za proces izrada fakture.

alempije@beotel.rs

19

: Referent prodaje

: Faktura

: Radnik

: Partner

: FakturaPredmetPoslovanja

: PredmetPoslovanja

Unesi(FakturaID, BrojFakture, DatumFakture, OsnovFakturisanja) Izaberi(RadnikID) Izaberi(PartnerID) Unesi(FakturaID) Izaberi(PredmetPoslovanjaID) Unesi(Kolicina, JedinicnaCena) Izracunaj(Vrednost)

Slika 3.4. Dijagram sekvenci za proces izrada fakture Na sledeoj slici prikazan je dijagram sekvenci za proces analiza fakturisanja.

: Faktura : Analiticar prodaje Izaberi(FakturaID)

: NacinPlacanja

: StavkaPlacanja

: Radnik

Izaberi(NacinPlacanjaID)

Unesi(Iznos, Datum, BrojIzvoda) Izaberi(RadnikID)

Slika 3.5. Dijagram sekvenci za proces analiza fakturisanja

20

alempije@beotel.rs

Izrada dijagrama klasa za poslove fakturisanja

Dijagram klase se sastoji iz klasa i veza izmeu njih. Naziva se jo i dijagram statike strukture. Klasa predstavlja sloeni tip, kolekciju, struturu koja se sastoji od vie atributa (podata lanova) i operacija (metoda, funkcija lanica). Na sledeoj slici prikazan je potpuni dijagram klasa za poslove fakturisanja.
Partner NazivPartnera PIB TekuciRacun Adresa Mesto Telefon Izaberi(PartnerID) Faktura BrojFakture DatumFakture OsnovFakturisanja Vrednost Unesi(FakturaID, BrojFakture, DatumFakture, OsnovFakturisanja) Izaberi(FakturaID) 0..* 1..1 StavkaPlacanja BrojIzvoda Iznos Datum Unesi(Iznos, Datum, BrojIzvoda) 0..* 0..*

1..1

0..*

1..1

0..*

0..* 1..* FakturaPredmetPoslovanja Kolicina JedinicnaCena 1..* 1..1 Unesi(FakturaID) Unesi(Kolicina, JedinicnaCena) Izracunaj(Vrednost) 0..1 NacinPlacanja NazivNacinaPlacanja Izaberi(NacinPlacanjaID)

PredmetPoslovanja NazivPredmetaPoslovanja StaraSifra KlasifikacioniBroj Izaberi(PredmetPoslovanjaID) 0..* 0..1 JednicaMere Oznaka NazivJedinceMere

0..10..1 Radnik Prezime Ime JMBG Izaberi(RadnikID)

0..1

Slika 3.6. Dijagram klasa za poslove fakturisanja

Izrada eme baze podataka za poslove fakturisanja

Na sledeoj slici prikazan je fiziki model podataka definisan u Erwinu i i odgovarajui fiziki model podataka u RationalRous-u dobijen postupkom reverznog inzinjeringa iz skript fajla generisanog u Erwin-u.

alempije@beotel.rs

21

Partner PartnerID: Long Integer PIB: Text(50) NazivPartnera: Text(50) TekuciRacun: Text(50) Adresa: Text(50) Mesto: Text(50) Telefon: Text(50) ReferentOznacavanja: Long Integer

Faktura FakturaID: Long Integer BrojFakture: Text(50) DatumFakture: Date/Time OsnovFakturisanja: Text(50) PartnerID: Long Integer ReferentProdaje: Long Integer

StavkePlacanja FakturaID: Long Integer RedniBroj: Long Integer NacinPlacanjaID: Long Integer Iznos: Currency Datum: Date/Time BrojIzvoda: Text(50) AnaliticarProdaje: Long Integer

Fizicki model podataka u ERwinu(2)

PredmetPoslovanja Kolicina: Double PredmetPoslovanjaID: Long Integer JedinicnaCena: Currency NazivPredmetaPoslovanja: Text(50) KlasifikacioniBroj: Text(20) StaraSifra: Text(50) JedinicaMereID: Long Integer ReferentOznacavanja: Long Integer

FakturaPredmetPoslovanja FakturaID: Long Integer PredmetPoslovanjaID: Long Integer

NacinPlacanja NacinPlacanjaID: Long Integer NazivNacinaPlacanja: Text(50) ReferentOznacavanja: Long Integer

Radnik RadnikID: Long Integer JedinicaMere JedinicaMereID: Long Integer Oznaka: Text(20) NazivJediniceMere: Text(50) ReferentOznacavanja: Long Integer Sifrao: Text(50) Prezime: Text(50) Ime: Text(50) JMBG: Text(13)

Odelenje Sifrao: Text(50) Naziv: Text(50) Mesto: Text(50)

Partner PartnerID : IdentBroj PIB : Naziv NazivPartnera : Naziv TekuciRacun : Naziv Adresa : Naziv Mesto : Naziv Telefon : Naziv ReferentOznacavanja : IdentBroj 0..*

<<Non-Identifying>>

Faktura FakturaID : IdentBroj BrojFakture : Naziv DatumFakture : Datum OsnovFakturisanja : Naziv PartnerID : IdentBroj ReferentProdaje : IdentBroj 1 0..* <<Identifying>>

<<Identifying>>

StavkePlacanja FakturaID : IdentBroj RedniBroj : RedniBroj NacinPlacanjaID : IdentBroj Iznos : Iznos Datum : Datum BrojIzvoda : Naziv AnaliticarProdaje : IdentBroj 0..* 0..*

0..*

0..*

Model podataka u Rational Rous-u

<<Non-Identifying>> <<Non-Identifying>> 0..* <<Non-Identifying>> PredmetPoslovanja PredmetPoslovanjaID : IdentBroj NazivPredmetaPoslovanja : Naziv KlasifikacioniBroj : Oznaka StaraSifra : Naziv JedinicaMereID : IdentBroj ReferentOznacavanja : IdentBroj 0..* <<Identifying>> 1 0..* FakturaPredmetPoslovanja FakturaID : IdentBroj PredmetPoslovanjaID : IdentBroj Kolicina : Kolicina JedinicnaCena : Iznos <<Non-Identifying>>

0..* <<Non-Identifying>> 1

<<Non-Identifying>> 1 1 1 <<Non-Identifying>> 1 Radnik RadnikID : IdentBroj Sifrao : CHAR(18) Prezime : Naziv Ime : Naziv JMBG : JMBG <<PK>> PK_Radnik7() <<FK>> FK_Radnik9() 1 <<Non-Identifying>> NacinPlacanja 1 0..* NacinPlacanjaID : IdentBroj NazivNacinaPlacanja : Naziv ReferentOznacavanja : IdentBroj

JedinicaMere JedinicaMereID : IdentBroj Oznaka : Oznaka NazivJediniceMere : Naziv ReferentOznacavanja : IdentBroj 0..* 1

Slika 3.7. Model podataka

22

alempije@beotel.rs

Zakljuak
Na osnovu definisanih dijagrama pristupa se izradi dva sledea koraka. U prvom koraku prelazi se na definisanje server strane generisanjem baze podataka kao to je pokazano za ovaj primer u(2). Drugi korak podrazumeva izradu klijent strane u zavisnosti od potreba korisnika ili Web programiranjem ili korienjem Visual Basica ili na kraju i MS Access-om.

Literatura
1 Veljovi A. Objektno modeliranje informacionih sistema, Fakultet za poslovne studije, MEGATREND Univerzitet, 2003. godina 2. Veljovi A. Praktikum iz analize informacionih sistema, Fakultet za poslovne studije, MEGATREND Univerzitet, 2005. godina

alempije@beotel.rs

23

4. Poslovi praenja ispita

Uvod
Na primeru procesa praenja ispita, prikazae se faze objektnog modeliranja informacionog sistema definisanog u (1). Ovaj primer predstavlja svojevrsan vodi kroz definisanje osnovnih elemenata projekta razvoja informacionog sistema korienjem objektno orijentisanih CASE alata (RationalRous). Osnove vezane za poslove praenja ispita date su u (2). Ovo je primer sa minimalnim zahtevima za izradu seminarskog rada za predmet Projektovanje informacionih sistema i orjentisan sluajevima upotrebe (use case driven). Potrebno je uraditi za svaki sluaj upotrebe u okviru dijagrama sluajeva upotrebe: Dijagram aktivnosti Konceptualni model Dijagram sekvenci Dijagram klasa emu baze podataka

24

alempije@beotel.rs

Izrada dijagrama sluajeva upotrebe za poslove praenja ispita

U daljem radu koristiemo CASE alata RationalRose koji u potpunosti podrava UML notaciju za modelovanje dijagrama sluaja korienja. Model se ne sastoji samo od dijagrama ve i od detaljnog opisa sluaja upotrebe. Slede dijagrami sluajeva upotrebe i tekstualni opis sluajeva upotrebe praenja ispita.
<<include>> Studenti Prijavljivanje ispita <<extend>>

Polaganje ispita

Analiza ispita

<<include>>

<<include>> Nastavnik <<communicate>> Referent

Prodekan za nastavu

Izrada plana polaganja ispita

Slika 4.1. Dijagram sluajeva upotrebe za poslove praenja ispita

Poslovi vezani za sluaj upotrebe Prijavljivanje ispita

Za sluaj upotrebe Prijavljivanje ispita opisuje se sluaj upotrebe i definiu dijagram aktivnosti, dijagram sekvenci i dijagram klasa.

Sluaj upotrebe: Prijavljivanje ispita

Kratak opis: Prijavljivanje ispita ima za osnovu popunjavanje prijave za ispit. Uesnici: Referent i Student Uslovi koji moraju biti zadovoljeni pre izvravanja: Moraju biti azurni sifarnici.
alempije@beotel.rs

25

Opis: Student prilikom prijavljivanja ispita overava semestar, popunjavanje prijave za ispit i uplauje ispit. Referent izradjuje izvestaj o prijavljenim ispitima. Izuzeci: (tampa ne tampa fakturu) proveriti da li u tampau ima papira; Uslovi koji moraju biti zadovoljeni posle izvravanja: Poslata informacija studentskoj slubi u obliku spisak prijavljeni studenta po ispitima.

Dijagram aktivnosti: Prijavljivanje ispita

Dijagram aktivnosti Prijavljivanje ispita definisan je plivakim stazama, stanjem i tranzicijom. Plivake staze ili procesori su student i referent. Stanja pripadaju stazama, a tranzicije mogu prelaziti iz jedne staze u drugu. Na sledeoj slici prikazan je dijagram aktivnosti za poslove Prijavljivanje ispita

Studenti

Referent

Pocetak

Overa semestra [ ne ] [ da ] Popunjavanje prijave za ispit [ ne ] Prijava ubacena [ da ] Uplata ispita Izrada izvestaja o prijavljenim ispitima

Uplata izvrsena [ da ] [ ne ] Kraj

Slika 4.2. Dijagram aktivnosti za sluaj upotrebe Prijavljivanje ispita

Dijagram sekvenci: Prijavljivanje ispita

Prikazae se ta sluaj upotrebe Prijavljivanje ispita treba da radi u realnom vremenu da bi obavio svoju funkciju. Vremenskim redosledom poruka u sekvencijalnom dijagramu opisae logiku 26
alempije@beotel.rs

odvijanja poslova Prijavljivanja ispita za sluaj upotrebe Prijavljivanje ispita. Na sledeoj slici prikazan je dijagram sekvenci za proces Prijavljivanje ispita

: Prodekan za nastavu

: Fakultet

: Smer

: Rok

: PlanIspita

: Predmet

: Predavac

Izaberi(Fakulte... Izaberi(SmerID) Izaberi(RokID) Otvori(RokID, rbr) Izaberi(Predme...

Izaberi(PredavacID)

Definisi(DatumPolaganja, MestoPolaga...

Slika 4.3. Dijagram sekvenci za sluaj upotrebe Prijavljivanje ispita

Dijagram klasa: Prijavljivanje ispita

Dijagram klase Prijavljivanje ispita se sastoji iz klasa i veza izmeu njih. Klasa predstavlja sloeni tip, kolekciju, struturu koja se sastoji od vie atributa (podata lanova) i operacija (metoda, funkcija lanica). Na sledeoj slici prikazan je dijagram klasa za poslove Prijavljivanje ispita.

alempije@beotel.rs

27

Smer
(from Logical View)

Student
(from Logical View)

Naziv

1..1 Izaberi(SmerID)

BrojIndeksa Ime 0..* Prezime JMBG

Predmet 1..1 PrijavaIspita

(from Logical View) (from Logical View)

1..1

Naziv BrojCasova Semestar

0..*

0..*

KojiPutPolaze DatumPrijave Iznos

0..*

Izaberi(PredmetID) Unesi(StudentID) Izaber(ValutaID) Izaberi(ModelPlacanjaID) Unesi(KojiPutPolaza, DatumPrijave, Iznos) 1..1 0..* 0..*

Fakultet
(from Logical View)

1..1 1..1 Valuta

(from Logical View)

Naziv ZiroRacun Izaberi(FakultetID)

ModelPlacanja
(from Logical View)

BrModela

NazivValute

Slika 4.4. Dijagram klasa za sluaj upotrebe prijavljivanje ispita

Poslovi vezani za sluaj upotrebe Izrada plana polaganja ispita

Za sluaj upotrebe Izrada plana polaganja ispita opisuje se sluaj upotrebe i definiu dijagram aktivnosti, dijagram sekvenci i dijagram klasa.

Sluaj upotrebe: Izrada plana polaganja ispita

Kratak opis: Izrada plana polaganja ispita definie termine polaganja ispita. Uesnici: Prodekan za nastavu i Nastavnik Uslovi koji moraju biti zadovoljeni pre izvravanja: Konsultovani nastavnici i pregled raspoloivih prostorija. Opis: Izrada plana polaganja ispita poinje sa izradom pregleda nepolozenih ispita, i utvrdjivanjem raspolozivosti prostorija i utvrdjivanjem raspolozivosti nastavnika. Na osnovu ovih 28

alempije@beotel.rs

elemanata odredjuju se termini ispita. Izuzeci: Nema. Uslovi koji moraju biti zadovoljeni posle izvravanja: Uredna i tana evidencija zapisa.

Dijagram aktivnosti: Izrada plana polaganja ispita

Dijagram aktivnosti Izrada plana polaganja ispita definisan je plivakim stazama, stanjem i tranzicijom. Plivake staze ili procesori su Prodekan za nastavu i Nastavnik. Stanja pripadaju stazama, a tranzicije mogu prelaziti iz jedne staze u drugu. Na sledeoj slici prikazan je dijagram aktivnosti za poslove Izrada plana polaganja ispita
Referent

Izrada pregleda nepolozenih ispita

Utvrdjivanje raspolozivosti nastavnika

[ ne ]

Raspolozivost nastavnika [ da ] Utvrdjivanje raspolozivo...

[ ne ] [ da ] Odredjivanje termina ispita

Slika 4.5. Dijagram aktivnosti za sluaj upotrebe Izrada plana polaganja ispita

Dijagram sekvenci: Izrada plana polaganja ispita

Prikazae se ta sluaj upotrebe Izrada plana polaganja ispita treba da radi u realnom vremenu

alempije@beotel.rs

29

da bi obavio svoju funkciju. Vremenskim redosledom poruka u sekvencijalnom dijagramu opisae logiku odvijanja poslova Izrada plana polaganja ispita za sluaj upotrebe Izrada plana polaganja ispita. Na sledeoj slici prikazan je dijagram sekvenci za proces Izrada plana polaganja ispita

: Prodekan za nastavu

: Fakultet

: Smer

: Rok

: PlanIspita

: Predmet

: Predavac

Izaberi(Fakulte... Izaberi(SmerID) Izaberi(RokID) Otvori(RokID, rbr) Izaberi(Predme...

Izaberi(PredavacID)

Definisi(DatumPolaganja, MestoPolaga...

Slika 4.6. Dijagram sekvenci za sluaj upotrebe Izrada plana polaganja ispita

Dijagram klasa: Izrada plana polaganja ispita

Dijagram klase Izrada plana polaganja ispita se sastoji iz klasa i veza izmeu njih. Klasa predstavlja sloeni tip, kolekciju, struturu koja se sastoji od vie atributa (podata lanova) i operacija (metoda, funkcija lanica). Na sledeoj slici prikazan je dijagram klasa za poslove Izrada plana polaganja ispita.

30

alempije@beotel.rs

(from Logical View)

Smer

(from Logical View)

Rok

Naziv Izaberi(SmerID) 0..*

0..1

0..*

Naziv Izaberi(RokID) 1..1

0..* Predmet
(from Logical View)

PlanIspita

(from Logical View)

(from Logical View)

1..1 Fakultet

Naziv BrojCasova Semestar 0..*

DatumPolaganja MestoPolaganja 1..1 0..* Otvori(RokID, rbr) Izaberi(PredavacID) Izaberi(PredmetID) Definisi(DatumPolaganja, MestoPolaganja) 0..* 0..1
(from Logical View)

Naziv ZiroRacun Izaberi(FakultetID)

Predavac

1..1

Ime Prezime Telefon Email JMBG AkademskoZvanje IzbornoZvanje

Slika 4.7. Dijagram klasa za sluaj upotrebe Izrada plana polaganja ispita

Poslovi vezani za sluaj upotrebe polaganje ispita

Za sluaj upotrebe polaganja ispita opisuje se sluaj upotrebe i definiu dijagram aktivnosti, dijagram sekvenci, dijagram klasa i dijagrami baze podataka.

Sluaj upotrebe: Polaganje ispita

Kratak opis: Izrada zapisnika o polaganju ispita. Uesnici: Nastavnik, student Uslovi koji moraju biti zadovoljeni pre izvravanja: Prijavljen ispit. Opis: Prvi korak u polaganju ispita je pristupanje ispitu gde nastavnik utvrdjuje spremnost studenta i izvodi kontrola ispravnosti dokumenata. Nastavnik kontrolie spisak prijavljenih studenata, uplatnice, prijavnice za ispit i indeks. Student se neposredno priprema za ispit izborom pitanja za ispit, konsultacijom sa nastavnikom i pripremom pisanog koncepkta za ispit. Nastavnik u sledeem koraku izvodi ispitivanje postavljanjem pitanja, dobijanjem odgovara na pitanja i postavljanjem dopunskih pitanja. Na kraju nastavnik izvodi postupa ocenjivanja kroz vrednovanje pojedinacnog odgovora, zakljuna ocena odgovora i upisivanjem ocena. Izuzeci:Nema Uslovi koji moraju biti zadovoljeni posle izvravanja: Uredna i taan zapisnik o polaganju ispita.

Dijagram aktivnosti: Polaganje ispita

Dijagram aktivnosti Polaganje ispita definisan je plivakim stazama, stanjem i tranzicijom.

alempije@beotel.rs

31

Plivake staze ili procesori su Nastavnik, student. Stanja pripadaju stazama, a tranzicije mogu prelaziti iz jedne staze u drugu. Na sledeoj slici prikazan je dijagram aktivnosti za poslove Polaganje ispita
Nastavnci Student

Utvrdivanje spremnosti studenta [ ne ] Spreman [ da ] Kontrola ispravnosti dokumenta Dokumenta ispravna Postavljanje pitanja [ negativan ] Postavljanje dopunskog pitanja [ negativan ] [ da ]

Izbor pitanja za ispit

Konsultacija sa nastavnikom

[ ne ]

Priprema pisanog koncepta Odgovor na pitanje Vrednovanje odgovora

[ pozitivan ] Vrednovanje pojedinacnih odgovora Zakljucna ocena odgovora Upisivanje ocene [ pozitivan ]

Slika 4.8. Dijagram aktivnosti za sluaj upotrebe Polaganje ispita

Dijagram sekvenci: Polaganje ispita

Prikazae se ta sluaj upotrebe Polaganje ispita treba da radi u realnom vremenu da bi obavio svoju funkciju. Vremenskim redosledom poruka u sekvencijalnom dijagramu opisae logiku odvijanja poslova Polaganje ispita za sluaj upotrebe Izrada plana polaganja ispita. Na sledeoj slici prikazan je dijagram sekvenci za proces Polaganje ispita

32

alempije@beotel.rs

: Nastavnik

: Fakultet

: Smer

: Rok

: Student

: Predmet

: Ispi t

: VremaPolaganja

Izaberi(FakultetID) Izaberi(SmerID) Izaberi(RokID) Izaberi(StudentID)

Izaberi(PredmetID) Unesi(VremePolaganjaID) Unesi(DatumPolaganja, Skol skaGodina)

Unesi(Ocena, OveraSemestraDaNe)

Slika 4.9. Dijagram sekvenci za sluaj upotrebe Polaganje ispita

Dijagram klasa: Polaganje ispita

Dijagram klase Polaganje ispita se sastoji iz klasa i veza izmeu njih. Klasa predstavlja sloeni tip, kolekciju, struturu koja se sastoji od vie atributa (podata lanova) i operacija (metoda, funkcija lanica). Na sledeoj slici prikazan je dijagram klasa za poslove Polaganje ispita.
Smer
(from Logical View)

Student
(from Logical View)

Naziv 1..1 Izaberi(SmerID) 0..* 0..1 0..*

BrojIndeksa Ime Prezime 1..1 JMBG 0..* Ispit

(from Logical View)

Predmet
(from Logical View)

1..1

Naziv BrojCasova Semestar 0..*

0..*

Ocena OveraSemestraDaNe Izaberi(StudentID) Izaberi(PredmetID) Unesi(VremePolaganjaID) Unesi(Ocena, OveraSemestraDaNe) 0..* 0..* 0..1 (from Logical View) Naziv Izaberi(RokID) Rok 0..* 1..1 VremaPolaganja
(from Logical View)

0..1 Predavac
(from Logical View)

1..1 Fakultet
(from Logical View)

Naziv ZiroRacun Izaberi(FakultetID)

DatumPolaganja SkolskaGodina Unesi(DatumPolaganja, SkolskaGodina)

Ime Prezime Telefon Email JMBG AkademskoZvanje IzbornoZvanje

Slika 4.10. Dijagram klasa za sluaj upotrebe Polaganje ispita

alempije@beotel.rs

33

Poslovi vezani za sluaj upotrebe Analiza ispita

Za sluaj upotrebe Analizu ispita opisuje se sluaj upotrebe i definiu dijagram aktivnosti, dijagram sekvenci i dijagram klasa.

Sluaj upotrebe: Analiza ispita

Kratak opis: Analiza ispita ima za osnovu zapisnik o polaganju ispita. Uesnici: Referent Uslovi koji moraju biti zadovoljeni pre izvravanja: Moraju biti azurni sifarnici. Opis: Referent izvodi analizu ispita izradom pregleda struktura ocene studenata koji su prijavili, izasli, polozili ili pali. Izuzeci: (tampa ne tampa fakturu) proveriti da li u tampau ima papira; Uslovi koji moraju biti zadovoljeni posle izvravanja: Poslata informacija studentskoj slubi u obliku spisak prijavljeni studenta po ispitima.

Dijagram aktivnosti: Analiza ispita

Dijagram aktivnosti Analiza ispita definisan je plivakim stazama, stanjem i tranzicijom. Plivaka staza ili procesor je referent. Stanja pripadaju stazama, a tranzicije mogu prelaziti iz jedne staze u drugu. Na sledeoj slici prikazan je dijagram aktivnosti za poslove Analiza ispita.

34

alempije@beotel.rs

Pristup podacima

Izrada pregleda prijavljenih

Izrada pregleda izaslih

Izrada pregleda polozilo

Izrada pregleda palo

Izrada pregleda struktura ocene

Print [ da ]

Stampaj izvestaj

[ ne ]

Kraj [ da ]

Slika 4.11. Dijagram aktivnosti za sluaj upotrebe Analiza ispita

Dijagram klasa: Analiza ispita

Dijagram klase Analiza ispita se sastoji iz klasa i veza izmeu njih. Klasa predstavlja sloeni tip, kolekciju, struturu koja se sastoji od vie atributa (podata lanova) i operacija (metoda, funkcija lanica). Na sledeoj slici prikazan je dijagram klasa za poslove Analiza ispita.

alempije@beotel.rs

35

Smer
(from Logical View)

Rok
(from Logical View)

Naziv Izaberi() 0..* 1..1 0..1 Ispit

(from Logical View)

Naziv 0..* Izaberi() 0..1 0..* 1..1

Ocena OveraSemestraDaNe 0..* Student BrojIndeksa 1..1 Ime Prezime JMBG Izaberi() Izaberi() 0..* Unesi() Unesi() 0..* Unesi() 1..1 Predmet
(from Logical View)

VremaPolaganja0..* 1..1
(from Logical View)

(from Logical View)

DatumPolaganja SkolskaGodina

1..1 Fakultet
(from Logical View)

Naziv BrojCasova Semestar Predavac

(from Logical View)

1..1 0..* 0..* PlanIspita

(from Logical View)

Naziv ZiroRacun Izaberi()

0..*

Ime 0..1 Prezime Telefon Email 1..1 JMBG AkademskoZvanje IzbornoZvanje

DatumPolaganja MestoPolaganja 0..* Otvori() Izaberi() Izaberi() Definisi()

Slika 4.12. Dijagram klasa za sluaj upotrebe Analiza ispita

Izrada dijagrami aktivnosti za poslove praenja ispita

Svaki dijagram aktivnosti, poinje startnom aktivnou koja se predstavlja ispunjenim crnim krugom. Dijagram aktivnosti definisan je plivakim stazama, stanjem i tranzicijom. Plivake staze ili procesori su referent prodaje, referent oznaavanja i analitiar prodaje i one specificiraju odgovornosti za delove celokupne aktivnosti i nemaju neku duboku semantiku. Stanja pripadaju stazama, a tranzicije mogu prelaziti iz jedne staze u drugu. Na sledeoj slici prikazan je dijagram aktivnosti za poslove praenja ispita.

36

alempije@beotel.rs

Referent

Prodekan za nastavu

Studenti

Nastavnici

Izrada plana ispita

Prijem plana ispita Prijem prijava i zapisnika

Prijavljivanje ispita

Overavanje prijava i zapisnika Polaganje ispita

Prijem prijava i zapisnika za ispit

Arhiviranje podataka o Izrada analiza

Azuriranje zapisnika

Slika 4.13. Dijagram aktivnosti za poslove praenja ispita

Izrada dijagrama klasa za poslove praenja ispita

Dijagram klase se sastoji iz klasa i veza izmeu njih. Naziva se jo i dijagram statike strukture. Klasa predstavlja sloeni tip, kolekciju, struturu koja se sastoji od vie atributa (podata lanova) i operacija (metoda, funkcija lanica). Na sledeoj slici prikazan je potpuni dijagram klasa za poslove praenja ispita.

alempije@beotel.rs

37

Smer Naziv Izaberi(SmerID) 0..1 1..1 0..* Valuta NazivValute 1..1 0..* 0..* PrijavaIspita 0..* KojiPutPolaze DatumPrijave Iznos Izaberi(PredmetID) Unesi(StudentID) Izaber(ValutaID) Izaberi(ModelPlacanjaID) Unesi(KojiPutPolaza, DatumPrijave, Iznos) 0..* VremaPolaganja DatumPolaganja SkolskaGodina 1..1 0..* ModelPlacanja BrModela

0..*

Rok Naziv Izaberi(RokID) 1..1 0..1

1..1

0..* Student BrojIndeksa1..1 Ime Prezime JMBG 1..1 1..1 Fakultet Naziv ZiroRacun Izaberi(FakultetID)

0..* PlanIspita DatumPolaganja MestoPolaganja Otvori(RokID, rbr) Izaberi(PredavacID) Izaberi(PredmetID) Definisi(DatumPolaganja, MestoPolaganja) 0..* 0..*

Unesi(DatumPolaganja, SkolskaGodina)

1..1

1..1

0..* Ispit Ocena OveraSemestraDaNe

0..*

1..1

Predmet Naziv BrojCasova Semestar

0..*

1..1 Predavac Ime Prezime Telefon Email JMBG AkademskoZvanje IzbornoZvanje

0..* Izaberi(StudentID) Izaberi(PredmetID) Unesi(VremePolaganjaID) Unesi(Ocena, OveraSemestraDaNe)

0..1

Slika 4.14. Dijagram klasa za poslove praenja ispita

Izrada eme baze podataka za poslove praenja ispita

Kako je definisan model podataka u (2) korienjem CASE alata ERwin postupkom reverznim inenjeringom u RationalRose modeliraemo model podataka u istom.Da biste poeli proces, potrebno je da izaberete Tools > Data Modeler > Reverse Engineer. Na sledeoj slici prikazan je fiziki model podataka definisan u Erwinu i i odgovarajui fiziki model podataka u RationalRous-u dobijen postupkom reverznog inzinjeringa iz skript fajla generisanog u Erwin-u.

38

alempije@beotel.rs

Smer SmerID: char(18) FakultetID: char(18) Naziv: char(18) Student StudentID: char(18) BrojIndeksa: char(18) Ime: char(18) Prezime: char(18) JMBG: char(18) FakultetID: char(18) SmerID: char(18) ModelPlacanja ModelPlacanjaID: char(18) BrModela: char(18) PrijavaIspita PrijavaIspitaID: char(18) ValutaID: char(18) ModelPlacanjaID: char(18) PredmetID: char(18) RokID: char(18) StudentID: char(18) KojiPutPolaze: char(18) DatumPrijave: char(18) Iznos: char(18) Valuta ValutaID: char(18) NazivValute: char(18) Rok RokID: char(18) SmerID: char(18) FakultetID: char(18) Naziv: char(18)

Fizicki model podataka u ERwinu(2)

VremePolaganja Ispit StudentID: char(18) PredmetID: char(18) VremePolaganjaID: char(18) Ocena: char(18) OverenSemestarDaNe: char(18) PredsedniKomisijeID: char(18) VremePolaganjaID: char(18) RokID: char(18) DatumPolaganja: char(18) SkolskaGodina: char(18)

PlanIspita RokID: char(18) RedniBroj: char(18) MestoPolaganja: char(18) DatumPolaganja: char(18) PredavacID: char(18) PredmetID: char(18)

Predmet PredmetID: char(18) PredavacID: char(18) Naziv: char(18) BrojCasova: char(18) Semestar: char(18)

Fakultet FakultetID: char(18) Naziv: char(18) ZiroRacun: char(18)

Predavac PredavacID: char(18) Ime: char(18) Prezime: char(18) Telefon: char(18) Email: char(18) JMBG: char(18) AkademskoZvanje: char(18) IzbornoZvanje: char(18)

<<Non-Identif y ing>> Smer SmerI D : CHAR(18) F akultetID : CHAR(18) Naziv : C HAR(18) 1 Ispit 0..1 <<Non-Identif y ing>> 0. .* 0. .1 Rok RokID : CHAR(18) SmerID : CHAR(18) FakultetID : CHAR(18) Naziv : CHAR(18)

VremePolaganja <<Non-Identif y ing>> 1 0..* VremePolaganjaID : CHAR(18) RokID : CHAR(18) DatumPolaganja : CHAR(18) SkolskaGodina : CHAR(18)

0..1 0..* <<Non-Identif y ing>>

Model podataka u Rational Rous-u

0..*

StudentID : CHAR(18) PredmetID : CHAR(18) VremePolaganjaID : CHAR(18) Ocena : CHAR(18) Ov erenSemestarDaNe : CHAR(18) <<Non-Identif y ing>> PredsedniKomisijeID : CHAR(18) 0..* 0..* 0..*

0..* Prijav aIspita Prijav aIspitaID : CHAR(18) ValutaID : CHAR(18) ModelPlacanjaID : CHAR(18) PredmetID : CHAR(18) RokID : CHAR(18) StudentID : CHAR(18) KojiPutPolaze : CHAR(18) DatumPrijav e : CHAR(18) Iznos : CHAR(18) 0..* <<Non-Identif y ing>> ModelPlacanja 0..* 1 ModelPlacanjaID : CHAR(18) BrModela : CHAR(18)

<<Identif y ing>>

<<Identif y ing>>

0..* <<Non-Identif y ing>> <<Identif y ing>> 0..* 1

0..* <<Non-Identif y ing>>

<<Identif y ing>>

<<Non-Identif y ing>> <<Non-Identif y ing>>

Student StudentID : CHAR(18) BrojIndeksa : CHAR(18) Ime : CHAR(18) Prezime : CHAR(18) JMBG : CHAR(18) FakultetID : CHAR(18) SmerID : CHAR(18)

1 1

Valuta ValutaID : CHAR(18) Naziv Valute : CHAR(18)

Predmet 1 PredmetID : CHAR(18) Predav acID : CHAR(18) Naziv : CHAR(18) BrojCasov a : CHAR(18) 0..* Semestar : CHAR(18) <<Non-Identif y ing>> 0..* 1 0..* PlanIspita RokID : CHAR(18) RedniBroj : CHAR(18) MestoPolaganja : CHAR(18) DatumPolaganja : CHAR(18) Predav acID : CHAR(18) PredmetID : CHAR(18)

<<Non-Ident if y ing>> Predav ac Predav acID : CHAR(18) Ime : CHAR(18) Prezime : CHAR(18) Telef on : CHAR(18) Email : CHAR(18) JMBG : CHAR(18) AkademskoZ v anje : CHAR(18) IzbornoZv anje : CHAR(18)

<<Non-Identif y ing>> 1

0..*

0..1

F akultet FakultetID : CHAR(18) Naziv : CHAR(18) ZiroRacun : CHAR(18)

Slika 4.15. Model podataka

alempije@beotel.rs

39

Zakljuak
Na osnovu definisanih dijagrama pristupa se izradi dva sledea koraka. U prvom koraku prelazi se na definisanje server strane generisanjem baze podataka kao to je pokazano za ovaj primer u (2) i (3). Drugi korak podrazumeva izradu klijent strane korienjem Web programiranjem.

Literatura
1 Veljovi A. Objektno modeliranje informacionih sistema, Fakultet za poslovne studije, MEGATREND Univerzitet, 2003. godina 2. Veljovi A. Praktikum iz analize informacionih sistema, Fakultet za poslovne studije, MEGATREND Univerzitet, 2005. godina. 3.Veljovi A., Put ka integranolm inforacionom sistemu na primeru Megatrend univerziteta, Megatrend revija, 2005. godina.

40

alempije@beotel.rs

5.Poslovi izrade tehnolokog postupka

Uvod
Na primeru poslova izrade tehnolokog postupka, prikazae se faze objektnog modeliranja informacionog sistema definisanog u (1). Ovaj primer predstavlja svojevrsan vodi kroz definisanje osnovnih elemenata projekta razvoja informacionog sistema korienjem objektno orijentisanih CASE alata (Rational Rous). Osnove vezane za poslove izrade tehnolokog postupka date su u (2). Ovo je primer sa minimalnim zahtevima za izradu seminarskog rada za predmet Projektovanje informacionih sistema Potrebno je izvesti sledee aktivnost i to: Dijagram sluajeva upotrebe Dijagram koncepta Dijagram sekvenci Dijagram kolaboracije Dijagram klasa

Izrada dijagrama sluajeva upotrebe TehnIS

Korienjem IDEF0 metodologije(2) opisuje se funkcionalnost sistema, tj. definie se ta sistem rad. Izradom dijagrama sluajeva upotrebe treba da se da odgovore i na pitanje kako sistem funkcionie unutra. Drugim reima, moe se rei da je dijagrami sluajeva upotrebe korisniki pogled funkcionisanja sistema. Na narednoj slici prikazan je dijagram sluajeva upotrebe TehnIS.

alempije@beotel.rs

41

Logon

<<include>> Izbor proizvoda

Opis operacije

<<include>>

<<include>> Definisanje operacija <<include>> <<extend>>

Definisanje varijante tehnoloskog postupka Tehnolog

Definisanje parametara <<include>> <<include>>

Odrzavanje tehnoloskih lokacija

Definisanje parametara uredjaja

Definisanja parametara uzorka

Slika 5.1. Dijagram sluajeva upotrebe TehnIS Uesnici (Actor) je tehnolog, koji komunicira sa sistemom TehnIS. Uesnik prima i odailje poruke koje nisu formalno prikazane.. Sluaj upotrebe predstavlja: "atomsku transakciju" jer po njegovom zavretku IS sistem ostaje u konzistentnom stacionarnom stanju, dok na njega ne ponu da deluju drugi sluaj upotrebe. "logiku jedinicu posla" u realnom vremenu, neto to ima znaenje za korisnika, bez obzira na njegovu sloenost.

42

alempije@beotel.rs

Sluaji upotrebe: Izbor proizvoda, Definisanje Varijante tehnolokog postupka, Odravanje tehnoloke lokacije i Opis operacije
Kratak opis: Izbor proizvoda i Definisanje Varijante tehnolokog postupka treba da omogui nalaenje proizvoda za koji je potrebno izbrati ili projektovati varijantu tehnolokog postupka. Odravanje tehnoloke lokacije je zajedniki ifranik i definie ga po potrebi onaj kome to treba a svi ga koriste. Opis operacije je tekstualno opisuje operacije. Uesnici: Tehnolog Uslovi koji moraju biti zadovoljeni pre izvravanja: Moraju biti azurni sifarnici. Opis:. Pretpostavka za izvodjenje ovog sluaja upotrebe je da je izvrena identifikacija i standardizacija naziva proizvoda.Izbor proizvoda je asocijativnom vezom povesan preko stereotipa <<include>> sa sluajem upotrebe Definisanje Varijante tehnolokog postupka . Ovo znai da sluaj upotrebe Izbor proizvoda ukljuuje sluaj upotrebe Definisanje varianate tehnolokog postupka. Odravanje tehnoloke lokacije je sluaj upotrebe koji je izvan TehnIS-a i on se ovde samo koristi. Nastao je u internoj standardizaciji. Opis operacije je sluaj upotrebe gde se za dogovarajuu operaciju tekstualno opisuje operacije. Izuzeci: Nema Uslovi koji moraju biti zadovoljeni posle izvravanja: Nema.

Sluaj upotrebe: Definisanje operacije

Kratak opis: Definisanje operacije generie se tehnoloki postupak (spisak operacija koji je definisan rednim brojem, nazivom (nazivi su takodje standardizovani), vremenom pripreme i trajanjem). Uesnici: Tehnolog Uslovi koji moraju biti zadovoljeni pre izvravanja: Moraju biti azurni sifarnici. Opis:. Stereotipom <<include>> ovaj sluaj upotrebe koristi sluajeve upotrebe Opis operacije i Definisanje parametara. Steretipom <<extend>> ovaj sluaj upotrebe proiruje se sluajem upotrebe Odravanje tehnoloke lokacije. Izuzeci: Nema Uslovi koji moraju biti zadovoljeni posle izvravanja: Nema

Sluaj upotrebe: Definisanje parametara

Kratak opis: Definisanje parametara je sluaj upotrebe gde se za dogovarajuu operaciju bira izbor definisanja parametara uredjaja i parametara uzorka. Uesnici: Tehnolog Uslovi koji moraju biti zadovoljeni pre izvravanja: Moraju biti azurni sifarnici.

alempije@beotel.rs

43

Opis: Stereotipom <<include>> ovaj sluaj parametara uredjaja i Definisanje parametara upotrebe gde se definiu parametri maine parametara uzorka je sluaj upotrebe gde labaratorije ispituju. Izuzeci: Nema

upotrebe koristi sluajeve upotrebe Definisanje uzorka. Definisanje parametara uredjaja je sluaj za izvodenje tehnolokog procesa. Definisanje se definiu parametri uzorka koji se u okviru

Uslovi koji moraju biti zadovoljeni posle izvravanja: Nema

Izrada konceptualnog modela TehnIS

Sutina konceptualnog modela je u pronalaenju klasa u domenu izrade tehnolokih procesa. To je svojevrsno razmatranje realnog sistema koji stoji pred nama. Klase u konceptualnom modelu su samo rezultat pokuaja da se sagledavanjem realnog sistema prepoznaju neki entiteti koji bi mogli da konkuriu za softverske klasu, te da se prepoznaju neke veze i njihova kardinalnost. U okviru izrade konceptualnog modela definiu se sledee aktivnosti: Definisanje koncepta Definisanje asocijacija izmedju koncepata Konceptom se opisuju stvari u realnom sistemu i na osnovu njih se kasnije, u "Izradi dijagrama klasa", definiu odgovarajue klase i objekti koji definiu odgovarajua softverska reenja. Definisanjem veza izmedju koncepata uspostavljaju se asocijacije izmedju predhodno definisanih koncepata. U okviru UML asocijacija se opisuje kao "strukturne relacije" izmedju objekata za razliite tipove. Apstrakcijama, e se otkriti da veoma mali broj koncepata stoje same.Veina njih sarauje sa drugima na vie naina. Stoga, kada se pravi konceptualni model, ne samo da se moraju identifikovati stvari koje formiraju renik modela, ve, takoe, moraju se definisati i kako te stvari stoje jedna u odnosu na drugu. Na narednoj slici prikazan je koncept TehnIS gde se mogu uoiti neke od gore opisanih osobina.

44

alempije@beotel.rs

Proizvod barKod

1..1

TehnoloskaLokacija tehnoloskaSifra nazivTehnoloskeLokacije slika 0..1 1..* TehnoloskiPostupakStavka brojOperacije naziOperacije vremePripreme vremeTrajanja opisOperacije 1..1

0..* TehnoloskiPostupak brojTehnoloskogPostupka datum ukupnoVreme

1..*

PredmetPoslovanja nazivPredmetaPoslovanja staraSifra stariNaziv engleskiNaziv dokument brojCrtezaStandard prosecnaCena datumOtvorio datumIzmene napomena

0..* Parametar zahtevanaVrednost zahtevanaVrednostMin zahtevanaVrednostMax

ParametriUredjaja

ParametriUzorka

Slika 5.2. Konceptualni model TehnIS Dakle, identifikovani su sledei koncepti u konkretnom problemu realnog sistema: Predmet poslovanja, Proizvod, tehnoloki postupak, Tehnoloki postupak stavka, Tehnoloka lokacija, Parametri, parametri uredjaja i parametri Uzorka. U daljem tekstu detaljno e se specificirati svaki pojedinani koncept. Predmet poslovanja je generalizovani koncept nastao na viem nivou u okviru renika podataka ProteIS i ovde se prikazuje da bi se pokazala veza sa njegovom specijalizaciojom Proizvod. Predmet poslovanja je vezni koncept prema ostalim podsistemima u Sojaproteinu u okviru projekta ProteIS. Ovde je definisan u okviru koncepta jer treba da zadovolji zahteve koji su postavljeni od strane odravanja. Proizvod je specijalizacija od predmeta poslovanja i mogue ga je samo koristiti a njegov nastanak je vezan za posistem interna standardizacija. Nasledjuje atribute iz klase PredmetaPoslovanja a njegov specifini atribut kojim se opsuje je BarKod. Tehnoloki postupak je koncept koji se ovde stvara i koji za jedan proizvod moe da ima vie varijanti. Za tehnoloki postupak potrebno je definisati varijantu, datum nastanka i kao povratna informacija (izveden podatak) ukupno vreme. Tehnoloki postupak stavka su operacije koje se definiu za konkretan proizvod i odgovarajuu varijantu tehnoloskog postupka. Potrebno je definisati redni broj operacije, standradizovani naziv operacije, vreme pripreme i vreme trajanja.Posebno je mogue za svaku operaciju opisati operaciju kao i definisati parametre. Parametri su generalizovani koncept i definie za odgovarajuu operaciju ije su specijalizacije parametri uredjaja i parametri uzorka. Parametri su opisani zahtevanom vrednou, zahtevana vrednost minimum i zahtevana vrednost maksimum. Tehnoloka lokacija je koncept kojim se definie lokacija gde se operacija izvodi.

alempije@beotel.rs

45

Na osnovu ovako definisanog koncepta u sledeem poglavlju definisae se dijagrami interakcije kojima se definie dinamika sistema tj. opisuje se klijent strana budue aplikacije.

Dijagram sekvenci TehnIS

Dijagram sekvenci (Sequence Diagram) opisuje vreme trajanja poruke i nain su na koji objekti u sistemu medjusobno komuniciraju, ostvarujui oekivano ponaanje. Dijagram sekvenci poseduju dve dimenzije: vreme i kolekciju objekata (objekat je instanca klase). Uobiajeno je da se vreme prikazuje po vertikalnoj, a kolekcija objekata po horizontalnoj dinmenziji. Na vertikalnoj liniji se moe, na pogodan nain predstaviti i vremensaka skala. Objekti na dijagramu sevenci su predstavljeni vertikalnim linijama. Na vrhu linije se navodi naziv objekt i/ili simbol objekta. Aktiviranje objekta se predstavlja uskim pravougaonikom na liniji objekta i predstavlja operaciju (akciju) koju objekat, u periodu predstavljenom duinom aktivacije, obavlja. Na vrhu aktivacionog objekta se prikazuje dogaaj (poruka) koja je aktivirala objekat, a na dnu povratna poruka objektu koji je aktivirao posmatrani objekat. Povratna poruka se esto ne prikazuje, pogotovo kada daje oigledna i daje samo status okinute operacije. Iz svakog objekta polazi na dole isprekidna linija koja predstavlja njegov ivotni vek (lifeline). ivotni vek predstavlja postojanje nekog objekta u periodu vremena. Veina objekata koji se pojavljuju u sekvencijalnom dijagramu postojae i dok traje interakcija, pa su svi ti objekti poreani na vrhu dijagrama, sa svoji ivotnim vekom povuenim od vrha ka dnu dijagrama. Na narednoj slici prikazan je dijagram sekvenci TehnIS. Tehnolog u prvom koraku porukom NadjiID() pristupa objektu :Proizvod i bira odgovarajui ident broj proizvoda (ProizvodID) za koji e se praviti tehnoloki postupak. Takoe je mogue porukom prikazi (proizvodID) daje prikaz svih proizvoda. U sledeem koraku se porukom pronadjiTP (proizvodID) pristupti objektu :TehnoloskiPostupak i dobiti spisak projketovanih tehnolokih postupaka za taj ident broj proizvoda Ako se definie novi tehnoloi postupak porukom unesiVarijantu(proizvodID) pristupa se objektu :TehnoloskiPostupak poinje se sa projektovanjem. Na osnovu predhodno definisan proizvod i za definisanu varijantu tehnoloskog postupka definie se redni broj operacija i sve to prosledi porukom prikaziOperaciju (proizvodID, varTP, rbrOP) koja se kao operacija izvodi u objektu :TehnoloskiPostupakStavka. U okviru istog objekta se izvode operacije unesiOpis (proizvodID, varTP, rbrOP), unesiVremePripreme (proizvodID, varTP, rbrOP) i unesiVremeTrajanja (proizvodID, varTP, rbrOP).

46

alempije@beotel.rs

: Tehnolog

: Proizvod

: TehnoloskiPostupak

: TehnoloskiPostupakStavka

: TehnoloskaLokacija

: Parametar

nadjiIDbroj( )

unesiVarijantuTP(proizvodID) prikaziOperaciju(proizvodID, varTP, rbrOP) unesiOpis(proizvodID, varTP, rbrOP)

prikazi(proizvodID) pronadjiTP (proizvodID) izaberiLokaciju(lokacijaID) azurirajLokaciju(lokacijaID)

unesiParametarUredjaja(proizvodID, varTP, rbrOP) unesiParametarUzorka(proizvodID, varTP, rbrOP)

korekcijaParametara(proizvodID, varTP, rbrOP)

unesiVremePripreme(proizvodID, varTP, rbrOP) unesiVremeTrajanja(proizvodID, varTP, rbrOP) ukupnoVreme(proizvodID, varTP)

Slika 5.3. Sekvencijalni dijagram TehnIS Ovaj objekat prosledjuje poruku izaberiLokaciju(lokacijaID) objektu :TehnoloskaLokacija na osnovu koje biramo tehhnoloku lokaciju na kojoj se izvodi operacija. Objekat :TehnoloskiPostupakStavka prosledjuje poruke unesiParametarUredjaja (proizvodID, varTP, rbrOP) i unesiParametarUzorka(proizvodID, varTP, rbrOP) objektu :Parametri gde se izvod istomene operacije i izvri unos odgovarajuih podataka u atribute objekta : Parametri. Kada se definiu za sve operacije vremena prpreme i trajanja porukom ukupnoVreme (proizvodID, varTP) aktivira se istoimena operacija u objektu :TehnoloskiPostupak koja izvri unos podatka u atribut ukupnoVreme.

Dijagram kolaboracije TehnIS

Dijagram saradnje (Collaboration Diagram) definie komunikaciju, pa i veze izmedju objekata neophodne za ostvarivanje posmatrane komunikacije. Dijagram saradnje pored objekata i veza prikazuje i poruke koje objekti medjusobno prosledjuju, ostvarujui na taj nain oekivano ponaanje. Dijagram saradnje opisuje strukturnu organizaciju objekata koji alju i prikazuju poruke.Dijagram saradnje prikazuje interakciju izmedju skupa objekata koji se predstavljaju kao vorovi nekog grafa. Kako razvoj sistema napreduje i kako struktura koncepta prelazi u strukturu klasa, tako i znaaj dijagrama saradnje raste, a dijagrama sekvenci opada, jer je semantika dijagrama saradnje bogatija.

alempije@beotel.rs

47

Drugim reima, poto su izvedeni iz istih informacija u UML-ovom metamodelu, sekvencijalni i dijagram saradnje su meusobno ekvivalentni. Kao posledica toga jedan se moe prevesti u drugi bez bilo kakvog gubitka informacija kao to je pokazano na narednoj slici.
1: nadjiIDbroj( ) 5: prikazi(proizvodID) 2: unesiVarijantuTP(proizvodID) 6: pronadjiTP (proizvodID) : TehnoloskiPostupak 3: prikaziOperaciju(proizvodID, varTP, rbrOP) 4: unesiOpis(proizvodID, varTP, rbrOP) 12: unesiVremePripreme(proizvodID, varTP, rbrOP) 13: unesiVremeTrajanja(proizvodID, varTP, rbrOP) : Tehnolog 8: azurirajLokaciju(lokacijaID) 14: ukupnoVreme(proizvodID, varTP)

: Proizvod

: TehnoloskaLokacija

7: izaberiLokaciju(lokacijaID)

: TehnoloskiPostupakStavka

9: unesiParametarUredjaja(proizvodID, varTP, rbrOP) 10: unesiParametarUzorka(proizvodID, varTP, rbrOP) : Parametar

11: korekcijaParametara(proizvodID, varTP, rbrOP)

Slika 5.4. Dijagram kolaboracije TehnIS Saradnja (kolaboracija) izmedju objekata prikazuje se objektima i njihovim medjusobnim vezama. Komunikacija izmedju objekata opisuje se porukama koje objekti medjusobno razmenjuju, ostvarujui na taj nain oekivano ponaanje i odredjenu funkcionalnost sistema.

Definisanje dijagrama klasa

Dijagram klasa (Class Diagram) prikazuje skup klasa, interfejsa i saradnja i njihovih relacija. Dijagram klasa je statiki struktura klasa u sistemu koje izmedju sebe uspostavljaju relacija tipa asocijacija (veza sa svakom drugom), zavisnosti (jedna klasa zavisi/koristi se od druge klase), specijalizacije (jedna klasa je specijalizacija druge klase, i paketa (grupisanje u jednu jedinicu tj. paketi); Potpuni dijagram klasa ili kako se krae kae dijagram klasa se tako zove da bi se odvojio od konceptualnog modela (koji se prikazuje kao dijagram klasa bez operacija). Klasa predstavlja sloeni tip, kolekciju, strukturu koja se sastoji od vie atributa (podata lanova) i operacija (metoda, funkcija lanica). Na narednoj slici prikazan je dijagram klasa za TehnIS.

48

alempije@beotel.rs

TehnoloskaLokacija tehnoloskaSifra nazivTehnoloskeLokacije slika azurirajLokaciju(lokacijaID) izaberiLokaciju(lokacijaID) 0..1 TehnoloskiPostupakStavka 1..* TehnoloskiPostupak brojTehnoloskogPostupka datum ukupnoVreme unesiVarijantuTP(proizvodID) pronadjiTP(proizvodID) unesi Datum(Date) ukupnoVreme(proizvodID, varTP) 0..* 1..1 Proizvod barKod nadjiIDbroj() prikazi(proizvodID) 0..* Parametar zahtevanaVrednost zahtevanaVrednostMin zahtevanaVrednostMax unesiParametarUredjaja(proizvodID, varTP, rbrOP) unesiParametarUzorka(proizvodID, varTP, rbrOP) korekcijaParametara(proizvodID, varTP, rbrOP) brojOperacije naziOperacije vremePripreme vremeTrajanja opisOperacije 1..* unesiVremePripreme(proizvodID, varTP, rbrOP) unesiVremeTrajanja(proizvodID, varTP, rbrOP) unesiOpis(proizvodID, varTP, rbrOP) prikaziOperaciju(proizvodID, varTP, rbrOP) 1..1

Slika 5.5. Dijagram klasa TehnIS Dijagram klasa koji je dat na slici. opisuje logiku aplikacije TehnIS i definisan je sa tri kljune klase:TehnoloskiPostupak, TehnoloskiPostupakStavka i Parametri. Klase Proizvod i TehnoloskaLokacija ne nastaju u okviruTehnIS-a ve slue za izbor i proirivanje TehnIS-a. Za jedan tehnoloski postupak definie se jedna ili vise stavki i ova veza je agregacija tj. kompozicija (Composition). Kod kompozicije, objekti-delovi su u ekskluzivnom vlasnitvu samo jednog objekta-celine koji je odgovoran za njihovo kreiranje i unitavanje. U okviru klase TehnoloskiPostupakStavka definie se operacijai vezuje agregacijom tj. referenca. Ovaj tip agregacije je samo specijalna vrsta asocijacije i definisana je romboidom i predstavlja strukturalni odnos, to znai da su oba klase na istom nivou. Agregacija definie odnos: celina/deo tj. odnos :ima (has-a), to znai da objekat celine ima objekte delova. Klasa parametri objedinjuje u konceptu definisane klase ParametaraUredjaja i ParamataraUzorka. Neki atributi koji e se kasnije pojaviti u modelu podataka nedostaju a to je stoga to se ovde ne radi o tabelama i prenoenju stranih kljueva, ve o softverskim klasama kod kojih se to reava mogunou referenciranja.

Fiziki model podataka TehnIS

Definisanje fizikom modela podataka tj. implementacija klasa i njihovih atributa u tabele i kolone nekog SUBP, korienjem RationalRous-a, definisali smo na osnovu ERwin fizikog modela

alempije@beotel.rs

49

podataka(2) postupkom reverse enginering. Prvo smo u ERwinu napravili skript fajl a potomo pozvali u RationalRous-u Tools-Data Modeler-Reverse Engeenering. eme logike baze podataka obuhvata poseban skup podataka (odgovarajui renik podataka) sa odgovarajuom semantikom i vezama meu elementima baze podataka. Fiziki, ove veze su smetene u bazi podataka, za kasniju upotrebu. Na sledeoj slici prikazana je ema baze podataka dobijena ovim postupkom.
TehnoloskiPostupak ProizvodID: int TehnoloskiPostupakID: int BrojTehnoloskogPostupka: varchar(25) Datum: smalldatetime Izradio: int Odobrio: int TehnoloskaLokacija TehnoloskaLokacijaID: int TehnoloskaSifra: nvarchar(15) NazivTehnoloskeLokacije: nvarchar(80) Slika: image NadredjenaTL: int

Fizicki model podataka u ERwinu(2)

Proizvod ProizvodID: int PakovanjeID: int BarKod: nvarchar(50)

Te hnoloskiPostupakStavka ProizvodID: int TehnoloskiPostupakID: int OperacijaID: int BrojOperacije: int NazivOperacije: nvarchar(80) OpisOperacije: ntext KodUredjajUzorak: tinyint TehnoloskaLokacijaID: int PredmetPoslovanjaID: int VremePripreme: numeric(13,2) VremeTrajanja: numeric(13,2)

Parametar ProizvodID: int TehnoloskiPostupakID: int OperacijaID: int RedniBrojParametra: int NazivParametra: nvarchar(80) ZahtevanaVrednost: numeric(13,2) ZahtevanaVrednostMin: numeric(13,2) ZahtevanaVrednostMax: numeric(13,2) JedinicaMereID: int

Proizvod ProizvodID : INT PakovanjeID : INT BarKod : NVARCHAR(50) <<PK>> PK_Proizvod1() 1

Parametar ProizvodID : INT TehnoloskiPostupakID : INT OperacijaID : RedniBroj RedniBrojParametra : RedniBroj ZahtevanaVrednost : KolicinaDecimal NazivParametra : NazivIdenta ZahtevanaVrednostMin : KolicinaDecimal ZahtevanaVrednostMax : KolicinaDecimal JedinicaMereID : INT <<PK>> PK_Parametar0() <<FK>> FK_Parametar0() 0..* <<Identifying>>

TehnoloskaLokacija TehnoloskaLokacijaID : INT TehnoloskaSifra : Oznaka NazivTehnoloskeLokacije : NazivIdenta Slika : IMAGE NadredjenaTL : INT <<PK>> PK_TehnoloskaLokacija2() <<FK>> FK_TehnoloskaLokacija1() 0..1 0..1 <<Non-Identifying>>

0..*

Model podataka u Rational Rous-u

<<Identifying>>

<<Non-Identifying>>

0..*

0..*

TehnoloskiPostupak ProizvodID : INT Odobrio : INT Izradio : INT TehnoloskiPostupakID : INT BrojTehnoloskogPostupka : Delovodnik Datum : KratkiDatum <<PK>> PK_TehnoloskiPostupak3() <<FK>> FK_TehnoloskiPostupak2()

TehnoloskiPostupakStavka ProizvodID : INT NazivOperacije : NazivIdenta TehnoloskiPostupakID : INT KodUredjajUzorak : TINYINT <<Identifying>> OperacijaID : RedniBroj OpisOperacije : Napomena BrojOperacije : RedniBroj 0..* TehnoloskaLokacijaID : INT 1 VremePripreme : KolicinaDecimal PredmetPoslovanjaID : INT VremeTrajanja : KolicinaDecimal <<PK>> PK_TehnoloskiPostupakStavka4() <<FK>> FK_TehnoloskiPostupakStavka4() <<FK>> FK_TehnoloskiPostupakStavka3()

Slika 5.6. Fiziki model podataka TehnIS

50

alempije@beotel.rs

Zakljuak
Na osnovu definisanih dijagrama pristupa se izradi dva sledea koraka. U prvom koraku prelazi se na definisanje server strane generisanjem baze podataka kao to je pokazano za ovaj primer u(2). Drugi korak podrazumeva izradu klijent strane korienjem MS Access-om kao to je pokazano u (2) i (3).

Literatura
1 Veljovi A. Objektno modeliranje informacionih sistema, Fakultet za poslovne studije, MEGATREND Univerzitet, 2003. godina 2. Veljovi A. Praktikum iz analize informacionih sistema, Fakultet za poslovne studije, MEGATREND Univerzitet, 2005. godina 3. Veljovi A. i drugi, Projekat TehnIS, Sojaprotein Beej, 2001. godina.

alempije@beotel.rs

51

6. Poslovi cirkulacije u biblioteci

Uvod
Na primeru cirkulacije u biblioteci, detaljno e se prikazati sve faze objektnog modelranja informacionog sistema definisanog u (1). Ovaj primer predstavlja svojevrsan vodi kroz definisanje svih elemenata projekta razvoja informacionog sistema korienjem objektno orijentisanih CASE alata (Rational Rous). Osnove vezane za poslove cirkulacije u biblioteci date su u (2). Osnova za praenje faza OO projektovanja IS ine sledee faze: Definisanje zahteva o Izrada dijagrama sluajeva upotrebe o Izrada dijagrama aktivnosti Objektno orijentisana analiza o Izrada konceptualnog modela o Izrada dijagrama sekvenci o Definisanje ugovora o izvrsenju operacija Objektno orijentisan dizajn o Izrada dijagrama saradnje o Izrada potpunih dijagrama klasa o Izrada dijagrama stanja o Definisanje paketa Implementacija o Izrada aplikacije o Definisanje tehnologije aplikativne i mrezne arhitekture Predmet razmatranja ovog primera nije testiranje, uvodjenje i odrzavanje.

52

alempije@beotel.rs

Definisanje zahteva za poslove cirkulacije u biblioteci

Osnovne pretpostavke vezane za definisanje zahteva poslova cirkulacije u biblioteci dati su u (2) i treba da bude veza sa elementima UML definisanim preko dijagrama aktivnosti i dijagrama sluajeva upotrebe. Model poslovnih procesa (ili fiziki model) je vezan za odgovarajue organizaciono tehnoloko okruenje i podrazumeva detaljan opis poslovnih procesa kao sekvence aktivnosti. Imajui ovo u vidu model poslovnih procesa podloan je eim izmenama zbog promene organizacije i tehnologije obavljanja posla. Ovde se pod poslovnim procesom definie sekvenca (nit) aktivnosti kojima se ostvaruje neki cilj sistema ili zadovoljava zahtev korisnika. Pod modeliranjem poslovnih procesa podrazumevaju se metode i alati koji se koriste za opis poslovnih procesa tj. definiu se: aktivnosti u svakom poslu kao i njegov redosled i uslovi pod kojima se odvija radna mesta (procesori) na kojima se aktivnosti odvijaju kao i dokumenta koji su ulaz, odnosno izlaz iz svake aktivnosti. Izrada modela poslovnih procesa cirkulacije u biblioteci definisane su sledeim aktivnostima: Razvoj dijagrama sluajeva upotrebe za poslove cirkulacije u biblioteci Razvoj dijagrama aktivnosti za poslove cirkulacije u biblioteci U daljem tekstu detaljno e se obrazloiti gore definisane aktivnosti.

Izrada dijagrama sluajeva upotrebe za poslove cirkulacije u biblioteci

U daljem radu koristiemo CASE alata RationalRose koji u potpunosti podrava UML notaciju za modelovanje dijagrama sluaja korienja. Model se ne sastoji samo od dijagrama ve i od detaljnog opisa sluaja upotrebe. Za opisivanje sluajeva upotrebe moraju se ispotovati odgovorajui sadraji koji sadre kratak opis, uesnike, uslove koji se moraju zadovoljiti pre izvrenja, opis, izuzeci, i uslovi koji moraju biti zadovoljeni posle izvravanja. Slede dijagrami sluajeva upotrebe i tekstualni opis sluajeva upotrebe clirkulacije u biblioteci.

alempije@beotel.rs

53

Opominjanje

<<extend>> Zaduzivanje

Bibliotekar <<communicate>>

Evidencija <<extend>>

Razduzivanje

<<extend>>

Clan Rezervisanje

Slika 6.1. Dijagram sluaja upotrebe Cirkulacija

Sluaj upotrebe: Evidencija

Kratak opis: Voenje podataka o lanovima cirkulacije u biblioteci Uesnici: Bibliotekar Uslovi koji moraju biti zadovoljeni pre izvravanja: Uredan spisak lanova za upis sa tanim linim podacima. Opis: Svaka biblioteka mora imati aurnu evidenciju o svojim lanovima. Tu se vode lini podaci kao to je jedinstveni identifikator lana (ovde usvojeno JMBG), ime, prezime, telefon, radno mesto itd. Unos veine podataka sem pojedinih (kao broj telefona) je obavezan. Jedan lan moe samo jednom biti zaveden u evidenciju cirkulacije u biblioteci, i naravno iz cirkulacije u biblioteci se moe ispisati samo lan koji je ve ulanjen. Izuzeci: Za lana koji se upisuje postoji proverava se da li je tano unesen JMBG. Ako lan koji se ispisuje ne postoji proverava se tanost unesenih podataka. Uslovi koji moraju biti zadovoljeni posle izvravanja: Uredna i tana evidencija zapisa lanova cirkulacije u biblioteci .

54

alempije@beotel.rs

Sluaj upotrebe: Zaduivanje

Kratak opis: lanovi cirkulacije u biblioteci izuzimaju naslove iz bibliotekog fonda. Uesnici: Bibliotekar Uslovi koji moraju biti zadovoljeni pre izvravanja: lan i naslov postoje; zaduenje je evidentirano. Opis: lan trai naslov i ako nije na zaduenju zaduuje ga na period od 30 dana. Izuzeci: Za naslov koji je na pozajmici moe se samo izvriti rezervisati. Za naslov koji ne postoji proverava se da li je tano unesen kriterijum pretrage. Ako takvo zaduenje ne postoji proverava se da li je knjiga rashodovana. Uslovi koji moraju biti zadovoljeni posle izvravanja: Tana evidencija svih zaduenja koja su tekua i jo nisu namirena.

Sluaj upotrebe: Razduivanje

Kratak opis: lanovi cirkulacije u biblioteci vraaju naslove iz bibliotekog fonda. Uesnici: Bibliotekar Uslovi koji moraju biti zadovoljeni pre izvravanja: lan i naslov postoje; zaduenje je evidentirano. Opis: Pri razduivanju identifikuje se zaduenje lana i brie se zapis o njemu.

Sluaj upotrebe: Opominjanje

Kratak opis: lanovima koji su zadrali naslov due od 30 dana alje se opomena. Uesnici: Bibliotekar Uslovi koji moraju biti zadovoljeni pre izvravanja: Taan sistemski datum i tani podaci o datumu zaduenja Opis: Svakodnevno pri startovanju aplikacije prolaze se svi zapisi o zaduenjima i na osnovu datuma zaduenja i sistemskog datuma utvruju se prekoraenja za koja podsistem nudi mogunost slanja opomene. Opomena se ne mora poslati kao to i sam bibliotekar moe pokrenuti filtriranje zaduenja u potrazi za vremenskim prekoraenjima. Opomena se tampa i alje lanu. Izuzeci: (tampa ne tampa opomenu) proveriti da li u tampau ima papira; (Podaci na opomeni nisu kompletni) proveriti da li se za datog lana i naslov vode svi relevantni podaci. Uslovi koji moraju biti zadovoljeni posle izvravanja: Svi zapisi iz tabele zaduenja koji su prekoraili vremenski rok vraanja naslova, smeteni su u tabelu opomena.

Sluaj upotrebe: Rezervisanje

Kratak opis: Javljanje lana na listu ekanja za naslov koji je ve zaduen.

alempije@beotel.rs

55

Uesnici: Bibliotekar, lan Uslovi koji moraju biti zadovoljeni pre izvravanja: Naslov koji se zaduuje postoji u vidu zapisa. Opis: lan pretrauje naslove i kada nae odgovarajui a on je ve na zaduenju kod drugog lana javlja se na listu ekanja za taj naslov. Sada nakon vraanja naslova u biblioteku on nemoe biti zaduen niti od jednog lana osim od onog koji ga je rezervisao i to po FIFO(First In Firs Out) algoritmu ekanja. Do sada se ta funkcija vrila kroz komunikaciju lana sa bibliotekarom, dok bi uvoenjem novog tehnolokog okruenja tu funkciji mogli da vre i lanovi samostalno. Izuzeci: (naslov ne postoji) pogledati da li su dobro uneti podaci za pretragu Uslovi koji moraju biti zadovoljeni posle izvravanja: Tano formiran redosled lanova po datumu rezervacije.

Izrada dijagrami aktivnosti za poslove cirkulacije u biblioteci

Zbog boljeg razumevanja korisnikih zahteva, dijagramima aktivnosti e se opisati mehanizam izvravanja sluaja upotrebe koji su prethodno opisani. Dijagram aktivnosti definisan je: plivakim stazama stanjem i tranzicijom Plivake staze ili procesori su logike celine nastali na osnovu definisane organizacije biblioteke. U plivake staze se navode uesnici, aktivnosti koje dati procesor obavlja i dodeljuju odgovornosti za izvrenje akcija u pojedinim logikim celinama. Dakle plivake staze (swimlanes) specificiraju odgovornosti za delove celokupne aktivnosti i nemaju neku duboku semantiku. Staza obino reprezentuje neki entitet realnog sveta. Stanja pripadaju stazama, a tranzicije mogu prelaziti iz jedne staze u drugu. vorovi grafa predstavljaju aktivna stanja posla (aktivnosti), a neimenovane linije su tranzicije. Stanje akcija i aktivnosti tako se rasporedjuju da se vidi odgovornost objekata ili uesnika u sistemu za njegovo izvrenje. Slede dijagrami aktivnosti za pojedine sluajeve upotrebe.

56

alempije@beotel.rs

Dijagram aktivnosti za voenje evidencije lanova

Svaki dijagram aktivnosti, poinje startnom aktivnou koja se predstavlja ispunjenim crnim krugom. Imajui u vidu da je ve reeno da sluaj upotrebe evidencija lanova biblioteke podrazumeva i upis i ispis lanova tako e i dalji tok aktivnosti u ovom dijagramu zavisiti od aktivnosti koje e lan obavljati u svom domenu (plivakoj stazi). Drugim reima u zavisnosti da li se lan upisuje ili ispisuje dolazie do upisa odnosno ispisa iz evidencije lanova biblioteke. U zavisnosti da li se radi o upisu ili ispisu lana, bibliotekar e vriti ili formiranje zapisa korisnika ili njegovo pretraivanje. U oba konkurentna toka postoje dva identina stanja odluke koja postavljaju sigurnosno pitanje: "Da li je nov lan?". Time se obezbeuje da se ne dupliraju upisi istog lana biblioteke, a u drugoj grani proverava osnovanost brisanja zapisa lana koji mora da postoji da bi uopte bio izbrisan. Dijagram se naravno zavrava oznakom krajnjeg stanja koje se predstavlja krugom koji nije do kraja ispunjen. Na sledeoj slici prikazan je dijagram aktivnosti za voenje evidencije lanova.
Clan Bibliotekar

Start

Upis Da li je nov clan

Ispis

da

ne

Formiranje zapis clana

Trazenje clana

ne

da Brisanje zapisa

da

Azuriranje zapisa

ne

Stop

Slika 6.2. Dijagram aktivnosti za voenje evidencije lanova

alempije@beotel.rs

57

Dijagram aktivnosti za zaduivanje i razduivanje

Na sledeoj slici prikazan je dijagram aktivnosti za osnovnu i najvaniju funkciju bibliotekog poslovanja, opsluivanje lanova naslovima iz fonda biblioteke. Dakle, radi se o zaduivanju i razduivanju naslova iz biblioteke. I ovde se susreemo sa domenima (plivakim linijama) odgovarajuih uesnika u korespodenciji. lan formira zahtev (bilo da eli da zadui ili razdui knjigu), koji nije formalizovan ve se ovde prosto misli na izraavanje elje lana za obavljanjem odgovarajue operacije. Informacije koje e on prosleivati bibliotekaru razlikovae se u zavisnosti od toga da li se radi zaduivanju ili razduivanju naslova, ali to nije aspekt koji razmatra dijagram aktivnosti. Bibliotekar e nakon toga izvravati bilo pretraivanje naslova koji se eli zaduiti bilo zapisa o zaduenju prvenstveno orjentisanom ka linim podacima lana biblioteke. Pratimo za trenutak granu zaduivanja. Nailazimo na stanje odluke kome je uslov: "Da li je naslov zaduen?". U sluaju da nije, na osnovu svih raspoloivih podataka vri se formiranje zapisa zaduenja. U suprotnom sluaju vri se rezervacija naslova. Vratimo se grani razduenja. U tom sluaju vri se pretraivanje zapisa zaduenja na osnovu linih podataka lana biblioteke. Drugim reima proverava se da li se kod tog lana nalazi na zaduenju knjiga koja je podneta na uvid bibliotekaru. Samo u sluaju da je rezultat takve pretrage pozitivan izvrie se raskid zapisa zaduenja. U suprotnom takva aktivnost se nee desiti i stanje zaduenja ostae nepromenjeno.

58

alempije@beotel.rs

: CLAN

: Bibliotekar

Start

Formiranje zahteva

Da li je zaduzivanje?

DA

Pretrazivanje fonda

Da li je knjiga zaduzena? NE DA Formiranje zapisa rezervacije

Formiranje zapisa zaduzenja

Pretrazivanje zapisa zaduzenja

Da li je to ta knjiga? DA Raskidanje zapisa zaduzenja

Stop

Slika 6.3. Dijagram aktivnosti za zaduivanje i razduivanje

Dijagram aktivnosti opominjanje

Na sledeoj slici dat je dijagram aktivnosti za sluaj upotrebe opominjanja korisnika. Sastoji se od tri aktivnosti koje se odvijaju linearno jedna za drugom. Da bi se izdala opomena nekom lanu biblioteke potrebno je pretraiti sva zaduenja i nai sva ona koja nisu regulisana na vreme. Tako se formira lista prekoraenja. S obzirom da je po pravilu takvih zaduenja vie od jednog, potrebno je izabrati jedno od njih, jer se u jednom momentu moe tampati samo jedna opomena. Nakon toga sledi aktivnost tampanja opomene na osnovu izabranog prekoraenja.

alempije@beotel.rs

59

Formiranje liste prekoracenja

Biranje opomene za slanje

Stampanje opomene

Slika 6.4. Dijagram aktivnosti opominjanje korisnika

Dijagram aktivnosti za rezervisanje

Ni ovaj dijagram kao ni prethodni ne karakteriu tzv. plivake linije jer su sve aktivnosti koje su obuhvaene dijagramom u zoni odgovornosti bibliotekara. Dodue ostavlja se verovatnoa (koja e kasnije biti detaljnije razraena) da rezervaciju preko odvojenih terminala vri i sam lan biblioteke. Aktivnosti koje se izvravaju u sastavu sluaja upoterebe rezervisanja naslova su pretraivanje bibliotekog fonda, izbor eljenog naslova i auriranje rezervacije u bazu podataka. U praksi se retko deava da lan doe sa formiranom idejom o tanom naslovu koji eli da izuzme iz biblioteke. Najee lan ima samo neku iru ili uu oblast interesovanja ili neki parcijalni podatak o naslovu. U tu svrhu su predvieni razliiti kriterijumi pretrage koji najee daju vie rezultata pretrage. Iz dobijene liste potrebno je odabrati neki od naslova i izvriti rezervaciju. Kraj rezervisanja se ogleda u aktivnosti auriranja rezervacije u bazu podataka. Nakon te aktivnosti naslov je rezervisan i moe ga zaduiti samo lan koji ga je rezervisao. Naravno, ta rezervacija ne moe stojati veno i pitanje je politike poslovanja biblioteke koliki je taj dozvoljeni period izmeu dana rezervisanja i dana zaduenja. Period o kome se govori ne opisuje se dijagramom aktivnosti.

60

alempije@beotel.rs

Pretrazivanje biblioteckog fonda

Izbor zeljenog naslova

Azuriranje rezervacije u bazu podataka

Slika 6.5. Dijagram aktivnosti za rezervisanje

alempije@beotel.rs

61

Objektno orjentisana analiza za poslove cirkulacije u biblioteci

Objektno orijentisana analiza poslova cirkulacije u biblioteci koristi se za definisanje kljunih koncepata (kljunih apstrakcija) i veza izmedju koncepata (mehanizama) vezanih za domen problema. U okviru ove faze definisae se: Izrada konceptualnog modela Izrada dijagrama sekvenci Definisanje ugovora o izvrenju operacije U daljem tekstu detaljno e se opisati gore definisane aktivnosti.

Izrada konceptualnog modela za poslove cirkulacije u biblioteci

Sutina konceptualnog modela je u pronalaenju klasa u domenu problema kojim se bavimo. To je svojevrsno razmatranje realnog sistema koji stoji pred nama. Klase u konceptualnom modelu su samo rezultat pokuaja da se sagledavanjem realnog sistema prepoznaju neki entiteti koji bi mogli da konkuriu za softverske klasu, te da se prepoznaju neke veze i njihova kardinalnost. Konceptualni model e morati da pretrpi krupne promene kako bi kroz ostatak faze analize i faze dizajna rezultovao dijagramom klasa.

62

alempije@beotel.rs

Slika 6.6. Konceptualni model cirkulacije u biblioteci Dakle, identifikovani su sledei koncepti u konkretnom problemu realnog sistema: lan, Naslov, Zaduenje, Primerak, Izvetaj, Opomena i Rezervacija. U daljem tekstu detaljno e se specificirati svaki pojedinani koncept. Naslov je klasa koja predstavlja apastrakciju stavke bibliotekog fonda, skupa svih knjiga u biblioteci. Ovaj koncept sastoji se od sledeih javnih atributa: naslov: je niz znakova koji predstavlja ime naslova autor: atribut znakovnog tipa koji uva ime i prezime osobe koja je napisala konkretni naslov. Primerak je koncept realnog sistema gde je mogue i deava se da jedan naslov ima vie primeraka. Razdvajanje koncepata naslova i primerka je potrebno zbog razliitih operacija koje se odvijaju nad instancama ovih klasa. Ovaj koncept sastoji se od sledeeg javnog atributa: invbr: je jedinstveni identifikator svakog primerka naslova lan je koncept koji predstavlja svakog legitimnog korisnika bibliotekog fonda. Ovaj koncept sastoji se od sledeih privatnih atributa: jmbg: je jedinstveni matini broj graanina(lana) koji je ovde na neki nain i lanski broj ime: je ime i prezime lana biblioteke telefon : je atribut koji uva podatak o telefonskom broju lana biblioteke.
alempije@beotel.rs

63

Zaduenje je klasa-koncept koji predstavlja apstrakciju veze koju mogu da ostvare izmeu sebe jedan lan i jedan primerak. Ovaj koncept sastoji se od sledeih privatnih atributa: datum: je podatak lan koji sadri datum formiranja konkretnog zaduenja. rok: moe ili biti broj dana na koji se daje primerak na itanje ili konkretan datum do kojeg se izdaje primerak. Opomena je apstrakcija odnosa koji moe postojati izmeu lana i njegovog zaduenja, u sluaju da ne razdui primerak do datog mu roka. Ovaj koncept sastoji se od sledeih privatnih atributa: rednibr: je celobrojna vrednost rednog broja konkretne opomene za konkretnog lana. Rezervacija je koncept koji realizuje apstrakciju odnosa koji moe postojati izmeu jednog naslova i jednog lana Ovaj koncept sastoji se od jednog javnog atributa: datum: je datum kada se naslov rezervisao Izvetaj je koncept realnog sistema koji predstavlja dokument izvetavanja o korisniku i naslova. Ovaj koncept sastoji se od sledeih privatnih atributa: kriterijum: je argument koji govori o tome da li se radi o izvetaju o knjizi ili o izvetaju o naslovu. Moe se rei da svaka koncept u konceptualnom modelu opisan je dodeljenim atributima i nekim elementarnim operacijama. Izuzetno je vano odvojiti koncept naslova od koncepta primerka. Naime dok je naslov jedan, primeraka moe biti vie (u sluaju naslov udbenika redovno ima vie primeraka), na ta ukazuje i kardinalnost veze izmeu ova dva koncepta. Logino je onda to se naslov karakterie atributima kao to su ime naslova i autora, a primerak inventarnim brojem koji ga jedinstveno razlikuje od ostalih primeraka istog naslova. Treba primetiti da koncept rezervacije povezuje koncepte lana i naslova, dok su koncepti lana i primerka povezani asocijativnim konceptima zaduenja i opomena. Upravo se ovde vidi sutina konceptualnog modela-skeniranje realnog sistema u potrazi za klasama objekata i znaenjem njihovih meusobnih veza. Idui tim putem dolo se do toga da lan rezervie naslov bez obzira na primerak (jer je to u tom sluaju nebitno), dok se lan zaduuje sa konkretnim primerkom. Dakle, konceptualni model, opisuje relaciju koncepata lana i primerka, koja je sama sr funkcionisanja realnog sistema bibliotekog poslovanja. Tako primerak sa jedne strane moe biti u jednom vremenskom momentu zaduen jednom ili nijednom, a jedno zaduenje se moe voditi za samo jedan primerak. Idui dalje trasom veze koncepata lan i primerak moe se videti da je po jednom zaduenju mogua ili nijedna ili vie opomena, a jedna opomena moe biti izdata za jedno i samo jedno zaduenje. Istovetna je i kardinalnost veze opomena-lan, gde lan moe imati nijednu ili vie opomena, a jedna opomena moe biti izdata za jednog i samo jednog lana. Poslednji na ovom dijagramu je koncept izvetaja, koji je kao to se

64

alempije@beotel.rs

vidi zajedniki i za lana i za naslov. Veze na oba pravca su jednostruke, zato to u realnom sistemu izvetaj moe u jednom trenutku biti vezan za jednog i samo jednog lana i jedan naslov, a vai i obrnuto.

Izrada dijagrama sekvenci za poslove cirkulacije u biblioteci

Dijagrami sekvenci spadaju u grupu interakcionih dijagrama koji slue za opis dinamikog aspekta modela. Pored sekvencijalnih u ovu grupu dijagrama spadaju i dijagrami saradnje. Naziv potie od tuda to je u sreditu panje ovih dijagrama meusobna komunikacija, interakcija izmeu objekata razliitih klasa. Obe vrste dijagrama (i sekvencijalni i kolaboracioni ) semantiki su jednaki i mogue je vriti meusobnu transformaciju, zato to nose iste informacije. Jedino u emu se razlikuju je ugao gledanja na informacije koje nose. Kod sekvencijalnih dijagrama naglasak je na vremenski redosled odvijanja poruka izmeu objekata razliitih klasa, dok kolaboracioni dijagrami naglaavaju strukturu veza izmeu objekata u interakciji. Dakle, sekvencijalni dijagrami se crtaju na vremenskoj osi, i predstavljaju specifikaciju vremenski zahteva u pogledu ta sistem treba da radi u realnom vremenu. Zato e za razliku od svog sabrata iz grupe interakcionih dijagrama (kolaboracioni dijagrami koji e biti korieni u fazi dizajna problema) biti iskorieni ovde za opis odigravanja dogaaja pojedinih sluaja upotrebe. Vremenskim redosledom poruka u sekvencijalnom dijagramu opisae se logika odvijanja osnovnih funkcija poslova cirkulacije u biblioteci datih sluajevima upotrebe u prethodnoj fazi definisanja zahteva. Dakle, videe se ta podsistem treba da radi u realnom vremenu da bi obavio svoju funkciju predstavljenu sluajom upotrebe.

Sekvencijalni dijagram za rezervisanje naslova

Da bi lan biblioteke, od kojeg i poinje interakcija objekata, rezervisao neki naslov on mora pretraiti naslove koji postoje u bibliotekom fondu. Zato je prva poruka koju alje lan raunaru klijentu ona koja zahteva pretragu. S obzirom da se naslov moe traiti po vie kriterijuma kao odgovor na prethodnu poruku klijent e traiti od lana da izabere kriterijum po kojem e pretraivati naslov (po jeziku, izdavau, datumu unosa, signaturi, inventarnom broju, deskriptoru, naslovu, autoru). Odgovor klijenta je izbor jednog od navedenih kriterijuma i poruka klijentu da pretrai naslov. Klijent, ija je uloga u funkcionisanju podsistema posrednika, kao odgovor na tu poruku jednostavno prosleuje zahtev sa odgovarajuim parametrima serveru. Server, pak po prijemu poruke vri filtriranje svoje baze zapisa o naslovima po dobijenim parametrima. Rezultat takve aktivnosti je raznolik. Moe se po zadatom kriterijumu dobiti nijedan, jedan ili vie naslova koji odgovaraju zadatom kriterijumu. Imajui u vidu da se moe rezervisati samo jedan naslov bie potrebno da se izabere jedan sa dobijene liste. Zato server alje klijentu poruku kojom se zahteva izbor, a klijent taj zahtev lanu u vidu liste sa koje se mora izabrati jedan od naslova da bi se izvrila rezervacija. lan se odluuje za jedan od naslova i alje poruku o rezervaciji klijentu. On tu poruku prosleuje sa odgovarajuim parametrima serveru gde se vri auriranje rezervacije. Sada je obavljena rezervacija eljenog naslova. Naravno da jedan lan moe rezervisati vie naslova ali se u okviru jednog rezervisanja moe rezervisati jedan i samo jedan naslov.

alempije@beotel.rs

65

Na sledeoj slici prikazan je sekvencijalni dijagram za rezervisanje naslova.

: Klijent : Server

: Clan

Zahtavampretragu( ) IzaberiKriterijum( ) Prona| iKnjigu( ) Pretra`i( ) Filtriraj( ) Izaberi( ) IzaberiNaslov( ) Rezervi{ iNaslov( ) Rezervi{ i( )

A`uriraj( )

Slika 6.7. Sekvencijalni dijagram za rezervisanje naslova

Sekvencijalni dijagram za izvetavanje i backupovanje

Za bolje razumevanje dijagrama sekvenci prikazanog na sledeoj slici potrebno je du njene leve vertikalne ivice zamisliti vremesku osu, kao bi se imala potpuna predstava odvijanja poruka u realnom vremenu. Treba rei da imena poruka nisu obavezujua te da je za funkcionisanje sistema bitno da za objekat koji prima poruku ona ima smisao imena koji nosi. Mogue je bilo razbiti na tri odvojena dela koji bi respektivno prikazivali sekvence poruka za izvetavanje o korisniku, izvetavanje o naslovu i backup-ovanje, ali to ovde nije uinjeno zbog izbegavanja nepotrebnog gomilanja, a istovremeno se ne gubi nita na opisu funkcionalnosti. Dakle, da bi se izvrila funkcija izvetavanja potrebno je da prethodno da objekat klase bibliotekar poalje serveru poruku kojom zahteva svoju identifikaciju i poetak rada. Nakon toga alje poruku kojom zahteva kreiranje izvetaja. Posle dobijane poruke server vri pregled odgovarajuih zapisa koji sadre podatke relevantne za izvetaj.

66

alempije@beotel.rs

Dalje su mogua dva dogaaja ili da server poalje poruku kojm se zahteva pravljenje izvetaja o korisniku ili izvetaja o knjizi. Odatle se od objekata izvetaj o knjizi i izvetaj o korisniku prema primerku klase tampaa alje se od objekta poruka kojom se zahteva tampanje odgovarajueg izvetaja. Imajui u vidu dijagram koji je dat primeuje se da je vremenski redosled poruka izvesti o korisniku i izvesti o knjizi nebitan. Vano je samo da poruka tampaj sledi iza ovih poruka, a stvar je bibliotekara da li e prvo eleti da se obavesti o knjizi ili o korisniku(lanu). Na samom kraju vertikalne vremenske ose prikazane su poruke koje se razmenjuju izmeu objekata u funkciji backup-ovanja koja podrazumeva pravljenje rezervne baze podataka. Bibliotekar alje poruku serveru za kopiranje podataka, koju on prosleuje objektu kopirana baza. Naravno da se i ova sekvenca poruka vezana za backup-ovanje mogla u vremenu desiti i ranije ali je to samo stvar izbora primerka klase bibliotekar da li e prvo eleti da napravi izvetaj ili rezervnu kopiju podataka iz podsistema bibliotekog poslovanja. Na sledeoj slici prikazan je sekvencijalni dijagram za izvetavanje i backup-ovanje

: Server Biblitekar : Bibliotekar PrijaviMe( )

Izvestaj o korisniku :

Izvestaj o knjizi :

Kopirana Baza : Baza

: [ tampa~

UradiIzve{ taj( ) Pregledaj() IzvestiOKorisniku( ) IzvestiOKnjizi( ) [ tampaj( ) [ tampaj( ) KopirajBazu( ) Kopiraj( )

Slika 6.8. Sekvencijalni dijagram za izvetavanje i backup-ovanje

Sekvencijalni dijagram za opominjanje lanova

Na sledeoj slici prikazana je vremenska sekvenca poruka koje razmenjuju objekti prilikom ostvarenja funkcije opominjanja. Potrebno je da na poetku objekat klase bibliotekar poalje

alempije@beotel.rs

67

serveru poruku za listanje prekoraenja roka zaduenja. Ta poruka izavae pretraivanje na serveru svih zaduenja koja nisu raskinuta do roka koji je postavljen. Rezultat te pretrage u realnom sistemu je po pravilu spisak koji sadri vie od jednog prekoraenog zaduenja. Stoga e svojevrsna povratna poruka servera ka bibliotekaru biti da se izbere neko od tih prekoraenja kako bi se mogla tampati opomena. Ta poruka nije SW ve je e prevashodno biti u vidu ekranskog prikaza spiska prekoraenja koji e prisiliti bibliotekara da izabere neke od njih kako bi se mogla tampati opomena. Sada bibliotekar kao reakciju na poruku servera da izabere neko od prekoraenja alje poruku da se tampa jedna konkretna opomena. Reakcija servera na tu poruku je njeno prosto prosleivanje tampau. Na sledeoj slici prikazae se dijagram sekvenci za rezervisanje naslova i to za onaj njegov modalitet koji se oslanja na mrenu arhitekturu podsistema. Razlog za to je neto sloenija saradnja izmeu objekata u tom modu rezervisanja, koji je posledica dodavanja jo jednog nivoa posredovanja u pristupu podsistemu (klijenta preko kojeg se pristupa podacima na serveru).

: Bibliotekar

: Server Pretra`uj( )

: [ tampa~

Listajprekora~ enja( ) Izaberi( ) [ tampajopomenu( )

[ tampaj( )

Slika 6.9. Sekvencijalni dijagram za opominjanje lanova

Izrada sekvencijalnih dijagrama interfejsa

Pored logike osnovnih funkcija koje treba da obavlja informacioni podsistem poslova cirkulacije u bibliotekom poslovanju, mogue je sekvencijalnim dijagramima opisati i vremenski redosled razmene poruka izmeu razliitih formi (maski) aplikacije u toku izvravanja specifinih funkcija podsistema. injenica je da bi se svi dijagrami vezani za modelovanje korisnikog interfejsa podsistema mogli svrstati u objektno orjentisani dizajn, s obzirom da se radi o reenju (kako sistem treba da obavlja osnovne funkcije posredstvom interfejsa). Svrastavanje ovakvih sekvencijalnih dijagrama u poglavlje posveeno objektno orjentisanoj analizi treba shvatiti 68

alempije@beotel.rs

uslovno, te da su tu dati radi neprekidnosti izlaganja o sekvencijalnim dijagramima. Na dijagramima pojavie se objekti ( primerci) nekih novih klasa koje e kasnije podrobnije biti dati u dijagramima klasa interfejsa. Te klase uglavnom predstavljaju razliite forme ( maske ) koje e se pojavljivati u aplikaciji.

Sekvencijalni dijagram interfejsa dodavanja lana

Prilikom upisa novog lana u biblioteku pred bibliotekarem koji obavlja tu funkciju nalazi se forma za unos novog lana. Da bi uneo podatke za novog lana on mora da pritisne dugme Dodaj, koje se nalazi na formi. Potom se vri provera da li takav lan ve postoji i ta provera se vri na osnovu JMBG, poto nigde pa ni u podsistemu biblioteke se nemogu nai dve osobe istog matinog broja. Jedna osoba nemoe dva puta biti upisan u biblioteku. Tek potom se iz forme novog lana alje poruka koja je zapravo konstruktor klase lan. Tako formiran objekat se smeta i uva u nekoj tabeli baze podataka koja se koristi. Na sledeoj slici prikazan je sekvencijalni dijagram interfejsa dodavanja lana.

: Bibliotekar

: FormaNovogClana

: CLAN

DugmeDodaj_Clicked ( ) PoJMBG CLAN pohrani

Provera da li vec postoji

Slika 6.10. Sekvencijalni dijagram interfejsa dodavanja lana

Sekvencijalni dijagram interfejsa zaduivanja

I na ovom dijagramu prepliu se objekti klasa koji pretstavljaju korisniki interfejs i klasa koje opisuju logiku rada baze podataka. Meutim, to je neminovno jer je posledica pokretanja kontrola koje se nalaze na maskama interfejsa kreiranje objekata softverskih klasa koji uvaju trenutno stanje podsistema u pogledu materijalnog zaduenja. Na slici A.6.12. prikazan je sekvencijalni dijagram interfejsa zaduivanja.

Sekvencijalni dijagram interfejsa razduivanja

Kod razduivanja bibliotekar radi na formi za razduivanje, odakle je redosled radnji sledei. Naslov se trai po inventarnom broju i tu se koristi forma za pretragu naslova. Zatim se pregledaju primerci tog naslova i kada se nae primerak naslova, koji se razduuje, te se na osnovu njega trai zaduenje. Kada se nae zaduenje trai se i pribavlja lan koji ga dui. Na osnovu tako

alempije@beotel.rs

69

uspostavljene veze i provere vri se raskidanje zaduenja i njegovo uklanjanje iz tabele zaduenja. Na slici 6.13. prikazan je sekvencijalni dijagram interfejsa razduivanja

Sekvencijalni dijagram rezervisanja

Pri rezervisanju prvo se sa forme za rezervisanja poziva forma za pretraivanje naslova koji e se rezervisati. Naslov se pretrauje po inventarnom broju. Dodue moe se naslov pretraivati i po drugim kriterijumima ali e samo ovakvo pretraivanje dati jedan i samo jedan naslov. Potom se preko forme za pretragu lanova pretrauje lan koji e rezervisati naslov. Kako je postavljeno u ovom dijagramu ovo pretraivanje lana se vri po matinom broju. Kao i kod naslova i lana mogue je pretraivati po jo nekim pa i zbirnim kriterijumima, ali samo pretraivanje po matinom broju daje jednoznaan rezultat pretrage. Nakon to se tako pronae odgovarajui lan i naslov za rezervaciju, porukom koja je zapravo konstruktor klase rezervacije kreira se objekat klase rezervacija. Taj objekat se pohranjuje i stanje sistema uveano za jednu rezervaciju se uveava. Na slici prik 6.14. prikazan je sekvencijalni dijagram rezervisanja.

Sekvencijalni dijagram interfejsa brisanja rezervacije

Na sledej slici daje se opis deavanja prilikom brisanja postojee rezervacije. Bibliotekar komunicira sa odgovarajuom formom za brisanje rezervacije i dijalogom za pretragu naslova. Na osnovu dobijenih rezultata vre se intervencije nad stanjima objekata klasa naslov, lan i rezervacija. Ovakvim sekvencijalnim dijagramima mogue je opisati sve to se deava na svim formama aplikacije bibliotekog poslovanja. Smatrajui da su dosadanjim primerima u dovoljnoj meri opisani mehanizmi bibliotekog poslovanja i semantika i notacija sekvencijalnih dijagrama prostali sekvencijalni dijagrami koji su izraeni za potrebe ovog projekta bie dati samo potpisani bez tekstualnog opisa. Radi se o dijagramima koji se odnose na funkcionisanje interfejsa za odravanje aurnosti sistema. Preko korisnikog interfejsa koji je pomenut vri dodavanje novih naslova, lanova i primeraka ali i njihovo brisanje iz podsistema bibliotekog poslovanja. Na slici 6.15. prikazan je sekvencijalni dijagram interfejsa brisanja rezervacije.

70

alempije@beotel.rs

: Bibliotekar

: FormaZaduzivanja

: NASLOV

: DijalogPretrageNaslova

: DijalogPretrageClana

: CLAN

: Primerak

: ZADUZENJE

DugmePronadjiNaslov_Clicked ( )

DijalogPretrageNaslova (Frame, boolean)

DugmePronadji_Clicked ( ) PoINVBR DaDugme_Clicked ( ) dostaviNaslov (ObjId) pribaviBrojPrimeraka pribaviPrimerak(int) pribaviObjekat pribaviINVBR PronadjiPodatkeClana_Clicked ( ) DijalogpretrageClana (Frame, boolean)

PronadjiDugme_Clicked ( ) PoJMBG DaDugme_Clicked ( ) dostaviClana (ObjId)

ListaPrimeraka_ListSelect ( ) DaDugme_Clicked ( ) pribaviPrimerakSaInvbr Zaduzenje pohrani( )

zaduzi azuriraj dodajZaduzenje azuriraj

Slika 6.12. Sekvencijalni dijagram interfejsa zaduivanja

alempije@beotel.rs

71

: Bibliotekar

: FormaRazduzivanja

: DijalogPretrageNaslova

: NASLOV

: Primerak

: ZADUZENJE

: CLAN

DugmePronadjiNaslov_Clicked ( ) DijalogPretrageNaslova (Frame, boolean) DugmePronadji_Clicked ( ) PoINVBR DaDugme_Clicked ( ) dostaviNaslov (ObjId) ListaPrimeraka_Selected ( ) proveriStanje ( ) pribaviPrimerakSaINVBR pribaviZaduzenje pribaviClana

DaDugme_Clicked ( ) pribaviPrimerakSaINVBR pribaviZaduzenje pribaviClana pohrani azuriraj obrisiZaduzenje azuriraj izbrisi

Slika 6.13. Sekvencijalni dijagram interfejsa razduivanja

72

alempije@beotel.rs

: Bibliotekar

: FormaRezervisanja

: DijalogPretrageNaslova

: NASLOV

: DijalogPretrageClana

: REZERVACIJA

: CLAN

DugmePronadjiNaslov_Clicked ( ) DijalogPretrageNaslova (Frame, boolean) DugmePronadji_Clicked ( ) PoINVBR DaDugme_Clicked ( ) dostaviNaslov (ObjId) DugmePronadjiClana_Clicked ( ) DijalogpretrageClana (Frame, boolean)

PronadjiDugme_Clicked ( )

PoJMBG dostaviClana (ObjId) DaDugme_Clicked ( ) Rezervacija pohrani dodajRezervaciju azuriraj dodajRezervaciju azuriraj

Slika 6.14. Sekvencijalni dijagram rezervisanja

alempije@beotel.rs

73

: Bibliotekar

: FormaBrisanjaRezervacije

: DijalogPretrageNaslova

: NASLOV

: REZERVACIJA

: CLAN

DugmePronadjiNaslov_Clicked ( ) DijalogPretrageNaslova (Frame, boolean) DugmePronadji_Clicked ( ) PoJMBG DaDugme_Clicked ( ) dostaviNaslov (ObjId) pribaviBrojRezervacija pribaviRezervaciju(int) pribaviClana pribaviJMBG ListaClanova_Selected ( ) DaDugme_Clicked ( )

PoJMBG pribaviRezervaciju(int) pribaviNaslov pribaviNaslov obrisiRezervaciju azuriraj ukloniRezervaciju azuriraj izbrisi

Slika 6.15. Sekvencijalni dijagram interfejsa brisanja rezervacije

74

alempije@beotel.rs

Sekvencijalni dijagram interfejsa dodavanja naslova

Da bi se dodao novi naslov u evidenciju bibliotekar mora da pozivom konstruktora forme novog naslova otvori masku za unos podataka novog naslova. Kada se unesu svi podaci alje se poruka izazvana dogaajem pritiska na da dugme. Potom se proverava da li takav naslov postoji imajui u vidu upisani inventarni ili ISBN broj. Ako takav naslov ne postoji poziva se konstruktor objekta klase naslov ije se stanje postavlja u zavisnosti od podataka novog lana. U zavisnosti od broja primeraka novog naslova odreeni broj puta se poziva i konstruktor objekta klase primerka. Tek nakon toga se objekat novog naslova zaista i menmorie u bazu podataka. Kao to postoji vremenski redosled razmene poruka izmeu objekata klasa interfejsa u sluaju dodavanja naslova, tako vremenski redosled poruka postoji i u sluaju brisanja naslova iz evidencije. Na sledeoj prikazan je sekvencijalni dijagram interfejsa dodavanja naslova.

: Bibliotekar

: FormaNovogNaslova

: NASLOV

: Primerak

FormaNovogNaslova ( ) DugmeDodaj ( ) Provera da li postoji vec naslov Kreiranje naslova i primeraka PoINVBR PoISBN Naslov Primerak pohrani dodajNaslov pohrani

Smestanje primeraka i naslova

Slika 6.16. Sekvencijalni dijagram interfejsa dodavanja naslova

Sekvencijalni dijagram interfejsa brisanje naslova

Prvo se naslov koji se brie mora pronai i zato se prvo poziva konstruktor klase dijaloga pretrage naslova. U taj dijalog se unosi kriterijum pretraivanja pa se u zavisnosti od njega naslov pretrauje (ovde je uzeto primera radi pretraivanje po inventarnom broju). Kada se pronae naslov koji treba da se izbrie otvara se forma prepravke naslova, jer je i brisanje neka vrsta prepravke. Naslov se potom fiziki brie i pribavljaju se njegovi primerci, proverava se da li su primerci zadueni , ako nisu i ti se objekti briu a bez ikakvog ogranienja uklanjaju se i sve rezervacije tog naslova. Na sledeoj slici prikazan je sekvencijalni dijagram interfejsa brisanje naslova.

alempije@beotel.rs

75

: Bibliotekar

: DijalogPretrageNaslova

: NASLOV

: FormaPrepravkeNaslova

: Primerak

: REZERVACIJA

: CLAN

DugmePronadji_Clicked ( ) PoINVBR DaDugme_Clicked ( ) FormaPrepravkeNaslova (ObjId, boolean) DugmeIzbrisi_Clicked ( ) pribaviBrojPrimeraka Pretpostavka da primerak nije zaduzen PribaviPrimerak(int) jePozajmljen izbrisi pribaviBrojRezervacija pribaviRezervaciju(int) PribaviClana obrisiRezervaciju izbrisi obrisi

Slika 6.17. Sekvencijalni dijagram interfejsa brisanje naslova

76

alempije@beotel.rs

Sekvencijalni dijagram interfejsa dodavanja primerka

U realnom sistemu je za oekivati takvu situaciju da e za ve zavedeni naslov pristizati novi primerci. Prvo se mora pronai naslov za koji se dodaju primerci i zato se inicira forma pretrage naslova. Naslov se potom pretrauje po nekom kriterijumu (recimo inventarni broj) i za pronaeni naslov se otvara forma prepravke naslova. Iz ove forme se dolazi do podatka o postojeem broju primeraka i ostalih injenica od znaaja za dodavanje novog primerka naslova. Na slici 6.18. prikazan je sekvencijalni dijagram interfejsa dodavanja primerka.

Sekvencijalni dijagram interfejsa brisanja primerka

Inverzna operacija od gore opisane je naravno, operacija brisanja primerka naslova. Veoma je slian scenario odvijanja razmene poruka izmeu objekata klasa u interakciji sa onim opisanim u prethodnim sluajevima. Mora se otvoriti forma pretrage naslova kako bi se naao naslov kojem se briu primerci. Za pronaeni naslov se otvara dijalog prepravke naslova, iz nje se pribavljaju postojei primerci naslova i odabrani se uklanjaju iz evidencije bibliotekog podsistema. Na slici 6.19. prikazan je sekvencijalni dijagram interfejsa brisanja primerka.

alempije@beotel.rs

77

: Bibliotekar

: DijalogPretrageNaslova

: NASLOV

: FormaPrepravkeNaslova

: NASLOV

: Primerak

DugmePronadji_Clicked ( ) PoINVBR DaDugme_Clicked ( ) FormaPrepravkeNaslova (ObjId, boolean) pribaviNaslov pribaviBrojPrimeraka pribaviPrimerak(int) pribaviINVBR DugmeDodajPrimerak_Clicked ( ) Primerak pohrani dodajPrimerak azuriraj

Slika 6.18. Sekvencijalni dijagram interfejsa dodavanja primerka

78

alempije@beotel.rs

: Bibliotekar

: DijalogPretrageNaslova

: NASLOV

: FormaPrepravkeNaslova

: NASLOV

: Primerak

DugmePronadji_Clicked ( ) PoInventarnomBr DaDugme_Clicked ( ) FormaPrepravkeNaslova (ObjId, boolean) pribaviNaslov pribaviBrojPrimeraka pribaviPrimerak pribaviInvBr DugmeObrisiPrimerak_Clicked ( ) pribaviPrimerak izbrisi obrisiIndexPrimerka azuriraj

Slika 6.19. Sekvencijalni dijagram interfejsa brisanja primerka

alempije@beotel.rs

79

Sekvencijalni dijagram interfejsa brisanja lana

Na kraju je ostao da se opie jo sekvencijalni dijagram interfejsa za brisanje lana biblioteke. lan iji se podaci uklanjaju iz podsistema mora se prvo pronai i zato se prvo radi sa dijalogom za pretragu lana. Iz njega se lan pretrauje po zadatim kriterijumima (najee po jedinstvenom matinom broju graanina). Za pronaenog lana biblioteke otvara se forma prepravke lana, s obzirom da je i brisanje svojevrsna promena stanja objekta klase lana. Za lana se pribavlja spisak primeraka naslova koje dui kako i spisak njegovih rezervacija. U naelu je zabranjeno izbrisati lana koji nije u potpunosti razduen sa primercima iz bibliotekog fonda, a to zavisi od usvojene politike poslovanja koja je podlona ponekad i isuvie estim promenama. Bilo kako bilo, rezervacije koje je ostvario lan u toku svog ivotnog veka u bibliotekom podsistemu se uklanjaju bez ikakvih ogranienja. Indikativno je i sa stanovita programerske logike oekivano da se prvo pozivaju destruktori sa lanom povezanih objekata klasa zaduenja i rezervacija. pre nego to se pozove i destruktor konkretnog objekta klase lana biblioteke. Na sledeoj slici prikazan je sekvencijalni dijagram interfejsa brisanja lana.

80

alempije@beotel.rs

: Bibliotekar

: DijalogPretrageClana

: CLAN

: FormaPrepravkeClana

: ZADUZENJE

: Primerak

: REZERVACIJA

: NASLOV

PronadjiDugme_Clicked ( ) PoJMBG DaDugme_Clicked ( ) FormaPrepravkeClana (ObjId, boolean) pribaviClana DugmeIzbrisi_Clicked ( ) pribaviBrojZaduzenja pribaviZaduzenje(int) pribaviPrimerak postaviZaduzenje izbrisi pribaviBrojRezervacija pribaviRezervaciju(int) pribaviNaslov izbrisiRezervaciju obrisi izbrisi

Slika 6.20. Sekvencijalni dijagram interfejsa brisanja clana

alempije@beotel.rs

81

Definisanje ugovora o izvrenju operacija

Ugovori o izvrenju operacija definiu efekte koje operacije treba da imaju po stanje sistema. Uobiajno je predstavljanje operacija u vidu formalnog izlaganja opisa stajna u kojima se sistem nalazi pre i posle izvrenja operacija. Ugovore je mogue definisati na veoma niskom nivou, pojedinanih metoda svake softverske klase, ali i na nivou uoptenih sistemskih operacija. S obzirom da se razvoj informacionog sistema bibliotekog poslovanja jo uvek nalazi u fazi analize kada treba dati ogovor na pitanje ta sistem treba da radi, ovde e biti specificirani neki ugovori o izvrenju operacija sistema, posmatranog kao celina. Dakle radi se o formalnim opisima stanja sistema nakon izvrenja operacija ija je realizacija u neku ruku data prethodnom izradom sekvencijalnih dijagrama. Ime operacije: Dodavanje lana Odgovornosti: Upisuje podatke novog lana u evidenciju podsistema Izuzeci: lan tog matinog broja ve postoji ; Nisu uneti svi obavezni podaci lana Preduslov: ifarnici atributa lana su aurni Post uslov: Kreiran je novi objekat klase lan, vezan je za odreene reference kategorije lanstva(student, zaposlen ili vanredni), te u zavisnosti od kategorije za identifikatore studentske klase, slube, jedinice ili ustanove. Ime operacije: Brisanje lana Odgovornosti: Uklanjanje zapisa podataka lana iz evidencije podsistema. Izuzeci: lan ne postoji, lan jo uvek ima zaduenja Preduslov: lan postoji i razduio je sve naslove koje je imao na pozajmici Post uslov: Uniten je konkretni primerak klase lana, i izbrisane su sve njegove rezervacije koje postoje u podsistemu. Ime operacije: Dodavanje naslova Odgovornosti: Unosi podatke novog naslova u evidenciju podsistema Izuzeci: Naslov tog inventarnog broja ili signature ve postoji; Nisu uneti svi obavezni podaci naslova. Preduslov: Svi ifarnici atributa naslova su aurni Post uslov: Kreiran je novi objekat klase naslov, povezan je sa odgovarajuim identifikatorima jezika i udk oblasti. Ime operacije: Brisanje naslova Odgovornosti: Uklanja podatke naslova iz evidencije podsistema Izuzeci: Naslov ne postoji Preduslov: Naslov mora da postoji

82

alempije@beotel.rs

Post uslov: Uniten je primerak klase naslov, i sve njegove rezervacije, zaduenja i opomena. Ime operacije: Zaduivanje Odgovornosti: Zaduuje lana biblioteke sa konkretnim primerkom naslova Izuzeci: lan ili naslov ne postoji; svi primerci naslova su zadueni ili rezervisani Preduslov: lan i naslov postoje i ima slobodnih primeraka naslova Post uslov: Kreiran je novi objekat klase zaduenje sa pripadajuim atributima Ime operacije: Razduivanje Odgovornosti: Razduuje lana biblioteke sa primerakom naslova Izuzeci: Ne poklapaju se inventarni brojevi primerka naslova koji je zaduen i primerka koji pokuava da se razdui Preduslov: zaduenje postoji Post uslov: Uniten je konkretni primerak klase zaduenja, i kreiran je odgovarajui objekat klase razduenja. Ime operacije: Rezervisanje Odgovornosti: lan rezervie naslov koji mu nije trenutno dostupan ili ne eli da ga pozajmi odmah, ve u narednom periodu. Izuzeci: lan ili naslov ne postoji; lan je ve rezervisao naslov Preduslov: lan koji rezervie i naslov koji se rezervie moraju da postoje. Post uslov: Kreiran je odgovarajui objekat klase rezervacije Ime operacije: Brisanje rezervacije Odgovornosti: Ukida se rezervacija lana biblioteke u odnosu na neki naslov iz bibliotekog fonda. Izuzeci: Rezervacija ne postoji Preduslov: Prolo je odreeno vreme nakon to je primerak naslova osloboen a rezervacija nije prerasla u zaduenje Post uslov: uklonjen je objekat klase rezervacije iz liste rezervacije. Redosled objekata u FIFO listi rezervacija je auriran.

alempije@beotel.rs

83

Objektno orjentisan dizajn za poslove cirkulacije u biblioteci

U okviru Objektno orjentisan dizajn poslova u biblioteci treba da se odogovor na pitanje kako izvriti proces logikog i fizikog dekomponovanja sistema na manje softverske celine i blokove, i pritom izvriti specifikaciju statikih i dinamikih programskih celina. U ovoj fazi razmatrae se: Izrada dijagrama saradnje poslova cirkulacije u biblioteci Izrada potpunog dijagrama klasa za poslove cirkulacije u biblioteci Izrada dijagrama stanja poslova cirkulacije u biblioteci Definisanje paketa U daljem tekstu detaljno e se opisati gore definisane aktivnosti.

Izrada dijagrama saradnje poslova cirkulacije u biblioteci

Kao to smo ve rekli u poglavlju vezanom za objektno orjentisanu analizu i dijagrami saradnje spadaju u interakcione dijagrame. Dijagramima saradnje se modeluju tokovi kontrole po organizaciji. Takvo modelovanje naglaava strukturne odnose objekata u interakciji, koji razmenjuju poruke. U odnosu na dijagrame sekvenci dijagrami saradnje( kolaboracije) su mnogo zgodniji za opis vie paralelnih tokova kontrole. Objekti su na dijagramu saradnje prikazani kao vorovi nekog grafa izmeu kojih teku veze kojima se kreu poruke. Znaaj dijagrama saradnje je u tome to se njima na neki nain predefiniu metode (funkcije lanice) koje e se pojavljivati u dijagramu klasa. Svaka od operacija lanica klase na neki nain je satavljena od poruka koje razmenjuju objekti u saradnji. Na sledeoj slici je dat dijagram saradnje za izvetavanje i backupovanje.

Dijagram saradnje za izvetavanje i backup-ovanje

S obzirom da je smisao odvijanja poruka prethodnog dijagrama objanjen na istom sluaju ali za sekvencijalan dijagram, ovde e se samo skrenuti panja na neke momente koji nisu mogli biti prikazani notacijom u vremenskom domenu. Ovde se moe videti da su nakon slanja odgovarajuih poruka (kopiraj bazu, uradi izvetaj) serveru mogua dva paralelna toka. Mogue

84

alempije@beotel.rs

je i kopirati i bazu i uraditi izvetaj i za korisnika i za naslov. Taj momenat nije mogao da doe do izraaja kod opisa pomou sekvencijalnog dijagrama. I na ovom dijagramu kao i na sekvencijalnom, a moda i jo jasnije, postaje jasno da poruka tampaj moe uslediti tek nakon odgovarajuih poruka za kreiranjem izvetaja. Obe poruke se stiu u jednom voru grafa, primerku klase tampa. Na sledeoj slici prikazan je dijagram saradnje za izvetavanje i backup-ovanje.
3: Pregledaj() 1: PrijaviMe( ) 2: UradiIzve{ taj( ) 8: KopirajBazu( )

: Server

9: Kopiraj( )

Kopirana Baza

Biblitekar

5: IzvestiOKnjizi( ) 4: IzvestiOKorisniku( )

Izvestaj o knjizi : Izve{ taj

Izvestaj o korisniku 6: [ tampaj( ) : [ tampa~

7: [ tam paj( )

Slika 6.21. Dijagram saradnje za izvetavanje i backup-ovanje

Dijagram saradnje za opominjanje

Dijagram koji se nalazi na sledeoj slicic znatno je jednostavniji od prethodnog zato to ima manje objekta u kolaboraciji pa je samim tim i interakcija izmeu njih prostija. Brojevi koji su dodati u odnosu na prethodni dijagram predstavljaju numeraciju poruka po vremenskom redosledu, koja je preuzeta iz odgovarajueg sekvencijalnog dijagrama. Nema paralelnih tokova kontrole kao u prethodnom sluaju. Logika kojom se odvija slanje poruka opisana je u delu posveenom sekvencijalnom dijagramu iste funkcije informacionog podsistema bibliotekog poslovanja. Na sledeoj slici prikazan je dijagram saradnje za opominjanje.

alempije@beotel.rs

85

2: Pretra`uj( ) 1: Lista jprekora~ enja () 4: [ tam pajopom enu( ) : Serve r 3: Izabe ri( ) : Bibliotekar 5: [ tam paj( ) : [ ta m pa~

Slika 6.22. Dijagram saradnje za opominjanje

Dijagram saradnje za rezervisanje

Dijagram saradnje Na sledeoj slici ilustruje razmenu poruka izmeu objekata klasa. Nema pralelnih tokova kontrole. Poruke se izmeu objekata razmenjuju po redosledu brojeva koji ih numeriu i to na trasi lan-klijent-server. lan biblioteke preko raunara razmenjuju poruke sa serverom gde se nalaze podaci neophodni za obavljanje funkcije rezervisanja naslova. Smisao odvijanja slanja poruka ve je opisan u odgovarajuem sekvencijalnom dijagramu u poglavlju objektno orjentisane analize.
1: Zahtavam pretragu( ) 3: Prona| iKnjigu( ) 8: Rezervi{ iNaslov( ) 2: IzaberiKriterijum( ) : Clan 7: IzaberiNaslov( ) 6: Izaberi( ) 5: Filtriraj( ) 10: A`uriraj( ) : Server

: Klijent 4: Pretra`i( ) 9: Rezervi{ i( )

Slika 6.23. Dijagram saradnje za rezervisanje

86

alempije@beotel.rs

Izrada dijagrama saradnje interfejsa

Na isti nain kao to su definisani sekvencijalni dijagrami za korisniki interfejs razliitih funkcija podsistema, isto tako mogu biti uraeni i kolaboracioni dijagrami interfejsa. injenica da su ve uradjeni sekvencijalni dijagrami istih pojava taj zadatak ini samo lakim, zbog semantike jednakosti ove dve podvrste interakcionih dijagrama. Jedina razlika, to je ve naglaeno, je u pogledu na saradnju koju objekti interfejsnih klasa ostvaruju razmenjujui poruke. Za razliku od sekvencijalnih dijagrama klasa interfejsa kolaboracioni dijagrami interfejsa naglaavaju strukturu objekata koji komuniciraju i veza izmeu njih. Pored oekivanih interfejsnih klasa ovde e se pojavljivati i neke poslovne klase, tako da ni ovi kao ni sekvencijalni dijagrami nee biti u potpunosti samo interfejsni. No to je i za oekivati jer granica izmeu interfejsnog sloja i sloja logike aplikacije nije jasno povuena, pogotovu kada se uzmu u obzir interakcioni dijagrami, koji se zasnivaju na saradnji objekata razliitih klasa pa makar one bile i iz razliitih slojeva. Uostalom normalno je da obrasci i poslovni objekti meusobno razmenjuju poruke- na tome se zasniva svaka aplikacija u grafikom okruenju.

Dijagram saradnje interfejsa brisanja primeraka

Pratei numeraciju koja oznaava redosled slanja poruka u komunikaciji koja se ostvaruje pri brisanju postojeeg primerka nekog naslova moe se rekonstruisati saradnja intrfejsa i objekata poslovnih klasa. Bibliotekar koji vri brisanje primerka pritiska dugme pronai i time pretrauje naslov po inventarnom broju (mogui su i drugi kriterijumi pretrage). Izbor tog naslova se potvruje, nakon ega se otvara forma za prepravku naslova pozivom njenog konstruktora (brisanje primerka je zapravo menjanje jednog podatka naslova). Potom se pribavlja naslov sa svim prateim podacima, od kojih je od posebnog interesa broj primeraka jednog naslova. Tako dobijeni primerak se uklanja a stanje aurira. Time je izvreno brisanje primerka naslova. Na sledeoj slici prikazan je dijagram saradnje interfejsa brisanja primeraka

alempije@beotel.rs

87

1: DugmePronadji_Clicked ( ) 3: DaDugme_Clicked ( )

: DijalogPretrageNaslova

: Bibliotekar

5: pribaviNaslov 6: pribaviBrojPrimeraka 7: pribaviPrimerak 10: pribaviPrimerak 4: FormaPrepravkeNaslova (ObjId, boolean)12: obrisiIndexPrimerka 9: DugmeObrisiPrimerak_Clicked ( ) 13: azuriraj

: NASLOV

2: PoInventarnomBr

8: pribaviInvBr 11: izbrisi : FormaPrepravkeNaslova : Primerak : NASLOV

Slika 6.24. Dijagram saradnje interfejsa brisanja primeraka

Dijagram saradnje interfejsa dodavanje lana

Dijagram saradnje interfejsa za upis novog lana biblioteke je krajnje jednostavan kao i njegov parnjak iz grupe sekvencijalnih dijagrama. Na pritisak dugmeta na formi za dodavanje novog lana pre nego to se pozove konstruktor lana proverava se po matinom broju da takav lan ve ne postoji. Jedna osoba moe samo jednom biti ulanjena u biblioteku. Na sledeoj slici prikazan je dijagram saradnje interfejsa dodavanje lana.
: FormaNovogClana

1: DugmeDodaj_Clicked ( )

2: PoJMBG 3: CLAN 4: pohrani

: CLAN : Bibliotekar

Slika 6.25.Dijagram saradnje interfejsa dodavanje lana

88

alempije@beotel.rs

Dijagram saradnje interfejs brisanja lana

Da bi se lan izbrisao mora se prvo pretraiti. Zato je u saradnji potrebna forma za pretragu lana, potom se poziva forma za prepravku lana jer je brisanje lana na neki nain njegova prepravka. Interesantno je da se na osnovu numeracije moe odmah rei da pre nego to se izbrie lan pribavljaju se njegova zaduenja i njegove rezervacije pa se i one uklanjaju. Tek nakon brisanja rezervacija i zaduenja vri se i uklanjanje objekta klase lana. Na sledeoj slici prikazan ke dijagram saradnje interfejs brisanja lana.
: DijalogPretrageClana 2: PoJMBG : CLAN

1: PronadjiDugme_Clicked ( ) 3: DaDugme_Clicked ( )

5: pribaviClana 7: pribaviBrojZaduzenja 8: pribaviZaduzenje(int) 12: pribaviBrojRezervacija 13: pribaviRezervaciju(int) 17: izbrisi

4: FormaPrepravkeClana (ObjId, boolean) 6: DugmeIzbrisi_Clicked ( ) : Bibliotekar 10: postaviZaduzenje : Primerak 9: pribaviPrimerak 11: izbrisi

: NASLOV 15: izbrisiRezervaciju

: FormaPrepravkeClana

: REZERVACIJA

14: pribaviNaslov 16: obrisi

: ZADUZENJE

Slika 6.26. Dijagram saradnje interfejs brisanja lana

Dijagram saradnje interfejsa dodavanja naslova

U sluaju kada se uvodi novi naslov (pristigla je nova knjiga), bibliotekar sa sistemom komunicira preko forme novog naslova. I ovde se vri standardna provera da ne postoji ve naslov istog inventarnog broja. Interesantno je da se kreira objekat klase naslova pa nakon toga i odgovarajui primerci naslova u sluaju da naslov ima vie primeraka. Tek nakon toga vri se smetanje novog naslova u podsistem bibliotekog poslovanja na . Na sledeoj slici prikazan je dijagram saradnje interfejsa dodavanja naslova.

alempije@beotel.rs

89

1: FormaNovogNaslova ( ) 2: DugmeDodaj ( ) : FormaNovogNaslova

: Bibliotekar

6: Primerak 7: pohrani 3: PoINVBR 4: PoISBN 5: Naslov 8: dodajNaslov 9: pohrani

: NASLOV

: Primerak

Slika 6.27. Dijagram saradnje interfejsa dodavanja naslova

Dijagram saradnje interfejsa dodavanja primerka

U poslovanju biblioteke deava se da naknadno stignu novi primerci naslova koji ve postoji zaveden u podsistemu. Tada je potrebno zavesti te primerke , a to nije isto kao unos novog naslova. Zato za tu operaciju postoji posebna forma prepravke naslova, jer je unoenje novih primeraka u naslov promena podataka naslova. No, pre toga potrebno je putem dijaloga za pretragu naslova pronai naslov, bibliografsku jedinicu za koju se unose novi primerci. Naslov se pretrauje, po pravilu, po inventarnom broju, mada nije obavezno, ali je preporuljivo. Kada se pronae odgovarajui naslov dobavlja se njegov broj primeraka kako bi se znalo koje redne brojeve dodeliti novopridolim primercima. Tek tada se za poznate podatke poziva konstruktor primerka i nastaje novi objekat klase primerka. Na sledeoj slici prikazan je dijagram saradnje interfejsa dodavanja primerka.

90

alempije@beotel.rs

1: DugmePronadji_Clicked ( ) 3: DaDugme_Clicked ( )

: DijalogPretrageNaslova

: Bibliotekar 4: FormaPrepravkeNaslova (ObjId, boolean) 9: DugmeDodajPrimerak_Clicked ( ) 2: PoINVBR

: FormaPrepravkeNaslova

: NASLOV 8: pribaviINVBR 10: Primerak 11: pohrani

5: pribaviNaslov 6: pribaviBrojPrimeraka 7: pribaviPrimerak(int) 12: dodajPrimerak 13: azuriraj

: Primerak : NASLOV

Slika 6.28. Dijagram saradnje interfejsa dodavanja primerka

Dijagram saradnje interfejsa brisanja naslova

U skladu sa usvojenom politikom poslovanja definisani uslovi kada moe doi do rashodovanja nekog naslova. Definisanje tih uslova ne spada u domen informacionog sistema, on samo izvrava brisanje naslova kada se za to donese prethodna odluka. I ovu funkciju obavlja bibliotekar preko korisnikog interfejsa aplikacije. Naravno radi se sa maskom koja je dijalog pretrage naslova, koji se eli obrisati. Na osnovu dobijenog rezultata pretrage poziva se forma za prepravku naslova, poto se brisanje naslova moe smatrati njegovom svojevrsnom prepravkom. Za svaki naslov se pribavljaju primerci i rezervacije, kako bi se prvo oni uklonili pre nego to se obrie i sam naslov. Kada bi se obrisao naslov pre primeraka i rezervacija tada se primercima i rezervacijama ne bi vie moglo pristupiti i oni bi za navek ostali u podsistemu i time vremenom zauzimali sve vei i vei memorijski prostor. Primeuje se da brisanju naslova ne prethodi na isti nain i brisanje zaduenja, iz ega se moe zakljuiti da se naslov ne moe rashodovati ukoliko je kod nekog lana na zaduenju. Na sledeoj slici prikazan je dijagram saradnje interfejsa brisanja naslova.

alempije@beotel.rs

91

1: DugmePronadji_Clicked ( ) 3: DaDugme_Clicked ( ) : DijalogPretrageNaslova

2: PoINVBR : NASLOV

: Bibliotekar

6: pribaviBrojPrimeraka 7: PribaviPrimerak(int) 10: pribaviBrojRezervacija 4: FormaPrepravkeNaslova (ObjId, boolean) 11: pribaviRezervaciju(int) 5: DugmeIzbrisi_Clicked ( ) 15: obrisi

12: PribaviClana 14: izbrisi : Primerak 8: jePozajmljen 9: izbrisi : FormaPrepravkeNaslova

: REZERVACIJA

13: obrisiRezervaciju : CLAN

Slika 6.29. Dijagram saradnje interfejsa brisanja naslova

Dijagram saradnje interfejsa rezervisanja

Za uspostavljanje valjane rezervacije nekog naslova potrebni su validni podaci lana i naslova koj se zdruuju u rezervaciji. Zato se u dijagramu saradnjepojavljuju primerci klasa koje predstavljaju dijaloge za pretragu naslova i lana biblioteke. Pretrage se vre u naelu po inventarno, odnosno matinom broju, ali ne i obavezno. Veliku ulogu u obrazovanju i poveanju uslunosti informacionog sistema trebalo bi da odigra formiranje strunog kataloga po UDK klasifikaciji. lan bi onda na osnovu svog interesovanja mnogo bolje koristio fond biblioteke . Nakon to se obave konkurentni tokovi ka pretrazi naslova i lana, dobijemi podaci se zdruuju u jednoj formi rezervacije, odakle se alju poruke ka tri strane. To se podaci o pohranjenoj rezervaciji smetaju u objekte klasa lan, naslov i rezervacija. Moe se primetiti da u saradnji pri rezervisanju ne uestvuje klasa primerka, a razlog tome je, kao to je ve pomenuto, to se ne rezervie konkretan primerak ve naslov bez obzira na pojavu. Na sledeoj slici prikazan je dijagram saradnje interfejsa rezervisanja.

92

alempije@beotel.rs

3: DugmePronadji_Clicked ( ) 5: DaDugme_Clicked ( ) : DijalogPretrageNaslova : Bibliotekar : NASLOV 4: PoINVBR

2: DijalogPretrageNaslova (Frame, boolean) 6: dostaviNaslov (ObjId) 15: dodajRezervaciju 16: azuriraj : FormaRezervisanja 1: DugmePronadjiNaslov_Clicked ( ) 7: DugmePronadjiClana_Clicked ( ) 12: DaDugme_Clicked ( ) 11: dostaviClana (ObjId)

9: PronadjiDugme_Clicked ( )

13: Rezervacija 14: pohrani

8: DijalogpretrageClana (Frame, boolean) 17: dodajRezervaciju 10: PoJMBG : DijalogPretrageClana : CLAN 18: azuriraj : REZERVACIJA

Slika 6.30. Dijagram saradnje interfejsa rezervisanja

Dijagram saradnje interfejsa brisanja rezervacije

Poto je na sledeoj predstavljen dijagram saradnje za rezervisanje naslova, prirodno je da se predvidi i mogunost sistema da obrie jednom postavljenu rezervaciju. Rezervacija se uklanja tako to se briu podaci o njoj iz objekata klasa naslov, lan i rezervacija. Prvo se preko dijaloga za pretragu naslova pronae naslov za koji se eli obrisati rezervacija i time se dobija lista lanova koji su rezervisali taj naslov. Sa ponuene liste bira se eljeni lan te se pribavlja njegov matini broj. Tako se dolazi do objekata iz koji se treba izbrisati podatak o postavljenoj rezervaciji. Jedino se odgovarajui objekat klase rezervacija brie u potpunosti, tanije poziva se njegov destruktor.

alempije@beotel.rs

93

1: DugmePronadjiNaslov_Clicked ( ) 11: ListaClanova_Selected ( ) 12: DaDugme_Clicked ( ) : FormaBrisanjaRezervacije

2: DijalogPretrageNaslova (Frame, boolean) 9: pribaviClana 15: pribaviNaslov 21: izbrisi : REZERVACIJA

6: dostaviNaslov (ObjId) : Bibliotekar

3: DugmePronadji_Clicked ( ) 5: DaDugme_Clicked ( )

7: pribaviBrojRezervacija 8: pribaviRezervaciju(int) 16: pribaviNaslov 19: ukloniRezervaciju 20: azuriraj 10: pribaviJMBG 13: PoJMBG 14: pribaviRezervaciju(int) 17: obrisiRezervaciju 18: azuriraj

: DijalogPretrageNaslova

4: PoJMBG : NASLOV : CLAN

Slika 6.31. Dijagram saradnje interfejsa brisanja rezervacije

Dijagram saradnje interfejsa zaduivanja

U ovom dijagramu saradnje figuriraju objekti poslovnih klasa naslova, primerka, lana i zaduenja, ali i interfejsnih klasa koje predstavljaju forme aplikacije zaduene za pretraivanje naslova, lana i formiranje zaduenja. U poetku se alje poruka objektu klase forme zaduivanja da pronae naslov, na ta se otvara forma za pretragu naslova. Sada se odvija sekvenca poruka koja je ve viena u ranijim dijagramima saradnje kada su se pretraivali naslovi. Za dobijeni naslov pribavlja se broj primeraka naslova i odluuje se za neki konkretni, jer se zaduuje konkretan primerak naslova. Potom se objektu klase forme zaduivanja alje poruka za pretragu lana koji e zaduiti primerak naslova. Na prijem te poruke otvara se dijalog pretrage lana odakle se pretrauje eljeni lan po matinom broju. Kada su pribavljeni svi podaci potrebni za zaduenje naslova, poziva se konstruktor klase zaduenje i tako kreirani objekat se pohranjuje u informacioni podsistem. Sada je zaduenje formirano i ostalo je samo obezbediti inverzni proces, operaciju razduivanja zaduenog naslova. Sledi dijagram saradnje interfejsa za razduivanje zaduenog naslova. Na sledeoj slici prikazan je dijagram saradnje interfejs zaduivanja.

94

alempije@beotel.rs

13: PronadjiDugme_Clicked ( ) 15: DaDugme_Clicked ( ) : DijalogPretrageClana

: Bibliotekar

: ZADUZENJE 14: PoJMBG

1: DugmePronadjiNaslov_Clicked ( ) 11: PronadjiPodatkeClana_Clicked ( ) 17: ListaPrimeraka_ListSelect ( ) 18: DaDugme_Clicked ( ) 3: DugmePronadji_Clicked ( ) 5: DaDugme_Clicked ( ) 20: Zaduzenje 21: pohrani( )

12: DijalogpretrageClana (Frame, boolean) 16: dostaviClana (ObjId) : CLAN 24: dodajZaduzenje 25: azuriraj

6: dostaviNaslov (ObjId) : DijalogPretrageNaslova : FormaZaduzivanja 2: DijalogPretrageNaslova (Frame, boolean)

10: pribaviINVBR 22: zaduzi 23: azuriraj : Primerak

4: PoINVBR

7: pribaviBrojPrimeraka 9: pribaviObjekat 8: pribaviPrimerak(int) 19: pribaviPrimerakSaInvbr

: NASLOV

Slika 6.32. Dijagram saradnje interfejs zaduivanja

Dijagram saradnje interfejsa razduivanja

Razduivanjese izvodi slanjem poruka za traenje naslova na koju se otvara dijalog pretrage naslova. Mora se nai naslov koji se eli razduiti. Naslov se pretrauje po inventarnom broju. Od naslova se uzima broj primeraka, i od ponuenih primerak bira se primerak koji se eli razduiti. Sa tog primerka uzima se podatak o zaduenju u kome se nalazi i informacija o lanu koji dui dati primerak. Sada postoje svi neophodni podaci za brisanje zaduenja. Podaci o zaduenju se briu i auriraju za objekte klasa lan i primerak, dok se za objekat klase zaduenja poziva destruktor. Na sledeoj slici prikazan je dijagram saradnje interfejsa razduivanja.

alempije@beotel.rs

95

3: DugmePronadji_Clicked ( ) 5: DaDugme_Clicked ( ) : Bibliotekar

: DijalogPretrageNaslova

2: DijalogPretrageNaslova (Frame, boolean) 1: DugmePronadjiNaslov_Clicked ( ) 7: ListaPrimeraka_Selected ( ) 12: DaDugme_Clicked ( ) 8: proveriStanje ( ) 6: dostaviNaslov (ObjId) 4: PoINVBR

9: pribaviPrimerakSaINVBR 13: pribaviPrimerakSaINVBR : FormaRazduzivanja 10: pribaviZaduzenje 14: pribaviZaduzenje 16: pohrani 17: azuriraj 18: obrisiZaduzenje 19: azuriraj : CLAN : Primerak : NASLOV

11: pribaviClana 15: pribaviClana 20: izbrisi : ZADUZENJE

Slika 6.33. Dijagram saradnje interfejsa razduivanja

Izrada potpunih dijagrama klasa za poslove cirkulacije

Potpuni dijagram klasa ili kako se krae kae dijagram klasa se tako zove da bi se odvojio od konceptualnog modela koji se prikazuje kao dijagram klasa bez operacija ili sa onim najosnovnijim. Dijagram klase se sastoji iz klasa i veza izmeu njih. Naziva se jo i dijagram statike strukture. Klasa predstavlja sloeni tip, kolekciju, struturu koja se sastoji od vie atributa (podata lanova) i operacija (metoda, funkcija lanica). Na sledeoj slici prikazan je potpuni dijagram klasa koji e bitiu daljem tekstu detaljno opisan.

96

alempije@beotel.rs

Slika 6.34. Potpuni dijagram klasa poslova cirkulacije

alempije@beotel.rs

97

Dijagram klasa koji je dat na predhodnoj slici opisuje logiku aplikacije i deo paketa istog imena koji predstavlja pogon sistema u njegovoj troslojnoj arhitekturi, o emu e neto kasnije biti govora. Odmah valja rei da sve klase imaju dve iste funkcije lanice (metode), a to su Class_Initialize i Class_Terminate. Radi se o takozvanim konstruktorima i destruktorima klase koji se pozivaju uvek kada se kreira, odnosno unitava objekat date klase. Na dijagramu klasa uoavaju se dve klase od kljunog znaaja za problem koji se pokuava reiti. To su klase NASLOV i CLAN. Klasa NASLOV ima oekivane atribute (naslov, podnaslov, inventarni broj, imena autora, signatura, format, godina itd.) u odgovarajuim tipovima podataka. Neki atributi koji e se kasnije pojaviti u modelu entiteta i veza nedostaju a to je stoga to se ovde ne radi o tabelama i prenoenju stranih kljueva, ve o softverskim klasama kod kojih se to reava mogunou referenciranja. Klasa NASLOV takoe ima odgovarajue metode pored ve pomenutih konstruktora i destruktora. Nazivi tih funkcija jasno govore o njihovoj nameni. Vano je istai da klasa NASLOV referencira klasu Primerak, iz raloga to je est sluaj da jedan naslov ima vie primeraka (s obzirom da vei deo fonda biblioteke ine udbenici). to se tie klase CLAN stvar je malo drugaija, jer se radi o klasi roditelja koja slui prvenstveno za izvoenje (generalizaciju) specifinih klasa koje predstavljaju razliite tipove lana koji mogu da postoje u poslovima cirkulacije. Zato klasa CLAN ima samo one atribute koji su zajedniki za sve vrste lanova (ime, prezime, telefon i JMBG). Ti atributi su svi protected nivoa zatite kako bi mogli da im pristupe samo klase koje nasleuju klasu lana (STUDENT, ZAPOSLEN, VANREDNI). Poslovi cirkulacije odvijaju se izmeu objekata ove dve klase i zato od njih polaze gotovo sve veze u dijagramu klasa. Razmotriemo prirodu i smisao tih veza u ovakvom dijagramu. Jedna vrsta tih veze koje se pomalo i ponavljaju je veza asocijacije ka neemu to bi se u modelu objekti i veze moglo nazvati ifarnikom. Za ilustraciju emo uzeti vezu asocijacije klase NASLOV sa klasom UDKOBLAST. Ta veza zamenjuje atribut koji bi da je nema morao postojati u klasi NASLOV. Ovako veza asocijacije to reava elegantije. Znaenje veze asocijacije izmeu bilo koje dve klase pa i ove je da objekti te dve klase mogu da referenciraju jedan drugi tj. to znai da objekat koji je u asocijaciji sa objektom druge klase ima informaciju o objektu te druge klase koju referencira. Drugim reima, naslov ima svest i zna udk broj i naziv udk oblasti kojoj pripada. Isto tako jedna udk oblast zna sve naslove koji je referenciraju i njihove atribute (to je potrebno da bi se mogli pretraivati naslovi po udk oblasti). Takoe, ova veza ima i kardinalnost koja govori da jedan naslov moe i mora da referencira samo jednu udk oblast, dok udk oblast moe da postoji bez da je referencira bilo koji naslov. U praksi to znai da e se popunjavati ifarnik udk oblasti, te da e takve oblasti moi imati u sebi svrstan nijedan ili vie naslova, dok e naslov morati da ima jedan i samo jedan udk broj koji ga svrstava u strunom katalogu. Odnos koji je opisan gotovo bez izuzetka se ponavlja kod svih klasa koje su svrstane u kategoriju ifarnika (IZDAVAC, JEZIK, SS, RADNO MESTO i USTANOVA)

98

alempije@beotel.rs

Druga kategorija klasa uslovno je nazvana grupom asocijativnih klasa. To su klase koje predstavljaju vezu klasa NASLOV i CLAN i dinamiku tog odnosa (REZERVACIJA, OPOMENA, ZADUZENJE I RAZDUZENJE). Ove klase su povezane i sa klasom NASLOV i sa klasom CLAN vezom asocijacije slinom onoj koja je opisana u prethodnom paragrafu. Od navedene etiri "asocijativne" klase jedino klasa REZERVACIJA direktno referencira klasu NASLOV, dok ostale tri to ine preko tranzizentne klase Primerak. To je i logino jer se objekti klasa zaduenja, razduenja i opomene kreiraju za konkretni primerak naslova, a samo se rezervacija vri za naslov bez obzira na primerak. I navigabilnost tih veza je dvosmerna jer konkretan objekat zaduenja referencira objekat klase lana i ima sve informacije o njemu. Tako primerak klase lana referencira nijedno, jedno ili vie zaduenja i ima sve informacije o tim zaduenjima. Slina je i situacija u vezi ovih klasa prema klasi Primerak. Kardinalnosti govori o moguim stanjima dinamikog odnosa naslova i lana. Primerak moe imati nijedno ili jedno zaduenje (naslov moe imati vie primeraka), nijednu, jednu ili vie rezervacija i opomena; dok jedno zaduenje, rezervacija, i opomena moe ukazivati na jedan i samo jedan naslov. Istovetno za jednog lana moe postojati nijedno,jedno ili vie zaduenja, rezervacija i opomena; dok za jedno zaduenje, rezervaciju i opomenu moe biti vezan samo jedan lan. Pored ve navedenih tipova veza uoava se jedna koja je specifina i javlja se izmeu klasa STUDENT i GODINA, ali i GODINA i SMER. To su takozvane veze agregacije koje reprezentuju odnos celina - deo. Radi se o dve podvrste veze agregacije : po vrednosti (kompozicija izmeu klasa studenta i klase studentske klase) i po referenci (veza izmeu studentske klase i slube). Smisao ovih veza je sledei. Znaenje agregacije po vrednosti: Primerak klase GODINA je vlasnik jednog ili vie primeraka klase STUDENT i ivotni vek primerka klase STUDENT prestaje prestankom postojanja primerka klase GODINA iji je deo. Znaenje agregacije po referenci je neto drugaije. Jedan objekat klase GODINA moe biti deo vie primeraka klase SMER. Logiku veza agregacije koje su opisane slikovito dopunjuju i kardinalnosti koje su date.

Izrada dijagrama interfejs klasa

Pored dijagrama klasa kojima se opisuje logika rada aplikacije mogue je sistem jo detaljnije modelovati izradom interfejsnih dijagrama klasa. To su dijagrami koji snimaju statiku strukturu izgleda korisnikog interfejsa aplikacije koja se projektuje. Dinamika klasa koje ine ove interfejs dijagrame specificirana je ranije odgovarajuim kolaboracionim i sekvencijalnim dijagramima. Paket koji sadri ove klase i dijagrame za razliku od prethodno opisanog dijagrama pripada gornjem sloju troslojne arhitekture softvera sistema- korisniki servis (User Services). Ovde klase predstavljaju prozore (maske) aplikacije a veze izmeu njih mogunost prelaza iz jedne maske u drugu. Ti dogaaji nastupaju pritiskom na odreene kontrole koje se nalaze na formama. Kompletni scenariji tih deavanja dati su prethodno pomenutim interakcionom dijagramima za pojedine osnovne funkcije podsistema koje se obavljaju preko rada sa formama korisnikog interfejsa. Slede dijagrami interfejs klasa aplikacije cirkulacije poslovanja biblioteke na uslovno podeljeni u tri grupe:

alempije@beotel.rs

99

 osnovne funkcije poslovanja(zaduivanje, rezervisanje...), manipulisanje podacima( razne pretrage ) i auriranje podataka.

Interfejs za osnovne funkcije poslova cirkulacije u biblioteci

Postoji jedna glavna forma iz koje se moe, pritiskom na odreene kontrole ulaziti u etiri forme gde se obavljaju etiri (u svakoj po jedna) osnovne funkcije koje treba da obavlja aplikacija bibliotekog poslovanja: zaduivanje, razduivanje, rezervisanje i brisanje rezervacije. Prelazak iz glavne u ove ostale forme izvravaju funkcije lanice klase glavnog obrasca. Izuzimajui metodu koja je konstruktor ostale funkcije praktino otvaraju neku od maski aplikacije. One funkcije koje ne otvaraju neku od formi ije se klase nalaze na gornjem klasnom dijagramu, igrae tu ulogu u nekom od sledeih dijagrama. Tako, metoda klase glavne forme Zaduzi_Action() otvara obrazac gde se vri zaduivanje naslova, a koji je na dijagramu predstavljen klasom FormaZaduivanja. Ova klasa pored konstruktora ima svoje metode kojima se obavlja zaduivanje naslova, tanije konkretnog njegovog primerka. Klasa takoe sadri za razliku od klase glavne forme dva podatka lana tipa lan i naslov. Ovi podaci lanovi moraju biti prisutni jer funkcija zaduivanja vezuje podatke lana biblioteke i naslova iz bibliotekog fonda. Na sledeoj slici prikazan je dijagram klasa interfejsa osnovnih funkcija podsistema.

Slika 6.35. Dijagram klasa interfejsa osnovnih funkcija podsistema

Interfejs za manipulisanje podacima

Polazna klasa i na ovom kao i na prethodnom dijagramu je klasa glavne forme. Iz nje se korisnik 100
alempije@beotel.rs

podsistema moe odluiti da pregleda naslove, lanove ili naloge za rad sa aplikacijom (ukoliko ima ovlaenje za takav rad). Bilo za koju od mogunosti da se korisnik odlui njoj e korespondirati neka maska. Uzmimo recimo u razmatranje prozor pretrage lana. Klasa koja odgovara tom prozoru ima jedan podatak lan tipa lana, koji sadri podatke o lanu biblioteke koji je trenutan. Pritisak na dugme pronai, koje se nalazi na toj formi, otvara se sledei obrazac koji je na dijagramu predstavljen klasom dijaloga pretrage lana. Pored ve pomenutog podatka lana tipa lan ova klasa ima jo jedan podatak lan istog tipa koji predstavlja rezultata pretrage. Istovremeno klasa realizuje interfejs rezultata pretrage koji dostavlja lana po zadatoj kategoriji. Istovetno je reeno i odvijanje prelaza iz maske u masku u sluaju kada se korisnik aplikacije odluuje za pretragu Naslova. U ovu grupu obrazaca spada i obrazac pregleda korisnikih naloga aplikacije sa svojom odgovarajuom klasom i pripadajuim metodima. U toj formi mogue je pregledanje, dopuna i prepravka postojeih naloga. Na sledeoj slici prikazan je dijagram klasa interfejsa pretrage naslova i lanova.

alempije@beotel.rs

101

GlavnaForma slikaj() Zaduzi_Action() Razduzi_Action() Rezervisi_Action() Obrisi rezervaciju_Action() Naslov_Action() Clan_Action() PregledajNaloge_Action() UnesiNaslov_Action() PrepraviPrimerakNaslova_Action() UpisiClana_Action() PrepraviClana_Action() About_Action() Izadji_Action() dostaviNaslov() dostaviClana() GlavnaForma()

DijalogPretrageNaslova rezultat : NASLOV trenutni : NASLOV DugmePronadji_Clicked() DaDugme_Clicked() NeDugme_Clicked() DijalogPretrageNaslova() ProzorPodatakaNaslova DugmePronadji_Clicked() DaDugme_Clicked() dostaviNaslov() ProzorPodatakaNaslova()

ProzorPodatakaClana <<Interface>> RezultatPretrageNaslova dostaviNaslov() trenutni : CLAN DugmePronadji_Clicked() DaDugme_Clicked() dostaviClana() ProzorPodatakaClana()

ProzorPregledaNaloga DugmePromenaNaloga_Clicked() DugmeZatvori_Clicked() popuni() ProzorPregledaNaloga()

DijalogPretrageClana <<Interface>> RezultatPretrageClana dostaviClana() rezultat : CLAN trenutni : CLAN PronadjiDugme_Clicked() DaDugme_Clicked() NeDugme_Clicked() DijalogpretrageClana()

Slika 6.36. Dijagram klasa interfejsa pretrage naslova i lanova.

102

alempije@beotel.rs

Interfejsa odravanja aurnosti podataka

I ovde sve poinje od jedne glavne forme, ali je svrha postojanja svih ostalih klasa koje predstavljaju obrasce aplikacije razliita od prethodnih i sastoji se od odravanja tanosti podataka u sistemu. U tu svrhu omoguene su maske (a u modelu i odgovarajue klase koje ih predstavljaju) za unos podataka novih lanova i novih naslova. Meutim, aurnosti radi ponekad nije dovoljno samo unositi nove lanove i naslove, ve i intervenisati na postojeim kada se za to ukae potreba. Zato postoje forme prvo za pretragu lana, odnosno naslova pa onda i za prepravku lanova, odnosno naslova. Sve odgovornosti obrazaca omoguene su funkcijama lanicama klasa koje predstavljaju te obrasce. Na sledeoj slici prikazan je dijagram klasa interfejsa odravanja aurnosti podataka. Na kraju odeljka posveenog izradi dijagrama klasa interfejsa valja neto rei o vezama izmeu klasa koje predstavljaju maske aplikacije. Radi se o vezama asocijacije, ali bez navigabilnosti. To znai, a u praksi tako i jeste, da maske koje su povezane tim vezama referenciraju jedna drugu, ili da mogu jedna drugu otvarati. Drugim reima u toku rada sa aplikacijom prelaz iz jedne u drugu formu je izvodljiv. Nain na koji to klase izvode pozivajui svoje funkcije lanice, dinamiki je opisan u poglavljima posveenim kolaboracionim i sekvencijalnim dijagramima.

alempije@beotel.rs

103

GlavnaForma slikaj() Zaduzi_Action() Razduzi_Action() Rezervisi_Action() Obrisi rezervaciju_Action() Naslov_Action() Clan_Action() PregledajNaloge_Action() UnesiNaslov_Action() PrepraviPrimerakNaslova_Action() UpisiClana_Action() PrepraviClana_Action() About_Action() Izadji_Action() dostaviNaslov() dostaviClana() GlavnaForma() FormaNovogClana DugmeDodaj_Clicked() NeDugme_Clicked() FormaNovogclana()

FormaNovogNaslova trenutni : NASLOV DugmeDodaj() NeDugme_Clicked() FormaNovogNaslova()

DijalogPretrageClana rezultat : CLAN trenutni : CLAN PronadjiDugme_Clicked() DaDugme_Clicked() NeDugme_Clicked() DijalogpretrageClana()

DijalogPretrageNaslova rezultat : NASLOV trenutni : NASLOV DugmePronadji_Clicked() DaDugme_Clicked() NeDugme_Clicked() DijalogPretrageNaslova()

FormaPrepravkeNaslova naslov : NASLOV DugmrPrepravi_Clicked() DugmeIzbrisi_Clicked() DugmeDodajPrimerak_Clicked() DugmeObrisiPrimerak_Clicked() NeDugme_Clicked() OsveziFormu() FormaPrepravkeNaslova()

FormaPrepravkeClana clan : CLAN DugmePrepravi_Clicked() DugmeIzbrisi_Clicked() NeDugme_Clicked() OsveziFormu() FormaPrepravkeClana()

Slika 6.37. Dijagram klasa interfejsa odravanja aurnosti podataka

104

alempije@beotel.rs

Izrada dijagrama stanja za poslove cirkulacije u biblioteci

Dijagramom stanja se opisuju dinamike karakteristike sistema. Dijagram stanja se pridruuje svakoj klasi ije je ponaanje znaajno u opisu dinamike sistema. Njime se opisuje ponaanje instanci date klase, prikazuje prostor stanja (skup svih moguih stanja) instanci klase i dogaaje koji iniciraju prelaz objekta iz jednog stanja u drugo kao i akcije koje se izvravaju kao posledica promene stanja. Do promene stanja jednog objekta u sistemu dolazi kao odgovor na poruku koju alje drugi objekat u sistemu. Dijagram stanja moe opisivati dinamiki model klase, paketa ili itavog sistema. Ovde e se opisati prostor stanja objekata klasa karakteristinh za reenje koje je ponueno. Pri opisu dijagrama klasa ve su izdvojene neke karakteristine grupe klasa pa e se ta uslovno uzeta kategorizacija i ovde koristiti. Za svaku od kategorija dae se i opisati dijagram stanja po jedne klase koja je u tu grupu svrstana. Radi se o prostorima stanja objekata klasa SS (struna sprema), lana, zaduenja i naslova.

Dijagram stanja objekta klase SS

Jedan dijagram stanja, kao to je ovaj predstavlja prostor svih moguih stanja u kojima moe da se nae jedan objekat posmatrane klase u toku svog ivotnog veka, od pozivanja konstruktora do pozivanja destruktora. Dakle, nakon poetnog stanja sledee stanje u kom se moe nai objekat klase SS je stanje kreiran. Odatle su mogui prelazi u dva stanja. Objekat moe odmah biti izbrisan (to e se desiti kod pogrenog unosa) ili moe biti prihvaen i korien, to e rei izlistan. Objekat klase SS se u aplikaciji moe koristiti za dodelu strucne spreme lanu ili za pretraivanje lana po strunoj spremi. U svim tim sluajevima objekti klase SS se daju korisniku na uvid u vidu listinga. Zato je sledee stanje objekta izlistan. Razumljivo to mu se stanje u toku njegovog ivotnog veka moe ponoviti neogranien broj puta, i to je razlog rekurzivnog prelaza stanja izlistan. U nekom od tih stanja izlistan objekat klase SS moe biti izabran i to je novo sledee mogue stanje. Kada je objekat izabran on se dodeljuje nekom objektu klase CLAN ili se uzima kao vrednost za pretragu. Tako je mogu i prelaz u stanje dodeljen. Meutim, iz stanja izabran mogu je i prelaz u stanje izbrisan, jer je to ono to se zapravo i deava u formi odravanja ifarnika. Praktino s vremena na vreme se u sklopu odravanja aurnosti ifarnika briu inovi koji vie ne vae ili unose novi. Tu bi i bio kraj ivotnog ciklusa objekta klase SS. Na sledeoj slici prikazan je dijagram stanja objekta klase SS.

alempije@beotel.rs

105

Izlistaj

Dodeljen Dodeli [ izabran ]

Kreiran

Izlistaj[ postoji ]

Izlistan

Izaberi [ izlistan ]

Izabran

Obrisan

Slika 6.38. Dijagram stanja objekta klase SS

Dijagram stanja objekta klase CLAN

Na dijagramu stanja prikazanom na sledeoj slici su data sva mogua stanja u kojima se moe nai objekat klase CLAN u toku svog ivotnog veka, od upisa do ispisa iz biblioteke. Ako objekat postoji (ako je CLAN ve upisan) mogua su dva stanja, ili e se pozvati destruktor i CLAN e biti ispisan, ili e CLAN ui u cirkulaciju, gde moe da obavlja sve funkcije kao to je zaduivanje, razduivanje i rezervisanje naslova iz biblioteke. Ako pak objekat ne postoji (osoba nije upisana) on prelazi u stanje upisan i onda je mogu prelaz u ve pomenuto stanje cirkulacije. U okviru cirkulacije to se tie objekta klase CLAN ne postoje nikakva ogranienja u pogledu razduivanja i rezervisanja. Ogranienje postoji jedino za zaduivanje. Naime, na izlazu iz cirkulacije u zavisnosti da li je naslov koji objekat klase CLAN dui vraen ili ne, mogua su dva prelaza. Ako naslov nije vraen objekat klase CLAN prelazi u stanje opomenut i zadrava se u tom stanju sve dok ne vrati naslov. To je razlog rekurzivnog prelaza u stanje opomenut. Kada clan vrati naslov opet mu je mogu prelaz u cirkulaciju. Iz cirkulacije (glavnog stanja poslovanja za objekte i klase CLAN i klase NASLOV) postoji jedan tok koji se odnosi na proveravanje statusa lana. Moe se desiti da je lan u toku cirkulacije izgubio status, pa su u zavisnosti od situacije mogui prelazi ili u opet u cirkulaciju ili u stanje ispisan. Na sledeoj slici prikazan je dijagram stanja objekta klase CLAN.

106

alempije@beotel.rs

[ os oba je vec upis ana ]

[ nas lov je vracen ]

Cirkulac ija [ os oba je za upis ] Zaduzivanje

[ nas lov nije vrac en ]

Upis an

Razduz ivanje [ nas lov nije vrac en ]

Opomenut

[ os oba je za is pis ] [ os oba nije za is pis ]

Rezervis anje

[ nas lov je vrac en ] proveri s tatus is pisi[ os oba je za is pis ] Is pis an

Slika 6.39. Dijagram stanja objekta klase CLAN Sada e biti dat dijagram stanja objekta klase zaduenja koja je u prethodnom izlaganju bila uslovno reeno svrstana u red "asocijativnih" klasa.

Dijagram stanja objekta klase ZADUZENJE

Prostor stanja objekta klase zaduenja nije velik. To je zato to se objekat klase zaduenja moe nai u svega tri stanja : formirano, pretraeno i raskinuto. Objekat se na poetku formira i ulazi u stanje formirano. Iz tog stanja mogu mu je prelaz odmah u stanje raskinuto u sluaju kada se do razduivanja ne prelistava ba to zaduenje, ili kada se napravi greka u zaduenju. Sa druge strane mogu je prelaz u stanje pretraeno, jer se kada se jednom zaduenje formira ono u toku svog ivotnog veka moe indirektno pretraiti bilo pri pregledu stanja naslova ili pri pregledu zaduenja nekog od lanova. I ovde je ostvarena rekurzivna veza ka stanju pretraeno jer se to stanje u toku ivotnog veka objekta klase zaduenja moe vie puta ponoviti. Iz stanja pretraeno moe se prei u stanje raskinuto, to se u praksi i deava, jer pre svakog ina razduenja mora prethoditi pretraivanje tog zaduenja. Na sledeoj slici prikazan je dijagram stanja objekta klase ZADUZENJA.

alempije@beotel.rs

107

pretrazi formiraj

Formirano

Pretrazeno

Raskinuto

Slika 6.40. Dijagram stanja objekta klase ZADUZENJA

Dijagram stanja objekta klase NASLOV

Razumljivo je da je prostor stanja objekta klase NASLOV vei nego to je to bio sluaj na prethodnom dijagramu. Radi se o klasi iji su objekti u sreditu rada podsistema, pa su samim tim mogui scenariji brojniji. Objekat klase NASLOV moe ve postojati ili ne postojati. Ako postoji moe mu se desiti ulazak u cirkulaciju ( gde se deavaju ve poznate operacije ) ili u stanje rashodovan ( to predstavlja kraj ivotnog ciklusa objekta). Iz stanja zaveden prelazi se u stanje u obradi gde se vri bibliografsko kataloka obrada naslova (dodeljuje mu se udk broj, pravi se kataloki listi...). Ovo pokazuje da nov naslov nikako ne moe ui u cirkulaciju dok se ne izvri bibliografsko-kataloka obrada. U cirkulaciji naslov mora prvo biti zaduen da bi odatle mogao prei u stanje rezervisan ili razduen. Naravno naslov koji je zaduen moe se rezervisati. Na izlasku iz stanja rezervisan i razduen prelaz se grana u dva pravca. Pod uslovom da je izvrena rezervacija, nju je mogue opet ponavljati, ali ne i prelaz u stanje zaduen. Prelaz u stanje zaduen mogue je samo na izlazu iz stanja razduen. Na izlasku iz cirkulacije postoji provera statusa naslova. Ako naslov postoji on se vraa u cirkulaciju, u suprotnom vri se prelaz u stanje rashodovano, pozivom destruktora klase naslov. Dijagrami stanja objekata ostalih klasa slini su ili istovetni opisanim dijagramima stanja objekata klasa sa kojima se nalaze uslovno svrstani u srodnim grupama klasa. Na sledeoj slici prikazan je dijagram stanja objekta klase NASLOV.

108

alempije@beotel.rs

[ zaveden ]

U cirkulaciji Zavedi[ [stigao] ] Zaveden Zaduzen rashoduj[ izgubljen ] obradi U obradi Rezervisan rashoduj[ izgubljen ] Razduzen

Rashodovan

provera statusa [ nije razduzen ]

vrati u cirkulaciju[ postoji ]

[ razduzen je ]

Slika 6.41. Dijagram stanja objekta klase NASLOV

Definisanje paketa za poslove cirkulacije u biblioteci

Mnotvo klasa i drugih stvari UML notacije redovna je pojava projekata velikih sistema, te je poeljno grupisati ih u neke logike i funkcionalne celine. UML stvari koji predstavljaju te celine nazivaju se paketi. Paketi okupljaju semantiki bliske i elemente koji se zajedniki menjaju. Ponekad paket moe predstavljati i pogled na sistemsku arhitekturu ( primera radi u alatu RationalRose postoje etiri predefinisana paketa koji predstavljaju poglede na sistem: Use Case View, Logical View, Component View i Deployment View. Naravno pored njih mogu postojati i neki korisniki paketi. Izmeu paketa kao i izmeu klasa mogu se povui sve vrste veza (agregacija, asocijazija i zavisnost). Meutim, i pored te slinosti postoji jedna velika razlika izmeu klasa i paketa. Klasa ima svoj primerak, instancu, pojavu dok paket to nema. On je jedan apstraktan koncept koji pre svega slui za grupisanje elemenata modela kojima je zajednika neka od moguih veza prema drugoj grupi elemenata. S obzirom da paket predstavlja i oblast definisanosti elementa u paketu mogue je definisati i vidljivosti elemenat (klasa) unutar paketa (standardna su tri nivoa :public, protected i private).
alempije@beotel.rs

109

Na sledeoj slici bie dati paketi klasa sistema s obzirom na troslojnu arhitekturu aplikacije. O troslojnoj arhitekturi aplikativnog softvera koji se projektuje vie e rei biti u poglavlju izbora tehnologije. Sada e se videti samo reprezentacija troslojne arhitekture putem paketa elemenata( klasa).

Us e r S e rv ic e s

Bu s in e s s S e rv ic e s

D a ta S e rv ic e s

Korisnicki interfejs

Logika aplikacije

Paket baze podataka

Usluzni paket

Slika 6.42. Paketi troslojne arhitekture Dakle razlikojemo dva nivoa arhitekture i etiri paketa. O nivoima kasnije. Paketi okupljaju elemente notacije srodne po funkciji i ponaanju. Paket korisnikog interfejsa sadri sve klase i itave dijagrame (o kojima je bilo rei u poglavlju razvoja dijagrama interfejsnih klasa) od znaaja za opis i definiciju grafike reprezentacije aplikacije -forme, dijalozi, kontrole itd... Paket baze podataka sadri klase odgovorne za postojano (persistent) uvanje, memorisanje i odravanje podaka u skladitu. Dva preostala paketa kao to je to slikovito prikazano imaju zadatak da povezuju dva ve pomenuta paketa u funkcionalnu celinu. To su paketi logike aplikacije i usluni paket. O sastavu paketa logike aplikacije bilo je ve rei u poglavlju o izradi potpunih dijagrama klasa, dok u uslunom paketu nalaze klase koje su zaduene za apstrakciju rezultata pretrage, izvetaja itd... Na sledeoj slici prikazan je sadrzaj uslunog paketa.

110

alempije@beotel.rs

Slika 6.43. Sadraj uslunog paketa

alempije@beotel.rs

111

Implementacija za poslove cirkulacije u biblioteci

Implementacija poslova cirkulacije definisana je kroz: Izradu aplikacije poslova cirkulacije u bibloteci o o o o o o Izrada baze podataka Izrada korisnickog interfejsa Mapiranje programiranje prevodjenje Definisanje tehnologije Definisanje aplikativne arhitekure (dijagram komponenti) Definisanje mrezne arhitekture (razvojni dijagram)

Definisanje tehnologije aplikativne i mrezne arhitekture za poslove cirkulacije

Izrada aplikacije za poslove cirkulacije u biblioteke

Da bi se smanjio rizik i poveala verovatnoa razvoja odgovarajue aplikacije, razvoj bi treba da bude u to veoj meri zasnovan na analizi i dizajnu pre nego to programiranje otpone. To ne znai da nema mesta za dizajn u toku programiranja; savremeni alati za razvoj omoguavaju brzo ispitivanje drugaijih pristupa. Poeljeno je da dijagrami uraeni u fazi dizajna budu poluautomatski izmenjeni kako bi odrazili promene u prethodnoj fazi programiranja. Ovo se radi sa CASE alatom koji ita izvorni kod (kao to je Java) i automatski generie, na primer, dijagrame klasa i kolaboracije. Dijagram klasa prikazuje ime klase, nadklase, prtotipove metoda, i proste atribute klasa. Ovo su neophodne stavke za stvaranje definicije klase u objektno-orjentisanom programskom jeziku. Izradu aplikacije poslova cirkulacije u bibloteci satoji se od: Izrade baze podataka Izrade korisnickog interfejsa Mapiranje programiranje prevodjenje Na sledeoj slici prikazan je fiziki model podataka definisan u Erwinu i i odgovarajui fiziki model

112

alempije@beotel.rs

podataka u RationalRous-u dobijen postupkom reverznog inzinjeringa iz skript fajla generisanog u Erwin-u.
RAZDUZEN invbr: Character(20) ClanID: Character(6) datumzad: Date datumrazd: Date IZDAVAC IizdavacID: Numeric izdavac: Character(20) SMER SmerID: Numeric Smer: Character(20)

G ODINA
GodinaID: Numeric SmerID: Numeric Godina: Character(20)

NASLO V
invbr: Character(20) IizdavacID: Numeric JezikID: Numeric udk: Character(20) naslov: Character(20) podnaslov: Character(20) autor1: Character(20) autor2: Character(20) autor3: Character(20) godina: Numeric brprimerak: Numeric signatura: Character(20) datumunosa: Date format: Numeric ilustracij: Character(18) brstrana: Numeric izdanje: Character(20)

Fizicki model podataka u ERwin-u

ZADUZENJ invbr: Character(20) ClanID: Character(6) datzaduzen: Date rok: Date REZERVAC invbr: Character(20) ClanID: Character(6) datum: Date

CLAN
ClanID: Character(6) jmbg: Numeric ime: Character(20) prezime: Character(20) telefon: Character(20)

STUDENT ClanID: Character(6) SsID: Numeric GodinaID: Numeric SmerID: Numeric

UDKOBLAS udk: Character(20) nazivoblas: Character(20)

SS SsID: Numeric Strucna_sp: Character(20)

JEZIK JezikID: Numeric jezik: Character(20)

OPOMENA invbr: Character(20) ClanID: Character(6) broj: Numeric datum: Date

DESKRIPT invbr: Character(20) deskriptor: Character(20)

USTANOVA UstanovaID: Numeric ustanova: Character(20)

VANREDNI ClanID: Character(6) UstanovaID: Numeric

ZAPOSLEN ClanID: Character(6) SsID: Numeric Radnomesto: Numeric

RADNO_ME Radnomesto: Numeric RadnoMesto: Character(20)

JEZ IK JezikID : INT jezik : VARC HAR(20) 1 <<Non-Identif y ing>>

IZDAVAC Iizdav acID : INT izdav ac : VARCH AR (20) 1 <<Non-Identif y ing>> 0..*

<<Identif y ing>> RAZDUZENJ E inv br : VARCHAR(20) C lanID : CHAR(6) dat um zad : DATETIME dat um razd : DATETI ME 0..* SMER Sm erID : INT Sm er : VARC HAR(20) <<Identif y ing>> 1 0..* GODINA GodinaI D : I NT Sm erID : I NT Godina : VAR CHAR(20) 1

<<Identif y ing>> 0..* 0. .* 1 <<Identif y ing>> NASLOV inv br : VARC HAR(20) Iizdav acID : INT Jezik ID : INT udk : VARCHAR(20) naslov : VAR CHAR(20) podnaslov : VARCH AR (20) autor1 : VARCH AR(20) autor2 : VARCH AR(20) autor3 : VARCH AR(20) godina : INT brprimerak a : IN T signat ura : VARCHAR(20) datumunosa : DATETIME f ormat : INT ilus tracija : CH AR(18) brstrana : IN T izdanje : VAR CHAR(20) 0..* ZADUZENJ E 1 <<Identif y ing>> 0. .* 1 1 <<Identif y ing>> 1 <<Identif y ing>> 0..* REZERVACIJA <<Identif y ing>> inv br : VARCHAR(20) ClanID : CHAR(6) dat um : D ATETIME <<Identif y ing>> 0..* <<Identif y ing>> 0. .1 0. .* inv br : VARCHAR(20) ClanID : CHAR(6) datzaduzenja : DATETI ME rok : DATETIME <<I dentif y ing>> 0..* 1 CLAN ClanI D : CHAR(6) jmbg : I NT ime : VARCH AR(20) prezim e : VARCH AR (20) telef on : VAR CHAR(20) 1 1 1 1 <<Non-Identif y ing>>

Model podataka u Rational Rous-u

1 <<Identif y ing>>

STUD ENT ClanID : CHAR(6) SsI D : IN T GodinaID : I NT SmerID : I NT <<Non-Ident if y ing>> 0. .*

1 <<Identif y ing>> 0..* 0. .1 0. .* SS SsID : INT Strucna_s prema : VARCHAR(20) 0..1 0.. * ZAPOSLEN ClanID : CHAR(6) SsID : INT RadnomestoID : INT 0. .* 1 <<Non-Identif y ing>> 1

<<Non-Ident if y ing>> DESKRIPTOR inv br : VARCHAR(20) deskriptor : VARCHAR(20) OPOMENA inv br : VARCHAR(20) ClanID : CHAR(6) broj : INT datum : D ATETIME 0..1 <<Non-Identif y ing>> VANREDNI USTANOVA Us tanov aI D : IN T ustanov a : VARC HAR(20) 1 0..* ClanID : CHAR(6) Us tanov aID : IN T 0. .1

UD KOBLASTI udk : VARCHAR(20) naziv oblas ti : VARCHAR (20)

<<Non-Ident if y ing>>

RADN O_MESTO Radnomes toID : INT RadnoMesto : VARC HAR(20)

Slika 6.44. Model podataka

Izrade korisnikog interfejsa za poslove cirkulacije u biblioteci

Ovde e se opisati izgledi konkretnih formi i funkcionalnosti pojedinih kontrola koje se na njima nalaze. Ve je reeno koje su to funkcije koje sistem treba da ostvari, a sada e se videti i koje su to maske i kontrole koje ih ostvaruju. Imajui u vidu da je korisniki pogled definisan u dijagramima sluajeva upotrebe, to se radi se o istoj strukturi funkcionalnosti. Ipak mogu se zapaziti izvesna razlika u odnosu na strukturu organizacije kontrola na formama aplikacije, koje predstavljaju inicijalizatore za ostvarivanje tih funkcija. Jedini razlog takvog rasporeda kontroli (komandnih dugmia) je omoguavanje rada koji bi bio to blii korisnicima.

alempije@beotel.rs

113

Svi koncepti do kojih se dolo kroz objektno orjentisan razvoj u potpunosti su ugraeni u reenja korisnikog interfejsa i logike aplikacije, bez obzira na raspored komandi na maskama. Pre nego to se daju stavke glavnog menija aplikacije, idui redom od poetka startovanja programa, prvo se nailazi na dijalog za autenfikaciju korisnika aplikacije. Radi se o tome da je u aplikaciju ugraen svojevrstan sistem zatite koji onemoguava rad sa aplikacijom korisniku koji za to nema ovlaenja. Svi zaposleni u biblioteci koj rade na sitemu imaju svoje korisniko ime i odgovarajuu lozinku. Postoje dve kategorije korisnikih naloga za rad na aplikaciji. Uslovno su nazvani administratorski i obini. Administratorski u odnosu na obian nalog ima mogunost backup-ovanja podataka i administriranje svih korisnikih naloga i ifarnika baze podataka. Ograniavanje ovih funkcija samo na odreenu kategoriju naloga bilo je neophodno kako bi se izbegle sve neeljene posledice samovoljnog unoenja podataka iz domena ifarnika. Pomenuto je i administriranje korisnikih naloga. Ono se obavalja u formama posebno namenjenim toj funkciji a za sada treba rei da je mogue dodavanje novih, brisanje i promena postojeih naloga (promena ifre). Mora se uneti korisniko ime i lozinka imajui u vidu velika i mala slova. Naime, nije isto da li je za lozinku ukucano "E" ili "e". Sledea forma u koju se ulazi ( ako je lozinka i korisnko ime ispravno)je forma glavnog menija aplikacije koja sadri sledee opcije:

Cirkulacija Zaduzivanje Razduzivanje Opomena Rezervacija Pretrazivanje Autor Naslov Izdavac Jezik Datum Signatura Deskriptor UDK Inventarski broj Korisnici Upis Ispis Pregeled

Knjige Evidencija Zavodjenje Rashodovanje Stanje Kataloski listic Nalepnice Izvestaji po Korisnicima po Knjigama Prinovljenih knjiga Godisnji Periodicni Materijalno MP20 VB-15

Opcije Novo nalog Izmene Promeni lozinku Izloguj se Sifarnici Smer Godina Strucna sprema Izdavac Radno mesto Ustanova Jezika UDK oblasti Dopune podataka O autoru Backup Export Import Kraj

Slika 6.45. Izgled menija Iz ove forme se ulazi u sve ostale forme aplikacije, putem komandi iz menija u vrhu prozora. Sada se vidi mala reorganizacija funkcija podsistema u odnosu na stablo aktivnosti koje je dato u poglavlju definisanja korisnikih zahteva, Tako postavljen meni je u funkciji efikasnijeg rada korisnika sa aplikacijom. Naime, korisno je imati sve operacije vezane za knjigu ili korisnika (iako

114

alempije@beotel.rs

je evidencija korisnika u dijagramima sluaja upotrebe bila svrstana u cirkulaciju) odvojene na jednom mestu, pogotovu to je takva organizacija menija bila prisutna i u prethodnom reenju. U daljem izlaganju bie date opcije stavki glavnog menija. Imena tih opcija dovoljno plastino opisuju njihovu funkcionalnost, za neke kod kojih ona nije oigledna dae se i tekstualni opis. Pritisak kursorom mia na ove opcije otvara odgovarajue forme na kojima se ostvaruje funkcionalnost podsistema. Stavka backup-a ima opcije export-a i import-a, koje otvaraju odgovarajue dijaloge za import i export podataka u podsistem. Posebno je interesantan sadraj stavke imena Opcije. Tu se administriraju korisnici aplikacije, otvaraju novi nalazi i promenjuju postojei. Zatim se mogu aurirati sadraj ifarnika koji se nalaze u podsistemu (slubi, ustanova, klasa, inova, izdavaa, jedinica). Takoe tu se mogu dopunjavati podaci o naslovima i lanovima biblioteke. Izvetavati se moe po korisnicima i po knjigama. Novina je izvetaj o knjigama koje su zavedene u biblioteci i to godinji i periodini (za zadati vremenski interval). U skladu sa postavljenim korisnikim zahtevima dodata je i stavka materijalno kojom se moe doi do dva dokumenta koji se vode za naslove iz bibliotekog fonda (materijalni list -MP 20 i karton bibliotekog materijala-VB15). Stavke glavnog menija, kao to su cirkulacija, korisnici, knjige i pretraivanje su opcije iz sadraja stavki u punoj funkciji i nesmetano se izvode. Recimo mogue je pretraiti naslov po deskriptoru, ali je i dodato pretraivanje po udk broju, kojim se mogu pronai svi naslovi iz odreene oblasti ljudskog stvaralatva i odreene tematike. Slede izgledi konkretnih formi koje se otvaraju izborom odgovarajuih opcija iz stavki menija, onim redom kako su date i u aplikaciji. Zbog obimnosti aplikacije priazae se samo elementi zaduivanja i forma knjige. Definisanje zaduivanja Pritiskom komande zaduivanja u stavci cirkulacija glavnog menija otvara se sledei dijalog izbora kriterijuma pretraivanja naslova biblioteke (prethodi samom pretraivanju i zaduivanju). Pretraivanje se moe izvoditi izborom opcije: Autor, Naslov, Izdavac, Jezik, Datum, Signatura, Deskriptor, UDK i Inventarski broj. Vano je rei da e se ova forma pojavljivati i pre nekih drugih formi vezanih za naslove, jer je potrebno pronai naslov za koji se radi izvetaj, pravi pregled, kataloki listi, nalepnica ili rezervacija. Ukupno ima devet kriterijuma i svi su operativni, a izbor se vri jednostavnim ekiranjem nekog od kriterijuma. Istovremeno je mogue izabrati samo jedan kriterijum pretrage. U konkretnom primeru uzeto je da je izabran kriterijum pretrage po jeziku. Sledi izgled forme korisnikog interfejsa koji se otvara pritiskom na dugme dalje, u zavisnosti od izabranog kriterijuma.

alempije@beotel.rs

115

Slika 6.46. Forma izbora jezika po kojem se pretrauje naslov S obzirom da smo izabrali kriterijum pretraivanja po jeziku na sledeoj formi se pojavljuje element klase combobox koji vue vrednosti naziva jezika iz tabele ifarnika jezika. Auriranjem ifarnika jezika menjae se i broj i sadraj stavki combobox-a. Izabrani jezik se prenosi na donju tekst kontrolu. Na formi postoje i dve kontrole. To je dugme izai kojim se ponovo odustaje od pretraivanja. Dugme pretrai odpoinje pretragu tabele naslova za svim onim koji su napisani na srpskom jeziku. Rezultat pretrage e biti dat na sledeoj formi i to e biti svi naslovi koji su ranije oznaavani kao dela na hrvatskom i srpskohrvatskom jeziku. Forma rezultat pretrage koja se pojavljuje je najea pojava u radu sa aplikacijom BibIS 1.0. Njeno pojavljivanje moe biti i rezultat nekih drugih akcija kao to je komanda rezervacije, pregleda stanja naslova, tampanja nalepnice i katalokog listia. Stavljanjem vie ovakvih kontroli, koje se sve definiu nad primerkom klase naslova, na jednu formu tedi prostor, skrauje vreme u pristupu svim podacima vezanim za jedan naslov. Korisno je imati mogunost obavljanjana jednom mestu vie operacija nad naslovom, Na levoj strani maske se nalaze podaci vezani za naslov dok su sa desne strane podaci vezani za lana biblioteke koji dui primerak naslova (ako je naslov zaduen). Sluaj koji je i ovde prisutan (da je rezultat pretrage vie naslova), da ima vie naslova na srpskom jeziku, rezultuje pojavljivanjem broja takvih naslova u status baru. Uz pomo odgovarajuih kontrola mogue je kretati se po skupu pretraenih naslova. U zavisnosti od trenutnog naslova se menja i sadraj desnog dela ekrana. U status baru, u njegovom desnom delu, se nalazi i podatak o broju lanova koji due primerke takvog naslova, ako i njih ima vie od jednog mogue je i kretati se po skupu lanova koji due trenutni naslov (kontrole kojima se to ostvaruje su dugmad pre.lan i sle.lan).

116

alempije@beotel.rs

Slika 6.47. Forma rezultata pretrage naslova

Slika 6.48.Forma zaduivanja trenutnog naslova U zavisnost da li je izabrano zaduivanje, rashodovanje naslova, rezervisanje, tampanje nalepnice ili katalokog listia neki od dugmia koji i nose imena ovih operacija nad instancom klase naslova e biti dostupni a neki ne. Ako je broj slobodnih primeraka vei od nula dugme zadui e reagovati na dogaaj pritiska, u protivnom je mogue samo rezevisanje naslova. U konkretnom sluaju svi primerci naslova su slobodni pa je mogue zaduiti trenutni naslov. Pritisak na taster zadui otvara sledei dijalog zaduenja. Ovde se ostvaruje koncept postavljen u toku faze dizajna, koji glasi : zaduuje se primerak, a rezervie se naslov. lan koji zaduuje naslov se identifikje preko matinog broja i samo ako se pronae lan za zadati JMBG aktivirae se dugme zadui. No pre toga, ako se radi o naslovu koji ima vie od jednog primerka u odgovarajuem combobox-u valja izabrati neki od slobodnih primeraka. Od kontrola vezanih za ovu funkciju mogue je jo i odustati od zaduivanja naslova kao i izvriti ponovni unos u sluaju greke.

alempije@beotel.rs

117

Forme knjige U stavci knjiga mogue je pogledati stanje naslova, tampati nalepnicu naslova i kataloki listi, te rashodovati postojei naslov. U sluaju izbora neke od tih opcija redosled otvaranja formi je istovetan onom kod zaduivanja ili rezervisanja naslova. Dakle, prvo se bira kriterijum pretraivanja, pa se unose vrednosti upita za izabrani kriterijum, a nad dobijenim rezultatima pretrage vre se odgovarajue operacije. Jedinu razliku u odnosu na ovakvo ponaanje predstavlja unoenje podataka novopristiglog naslova u biblioteku, koje otpoinje izborom opcije evidencija/zavoenje iz stavke knjiga glavnog menija aplikacije.

Slika 6.49. Forma zavoenja novog naslova Dizajn i ogranienja vezani za unos podataka novog naslova spreavaju nepravlnosti u voenju podataka naslova. do kojih je ranije dolazilo. Postavljanjem zabrane unosa null podataka za veinu kljunih polja entiteta naslova, izbegava se sluaj nemogunosti pretraivanja ili zaduivanja i rezervisanja naslova. U ranijem podsistemu od neto preko 10.000 naslova u bibliotekog fonda, preko 1500 njih nije imalo inventarni broj, to je nedopustivo jer se radi o primarnom kljuu po kojem se formiraju zaduenja, rezervacije i pretrauje naslov. Jedina dva polja koja su neobavezna su polja podnaslova i koautora naslova. Pri unosu je nemogue uneti naslov inventarnog broja ili signature koja ve postoji. Neki podaci kao to je UDK broj se vuku iz odgovarajueg ifarnika, kretanjem po hijerarhijskom stablu udk oblasti na nain kako je to opisano u formi zadavnja upita po udk broju. Od ostalih komandi obezbeene su jo uobiajne komande za izlazak iz forme i ponovni unos u sluaju greke. Zatim je tu komanda deskriptor koja otvara formu za unos deskriptora tekueg naslova ije se ime ispisuje u gornjem levom uglu.

118

alempije@beotel.rs

Slika 6.508. Forma unosa deskriptora

Mapiranje proizvoda dizajna u programski kod

Sada e biti dati primeri klasa iz klasnog dijagrama logike aplikacije sa odgovarajuim kodom koji alat RationalRose generie u jeziku Java. Jezik Java, je potpuno objektno orjentisan, oigledan i pogodan za prikaze ove vrste gde je potrebno povui paralelu izmeu modela u UML notaciji i koda koji se za njega generie. Dakle, trenutni izbor jezika za generisanje koda uslovljen je potrebom za boljim prikazom mapiranja modela u izvorni kod. Atributi i metode koje se pojavljuju jednako i u grafikoj prezentaciji klase i u dijagramu klasa i u deklaraciji klase nee biti posebno opisivani, osim naravno onih koji predstavljaju razliku u odnosu na dijagram klasa. Jedna metoda se u deklaraciji svake klase pojavljuje a nema je u klasi na dijagramu. Ta metoda koja je javna i nosi isto ime kao i klasa je funkcija lanica konstruktor klase.

Mapiranje klase UDKOBLAST u izvorni kod

Deklaracije klase UDKOBLAST ima i pridodati referencijalni atribut tipa klase NASLOV. To znai, i ve je reeno da udk oblast mora imati iz razloga pretraivanja po udk broju podatke o svim naslovima istog udk broja. Na sledeoj slici prikazano je mapiranje klase UDKOBLAST u izvorni kod.

UDKOB LAST udk : S tring naziv oblas t : S tring Class _Initialize() Class _Terminat e() Razgranaj() Obrisi()
Slika 6.51. Mapiranje klase UDKOBLAST u izvorni kod

alempije@beotel.rs

119

Mapiranje klase NASLOV u izvorni kod

Dodati atributi su referencijalni tipa klasa DESKRIPTOR, JEZIK i REZERVACIJA. Ovde se na konkretnom primeru moe videti realizacija principa postavljenog jo u fazi analize, da se rezerviu naslovi a zaduuju konkretni primerci naslova. Na sledeoj slici prikazano je mapiranje klase NASLOV u izvorni kod.
NA SLOV inv br : I nt eger nas lov : String podnas lov : String aut or1 : String aut or2 : String aut or3 : String godina : I nt eger brprimerak : Int eger s ignat ura : String datumunos a : Date f ormat : I nt eger ilus trac ij : Boolean brs trana : Int eger iz danje : String Clas s _I nitializ e() Clas s _T erminate() Pretraz i() A zuriraj() Z av edi() Rs hoduj() Z aduz i() Raz duz i()

Slika 6.52.Mapiranje klase NASLOV u izvorni kod

Mapiranje klase IZDAVAC u izvorni kod

U deklaraciju klase izdava je dodat je referencijalni atribut tipa klase NASLOV, iz razloga pretraivanja naslova po izdavau. Svi referencijalni atributi pa i ovaj su posledica asocijativne veze izmeu klasa, odnosno navigabilnosti tih veza. Na sledeoj slici prikazano je mapiranje klase IZDAVAC u izvorni kod.

120

alempije@beotel.rs

IZDAV AC idizdav aca : Int eger izdav ac : S tring Class_Init ialize() Class_Terminate() Izlistaj()
Slika 6.53.Mapiranje klase IZDAVAC u izvorni kod

Mapiranje klase CLAN u izvorni kod

Klasa CLAN je izuzetno vana za funkcionisanje aplikacije. Njenoj deklaraciji je generator koda gde su definisani referencijalni atributi koji ukazuju na klase CIN, RAZDUZENJE , REZERVACIJA, ZADUZENJE i OPOMENA. Veina atributa i metoda ove klase su nivoa zatite protected jer slue kao i sama klasa za nasleivanje, specijalizaciju lana biblioteke na podklase STUDENT, ZAPOSLEN. Na sledeoj slici prikazano je mapiranje klase CLAN u izvorni kod.

CLA N jmbg : String ime : St ring prezime : String telefon : St ring Class_Initialize() Class_Terminat e() Upisi() Ispisi() Izlistaj() Azuriraj() St ampaj()

Slika 6.54.Mapiranje klase CLAN u izvorni kod

Mapiranje klase ZADUZENJE u izvorni kod

U deklaraciji klase ZADUZENJE se prisutnou referencijalnih atributa tipa klase CLAN i Primerak. Objekat klase ZADUZENJE znai, zahvaljujui asocijativnim vezama i navigabilnou u oba pravca ima informacije o objektima klasa CLAN i Primerak koje zdruuje u relaciji zaduenja.

alempije@beotel.rs

121

Na sledeoj slici prikazano je mapiranje klase ZADUZENJE u izvorni kod.

ZADUZENJE datzaduzen : Date rok : Date Class_Initialize() Class_Terminate() Pretrazi() Azuriraj()

Slika 6.55. Mapiranje klase ZADUZENJE u izvorni kod

Mapiranje klase REZERVACIJA u izvorni kod

I klasa REZERVACIJA zahvaljujui svojim vezama navigabilnosti u oba pravca i smera dobija u svojoj deklaraciji kao i klasa ZADUZENJA dva nova referencijalna atributa, s tom razlikom to jedan od njih nije tipa klase Primerak ve klasa NASLOV. O tome je ranije vie puta bilo rei (rezervie se naslov a zaduuje se primerak naslova). Na sledeoj slici prikazno je mapiranje klase REZERVACIJA u izvorni kod.

REZERVACIJA datum : Date Clas s _Initialize() Clas s _Term inate() Ukini()

Slika 6.56. Mapiranje klase REZERVACIJA u izvorni kod U pogledu posedovanja, na osnovu osobina veza asocijacije pridodatih referencijalnih atributa , klase OPOMENA i RAZDUZENJE (i generisani kod njihove deklaracije) se ne razlikuju nimalo u odnosu na klasu zaduenja.

Mapiranje klase RAZDUZENJE u izvorni kod

U odnosu na klasu ZADUZENJA klasa RAZDUZENJE, pored pomenutih referencijalnih atributa, ima jo dva podataka lana tipa datuma koji uvaju podatak o danu pozajmice i danu vraanja primerka naslova. Na sledeoj slici prikazano je mapiranje klase RAZDUZENJE u izvorni kod.

122

alempije@beotel.rs

RAZDUZENJE datum zad : Date datum razd : Date Clas s _Initial ize() Clas s _Term inate() Pretraz i () Azuri raj ()

Slika 6.57. Mapiranje klase razduenja u izvorni kod

Mapiranje klase OPOMENA u izvorni kod

Objekti klase OPOMENA se kreiraju dinamiki u toku izvrenja programa na dogaaj pritiska na odreenu stavku forme glavnog menija. U takav objekat se kao to se vidi na primeru deklaracije klase smetaju podaci o lanu, primerku (kao referencijalni atributi) ali i podaci datumu i rednom broju opomene. Klasa ima i odgovarajue funkcije lanice(metode). Na sledeoj slici prikazano je mapiranje klase OPOMENA u izvorni kod.

OPOMENA broj : Integer dat um : Date Class_Initialize() Class_Terminate() Pretrazi() Stampaj() A zuriraj()
Slika 6.58. Mapiranje klase OPOMENA u izvorni kod

Definisanje tehnologije aplikativne i mrezne arhitekture za poslove cirkulacije

Definisanje tehnologije aplikativne i mrezne arhitekture za poslove cirkulacije Definisanje tehnologije Definisanje aplikativne arhitekure (dijagram komponenti) Definisanje mrezne arhitekture (razvojni dijagram)

alempije@beotel.rs

123

Definisanje tehnologije
U pogledu izbora tehnologije bilo je najmanje dvoumljenja, jednostavno je vreme samo nametnulo svoje reenje. Radi se o izboru troslojne arhitekture o kojoj je ranije bilo dosta rei. Troslojna arhitektura je zajednika za informacione sisteme koji ukljuuju korisniki interfejs i postojano skladite podataka. Uobiajan opis vertikalnih slojeva je: Prezentacija- prozori, izvetaji, i.t.d. Logika aplikacije- zadaci i pravila upravljanja procesima Skladite- postojani mehanizam skladitenja. Posebna prednost troslojne arhitekture je razdvajanje logike aplikacije u logiki poseban srednji sloj softvera. Sloj prezentacije je relativno osloboen od poslova aplikacije; prozori prosleuju zahteve zadataka srednjem sloju. Srednji sloj komunicira sa poslednjim slojem skladita. Koncept troslojne arhitekture aplikacije razdvaja razliite komponente sistema u tri sloja usluga: sloj prezentacije, sloj procesiranja i druge srednje slojeve, i sloj podataka.

Prezentacija

Logika aplikacije

Skladiste

Zabelezi naslove Azuriraj zaduzenja

baza

Slika 6.59. Troslojna arhitektura Ovakava arhitektura se razlikuje od dvoslojnog dizajna, u kojem je primera radi, logika aplikacije smetena u definiciji prozora, koji ita i upisuje direktno u bazu podataka; ne postoji nikakav srednji sloj koji izdvaja logiku aplikacije. Nedostatak dvoslojne arhitekture je nemogunost da se logika aplikacije predstavi u odvojenim komponentama, to povlai za sobom nemogunost ponovnog korienja koda. Takoe nije mogue distribuirati aplikaciju izmeu odvojenih raunara. Kod troslojne arhitekture je to mogue i odvajanjem sloja prezentacije od sloja skladitenja se postiglo to da nije bitno u kom se alatu realizuju interfejsi i kojem sistemu za upravljanje bazom podataka se pristupa. Tako je mogue raditi korisnike interfejse u Delphi-ju koji e koristiti podatke iz jedne tako ozbiljne baze kao to je Oracle-ova.

Vieslojna objektno-orjentisana arhitektura

Preporuena vieslojna arhitektura za objektno- orjentisane informacione sisteme podrazumeva razdvajanje odgovornosti koje sprovodi klasina troslojna arhitektura. Ove odgovornosti se dodeljuju softverskim objektima. 124
alempije@beotel.rs

Dekomponovanje sloja logike aplikacije

U objektno-orjentisanom dizajnu sloj logike aplikacije je razloen u detaljnije slojeve. Ova arhitektura organizovana u obliku softverskih klasa je data na sledeoj slici. Sam sloj logike aplikacije razloen je na sledee podslojeve: Objekti domena Servisi

Prezentacija

Logika aplikacije Koncepti domena

Skladiste

Servisi Interfejs ka bazi podataka Generator Izvestaja Baza

Interfejs klase

Cirkulacija

Obrada

Slika 6.60. Dalje dekomponovanje troslojne arhitekture Kada se gleda ovako dekomponovan sloj logike aplikacije moe se rei da se vie ne radi o troslojnoj ve o vieslojnoj arhitekturi. Mogue je ak vriti dalju dekompoziciju, na primer, na nie servise (itanje i upisivanje u datoteku) i vie servise (izrada izvetaja). Troslojna logika arhitektura moe biti fiziki razvijena u razlitim oblicima: Slojevi prezentacije i logike aplikacije su na klijent raunaru, skladite je na serveru. Prezentacija je na klijent raunaru, logika aplikacije je na serveru aplikacije, a skladite na odvojenom serveru podataka. Opredeljenje u konkretnom problemu je za prvu od dve gore navedene opcije, jer ona obezbeuje zadovoljavajue rezultate uz manje ulaganje. Sa poveanjem upotrebe programskih jezika i tehnologija koje sa lakoom podravaju distribuiranu obradu, kao to je Java, i razvoj podsistema e isto tako biti sve vie distribuiran. Razlozi za uvoenje vieslojne arhitekture su: Izdvajanje logike aplikacije u odvojene komponente koje se kasnije ponovo mogu koristiti u drugim sistemima. Distribucija slojeva na razliite fizike raunarske vorove. Ovo moe da pobolja perfomanse i povea kordinaciju i deljenje informacija u klijent-server sistemu. Rasporeivanje programera na razvoj odreenih slojeva, kao to je timski rad na sloju prezentacije. To podrava specijalizaciju u smislu razvojnih vetina, i mogunost paralelnog timskog rada.
alempije@beotel.rs

125

Nakon svega navedenog ne bi trebalo da ima sumnje u opredeljenju za troslojnu arhitekturu, pogotovu kada se zna da je ona u dananje vreme postala gotovo standard. Nezavisnost korisnikog interfejsa od sistema za upravljanje bazama podataka, koji implementira postojano skladite podataka, je jednostavno nezamenljiva.

Definisanje aplikativne arhitekure (dijagram komponenti)

Pod ovom aktivnou se podrazumeva definisanje softverskih komponenti koje obezbeuju funkcionisanje aplikacije, kao i definisanje veza zavisnosti izmeu njih. To je opis softverske arhitekture sistema. Takva komponenta je fiziki izmenljiv deo sistema koji obezbeuje realizaciju skupa interfejsa. Komponenta je fiziki deo sistema jer ona zaista postoji u vidu datoteke instalirana na sistemu na kojem se izvodi aplikacija. Komponenta je izmenljiva u tom smislu to je mogue vriti intervenciju na kodu komponente i tako na jednom mestu menjati, recimo, funkciju koja se vie puta poziva u izvornom kodu. To doprinosi izuzetno poeljnoj osobini softvera koji se projektuje- ponovno iskoristljivost, reuseability of code. Radi se o ideji da se jednom napisani kod, recimo algoritam neke obrade, nikad vie ne mora pisati ve se po potrebi zahvaljujui konceptu deljenja koda na komponente, koji odlikuje sve savremene alate za objektno orjentisano programiranje, jednostavno uvruje u razliite projekte. To umanjuje vreme izrade aplikacije, poveava efikasnost u radu i smanjuje verovatnou da e se napraviti greka u kodu. Stereotipovi komponenti sistema koji se razvija zavise od odlika okruenja (kompajlera) koji se koristi. Tako su za jezik C++ neki od predefinisanih stereotipova za komponente softvera recimo EXE i DLL. No i ako se aplikacija ne razvija u tom programskom jeziku, kao to je to ovde sluaj, ne mari mnogo jer se stereotip softverske komponente moe i runo upisati. Inae u paketu RationalRose (koji je ovde korien) aplikativna arhitektura se opisuje dijagramom komponenti. Na sledeoj slici je dat osnovni komponentni dijagram za aplikaciju podsistema koji se razvija.
<<EX E>> Bibis

<<RES>> R esursi Paket datoteka "*.dfm" Paketi komponenti Delphija Paket datoteka "*.dcu"

Sv akoj formi u D elphi okruzenju pridruzena je jedna datoteka sa opisom izgleda forme

Paket datoteka "*.pas"

126

alempije@beotel.rs

Slika 6.61. Osnovni komponentni dijagram Kao to se moe naslutiti iz priloenog komponentnog dijagrama, izabrano razvojno okruenje aplikacije je Delphi. To je kompajler firme Borland koji implementira objektno-orjentisan Pascal. Izvorini kod takvog alata uva se u datotekama tipa "*.PAS", koje odgovaraju datotekama "*.CPP" u jeziku C++. Svaka klasa u objektno orjentisanom Pascal-u ima svoju datoteku tipa "*.PAS". One su smetene u odgovarajuem paketu na dijagramu na slici gore. Za svaku od tih datoteka ( koje praktino predstavljaju klase formi Delphi aplikacije)izvoriog postoje jo po dve datoteke koje je prate. To su datoteke tipa "*.DFM" i datoteke tipa "*.DCU". Datoteke "*.DFM" ( Delphi Forms ) sadre parametre koji odreuju spoljni, ekranski izgled svake forme- visina, irina, boja, pozicija... Datoteke "*.DCU"(Delphi Compiled Unit) predstavljaju rezultat prevoenja datoteka izvorinog koda- ekstenzije "*.PAS". One su paralela datotekama tipa "*.OBJ" u jeziku C++. Jedna softverska komponenta, jedan fajl, koji ih povezuje je izvrni fajl radnog naziva Bibis.exe, opisan stereotipom <<EXE>>. Sve ove komponente na dijagramu su meusobno povezane vezama zavisnosti. Semantika ovih veza je sledea: Svaka promena na fajlu (softverskoj komponenti) ili njeno nepostojanje uticae na izgled komponente koje zavisi od nje. Na ovom primeru to bi izgledalo ovako. Svaka promena na kodu izvorinog fajla tipa "*.PAS" uzrokovae primene u odgovarajuoj datoteci tipa "*.DCU". Isto tako ako nema izvorine datoteke nama ni njenog prevedenog oblika u binarnom zapisu. Pored pomenutih komponenti i paketa komponenti na dijagramu se nalazi i paket komponenti Delphi-ja, koje su ugraene u alat ali bez njih nema valjanog prevoenja izvorinog koda to se i da videti na dijagramu. Zavisnost vai samo ako je komponenta iz paketa koriena u izradi aplikaciji.
<<BPL>> dcldb40 <<BPL>> dclint40 <<BPL>> dclusr <<BPL>> DBWEBXPRT40

<<BPL>> dcldss40

<<BPL>> dclsmp40

<<BPL>> dcl3iw40

<<BPL>> NMFAST40

<<BPL>> ibevent40

<<BPL>> dclocx40

Paketi za barkod

<<BPL>> dclnet40

<<BPL>> dclstd40

<<BPL>> dclqrt40

<<BPL>> frmhelp

<<BPL>> dclmid40

<<BPL>> dcltee40

<<BPL>> Gen_Pack

Slika 6.62. Komponente Delphi okruenja Kao to se da videti radi se o velikom broju komponenti i naravno da nisu sve koriene za problem koji se ovde razmatra. Radi se o datotekama tipa "*.BPL"- Borland Package Library. Od nestandardnih komponenti Delphi okruenja istie se paket komponenti za podrku rada sa bar kodom. One su neophodne s obzirom na specifikaciju korisnikih zahteva da budui podsistem integrie u sebi i predstavljanje matinog broja CLANa i inventarnog broja knjige linjskim kodom. Pored svih pomenutih komponenti vidi se da komponenta Bibis zavisi i od komponete na slici 54. nazvane resursi, koja je zapravo jedna datoteka tipa "*.RES" i usebi uva podatke o resursima koje koristi aplikacija. Podrazumevano u toj datoteci se nalazi podatak o ikonici projekta, a runo se mogu dodati i drugi resursi , kao to su recimo korieni fontovi. Tako e aplikacija koristiti iste

alempije@beotel.rs

127

fontove na kojem god raunaru da se instalira i bez obzira da li na njemu postoje takvi fontovi. Sad e na sledeoj slici biti dat malo komplikovaniji komponentni dijagram sa prikazom zavisnosti datoteka izvorinog koda. Na dijagramu se istie komponenta datoteke " Glavni meni.pas" koja zavisi od velikog broja drugih komponenti. Znaenje ovih veza je da svaka izmena u nekoj od komponenti menja funkcionisanje komponente "Glavni meni.pas".
<<PA S>> Zaduzivanje <<PA S>> Rezultat pretrage <<P AS>> Nalepnica <<PAS>> Zbirna pretraga <<PAS>> Upis clana <<PA S>> UDK <<PAS>> Podaci <<PAS >> Kategorija clana

<<PAS>> Uvodna

<<PAS >> Kriterijum i pretrage

<<PAS>> Pretraziv anje po jeziku <<P AS >> Sluzbe

<<PAS>> Unos lozinke

<<PAS>> Promena naloga

<<PAS>> G lavni meni <<PAS>> Knjiga

<<PAS>> Nov a knjiga

<<PAS>> P romena lozinke i priv ilegija <<PA S>> Spisak nal oga

<<PAS >> Nov i nal og

<<P AS >> Izmena lozinke <<PA S>> K lase

<<PAS>> Ispis clana <<PAS>> Clan

<<PAS>> Desk riptor

<<PA S>> Jezici

<<P AS>> Cinov i

<<PAS>> Listing clana

Slika 6.63. Komponentni dijagram sa prikazom zavisnosti datoteka izvorinog koda

Definisanje mrene arhitekture (dijagram razvoja)

Ovo je zadnji korak u objektno orjentisanom dizajnu. Podrazumeva definisanje strukture hardverskih komponenti na kojoj treba da se izvravaju pomenute softverske komponente. Pored hardverskih komponenti mogu se predstaviti i softverske komponente koje se na njima izvravaju. Pomenuta struktura se najbolje opisuje dijagramom razmetaja (deployment diagram) u alatu ParadigmPlus, koji za razliku od alata RatonalRose ima vizuelniju reprezentaciju hardverskih ureaja sistema. Za razliku od postojeeg okruenja novo bi u sebe ukljuilo znatna HW proirenja kao i promene u arhitekturi podsistema. Zadrava se centralni server na kojem operiu zaposleni u biblioteci, gde se nalaze svi podaci (baza podataka) vezani za biblioteko poslovanje. Ostaje i tampa povezan na server standardnom paralelnom linijom, sa potrebom nabavke tampaa savremenije tehnologije ( ink jet ili laser) kako bi se ubrzao rad na uvoenju novih naslova i clanova u poslovanje, ali i izvetavanje. Najvea novinu predstavlja uvoenje odreenog broja klijent raunara i uspostavljanje odgovarajue mrene arhitekture. Time bi se poveala funkcionalnost podsistema, kojem bi sa udaljenih lokacija pristupali clanovi biblioteke. Sa ovakvih klijenata bi se izvravale funkcije pretraivanja bibliotekog fonda i rezervisanja naslova. Veza klijenata i servera 128

alempije@beotel.rs

bi se realizovala standardnim TCP/IP mrenim protokolom. U cilju optimizacije perfomansi mree veina rutina bi se nalazila na serveru i tu se izvravala. Svakako da realizacija ovakvog okruenja iziskuje izdvajanje izvesnih materijalnih sredstava. Dijagram razvoja je zapravo graf iji su vorovi hardverski ureaji sitema. Veza izmeu pojedinih vorova grafa predstavlja direktnu konekciju dva hardverska sklopa u sistemu. Na sledeoj slici je dat izgled mogue hardverske strukture podsistema bibliotekog poslovanja.
1 1 1 paralelna veza Server Operater STAMPAC

TCP/IP *

Klijent

Slika 6.64. Dijagram razmetaja Dakle, mogue reenje bi bilo postojanje jednog raunara servera na kojem bi se uvali podaci i vie raunara klijenata na kojima bi se obavljali korisniki servisi nad podacima. Veza ka serveru bi se ostvarivala TCP/IP mrenim protokolom. Kako bi se server oslobodio bilo kakvog rada u odnosu na dijagram razmetaja iz poglavlja definisanja zahteva dodat je i jedan vor u vidu raunara operatera na kojem bi radili zaposleni u biblioteci. Naime klijenti su namenjeni CLANovima biblioteke odakle bi se mogli pretraivati naslovi i vriti rezervacije. sve ostale funkcije, kao to je vie puta naglaeno, mogli bi da vre zaposleni u biblioteci preko raunaraoperatera. Na raunar-operater je povezan paralelnom vezom tampa preko kojeg bi zaposleni tampali odgovarajue nalepnice CLANa, naslova, kataloke listie, dokumenta materijalnog knjigovodstava i razne izvetaje. Zapaa se da je pored veza vorova grafa data i kardinalnost veza. Svakako da je server jedan i samo jedan, raunara klijenata je vie( ali bi mogao biti i jedan) dok je operater jedan. Naravno, s obzirom da u biblioteci ima vie zaposlenih (troje) ostavlja se mogunost da ih bude i vie, ali se postavlja pitanje ekonomske opravdanosti takvog ulaganja kada se uzme u obzir dnevni protok CLANova i naslova kroz biblioteku. Treba ipak istai da je dijagram sa slike gore, nepotpun u smislu to predstavlja ogoljen hardver bez podataka o softveru koji se na njemu izvrava. Taj nedostatak e se pokuati otkloniti slikom koja sledi.

alempije@beotel.rs

129

<<executable>> <<executable>> WindowsNT for Workstations <<executable>> SERVER BIBIS OPERATER

WindowsNT Server DBase

TCP/IP <<executable>> WindowsNT for Workstations <<executable>>

paralelna veza 1

BIBKlijent KLIJENT

STAMPAC

Slika 6.65. Dijagram razmetaja sa odgovarajui softverskim komponentama U pogledu hardveske strukture dijagrama na nije pretrpeo nikakve izmene. Novinu predstavljaju softverske kompnente koje su na vorovima grafa hardverske strukture an kojima se izvravaju. Razlikuju se softverske komponente operativnog sistema i aplikacije. U pogledu operativnog sistema izbor je pao na WindowsNT firme Microsoft za rad u mrenom okruenju. Taj operativni sitem je sa jedne strane dovoljno komercijalan da bi bio pristupaan, a sa druge strane sasvim solidno ispunjava bezbedonosne zahteve kakve moe imati rad u mrenom okruenju. Naravno na serveru e biti instalirana server verzija ovog operativnog sistema, dok e na klijentima i operateru biti instaliran WindowsNT for Workstations. Baza podataka se nalazi na serveru. Aplikacija bibliotekog podsistema se u punom obimu izvrava na raunaru-operateru gde administriranje vre zaposleni u biblioteci . Na raunarima klijentima izvravao bi se modul aplikacije koji je ovde uslovno nazvan BibKlijent, a koji bi u skladu sa svim napred izreenim mogao da vri samo pretraivanje naslova i rezervisanje. Mrena arhitektura podsistema bibliotekog poslovanja je tako projektovana da uzima u obzir ekstremnu udaljenost pojedinih objekata u okviru.

130

alempije@beotel.rs

Zakljuak
Da bi rad u novom okruenju bio mogu neophodno je da zaposleni u biblioteci pomou odgovarajue opcije u stavkama glavnog menija dopune podatke za naslove koji do sada nisu voeni, kao i odgovarajue ifarnike. Pravci u kojima treba da se kreu eventualna budua poboljanja su proirivanje fonda sa informatikom evidencijom asopisa (isto kao to je uinjeno za naslove), zatim ako to bude svrsishodno i razmotriti mogunosti primene Web tehnologija u cilju ostvarivanja bolje saradnje sa bibliotekama akademskih ustanova u inostranstvu.

Literatura
1 Veljovi A. Objektno modeliranje informacionih sistema, Fakultet za poslovne studije, MEGATREND Univerzitet, 2003. godina 2. Veljovi A. Praktikum iz analize informacionih sistema, Fakultet za poslovne studije, MEGATREND Univerzitet, 2005. godina 3. Veljovi A. Objektni pristup razvoju informacionih sistema i baze podataka, VTA Beograd, 2002. godina.

alempije@beotel.rs

131