Programska re itev za podporo poslovanja gozdne urbarialne ... · Visual Basic 6 in uporablja podatkovno zbirko tipa Microsoft Access. KLJU ČNE BESEDE - poslovanje, - urbarialna

UNIVERZA V MARIBORU FAKULTETA ZA ORGANIZACIJSKE VEDE

Diplomsko delo univerzitetnega študija Smer organizacijska informatika

PROGRAMSKA REŠITEV ZA PODPORO POSLOVANJA

GOZDNE URBARIALNE SKUPNOSTI Mentor: doc. dr. Borut Werber Kandidat: Robert Doler

Kranj, november 2006

ZAHVALA Zahvaljujem se mentorju dr. Borutu Werberju za pomoč in nasvete ob pripravi in izdelavi diplomske naloge. Hvala g. Miranu Lovrinu iz Gozdne urbarialne skupnosti Dobrovnik za pomoč, nasvete in testiranje programske rešitve. Zahvaljujem se tudi lektorici Raheli Hojnik, ki je lektorirala mojo diplomsko nalogo.

POVZETEK Diplomska naloga zajema zasnovo in izvedbo prototipne programske rešitve za podporo poslovanja gozdne urbarialne skupnosti. Ena večjih gozdnih urbarialnih skupnosti v Sloveniji nastopa kot naročnik programske rešitve, ki bi omogočila neprimerno hitrejše delo in natančnejše rezultate.

Poslovanje je do vpeljave rešitve potekalo povsem ročno, delo je bilo zelo zamudno, hkrati pa je bilo veliko napak in odstopanj.

Programska rešitev omogoča evidenco deležev solastnikov, podporo ocenjevanju vrednosti dreves, dodeljevanje dreves in vse potrebne izpise, omogoča še vpogled v zgodovino deležev in dodeljevanj za pretekla leta. Izdelana je v razvojnem okolju Visual Basic 6 in uporablja podatkovno zbirko tipa Microsoft Access.

KLJUČNE BESEDE

- poslovanje, - urbarialna skupnost, - visual basic, - Microsoft Access, - podatkovna zbirka.

ABSTRACT Diploma work consists of the plan and realization of the prototype software solution for the operation of an agricultural community. One of the largest agricultural communities in Slovenia represents the user client of the software solution, which would greatly improve the speed and accuracy of their work.

Before the introduction of the software solution the work was done manually, it was very time-consuming with a lot of errors and deviations.

The software solution enables keeping records of part-owners, tree-value assessment support, allocation of trees and all necessary printouts. The software also supports the history of shares and allocation for previous years. It is developed in Visual Basic 6 and uses a Microsoft Access type database. KEYWORDS

- business operation, - agricultural community, - visual basic, - Microsoft Access, - database.

KAZALO

1 UVOD ............................................................................................................................................6

1.1 Predstavitev problema .......................................................................................................6

1.2 Predstavitev okolja .............................................................................................................6

1.3 Predpostavke in omejitve ..................................................................................................6

1.4 Metode dela .........................................................................................................................7

2 RAZVOJ PROTOTIPNIH REŠITEV .........................................................................................8

2.1 Osnove .................................................................................................................................8

2.2 Metoda zavračanja prototipov...........................................................................................8

2.3 Razvojna prototipna metoda .............................................................................................9

2.4 Delno prototipiranje ............................................................................................................9

2.5 Orodja za prototipiranje ...................................................................................................10

2.6 Kdaj uporabiti prototipiranje ............................................................................................12

2.7 Postopek prototipiranja ....................................................................................................12

2.8 Prednosti in težave ...........................................................................................................14

3 OSNOVE RAZVOJNEGA OKOLJA VB6 .............................................................................15

3.1 Zgradba ..............................................................................................................................15

3.2 Osnove razvoja .................................................................................................................15

3.2.1 Splošno o oknih ............................................................................................................15

3.2.2 Dogodkovno programiranje ........................................................................................16

3.2.3 Gradniki, lastnosti, metode in dogodki ......................................................................17

3.3 Predmeti in zbirke podatkov............................................................................................18

4 OBSTOJEČE STANJE ............................................................................................................20

4.1 Posnetek stanja ................................................................................................................20

4.2 Kritična analiza..................................................................................................................21

5 IZDELAVA PROGRAMSKE REŠITVE..................................................................................22

5.1 Analiza zahtev naročnika in zasnova rešitve................................................................22

5.2 Zasnova podatkovnega modela .....................................................................................24

5.3 Struktura podatkovnih tabel ............................................................................................25

5.4 Zasnova programske rešitve...........................................................................................27

5.4.1 Uporabniški vmesnik....................................................................................................27

5.4.2 Žreb in delitev ...............................................................................................................33

5.4.3 Poročila ..........................................................................................................................37

5.4.4 Zaščita............................................................................................................................41

5.4.5 Distribucija programske rešitve ..................................................................................42

5.4.6 Testiranje .......................................................................................................................44

6 ZAKLJUČKI ...............................................................................................................................46

6.1 Ocena učinkov ..................................................................................................................46

6.2 Pogoji za uvedbo ..............................................................................................................47

6.3 Možnosti nadaljnjega razvoja .........................................................................................47

LITERATURA IN VIRI ...................................................................................................................48

PRILOGE ........................................................................................................................................49

KAZALO SLIK ................................................................................................................................49

POJMOVNIK ..................................................................................................................................49

KRATICE IN AKRONIMI...............................................................................................................49

Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo univerzitetnega študija

Robert Doler: Programska rešitev za podporo poslovanja gozdne urbarialne skupnosti stran 6

1 UVOD 1.1 PREDSTAVITEV PROBLEMA V diplomski nalogi se lotevamo problema poslovanja urbarialne skupnosti. Solastniki gozdne urbarialne skupnosti gospodarijo z nepremičninami v skupni lasti. Gre za gozdne parcele, na katerih je potrebno vsako leto posekati določeno število dreves. Ta drevesa oz. les je potrebno ovrednotiti ter razdeliti med solastnike. Ključ delitve je delež vsakega solastnika v urbarialni skupnosti. Ti deleži so zelo različni, od zelo majhnih do zelo velikih. Ena večjih gozdnih urbarialnih skupnosti v Sloveniji nastopa kot naročnik programske rešitve, ki bi omogočala neprimerno hitrejše delo in natančnejše rezultate, saj je dosedanje poslovanje potekalo povsem ročno. 1.2 PREDSTAVITEV OKOLJA Urbarialne skupnosti so nastale na podlagi nekdanjih agrarnih skupnosti. Nepremičnine v njihovi lasti so bile po drugi svetovni vojni podržavljene, nato pa po osamosvojitvi Slovenije po Zakonu o denacionalizaciji vrnjene nekdanjim lastnikom. Skupnosti so organizirane podobno kot društva, imenujejo upravni odbor in druge organe skupnosti. Gozdna urbarialna skupnost Dobrovnik je ena večjih, ima preko 400 članov in gospodari s približno 200 hektari gozdnih parcel. Vsako leto določijo za posek okoli 1200 dreves. Ročno poslovanje je zelo zamudno, pojavlja se tudi veliko napak in odstopanj. Samo za ocenjevanje dreves odbor porabi vsaj teden dni, še enkrat toliko za delitev lesa, potem pa je potrebno izdelati še spremljajočo dokumentacijo. Po analizi ročnega dodeljevanja smo ugotovili, da so odstopanja tudi do 300%. 1.3 PREDPOSTAVKE IN OMEJITVE Osnovna zahteva je izdelava računalniškega programa, ki bi omogočal evidenco deležev solastnikov, podporo evidentiranju in ocenjevanju dreves, dodeljevanje dreves in vse potrebne izpise, hkrati pa omogočal še vso zgodovino deležev in dodeljevanja za posamezna leta.



Programska rešitev naj bi opravila vsaj večino zahtevnega preračunavanja ob ocenjevanju in dodeljevanju, mora pa omogočati tudi povsem ročno delo, da je možno popraviti morebitne napake ali omogočiti posebne želje solastnikov, npr. dodeljevanje določene vrste lesa ipd. Programska rešitev bo narejena v razvojnem okolju Visual Basic 6 in nima posebnih zahtev glede strojne opreme. 1.4 METODE DELA V prvi fazi so izvedeni pogovori z predstavniki naročnika. Na podlagi teh informacij je opravljena sistemska analiza obravnavanja podatkov. Rezultat le-te je entitetno - relacijski diagram in pripadajoč relacijski podatkovni model. Odločili smo se za metodo prototipne rešitve, ki omogoča naslednje prednosti (Zupančič, 2006):

- nizke razvojne stroške projekta - razmeroma hiter razvoj začasne delujoče programske rešitve - skrajšan čas razvoja sistema - možnost preizkušanja idej brez večjih stroškov - učinkovito delitev dela med uporabniki in razvijalci - učinkovito uporabo strojnih in človeških virov

Prototipna rešitev bo predstavljena naročniku, dogovorili smo se tudi za testiranje. Morebitne pomanjkljivosti bodo odpravljene do končne uvedbe rešitve.



2 RAZVOJ PROTOTIPNIH REŠITEV 2.1 OSNOVE 1 Tendenca razvoja programskih sistemov je danes usmerjena k hitrejši in cenejši izdelavi, hkrati pa naj bi bili programski sistemi izdelani po merilih, ki jih postavlja uporabnik. Očitno je tudi, da se v današnjem času poslovni procesi spreminjajo hitreje, kot se obrne konvencionalni kaskadni življenjski cikel programske opreme. Sklepamo lahko, da realizirani programski sistem ne predstavlja več ustreznega odgovora na aktualne, torej že povsem spremenjene uporabnikove zahteve. Problema ne izločimo niti s povečano produktivnostjo oz. storilnostjo. Ustrezno rešitev navedenega problema predstavlja prototipiranje. Namesto da razvijamo sistem, zgradimo model, katerega lahko hitro in enostavno prilagodimo uporabnikovim zahtevam. Te modele - prototipe predstavimo uporabnikom, ti jih ocenijo in v primeru, ko z njimi niso zadovoljni, lahko model hitro in enostavno modificiramo. Stroški so manjši kot pri spreminjanju že obstoječega sistema. Prototipiranje je tehnika načrtovanja delne implementacije sistema, tako da se lahko uporabniki in razvijalci podrobneje seznanijo s problemom oz. njegovo rešitvijo. Obstajata dva osnovna pristopa oz. dve različni metodi prototipiranja:

- metoda zavračanja (throwaway): 'hitro in robustno' ('quick and dirty'), - razvojna (evolutionary) metoda: sistematičen pristop pri izgradnji.

Pri metodi zavračanja po pridobitvi vsega potrebnega znanja o problemu in o rešitvah prototip zavržemo in začnemo razvijati sistem, pri razvojni metodi pa prototip preraste v sam sistem. 2.2 METODA ZAVRAČANJA PROTOTIPOV Pri gradnji zapletenih sistemov so zahteve ob začetku projekta praviloma nejasne in slabo definirane ter se med samo izgradnjo sistema pogosto spreminjajo. Rečemo lahko, da zahteve dozorijo oz. da se resnične zahteve pojavijo šele takrat, ko lahko uporabniki praktično preverijo sistem. Pri metodi zavračanja zgradimo hiter in robusten (quick-and-dirty) prototip ter ga predstavimo potencialnim uporabnikom ali naročnikom z namenom, da skupaj z njimi:

- ugotovimo izvedljivost želja (zahtev), - potrdimo potrebnost oz. nujnost posameznih funkcij, - odkrijemo manjkajoče, torej nepodane zahteve in - raziščemo možnosti razvoja ustreznega uporabniškega vmesnika.

1 Povzeto po Rozman, Osnove informacijskih sistemov, 2002



S pomočjo tako pridobljenih podatkov lahko z večjo verjetnostjo, da gradimo pravi oz. ustrezen sistem, dokončamo specifikacije programskih zahtev (software requirements specification). Prototipa seveda ne gradimo, če lahko identificiramo vse zahteve in se potencialni uporabniki z njimi strinjajo. Hitre in robustne prototipe lahko gradimo v fazi načrtovanja (tako preliminarnega kot podrobnega). Z njimi lahko validiramo strukturo programskega sistema, torej ugotovimo, ali zasnovana programska struktura zadovoljuje vse opredeljene zahteve, oz. če bo lahko zahteve zadovoljila. Vendar tudi pri načrtovanju velja podobno kot pri analizi, da prototipa ne gradimo, če smo lahko dovolj učinkoviti tudi brez njega oz. obstaja splošno soglasje glede ustrezne alternative. V fazi podrobnega načrtovanja pa nam lahko hiter in robusten prototip pomaga pri vrednotenju določenega algoritma. Vsekakor v vseh teh primerih (analizi, preliminarnem in podrobnem načrtovanju) ne smemo pozabiti, da gradimo hiter in robusten prototip. Pod pojmom hiter mislimo predvsem na hitrost izgraditve prototipa, tako da za njegovo izgradnjo ni potrebno veliko oz. preveč časa. Le tako lahko rezultate oz. ugotovitve še pravočasno upoštevamo in koristno uporabimo. Prototip je robusten v smislu kvalitete, saj ga tako ali tako nameravamo kasneje zavreči. Robusten je, ker je brez načrtovanja, brez komentarjev, brez načrta testiranja itd. 2.3 RAZVOJNA PROTOTIPNA METODA Pri tej metodi prototip razvijemo v končni sistem, zato le-ta ne sme biti hiter in robusten, saj mora imeti kvalitete končnega produkta kot so zanesljivost ter enostavno vzdrževanje. Vse to povzroča počasnejši razvoj prototipa v primerjavi z metodo zavračanja. Če se odločimo za ta pristop, je naravna pot seveda ta, da sledimo običajnemu razvoju življenjskega cikla: razjasniti izdelek, priskrbeti in uporabiti izkušnje, na osnovi pridobljenih izkušenj ponovno opraviti povpraševanje, ponovno načrtovati, kodirati, testirati in ponovno pojasniti. Proces seveda ponavljamo tako dolgo, dokler ne dosežemo zadovoljive stopnje prototipa, katerega razvijemo v končni sistem. Tak način nam zagotavlja razvoj potrebne dokumentacije in potreben pregled nad sistemom. 2.4 DELNO PROTOTIPIRANJE Prototipi lahko predstavljajo delovanje celotnega sistema, poznamo pa tudi prototipe, ki se ukvarjajo samo z določenim delom programskega sistema. Te delne prototipe lahko zasledimo v naslednjih pojavnih oblikah (Rozman, 2002): Pogovorni prototip – dialog končnega sistema z uporabnikom. Prototip tega tipa simulira sodelovanje oz. komunikacijo, torej dialog končnega sistema z uporabnikom. Je najpogostejša oblika delnega prototipa. Uporabniki vidijo način komunikacije s sistemom, zato je ta tip prototipa zaželen, saj se lahko uporabniki že pred fazo implementacije seznanijo z delovanjem prototipa in predlagajo omejitve, izboljšave itd. Pogovorni prototip ima največji vpliv na prikaz uporabnosti in uporabnikovo dojemanje sistema. Večina sistemskih analitikov in programerjev ni poučenih, kakšen je psihološko učinkovit dialog. Pogosto oblikujejo dialoge, ki niso



dovolj jasni in/ali so zapleteni ter zmedejo uporabnika. Zaradi naštetih razlogov je priporočljivo izdelati prototip, ki ga lahko uporabniki testirajo in ocenijo. Dialog lahko izboljšamo oz. prilagodimo uporabniku še preden izdelamo dejanski sistem. Prototip vnosa podatkov – je uporaben predvsem pri sistemih, ki zahtevajo vnos velikega števila oz. obsega podatkov. Lahko ga obravnavamo kot samostojno celoto in ga kasneje povežemo z obstoječim sistemom. Zgradimo oz. izdelamo ga, da ugotovimo hitrost in točnost vstavljanja podatkov. Preverimo lahko tudi veljavnost in integriteto podatkov. Prototip sistema sporočanja – zgradimo, da preverimo sporočila in način njihovega podajanja. Sporočila, ki so namenjena uporabnikom, je priporočljivo pred implementacijo sistema preveriti ter raziskati najprimernejši način njihovega podajanja. Prototip podatkovnega sistema – predstavimo kot nekaj zapisov v podatkovni zbirki. Uporabniki in analitiki nato testirajo njihovo delovanje in identificirajo pomanjkljivosti. S tem prototipom je možno ugotoviti, katera polja zapisa so odvečna in katera manjkajo. Na tak način pridemo do optimalnega zapisa, kar povzroči hitrejšo in lažjo obdelavo podatkov. Kreiramo lahko takšne prototipe, ki uporabnikom in analitikom omogočajo kreiranje novih podatkovnih zapisov, njihov prikaz ter opravljanje operacij. Ti prototipi se uporabljajo v primerih, ko želimo izluščiti uporabnikove želje o tem, kaj vse naj vsebuje podatkovna zbirka. Podatkovna zbirka, uporabljena pri prototipiranju, je lahko dejanska ali le model dejanske podatkovne zbirke. V nekaterih primerih je dovolj, če sami modeliramo podatkovno zbirko in razvijamo prototip, obstajajo pa tudi primeri, ko moramo graditi prototip na obstoječi podatkovni zbirki. Prototip računanja in logike – uporabimo, ko so izračuni ali logika programskega sistema zelo zapleteni. Uporabniki v takem primeru podajo primere pričakovanih izračunov oz. delovanje sistema. Te primere lahko nato priključimo sistemu ali jih povežemo z aplikacijo in nato ugotavljamo oz. primerjamo točnost prototipnih izračunov s podanimi. Prototip aplikacijskega paketa – zgradimo, da preverimo uporabnost in pogoje povezovanja. S tem se izognemo slabemu povezovanju z drugimi aplikacijami. Prototip koncepta – uporabimo pri velikih sistemih, ko se pojavi vprašanje koncepta sistema. Koncept preizkusimo, da po nepotrebnem ne vlagamo denarja v razvoj velikega sistema. Taki prototipi so razviti predvsem po metodi zavračanja, saj morajo biti sestavljeni hitro in robustno, da lahko izluščimo pravi koncept sistema. Ko določimo koncept, se lahko lotimo načrtovanja ciljnega sistema. 2.5 ORODJA ZA PROTOTIPIRANJE Prototipiranje se je začelo uveljavljati šele po letu 1980, predvsem, ker metoda prototipiranja ni bila dodelana in je bila cena prototipiranja skoraj enaka ceni izdelave pravega sistema. V osemdesetih letih pa so se pojavili jeziki četrte generacije, ki so omogočili cenejše snovanje prototipov, omogočili pa so tudi njihovo



hitro in učinkovito izdelavo. Ti jeziki nam omogočajo izgradnjo osnovnih prototipov v nekaj dneh, tako da lahko uporabniku hitro prikažemo dejavnosti bodočega sistema. Na uporabnikove pripombe in opozorila lahko hitro reagiramo ter prototip popravimo ali odpravimo pomanjkljivosti v dnevu ali dveh. Tudi podatkovno zbirko lahko zelo hitro načrtujemo in spreminjamo. Jeziki četrte generacije seveda niso namenjeni samo za izdelavo prototipov, uporabljamo jih lahko tudi za izgradnjo sistema, zato lahko prototipe z uporabo jezikov četrte generacije razvijemo v končni sistem. Izbira pravilnega orodja je v veliki meri odvisna od izbrane metode prototipiranja (razvoj ali zavračanje). Če se npr. odločimo za razvojno metodo, je smiselno razvijati prototip v istem okolju, kot bomo razvijali sistem. Zato je potrebno pri izbiri ustreznega orodja za prototipiranje upoštevati tudi strojno opremo in ciljno okolje, v katerem bo deloval grajeni sistem. Za prototipiranje je potrebno izbrati takšno orodje, da bo izdelava, oz. izgradnja prototipov čim hitrejša in enostavnejša, hkrati pa bo mogoče prototip brez večjega truda tudi spreminjati. Rečemo torej lahko, da je optimalno orodje za prototipiranje takšno, ki nam omogoča hitro in enostavno zajemanje uporabnikovih zahtev in kjer niso potrebni veliki posegi pri spreminjanju in dodajanju operacij. Prototipe gradimo, da omogočimo skupno delo oz. sodelovanje uporabnikov in razvijalcev sistema. Nekatera orodja omogočajo sestavo prototipa med samim trajanjem oz. potekom delovnega sestanka uporabnikov in razvijalcev. Tak način dela je seveda nadvse zaželen. Kriteriji izbire prototipnega orodja (Rozman, 2002) Orodje naj bi:

- bilo interaktivno, - bilo enostavno za uporabo, - omogočalo enostavno in hitro spreminjanje, - omogočalo hitro gradnjo prototipov (tudi delnih), - vzpodbujalo postopno dograjevanje, - podpiralo ustrezne strukture baz podatkov,

ter vključevalo:

- zmogljiv zaslonski oblikovalnik, - možnost povezovanja zaslonov kot odgovora na dialog, - zmogljiv generator poročil, - jezik četrte generacije ali generator kode, - primeren sistem za upravljanje baze podatkov, - integrirani podatkovni slovar, - možnost pridobitve podatkov iz obstoječih zbirk podatkov, - in njihov prenos v prototipno podatkovno zbirko (ali on-line dostop).

Pri razvojni metodi mora orodje dodatno nuditi še:

- možnost izboljšanja strojnih zmogljivosti, - podporo podatkovnim strukturam končnega sistema, tudi glede distribuiranih

podatkov, - omrežni dostop, - večuporabniško opcijo, - sposobnost nadzora obsežnih baz podatkov, - možnost vključevanja segmentov, napisanih v drugih programskih jezikih.



2.6 KDAJ UPORABITI PROTOTIPIRANJE Uporaba prototipov pri razvoju programskih sistemov ni vedno primerna. Pri npr. paketni obdelavi prototipiranje zagotovo ni tako učinkovito kot je pri interaktivnih programih. Prototipiranje je priporočljivo predvsem, ko:

- uporabniki ne vedo natančno, kaj želijo; - uporabniki s težavo podajajo oz. izražajo svoje zahteve; - novi sistem spreminja osnove poslovnih operacij; - uporabniške vmesnike prilagajamo končnim uporabnikom; - so funkcije, ki naj bi jih računalniško podprli, zapletene in nejasne ter jih

uporabniki poznajo oz. razumejo bolje kot analitiki; - je potrebno preveriti zaslonske oblike in poročila, da ugotovimo možne

izboljšave ter zvišamo nivo uporabnosti; - obstaja področje uporabnikovega dela, ki ga je možno izboljšati in je

potrebno zagotoviti kreativno sodelovanje uporabnikov; - uporabniki ne razumejo in opazijo vseh pridobitev in možnosti, ki jih nudi

nastajajoči sistem; - je potrebno raziskati relativno vrednost alternativnih rešitev.

Vsekakor pa je uporaba prototipov zelo priporočljiva in učinkovita pri izdelavi takšnih sistemov, kjer uporabniki še ne zmorejo natančno definirati, kaj naj bi sistem omogočal ali tam, kjer je razvoj zelo dinamičen in se zahteve uporabnikov nenehno spreminjajo. S pomočjo prototipov lahko enostavno in dosledno razvijamo vso potrebno dokumentacijo. 2.7 POSTOPEK PROTOTIPIRANJA Področje in cilj Če je opravljena analiza s pomočjo informacijskega inženirstva, se lahko področje prototipiranja določi iz procesnih blokov v enciklopediji. Enciklopedija je nekakšna centralna shramba, v katero so vnesene vse sistemske informacije le enkrat. V njej so shranjeni podatkovni modeli, procesiranja, informacije načrtovanja, dejstva, pravila ter nadzor organizacije in njenih sistemov. Cilj sistema, ki ga prototipiramo, moramo določiti, preden začnemo z načrtovanjem prototipa. Raziskati moramo ustrezne naloge, probleme in kritične faktorje, ki vplivajo na rezultat prototipa. Prav tako je potrebno določiti, kako bo razdeljen in umeščen bodoči sistem. Slednje nam pomaga pri odločitvi, kdo bo prototip testiral. Kdo bo prototip testiral Poznamo dva načina testiranja:

- validacija - je proces testiranja rezultatov v vsaki fazi življenjskega cikla, kjer preverjamo, če se rezultati ujemajo z rezultati, ugotovljenimi v predhodni fazi življenjskega cikla;

- verifikacija - je proces testiranja, kjer rezultate sistema primerjamo z uporabniškimi zahtevami.



Del procesa načrtovanja je tudi odločitev, kdo bo testiral pravilnost delovanja prototipa. Glavni preizkuševalci so končni uporabniki, ki bodo bodoči sistem tudi uporabljali. Nujno je, da so med preizkuševalci tudi razvijalci aplikacij. Pri prototipiranju lahko nastanejo težave, če preizkuševalci niso dosledni ali nimajo motiva za natančen pregled prototipa. Zato moramo poiskati takšne, ki so dosledni in kritični. Ko je prototip razvit do določene stopnje, ga lahko testiramo. Potencialni kandidati, ki lahko sodelujejo pri testiranju so: vodstvo, investitor sistema, tehnično osebje, ki bo gradilo sistem, v nekaterih primerih zunanji ljudje, npr. kupci, zastopniki, ki so vpleteni v razvoju sistema, včasih pa vprašamo za mnenje tudi zunanjega eksperta. Kdo bo zgradil prototip Običajno gradi prototip ena sama oseba, ki je dobro seznanjena z jeziki četrte generacije ali uporabljenim generatorjem. Ta oseba je običajno strokovnjak s področja informacijskega inženirstva, v nekaterih izjemnih primerih pa lahko kar končni uporabnik. Običajno seveda strokovnjak zgradi prototip, končni uporabniki pa ga testirajo. Redki so primeri, vendar obstajajo, ko uporabniki zgradijo prototipe, testirajo pa ga strokovnjaki. Prototip lahko gradita tudi dve osebi, vsaka z drugačnim znanjem. Ponavadi je to strokovnjak informacijskega inženirstva in uporabnik. V splošnem za gradnjo prototipov ni priporočljiva velika skupina. Dve osebi sta zgornja meja, saj v večini primerov to zadošča. Gradnja prototipa Omenili smo že, da mora biti pri uporabi razvojne metode prototip skrbno načrtovan. Prototip ne sme postati izgovor za malomarnost pri delu in opustitev strukturnega načrtovanja. Če nismo dosledni, se lahko zgodi, da dobimo namesto prototipa kaos, ki ga je težko spremeniti ali prevesti v sistem. Dobro prototipno orodje mora voditi k čistemu strukturnemu načrtovanju. Pri prototipiranju moramo na začetku zgraditi preprost model, tako da že v razvojni fazi opazimo razhajanja med ciljem in nalogami. Pri zapletenih sistemih je potrebno najprej zgraditi njegovo ogrodje in šele nato vse ostalo. Načini razvoja Prototipe lahko razvijamo na dva osnovna načina:

- razvoj ‘korak za korakom’ in - nepretrgan razvoj.

Pri razvoju ‘korak za korakom’ sestavimo za vsak prototip listo potrebnih popravkov ali dodatkov. To ponavljamo tako dolgo, dokler ne dosežemo ciljne verzije sistema. Pri nepretrganem razvoju sodelujejo preizkuševalci, ki z razvijalci prototipa sprotno popravljajo prototip. Tak način uporabimo takrat, ko obstaja močna povezanost med uporabniki in razvijalci prototipa. Včasih je potrebno testiranje za nekaj časa prekiniti, da lahko razvijalci preučijo staro verzijo in jo ponovno modificirajo. Razlike med prototipom in sistemom Ko končamo s prototipiranjem in izdelamo končno verzijo prototipa, se ta še vedno razlikuje od sistema. Po končanem prototipiranju sestavimo spisek lastnosti, ki jih prototip ne vsebuje, sistem pa jih mora. Najpogostejše so:

- sposobnost okrevanja po napaki, - varovanje podatkov,



- sposobnost revizije, - enostavnost vzdrževanja, - učinkovitost, - večuporabniško delovanje, - ustrezni odzivni časi, - obvladovanje obsežnih baz podatkov, - delovanje v omrežju, - delovanje na različni strojni opremi in - dokumentacija.

Uporabnikom moramo razložiti, zakaj se prototip, takšen kot je, ne more uporabiti kot sistem. Prav tako jim moramo podati datumske roke za dograjevanja sistema. Zgodi se namreč, da uporabniki ne razumejo, da je prototip tako hitro nastal, za izgradnjo sistema pa je potrebno dalj časa. 2.8 PREDNOSTI IN TEŽAVE Prednosti uporabe prototipnega načina načrtovanja so:

- uporabniki vidijo, kaj za njih gradimo ter podajo kritične pripombe; - tveganje, da zgradimo neustrezen sistem, je manjše; - ta način vzpodbuja uporabnike h kreativnemu delu oz. konstruktivnemu

sodelovanju; - za uporabnika je lažje in boljše, kot da mora podati specifikacije na papirju; - prototip nastane hitreje kot specifikacije; - izločimo pristranskost, saj nakažemo pridobitve novega načina dela; - napake lahko odkrijemo pred cenovno zahtevnimi fazami; - pridobimo navdušenost in večjo zainteresiranost uporabnikov in razvijalcev; - preizkusimo lahko več inačic.

Nastopajo seveda tudi slabosti oz. težave. Glavne so:

- površno načrtovanje, - previsoke zahteve uporabnikov, - problem razlikovanja prototipa in sistema, - površnost uporabnikov pri pregledu.

Uporabljen na pravi način, nam prototipni pristop zagotavlja hitrejši razvoj kot tradicionalni življenjski cikel razvoja programske opreme (Rozman, 2002).



3 OSNOVE RAZVOJNEGA OKOLJA VB6

3.1 ZGRADBA Visual basic je združeno razvojno okolje (IDE, Integrated Development Environment), ker združuje večino funkcij razvijanja programov, kot so npr. urejanje grafičnega vmesnika, urejanje kode, prevajanje in poskusno izvajanje ter razhroščevanje (Mesojedec, 1998). Uporabniški vmesnik je prilagodljiv in zgrajen tako, da nam skuša pomagati na vsakem koraku. Glavni elementi razvojnega okolja so:

- priročni meni (Context menu), ki vsebuje ukaze predmeta ali območja, na katerega smo kliknili;

- vrstica z gumbi (Toolbar), ki vsebuje bližnjice do najuporabnejših menijskih ukazov;

- orodjarna (Toolbox), ki vsebuje gradnike, s katerimi oblikujemo uporabniški vmesnik nastajajočega programa;

- projektno okno (Project Explorer), ki vsebuje seznam odprtih projektov in posameznih enot projektov;

- prostor za načrtovanje obrazcev (Form Designer), kjer vizualno načrtukemo obrazce in pišemo programsko kodo.

- okno za nastavljanje lastnosti (Properties), ki vsebuje lastnosti trenutno izbranega elementa;

- položajno okno (Form Layout), ki omogoča nastavitev izhodiščnega položaja okna pri izvajanju programa.

Uporabniški vmesnik razvojnega okolja visual basica si je mogoče temeljito prikrojiti po lastnih željah in potrebah. 3.2 OSNOVE RAZVOJA Vizualno programiranje temelji na skupnih značilnostih vseh programov, ki se izvajajo v Oknih. Gradniki in odzivni podprogrami uporabnika visual basica precej varujejo pred podrobnostmi, vendar jih moramo vsaj bežno poznati. 3.2.1 SPLOŠNO O OKNIH Družina operacijskih sistemov Microsoft Windows (Okna) ima grafični uporabniški vmesnik (GUI, graphical user interface). Za tovrstne vmesnike so značilna prekrivajoča se okna, meniji, ikone ter izdatna uporaba miške ali podobne kazalne naprave. Taka so Okna navzven, za vsakdanje uporabnike.



Za programerja pa je okno (window) pravokotno območje na zaslonu določenega videza in vedenja. Osnovno okno programa s svojo naslovno vrstico je okno, okno je tudi vsak gumb, vsako vnosno polje, celo meni. Vsa ta okna so vzorno označena in evidentirana v srcu operacijskega sistema. Operacijski sistem jih redno preverja in obvešča o najrazličnejših dogodkih (events), ki jih lahko zanimajo. Za gumb je tak dogodek prav gotovo klik z miško nad njegovo površino. Dogodkom, ki jih povzroči miška ali tipkovnica, pravimo tudi uporabniško ustvarjeni dogodki (user events). To pa še zdaleč niso vsi dogodki, o katerih je okno lahko obveščeno. Dogodek lahko povzroči tudi drugo okno ali pa izvira iz operacijskega sistema, npr. »končajte delo, pospravljamo«. Če se zavedamo, da je oken na značilnem uporabniškem vmesniku toliko in da vsakega lahko doleti silno veliko dogodkov, je jasno, da bi popolno obvladovanje vse te množice sporočil (messages) terjalo zelo veliko dela. Visual basic zna večino stvari postoriti namesto nas. Po drugi strani pa nam omogoča, da določene dogodke obravnavamo po lastnih željah. Zato lahko zelo hitro pridemo do delujočega programa, hkrati pa razvijemo program, izpiljen v vseh podrobnostih. 3.2.2 DOGODKOVNO PROGRAMIRANJE Druga značilnost operacijskega sistema Okna je večopravilnost (multitasking). Hkrati lahko uporabljamo več programov. Medtem ko se prenaša naša elektronska pošta, lahko urejevalnik besedil tiska novoletne voščilnice, mi pa polagamo pasjanso. Tudi večopravilnost omogoča sistem poizvedovanja in obveščanja o dogodkih, ki ga v celoti nadzira operacijski sistem. Zato pravimo, da so programi dogodkovno vodeni. Dogodkovna naravnanost pomeni, da program nima vnaprej določene poti izvajanja. Vsak program, ki kakorkoli komunicira z uporabnikom, je pri današnji hitrosti računalnikov večinoma brezposeln - čaka, da premaknemo miško ali pritisnemo na tipko. V tem času lahko koristno delo opravljajo drugi programi, npr. tisti, ki skrbi za tiskanje ali prenašanje podatkov. Brž ko se uporabnik odzove, operacijski sistem to prestreže, sestavi ustrezno sporočilo ter z njim obvesti vse čakajoče stranke. Naš program pa ne more vedeti, ali bo uporabnik najprej pritisnil na tipko ali bo prej z miško kaj prestavil ali bo celo njegov prvi odziv na naš umotvor negativen in bo želel program čim prej zapreti. Za povrh smo že omenili, da ni samo uporabnik tisti, ki povzroča dogodke. Pri razvijanju dogodkovno vodenih programov je nujno, da se zavedamo te nedoločenosti poti izvajanja. Zato moramo sestavne dele programa razvijati tako, da se izvajajo samo ob ustrezno izpolnjenih pogojih. Lahko, npr., preprečimo izpis pozdrava, dokler uporabnik ne vnese svojega imena. To je mogoče precej preprosto doseči, tako da onemogočimo gumb, dokler uporabnik česa ne vnese v vnosno polje. Ker visual basic ustrezno obdela vse življenjsko pomembne dogodke, lahko brez težav poganjamo tudi na pol dokončane programe. To je zelo pogosto pri programiranju, saj bi drugače zlahka pozabili na marsikatero malenkost, ki se vidno odrazi šele po praktičnem preizkusu programa.



3.2.3 GRADNIKI, LASTNOSTI, METODE IN DOGODKI Gradnike (controls) uporabljamo pri načrtovanju uporabniškega vmesnika. Zbrani so v orodjarni (Toolbox). Po potrebi lahko dodajamo nove, ki jih lahko razvijemo tudi v samem visual basicu. Njihov videz določajo lastnosti (properties), vedenje pa odzivni podprogrami (event procedures). Temeljni gradnik uporabniškega vmesnika je obrazec (form), gradniki pa so tudi vsi elementi, ki jih naknadno narišemo nanj, kot sta npr. gumb ali vnosno polje. Lastnosti (properties) določajo dokončen videz posameznega gradnika. Najpo-membnejša lastnost prav vsakega gradnika je njegovo ime (lastnost Name). Ime enolično določa sleherni gradnik na obrazcu in omogoča njegovo uporabo iz programske kode. Lastnosti gradnika določajo tudi njegov položaj in velikost na obrazcu ter kup drugih značilnosti, ki pa se od gradnika do gradnika precej razlikujejo. Nabor lastnosti je za vsak gradnik že določen, hkrati pa ima vsaka lastnost že svojo privzeto nastavitev, tako da v praksi spreminjamo nastavitve le manjšega dela lastnosti. Dogodki (events) samodejno sprožajo odzivne podprograme, ki pa določajo vedenje gradnika. Vrste odzivnih podprogramov, in s tem tudi prepoznani dogodki, so za vsako posamezno vrsto gradnika že dokončno izbrani. Programer se lahko zgolj odloča, katere odzivne podprograme bo uporabil in katerih ne bo, torej na katere dogodke se bo odzval in na katere ne. Odziv na dogodek zapišemo s programsko kodo v visual basicu. Dogodek je lahko posledica dejavnosti uporabnika (premik miške, pritisk na tipko ...), lahko je sporočilo drugega programa ali celo operacijskega sistema. Moramo pa vedeti, da je dogodek lahko tudi posledica ukaza v programski kodi. Metoda (method) je sestavni del gradnika, podobno kakor lastnost. Metoda je neko zaokroženo opravilo, ki ga zna gradnik opraviti. Dejansko je podprogram, vezan na posamezno vrsto gradnika. Podobno kakor vsi gradniki poznajo lastnosti Left in Top, ki določata njun položaj, poznajo tudi metodo Move, ki omogoča premik gradnika drugam. Ni redko, da metode opravljajo delo, ki ga je sicer mogoče postoriti tudi z nastavitvijo nekaj lastnosti. Seveda so tudi opravila, ki jih z lastnostmi ni mogoče doseči, zato moramo, da bi gradnik lahko učinkovito uporabljali, poznati tako njegove lastnosti kakor metode, pa tudi dogodke, ki jih prepozna. Gradniki so sestavni del vsakega programa, določajo izgled programa in se jim ne moremo izogniti. Hkrati nam izdatno olajšajo programiranje, saj za večino drobnih stvari poskrbijo sami, mi pa se lahko osredotočimo na sam problem. Programska koda pa določa vedenje nekega programa. Okno s kodo pripada vsakemu obrazcu v našem projektu. V projekt je mogoče dodati tudi samostojna okna s kodo, v katerih so splošna programska navodila, neodvisna od uporabniškega vmesnika. Jezik, ki ga uporablja razvojno okolje, je predmetna oblika Microsoftovega basica, ki ima nekaj skladenjskih posebnosti, vendar še vedno ohranja vse značilnosti jezika basic, kot je tolmačeno izvajanje, uporaba nenapovedanih spremenljivk ipd. Naštete



prednosti basica so morda za začetnika olajšanje, vendar skrivajo tudi nekaj pasti. Visual basic je zato nadgrajen z ukazi, ki ga prelevijo v bolj dosleden računalniški jezik, pozna predmetne razširitve, zato se lahko primerja z najzmogljivejšimi programerskimi orodji. 3.3 PREDMETI IN ZBIRKE PODATKOV Predmet (object) je ime za skupek podatkov in pripadajoče programske kode, ki se z njimi ukvarja. Osnovni predmeti, ki smo jih že omenili, so gradniki uporabniškega vmesnika: obrazec, gumb, seznam, menijska izbira itd. V programski kodi je na voljo še nekaj posebnih predmetov, ki jih med načrtovanjem ne moremo uporabiti. S tehnologijo predmetnega povezovanja nam visual basic omogoča uporabo predmetov drugih programov, ki so nameščeni v našem računalniku ali pa se izvajajo kje v omrežju, v katerega smo vključeni. Nove predmete lahko v celoti izdelamo v samem visual basicu. Raba zbirk podatkov je v novejših verzijah visual basica zelo preprosta, in je, kot navaja Werber (2002), v veliki meri nadomestila rabo sekvenčnih, naključnih in binarnih datotek. Za osnovno pregledovanje podatkov lahko uporabimo pripravljene, vgrajene gradnike, ki jim nastavimo nekaj lastnosti. Delujoč program dobimo, ne da bi zapisali eno samo vrstico kode. Z nadaljnjo uporabo gradnikov, pisanjem odzivnih procedur za nekatere dogodke, še posebej pa z rabo predmetnega modela lahko zbirke podatkov popolnoma obvladujemo. Ne glede na izbrani način povezovanja smo vedno izolirani od fizičnega dela z datotekami. Zbirka podatkov (database) je ponavadi ena ali več datotek z večjo količino smiselno urejenih podatkov, pa tudi orodij za njihovo obdelovanje. Podatki so znotraj zbirke urejeni v tabelah. Tabela (table) je skupina istovrstnih zapisov, zapis (record) pa je sestavljen iz enega ali več polj. Polje (field) je podatek osnovnega podatkovnega tipa. Zapisom tabele pogosto rečemo tudi vrstice, poljem pa stolpci tabele. V določenem trenutku je neposredno dostopna samo ena vrstica tabele. Nanjo kaže podatkovni kazalec (cursor). Zapis v tej dejavni vrstici imenujemo tudi trenutni zapis (current record). Če želimo doseči kak drug zapis, moramo najprej prestaviti podatkovni kazalec. Ker so zbirke podatkov samo posebna vrsta datotek, so zapisi v tabelah urejeni v naravnem vrstnem redu, tako kakor so bili dodani. Če bi bilo treba po vsakem dodajanju vso datoteko urediti, bi to vzelo silno veliko časa, hkrati pa bi imeli le en način urejanja podatkov. Urejenost podatkov v tabeli zato določajo posebni seznami, ki vključujejo le zaporedje zapisov, urejenih po določenem merilu. Tak seznam imenujemo indeks. Tabela, ki ima enega ali več indeksov, omogoča nadvse hitro preiskovanje, tabele brez indeksov pa je mogoče preiskovati le zaporedno (sequential), zapis za zapisom, od začetka do konca. Zbirke podatkov lahko - to je predvsem odvisno od oblike, kako so zapisane -vključujejo še orodja za obdelovanje tabel. To so poizvedbe, pogledi, poročila in podobno. Poizvedba (query) je ukaz, ki iz ene ali več tabel izlušči novo tabelo s podatki, ki nas zanimajo, urejenimi po zahtevanem vrstnem redu. Pogled (view) je



kombinacija tabel in poizvedb, poročilo (report) pa je pogled, urejen za oblikovan izpis. V kodi visual basica se lahko ukvarjamo tako s tabelami kakor z izidi poizvedb, zato se je uveljavil izraz zbirka zapisov (recordset), ki lahko predstavlja kakršnokoli skupino zapisov, bodisi iz ene same tabele, bodisi izbor zapisov več tabel iz relacijske poizvedbe. Zbirke podatkov je mogoče organizirati na več načinov. Poznamo zaporedne, hierarhične, predmetne, hibridne in relacijske načine organizacije. Organizacija zbirke ne določa samo načina, kako so podatki shranjeni, temveč predstavlja logični model, ki ga uporabljamo pri njihovi rabi. Relacijski model je danes splošno uveljavljen standard. Njegov uspeh temelji predvsem na moči in razširjenosti jezika SQL, ki omogoča učinkovito modeliranje in izkoriščanje podatkov. Načrtovanje zbirke podatkov zahteva porazdelitev podatkov v relacijsko povezane tabele. Dobro načrtovana zbirka ima tabele, ki ne vsebujejo podvojenih podatkov. To opravimo z normalizacijo, ki je lahko zelo zapleten proces, vendar učinkovito izdelana zbirka omogoča hitro preiskovanje in enostavno vzdrževanje. Ključ (key) je polje ali kombinacija polj v tabeli, ki so navadno indeksirana zaradi hitrega preiskovanja. Ključ je lahko enoličen ali ne, odvisno od primera. Samo enolično določen ključ lahko določimo kot primarni. Primarni ključ (primary key) določa natančno en zapis v tabeli. Tuji ključ (foreign key) je primarni ključ neke druge tabele, s katero želimo vzpostaviti relacijo. Relacije (relation) omogočajo medsebojno povezovanje tabel po ključih. Poznamo relacije vrste »eden z enim« (one-to-one), »eden z mnogimi« (one-to-many) in »mnogi z mnogimi« (many-to-many). Tovrstnih relacij se izogibamo, rešimo jih z dvema relacijama »eden z mnogimi« s tretjo tabelo, ki obsega povezane tuje ključe obeh relacij.



4 OBSTOJEČE STANJE 4.1 POSNETEK STANJA V nalogi se omejujemo na poslovanje urbarialne skupnosti, ki zajema evidenco nepremičninskih deležev solastnikov ter ocenjevanje in razdelitev dreves oz. lesa, odkazanega za posek. Proces poteka povsem ročno, odbor skupnosti si je z računalnikom pomagal le na koncu, ko je bilo potrebno izpisati dodelitvene obrazce. Proces sestoji iz naslednjih glavnih opravil:

- odkazovanje dreves, primernih za posek; - ocenjevanje vrednosti odkazanih dreves; - ažuriranje deležev solastnikov – iz zemljiškoknjižnih evidenc je potrebno

pridobiti sveže podatke o solastnikih, ki bodo podlaga za delitev lesa; - razdelitev dreves oz. lesa med solastnike v skupnosti.

A3

Ažuriranjedeležev

solastnikov

A1

Odkazovanjedreves za posek

A2

Ocenjevanjevrednosti dreves

A4

Delitev dreves

Podatki iz zemljiške knjige

Nalog

Dodelitvenilisti

Slika 1: Proces delitve lesa

Odkazovanje dreves, primernih za posek, opravi strokovnjak gozdarske stroke. Čas trajanja tega podprocesa je sprejemljiv. Ocenjevanje dreves opravijo strokovnjaki, ki vsak zase subjektivno ocenijo vrednost posameznega drevesa, nato pa se dogovorijo za oceno, s katero se vsi strinjajo. Čas trajanja tega podprocesa je nesprejemljiv, saj traja približno teden dni.



Ažuriranje deležev opravi eden izmed članov upravnega odbora skupnosti. Čas trajanja tega podprocesa je sprejemljiv. Razdelitev lesa opravi običajno pet članov upravnega odbora skupnosti. Čas trajanja tega podprocesa je nesprejemljiv, saj traja približno 7 do 10 dni. 4.2 KRITIČNA ANALIZA Opisani proces bomo podprli z ustrezno programsko rešitvijo, ki bo omogočala bistveno skrajšanje najzahtevnejšega dela procesa, ocenjevanja vrednosti dreves in razdelitve lesa. Ocenjevanje dreves je bilo zelo subjektivno. Programska rešitev mora omogočati ocenjevanje na podlagi dvovhodnih deblovnic. To so empirične tabele, ki temeljijo na velikem vzorcu dreves. Na podlagi meritev prsnega premera drevesa (premer debla na višini 1,3 m) in ocene višine drevesa lahko iz teh tabel odčitamo prostornino, ki je osnovno merilo za vrednost drevesa. Vpeljemo še korekcijski faktor, s katerim lahko opredelimo nadpovprečne in podpovprečne primerke po rasti ali kvaliteti. Obdržali bomo tudi način neposrednega vrednotenja oz. neposrednega vpisa vrednosti drevesa. Pri drevesih bomo tudi dodali oznako, s katero bomo lahko določali ali gre za tehnični les ali les za kurjavo. Delitev lesa mora programska rešitev opraviti v določenih tolerancah, ki morajo biti nastavljive. Vrstni red dodeljevanja mora biti naključen. Drevesa, ki jih dodelimo enemu lastniku, morajo biti zaradi spravila relativno blizu. Manjvredne vrste lesa (predvsem iglavcev), morajo biti razdeljene sorazmerno. Programska rešitev mora omogočati tudi posebne želje oz. ročno dodeljevanje. Programska rešitev mora omogočati izdelavo vseh potrebnih izpisov.



5 IZDELAVA PROGRAMSKE REŠITVE 5.1 ANALIZA ZAHTEV NAROČNIKA IN ZASNOVA REŠITVE Glavnino podatkov, ki jih bomo obdelovali s programsko rešitvijo, predstavljajo deležniki in drevesa, zato bosta večji del glavnega okna programa zasedali preglednici oz. seznama teh dveh entitet. Ob obeh preglednicah bomo nanizali ukazne gumbe, s katerimi bomo sprožali posamezne delovne procedure. Eden od ciljev programske rešitve je tudi intuitiven in pregleden vmesnik, brez nepotrebnih okraskov. Varovanje pred neželenimi akcijami bomo rešili z omogočanjem in onemogočanjem ukaznih gumbov. Sporočanje z sporočilnimi okni bomo omejili na nujni minimum. Vnosna okna bodo imela enak razpored ukaznih gumbov. Vrednotenje dreves je zelo pomemben del programske rešitve, saj je podlaga za pravilna razmerja med končnimi vrednostmi dreves, posledično pa pravilno vrednotenje prinaša zadovoljstvo strank, v našem primeru deležnikov. Ocena količine oz. prostornine lesa, ko drevo še stoji, ni enostavna.

0,35

0,4

0,45

0,5

0,55

Deb10 Deb20 Deb30 Deb40 Deb50 Deb60 Deb70

bukev

hrast

gaber

topol

jelša

bor

macesen

breza

Slika 2: Primerjava prostorninskih faktorjev posameznih drevesnih vrst

Za ilustracijo, hrast z enakim prsnim premerom in enako višino daje večjo količino lesa kot bukev, čeprav sta drevesni vrstni skoraj enakovredni. Razlika proti drugim



drevesnim vrstam je še večja. Skupaj z naročnikom smo se odločili, da uberemo srednjo zahtevnostno pot in iz dvovhodnih deblovnic (Kotar, 2003) izračunamo razmerja oz. prostorninske faktorje, ki prostornino drevesa primerjajo z prostornino valja z enakim premerom in višino. Ugotovili smo namreč, da so napake pri tovrstnem izračunu zadovoljivo majhne oz. da je vrednotenje dovolj natančno. Za končno določitev vrednosti pa uporabimo še korekcijski faktor, s katerim znotraj iste drevesne vrste pomnožimo podpovprečne in nadpovprečne primerke, ter tržno ceno. Obdržali smo tudi neposreden vpis vrednosti drevesa, način vrednotenja bomo izbirali v meniju Nastavitve. Zaradi tega, da bomo v vsakem trenutku lahko videli vrednost posameznih dreves, bomo kljub normalizaciji in načelu, da v zbirke podatkov ne zapisujemo vrednosti, ki jih lahko izračunamo, v tabelo dreves dodali tri polja in sicer Prostornina, Vrednost in Relativni delež. Delitev dreves je glavni proces, zaradi katerega smo pravzaprav zasnovali programsko rešitev.

Začetek

Izbor lastnika

Postavitev nazačetek tabele

dreves

Dodelitevnaslednjega

prostega drevesa

Je skupnavrednost v mejah?

Preklic dodelitve

Konec

PREVEČ

DA

PREMALO

Slika 3: Diagram poteka osnovnega principa delitve



Osnovni princip delitve je, da deležniku dodeljujemo drevesa, dokler vsota relativnih deležev dodeljenih dreves ne doseže deleža, ki ga ima deležnik v skupnosti. Uporabimo faktorja za spodnjo in zgornjo mejo, npr. 0,92 in 1,02, s katerima reguliramo velikost ostanka ob koncu delitve (ko razdelimo vsem). Ena od zahtev naročnika je, da moramo sorazmerno razdeliti manjvreden les – iglavce. Zaradi tega vpeljemo še en koeficient, delež iglavcev v skupni lesni masi. Znotraj deleža, ki ga dodelimo posamezniku, moramo dodeliti določen delež iglavcev. Postopek delitve zajema torej dvojni prehod tabele dreves, v prvem dodelimo iglavce, v drugem pa ostale drevesne vrste. Vrstni red v tabeli dreves je naraven, kar pomeni, da so zaporedne številke dreves skupaj tudi fizično – v naravi. Ker ob delitvi jemljemo prosta drevesa po vrsti, s tem izpolnimo tudi zahtevo, da posameznik dobi drevesa, ki so v naravi relativno blizu. Vrstni red dodeljevanja mora biti naključen, zato pred delitvijo opravimo žreb vrstnega reda. Ob delitvi bi lahko prišlo do situacije, da bi posameznik z velikim deležem dobil veliko število majhnih dreves. Hkrati bi lahko majhnih dreves zmanjkalo za tiste z malimi deleži. Zaradi tega vpeljemo nastavitev 'Število malih'. Določenemu številu najmanjših 'delničarjev' dodelimo les najprej. Tako 'poberemo' mala drevesa in se izognemo navedenemu problemu. Z nastavitvami parametrov, ki smo jih navedli, se bomo lahko igrali in našli take vrednosti, da bo delitev optimalna. Ob dodeljevanju se bo sproti računal tudi odstotek odstopanja, ki smo ga poimenovali 'toleranca'. Če lastnik nima dodeljenega nobenega drevesa, je njegova toleranca -100. Dodeljevanje bomo lahko izvedli:

- avtomatsko: izbranemu lastniku procedura dodeli drevesa tako, da je njegova toleranca znotraj spodnje in zgornje meje;

- serijsko avtomatsko: vsem, ki nimajo dodeljenih dreves, dodelimo drevesa avtomatsko;

- ročno: izbranemu lastniku dodeljujemo posamezna drevesa, hkrati pa lahko posamezna drevesa tudi odvzemamo.

Z ročnim dodeljevanjem lahko izpolnimo morebitne posebne želje deležnikov. 5.2 ZASNOVA PODATKOVNEGA MODELA Podatkovna zbirka je v osnovi sestavljena iz dveh delov, lastnikov in dreves. Pri deležnikih evidentiramo ime, priimek, datum rojstva, bivališče in delež, ki ga ima v skupnosti. Pri drevesih pa evidentiramo vrsto, premer, višino, korekcijski faktor, vrednost, relativni delež in tip. V podatkovni zbirki se po normalizaciji znajdejo naslednje tabele:

- deležnik, - drevo,



- dodelitev, - postavka dodelitve, - vrstni red, - vrsta drevesa, - pošta.

Slika 4: Entitetno relacijski diagram

5.3 STRUKTURA PODATKOVNIH TABEL

Deleznik ID_deleznika samoštevilo Sifra število Ime besedilo Priimek besedilo DeklPriimek besedilo DatRojstva datum/čas Naslov besedilo Posta število Stevec število Imenovalec število Opomba besedilo Obdelan da/ne



Drevo ID_drevesa samoštevilo Dodelitev število Stevilka število Vrsta število Premer število Visina število KorFaktor število Tip besedilo Obdelan da/ne Prostornina število Vrednost število RelDelez število

Dodelitev ID_dodelitve samoštevilo Leto besedilo SkPrispevek število DelezIglavcev število SpMeja število ZgMeja število StMalih število ImeBesedila besedilo PredsednikGUS besedilo DirVrednotenje da/ne

Postavka_dodelitve ID_postavke samoštevilo Dodelitev število Deleznik število Drevo število

Vrsta_drevesa ID_vrste samoštevilo Ime besedilo Cena število Deb10 število Deb20 število Deb30 število Deb40 število Deb50 število Deb60 število Deb70 število

Vrstni_red ID samoštevilo Dodelitev število Deleznik število ZapSt število



5.4 ZASNOVA PROGRAMSKE REŠITVE 5.4.1 UPORABNIŠKI VMESNIK V razvojnem okolju visual basica odpremo nov podatkovni projekt (DataProject). V naš novi projekt se tako že vključi čarovnik za konfiguriranje podatkovnega okolja (DataEnvironment), kjer brez pisanja kode nastavimo vse parametre za povezavo z našo zbirko podatkov. Sledi načrtovanje obrazcev. Glavno okno programa sestavljata dva gradnika tipa DataGrid in pripadajoči ukazni gumbi.

Slika 5: Razvoj glavnega okna programa

Pri načrtovanju lahko povezavo z zbirko podatkov naredimo v programski kodi. Prav tako lahko programsko kreiramo poizvedbe, ukaze in poročila. V naši rešitvi je uporabljeno podatkovno okolje (DataEnvironment), ki nam omogoči lažje kreiranje obrazcev, ki vsebujejo polja, povezana z zbirko podatkov. Tak razvoj rešitve je sicer enostavnejši od pisanja kode, vendar je tudi manj prilagodljiv in včasih težaven zaradi svojih posebnosti.



Slika 6: DataEnvironment Designer

Osnovno okno programa nam takoj prikaže tabeli deležnikov in dreves. Gradnika DataGrid z lastnostmi DataMember in DataSource povežemo z ustreznima poizvedbama.

Slika 7: Glavno okno programa



V gradnikih DataGrid ne dovolimo popravljanja podatkov, kar onemogočimo z lastnostjo AllowUpdate=False. Podatke o deležnikih in drevesih lahko popravljamo v vnosnih obrazcih. Lahko pa podatke sortiramo in sicer s klikom na naslovno področje posameznega stolpca. To dosežemo z naslednjo proceduro: Private Sub dgDrevesa_HeadClick(ByVal ColIndex As Integer)

Dim ImeStolpca As String

ImeStolpca = deUrbarija.rsDrevesa.Fields(ColIndex).Name

deUrbarija.rsDrevesa.Sort = ImeStolpca

End Sub

S tem in z vertikalnima drsnikoma lahko zelo hitro pridemo do želenega zapisa, zato na osnovnem obrazcu ne potrebujemo kontrolnikov za premikanje po zapisih. Če želimo zapis popraviti, se postavimo nanj in kliknemo gumb Ažuriranje. Ukazna procedura prikaže ustrezni obrazec.

Slika 8: Obrazec za ažuriranje deležev



Na vnosnem obrazcu imamo gumbe za krmarjenje po zapisih, ter gumbe za vnos novega osebka, izbris obstoječega osebka, popravljanje podatkov ter izhod. Gumb 'Izračun deležev' je privzeto onemogočen. Omogočen postane, če spremenimo posamezen zapis, ista procedura pa se izvede tudi ob izhodu iz tega obrazca. Rezultat procedure je sporočilo, ki nam pove, če so deleži usklajeni ali ne. Deleži so usklajeni, če je skupni seštevek deležev 1. Program sicer omogoča nadaljnje delo tudi ob neusklajenih deležih, da lahko popravljanje začasno tudi odložimo. Procedura, ki izračuna seštevek deležev je naslednja: Private Sub cmdDelezi_Click()

Me.MousePointer = vbHourglass

Dim Vsota As Double

With deUrbarija.rsPreveriDeleze

.Open

Vsota = !vsota

.Close

End With

If CSng(Vsota) = 1 Then

MsgBox "Deleži so usklajeni."

Else

MsgBox "Deleži NISO usklajeni!"

End If

Me.MousePointer = vbDefault

cmdDelezi.Enabled = False

End Sub

Zbirko zapisov rsPreveriDeleze zgradi v podatkovno okolje (DataEnvironment) vgrajen preprost SQL ukaz, ki ima naslednjo obliko:

SELECT SUM(Stevec/Imenovalec) AS vsota FROM DELEZNIK

Procedura vrne sporočilo o neusklajenih deležih že ob najmanjši možni spremembi. Zelo podobno je narejen obrazec za ažuriranje dreves. Izgled in razpored gumbov je enak, drugačna so le vnosna polja. Omenili smo že, da mora programska rešitev podpirati dva načina vrednotenja. V meniju Nastavitve se nahaja izbira Neposredno vrednotenje, ki jo lahko vklopimo ali izklopimo.

Slika 9: Menijska izbira 'Neposredno vrednotenje'



Z lastnostjo Checked vidno označimo menijsko izbiro, nastavitev pa shranimo v tabeli skupaj z ostalimi nastavitvami. Tako je pravilna nastavitev ohranjena tudi ob naslednjem vstopu v program. Nastavitev shrani naslednji podprogram: Private Sub mnuVrednotenje_Click()

With deUrbarija.rsNastavitve

.Open

If !DirVrednotenje = True Then

!DirVrednotenje = False

mnuVrednotenje.Checked = False

Else

!DirVrednotenje = True

mnuVrednotenje.Checked = True

End If

.Update

.Close

End With

End Sub

Zbirko zapisov rsNastavitve zgradi v podatkovno okolje (DataEnvironment) vgrajen preprost SQL ukaz, ki ima naslednjo obliko:

SELECT * FROM DODELITEV ORDER BY Leto DESC

Nastavitve se sicer običajno shranjujejo v datoteke ali v register. V našem primeru so vezane na posamezno leto, zato jih skupaj z ostalim hranimo kar v zbirki podatkov.

Slika 10: Obrazec za ažuriranje dreves



Posamezne gumbe obrazca omogočamo, onemogočamo in prikazujemo s spreminjanjem lastnosti Visible in Enabled in s tem dosežemo, da so aktivni samo tisti gumbi, ki jih v določenem trenutku lahko uporabimo. Popravljanja teh lastnosti je sicer veliko, vendar tako odpade potreba po pretiranem številu sporočilnih oken, ki bi uporabnika obveščala o nedosegljivosti posamezne procedure. Zaradi lažjega vnosa smo k polju Korekcijski faktor dodali tudi gumba, ki za pet odstotkov povečujeta in zmanjšujeta vrednost polja. Možnost, da v polje napišemo vmesno vrednost, pa seveda ostaja. Ko spremenimo katerikoli zapis, postane tudi tu omogočen gumb Izračun deležev. To proceduro lahko prav tako, kot pri lastnikih, poženemo ročno, če je potrebno, pa se izvede tudi ob kliku na gumb Izhod. Procedura preračuna relativne deleže dreves glede na skupno vsoto vrednosti. Ker moramo popraviti prav vse zapise v tabeli dreves, to traja nekaj – včasih motečih – sekund. Če obrazec zapustimo tako, da ga zapremo s kontrolnim gumbom, se ta preračun ne izvede. Da ob preračunu ne pride do dodatne izgube časa pri prikazovanju sprememb v gradniku DataGrid, za čas preračuna spremenimo njegovo lastnost DataMember, jo ob koncu popravimo nazaj ter gradnik osvežimo. Procedura zgleda takole: Private Sub cmdDelezi_Click()

Me.MousePointer = vbHourglass

frmUrb.dgDrevesa.DataMember = ""

Dim Vsota As Long

With deUrbarija.rsPopDelezeDreves

.Open

Vsota = !Vsota

.Close

End With

With deUrbarija.rsDrevesa

.Update

.MoveFirst

Do While Not .EOF

!Delez = !Vrednost / Vsota

.MoveNext

Loop

.Sort = "Stevilka"

.MoveFirst

End With

Me.MousePointer = vbDefault

cmdDelezi.Enabled = False

frmUrb.dgDrevesa.DataMember = "Drevesa"

frmUrb.dgDrevesa.Refresh

End Sub



Zbirko zapisov rsPopDelezeDreves zgradi v podatkovno okolje (DataEnvironment) vgrajen preprost SQL ukaz, ki ima naslednjo obliko:

SELECT SUM(Vrednost) AS vsota FROM DREVO

5.4.2 ŽREB IN DELITEV Preden se lotimo procedur razdeljevanja, poglejmo še obrazec nastavitev. Na njem zberemo vse parametre, ki jih je možno nastaviti v naši programski rešitvi.

Slika 11: Obrazec nastavitev

Večji del obrazca je namenjen besedilu, ki ga bomo uporabili na dodelitvenem listu. Besedilo je shranjeno v tekstovni datoteki, ki jo ob nalaganju obrazca preberemo: Private Sub Form_Load()

Dim Vrstica As String

Open App.Path & "\Besedilo.txt" For Input As #1

txtBesedilo.Text = Empty

Do While Not EOF(1)

Line Input #1, Vrstica

txtBesedilo.Text = txtBesedilo.Text & Vrstica & vbCrLf

Loop

Close #1

End Sub

Po morebitnem popravljanju je potrebno datoteko shraniti. Datoteki smo, da je ročno ne moremo popravljati, nastavili atribut 'Samo za branje'. Tega pred shranjevanjem odstranimo, datoteko shranimo in atribut nastavimo nazaj: SetAttr App.Path & "\Besedilo.txt", vbNormal

Open App.Path & "\Besedilo.txt" For Output As #1

Print #1, txtBesedilo.Text

Close #1

SetAttr App.Path & "\Besedilo.txt", vbReadOnly



V meni nastavitve smo pripravili tudi obrazec, ki iz vnesenih dreves izračuna majhno statistično poročilo.

Slika 12: Statistika

V meni 'Nastavitve' smo umestili tudi šifrant drevesnih vrst.

Slika 13: Šifrant drevesnih vrst

Vrednost predstavlja tržno ceno posamezne vrste lesa na poljubno enoto, pomembna so le pravilna razmerja med vrstami. Faktorji Deb10 do Deb70 pa so prostorninski koeficienti, ki jih uporabljamo za določitev realne prostornine oz. količine lesa v posameznem primerku. Po ažuriranju lastnikov, dreves ter nastavitvi parametrov se lahko posvetimo sami delitvi. V zvezi s tem opravilom imamo 6 gumbov oz. procedur.



Žreb Z žrebom zagotovimo, da vrstni red dodeljevanja ne bo vedno enak, zato tisti, ki se piše na A, ne bo vedno dobil dreves na začetku gozda. Iz žreba izvzamemo določeno število najmanjših lastnikov, to število nastavimo s parametrom StMalih. Malim dodelimo začetne zaporedne številke in jih s tem postavimo na začetek vrstnega reda delitve. Ostalim z generatorjem naključnih števil določimo zaporedne številke. Private Sub cmdZreb_Click()

Dim i As Integer

Call Tamali

With deUrbarija.rsDelezi

.Sort = Empty

.MoveFirst

Do While Not .EOF

Randomize

If !Obdelan = False Then

!Zst = Rnd + 10

!Obdelan = True

End If

.MoveNext

Loop

.Sort = "ZSt"

.MoveFirst

End With

Call NasloveSkup

End Sub

Sestavni del žreba je še procedura 'NasloveSkup', ki lastnike, ki živijo na istem naslovu, 'zloži' skupaj. S tem izpolnimo zahtevo naročnika, da družinskim članom dodelimo drevesa, ki so v gozdu relativno skupaj: Private Sub NasloveSkup()

Dim Zap As Single

Dim Biv As String


.Sort = "Bivalisce"

.MoveFirst

Do While Not .EOF

Zap = !Zst

Biv = !Bivalisce

.MoveNext

If .EOF Then

.MoveLast

Exit Do

End If

If !Bivalisce = Biv Then

!Zst = Zap

End If

Loop

.Sort = "ZSt"



.MoveFirst

End With

End Sub

Dodeljevanje izbranemu lastniku Z ukaznim gumbom 'Dodeli izbranemu' poženemo osnovno proceduro delitve. Ta izbranemu lastniku dodeli drevesa tako, da mu najprej dodeli delež manjvredne drevesne vrste – iglavcev, nato pa še ostale drevesne vrste. Vrednost dodeljenih dreves mora biti v mejah, ki smo jih nastavili. Mogoče je, da lastniku ne bo možno dodeliti takih dreves, da bi izpolnili vse pogoje. Takrat njegova toleranca ne pride v območje, ki smo ga nastavili. Dodeljevanje vsem V tej proceduri dodelimo drevesa vsem lastnikom, ki imajo toleranco -100, ostale pa preskočimo. Dodelitev izvedemo z zaporednimi klici osnovne procedure 'Dodeli izbranemu'. Čas trajanja ponazorimo s časovnim trakom in zaradi prihranka časa gradniku DataGrid na začetku spremenimo lastnost DataMember, na koncu pa jo popravimo nazaj. Private Sub cmdDodeliVsem_Click()

dgDrevesa.DataMember = ""


.Sort = "ZSt"

.MoveFirst

Do While Not .EOF

Call cmdDodeli_Click

pbBar.Value = .AbsolutePosition

.MoveNext

Loop

.MoveFirst

End With

pbBar.Value = 1

dgDrevesa.DataMember = "Drevesa"

dgDrevesa.Refresh

End Sub

Dodelitev in odvzem izbranega drevesa Proceduri služita ročnemu delu in morebitnemu popravljanju. Ukazna gumba sta dostopna šele v posebnem načinu prikaza tabele dreves. Do teh načinov pridemo z izbirnimi gumbi v okvirju Prikaz. Posamezno drevo lahko dodelimo samo izmed dreves, ki niso dodeljena. Zato je potrebno prikaz preklopiti na drevesa brez lastnika, s čimer tudi omogočimo gumb za dodelitev. Gumb za odvzem omogočimo, ko izberemo prikaz dreves izbranega lastnika. Odločili smo se, da uporabniku ne bomo na ekran pošiljali nadležnih sporočilnih oken, dovolj je že, da mora preklopiti prikaz, ko želi narediti kaj ročno. Ob odvzemih in dodelitvah se vsakokrat sproti izračuna trenutna toleranca, tako da takoj vidimo ali ima lastnik preveč ali premalo dodeljenega lesa.



Slika 14: Izbirni gumbi prikaza

Zbirko zapisov rsDrevesaIzbranegaLastnika, ki služi za prikaz in izračun tolerance, zgradi v podatkovno okolje (DataEnvironment) vgrajen preprost SQL ukaz SELECT * FROM DREVO WHERE (StLastnika = ?)

ki pa mu parameter StLastnika dostavimo ob klicu: Private Sub optLastnik_Click()

cmdOdvzemiDrevo.Enabled = True

cmdDodajDrevo.Enabled = False

On Error Resume Next

deUrbarija.rsDrevesaIzbranegaLastnika.Close

deUrbarija.DrevesaIzbranegaLastnika & _

CInt(deUrbarija.rsDelezi!Sifra)

dgDrevesa.DataMember = "DrevesaIzbranegaLastnika"

dgDrevesa.Refresh

End Sub

Brisanje dodelitev Izbrišemo lahko vse dodelitve naenkrat, izbrišemo pa lahko tudi dodelitev izbranemu posamezniku. Ob brisanju je potrebno osvežiti tolerance oz. jih postaviti na začetno vrednost -100. 5.4.3 POROČILA Najpomembnejše poročilo je dodelitveni list, s katerim lastnika – deležnika obvestimo o dodeljenih drevesih. Delo z vgrajenim urejevalnikom poročil je precej zamudno, ker je treba vse postoriti 'peš'.



Slika 15: Urejevalnik poročil

Za relativno velik problem se pokaže že številčenje postavk v sestavljenem poročilu. Zgraditi je potrebno novo zbirko zapisov: SELECT Stevilka, VrstaDrevesa, Vrednost, Tip, (SELECT COUNT(*)

FROM tblDrevesa A2 WHERE A2.Stevilka <= A1.Stevilka AND

StLastnika=?) AS SerialNo FROM tblDrevesa A1 Where

StLastnika=?

Vsebino posameznega poročila zgradimo v dogodku Initialize, kjer popravimo in dopolnimo vsebino z dejanskimi vrednostmi, npr.: With repDodelitev.Sections("Section4").Controls

.Item("lblZst").Caption = .Item("lblZst").Caption & _

CStr(deUrbarija.rsDelezi!Sifra)

.Item("lblDatum").Caption = .Item("lblDatum").Caption & _

Format(Date, "d. mmmm YYYY")



.Item("lblZaLeto").Caption = .Item("lblZaLeto").Caption & _

CStr(Leto)

End With

Naročnik želi, da bi lahko dodelitvene obrazce tiskal tudi serijsko. Zaradi tega smo v meni dodali izbiro 'Dodelitveni listi – serijsko', v odzivni proceduri pa ob klicu poročila namesto metode Show uporabimo metodo PrintReport.

Slika 16: Serijski izpis

Vsako zgrajeno poročilo moramo sproti uničiti z ukazom Set repDodelitev = Nothing

Če tega ne storimo, se dogaja, da predmet (poročilo) ob inicializaciji ne spremeni vsebine, ker že obstaja v pomnilniku. Poleg glavnega poročila – dodelitvenega lista – so na voljo še izpisi o nerazdeljenem lesu in deležnikih.



Slika 17: Dodelitveni list - poročilo



5.4.4 ZAŠČITA Našo programsko rešitev bomo tudi prodajali, zato smo se odločili, da vključimo zaščito proti nepooblaščenemu kopiranju. V ta namen smo uporabili proceduro, ki ob vsakem zagonu programa preveri, če se še vedno nahaja na istem računalniku kot ob namestitvi. Če se ne, se uporabnik znajde pred aktivacijskim oknom, ki ga povpraša po aktivacijski kodi. Če le-te ne vnesemo, se program zapre.

Slika 18: Aktivacijsko okno

Ključ, ki ga ponudi aktivacijska procedura, je zgrajen glede na identifikacijske podatke o strojni opremi računalnika in je unikat. Aktivacija po potrditvi vnosa preveri verodostojnost kode in nato dovoli uporabo programa, če je koda pravilna. Ko je izdelek aktiviran, se okno ne pojavi več. Aktivacija je v zadnjem času postala široko uporabljan način zaščite pred nezaželeno uporabo programov. Prvi jo je poskusno uvedel Microsoft v nekaterih verzijah izdelka Office 2000. Po začetnem uspehu pa so jo vgradili v vse nadaljnje izdelke družine Windows in Office. Ta praksa je postala predmet debate, glavne kritike pa so (Wikipedia, 2006):

- aktivacija povzroča neprijetnosti uporabniku, sploh če mora telefonsko aktivirati izdelek, če požarni zid blokira izmenjavo podatkov ali če aktivacijski strežnik ni na voljo;

- če aktivacije ni mogoče ponovno izvesti na nadgrajenem ali novem računalniku, je to lahko tudi nelegalno;

- če izdajatelj propade, je lahko uporaba programa po ponovni namestitvi nemogoča, čeprav smo ga kupili;

- vprašljivo je tudi zbiranje osebnih podatkov ob aktivaciji. Danes se tudi na slovenskem trgu že pojavljajo komercialni izdelki, ki ponujajo rešitev, ki jo vgradimo v naš program.



5.4.5 DISTRIBUCIJA PROGRAMSKE REŠITVE Distribucijo izdelka bomo izvedli tako, da bomo pripravili standardni namestitveni paket, v katerem bodo vse potrebne datoteke. Pri tem si pomagamo z čarovnikom, ki je priložen razvojnemu okolju Visual Studio.

Slika 19: Čarovnik za izdelavo namestitvenih paketov

Uporabili bomo prvo možnost, torej izdelavo distribucijskega paketa. Ta nam omogoča izdelavo paketa, ali pa zgradi samo datoteko odvisnosti (Dependency File), to je seznam komponent, ki jih program potrebuje, ko teče.

Slika 20: Tip paketa



Namestitvenemu paketu je potrebno priložiti tudi gonilnike za dostop do podatkov (DAO Drivers). Uporabili smo podatkovni stroj JET.

Slika 21: Izbira podatkovnih gonilnikov

V namestitveni paket je potrebno dodati tudi zbirko podatkov in ostale pomožne datoteke.

Slika 22: Dodajanje ostalih datotek

Sledijo koraki z izbiro velikosti posameznih *.cab datotek, izbiro imena namestitve, konfiguracijo bližnjic za zagon programa, lokacij za namestitev programskih knjižnic, izbiro datotek v skupni rabi, shranimo lahko nastavitve za ta paket in končno dobimo tri namestitvene datoteke, s katerimi bomo nameščali našo programsko rešitev.



Slika 23: Nameščanje programske rešitve

5.4.6 TESTIRANJE Ko programsko rešitev postopoma gradimo, sproti testiramo vsako izdelano celoto (posamezno funkcijo ali več funkcij, ki so odvisne ena od druge). Na koncu testiramo še celotni program (ali sistem), saj ni rečeno, da bodo sicer posamezno pravilno delujoče funkcije pravilno delovale, ko bodo med seboj povezane v celoto. Za testiranje si moramo vnaprej ‘na papirju’ pripraviti tabelo podatkov, ki jih bomo vnašali, in pričakovanih rezultatov. Pričakovane rezultate moramo (ročno, s kalkulatorjem…) pripraviti vnaprej, ker bomo le na ta način lahko odkrili morebitne napake ali nepravilnosti v delovanju. Testiramo z nekaj podatkov iz nabora dovoljenih vrednosti in s podatki iz vseh skupin nedovoljenih vrednosti. Še posebej pa se osredotočimo na mejne vrednosti med dovoljenimi in nedovoljenimi. Pri načrtovanju moramo natančno določiti, kako bo program ukrepal pri nedovoljenih vhodnih podatkih. S predstavniki naročnika smo se dogovorili, da bodo preizkusili prototipno verzijo programske rešitve. S tem, ko program pregleda še nekdo, ki ni sodeloval pri programiranju, lahko hitro odkrijemo kako banalno napako, ki nam, razvijalcem, ni prišla na misel. Prvi vtisi so bili zelo dobri, večjih napak ni bilo, pojavilo pa se je nekaj dodatnih idej, sprememb in poenostavitev.



Programsko rešitev smo skušali načrtovati tako, da bi bilo možno kar najhitreje izvesti opravila, ki zahtevajo največ časa. Vnos dreves je eno takih opravil, zato smo pazljivo nastavili lastnost TabIndex gradnikov v vnosnem oknu. S kombinacijo miške in numeričnega dela tipkovnice tako lahko zelo hitro vnesemo veliko število zapisov. Naj omenimo še eno težavo, na katero smo naleteli pri vnosnih poljih. Visual basic namreč ne prebere regionalnih nastavitev operacijskega sistema in tako med vnosom ne prepozna decimalne vejice kot decimalnega ločila. Oviro smo obšli tako, da bdimo nad dogodki Keypress, in če se pojavi vejica, jo urno spremenimo v piko. Private Sub txtKorFaktor_KeyPress(KeyAscii As Integer)

Dim Znak As String * 1

Znak = Chr(KeyAscii)

If Znak = "," Then

KeyAscii = Asc(".")

End If

End Sub

Vsebino vnosnega polja, če obstaja, ob dogodku GotFocus označimo in tako uporabniku ni potrebno brisati vsebine, če želi vnesti drugačno vrednost. Private Sub txtKorFaktor_GotFocus()

txtKorFaktor.SelStart = 0

txtKorFaktor.SelLength = Len(txtKorFaktor.Text)

End Sub

Ob intenzivni uporabi programske rešitve se bo verjetno pojavil še kak predlog za izboljšanje, zelo verjetno se bo pojavila še kakšna napaka. Popravljanje seveda sodi v normalni življenjski cikel programske opreme – vzdrževanje.



6 ZAKLJUČKI 6.1 OCENA UČINKOV Poslovanje s pomočjo računalnika prodira na vsa področja našega dela. Kjerkoli je potreben kakršenkoli izračun, računalnik to opravi hitreje in natančneje od človeka. S tem, da taka in podobna opravila prepustimo stroju, lahko samo pridobimo. Z implementacijo naše programske rešitve v Urbarialni skupnosti Dobrovnik v osnovi prihranimo predvsem pri času, ki ga porabimo za opravilo deljenja. Če pa razmišljamo malo širše, znatno izboljšujemo kriterij natančnosti in s tem zadovoljstvo strank, v našem primeru deležnikov skupnosti. Vendar so tudi s takim načinom razdeljevanja lahko posamezni deležniki nezadovoljni, saj se slej ko prej pojavi nekdo, ki mu dodelitev ne ustreza. Glede skupne ravni zadovoljstva vpletenih v proces pa je vpeljava programske rešitve gotovo napredek in ker je delitev naključna, bo letošnji nezadovoljnež, po verjetnostnem računu, prihodnje leto gotovo boljše volje. Glavno proceduro programske rešitve, deljenje, današnji povprečen računalnik opravi v dvajsetih sekundah. Predstavniki naročnika ob predstavitvi prototipne rešitve niso mogli verjeti, da je delitev pravilna, saj je njihov odbor petih ljudi za delitev potreboval teden dni. Šele po nekaj ročnih preračunih so uvideli, da je izračun pravilen in zaupanje v prototip je pričelo rasti. Sedaj programski rešitvi zaupajo tudi izkušenejši, starejši člani urbarialne skupnosti, ki so zasnovali prejšnji sistem. Čeprav nekateri principa izračuna povsem ne razumejo, so uvideli, da bo 'po novem' lažje. Izborili so si le, da bo deljenje še vedno potekalo pred širšim odborom, tako da funkcija odbornika urbarialne skupnosti ni izgubila vrednosti. Velika pridobitev je tudi uporaba dvovhodnih deblovnic, kot osnovne podlage za izračun vrednosti posameznega drevesa. Tudi tukaj smo prihranili približno 100 ur dela, saj lahko dve vrednosti, ki jih potrebujemo za ocenitev posameznega primerka, zelo hitro določimo, eno pa izmerimo. Odpadejo prejšnja pogajanja in subjektivnost ocen. Glavnino dela v gozdu sedaj predstavlja označevanje dreves, to delo pa bo ostalo tako ali drugače. Ker je izračun delitve zelo hitro narejen, se lahko igračkamo z nastavitvami parametrov in poskušamo delitev opraviti na več načinov, tako da imamo kar najmanj ročnega dela.



6.2 POGOJI ZA UVEDBO Osnovni pogoj za uvedbo programske rešitve je posedovanje ustreznega računalnika in tiskalnika. Programska rešitev je nezahtevna do strojne opreme, kakršenkoli danes kupljen računalnik je več kot dovolj zmogljiv za uporabo programa. Od hardvera potrebujemo še tiskalnik, na katerem bomo izpisovali dodelitvene liste in ostala poročila. Programska rešitev deluje v okolju Windows, tako na Windows 98, kot tudi na Windows XP. Zadovoljimo se lahko tudi s starejšim, rabljenim računalnikom, pripravljeni moramo biti le na to, da bo izračun delitve trajal nekaj sekund več. 6.3 MOŽNOSTI NADALJNJEGA RAZVOJA Programska rešitev v tej fazi še ne omogoča tega, da bi delo opravili brez papirja. Ob odkazovanju in ocenjevanju dreves, si moramo podatke še vedno beležiti ročno, na papir. Uporabljali bi lahko tudi prenosni računalnik, a se izkaže, da je preneroden za prenašanje po gozdu, sploh ob slabem vremenu. Pojavi se tudi vprašanje avtonomije oz. zmogljivosti akumulatorja. Ena od rešitev je uporaba dlančnika, ki je dovolj majhen in priročen za delo oz. vnašanje podatkov v gozdu, hkrati pa omogoča dovolj avtonomije, da je njim mogoče normalno delati. S tem se rešimo podvojenega dela ob vnosu podatkov o drevesih, saj jih lahko z enostavno proceduro uvozimo v našo aplikacijo. Podpora vnosa podatkov z dlančnikom in uvoz podatkov bo zagotovo naslednja zmožnost (feature) naše programske rešitve. Razmišljamo pa lahko tudi o neposredni vgradnji dvovhodnih deblovnic, kot pripomočka za ocenjevanje prostornine dreves. Ta zalogaj bi bil malo večji, saj bi bilo potrebno računati aproksimacije med diskretnimi vrednostmi, ki jih vsebujejo te tabele. Pojavlja pa se vprašanje smiselnosti take natančnosti enega parametra, če pa moramo skoraj 'na oko' oceniti višino posameznega drevesa. Če bi lahko izboljšali natančnost parametra višine, pa bi bila vgradnja teh tabel smiselna. Je pa nekaj, kar naša programska rešitev ne zmore. Ne zmore, vsaj brez pomoči ne, da bi tistemu deležniku, ki nima dobrega mnenja o delu odbora gozdne urbarialne skupnosti, dodelila slaba drevesa. To pa je pomanjkljivost računalnikov. Zaenkrat.



LITERATURA IN VIRI Knjige: Kotar, M. (2003) Gozdarski priročnik, Biotehniška fakulteta, Ljubljana Mesojedec, U. (1998) Visual basic, sodobno programiranje, Pasadena, Ljubljana. Werber, B. (2002) Osnove programiranja Visual basic 6.0 na primerih, Moderna

organizacija, Kranj. Zapiski: Rozman, I.: Zapiski predavanj pri predmetu Osnove informacijskih sistemov, 2002 Zupančič, J. : Zapiski predavanj pri predmetu Programiranje, 2005 Zupančič, J. : Zapiski predavanj pri predmetu Razvoj uporabniških rešitev, 2006 Spletne strani: VB6 Language reference. http://msdn.microsoft.com, november 2006 Wikipedia. http://en.wikipedia.org, november 2006



PRILOGE Priloga 1: namestitvena zgoščenka s programsko rešitvijo KAZALO SLIK Slika 1: Proces delitve lesa.............................................................................. 20

Slika 2: Primerjava prostorninskih faktorjev posameznih drevesnih vrst .......... 22

Slika 3: Diagram poteka osnovnega principa delitve........................................ 23

Slika 4: Entitetno relacijski diagram ................................................................. 25

Slika 5: Razvoj glavnega okna programa......................................................... 27

Slika 6: DataEnvironment Designer ................................................................. 28

Slika 7: Glavno okno programa........................................................................ 28

Slika 8: Obrazec za ažuriranje deležev............................................................ 29

Slika 9: Menijska izbira 'Neposredno vrednotenje' ........................................... 30

Slika 10: Obrazec za ažuriranje dreves ............................................................. 31

Slika 11: Obrazec nastavitev ............................................................................. 33

Slika 12: Statistika ............................................................................................. 34

Slika 13: Šifrant drevesnih vrst .......................................................................... 34

Slika 14: Izbirni gumbi prikaza ........................................................................... 37

Slika 15: Urejevalnik poročil............................................................................... 38

Slika 16: Serijski izpis ........................................................................................ 39

Slika 17: Dodelitveni list - poročilo ..................................................................... 40

Slika 18: Aktivacijsko okno ................................................................................ 41

Slika 19: Čarovnik za izdelavo namestitvenih paketov....................................... 42

Slika 20: Tip paketa ........................................................................................... 42

Slika 21: Izbira podatkovnih gonilnikov .............................................................. 43

Slika 22: Dodajanje ostalih datotek.................................................................... 43

Slika 23: Nameščanje programske rešitve......................................................... 44

POJMOVNIK

dvovhodne deblovnice: empirične tablice za določanje lesnega volumna stoječih dreves

KRATICE IN AKRONIMI GUS: Gozdna urbarialna skupnost SQL: Standard query language: standardni povpraševalni jezik

Documents

Programska re itev za podporo poslovanja gozdne urbarialne ... · Visual Basic 6 in uporablja podatkovno zbirko tipa Microsoft Access. KLJU ČNE BESEDE - poslovanje, - urbarialna