Embed Size (px)
Citation preview
SVEUČILIŠTE U SPLITUFAKULTET ELEKTROTEHNIKE, STROJARSTVA I
BRODOGRADNJE
DIPLOMSKI RAD
INFORMATIZACIJA HACCP STANDARDA PRIMJENOM SOA RJEŠENJA
Jurica Grgičević
Split, rujan 2011.
KAZALO
1 SAŽETAK...........................................................................................................................4
2 UVOD..................................................................................................................................5
3 KONTROLA KVALITETE PROIZVODA........................................................................6
3.1 Sustavi Upravljanja Kvalitetom i ISO 9001.................................................................6
3.2 HACCP.........................................................................................................................8
3.2.1 HACCP načela......................................................................................................9
3.3 ISO 9001 i HACCP u PPK-a......................................................................................10
4 .NET..................................................................................................................................13
4.1 .NET razvojna okolina...............................................................................................13
4.1.1 Verzije .NET-a....................................................................................................15
4.1.2 .NET 4.0..............................................................................................................16
4.1.3 Windows Comunication Foundation..................................................................17
4.1.4 Windows Presentation Foundation.....................................................................26
4.1.5 ADO.NET Entity Framework.............................................................................30
4.1.6 Managed Extensibility Framework.....................................................................36
4.1.7 Prevođenje i CIL.................................................................................................42
4.2 Programski jezik C#...................................................................................................43
5 ARHITEKTURA ORIJENTIRANA SERVISIMA – SOA..............................................45
5.1 Uvod...........................................................................................................................45
5.2 Model arhitekture orijentirane servisima...................................................................48
5.2.1 Tipovi XML servisa............................................................................................50
6 QUALITY CONTROL SOFTWARE...............................................................................51
6.1 Baza podataka............................................................................................................51
6.2 Server.........................................................................................................................55
6.3 Klijent.........................................................................................................................63
6.4 Moduli........................................................................................................................74
2
6.4.1 Modul Organizacija............................................................................................74
6.4.2 Modul Korisnici..................................................................................................74
6.4.3 Modul HACCP....................................................................................................75
6.4.4 Modul Obrasci....................................................................................................75
7 ZAKLJUČAK....................................................................................................................76
8 LITERATURA..................................................................................................................77
9 PRILOZI............................................................................................................................80
9.1 Kazalo slika i tablica..................................................................................................80
9.1.1 Kazalo slika.........................................................................................................80
9.1.2 Kazalo tablica......................................................................................................80
9.2 Popis oznaka i kratica.................................................................................................81
9.3 Ostali prilozi i dodaci.................................................................................................83
9.3.1 Prilog 1. Shema Baze..........................................................................................83
9.3.2 Prilog 2. Osobna evidencija................................................................................84
9.3.3 Specifikacija Zahtjeva.........................................................................................85
9.3.4 Plan Projekta.......................................................................................................86
9.3.5 Pivis Zapisnici.....................................................................................................87
9.3.6 Upravljanje izmjenama.......................................................................................89
3
1 SAŽETAK
Sažetak
Sustavi kontrole kvalitete su danas postali važan dio svake organizacije koja se bavi
proizvodnjom i preradom hrane. Set standarda ISO daje niz uputa i preporuka za
implementaciju kontrole kvalitete. Njihov najpopularniji i najrašireniji standard za kontrolu
kvalitete je ISO 9001 standard. Dio ISO 9001 standarda zaduženog za sigurnost hrane
bazirane na prevenciji je HACCP standard (Hazard Analysis and Critical Control Point). U
okviru ove radnje razvijeno je rješenje za digitalizaciju ISO 9001 i HACCP sustava za
potrebe Mesne industrije PPK Karlovac. U prvom dijelu radnje opisan je sustav kontrole
kvalitete u PPK Karlovac. U drugom dijelu radnje opisane su Microsoftove tehnologije koje
su se koristile za izradu aplikacije. To su redom .NET tehnologije: WCF, WPF, Entity
Framework, MSSQL Server. Posljednji dio radnje opisuje arhitekturu aplikacije. Aplikacija
je napravljena kao SOA aplikacija. To znači da se sastoji od serverskog i klijentskog dijela.
Serverski dio ima zadaću da upravlja bazom podataka i poslužuje klijenta sa podacima.
Klijent omogućava interakciju korisnika sa sustavom. Napravljen je tako da može primati
dodatke (eng. plugin). Aplikacija ima četiri dodatka: Organizacija, Korisnici, HACCP i
obrasci. Organizacija i korisnici omogućavaju dodavanje, brisanje i ažuriranje korisnika
sustava i organizacija. HACCP dodatak omogućava analizu opasnosti i izradu HACCP
plana. Dodatak Obrasci sadrži digitalne verzije postojećih papirnatih obrazaca.
Ključne riječi
Kontrola kvalitete, ISO 9001, HACCP, .NET, WCF, WPF, Entity Framework, Quality Control
Software
4
2 UVOD
Danas, bilo koja organizacija, koja se bavi proizvodnjom hrane, ako sebe želi nazvati
imalo ozbiljnom, mora imati uveden neki od sustava za kontrolu kvalitete. Najčešće je to ISO
9001. Dio ISO-a 9001 koji se bavi sigurnošću hrane je HACCP. HACCP sustav, danas, je
postao zakonska obveza svih onih koji se bave proizvodnjom i preradom hrane.
Na hrvatskom tržištu, većinom se nude usluge savjetovanja u implementaciji HACCP
sustava. No polako pojavljuju se programska rješenja koja bi trebala pomoći pri bržoj
implementaciji HACCP sustava naspram načinu na koji se do sada koristio za uvođenje
HACCP sustava. Dosadašnji pristup rezultirao bi velikom količinom dokumenata, koji bi
stvarali dodatan posao radnicima organizacije koja uvodi HACCP. Zbog toga se postepeno
prelazi na programska rješenja u uvođenju HACCP sustav jer bi ona pomoću jednostavnog
sučelja trebala olakšati rad, a ne dodatno ga zakomplicirati. Na svjetskom tržištu postoji dosta
programskih rješenja koji imaju manje više iste funkcionalnosti. Neka od riješenja su:
ISOsystemPlus, Qsolve, ISO 22000:2005-HACCP, HACCP Manager Software, justfoodERP
Dok stanje na hrvatskom tržištu je drugačije. Postoje jedan, dva programska paketa.
Zbog toga mnoge organizacije uvode svoja programska rješenja. Pa tako i tema ovog rada
je napraviti programsko rješenje HACCP sustava prilagođeno za mesnu industriju PPK, na
temelju odluke uprave koja je ustanovila da niti jedno riješenje ne zadovljava njene potrebe.
Cilj ovog rada je upoznati se s principima HACCP standarda. O čemu će biti riječi u poglavlju
Kontrola kvalitete proizvoda Poglavlje .NET dat će kratak uvid o Microsoftovim
tehnologijama koje su se koristile prilikom izrade rada. To su redom WCF, WPF, Entity radna
okolina, MEF i C#. Navedeno je mnogo čudnih kratica, njihovo značenje bit će jasnije nakon
što se pročita to poglavlje. Razumijevanje ovih tehnologija je bitno kako bi se moglo lakše
razumjeti aplikacija. Poglavlje o arhitekturi orijentiranoj servisima ukratko će objasniti
osnovne principe dizajniranja ovakvih aplikacija. Ovo je važno jer je aplikacija dizajnirana na
ovakvom principu. I na kraju poglavlje Quality Control Software detaljno opisuje dizajn
aplikacije. Počevši od baze, gdje su opisane njezine tablice i model koji se krije iza nje.
Nakon baze opisana je serverska strana aplikacije, njene operacije i klase. Te na kraju je
opisan klijent, logika koja se krije iza njega i njegovi moduli.
5
3 KONTROLA KVALITETE PROIZVODA
3.1 Sustavi Upravljanja Kvalitetom i ISO 9001
Prije nego započne priča o sustavima za kontrolu kvalitete, potrebno je definirati što je
to kvaliteta. Jedna od definicija kvalitete je: subjektivni doživljaj kupca kroz dizajn proizvoda
i način na koji sam dizajn odražava originalnost proizvoda mogućnost da određeni proizvod
ili usluga ispuni svoju svrhu usklađenost sa propisima tvrtke.
Quality Management System (QMS ) tj. Sustav Upravljanja Kvalitetom (SUK ) je
tehnika upravljanja koja se koristi za definiranje (komuniciranje) sa zaposlenima o onome što
je potrebno za izradu željene kvalitete proizvoda i usluga, time se utječe na djelatnike da
ispune svoju zadaću prema očekivanom standardu kvalitete.
Osnovni elementi sustava upravljanja kvalitetom su: Osiguranje kvalitete, Osoblje,
Prostori i oprema, Dokumentacija, Proizvodnja, Kontrola kvalitete, Ugovorna proizvodnja i
analiza, Reklamacije i povlačenje proizvoda i Samoinspekcije.
Upravljanje kvalitetom je ključni element uspješnosti poslovanja, a osigurava se putem
sustava temeljenog na poznatim svjetskim standardima (EN-29000, ISO 9000, GMP, BS-
5750). Primjenom sustava osiguranja kvalitete dokazuje se kvaliteta poslovanja, smanjuju se
troškovi, stječe poslovna vjerodostojnost. Zadnjih godina to je postalo pravilo kako u svijetu
tako i u Hrvatskoj. [20]
ISO 9000 je oznaka međunarodne norme za certificiranje sustava upravljanja
kvalitetom. Niže navedeni niz norma ISO 9000, razvijen je kako bi se pomoglo
organizacijama svih vrsta i veličina da djelotvorno primjenjuju i provode učinkovite sustave
upravljanja kvalitetom. Niz normi koje obuhvaća ISO 9000 su: ISO 9000, ISO 9001, ISO
9004 i ISO 19011.
Sublimirani zahtjevi norme ISO 9001 traže da organizacija predodređuje svoj rad
(djelatnost) zadovoljenju kupaca i posredno ostalih zainteresiranih strana, da djelotvorno i
učinkovito upravlja svojim procesima i nadzire njihovo odvijanje, što izravno uzrokuje porast
kvalitete proizvoda (roba/usluga), smanjuje troškove i time ekonomizira procese.
U normi HRN EN ISO 9001 Sustavi upravljanja kvalitetom navodi se da (Područje
primjene) određuje zahtjeve sustava upravljanja kvalitetom u slučajevima kad organizacija:
6
a) treba dokazati svoju sposobnost dosljednog dobavljanja proizvoda koji ispunjava
zahtjeve kupca i zahtjeve zakona i propisa, te
b) namjerava povećati zadovoljstvo kupca učinkovitom primjenom sustava, uključujući
procese za stalno poboljšavanje sustava i osiguravanje sukladnosti sa zahtjevima
kupca, kao i zahtjeva zakona i propisa.
Uvođenje Norme je strateška odluka iza koje mora stajati vrh upravljačke strukture
organizacije, od kojeg se očekuje da podupire i oslanja se na sustav upravljanja kvalitetom.
Štoviše, to je osnovni uvjet da bi se sustav mogao početi uvoditi i funkcionirati u budućnosti.
ISO 9001 zahtijeva nadzor nad poslovnim procesima u organizaciji:
Definiranjem procesa (ulaz i izlaz procesa/povratna sprega, izvršitelji, odgovorne
osobe, vlasnici procesa, tijek procesa itd)
Izražavanjem i određivanjem ciljeva mjerljivim pokazateljima
Mjerenjem i analizom procesa tim pokazateljima izvedbe (odvijanja) procesa
Analizom pokazatelja i na osnovu toga izvještavanjem o uspješnosti procesa
Stalnim i kontinuiranim poboljšanjima procesa
U Normi se ističe da promiče procesni pristup, na samo u modeliranju, upravljanju i
nadzoru poslovnih procesa, već kao osnova za cjelokupno građenje i funkcioniranje
organizacije. Jedna od glavnih odredbi procesnog pristupa je stalno, kontinuirano i neprekidno
poboljšanje poslovnih procesa, odnosno cjelokupnog sustava upravljanja kvalitetom.
Ispunjavanjem tog zahtjeva ne vrši se samo poboljšanje sustava, već se omogućuje njegovo
funkcioniranje, normalno vršenje djelatnosti u svim procesima organizacije.
Ispunjavanje zahtjeva uvedene norme (ili više njih) u organizaciji se provjerava ocjenama
sustava, auditima. Auditi se dijele na unutarnje (interne) i vanjske (eksterne), odnosno
certifikacijske, nadzorne i recertifikacijske. Njima se provjerava, odnosno utvrđuje
usklađenost sustava sa zahtjevima norme. Svako veće odstupanje definira se kao
nesukladnost, koja se nužno mora otkloniti unutar određenog vremenskog roka.
Suvremeno poslovanje u današnjici podrazumijeva da organizacija ima uveden ISO 9001 i
to se predstavlja kao jedan od osnovnih uvjeta za bilo kakvu poslovnu suradnju. Prema
7
podacima organizacija koje se bave ISO sustavom, ISO 9001 je u čitavom svijetu najčešće
uvođena norma. [21]
3.2 HACCP
HACCP je sinonim upravljanja sigurnošću hrane. To je sustav koji identificira,
procjenjuje i kontrolira opasnosti koje su značajne za sigurnost hrane. Poanta je osigurati
sigurnost proizvoda, odnosno spriječiti da proizvod na bilo koji način uzrokuje štetu kod
potrošača. [22]
Izvorno je razvijen kao sustav mikrobiološke ispravnosti u ranim danima 1960-tih
godina od strane tvrtke Pillsbury, NASA-e i Američke vojske. Koristili su ga astronauti za
vrijeme svemirskih ekspedicija. [24]
Dvije riječi, dvije ključne stavke koje predstavljaju HACCP su analiza opasnosti
(hazard analysis) i kritične kontrolne točke (critical control points). Opasnost, kako se koristi
u HACCP sustavu se definira kao biološka, kemijska ili fizička opasnost, koje vidimo kao
potencijalnu prijetnju ljudskom zdravlju. Kritična kontrolna točka je korak u kojem se
primjenjuje kontrola za sprječavanje ili uklanjanje opasnosti za sigurnost hrane, odnosno
smanjenje opasnosti na prihvatljivu razinu. Načelo HACCP-a je sigurnost hrane tijekom
proizvodnje, a ne nakon što imamo gotov proizvod. Cilj je, dakle spriječiti opasnosti u
najranijoj mogućoj točki u lancu hrane, što znači da se može primijeniti od samog procesa
uzgoja životinja do točke potrošnje. Njegova primjena može zahtijevati temeljitu promjenu u
kulturi ili promjenu stavova ljudi uključenih u preradu hrane. U mnogim industrijama ne
postoji tradicija pisanih procedura, odnosno proceduralnih priručnika, te evidencije o kvaliteti
i sigurnosti. HACCP zahtijeva temeljne promjene u stavovima, fokusiran je na vođenje
evidencije i dokumentacije. Slično tome, oni koji pokušavaju implementirati HACCP mogu
teško prihvatiti koncept rizika kontrole sigurnosti hrane, osobito ako su naviknuti na kontrole
koje se temelje na unaprijed određenim parametrima ustanovljenim na vlastitim iskustvima.
Veoma je važno da svi ljudi koji rade u poduzeću razumiju HACCP sustav. Usvajanje
osnovnih znanja o HACCP-u, samo da bi se zadovoljili zahtjevi tvrtke može dovesti do
neuspjeha kompanije. [22]
U početku se HACCP sastojao od tri načela (načela 1,2 i 4 u sljedećem poglavlju).
Pillsbury zatim dodaje iduća dva načela (načela 3 i 5). HACCP sustav sa navedenih pet načela
standardiziran je 1992. Preostala dva načela su dodana 1997 i za sada HACCP sustav se
8
sastoji od tih sedam načela. Godine 2004 je bila zadnja revizija HACCP sustava, ali navedena
načela se nisu mijenjali. [24
HACCP nije nezavisan program, već je dio većeg sustava kontrole, koji uključuje i
provođenje univerzalnih procedura koje se primjenjuju za kontrolu općih uvjeta i okruženja
proizvodnje i doprinose sigurnosti proizvoda. Programi koji trebaju biti usvojeni,
implementirani i dokumentirani su GMP, dobra proizvođačka praksa, SOP – standardne
operativne procedure i SSOP – standardne operativne procedure higijene.
Počevši od 01. siječnja 2006. godine standardi sigurne hrane, u prvom redu HACCP,
obavezni su na tržištima EU i Svjetske trgovinske organizacije, a tvrtke koje ne budu
posjedovale certifikate o poslovanju u skladu sa ovim standardima neće biti u mogućnosti
svoju robu plasirati na spomenuta tržišta. [25]
3.2.1 HACCP načela
HACCP sustav se sastoji od sedam načela, koje opisuju kako uspostaviti
implementaciju i održavanje HACCP plana za određenu operaciju tijekom proučavanja.
Načelo 1
Provesti analizu opasnosti. Odrediti potencijalne opasnosti povezane sa svim fazama
proizvodnje, koristeći dijagram toka na kojem su prikazani koraci procesa. Procijeniti
vjerojatnost nastanka opasnosti, i identificirati preventivne mjere za njihovo suzbijanje.
Načelo 2
Potrebno je utvrditi koje su kritične kontrolne točke (u daljnjem tekstu CCP). Nakon toga,
trebaju se napisati postupci i operativni koraci koji se mogu kontrolirati kako bi se uklonile
opasnosti, ili smanjila vjerojatnost nastanka, odnosno smanjenje opasnosti na prihvatljivu
razinu.
Načelo 3
Uspostaviti kritične granice (ciljana razina i dopuštena odstupanja), koji moraju biti ispunjeni
kako bi se osiguralo da su CCP pod kontrolom. Moraju uključivati mjerljivi parametar kojeg
nazivamo apsolutnom tolerancijom, odnosno sigurnošću granica CCP.
Načelo 4
Uspostaviti sustav za praćenje kontrole CCP po rasporedima testiranja ili promatranja.
9
Načelo 5
Odrediti korektivne mjere koje se poduzimaju ako sustav praćenja utvrdi da se određena CCP
izmiče kontroli. Korektivne akcije za njihovu provedbu trebaju biti specificirane.
Načelo 6
Uspostaviti procedure za verifikaciju kojima se potvrđuje da HACCP sustav radi učinkovito.
Postupci verifikacije moraju biti razvijeni tako da održavaju HACCP sustav i osiguravaju
učinkovit nastavak rada.
Načelo 7
Napisati dokumentaciju koja se odnosi na sve procedure i zapise vezane za primjenu ovih
načela. Zapisi se moraju čuvati da bi pokazali kako HACCP sustav radi pod kontrolom i da su
odgovarajuće korektivne akcije poduzete za sva odstupanja od kritičnih granica.
Kao što je prije navedeno HACCP nije samostalan sustav. Dobre higijenske prakse i
drugi uvjeti vezani za preradu hrane, kao i jaka predanost menadžmentu su potrebne; HACCP
nije zamjena za njih. Obuka je još jedan jako bitan uvjet za uspješnost sustava. S ciljem
razvoja posebnih obuka koje će podržavati HACCP plan, potrebna je izrada radnih uputa i
procedura koje definiraju zadatke osoblja za svaku CCP. [23]
3.3 ISO 9001 i HACCP u PPK-a
PPK karlovačka mesna industrija d.d. ima certifikate za standarde ISO 9001 i HACCP
te se ti standardi i ispunjavaju u svakodnevnom radu. Standardi su implementirani kroz
potrebnu dokumentaciju, papirologiju i način rada.
Procesi koji su identificirani prilikom uvođenja SUK-a u PPK dijele se u tri grupe:
VODEĆI PROCESI (procesi upravljanja) su:
- planiranje SUK-a
- unutarnje ocjene SUK-a
- analize procesa
- upravna ocjena sustava
- poboljšanje i razvoj procesa
10
GLAVNI PROCESI (procesi realizacije proizvoda) su:
- proizvodnja (svježeg mesa, obarenih, polutrajnih i trajnih kobasica, trajnih
komadnih mesa i polutrajnih suhomesnatih proizvoda)
- prodaja
POMOĆNI PROCESI su:
- planiranje realizacije proizvoda
- nabava
- kontrola i ispitivanje nabavljenih proizvoda
- procesna kontrola
- kontrola gotovih proizvoda
- analiza opasnosti (HACCP)
- sanitacija i higijena pogona
- GMP (dobra proizvođačka praksa)
- skladištenje sirovina i repromaterijala
- skladištenje gotovih proizvoda
- transport
- upravljanje resursima
- upravljanje dokumentima i zapisima
- upravljanje mjerno-ispitnom i procesnom opremom
- upravljanje nesukladnostima
Dokumentacija koju nalažu ISO 9001 i HACCP unutar PPK organizirana je u četiri
razine. U dokumente prve razine: Politika kvalitete, Poslovnik integriranog sustava 11
upravljanja kvalitetom i sigurnošću hrane. U drugu razinu spadaju: Standardni operativni
postupci SUK-a (SOP). Treća razina obuhvaća Radne upute i propise, Norme i specifikacije,
Radne dokumente. Četvrtu razinu čine razni obrasci i formulari. [26]
Poslovnik upravljanja kvalitetom vrhovni je dokument ili dokument prve razine.
Njime su propisani procesi sustava upravljanja kvalitetom (SUK), njihove veze, provedbe i
odgovornosti za provedbu. Standardnim operativnim postupcima (SOP) i radnim uputama
(RU) SUK-a. HACCP plan koji je povezan sa Poslovnikom putem SOP-a HACCP, osnovni je
dokument koji osigurava uvijete za proizvodnju zdravstveno ispravne hrane. HACCP sustav u
potpunosti je integriran u SUK, a veze sa istim definirane su kroz poglavlja PUK-a.
Naravno svi ovi dokumenti se čuvaju i kontroliraju u skladu s propisima ISO standarda.
Sukladno s dokumentima unutar organizacije, provode se unutarnje kontrole, edukacija
zaposlenika, sanitacija tvrtke i ostali zahtjevi norme ISO 9001. Dokaz provedbe zahtjeva su
mnogobrojni formulari koje ispunjavaju QM i od njega ovlaštene osobe. Središnji dokument
HACCP standarda je HACCP plan. U njemu su identificirane sve prijetnje u svim procesima
koji se izvršavaju u PPK. No kako ne bi to ostalo samo na papiru, unutar proizvodnje mjesta
koja su u HACCP planu identificirana kao kritične točke, jasno su označena. Uz svaku
kritičnu točku napisana je i korektivna radnja kako bi radnik znao što mu je napraviti u
slučaju da nešto pođe po zlu.
12
4 .NET
Do izlaska Jave i .NET-a programiranje je bilo kaotično. Postojalo je mnoštvo jezika koji
su imali problema prilikom interakcije jednih s drugim. Razvojni programeri su imali dugu
krivulju učenja prilikom prebacivanje s jednog programskog jezika na drugi ili s jednog tipa
aplikacije na drugi jer nisu postojali standardni načini dizajniranja aplikacija i jer su postojale
velike sintaktičke razlike između jezika. Ovo je samo dio problema.
Ti problemi su se nastojali riješiti različitim standardima koji bi služili kao ljepilo koje će
omogućiti interoperabilnost, jedan od takvih standarda je COM i COM+. No u praksi rad s
ovakvim standardima je bio jako težak i nepraktičan. Osim ovog rješenja rastom aplikacija
pristupilo se rješenju zasnovanom na servisima.
Svi ovi nedostaci doveli su do novog programskog modela koji bi trebao omogućavati:
Da aplikacije budu napravljene kao komponente koje će se moći ponovno koristiti i dijeliti
preko interneta, da potiče razvoj aplikacija kao servisa. Te omogućava istinsku
interoperabilnost između jezika, što znači da kod napravljen u jednom jeziku je moguće
iskoristiti u nekom drugom.
Ovaj model je uspješno implementiran u Microsoftovu platformu - .NET. .NET
pojednostavljuje razvoj aplikacija za internet. Ali .NET je puno više od platforme za razvoj za
internet, ali namijenjen je pretežno za internet jer su sve druge tehnologije tu zakazale.
Prvo izdanje .NET Frameworka predstavljeno je 2002 godine i otad se nadograđuje.
NET pruža alate i biblioteke koje omogućavaju razvojnim programerima da razviju softver za
Windows OS mnogo brže i lakše. Dok s druge strane .NET krajnjim korisnicima omogućava
korištenje aplikacija koje su kvalitetnije, sigurnije i s više mogućnosti od klasičnih aplikacija.
Naravno .NET nije ograničen samo na klasične Windows aplikacije on omogućava i izradu i
korištenje, između ostalog, web aplikacija i servisa.
U ovom poglavlju bit će opisana .NET radna okolina, programski jezik C# te neke
Microsoftove tehnologije poput WPF i WCF-a.
4.1 .NET razvojna okolina
.NET radna okolina sastoji od četiri glavne komponente:
Common Language Specification (CLS)
Framework Class Library (FCL)
Common Language Runtime (CLR)
13
.NET alati
Ove četiri komponente su nabolje predočene na slici (Slika 4-1). Kao što se vidi na slici
dno slike zauzima siva boja tj. operacijski sustav i platforma. U teoriji može biti bilo koji OS,
ali većinom je to Windows operacijski sustav.
Slika 4-1 NET Framework [14]
Poviše operacijskog sustava nalazi se Common Language Runtime (CLR)- žuto na slici
(Slika 4-1).
Najvažnija komponenta .NET Frameworka je CLR koja pruža okruženje za izvođenje
programa. CLR sadrži virtualni stroj koji je u mnogo čemu sličan Java virtualnom stroju. CLR
pruža niz servisa koje aplikacije mogu koristiti da bi pristupile mnogim resursima (poput
nizova, kolekcija itd). [5]
Na višoj razini CLR aktivira objekte, na njima izvodi sigurnosne provjere, pohranjuje
ih u memoriju, izvodi ih i kasnije odlaže u otpad. Pošto CLR "upravlja" izvođenjem koda
takav kod se naziva upravljiv kod (managed code) dok ostali kod je naziva "neupravljiv kod".
[5]
14
Druga komponenta .Net-a je NET biblioteku klasa (FCL) - na slici (Slika 4-1) crvena
boja. Biblioteka je organizirana hijerarhijski u imenske prostore. Klase vezane za ugrađene
API-je nalaze se u System.* ili Microsoft.* imenskom prostoru. Biblioteke obuhvaćaju veliki
broj klasa, kao npr. klase vezane za rad s datotekama, bazama podataka i sl. Dio .NET
biblioteka klasa je Base Class Library (BCL).
Base Class Library (BCL) odnosno set osnovnih klasa, uključuje mali podskup od
cijele biblioteke klasa i glavni je skup klasa koje služe kao osnovni API CLR-a. Klase iz
mscorlib.dll i dio klasa iz System.dll i System.core.dll-a smatraju se da su dijelovi BCL-a.
Framework Class Library (FCL) je nadskup BCL-a i odnosi se na cijelu biblioteku
klasa koja se isporučuje s .NET razvojnom okolinom. Uključuje prošireni skup biblioteka,
uključujući WinForms, ADO.NET, ASP.NET, Language Integrated Query, Windows
Presentation Foundation, Windows Communication Foundation i mnoge druge.
Sljedeća komponenta .NET radne okoline je Common Language Specification (CLS).
Na slici (Slika 4-1) je to zelena boja. CLS je skup pravila koje moraju poštivati jezici da bi se
nazvali CLS jezikom. Na ovaj način je osigurana interoperablinost jezika. Jer svaki jezik koji
poštuje CLS može koristiti i nasljeđivati klase, hvatati iznimke i iskoristiti prednosti
polimorfizma drugog jezika. Interoperablinost jezika može povećati uporabu već postojećeg
koda te na taj način povećati efikasnost razvoja jezika. Prevoditelji koji su u skladu s CLS-om
stvaraju objekte koji mogu međusobno djelovati. FCL može koristiti u potpunosti bilo koji
jezik koji je u skladu s CLS-om.
Uz CLS treba i spomenuti Common Type System (CTS). CTS definira kako se
deklariraju, koriste i upotrebljavaju tipovi u vrijeme izvođenja. Dakle pomoću CLS i
CTS .NET razvojna okolina ostvaruje ugrađenu interoperabilnost jezika.
Zadnja komponenta .Net razvojne okoline su razvojni alati, na slici (Slika 4-1) bež boja. Prije
svega to je Visual Studio. Visual Studio je IDE, integrirano razvojno okruženje koje koristi
sve ove gore navedene komponente kako bi izgenerirao .NET aplikaciju. Dakle Visual Studio
je poput ljepila koje spaja sve te komponente u jednu cjelinu. Najnovija verzija je 2010. Uz
Visual studio tu postoje mnoštvo manjih alata poput IL disassemblera. [5]
4.1.1 Verzije .NET-a
Danas postoje nekoliko verzija .NET-a. Prva verzija je 1.0 nakon nje izdane su 1.1,
2.0, 3.0 i 3.5, te 4.0.
15
Verzija 1.0 , očito, bila je prva verzija .NET-a za operacijske sustave Windows. Izdana
je 2002. Ubrzo, sljedeće godine, izdana je nova verzija 1.1. Ona je bila prva veća nadogradnja
.NET-a. Izdavala se kao dio operacijskog sustava i bila je dio Visual Studia.
Sljedeća verzija bila je 2.0. Izdana zajedno s Visual Studiom 2005. Verzija 3.0 izlazi
2006.godine i već od početka je integrirana u tada novi Microsoftov sustav, Windows Vista.
Nedugo zatim, nakon izlaska Visual Studia 2008, nastaje mala nadogradnja u odnosu na .NET
3.0, verzija 3.5.
Glavne karakteristike ove verzije su:
• Windows Presentation Foundation – novi grafički podsustav baziran na XML-u i
vektorskoj grafici, koja upotrebljava 3D hardversku podršku.
• Windows Communication Foundation
• Windows Workflow Foundation
• Windows CardSpace
• LINQ
• ADO.NET Entity Framework
Danas najnoviji paket Microsoftovog Visual Studia, verzija 2010, u sebi sadrži također
najnoviju inačicu .NET-a, koja je već dosegla verziju 4.0, o kojoj će biti vise riječi u
zasebnom poglavlju, budući da će se aplikacija razvijati u toj verziji. [13]
4.1.2 .NET 4.0
.NET 4.0 je zadnja verzija .NET radne okoline. Izdana je 12. travnja. 2010. Verzija 4.0 je
donijela mnoštvo novosti, kao što su dodane brojne nove klase i imenski prostori, poboljšani
WPF. Dakle ima mnoštvo novosti al ovdje će biti spomenute samo neke najvažnije, a to su:
Windows work flow i WCF 4.0
Dynamic Language runtime
Paralelne ekstenzije
F#
Windows work flow i WCF 4.0 su kompletno redizajnirani. U WCF su dodani
jednostavniji servisi za konfiguraciju, otkrivanje i rutiranje. Dodani su REST poboljšanja i
workflow servisi. Što se tiče samog WWF unijete su temeljite promjene, promijenjen je cijeli
16
programski model. Programski model je postao jednostavniji i robusniji. Te je predstavljena
integracija između WCF i WWF.
Dynamic Language runtime (DLR) je set servisa koji dodaju sposobnost izvođenja
dinamički jezika, kao što su LISP, javasricpt, CLR-u. DLR se naslanja na CLR i omogućava
izvršavanje ovakvih jezika. Do izlaska DLR-a CLR je mogao samo izvršavati statički
tipizirane jezike kao što su C, C++, C#, VB.
Paralelne ekstenzije dodane su u .NET 4.0 kako bi dodale podršku za paralelno računanje
na višejezgrenim sustavima. Također je predstavljen i PLINQ, dodatak za LINQ koji
omogućava paralelno izvršavanje. Dodana je i nova biblioteka TBL koja sadrži paralelne
konstrukcije za petlje, funkcije i delegate. Predstavljen je novi jezik F#. F# je
mulitparadigmatski programski jezik namijenjen .NET radnoj okolini. Obuhvaća
funkcionalno programiranje kao i imperativno i objektno orijentirano. [2]
Slika 4-2 WCF Model [9]
4.1.3 Windows Comunication Foundation
WCF je dio .NET Frameworka za izgradnju i pokretanje povezanih (distribuiranih)
sustava. WCF pruža unificiranu radnu okolinu za izgradnju sigurnih i pouzdanih servisa.
WCF spaja i proširuje mogućnosti distribuiranih sustava, .NET Remoting-a, Web Services i
17
Web Services Enhancements (WSE), za razvoj i distribuciju ujedinjenih sigurnih sustava.
Također omogućava izgradnju labavo poveznih (eng. loosely coupled) aplikacija baziranih na
arhitekturi orijentiranoj servisima koja radi sigurnije i pouzdanije preko različitih platforma.
WCF pojednostavljuje napor pri razvoju servisno orijentiranih aplikacija pri čemu
spaja različite tehnologije potrebne za razvoj kao što su: Enterprise Services,
Messaging, .NET Remoting, Web Services, i WSE. Na taj način se razvoj aplikacija ubrzava
te povećava produktivnost. WCF gradi aplikacije sa programskim modelom baziranim na
atributima. Predstavljen je kao dio .NET-a 3.0. WCF pruža model programiranja baziran na
servisima koji međusobno djeluju jedni na druge pri čemu ne prelaze organizacijske i
platformske granice. WCF podržava velik broj Web servisa kao što su XML, XSD, SOAP,
XPath, WSDL i napredne standarde i specifikacije kao WS-Addressing, WS-Policy, WS-
Security, WS-Trust, WS-Secure Conversation, WS-Reliable Messaging, WS-Atomic
Transaction, WS-Coordination i WS-Policy. Model WCF razvojne okoline najbolje se može
predočiti slikom (Slika 4-2). [9]
Glavne komponente WCF radne okoline prikazane su na slici. (Slika 4-3) Ugovori
(eng. contracts) - sloj ugovora je odmah ispod aplikacijskog sloja. Njega developeri koriste
kako bi razvili servis. Njegovi dijelovi su ugovor podataka (eng. service contract), ugovor
podatka (eng. Data Contract), ugovor poruka (eng. message contract), politike i vezivanje
(policies and binding). Ugovor servisa opisuje operacije koje servis može obaviti. Ugovor
podatka opisuje tip podatka koji se prikazuje klijentu. Ugovor podatka definira tip podatka
koji se šalje i prima servisu. Primitivni tipovi podataka nije potrebno navoditi u ugovoru
podataka jer njihove definicije se nalaza u XML schema definition language dokumentu i
klijent ih može identificirati. Za razliku od njih složene tipove klijent ne može identificirati pa
se koristi DataContract kako bi se obavijestilo klijenta koji tip podatka se šalje i prima od
metode. Više o ugovorima u sljedećem poglavlju.
Zadani format poruka koji se koristi za komunikaciju između klijenta i servera u
WCF-u je SOAP format poruka. Ako to ne zadovoljava potrebe može se napraviti svoj format
poruka. To s može postići korištenjem ugovora poruka.
18
Slika 4-3: Komponente WCF radne okoline [10]
Politike i vezivanje specificiraju uvjete koji su potrebni da bi se ostvarila komunikacija
sa servisom, kao što su sigurnosni zahtjevi, protokol i kodiranje potrebno za povezivanje.
Sloj ispod sloja ugovora je sloj izvršavanja servisa (eng. service runtime). Sadrži ponašanja
koja se mogu dogoditi za vrijeme izvođenja servisa. Najvažnija ponašanja koje se nalaze u
ovom sloju su:
Throttling Behavior- kontrolira koliko se poruka obrađuje.
Error Behavior - specificira što se dogodi kad nastupi greška prilikom izvođenja
servisa.
Metadata Behavior - specificira kako i kad su metapodaci dostupni vanjskom svijetu.
Instance Behavior - specificira koliko se instanci servisa mora napravit za vrijeme
izvršavanja.
Transaction Behavior - omogućava povratak transakcije u slučaju greške.
Dispatch Behavior - Kontrolira način na koji WCF infrastruktura obrađuje poruke.
19
Ispod sloja izvršavanja nalazi se sloj poruka (eng. messaging). Sloj poruka se sastoji od
kanala. Kanal je komponenta koja obrađuje poruku na neki način, npr. autentikacija poruke.
Set kanal poznat je pod nazivom stog kanala (eng. channel stack). Kanali su glavna
apstrakcija za slanje i primanje poruka za krajnje točke (eng. endpoint) Kategoriziraju se u
sljedeće skupine:
Kanale transporta - obavljaju slanje i primanje poruka sa mreže. To su protokoli poput
HTTP, TCP, named pipes MSMQ
Kanale protokola - implementira protokol baziran na SOAP-u, npr. WS-Security i
WS-Reliability
Zadnji sloj WCF-a je sloj Aktivacije i smještaja servisa. Servisi mogu biti smješteni (eng.
hosting) ili izvršeni, tako da budu dostupni klijentu. WCF servis može biti dostupan klijentu
pomoću sljedećih mehanizama [10]:
IIS - Internet information Service pruža mnoštvo prednosti ako se servis koristi http
kao protokol. Ne zahtjeva host kod da bi aktivirao servis, to se radi automatski.
Windows Activation Service-(WAS) je novi proces aktivacijski mehanizam koji se
isporučuje sa IIS 7.9. Uz HTTP baziranu komunikaciju, WCF pomoću WAS-a
mogućava servisa i procesa baziranih na drugim protokolima poput TCP-a.
Self-Hosting - WCF servis može biti smjestiti i aktivirat kao konzolna aplikacija,
WinForms aplikacija ili WPF aplikacija sa grafičkim sučeljem.
Windows Service - WCF može biti smješten i aktiviran kao Windows servis, ali tad je
pod kontrolomService Control Manager-a (SCM).
20
4.1.3.1 Komunikacijski Model
Slika 4-4:komunikacijski model
WCF koristi klijent server model da bi uspostavio komunikaciju između aplikacija. Klijenti
mogu direktno pristupiti servisima kroz krajnje točke (eng. EndPoint) koje servis izlaže za
korištenje. Krajnja točka nije ništa drugo nego definirana lokacija kroz koje se poruke mogu
slati i primate. Servis može imat više krajnjih točaka. Za komunikaciju između klijenta i
servera koristi se SOAP format poruka. No osim njega mogu se koristiti i drugi formati poput
REST, JSON ili WDSL.
Kao što je prije ukratko navedenoWCF sloj ugovora sastoji seod sljedećih glavnih
komponenti:
Ugovor servisa (service contract)
Ugovor operacija (operation contract)
Ugovor podataka (data Ccontract)
Član podatka (data member)
Njihov odnos se najbolje vidi naslici (Slika 4-5) [9]
21
Slika 4-5: Odnos ugovora WCF servisa [9]
Ugovor servisa
Ugovor servisa je ugovor koji specificira smjer i tip poruke u komunikaciji. U WCF
aplikaciji ugovor servisa se implementira kao sučelje ili klasa. Ugovor servisa su ustvari vrata
preko kojih aplikacija koristi operacije servisa i svaki servis bi trebao imati bar jedan ugovor
servisa. Ugovor servisa se definira ovako:
// Student ServiceContract
[ServiceContract]public interface IQcsService
{
// Define the OperationContact here….
}
Gore navedeni atribut ServiceContract sučelja IQcsService definira ugovor servisa.
Ugovor servisa definira koje su operacije dostupne u tom servisu, operacije poput metoda web
servisa. Dakle svaki WCF servis se sastoji od sučelja, u ovom slučaju IQcsService i klase koja
implementira to sučelje. Ako se tom sučelju doda atribut ServiceContract to sučelje postaje
ugovor servisa, a sve metode unutar njega su metode koje servis daje na korištenje vanjskim
aplikacijama. Metode servisa se nazivaju operacije. [9]
Ugovor operacija
Ugovor operacija (eng. operation contract) definira operacije (metode) koje servis daje na
korištenje vanjskoj aplikaciji. Da bi operacija bila dostupna vanjskoj aplikaciji, mora joj biti
22
pridodan atribut OperationContract. I to za svaku operaciju, slično kao i web metodama u
web servisima. [9]
Ugovor operacije se definira na sljedeći način:
// Student ServiceContract
[ServiceContract]public interface IQcsService
{
// Define the Autenticate OperationContact here….
[OperationContract]AutenticationInfo Autenticate(string username, string pass); // Define the GetStudentInfo OperationContact here….
...
[OperationContract]int LoggedIn(string username, string password);
… }
Ugovor podatka
Ugovor podatka (eng. data contract) definira tip sa skupom članova tipa ili poljima
koji će biti upotrebljeni kao složeni podatak u ugovoru servisa. To je labavo spojen (loosely
coupled) model koji je definiran izvan implementacije servisa i moguće mu je pristupiti sa
servisom s neke duge platforme. Da bi definirali ugovor podatka treba primjeniti atribut
DataContract
na klasu i dodati atribut DataMember na polje unutar klase. Na taj način serializator zna
seriliziti klase u xml.
StudentInformation ugovor podatka može se definirati na ovaj način:
23
[DataContract]public class AutenticationInfo{
// Define the Datamembers here….
}
Član podatka (eng. data member) specificira tip koji je dio ugovora podatka, koji se
koristi kao složeni tip ugovora servisa. Da bi se definirao član podatka treba primjeniti
DataMember atribut na polje koje se mora serializirati. DataMember atribut se može
primjeniti i na privatne članove, te će biti serializirani i deserializirani, te će biti dostupni
korisniku i procesu.
DataMember se definira na sljedeći način:
[DataContract]
public class AutenticationInfo
{
[DataMember] public string Name { get; set; } [DataMember] public string Lastname { get; set; } [DataMember] public int UserId { get; set; }
[DataMember] public List<AutenticationOrganisation> Organisation { get; set; }
}
24
4.1.3.2 SOAP, WSDL i UDDI
WSDL (Web Service Description Language) je jezik za opis servisa. to znači da
specificira što servis radi, potrebne formate podataka i protokla, lokaciju servisa i drugo. To je
u suštini XML dokument.
UDDI (Universal Description, Discovery and Integration) omogućava registraciju i
pretraživanje servisa, pristup ESDL dokumentima. Te je neovisan o platformi.
SOAP (Simple Object Access Protocol) Protokol temeljen na XML-u koji omogućava slanje
poruka između pružatelja servisa i klijenta. Koriste ga drugi protokoli poput HTTP-a,
SMTP-a. One je također neovisan o platformi.
Servis prima SOAP poruku od klijenta i vraća SOAP poruku kao odgovor. SOAP
poruka se sastoji od omotnice (eng. envelope) koja ima tijelo i zaglavlje. Zaglavlje je opciono,
sadrži informacije o adresiranju, sigurnosti, transakcijama. Tijelo sadrži podatke poruke. [11]
Evo primjera:
<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:s="http://www.w3.org/2003/05/soap - envelope" >
<s:Header >
</s:Header>
<s:Body >
<ReserveRoom xmlns="http:// www.w3.org /ProCSharp/2010" >
<RoomReservation
xmlns:d4p1="http://schemas.datacontract.org/2009/CSharp.WCF"
xmlns:i="http://www.w3.org/2001/XMLSchema - instance" >
25
<d4p1:EndDate> 2010 – 06 – 21T14:00:00 < /d4p1:EndDate >
<d4p1:Contact> Georg Danzer < /d4p1:Contact >
<d4p1:Event> White Horses < /d4p1:Event >
< /RoomReservation >
< /ReserveRoom >
< /s:Body>
< /s:Envelope>
4.1.4 Windows Presentation Foundation
Windows Presentation Foundation ili WPF je novi grafički podsustav .NET-a.
Predstavljen je zajedno s .NET-om 3.0 i od tada je glavni grafički podsustav .NET-a. Sa
svakom novom verzijom .NET-a WPF se unapređuje i dodaju mu se nove mogućnosti.
Fizički, to je skup .NET sklopova (eng. assembly) i pomoćnih alata. Do izlaska WPF-
a, za prikaz UI koristio se WinAPI i kasnije Windows Forms. Windows Forms pruža
upravljiv omotač (eng. managed wrapper) oko Windows API-ija. Windows Forms su postali
hit jer su omogućili bržu izgradnju aplikacija i sam razvojni programer se mogao koncentrirati
na problem. Za prikaz 3D sadržaja koristio se DirecX i GDI/GDI+.
Upravo zbog ovoga, znači zbog složenosti izrade sučelja i korištenja mnogo alata da bi
se napravilo jedno sučelje predstavljen je WPF. Napravljen je s namjerom da pruži unificirani
API za izradu sofisticiranih korisničkih sučelja za Windows operacijske sustave.
WPF spaja sve dobre stvari iz razvoja za web, kao style sheet i označni jezik za opis
sučelja, animacija i podrška multimediji. Ove komponente su spojene u jednu cjelinu sa
stvarima iz tradicionalnog razvoja za desktop kao što su integracija sa OS i povezivanje
podataka.
U WPF-u ove stvari su poboljšane i unificirane. Osim ovih stvari WPF podržava 3D
crtanje i mnoštvo drugih stvari.
26
WPF aplikacije mogu se razvijati kao desktop i web aplikacije. WPF osigurava jasnu
razliku između korisničkog sučelja (eng. UI) i poslovne logike. Za korisničko sučelje WPF
koristi označni (eng. markup) jezik koji je nastao iz XML-a tzv. XAML (čitaj zammel). [6]
4.1.4.1 Arhitektura
Arhitektura WPF-a (Slika 4-6) sastoji se od dijelova koji pripadaju upravljivom kodu i
neupravljivom kodu. Veći dio pripada naravno upravljivom kodu, ali jedan dio jako bitan
pripada neupravljivom. To je Media Integration Layer ili MIL.
Slika 4-6: WPF arhitektura [15]
Ustvari to je jedini neupravljivi dio i nalazi se u milcore.dll. On se direktno naslanja na
DirectX i služi za integraciju s DirectX-om. Dakle kako se može zaključiti WPF koristi
DirectX za sva iscravanja. MIL osigurava podršku za iscrtavanje 2D i 3D sadržaja animacije.
Media kodaci su također podržani od strane WPF-a i to kroz windowscodacs.dll. Ovaj dll
također pripada neupravljivom dijelu.
Upravljivom dijelu pripada Presentation Core, nalazi se u presentationcore.dll, koji
osigurava omotač (eng. wrapper) za MIL i implementira core servise. Presentation
Framework implementira krajnje elemente UI kao što su animacije, layout i data binding. [12]
4.1.4.2 XAML
Extensible Application Markup Language ili XAML je deklarativan jezik baziran na
XML-u, a koristi se za inicijalizaciju objekata. Prednost XAML-a je u tome što je u
27
potpunosti deklarativan jezik. U deklarativnom jeziku, developer opisuje ponašanje i
integraciju komponenti bez uporabe proceduralnog programiranja. To omogućava nekome tko
ima malo ili nimalo programerskog znanja da kreira cjelokupnu aplikaciju bez programiranja.
Uporabom XAML-a u razvoju korisničkog sučelja omogućava razdvajanje modela i
pogleda, što se smatra dobrom dizajnerskom praksom. XAML se ne koristi samo u WPF već
ga je moguće koristiti i u drugim .NET komponentama kao npr. WWF-u. Naravno i tu se
koristi za definiranje UI.
XAML radi na principu da se elementi mapiraju u CLR objekte, dok se XAML atributi
mapiraju u svojstva (eng. property) i događaje (eng. event) tih objekata. XAML datoteke se
kompajliraju u .baml datoteke i dodaju se kao resurs u .NET sklop (eng. assembly). Za
vrijeme izvođenja CLR ekstraktira .baml, parsira ga, napravi odgovarajuće objekte i vizualno
stablo kojemu se onda može pristupati iz koda.
Znači XAML nije ovisan o WPF, mogu ga koristiti i ostali programi. U WPF-u koristi se
za opis sučelja. Alati koji se koriste XAML za opis sučelja su Visual Studio, Expression
Blend. [12]
4.1.4.3 JednostavnI WPF windows program
WPF program je najlakše napraviti pomoću visual studija. I to tako da se odabere
new project → Wpf Application. Nakon toga Visual Studio će izgenerirati projekt koji sadrži
dvije datoteke: App.xaml i MainWindow.xaml. Svaka od ove dvije datoteke ima code behind
datoteku u kojoj se nalazi programska logika. App.xaml stvara Application objekt te pokreće
naš program koji se nalazi unutar MainWindow.xaml-a. Program će biti jednostavan, sastojat
će se od jednog dugmeta koji se prostire preko cijelog prozora i koji će ispisivati poruku u
prozoru nakon što se klikne na njega.
Xaml datoteka ovako izgleda:
<Window x:Class="WpfApplicationtemp.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="MainWindow" Height="350" Width="525">
28
<Grid> <Button Content="Hello World!!" Name="HelloWorld"
VerticalAlignment="Stretch" HorizontalAlignment="Stretch"
Click="HelloWorld_Click" /> </Grid></Window>
Dakle sastoji se od tri taga: Window, Grid, Button. Svaki tag može imati atribute koji
mogu biti svojstva ili događaji. U ovom primjeru imamo jedan događaj koji je vezan za tag
Button, to je Click. Ovaj događaj ima vrijednost HelloWorld_Click, a to je ime obrađivača
događaja koji se nalazi u tzv.„code behind“ datoteci. Ali o tome malo više kasnije. Tag
Window predstavlja objekt Window tj. prozor programa. U njemu se nalaze dva imenska
prostora.
Jedan je
http://schemas.microsoft.com/winfx/2006/xaml/presentation koji
mapira sve Windows kontrole u System.Windows.Controls. Drugi je
http://schemas.microsoft.com/winfx/2006/xamlkoji definira Xaml tagove.
Grid tag predstavlja grid kontrolu koja služi kao kontejner za druge kontrole. Tj. u nju se
mogu stavljati druge kontrole kao u ovom slučaju Button kontrola. U datoteci
MainWindow.xaml.cs nalazi se logika programa:
using System.Windows;
namespace WpfApplicationtemp{ public partial class MainWindow : Window { public MainWindow() { InitializeComponent(); } private void HelloWorld_Click(object sender,
RoutedEventArgs e) { MessageBox.Show("Hello World!!!"); } }}
29
Kao što se vidi u „code behind“ datoteci nalazi se samo jedna metoda
void HelloWorld_Click
koja je obrađivač događaja (eng. event handler) HelloWorld_Click koji je zapisan u xaml-u.
Unutar metode nalazi se statička klasa MessageBox.Show koja prikazuje jednostavnu poruku
kad se klikne na dugme. Kao što je prije spomenuto imenski prostor
http://schemas.microsoft.com/winfx/2006/xaml sadrži definicije tagova standardnih WPF
kontrola. Ukoliko se koriste ne Microsoftove kontrole potrebno je dodati dodatne imenske
prostore. U ovom diplomskom koriste se DevExpress kontrole. DevExpress su set kontrola za
Windows Forme, ASP.NET, Silverlight, DelphiVCL i WPF. Ove kontrole su komercijalne pa
je u ovom diplomskom je korištena probna verzija. Inače radi se o jako kvalitetnom i dobrom
skupu kontrola koje omogućavaju lakši razvoj aplikacija. Korištene su ove
kontrole:BarManager, RibbonControl, DockLayoutManager, LayoutGroup, NavBarControl.
4.1.5 ADO.NET Entity Framework
ADO.NET Entity Framework je ORM (eng. Object - Relational Mapping) radna
okolina razvijena od strane Microsofta za .NET radnu okolinu. Prije nego se nastavi opisivati
Entity Framework potrebno je objasniti što je to ORM. ORM znači objektno - relacijsko
mapiranje. To je programerska tehnika koja se sastoji on seta klasa koje mapiraju relacijski
model entiteta u objekte specifičnog programskog jezika.
U početku su aplikacije direktno pozivale API-ije baza podataka kako bi mogli
komunicirati sa njima. Na primjer API za oracle baze Pro*C se pozivao da bi se moglo
pročitati ili upisati nešto u Oracle bazu iz C aplikacije. On bi ugrađene SQL naredbe pretvarao
i pozive Oracle biblioteci.
Sljedeći korak u pristupu bazama podataka bio je ODBC (Open Database
Connectivity). On je razvijen sa namjerom da ujedini sve komunikacijske protokole za
različite RDBMS-e. Dizajniran je tako da bude neovisan o programskom jeziku, bazi
podataka i operacijskom sustavu.
Prema tome aplikacija bi mogla komunicirati sa bilo kojom bazom podataka koristeći
isti kod, samo bi trebala promijeniti odgovarajući ODBC upravljački program. Bez obzira da
li se koristio ODBC ili neka druga metoda za pristup bazi podataka ostaje jedan problem.
Podaci koje vrati baza moraju se nekako prikazati u aplikaciji. Ili kao varijabla ili u slučaju
30
današnjih modernih programskih jezika kao klasa. Taj isti set klasa bi se morao ponovno
razviti ukoliko se radi nova aplikacija. Ovaj problem rješava pojava ORM-a. [16]
Korištenjem ORM-a baza podataka se predstavlja sa ORM kontekst objektom, koji je
specifičan za svaki programski jezik. Entiti baze podataka poput tablica su predstavljeni sa
klasama i vezama među tim klasama. Na primjer, recimo da postoje dvije tablice Order i
OrderDetail, koje su međusobno povezane vezom 1 na n. ORM stvara dvije klase koje će
predstavljati te dvije tablice. Isto tako klasa Order će imati i kolekciju koja će sadržavati sve
detalje vezane za nju. ORM isto tako vodi računa o mapiranju i konekcijama između klasa i
baze podataka. Uvođenjem ORM, baza podataka je aplikaciji predstavljena kroz navedene
klase. Aplikaciju ne zanima o kakvoj se bazi radi već samo koristi ove klase kako bi dobavila
ili spremila podatke. Aplikacija se ne mora brinuti kako se spojiti na bazu podataka, kako
napraviti SQL naredbe ili kako upotrijebiti mehanizme zaključavanja (eng. locking
mechanism). O svemu ovom ORM vodi računa.
Slika (Slika 4-7) pokazuje načine kako se može spojiti na bazu. Microsoftova verzija
ORM softvera je Entity Framework. Entity Framework je složena radna okolina i trebalo bi
puno više prostora za opisati je. Zbog toga će biti opisana u kratkim crtama s naglaskom na
programerskom dijelu.
Središnji dio Entity Frameworka je Entity Data Model (EDM). Njega sačinjavaju tri
XML datoteke. Svaka od tih datoteka definira dio modela i baze. Ove datoteke su: Conceptual
Slika 4-7: Načini povezivanja na bazu podataka [16]
31
Schema Definition Language (CSDL), Mapping Schema Language (MSL) i Store
Schema Definition Language (SSDL).
Conceptual Schema Definition Language (CSDL) definira kako se mogu slati upiti na
model sa gledišta aplikacije. Tj. definira klase koje predstavljaju bazu. Dio koji definira
stvaran shemu baze podataka je Store Schema Definition Language (SSDL). SSDL definira
izgled tablica i odnose među njima. Dio koji povezuje ova dva navedena dijela je Mapping
Schema Language (MSL). MSL je odgovoran za mapiranje podataka između CSDL i
SSDL-a. [16]
Ove datoteke imaju svoju strukturu te ih je moguće sam definirati i napisati ručno. No
njih može i izgenerirati Visual Studio te napraviti cijeli model za nas. Takav model je
dobar i dovoljan za ovaj diplomski rad. Zbog toga se neće ulaziti u objašnjavanje
strukture tih datoteka. Detaljniji opis dan je na adresi:
http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework.
Znači Visual Studio izgenerira ova tri dijela u obliku .edmx datoteke. I praktički kad
se to dogodi Entity Data Model je spreman za rad, jer Visual Studio stvara sve potrebne klase
za rad. Među njima je svakako najvažnija klasa koja nasljeđuje objekt ObjectContext. Taj
objekt upravlja sa svim što ima veze sa pristupom podataka. Kao što je stvaranje konekcije,
transakcije, promjene u vezama. Preko ObjectContext-a se vrši upisivanje, čitanje i brisanje
podataka.
Unutar klasa entiteta postoji set svojstava za svaki entitet unutar sustava. Svako to
svojstvo vraća objekt koji je generičkog tipa ObjectQuery<T>, T je tip entiteta. Sam
ObjectQuery je ugrađena klasa koja omogućava izvršavanje upita o spremište podataka koje
je u ovo slučaju baza podataka. Klase naravno imaju svojstva i relacije koje su definirane
putem CSDL-a.
Sljedeće što treba opisati se načini kako postaviti upite na Entity Data Model. Upite je
moguće izvršavati na različite načine, pomoću: Entity SQL, Linq to SQL ili Linq to Entities.
Entity Sql je verzija T-sql kojoj je omogućen rad na Entity Framework-u. Entity Framework
parsira eSQL te ga transformira u T-sql i vrši upite o bazu, Pomoću eSQL-a moguće je
izvršavati samo select naredbe. Puno bolji način pristupa podataka je pomoću Linq to SQL ili
Linq to Entities. Oni koriste ObjectContext objekt za pristup bazi. [16]
32
4.1.5.1 Linq
Linq (Language integrated query) se pojavio sa .NET-om 3.0. Linq omogućava
postavljanje upita sličnih SQL-u u bilo kojem .NET jeziku. Upiti se mogu postavljati na
relacijske baze, kao što je prije navedeno, na XML datoteke i na objekte. Zbog toga postoje
različiti tipovi linq-a. Uz linq povezane su neke nove značajke C# jezika. Kao što su: lamda
izrazi, anonimni tipovi, anonimne funkcije, inicijalizatori, automatska svojstva, var tip...
Ova svojstva neće biti posebno opisana već će biti opisana kako se bude dolazio do
njih na primjeru. Evo jedan primjer linq upita:
var OrgUsers = from worker in databaseEntities.QCS_organzationworker_orgwrk
where worker.id_orgwrk_usr == usr.idusr && worker.IsDeleted == false
select new { worker.id_orgwrk, worker.idorgwrk_dep, worker.idorgwrk_wp, worker.organization_orgwrk };
Svaki linq upit počinje s naredbom from in. U ovo slučaju je to
from worker in databaseEntities.QCS_organzationworke
Ova naredba je slična naredbi foreach, uzima element iz neke kolekcije koja se nalazi
desno od ključne riječi in. Iza ove prve naredbe slijedi druga, a to je
where worker.id_orgwrk_usr == usr.idusr && worker.IsDeleted == false
To je ustvari filter koji ispituje svaki objekt tipa c za neki uvjet. Iza njega slijedi
naredba s kojom završava svaki linq upit. A to je select tj.
33
select new {
worker.id_orgwrk, worker.idorgwrk_dep, worker.idorgwrk_wp, worker.organization_orgwrk };
Ovo je jedina naredba uz order by koja vraća vrijednost. To je nešto kao return
ključna riječ u metodama. Rezultat ovog upita bit će objekt tipa ObjectQuery<T>. Ovdje
treba primijetiti dvije nove stvari. Prva je varijabla tipa var. To ustvari varijabla koja nema tip
već se on nameće od strane kompajlera nakon što on shvati koji se tip nalazi s desne strane.
Dakle varijabla tipa var poprima tip od izraza s desne strane. Ne može biti null, te se mora
inicijalizirati prilikom deklaracije.
Druga novost je
new { worker.id_orgwrk, worker.idorgwrk_dep, worker.idorgwrk_wp, worker.organization_orgwrk };
To je takozvani anonimni tip. Oni se deklariraju sa var varijablama npr.
var p = new {X = 0, Y = 2};
Izrazi unutar vitičastih zagrada su inicijalizatori. Oni kao što ime kaže postavljaju
vrijednosti svojstava na neku vrijednost. Kad su već spomenuta svojstva u .NET-u 3.0
uvedena su automatska svojstva koje nije potrebno pisati, već samo navesti imena i oni se
sami generiraju od strane kompajlera. Kao u primjeru prije:
worker.id_orgwrk, worker.idorgwrk_dep, worker.idorgwrk_wp
34
Ovakvu sintaksu kompajler prevodi u:
var result = databaseEntities.QCS_organzationworker_orgwrk.Where( worker=> worker.id_orgwrk_usr == usr.idusr && worker.IsDeleted == false) .Select( worker => new { worker.id_orgwrk, worker.idorgwrk_dep, worker.idorgwrk_wp, worker.organization_orgwrk });
Kao što se vidi niz metoda s nekim čudnim izrazima. Ti izrazi su lamda izrazi. Oni
nisu ništa drugo nego li kraće i ljepše zapisane anonimne metode. No da se malo proanalizira
jedan lamda izraz:
worker=> worker.id_orgwrk_usr == usr.idusr && worker.IsDeleted == false)
Ovdje je ključan operator =>. Izraz lijevo od njega odgovara listi argumenata metode.
Ako ih ima više oni mogu biti grupirani unutar zagrada. Desno od operatora => odgovara
tijelu metode. Tijelo može imati više izraza u tom slučaju ih se stavlja unutar vitičastih
zagrada. Također može se primijetiti da je korištenje tipa u listi argumenata opciono kao i
return ključna riječ u tijelu lamda izraza.
Dakle ovaj izraz bi se mogao protumačiti kao primjeni lamda izraz na članove
kolekcije u metodama where i select.
35
4.1.6 Managed Extensibility Framework
4.1.6.1 Plugin sustav
Kako aplikacije rastu s vremena na vrijeme sve ih je teže održavati i dopunjavati sa
novim funkcionalnostima. Da bi se omogućilo lakše dodavanje novih funkcionalnosti i
olakšalo održavanje uvode se sustavi dodataka1 (eng. plugin). Dodatak ili plugin omogućava
da se aplikaciji kasnije lako dodaju nove funkcionalnosti. Plugin-ove mogu razvijati izdavači
softvera ali i drugi ukoliko se pridržavaju određenih pravila. Danas sve veće aplikacije
podržavaju sustave za upravljanje plugin-ovima.
U računarstvu, dodatak (eng. plugin) je skup softverskih komponenata koji dodaju
nove mogućnosti većoj softverskoj aplikaciji. Plugin sustav omogućava proširenje
mogućnosti aplikacije bez da se ona izmjeni ili rekompajlira. Osnovna struktura aplikacije
bazirane na plugin-onima prikazana je na slici (Slika 4-8).
Slika 4-8: Shema plug in sustava [19]
Kao što se vidi osnovni dijelovi ovog sustava su aplikacija domaćin2 (Host), sučelje i
samo plugin. Host aplikacija je novisna o plugin-ovima te ne zna kako su oni implementirani i
koliko ih je. Da bi se te komponente mogli komunicirati potrebno je definirati sučelje koje će
bit jednako za sve, dakle svaki plugin ga mora implementirati kako bi ga host aplikacija
mogla koristiti. Host također zna kako sučelje izgleda te pomoću tog sučelja komunicira s 1 Hrvatski naziv dodatak je nepraktičan te će se u radnji koristiti engleski naziv 2 Hrvatski naziv aplikacija domaćin jako je nespretan, zbog toga će se dalje u radu koristiti engleski naziv.
36
plugin-om. Unutar hosta obično se definira plugin upravitelj. On vodi računa o učitavanju i
upravljanju plugin-a. Postoje više tipova plugin upravitelja. Najjednostavniji plugin upravitelj
učitava plugin-ove jednom, prilikom pokretanja aplikacije. I to obično na način da se postavi
jedan direktorij kao plugin direktorij. Plugin upravitelj pretražuje taj direktorij za plugin-ove
koji implementiraju sučelje kojeg je definirala aplikacija. Drugi, napredniji način za
implementiranje plugin sustava omogućava učitavanje i iskrcavanje pluginova za vrijeme
izvođenja aplikacije. To za sobom vuće činjenicu da se plugin-ovi mogu ažurirati bez da se
aplikacija ponovno pokreće. [18]
Ponekad je potrebno da sam plugin koristi mogućnosti host aplikacije. U tom slučaju
host aplikacija definira sučelje koje je dostupno plugin-ovima tzv. sučelje aplikacije.
Sustav plugin-a je može izvesti na tri načina u .NET-u. Prvi način je da sami razvijete
sučelje i host upravitelj pomoću .NET sučelja, kasnog povezivanja i sklopova. To se izvodi na
način da se host aplikacija definira u jednom sklopu, sučelje u drugom, a sam plugin u trećem.
Host aplikacija uz pomoć ugrađenih .NET klasa može dinamički učitati sklop sa plugin-om.
Ovaj način je dobar jer je sučelje definirano u zasebnom sklopu te ga mogu koristiti i drugi
programeri za razvoj aplikacija.
Osim metode da sami razvijete plugin sustav, Microsoft se pobrinuo da napravi radnu
okolinu za plugin-ove. Postoje dvije: MAF i MEF. MAF koristi princip cijevovoda za
komunikaciju s plugin-ovima te je složeniji za uporabu. U ovom diplomskom koristit će se
MEF jer je jednostavniji i zadovoljava potrebe diplomskog.
37
4.1.6.2 MEF
Klase potrebne za rad s MEF-om (Managed Extensibility Framework) definirane su u
System.ComponentModel.Composition imenskom prostoru. MEF je prvi put predstavljen
s .NET-om 3.5. Osnovni dijelovi MEF-a su: dijelovi (eng. parts) i kontejneri (eng. containers).
Dijelovi (eng. parts) su ustvari pluginovi. Oni se definiraju sa atributom Export, kontejner
Slika 4-9: Arhitektura MEF-a [7]
pronalazi dijelove u katalogu (eng. catalog). Katalog pronalazi dijelove unutar nekog sklopa
ili direktorija, Kontejner spaja kod označen s atributom, Import sa kodom označenim
atributom Export i na taj način plugin-ove dostupne host aplikaciji.
Imports i exports su ustvari atributi pomoću kojih katalog pronalazi plugin-ove.
Pružatelj exporta pristupa katalogu i nudi mu exporte koji se nalaze u katalogu. Moguće je
više pružatelja exporta koji su povezani u lanac. Zatim kontejner upotrebljava pružatelje
exporta kako bi ih spojio s importima.
MEF se sastoji od tri kategorije klasa: klase za hosting, primitive i klase za mehanizam
baziran na atributima. U klase za hosting spadaju kontejneri i katalozi. Klase primitiva služe
38
ako želiom napraviti klase koje proširuju funkcionalnosti MEF-a. Te na kraju u klase koje
implementiraju mehanizam baziran na atributima spadaju Export i Import atributi. [7]
Na primjeru opisti će se MEF arhitektura. Radi se o dijelu koda iz plugin-a aplikacije.
Pošto su plugin-ovi dosta veliki opisani su samo dijelovi koda koji su važni da bi se razumjela
plugin arhitektura. Primjer se sastoji od tri sklopa: jedan za host aplikaciju, drugi za sučelje, a
treći za plugin. Prvo će se definirati sučelje kojeg plugin mora implementirati.
namespace IQCSPlugInInterface{ public interface IPlugInInterface { PlugInInfo GetPlugInInfo(); IEnumerable<SidebarItem> GetSidebarInfo();
bool Operate(string operation);
bool GetData(AutenticationInfo info);
bool SetRights(string organisation, string workplace, string name, string lastname, int right); void InitPlugIn(); void ShowToolbar(); }}
Nakon toga je potrebno definirati plugin. On mora implementirati gore navedeno
sučelje:
39
namespace HACCPmodul{[Export(typeof(IPlugInInterface))] public class HACCP : IPlugInInterface, IHostImportInterface {
...
public void InitPlugIn() { settingsUi.HostInterface = Host; HaccpTeamUI.HACCPTeamHostInterface = Host; }
... public void ShowToolbar() { HaccpTeamUI.ShowButtons(); settingsUi.ShowToolbar(); }
... }}
atributom Export definira HACCP klasu kao dostupnu host aplikaciji. Još je potrebno
definirati host aplikaciju:
using System.ComponentModel.Composition;using System.ComponentModel.Composition.Hosting;
...
namespace DXWPFApplication2{public partial class MainWindow : DXRibbonWindow,
IHostInterface, IPlugInmportInterface {
... [ImportMany] public IEnumerable<IQCSPlugInInterface.IPlugInInterface>
PlugInn { get; set; }...
40
void InitializePlugin() {
...var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
catalog.Catalogs.Add(new DirectoryCatalog
var batch = new CompositionBatch();batch.AddPart(this);container.Compose(batch);
//***glavna petlja za loadanje pluginaforeach (IQCSPlugInInterface.IPlugInInterface test in PlugInn){
//grupa modul_modulinfo = test.GetPlugInInfo();_modul = new NavBarGroup();..._sidebaritme = test.GetSidebarInfo();...}...}
Kad se pokrene glavni program pokreće se InitializePlugin metoda. U metodi
InitializePlugin prvo se stvara katalog u kojemu se nalazi popis exporta tj. dodataka. Nakon
toga se stvara kontejner koji sadrži sve plugin-ove koji se nalaze u katalogu. Te nakon toga se
pokreće metoda Compose koja prihvaća kao argumente objekt s definiranim import atributom.
Kako objekt tipa MainWindow ima definiran atribut import moguće ga je poslati kao
argument u metodu. Nakon izvršenja ove metode exporti se mapiraju u importe te ih je
moguće koristiti u program. Kao što se vidi poziva se metoda
_modulinfo = test.GetPlugInInfo();
iz plugin-a kako bi se dobavili podaci o plugin-u.
41
4.1.7 Prevođenje i CIL
Na platformi .NET programi se ne prevode u izvedbene datoteke, oni se prevode u
sklopove (eng. assemblies) koje sadrže Common Intermediate Language (CIL) upute koje
CLR zatim pretvara u strojni kod i izvodi. CIL datoteke koje proizvodi C# gotovo su
identične CIL datotekama koje proizvode ostali jezici podržavani u .NET platformi.
C# kod se prevodi u CIL prilikom izrade projekta. CIL se sprema u datoteku na disku.
Kada pokrenete program. CIL se ponovno prevodi s Just In Time (JIT) prevoditeljem.
Rezultat je strojni kod koji procesor može izvesti. Standardni se JIT prevoditelji pokreću na
zahtjev. Kada se metoda pozove, JIT prevoditelj analizira CIL i proizvodi iznimno učinkovit
strojni kod koji se vrlo brzo izvodi. Dok se program izvodi prevođenje se provodi samo po
potrebi, a jednom preveden kod se sprema u privremenu memoriju da bi se mogao ponovno
upotrijebiti. .NET aplikacije se svakim novim pokretanjem postaju sve brže jer se koristi već
prevedeni kod. Prije navedeni CLS ovdje dolazi do izražaja, tj. CLS znači da svi .NET jezici
Slika 4-10: Postupak prevođenja[13]
42
proizvode sličan kod. To omogućava da se objektima stvorenim u jednom jeziku može
pristupiti i iz drugog jezika. Stoga je moguće osnovnu klasu stvoriti u jeziku VB.NET, a iz nje
izvoditi C#. [5]
4.2 Programski jezik C#
Jezik C# je iznenađujuće jednostavan. Sadrži oko 80 ključnih riječi i desetak ugrađenih
tipova, ali implementira sve moderne programske koncepte. C# pruža svu podršku potrebnu
za strukturirano, objektno orijentirano programiranje. C# je sagrađen na temeljima jezika C++
i Java. U inačici 2.0 dodani su mu i mnogi važni elementi koji su ranije nedostajali, poput
generika i anonimnih metoda.
Verzija 4.0 donosi još neka poboljšanja kao što su: nazivski i opcijski parametri,
podrška za dinamičke tipove, varijanca i COM interoperabilnost.
U središtu svakog objektno orijentiranog jezika je njegova podrška za definiranje klasa i
rad sa klasama. Klase definiranju nove tipove, što omogućava proširivanje jezika kako bi se
bolje modelirao problem koji se pokušava riješiti. C# sadrži ključne riječi za deklariranje
novih klasa, njihovih metoda i svojstava te za implementaciju enkapsulacije (učahurivanja),
nasljeđivanja i polimorfizma – tri stupa objektno orijentiranog programiranja.
U C#-u, sve što je potrebno za deklariranje klase nalazi se u samoj deklaraciji. Definicije C#
klasa ne zahtijevaju posebne datoteke zaglavlja. Uz to, C# podržava novi XML stil
dokumentiranja koji pojednostavljuje izradu dokumentacije.
C# podržava sučelja, koja su poput ugovora s klasom o pružanju usluga koje sučelje
zahtjeva. U C# klasa može nasljeđivati samo iz jedne roditeljske klase, ali može
implementirati više sučelja. Kada implementira sučelje, C# klasa ustvari obećava pružiti
funkcionalnost koje sučelje zahtjeva.
C# pruža i podršku za strukture, tip podatka čije se značenje značajno promijenilo u
odnosu na C++. U C# struktura je ograničeni jednostavan tip koji prilikom instanciranja
manje opterećuje operacijski sustav i memoriju od obične klase. Struktura se ne može
nasljeđivati iz klase niti se iz nje može nasljeđivati, ali struktura može implementirati sučelje.
C# pruža potpunu podršku za delegate kako bi se omogućilo neizravno pozivanje
metoda. U drugim jezicima, poput C++, može se pronaći sličnu funkcionalnost (npr.
pokazivač na metodu), ali delegati su referentni tipovi koji enkapsuliraju metode s posebnim
potpisima i povratnim tipovima.
C# nudi komponentno orijentirane značajke, poput svojstva, događanja i deklarativnih
konstrukcija (kao što su atributi). Komponentno orijentirano programiranje podržava
43
spremište metapodataka u kojem se nalazi kod za klasu. Metapodaci opisuju klasu, zajedno s
njenim metodama i svojstvima, kao i njene sigurnosne potrebe i druge atribute, poput
mogućnosti serilizacije. Prevedena klasa je, dakle, samostojna jedinica. Stoga, okruženju koje
zna pročitati metapodatke i kod klase nisu potrebne druge informacije za korištenje klase.
Ako se koristi C# i CLR, klasi se mogu dodati prilagođeni metapodaci stvaranjem
prilagođenih atributa. Isto tako, metapodaci klase se mogu pročitati s pomoću CLR tipova koji
podržavaju refleksiju.
Prevođenjem koda zapravo stvara se sklopovlje (eng. assembly). Sklopovlje je
kolekcija datotekakoju programer vidi kao jednu dinamički povezanu biblioteku (DLL) ili
izvršnu datoteku (EXE). Na .NET platformi sklopovlje je osnovna jedinica za ponovnu
uporabu, praćenje inačica, zaštitu i razmještaj.
I na kraju treba još napomenuti kako C# daje podršku i za izravan pristup memoriji
pomoću pokazivača u stilu jezika C++. Takav kod se naziva neupravljiv kod i potrebno je
upozoriti CLR sakupljač otpada da ne sakuplja te objekte dok se eksplicitno ne oslobode. [5]
44
5 ARHITEKTURA ORIJENTIRANA SERVISIMA – SOA
5.1 Uvod
SOA (eng. Service-Oriented Architecture) je stil arhitekture koji omogućava stvaranje
aplikacija koje su napravljene na labavoj povezanosti i interoperabilnosti servisa. Ti servisi
međusobno djeluju preko formalnog sučelja koje je neovisno o platformi i programskom
jeziku. Jedan od načina implementiranja SOA su Web Servisi. To je tehnologija koja se
sastoji od kolekcije standarda koji se mogu upotrijebiti za izgradnju SOA aplikacije. Web
Servisi su tehnologija koja je neovisna o proizvođačima i platformi, interoperbilna i
podržavaju je mnogi proizvođači.
SOA je princip dizajniranja softvera bazirana na servisima. oslanja se na servise
dostupne računalnim mrežama kao što su www, tcp...
Arhitektura bazirana na servisima temelji se na labavoj povezanosti. To znači da servisi
i korisnici koji ih koriste su međusobno neovisni za razliku od dosadašnjeg pristupa gdje su
povezani što je karakteristično za objekte.
Da bi neka aplikacija bila nazvana kao SOA potrebno je da zadovolji dva kriterija, a to
su da ta aplikacija koristi servise ili da se ta aplikacija koristi kao servis.
Zašto je došlo do ideje razvoja aplikacija kao SOA aplikacija? Prve aplikacije su pisane
kao monolitne. Postajale su sve složenije i složenije. Te samo pisanje programa postaje
složeno, a iskoristivost postojećeg koda je nedovoljna. Zbog to ga se krenulo u modularno
programiranje kako bi se riješio taj problem. No s tim rješenjem došli su novi problem poput
problema s održavanjem. Sljedeći korak u razvoju aplikacija bilo je objektno programiranje.
Objektno programiranje donijelo je mnogo prednosti, omogućilo je izradu kompleksnih
aplikacija, te bolju iskoristivost koda. No objektno programiranje tako ima neke nedostatke.
Zbog toga je uvedena nova razina apstrakcija za rješavanje kompleksnosti. To je arhitektura
temeljena na komponentama. Takva arhitektura donijela je kvalitetno rješenje za iskoristivost
koda i održavanje softvera. Funkcionalnost cjeline podijeljena je na manje funkcije i te
funkcije su enkapsulirane u komponente.
Arhitektura na komponentama je riješila većinu problema, no razvojem tehnologija
javili su se novi problemi kao što su: integracija aplikacija, različitost platformi, različitost
uređaja, distribuirani softver... [11]
45
Rješenje ovih problema nađeno je u arhitekturi baziranoj na servisima. Par formalnih
definicija SOA:
SOA je informacijska i komunikacijska (ICT) arhitektura koja pruža fleksibilnost
potrebnu za implementiranje elemenata poslovnog procesa i postavljanje potrebne ICT
infrastrukture u obliku sigurnih, standardiziranih komponenti (servisa) koje se mogu
višestruko koristiti i međusobno kombinirati kako bi zadovoljile različite poslovne
procese.
SOA je široko rasprostranjena ICT arhitektura koja se temelji na labavoj povezanosti (eng.
loose coupling), višestrukoj iskoristivosti (eng. reuse) i interoperabilnosti između različitih
programskih i organizacijskih sustava
SOA je aplikacijska arhitektura u kojoj su sve funkcije i usluge (servisi) definirani
pomoću standardiziranog jezika (eng. description language) te posjeduju pristupna sučelja
pomoću kojih se pozivaju s ciljem potpore određenim segmentima s ciljem potpore
određenim segmentima poslovnih procesa. Svaki pristup i interakcija između servisa je
neovisna od interakcija između servisa je neovisna od ostalih interakcija i
komunikacijskih protokola. Budući da su sučelja neovisna o platformama, klijent može
pristupati i koristiti servise s bilo kojeg uređaja, bilo kojeg operacijskog sustava i
programskog jezika.
Neke od važnijih karakteristika SOA su: Podržavanje ineroperabilnosti koja se temelji na
standardima, heterogenost, raspoloživost i fleksibilnost i sigurno upravljanje komponentama.
Važni i pojmovi vezani za SOA-u su:
Servis: Poslovna funkcija koju obavlja davatelj usluga pa potencijalnog korisnika. Servis
prihvaća jedan, dva ili više zahtjeva te nakon obrade vraća isto toliko odgovora i to kroz
standardizirano sučelje. Servisi ne ovise od stanjima drugih funkcija i servis. Tehnologija
korištena za razvoj servisa se smatra nebitnom informacijom. Cilj svakog servisa je postići
željene rezultate za korisnika.
Service Provider: je strana koja kreira servis kao odgovor na zahtjev korisnika, tj.
pružatelj usluge-
Service requestor: je ustvari korisnik servisa koje je dostavio provider. [11]
Orkestracija (eng. orchestration): Sekvenciranje servisa i omogućivanje dodatne logike
potrebne za obradu podataka
46
Stateless: To znači da servis nije ovisan o prijašnjim stanjima, te stanjima drugih procesa.
Discovery (otkrivanje): SOA se oslanja na mogućnost indetificiranja servisa i njegovih
mogućnosti. Postoje direktoriji koji opisuju servise u svojoj domeni.
Binding (povezivanje): Odnos između providera i korisnika je dinamički, što znači da se
uspostavlja pomoću mehanizma za povezivanje u toku interakcije.
Nakon upoznavanja s osnovnim pojmovima SOA arhitekture sljedeće što treba opisati su
komponente koje sačinjavaju SOA-u.
Servis: Servis ima sučelje koje je neovisni o platformi i preko kojeg komunicira s
okolinom. Servisi se mogu dinamički locirati i pozvati te su neovisni o stanjima drugih
procesa.
Opis servis: kao što samo ime kaže opisuje servis navodeći sve detalje o servisu kao što
su: parametri, ograničenja, svrha, način korištenja...
Poruke: Temelj komunikacije SOA-e. Pružatelj usluge i korisnik usluge komuniciraju
izmjenom poruka. Tehnologija koja se koristi za definiranje poruka mora biti neovisna o
platformi. To je većinom riječ o XML-u.
Oglašavanje servisa: je metoda kojom se potencijalnim korisnicima daje opis servisa.
Postoje dvije metode:
Pull - potencijalni korisnik šalje zahtjev za opisom metode.
Push - pružatelj usluga šalje opis potencijalnim korisnicima
(npr. Unicast, Mulitcast)
Otkrivanje servisa: Za otkrivanje servisa koristi se Directory Service. Directory service
kategorizira servise po kriterijima. Na temelju tih kriterija korisnik može pronaći servis
koji mu odgovara. [11]
47
5.2 Model arhitekture orijentirane servisima
SOA logički model sastoji se od šest dijelova: postojećeg sustava, sloja za prijenos
podataka, sloja funkcijskih servisa, sloja poslovnih procesa, sloja poslovnih servisa i
prezentacijskog sloj.
Ovaj model u suštini se bazira na principu arhitekture tri razine (eng. three-tier), a to su
prezentacijska razina, razina poslovne logike i razina podataka. Ovi dodatni slojevi ili razine
služe kao apstrakcijski slojevi kako bi osigurali da glavne razine nisu strogo povezane. Na taj
način se osigurava manja složenost implementacije.
Važno je naglasiti da se logički model ne mora uvijek poklapati sa fizičkim modelom.
Prezentacijski sloj (eng. Presentation layer):
Prezentacijski sloj obuhvaća korisničko sučelje i različite načine implementacije kao što
su windows klijent, web stranica TD.
Sloj poslovnih servisa (eng. Business services layer):
Ovaj sloj predstavlja ugrubljenu sliku poslovnih servisa i na taj način enkapsulira i
apstrahira kompleksnost tehničke implementacije koja se nalazi ispod toga. Ovakva slika
poslovnih procesa jednaka je poslovnim procesima koji nisu vezani za specifičnu softversku
aplikaciju. Ovaj sloj se dalje dijeli na tri dijela, Enterprise Services, Process Services i Event
Services. Više o ovim dijelovima malo kasnije.
Sloj poslovnih procesa (eng. Business process logic layer):
Poslovni procesi se kreiraju, održavaju i izvršavaju u ovom sloju. Ovaj sloj se dijeli na dva
djela:
Sinkronizirani servisi - sinkroni pozivi se baziraju na jednostavnosti i brzini i imaju
ograničenu količinu orkestracije.
Asinkronizirani servisi - asinkroni pozivi mogu sadržavati dugotrajne transakcije ili
orkestracije preko različitih servisa i slojeva
Sloj funkcijskih servisa (eng. Functional services layer): [3]
48
Slika 5-11: SOA Model [3]
Sloj funkcijskih servisa je ulazna točka za sloj za prijenos podataka. Ovaj sloj štiti sloj
poslovne logike od potrebe da zna kako je implementiran sloj ispod. Time se smanjuje
složenost poslovne logike i ona će ostati nepromijenjena sve dok postoji konzistentno sučelje.
49
Sloj za prijenos podataka (eng. Data transport layer):
Ovaj sloj direktno komunicira sa postojećim sustavom kroz niz različitih protokola i
tehnologija. Sloj za prijenos podataka je vrlo složen jer omogućava komunikaciju s različitim
platformama.
Postojeći sustav (eng. Existing systems layer):
Ovaj sloj predstavlja različite postojeće i zastarjele sustave s kojima sloj za prijenos
podataka komunicira.
5.2.1 Tipovi XML servisa
XML servisi su podijeljeni u dvije osnovne kategorije. Te kategorije predstavljaju
servise koji imaju sličnu namjenu i konfiguraciju. Glavna karakteristika korištenja ovih
kategorija je u to što ubrzava i pojednostavljuje razvoj servisa. [3]
Entity Services - predstavljaju jednostavne atomske operacije na entitetu. Entitet u ovom
slučaju može biti jednostavna CRUD operacija.
Activity Services - Upravljaju sa nekoliko Entety servisa kako bi omogućile izvedbu
poslovnih funkcija.
Process services - predstavljaju dugoročne poslovne procese koji uključuju i čovjekovu
interakciju.
Enterprise Services - prestavljaju javne usluge kao Internet/B2B. One zahtijevaju
maksimalnu sigurnost. Isto tako ovi servisi zahtijevaju veću razinu robusnosti i otpornosti.
Infrastructure Services - pružaju česte funkcionalnosti drugim servisima.
Event Services - obavještava pretplatitelje da se neki događaj dogodio. Ovo je alternativa
"pollingu" koji se koristi kad dođe do promjene podataka.
Dominante platforme za razvoj SOA aplikacija su J2EE i .NET iako SOA nije ograničena
na te platforme. [3]
50
6 QUALITY CONTROL SOFTWARE
Quality Control Software (QCS) je softver koji bi trebao omogućiti digitalnu
implementaciju sustava kontrole kvalitete, ISO 9001 i HACCP-a. Iako je aplikacija
zamišljena da podržava cijeli ISO9001 standard, ovdje će biti opisano samo onaj dio vezan za
HACCP. QCS je napravljena kao višerazinska SOA aplikacija. To znači da se sama aplikacija
sastoji od više slojeva tj. razina. QCS, kao i većina višerazinskih aplikacija, se sastoji od tri
sloja: podatkovnog sloja, poslovnog sloja i prezentacijskog sloja. Razlog za ovakvu
arhitekturu je prije svega skalabilnost, u slučaju promjene na aplikaciji podjela na razine može
uvelike olakšati obavljanje promjena bez toga da se te promjene odraze na druge slojeve.
Navedeno je prije da se također radi o SOA aplikaciji. To znači da se aplikacija sastoji od
servera koji nudi neki servis i klijenta koji koristi taj servis. Na serverskoj strani su
implementirana dva sloja: podatkovni sloj i poslovni sloj. U podatkovni sloj se ubraja sav onaj
kod koji ima veze sa upisivanje podataka u bazu i čitanje tih podataka. Poslovni sloj sadrži
svu poslovnu logiku aplikacije te omogućuje komunikaciju s klijentom.
U klijentu je implementiran prezentacijski koji ima zadaću korisniku prezentirati podatke
obrade te omogućiti komunikaciju korisnika s aplikacijom. Za spremanje podataka korištena
je baza podataka, MSSQL Server 2008. U narednim poglavljima bit će detaljno opisana baza,
server i klijent QCS aplikacije.
6.1 Baza podataka
Modeliranje baze podataka pokazalo se kao najteži problem prilikom dizajniranja QCS-
a. Baza podataka je specifična po tome što u njoj mora biti izmodeliran cijeli poslovni sustav,
te u slučaju lošeg modeliranja, dizajn aplikacije može biti težak pa čak i nemoguć. Ovdje će
biti opisan samo jedan veći dio baze tj. sve one tablice koje obuhvaćaju HACCP. Iako je to
samo jedan dio, on je dosta velik pa će biti opisan u nekoliko dijelova. Bazu je najlakše
opisati ako je promatramo kao skup grupa tablica. Među tim grupama tablica, naravno postoje
veze, ali najdirektnija i najuočljivija veza je kroz tablice QCS_organizationworker_orgwrk i
QCS_Action_act. Te dvije tablice su ujedno i najvažnije. Prva tablica predstavlja aktivno
radno mjesto u nekoj organizaciji gdje se koristi HACCP, a druga predstavlja akcije koje
određeno radno mjesto može obaviti nad određenom tablicom. Pošto u HACCP standardu
svaki dokument i svaku akciju je potrebno prvo napraviti pa onda odobriti i izvršiti, ove dvije
tablice su gotovo povezane sa nekom vrstom veze skoro na svaku tablicu u bazi. Dok je
51
QCS_action_act jednostavna, sadrži samo naziv akcije, QCS_organisationworker_orgwrk je
malo složenija. Sastoji se od devet polja. Četiri od ta polja predstavljaju vezu prema
tablicama: QCS_workplace_wp, koja sadrži naziv radnog mjesta, QCS_department_dep,
sadrži odjele organizacije, QCS_user_usr, sadrži popis korisnika sustava tj. organizacije te
QCS_logger_log, koja sadrži popis vremena kad se pojedini korisnik prijavio i odjavio iz
sustava. Dakle po dosad viđenom radnik organizacije sastoji se od više tablica koje su spojene
preko tabliceQCS_organisationworker_orgwrk, gdje jedan zapis te tablice predstavlja jedno
radno mjesto u organizaciji. Iz ovoga slijedi da je moguće da jedan korisnik sustava može
imati više radnih mjesta. Ostala polja tablice QCS_organisationworker_orgwrk su:
reportsTo, koje sadrži primarni ključ tablice reda gdje se nalazi nadređena osoba,
isHACCPTeam, bolean polje koje identificira da li radnik pripada HACCP timu te
isLeaderHACCP, polje koje identificira da li se radi o voditelju HACCP tima. Još su ostala
dva polja za opisati, jedno je id_orgwrk koje predstavlja primarni ključ tablice, a drugo je
organization_orgwrk. Ovo je posebno polje i nalazi se skoro u svakoj tablici, tj. u onim
tablicama kojima je to potrebno. Radi se o polju koje sadrži primarni ključ organizacije i na
taj način definira koje red tablice pripada kojoj organizaciji. Jer je QCS zamišljen da bude
upotrjebljen u više organizacija. To bi bile te dvije tablice. Sad će ukratko biti opisane
pojedine grupe tablica. U prvu grupu tablica spadaju tablice koje opisuju organizaciju, odjele
organizacija te radna mjesta pojedenih organizacija. U tu grupu spadaju tablice:
QCS_organisation_org, QCS_department_dep, QCS_workplace_wp, QCS_phone_ph.
Drugu grupu tablica predstavljaju tablice koje su vezane za dokumente. To su redom
tablice: QCS_document_docs, QCS_revision_rev, QCS_hardcopy_hc, QCS_norm_nrm,
QCS_chapter_ch, QCS_doc_nrm. U treću grupu tablica spadaju tablice koje predstavljaju
procese, analizu rizika i HACCP plan. Iako se ovdje radi o tri različite stvari one su
međuovisne i zbog tog su stavljene u istu grupu. Tablice koje ovdje pripadaju su:
QCS_process_pro, QCS_process_step_ps, QCS_resources_res, QCS_pro_pro,
QCS_pro_res, QCS_risk_analysis_plan_rap, QCS_risk_analysis_process_step_raps,
QCS_hazard_analysis_hs, QCS_HACCP_plan_haccp, QCS_HACCP_process_step_hps.
Zadnja skupina tablica predstavlja tablice koje predstavljaju obrasce. Iako ISO 9001
ima puno više obrazaca, ovdje su implementirane samo one koje imaju veze sa HACCP-om.
Tablice su: QCS_obkk02_kk02, QCS_obpr21_pr21, QCS_obkk01_kk01, QCS__obkk03_kk03,
QCS_obpr14a_pr14a, QCS_obpr06_pr06, QCS_work_order_wo, QCS_obpr07_pr07,
QCS_obtr01_tr01 i QCS_temperature_temp.
52
Slika 6-12: Prva grupa tablica
53
Još treba spomenuti tablice koje su vezane za tablicu QCS_organisationworker_orgwrk.
Jedna od njih je QCS_ToDoList_tdl u kojoj se nalazi popis akcija koje korisnik mora obaviti,
prije spomenuti QCS_logger_log, u koje se nalaze vremena kad se neki korisnik prijavio i
odjavio o sustav te tablica QCS_modul_access_right_mar. QCS sustav bi trebao osigurati da
svatko ne može vidjeti niti mijenjati svaki dio aplikacije. Tj. QCS bi trebao osigurati pristup
pomoću rola. To se u bazi očituje kroz dva tipa tablice.
Jedan je QCS_modul_access_right_mar gdje je za svakog korisnika zapisano pravo pristupa
svakom modulu klijenta. Tri su razine pristupa. 0 korisnik nema pravo pristupa modulu, 1
korisnik može pristupiti modulu, ali ne može mijenjati podatke. 2 korisnik može mijenjati
podatke. Znači u ovoj tablici, za svakog korisnika, jedan red predstavlja pravo pristupa
jednom korisniku. Polja ima koliko i modula u klijentu te svako polje može poprimiti
vrijednosti 0,1,2 ovisno o pravu pristupa za pojedini modul. Drugi tip tablice vezane za pravo
pristupa su tablice naziva QCS_xxx_access_right_xxx. Ove tablice su vezane za svaku
pojedinu tablicu baze i u njoj su definirana prava pristupa korisnika pojedinom retku tablice
za koju je vezan. xxx se odnosi na zadnja tri slova tablice za koju je ova tablica vezana. Ova
vrsta tablica sadrži popis korisnika i njihova prava pristupa određenom redu tablice. Pomoću
Slika 6-13: Tablice vezane za korisnika sustava
54
ova dva tipa tablica osigurano je pravo pristupa unutar aplikacije. Dakle recimo da postoji
korisnik sa pravom pristupa 2 modulu dokumenti. On će moći pristupiti tom modulu., raditi
nove dokumente brisati postojeće, ali ako postoji neki dokument kojem je pravo pristupa
postavljeno na 0 taj ga korisnik neće moći mjenjati. Još je važno spomenuti i notaciju koja se
koristila za označavanje tablica i polja.
Svaka tablica je označena na načina da prva tri slova označavaju aplikaciju, iza njih
dolazi naziv tablice, a nakon naziva skraćenica naziva. Ovi dijelovi su odvojeni podvlakom.
Polja unutar tablice su označena svojim nazivom iza kojeg dolazi skraćenica tablice kako bi
se naglasila pripadnost toj tablici. Jedino primarni ključevi imaju oznaku id iza koje je sljedi
skraćenica tablice. Strani ključevi imaju oznake id iza koje slijedi skraćenica tablice i tablice
na koju pokazuje. Kompletna shema baze nalazi se u prilogu.
Još na kraju mora se spomenuti i tipove korisnika aplikacije i baze. Dva su tipa,
administratori i korisnici. Administratori mogu pristupati svemu dok obični korisnici mogu
pristupati ovisno o svojim pravima. Prilikom instalacije baze dodaje se test organizacija,
odjel, radno mjesto i admin korisnik.
6.2 Server
Prilikom dizajniranja servera glavni preduvjet je bio da bude skalabilan tj. u slučaju
uvođenja novih standarda kontrole kvalitete, da je moguće dodati serveru nove mogućnosti uz
male preinake u kodu. To je postignuto korištenjem WCF servisa. Prednost ovakvog načina je
u tome da ukoliko se želi dodati nove funkcionalnosti jednostavno se napravi novi servis i
priključi se postojećem. Svi servisi se moraju negdje postaviti kako bi ih drugi mogli koristiti.
U slučaju QCS-a servisi se pokreću unutar QCS servera. QCS Server je mala aplikacija
jednostavnog dizajna. Njezina prvenstvena zadaća je pokretanje i zaustavljanje servisa. Što se
tiče samog izgleda aplikacije vrlo je jednostavan: sastoji se od dva gumba, jedan za pokretanje
servera, a drugi za zaustavljanje servera. Aplikacija nije nametljiva te kad se je minimizira
ona se postavi u programskoj traci (eng. system tray) i tu obavlja svoju zadaću. Logika
aplikacije je također jednostavna. Sastoji se od toga da se metodom
InitService();
inicijalizira WCF servis ili servisi. Te ovisno o tome da li se klikne na gumb start ili stop
pokreće se servis. Inicijalizacija servisa obavlja se kroz nekoliko koraka. Prvo se inicijalizira
55
ServiceHost objekt koji se nalazi u imenskom prostoru System.ServiceModel. Njemu se kao
argument šalje tip servisa tj. sučelje servisa. Nakon toga se definira EndPoint tj. krajnja točka
preko koje klijent može komunicirati s servisom. U EndPoint metodi definiraju se ABC
servisa. Tj. Adresa servisa, zapisana je u app.config datoteci te se može mijenjati po potrebi.
B označava način komunikacije (eng. binding), za QCS odlučeno je da će se koristiti
netTcpBinding jer će se aplikacija koristiti unutar jedne organizacije tj. mreže. I na kraju C,
označava ugovor odnosno njime se definira sve operacije i podaci koji su na raspolaganju
klijentu. I to je to sad jedino što treba napraviti je pokrenuti ili zaustaviti servis.
Iz ovog se vidi kako je lako dodati nove mogućnosti postojanoj aplikaciji, samo treba
definirati novi servis unutar servera. Ne treba se mjenjati postojani servis. Za potrebe
diplomskog razvijen je QCSservice servis koji pruža sve metode potrebne klijentu vezane za
HACCP. Servis se sastoji od dva dijela: QCSDataBaseModel-a i samog servisa.
QCSDataBaseModel je Entity Framework model i predstavlja podatkovni sloj aplikacije.
Slika 6-14 Prozor server aplikacije
Više o Entity Frameworku je bilo riječi ranije. Prednost QCSDataBaseModel je u
tome što ga sam razvojni alat izgenerira na temelju postojeće baze. On sadrži objekte koji
predstavljaju tablice baze te se sam brine o komunikaciji s njom. Ovo je dobar princip jer
56
nigdje nije korišten SQL kako bi se pristupilo podacima već je to napravljeno poznatom
sintaksom C# i LINQ-a kao da se pristupa bilo kojem drugom objektu. Dio podatkovnog sloja
i cijeli poslovni sloj implementirani su unutar dvije datoteke koje predstavljaju QcsService.
To su IQcsService.cs i QcsService.cs. Unutar IQcsService.cs datoteke kao što se može
pretpostaviti definirano je sučelje servisa i tipovi podataka koje će servis primati i slati. Ovo
se sučelje koristi prilikom definiranja krajnjih točaka. Metode i tipove podataka također ćemo
podijeliti u grupe kako bi bilo lakše pratiti. Prvu grupu predstavljaju metode i tipove koji su
vezane za opće stvari vezane za servis. Operacije koje se tu ubrajaju su:
Tablica 6-1: Prva grupa operacija
AutenticationInfo Autenticate(string username, string pass);
bool IsServiceAvailable();int LoggedIn(string username, string password);
bool LoggedOff(int logID);SuperVisor GetSupervisor(int workplaceId);
List<Task> GetTasks(int workPlaceId);
Tipovi podataka koji tu ubrajaju:
Tablica 6-2: Tipovi prva grupe
AutenticationInfoAutenticationOrganisationAutenticationWorkPlace
AutenticationUserAccessRightSuperVisor
Task
Operacije
SuperVisor GetSupervisor(int workplaceId);
i
57
List<Task> GetTasks(int workPlaceId);
imaju zadaću osvježavanja početnog ekrana klijenta sa novim podacima. Više o početnom
ekranu bit će kad se bude opisivao klijent. Za sad operacija GetSupervisor na temelju
vrijednosti primarnog ključa radnog mjesta dobavlja podatke o radnikovoj nadređenoj osobi,
tako da on u svakom trenutku zna kome se može obratiti kad mu nešto zatreba. Dakle klasa
Supervisor sadrži podatke o korisnikovu šefu. Operacija GetTasks dobavlja sve zadaće koje
korisnik mora obaviti. Ove informacije dobiva iz tablice QCS_ToDoList_tdl. Klasa Task se
sastoji od tri elementa: Opisa radnje, predloženog datuma izvršenja i modula u kojem se ta
radnja treba obaviti.
Operacija
AutenticationInfo Autenticate(string username, string pass);
prima kao argumente korisničko ime i lozinku, provjerava da li postoji ti podaci u bazi
te ako postoje vraća objekt tipa AutenticationInfo koji sadrži sve podatke potrebne klijentu da
se pokrene. Ukoliko ne naiđe na te podatke u bazi vraća null referencu. AutenticationInfo
objekt sačinjavaju sljedeći elementi. Ime i prezime korisnika, njegov primarni ključ u tablici
te lista objekata tipa AutenticationOrganisation. Objekt tipa AutenticationOrganisation
predstavlja organizacije u kojima je korisnik prijavljen kao radnik. Elementi
AutenticationOrganisation su ime organizacije i lista objekata tipa AutenticationWorkPlace.
Tip AutenticationWorkPlace predstavlja radno mjesto korisnika unutar organizacije. Elementi
tipa AutenticationWorkPlace su primarni ključ radnog mjesta, naziv radnog mjesta, primarni
ključ tablice QCS_modul_access_right_mar, te objekt tipa AutenticationUserAccessRight.
AutenticationUserAccessRight je ustvari objekt koji sadrži tip Dictionary<> u kojem su
spremljeni par ključ i vrijednost. Ključ u ovom slučaju je ime modula, a vrijednost razina
pristupa. Dakle AutenticationInfo sadrži sve podatke koji su potrebni da bi se identificiralo
korisnika, a to su ime, prezime, sve organizacije u kojima radi i sva radna mjesta koja obavlja.
Operacija IsServiceAvailable samo provjerava da li je servis pokrenut. Vraća true ako je false,
ako nije. Sljedeće dvije operacije odnose se na praćenje korisnika u sustavu. Prva operacija
int LoggedIn(string username, string password);
58
zapisuje vrijeme u tablicu QCS_logger_log kad se korisnik logirao u sustav, vraća vrijednost
primarnog ključa tog zapisa. Druga operacija
bool LoggedOff(int logID);
na temelju vraćene vrijednosti ključa zapisuje vrijeme kad se korisnik odjavio iz sustava.
Sljedeća grupa operacija i tipova odnosi se na modul organizacija. Operacije koje
ovdje pripadaju su:
Tablica 6-3: Operacije modula organizacija
List<Organisation> GetOrganisations();List<string> GetAllDepartments();List<string> GetAllWorkplaces();
bool UpdateOrganisation(Organisation updateOrganisation);
bool UpdateDepartment(Department updateDepartment);bool UpdateWorkplace(DepartmentWorkPlace workPlace);
bool DeleteDepartment(Department department);bool DeleteWorkplace(DepartmentWorkPlace workPlace)
Tipovi:
Tablica 6-4: Tipovi vezani za modul organizacija
OrganisationPhone
DepartmentDepartmentWorkPlace
Operacija
List<Organisation> GetOrganisations();
vraća listu tipa Organisation. Tip Organisation predstavlja organizaciju tj. se atribute koji se
nalaze u tablici QCS_organisation_org, a to su vrijednost primarnog ključa, ime organizacije,
adresu organizacije, elektronička pošta i web stranica. Uz ova polja objekt tipa Organisation
59
sadrži i listu tipa Phone i listu tipa Department. Tip Phone predstavlja telefone organizacije.
Pošto se radi o listi moguće je zaključiti da organizacija može imati više telefona. Tip
Department predstavlja odjel organizacije. Elementi tipa Department su DepartmentId koji
sadrži vrijednost primarnog ključa, DepartmentType koji sadrži informaciju o tipu odjela,
DepartmentTitle sadrži ime odjela te dvije liste. Jedna je kao i kod tipa Organisation, Phone
predstavlja popis svih telefona, a druga je DepartmentWorkPlace koja predstavlja radno
mjesto koje se nalazi u pojedinom odjelu. Kao što vidimo radi se o klasama koje su dosta
slične grupi Autentication klasa. Operacije
bool UpdateOrganisation(Organisation updateOrganisation);
bool UpdateDepartment(Department updateDepartment);
bool UpdateWorkplace(DepartmentWorkPlace workPlace);
osvježavaju podatke u tablicama QCS_organisation_org, QCS_phone_ph,
QCS_department_dep i QCS_workplace_wp. Koriste prije opisane klase. Grupe klasa
namijenjenih za brisanje podataka
bool DeleteDepartment(Department department);
bool DeleteWorkplace(DepartmentWorkPlace workPlace);
su specifične po tome što one ustvari ne brišu podatke iz tablice, već postavljaju polje
isDeleted tablice u true čime obavještavaju server da ubuduće ne koriste te retke tablice tj. da
ih vodi kao obrisane. Razlog zbog čega je ovo napravljeno je u tome što većina obrazaca
mogu biti ispunjena ili odobrena od korisnika i odjela koje već ne postoji. Ukoliko bi ih
obrisali više ne bi imali zapisa o tome tko je te obrasce ispunio. Na ovaj način ne gubi se
podaci vezani za pojedine obrasce.
Sljedeća skupina operacija i klasa pripadaju modulu korisnici. Tu se ubrajaju ove
operacije:
Tablica 6-5: Operacije koje pripadaju modulu korisnici
List<UserOrganisation> GetUsers();int AddUser(UserWorkPlace wp);
60
bool DeleteUser(UserWorkPlace deletewp);bool UpdateUser(UserWorkPlace wPloa);
bool UpdateAccessRights(AutenticationUserAccessRight accessRight, int orgwrk);
Tablica 6-6: Tipovi modula korisnici
UserOrganisationUserDepartmentUserWorkPlace
Operacija GetUsers kao što je za i pretpostaviti dobavlja se korisnike sustava. Ona
vraća listu tipa UserOrganisation koja predstavlja organizaciju, odjele i korisnike te
organizacije. UserOrganisation klasa je slična klasama Organsation i
AutenitacationOrganisation. Klasa koja je specifična za ovu grupu je UserWorkPlace. Ona
sadrži sve podatke vezane korisnika te organizacije, poput naziva radnog mjesta, imena
prezimena itd.
int AddUser(UserWorkPlace wp);
bool UpdateUser(UserWorkPlace wPloa);
bool DeleteUser(UserWorkPlace deletewp)
su jako slične operacije jer koriste istu klasu kao argument. AddUser dodaje novi
zapis u tablicu QCS_organisationworker_orgerk, UpdateUser osvježava te podatke, a
DeleteUser briše podatke postavljajući element tablice IsDeleted u true. U ovoj grupi klasa
preostaje još samo za opisati operaciju
bool UpdateAccessRights(AutenticationUserAccessRight accessRight, int orgwrk);
Kad se doda novi korisnik dodaje se i novi zapis u tablicu
QCS_modul_access_right_mar sa vrijednostima 0. To znači da taj korisnik nema pravo
pristupa niti jednom dijelu aplikacije. Ukoliko mu se želi omogućiti pristup potrebno je
pozvati operaciju UpdateAccessRights koja će na temelju vrijednosti u klasi
AutenticationUserAccessRight postaviti prava pristupa za tog korisnika. Klasu
61
AutenticationUserAccessRight smo prije opisali, a drugi element je vrijednost primarnog
ključa korisnika. Pomoću toga se točno odredi kojem se korisniku želi omogućiti prava.
Operacije koje su potrebne HACCP modulu su:
Tablica 6-7: Operacije Haccp modula
List<HaccpDocs> GetHaccpMeeting(int orgId);bool UpdateHaccpMeeting(HaccpDocs hd);bool AddHaccpMeeting(HaccpDocs hd);bool DeleteHaccpMeeting(HaccpDocs hd)
List<Norms> GetNorms();List<HaccpTeam> GetHaccpTeam();
bool SetHaccpTeam(List<HaccpTeam>);HaccpSettings GetSettings();
Bool SetSettings(HaccpSettings);List<Process> GetProcess(int org);
List<RiskAnalysis> GetRiskAnalysis(int org);bool SetRiskAnalysis(RiskAnalysis);
bool DeleteRiskAnalysis(RiskAnalylsis);List<HaccpPlan> GetHaccpPlan(int org);
bool SetHaccpPlan(HaccpPlan);bool UpdateHaccpPlan(HaccpPlan);bool DeleteHaccpPlan(HaccpPlan)
Tipovi koji idu uz prije navedene operacije su:
Tablica 6-8: Tipovi Haccp modula
HaccpDocsNorms
HaccpSettingsHaccpTeam
RiskAnalysisHaccpPlan
62
Zadnja skupina klasa obuhvaća operacije i klase vezane za obrasce. Tu spadaju
operacije:
Tablica 6-9: Operacije modula obrasci
NewForm(Form form);bool UpDate(Form form);
bool DeleteForm(Form form);
Te o veliki skup klasa koje predstavljaju pojedini obrazac. No jedna klasa je svima
zajednička. Radi se o kontejner klasi Form. Ona se sastoji od dva elementa. Prvi element
opisuje o kojem se obrascu radi, a drugi element tipa object sadrži klasu koja predstavlja taj
obrazac. Naravno kao što možemo vidjeti klasu obrasca potrebno je pretvoriti u objekt te
kasnije na serveru je pretvoriti natrag u originalni tip. Da nije ovako napravljeno bilo bi
potrebno napraviti po tri nove operacije za svaki obrazac. U svrhu diplomskog implementiran
je jedan obrazac pod nazivom OB-KK-02 – kontrolnik temperature. On je predstavljen
pomoću tri klase: KK02Record, KK02Action i RecordAccessRight. KK02Record predstavlja
jedan zapis. Elementi tog zapisa su prostorija, vrijeme, opis, lista akcija i prava pristupa.
Svaka akcija koja se primjenjuje na obrazac predstavljena je klasom KK02Action koja
nasljeđuje klasu Action. Pod akcijom se podrazumijeva izrada, odobravanje i verificiranje.
Prema tome KK02Action sadrži naziv akcije, datum akcije i odgovornu osobu. Klasa
RecordAccessRight se sastoji od rječnika kojemu je ključ vrijednost primarnog ključa tablice
QCS_organisationworker_orgwrk, a vrijednost pravo pristupa tj. 0,1,2.
Kao što je prije navedeno sve ove klase i operacije deklarirane i definirane su u dvije
datoteke, QcsService.cs i IQcsService.cs. U QcsService nalazi se implementacija svih
operacija, dok se deklaracija operacija i tipova podataka nalazi u IQcsService.cs. Ove dvije
datoteke praktički sačinjavaju servis QCS aplikacije, a taj servis se pokreće i održava unutar
server aplikacije QCSserverComponent.
6.3 Klijent
Sljedeći sloj aplikacije je prezentacijski sloj. On prezentira sadržaj korisniku i
omogućuje korisniku da interakciju sa sustavom. Prezentacijski sloj QCS-a je klijent
aplikacija. Ona je zamišljena kao aplikacija sa plugin-ovima koja bi trebala sadržavati
različite plugin-ove koji bi trebali obavljate različite funkcije. Svaki plugin bi trebao pružati
63
neke od funkcionalnosti koje zahtijevaju standardi za kontrolu kvalitete ISO 9001 i HACCP.
Zamišljeno je da postoje deset plugin-a koji bi trebali u potpunosti enkapsulirati kontrolu
kvalitete. Za potrebe ovog rada razvijena su četiri dodatka: organizacija, korisnici, haccp, i dio
obrazaca, više o njima kasnije. Ovakav način razvijanja programa je uzet u obzir prije svega
jer je preglednije i lakše razvijati aplikaciju, a drugi razlog je taj što se standardi za kontrolu
kvalitete mijenjaju i dopunjavaju pa na ovakav način je lakše dodati nove i izmijeniti
postojeće funkcionalnosti.
QCS klijent sastoji se od dva WPF prozora. Prvi prozor je prozor za prijavu. U njemu
korisnik upisuje svoje korisničko ime i lozinku. Prozor za prijavu kontaktira server preko
operacije
Autentacate(string username, string pass);
U slučaju da takav korisnik ne postoji log in prozor obavještava o grešci i ponovno
omogućava unos. Ukoliko takav korisnik postoji server vraća objekt tipa AutenticationInfo
kojeg prozor za prijavu prosljeđuje prozoru MainWindow koji je ustvari aplikacija domaćin3
(eng. plugin host).
Da bi uopće mogli razviti plugin sustav potrebno je definirati sučelje kojeg će dijeliti
dodatak i host aplikacija. Sučelje koje mora implementirati dodatak definirano je unutar
datoteke IQCSPluginInterface.cs. Metode koje sadrži to sučelje su
: PlugInInfo GetPlugInInfo();
IEnumerable<SidebarItem> GetSidebarInfo();
bool Operate(string operation);
bool GetData(AutenticationInfo info);
bool SetRights(string organisation,string workplace;string name, string lastname, int right);
void InitHost();
void ShowToolbar();
3 Hrvatski naziv je jako nespretan pa će se koristiti engleski ekvivalent
64
Metoda GetPlugInInfo dobavlja objekt tipa PlugInInfo. Tip PlugInInfo sadrži opće
informacije o dodatku kao što su naziv, verzija opis i ikona. Inače svi tipovi koje koriste
dodaci i host aplikacija definirani su unutar posebne biblioteke koja se zove TypeLibrary. Na
ovaj način ukoliko netko želi razvijati za QCS svi tipovi su dostupni ako se biblioteka doda u
projekt. Sljedeća metoda je GetSidebarInfo. Ova metoda vraća kolekciju tipa SidebarItem.
Slika 6-15: Forma za prijavu
Više o tipu SidebarItem će biti riječi kasnije kad bude opisivalo sučelje MainWindow-a.
Za sad dosta je reći kako SidebarItem sadrži informacije potrebne host aplikaciji kako bi
nacrtala elemente koje su potrebni plugin-u. Pomoću metode Operate; host aplikacija pokreće
akcije u plugin-u. Koju će akciju pokrenuti ovisi o argumentu metode koji je tipa string. Vrstu
akcije i način na koji će biti implementirana metoda Operate u potpunosti ovisi o dizajneru
plugin-a. Naziv akcije nalazi se unutar klase tipa SideBarItem. Metoda GetData bi trebala
imati funkcionalnost osvježavanja podataka unutar dodatka na temelju objekta tipa
AutenticationInfo. InitPlugIn metoda ima ulogu dodatne inicijalizacije plugin-a ukoliko cijelu
inicijalizaciju nije moguće obaviti u konstruktoru plugin-a. Metoda ShowToolbar omogućuje
dodatku da kontrolira koja će se dugmad pojaviti u alatnoj traci. Osim sučelja preko kojeg
host aplikacija komunicira sa plugin-om, ukoliko se ukaže potreba da dodatak koristi neke
metode hosta potrebno je napraviti novo sučelje koje će te metode otkriti dodatku. U slučaju
QCS hosta to je sučelje IHostInterface. Metode ovog sučelja su:
65
bool RefreshData();
bool SetFocus(string module);
CurrentUser GetCurrentUser();
i svojstvo
QcsService.IQcsService ServiceClient { get; }
Metoda RefreshData kao što samo ime kaže osvježava podatke unutar host aplikacije.
SetFocus metoda stavlja određeni plugin kao aktivni unutar host aplikacije, ovisno o
argumentu. GetCurrentUser omogućava plugin-u da sazna koje je trenutno aktivno radno
mjesto i organizacija unutar host aplikacije. Podaci o tome nalaze se u klasi CurrentUser.
CurrentUser kao i svi ostali tipovi definiran je unutar TypeLibrary biblioteke. Svojstvo
ServiceClient omogućava dodatku da komunicira sa serverom. Naime preko ovog svojstva
host otkriva operacije servera. Dakle host aplikacija vodi računa o komunikaciji s serverom a
pomoću IHostInterface otkriva operacije koje su dostupne dodatku. Osim ova dva sučelja koja
definiraju komunikaciju između plugin-a i host-a postoje još dva sučelja koja su potrebna da
MEF obavi spajanje plugin-a sa host-om i host-a sa plugin-om.
To su IPlugInmportInterface i IHostImportInterface. IPlugInmportInterface sadrži
svojstvo
IEnumerable<IQCSPlugInInterface.IPlugInInterface> PlugInn { get; set; }
kojeg će MEF, o MEF-u je bilo govora ranije, spojiti sa plugin-om koje implementira sučelje
IQCSPlugInInterface.IPlugInInterface, a sučelje IHostImportInterface sadrži svojstvo
IHostInterface Host { get; set; }
kojeg će MEF spojiti sa host-om koji implementira sučelje IHostInterface.
66
Osim sučelja koje definira komunikaciju između host aplikacije i dodatka potreban je
nekakav upravitelj koji će upravljati s učitavanjem i upravljanjem plugin-a. No da bi se
razumjela struktura i način rada upravitelja dodataka4 (eng. plugin manager) potrebno je
razumjeti vizualni izgled host aplikacije, jer je plugin manager ovisan o njoj.
Slika 6-16: Početna stranica QCS klijenta
Sučelje host aplikacije izgrađeno je pomoću DevExpress kontrola. To je set profesionalnih
kontrola koji omogućava brzu i laku izgradnju složenih sučelja. To je glavni razlog korištenja
tih kontrola. Izgled host aplikacije definiran je u datoteci MainWindow.xaml. Glavni element
unutar xmal datoteke je BarManager. On je kao korijenski tag i svi ostali tagovi se nalaze
unutar njega. On se sastoji od dva glavna dijela: BarManager.Items i DockPanel.
BarManager. Items je ustvari kolekcija elemenata koji se pojavljuju i koriste unutar
BarManager-a. Oni se mogu koristiti kasnije bilo gdje unutar xaml-a ukoliko se definira link
na njih. Elementi mogu biti DevExpress kontrole napravljene za rad s BarManager-om.
Većinom su to kontrole koje odgovaraju standardnim WPF kontrolama. Drugi dio
BarManagera je tag DockPanel. Kao što ime kaže unutar ovog taga mogu se smjestiti drugi
tagovi odnosno kontrole. DockPanel pozicionira elemente, koji se nalaze unutar njega, u
prozoru. DockPanel sadrži tri taga: RibbonControl, RibbonStatusBarControl,
DockLayoutManager. RibbonControl je tag koji predstavlja Ribbon toolbar kontrolu.
4 Također će se koristiti engleski ekvivalent u daljnjem teksu
67
RibbonControl ima mnogo svojstava, jedno svojstvo je ApplicationMenu gdje se definiraju
linkovi na prije definirane BarManagerItem elemente. Tagovi koji se mogu naći unutar
RibbonControl-a su RibbonDefaultPageCategory, RibbonPage, RibbonPageGroup. Ovi
tagovi sačinjavaju stranice Ribbon radne trake i oni će biti korišteni od strane upravitelja
dodataka za iscrtavanje gumbova koji su potrebni plugin-u. RibbonDefaultPageCategory
predstavlja standardnu kategoriju stranice radne trake. Ukoliko je potrebno mogu se definirati
i druge kategorije. Unutar kategorije nalazi se tag ili skup tagova RibbonPage koji
predstavljaju stranicu trake s alatima. Svaka stranica sastoji se od jedne ili više grupa,
RibbonPageGroup. Te grupe sadržavaju poveznice prema BarManagerItem elementima. Ovi
tagovi sačinjavaju stranice Ribbon radne trake i oni će biti korišteni od strane plugin manager-
a za iscrtavanje gumbova koji su potrebni plugin-u.
Drugi tag unutar DockPanel taga je RibbonStatusBarControl. Ovaj tag "zakačen" je za
dno prozora. On sadrži dvije poveznice na BarManagerItem tagove, tj. na dva combobox-a.
Treći, a ujedno i najvažniji element je DockLayoutManager.
Ova kontrola služi za postavljanje izgleda. Njezini djeca tagovi su dva LayoutGroup
taga. Prvi LayoutGroup tag sadrži navigacijsku kontrolu NavBarControl, a drugi LayoutPanel
tag gdje bi se trebalo učitavati korisničko sučelje plugin-a.
Posebno zanimljiv tag je tag koji predstavlja NavBarControl. Svaka NavBarControl kontrola
može imati jednu ili više NavBarGroup, svaka NavBarGroup jednu ili više NavBarItem.
Upravo NavBarControl sa svojom djecom poslužit će upravitelju dodataka za pristup
pojedinim dodacima.
Sad kad je opisan izgled stranice može se objasniti i način rada upravitelja dodataka.
Pošto se izgled sastoji host aplikacije sastoji od ribbon radne trake, navigacijske kontrole koja
je smještena na lijevoj strani središnjeg dijela koji bi trebao sadržavati korisničko sučelje
došlo se do ideje da se napravi set klasa koji bi trebao opisati izgled i funkcionalnosti gumba u
radnoj traci i plugin manager bi ih trebao znati pročitati i u skladu s tim i izvesti. Isto tako
svaka grupa NavBarControl kontrole bi trebala predstavljati jedan plugin, a kontrole unutar
nje dijelove dodatka. Prema tome sve informacije koje plugin manager pročita iz plugina
trebali bi se spremiti u NavBarControl kontrolu. I ovisno o tome koji se modul odabere u
NavBarControl kontroli to bi se sučelje iscrtalo LayoutPanel i gumbi dodali u radnu traku.
Ukratko plugin manager učita dodatak i spoji ga sa jednom grupom unutar NavBarControl
kontrole, ovisno na koji se dodatak klikne upravitelj dodacima iscrta potrebno korisničko
68
sučelje i gumbe te postavi zadana prava pristupa. Plugin manager se sastoji od nekoliko
metoda:
void InitializePlugin();
SetRights();
ShowModule_Click(object sender, EventArgs e);
private void Action_ItemClick(object sender, ItemClickEventArgs e);
bool EnableDisable(string page, bool enable);
bool EnableDisable(string page, string group, bool enabl
e);
bool EnableDisable(string page, string group, string but
Metoda InitializePlugin kao što ime kaže pretražuje zadani direktorij te inicijalizira
dodatke. Metoda prvo iz objekta tipa AutenticationInfo popunjava dva combobox-a
vrijednostima. Jednoga, vrijednostima dostupnih organizacija a drugoga dostupnim radnim
mjestima. Nakon toga uz Pomoć MEF radne okoline svojstvu PlugInn, koje vraća
IEnumerable<IQCSPlugInInterface.IPlugInInterface>, pridružuje plugin-ove. Nakon više ili
manje uspješnog pridruživanja foreach petljom se prolazi kroz kolekciju, i za svaki dodatak u
kolekciji stvara se jedna grupa i jedan element te grupe u NavBarControl kontroli. Pošto
standardna NavBarItem kontrola nije bila dovoljno dobra, napravljena je nova kontrola koja
nasljeđuje NavBarItem kontrolu i dodaje joj nekoliko novih svojstava i metoda. Dodatna
svojstva su:
public FrameworkElement UI { get; set; };
public List<ToolbarPage> GetToolbarPage { get; set; };
public int AccessRight { get; set};
69
FrameworkElementUI svojstvo sadrži referencu na korisničko sučelje plugin-a,
AccessRight sadrži pravo pristupa tog plugina-a na temelju kojeg će kasnije metoda SetRights
postaviti prava nad ostalim elementima u dodatku. GetToolbarPage svojstvo sadrži listu klasa
koje opisuju radnu traku i stranice unutar radne trake i gumbe unutar stranice. Ove klase su:
ToolbarPage, ToolbarPageGroup, ToolbarButton. One su također definirane u TypeLibrary
biblioteci. ToolbarPage sadrži podatke o imenu stranice, kategorije kojoj pripada listu
objekata tipa ToolbarPageGroup. ToolbarPageGroup klasa sadrži ime grupe i liste objekata
tipa ToolbarButton. ToolbarButton klasa sadrži ikonu, ime gumba i akciju koju gumb obavlja.
Slika 6-17 HACCP Modul
Osim ovih svojstava NavBarItemExtend, kako je nazvana klasa koja nasljeđuje
NavBarItem, ima i tri događaja (eng. event). doAction, setRights i refreshData. Ovim
događajima se pridodaju metode:
bool Operate(string operation);
GetData(AutenticationInfo info):
bool SetRights(string organisation, string workplace, string name, string lastname, int right)
70
iz plugin-a. Te će uz pomoć ovih događaja NavBarContol kontrola i EditBarButton
kontrola moći pokretati metode plugin-a.
Nakon što se InitPlugin metoda prošeta kroz sve elemente svojstva PlugIn i postavi
elemente NavBarControl kontrole pokreće se druga metoda upravitelja dodataka, a to je
SetRights;. Nakon njezinog izvršenja postavlja se početna stranica host aplikacije, ali o njoj
više kasnije. Natrag na SetRights metodu. Ova metoda prvo očitava koja je organizacija i
radno mjesto aktivno. Nakon tog prolazi kroz objekt tipa AutenticationInfo i pronalazi radno
mjesto. Nakon toga svakoj grupi NavBarControl kontrole postavlja vrijednost polja
AccessRight na pravo pristupa za selektirano radno mjesto. Ukoliko je pravo pristupa nula
onemogućuje tu grupu, ukoliko je jedan postavlja 1 kao pravo pristupa svakom elementu te
grupe i poziva metodu
SetRights(barEditItemLocation.EditValue.ToString(); barEditItem4.EditValue.ToString(), _info.Name, _info.Lastname, 1);
kako bi to isto napravio i plugin.
Sljedeća metoda se poziva svaki put kad se klikne na neki element NavBarControl
kontrole. To je ShowModule_Click metoda, a ona je ustvari obrađivač događaja (eng. event
handler) na događaj Click NavBarItemExtend objekta. Ova metoda na temelju Liste objekata
tipa ToolbarPage koje sadrži selektirani NavBarItemExtend iscrtava grupe radne trake i
gumbe. Te gumbima postavlja svojstva kao što su pravo pristupa i naziv akcije te pridodaje
obrađivač događaja Action_ItemClick; koji bi trebao obrađivati Click događaj gumba.
Naravno originalna klasa BarButtonItem nije zadovoljavala potrebu pa je zbog toga
napravljena klasa koja je nasljeđuje, BarButtonItemExtend. Ona ima dva dodatna svojstva
string GetAction { get; set; } koje opisuje akciju koju gumb obavlja i int AccessRight{ get;
set; } koje sadrži pravo pristupa gumbu. Tri preopterećene metode EnableDisable omogućuju
plugin-u da odlučuje koji će se dijelovi alatne trake prikazati a koji ne.
Zadnja metoda koja sačinjava upravitelj dodataka je
void Action_ItemClick(object sender, ItemClickEventArgs e);
Ova metoda je ustvari obrađivač događaja svih gumba u radnoj traci. Metoda prvo
provjerava da li korisnik ima pravo izvršiti akciju, to radi tako što provjeri svojstvo
71
AccessRight. Ako ima dovoljnu razinu prava pristupa pokreće metodu Operate, a argument
dobiva kao svojstvo BarButtonItemExtend objekta.
Slika 6-18: Tab Dokumenata unutar HACCP modula
Ove metode, kao što je rečeno prije, ove metode sačinjavaju plugin manager, koji je
središnji dio host aplikacije. Još je vrijedno spomenuti kako postoji posebna grupa unutar
NavBarContol kontrole koja se zove „Home“. Ona predstavlja početnu stranicu host
aplikacije. Početna stranica je zamišljena tako da korisnika obavijesti o tekućim akcijama koje
mora napraviti te mu omogućava da vidi tko mu je nadležna osoba. Početna stranica je
napravljena kao korisnička kontrola koja se instancija u host aplikaciji. Home kontrola se
sastoji od dvije manje korisničke kontrole, Boss kontrole i liste ToDoItem kontrole. Boss
kontrola pruža informacije o nadležnoj osobi, a ToDoItem predstavlja jednu akciju koju
korisnik mora obaviti. Boss Kontrola se sastoji od tri textbox-a koji predstavljaju radno
mjesto, ime i kontakt podatke nadležne osobe. ToDoItem se sastoji od dvije label kontrole u
kojima piše datum akcije i opis te gumba koji kad ga se klikne odnosi korisnika u
odgovarajući modul. InitHome metoda inicijalizira home kontrolu na zadane vrijednosti.
Metoda poziva operaciju servera GetTask koja na temelju vrijednosti primarnog ključa tablice
QCS_organisationworker_orgwrk dobavlja podatke iz tablice QCS_ToDoList_tdl. Nakon što
dobavi podatke metoda ih ubacuje u listu čiji su objekti tipa ToDoItem. Jedina preostala
72
metoda Host aplikacije koju je vrijedno spomenuti je InitConnection. Njezina zadaća
uspostava komunikacije s serverom. To radi na način da definira krajnju točku komunikacije,
EndPoint i na temelju tog EndPoint-a otvara komunikacijski kanala uz pomoć metode
_qcsServiceClient = ChannelFactory<QcsService.IQcsService>.
CreateChannel(new NetTcpBinding(), endPoint);.
Kao što se može vidjeti koristi tcp protokol za komunikaciju. Opisom InitConnection
metode gotov je opis host aplikacije, ona još sadrži nekoliko obrađivača događaja koji su
potrebni da bi aplikacija mogla raditi. Od njih najvažniji su
private void barEditItemLocation_EditValueChanged(object sender, RoutedEventArgs e);
private void barEditItem4_EditValueChanged(object sender, RoutedEventArgs e);
Ove metode su obrađivači događaja dva combobox-a koji se nalaze u statusnoj traci
host aplikacije. Jedan sadrži popis organizacija u kojima radi korisnik, a drugi popis radnik
mjesta koje korisnik obavlja unutar organizacije. U većini slučajeva jedan korisnik se nalazi
unutar jedne organizacije i radi na jednom radnom mjesto no ima slučajeva gdje to nije tako.
Zbog toga su postoje ova dva combobox-a koji bi trebalo omogućiti lakše snalaženje
korisnika. Inicijalno aplikacija postavlja prvu organizaciju kao aktivnu te prvo upisano radno
mjesto kao aktivno radno mjesto. U slučaju da korisnik želi to promijeniti on jednostavno
odabere ono što želi iz combobox-eva. Ako se odabere druga organizacija pokreće se
barEditItemLocation_EditValueChanged obrađivač događaja. On jednostavno prođe kroz
popis organizacija unutar objekta tipa AutentictionInfo, i kad pronađe organizaciju, njezina
radna mjesta učita u combobox koji predstavlja popis radnih mjesta, te postavlja prvo radno
mjesto kao inicijalno. To radi tako da popuni svojstvo EditValue nazivom tog radnog mjesta.
Kad se postavi EditValue svojstvo okida se događaj koji pokreće obrađivač događaja
barEditItem4_EditValueChanged. Pošto svako radno mjesto nema isti pristup modulima
barEditItem4_EditValueChanged ima zadaću postaviti početnu stanicu kao aktivni modula,
zatim postaviti prava pristupa ostalim dodacima te to sve iscrtati. To postiže tako da pokreće
metode SetRights, ShowModule_Click i InitHomePage.
73
Host aplikacija sve svoje postavke sprema u app.config datoteku. Te postavke
uključuju, direktorij dodataka, adresu servera. Da bi se spriječilo korisnika da piše po
app.config datoteci Host aplikacija ima mali prozor s postavkama gdje korisnik može
promijeniti direktorij plugin-a. Ovom prozoru se pristupa preko File izbornika host aplikacije.
Ovim je u potpunosti opisana host aplikacija koja može primati dodatke koji implementiraju
IQCSPlugInInterface.IPlugInInterface i IQCSPlugInInterface.IHostImportInterface sučelje.
6.4 Moduli
QCS sustav je zamišljen kao sustav od 10 plugin-a tj. modula od kojih svaki obavlja neku
funkcionalnost: organizacija, korisnici, dokumenti, procesi, auditi, preduvjetni program,
nesukladnost, haccp, edukacija, obrasci. Za potrebe diplomskog rada razvijene su četiri
plugina: Organizacija, Korisnici, Haccp i jedan mali dio obrazaca.
Dizajn samog plugin-a, kako je prije navedeno, u potpunosti ovisi o dizajneru al plugin mora
imati implementirana sučelja IQCSPlugInInterface.IPlugInInterface i
IQCSPlugInInterface.IHostImportInterface. Međutim navedeni plugin-ovi su implementirani
na isti način. Svaki dodatak se sastoji od jedne .cs datoteke i jedne ili više .xmal datoteka. cs
datoteka bi trebala implementirati sučelja plugin-a. U njoj bi se trebao definirati broj i izgled
gumba plugina, informacije o pluginu te broj "poddodataka", te metode GetPlugInInfo,
GetSidebarInfo, InitPlugIn, Operate, GetData, SetRights, Host. Datoteka .cs svakom
"poddodatku" pridodaje instancu .xmal datoteke. Dakle .cs datoteka se ponaša kao kontrolna
datoteka koja upravlja s plugin-om.
6.4.1 Modul Organizacija
Modul Organizacija je dizajniran po gore navedenm načinu. Dakle sastoji se od jedne cs
datoteke gdje je implementirano IpluginInterface. U njemu se definirani svi gumbi i
„podmoduli“ modula. Unutar dodatka instancirani su korisničke kontrole koje predstavljaju
korisničko sučelje dodatka. Ovaj modul omogućava dodavanje novih organizacija, odjela i
radnih mjesta.
6.4.2 Modul Korisnici
Modul korisnici je jako slično dizajniran kao prije navedeni modul Organizacija. Korisničko
sučelje mu je napravljeno pomoću tab kontrole. Ovaj modul omogućava uvid u odjele i radna
mjesta organizacije. Također omogućava dodavanje i brisanje korisnika te trenutni uvid u broj
74
korisnika koji koriste sustav. Važno je napomenuti da ovaj i prethodni modu su dostupni samo
administratorima.
6.4.3 Modul HACCP
HACCP modul je najvažniji u cijeloj priči. Njegova je primarna zadaća omogućiti korisniku
uvid u procese, analizu rizika te izradu HACCP plana. Modul se sastoji od nekoliko
„podmodula“. HACCP Tim, Procesi, Analiza rizika, HACCP Plan i postavke. HACCP tim
omogućava izbor ljudi koji sačinjavaju HACCP tim, omogućava spremanje i pregledanje
izvještaja sa HACCP sastanka te pregled dokumenata HACCP politike.
6.4.4 Modul Obrasci
Modul obrasci zamišljen je tako da ima onoliko“podmodula“ koliko ima odjela u organizaciji.
Za potrebe ovo rada napravljen je samo jedan „podmodul“, a to je proizvodnja. Unutar svakog
„podmodula“ nalaze se digitalizirani obrasci. Digitalizirani su pomoću tab kontrole. Svaki tab
predstavlja jedan obrazac. Pošto ima mnogo obrazaca u ovom radu je obrađen samo jedan radi
primjera.
75
7 ZAKLJUČAK
Kontrola kvalitete bitan je element u svakoj organizaciji koja se bavi proizvodnjom i
preradom hrane. Ona dokazuje ozbiljnost neke organizacije i otvara put za suradnju s drugim
organizacijama. Naime ukoliko neka organizacija posjeduje neki od standarda za kontrolu
kvalitete prije će ostvariti neku poslovnu suradnju nego organizacija koja je nema. Kontrola
kvalitete isto tako daje sigurnost kupcima prilikom kupnje proizvoda. ISO organizacija je
definirala niz standarda za kontrolu kvalitete. Oni su svi obuhvaćeni oznakom 9000, a među
njima je najpopularniji ISO 9001 standard. Integralni dio ISO 9001 standarda je i HACCP.
Odnosno standard za sigurnost hrane. Prilikom uvođenja HACCP, na tradicionalan način,
stvara se mnoštvo dokumenata koji dodatno opterećuju zaposlene. Kao dokaz provođenja
HACCP standarda nastaju mnoštvo obrazaca. Dakle stvara se golema količina dokumenata tj.
papira koja samo otežava rad.
Tu nastupa računarstvo, odnosno aplikacije. Osnovna zadaća aplikacije za kontrolu
kvalitete i sigurnosti hrane je olakšanje izrade plana aktivnosti i smanjenje opsega
dokumentacije te kroz jednostavno sučelje olakšanje uvođenja i provođenja HACCP
standarda. To je ujedno i glavna zadaća QCS aplikacije. Aplikacije je napravljena i predstoji
implementacija kod korisnika.
76
8 LITERATURA
[1] SriSamp (2003), “What is .NET”, s interneta :
http://www.codeproject.com/KB/dotnet/netbasics.aspx, zadnji pristup: 2011-04-27
[2] Shivprasad koirala (2009), “.NET 4.0 FAQ Part 1” -- The DLR, s interneta:
http://www.codeproject.com/KB/dotnet/DOTNETre4pt0.aspx,
zadnji pristup: 2011-05-15
[3] Dave Oliver (2006), “SOA Logical Model”, s interneta:
http://geekswithblogs.net/SabotsShell/archive/2006/07/11/84708.aspx,
zadnji pristup: 2011-08-10
[4] Arnon Rotem-Gal-O, “What is SOA anyway?”, s interneta:
http://www.rgoarchitects.com/Files/SOADefined.pdf, zadnji pristup: 2011-08-10
[5] Jesse Liberty (2002), “Programming C#, Second Edition”, O'Reilly Media, Inc.,
978-0-596-00309-8
[6] Jesse Liberty (2003),”Programming C#, Third Edition”, O'Reilly Media, Inc.,
978-0-596-00489-7
[7] Christian Nagel, Bill Evjen, Jay Glynn, Karli Watson, Morgan Skinner (2010),
“Professional C# 4 and .NET 4”, 978-0-470-50225-9, Canada
[8] Joseph Albahari, Ben Albahari (2010), “C# 4.0 in a Nutshell, Fourth Edition”,
O’Reilly Media, Inc., 978-0-596-80095-6
[9] Deepthi Viswanathan Nair (2008),”A Windows Communication Foundation (WCF)
Overview”, s interneta; http://www.codeproject.com/KB/WCF/WCFOverview.aspx,
zadnji pristup: 2011-08-16
[10] Mike Thom (2011), “WCF Architecture”, s interneta:
http://www.codeproject.com/KB/WCF/WCFArchitecture.aspx,
zadnji pristup: 2011-08-17
[11] Igor Tomičić, Biljana Žarković, Nikola Rebernik (2006),
“ARHITEKTURA TEMELJENA NA SERVISIMA”, s interneta:
ftp://ftp.foi.hr/nastava/el_poslovanje/SOA/SOA%20(2).pdf, zadnji pristup: 2011-8-20
[12] Link group (2008), “Pojam i arhitektura WPF-a, uvod u Xaml”, s interneta:
http://www.linkelearning.com/dlmaterijali/materijali/DLWPF/sadrzajNJpdf/
WPF_01.pdf, zadnji pristup: 2011-6-26
77
[13] Wikipedia, “NET Framework”, s interneta:
http://en.wikipedia.org/wiki/.NET_Framework, zadnji pristup:2011-05-15
[14] Wilson Mar, “MS dot Net Architecture”, s interneta:
http://wilsonmar.com/msdotnet.htm, zadnji pristup: 2011-09-11
[15] WindowsClient.NET (2009), “WPF Application Quality Guide”, s interneta:
http://windowsclient.net/wpf/white-papers/wpf-app-quality-guide.aspx,
zadnji pristup: 2011-09-11
[16] Mike Liu (2011), “LINQ to SQL: Basic Concepts and Features”,s interneta:
http://www.codeproject.com/KB/linq/LINQtoSQLBasic.aspx,
zadnji pristup: 2011-08-26
[17] Amro Khasawneh (2007), “Understanding LINQ (C#)”, s interneta:
http://www.codeproject.com/KB/linq/UnderstandingLINQ.aspx,
zadnji pristup: 2011-08-26
[18] Halil ibrahim Kalkan (2011), “A Simple Plug-In Library For .NET”, s interneta:
http://www.codeproject.com/KB/macros/SimplePlugInLibrary.aspx,
zadnji pristup: 2s011-08-27
[19] Wikipedia, “Plug-in (computing)”, s interneta: http://en.wikipedia.org/wiki/Plug-
in_(computing), zadnji pristup: 2011-08-27
[20] Vesna Žerja, “Osnovni elementi sustava upravljanja kvalitetom u proizvodnji
lijekova”, s interneta: http://www.kvaliteta.net/kvaliteta/radovi/Zzerjav.pdf,
zadnji pristup: 2011-09-10
[21] Marko Mesarić(2011), “Ukratko o normi ISO 9001”, s interneta:
http://zastita.com.hr/index.php?
option=com_content&view=section&layout=blog&id=131&Itemid=478, zadnji
pristup: 2011-09-10
[22] Gumhalter Karolyi, L. (2005) „Primjena programskog rješenja u implementaciji
HACCP sustava“, s interneta:
http://www.kvaliteta.net/hrana/radovi/Gumhalter_Karolyi_L_rad.pdf, zadnji pristup:
2011-04-11
[23] International trade centre: „An introduction to HACCP“, s interneta:
http://www.intracen.org, zadnji pristup: 2011-05-10
78
[24] Wikipedia: „Hazard analysis and critical control points", s interneta:
http://en.wikipedia.org/wiki/Hazard_analysis_and_critical_control_points,
zadnji pristup: 2011-04-11
[25] Hrvatski-izvoznici: „HACCP standard“, s interneta: http://www.hrvatski-
izvoznici.hr/?FlashID=13270&LanguageID=-1,
zadnji pristup: 2011-04-11
[26] PPK karlovačka mesna industrija d.d. (2009), „POSLOVNIK INTEGRIRANOG
SUSTAVA UPRAVLJANJA KVALITETOM I SIGURNOSTI HRANE“
79
9 PRILOZI
9.1 Kazalo slika i tablica
9.1.1 Kazalo slika
Slika 4-1 NET Framework [14]................................................................................................14
Slika 4-2 WCF Model [9].........................................................................................................17
Slika 4-3: Komponente WCF radne okoline [10].....................................................................19
Slika 4-4:komunikacijski model...............................................................................................21
Slika 4-5: Odnos ugovora WCF servisa [9]..............................................................................22
Slika 4-6: WPF arhitektura [15]................................................................................................27
Slika 4-7: Načini povezivanja na bazu podataka [16]..............................................................31
Slika 4-8: Shema plug in sustava [19]......................................................................................36
Slika 4-9: Arhitektura MEF-a [7].............................................................................................38
Slika 4-10: Postupak prevođenja[13]........................................................................................42
Slika 5-1: SOA Model [3].........................................................................................................49
Slika 6-1: Prva grupa tablica.....................................................................................................53
Slika 6-2: Tablice vezane za korisnika sustava.........................................................................54
Slika 6-3 Prozor server aplikacije.............................................................................................56
Slika 6-4: Forma za prijavu.......................................................................................................65
Slika 6-5: Početna stranica QCS klijenta..................................................................................67
Slika 6-6 HACCP Modul..........................................................................................................70
Slika 6-7: Tab Dokumenata unutar HACCP modula................................................................72
9.1.2 Kazalo tablica
Tablica 6-1: Prva grupa operacija.............................................................................................56
Tablica 6-2: Tipovi prva grupe.................................................................................................57
Tablica 6-3: Operacije modula organizacija.............................................................................58
Tablica 6-4: Tipovi vezani za modul organizacija....................................................................59
Tablica 6-5: Operacije koje pripadaju modulu korisnici..........................................................60
Tablica 6-6: Tipovi modula korisnici.......................................................................................60
Tablica 6-7: Operacije Haccp modula......................................................................................61
Tablica 6-8: Tipovi Haccp modula...........................................................................................62
Tablica 6-9: Operacije modula obrasci.....................................................................................62
80
9.2 Popis oznaka i kratica
HACCP Hazard Analysis Critical Control Point
SUK Sustav Upravljanja Kvalitetom
ISO International Organization for Standardization
WPF Windows Presentation Foundation
WCF Windows Communication Foundation
CLS Common Language Specification
FCL Framework Class Library
CLR Common Language Runtime
BCL Base Class Library
LINQ Language Integrated Query
CTS Common Type System
WWF Windows Workflow Foundation
VB Visual Basic
SOAP Simple Object Access Protocol
WDSL Web Services Description Language
REST Representational State Transfer
JSON JavaScript Object Notation
UDDI Universal Description, Discovery and Integration
GDI Graphics Device Interface
XML EXtensible Markup Language
XAML Extensible Application Markup Language
81
MIL Media Integration Layer
UI User Interface
ORM Object-Relational Mapping
ODBC Open Database Connectivity
API Application Programming Interface
EDM Entity Data Model
CSDL Conceptual Schema Definition Language
MSL Mapping Specification Language
SSDL Store Schema Definition Language
MAF Managed Add-in Framework
MEF Managed Extensibility Framework
CIL Common Intermediate Language
JIT Just-in-time
COM Component Object Model
SOA Service-Oriented Architecture
WWW World Wide Web
TCP Transmission Control Protocol
ICT Iinformation And Communication Technology
J2EE Java 2 Platform Enterprise Edition
82
9.3 Ostali prilozi i dodaci
9.3.1 Prilog 1. Shema Baze
83
9.3.2 Prilog 2. Osobna evidencija
84
9.3.3 Specifikacija Zahtjeva
Zatraženi su sljedeći zahtjevi od strane naručitelja, PPK M.I. Karlovac, za aplikaciju QCS:
Korisnički ZahtjeviGlavini korisnički zahtjev je digitalizacija postojeće implementacije ISO9001 i HACCP
standarda u tvornici PPK M.I. Karlovac. A to podrazumljva sljedeće zahtjeve:
Zaštita od neovlaštenog pokretanja aplikacije Dodavanje, mjenjanje i brisanje korisnika/radnika Kontrola pristupa Izrada izvještaja nad svakom komponentom Dostupnost aplikacije i svih njenih djelova Mogućnost ispisa svih izvještaja Digitalizaciju dokumenata tj. dodavanje, mjenjanje i brisanje dokumenata Kontrola svih dokumenata te refernciranje s ostalim dokumentima. Pristup dokumentima ovisno o pravima pristupa Modeliranje procesa i određivanje koraka procesa Dodavanje, brisanje i mjenjanje procesa Mogućnost izrade plana audita i praćenja njegove provedbe Mogućnost izrade plana edukacije i praćenja provedbe Izrada plana sanitacije i održavanja Mogućnost prijave nesukladnosti i plana riješavanja nesukladnosti Izrada analize opasnosti Izrada HACCP plana Imenovanje HACCP tima Digitalizacija što većeg broja obrazaca Grafička analiza Trenutni uvid u hierarhiju organizacije
Sistemski Zahtjevi
TehnologijeZa izradu aplikacije koristit će se Microsoftove tehnologije i to:
.NET i C# kao jezik za izradu same aplikacije SQL Server kao relacijska baza podataka u kojoj će biti spremljeni svi podaci.
Hardverski zahtjeviTeba osigurati računalo s konfiguracijom:
Procesor: 1GHz
85
RAM: 512 MB
HDD: 40
DirectX 10 grafička kartica
Brza veza s internetom
Na računalu treba biti instaliran .NET 3.0 ili više kako bi aplikacija mogla ispravno raditi.
9.3.4 Plan Projekta
86
9.3.5 Pivis Zapisnici
PPK
Zapisnik 28.03.2011 Karlovac
SASTANAK JE SAZVAO
Jurica Grgičević
NAMJENA SASTANKA
Upoznavanje s tvrtkom i procesima u proizvodnji
SUDIONICI
Jurica Grgičević, Ivan Lažeta, Tomislav Knapić, Tomislav Žubčić, Robert
Filipović, Mirela Miljak
Upoznavanje tvrtke i procesa u tvrtci
RASPRAVA
Predstavljanje tvrtke, informacijskog sustava i procesa proizvodnje
ZAKLJUČCI
Nakon dolaska u postrojenje , upoznali smo se sa dvojicom informatičara Tomislavom i
Tomislavom, koji su bili naši domačini. Prvo su nas upoznali sa dijelovima postrojenja tj.
Upravom, proizvodnjom i ostalim zgradama. Nakon toga jedan od Tomislava zadužen za
upravljanjem ERP-om upoznao me je sa njihovim rješenjem CSB sustavom, dok je drugi
Tomislav upoznao kolegu Lažetu s mrežnom infrastrukturom. Moje zapažanje je kako oboje
imaju kvalitetno znanje i razumljevanje o sustavu i procesima koji se odvijaju u proizvodnji.
To zaključujem na temlju njegovog objašnjavanja rada proizvodnje i na temlju work flow
87
dijagrama kojeg je sam sastavio, a koji opisuje proces u proizvodnji. Taj dijagram nam je
mnogo pomogao u razumjevanju procesa proizvodnje.
Nakon kratkog uvoda kojeg su nam kolege pokazale krenuli smo prema prozvodnji. Tamo su
nas dočekali Robert Filipović
i Mirela Miljak. Oni su nas malo detaljnije uputili u proces proizvodnje i opisali nam ulogu
HACCP-a i ISO 9001 standarda.
Iz toga smo zaključili da je nemoguće digitalizirati jedan standard bez drugoga.
Što se tiče Roberta i Mirele, radi se o vrlo sposobnim ljudima koji znaju svoj posao, ali uz to
znaju i tehnologiju te shvaćaju njezinu važnost u olakšavanju svakodnevnog rada.
Bili su nam, a i bit će od velike pomoći.
KORACI KOJE TREBA PODUZETI ODGOVORNA OSOBA KRAJNJI ROK
SASTAVIOJurica Grgičević
USplitu
DANA30.3.2011.
88
9.3.6 Upravljanje izmjenama
OZNAKAVERZIJE
DATUM PRIPREMIO ODOBRIO KRATKI OPIS IZMJENA
1.0 2011-04-11 Jurica Grgičević Jurica Grgičević Inicijalna verzija
2.0 2011-06-05 Jurica Grgičević Jurica Grgičević Dodan tekst u poglavlja .NET, C#
2.1 2011-06-07 Jurica Grgičević Jurica Grgičević Male izmene u strukturi poglavlja
3.0 2011-08-10 Jurica Grgičević Jurica Grgičević Veće izmene dodan sadžaj u više poglavlja
3.1 2011-09-15 Stipe Čelar Stipe Čelar Manje izmjene – uglavnom označene kroz dokument
3.2 2011-09-18 Jurica Grgičević Jurica Grgičević Ispravljene greške, dodane slike i poglavlja koja nedostaju
3.3 2011-09-19 Stipe Čelar Stipe Čelar Manje izmjene – uglavnom označene kroz dokument
3.4 2011-09-19 Jurica Grgčević Jurica Grgičević Ispravljene greške koje su označene u dokumentu
3.5 2011-09-20 Stipe Čelar Stipe Čelar Posljednje korakcije mentora
3.6 2011-09-20 Jurica Grgičević Jurica Grgičević Finalna verzija
89
