VISOKOŠOLSKI STROKOVNI ŠTUDIJ

VISOKOŠOLSKI STROKOVNI ŠTUDIJ
Računalništvo in Informatika – Informatika
POROČILO PRAKTIČNEGA IZOBRAŽEVANJA
v
Modan Informatika d.o.o.
Čas opravljanja: Od 01.12.2008 do 31.5.2009
Mentor v GD Mag. Daniel Blejc, univ.dipl.ing.
Študent: Darko Jerinić
Vpisna številka: 93573363
E – pošta: darko.jerinic@gmail.com
Telefon: 031 – 493 – 064

Kazalo vsebine
1. UVOD..........................................................................................................................................
7
2. PREDSTAVITEV PODJETJA MODAN INFORMATIKA.......................................................
8
2.1. Kratek opis podjetja............................................................................................................................................
8
3. OPIS PRAKTIČNEGA IZOBRAŽEVANJA............................................................................
10
3.1. Uvajanje v delo..................................................................................................................................................
10
3.2. Pristop k projektu in potek izvedbe projekta v podjetju....................................................................................
11
3.3. Izvedba projekta poteka po naslednjih izvedbenih korakih: ............................................................................. 11
3.3.1. Definicija zahtev........................................................................................................................................................
11
3.3.2. Definicija projekta.....................................................................................................................................................
12
3.3.3. Specifikacija produkta................................................................................................................................................
13
3.3.4. Implementacija...........................................................................................................................................................
14
3.3.5. Tehnični prevzem.......................................................................................................................................................
15
3.4. VCL Loaderji....................................................................................................................................................
16
3.4.1. Uvod..........................................................................................................................................................................
16
3.4.2. Zahteve......................................................................................................................................................................
17
3.4.3. Opis VCL komponent ............................................................................................................................................... 17
3.4.4. Struktura razredov......................................................................................................................................................
20
3.4.5. XML Datoteka...........................................................................................................................................................
20
3.4.6. Funkcionalnost in delovanje modula..........................................................................................................................
24
3.4.7. Zaključek...................................................................................................................................................................
26
3.5. Razred za prevod programa...............................................................................................................................
27
3.5.1. Uvod ......................................................................................................................................................................... 27
3.5.2. Zahteve......................................................................................................................................................................
27
3.5.3. Opis datotek...............................................................................................................................................................
28
3.5.4. Delovanje razreda......................................................................................................................................................
28
3.5.5. Zaključek...................................................................................................................................................................
30
4. Pridobljeno znanje in izkušnje...................................................................................................
31
5. Mnenje o praksi..........................................................................................................................
32

Kazalo slik
Slika 3-1: cxTreeView komponenta..............................................................................................18
Slika 3-2: cxTreeList komponenta.................................................................................................18
Slika 3-3: cxGrid komponenta.......................................................................................................19
Slika 3-4: Struktura razredov modula............................................................................................20
Slika 3-5: View node.....................................................................................................................21
Slika 3-6: DataController node......................................................................................................22
Slika 3-7: DataBase node...............................................................................................................23
Slika 3-8: Program pred inicializacijo...........................................................................................24
Slika 3-9: Meni - zagon modula.....................................................................................................24
Slika 3-10: Inicializirani gradniki..................................................................................................25
Slika 3-11: Primerjava Xml in gradnika........................................................................................26
Slika 3-12: Vnos v .ini datoteki.....................................................................................................29
Slika 3-13: Nastavitve....................................................................................................................29

Kazalo tabel
Tabela 3-1 Projketne listine...........................................................................................................11
Tabela 3-2: Datoteka s prevodi......................................................................................................28
Tabela 3-3: Referenčna datoteka...................................................................................................28

1. UVOD
Poročilo o praktičnem izobraževanju je sestavljeno iz dveh delov. Jedro poročila je opis
dela, ki sem ga opravljal v času praktičnega izobraževanja. V uvodnem delu poročila je na
kratko predstavljeno podjetje. Sledi natančen opis del, ki sem jih opravljal v času mojega
praktičnega izobraževanja v podjetju Modan Informatika d.o.o. V zaključku še izrazim svoje
mnenje o praksi, o mojih izkušnjah ki sem jih pridobil.

2. PREDSTAVITEV PODJETJA MODAN INFORMATIKA
2.1. Kratek opis podjetja
Poslovna pot podjetja Modan Informatika d.o.o. se je začela leta 1995 v okviru podjetja
MCI Modan. Podjetje se je nato razvijalo v dve smeri:
• razvijanje industrijske elektronike in
• razvijanje programske opreme za računalnike.
Leta 1997 je prišlo do delitve in nastalo je novo podjetje Modan informatika d.o.o., ki je
nadaljevalo z razvojem programske opreme. V tem razvoju so se usmerili predvsem na tista
področja, ki v Sloveniji takrat še niso bila pokrita. Za Slovenski trg so priredili program za
upravljanje portfeljev vrednostnih papirjev in program za vodenje prodaje v sistemu mrežnega
marketinga. Že od vsega začetka se je dejavnost podjetja konstantno širila. Odlikujejo pa se
predvsem po prilagodljivosti specifičnim potrebam njihovih kupcev.
Njihova temeljna dejavnost je razvoj programske opreme za znanega kupca, ki dopušča
možnost razširitve funkcij in prilagoditve potrebam neznanega kupca. Z njo tesno povezane
so ostale dejavnosti:
• prodaja in servisiranje programskih paketov;
• izobraževanje o uporabi programske opreme;
• svetovanje in uvajanje naprednih rešitev (tehnologij);
• vodenje in vzdrževanje podatkovnih skladišč;
• inženiring računalniških sistemov;
• oblikovanje in izdelava spletnih strani na Internetu.
V času delovanja od začetka do zdaj so razvili štiri zaključene programske sklope in
enega, ki je v zadnji fazi izdelave. Skupna lastnost vseh je, da poenostavljajo poslovanje,
omogočajo izvajanje zapletenih ali obsežnejših procesov na enostaven in uporabniku
sprejemljiv način. Zapletene formule in postopki so predvideni in vključeni v program.
Izvršijo se na poziv uporabnika.
Rezultati njihovega dela so naslednji programski paketi:

• ARCHIVpro98
, program za arhiviranje in delo z dokumenti;
• proTRADE, program za nadzor prodaje v sistemih direktnega in mrežnega
marketinga s tremi različicami;
• WINDEX, program za upravljanje portfeljev in analiza vrednostnih papirjev;
• BAS, programski paket, ki združuje vse tri zgoraj naštete programe, ki so seveda
nadgrajeni, ter orodja za administracijo sistema.
Iz teh osnovnih produktov so izpeljane prilagojene različice za končnega kupca s
specifičnimi potrebami. Tako so nastali produkti za:
• Stanovanjski sklad občine Maribor, za vodenje stanovanj, pogodb in najemnikov;
• Probanko d.z.u., za vodenje investitorjev, investicij, transakcij,…;
• Elito, za mrežni marketing oz. trženje življenjskih zavarovanj;
• Fitness Megafit, za vodenje članstva in pregled poslovanja;
• Individa, za trženje zavarovanj, ki temelji na mrežnem marketingu;
• Itd…

3. OPIS PRAKTIČNEGA IZOBRAŽEVANJA
3.1. Uvajanje v delo
Uvajanje v delo podjetja je potekalo na naslednji način:
• Predstavitev podjetja
• Predstavitev zaposlenih v podjetju
• Predstavitev načina dela v podjetju
• Predstavitev virov informacij v podjetju ( knjige, dodatni program, projektne
dokumentacije, spletni viri, itd.. )
• Predstavitev osnovnih paketov, na katerih se izvajajo nadgradnje za končne stranke
Po predstavitvi podjetja in načina dela mi je mentor zadal naloge, ki sem jih moral
opraviti. Seznanil me je s sodelavci, katere sem lahko prosil za pomoč, pri reševanju
zastavljenih nalog, v vsakem trenutku pa sem lahko dobil pomoč tudi od mentorja.
V podjetje sem prišel z osnovnim znanjem programskega jezika C#, Delphi,
DreamWeaver ter poznavanjem teorije relacijskih podatkovnih baz in povpraševalnega
jezika SQL. Po uvodnem spoznavanju dela v podjetju sem se lotil programiranja zadane naloge.
Moja začetna naloga v podjetju je bila programiranje XML loaderja v programskem jeziku C#, s
katero bom pokazal koliko znanja imam.
V času opravljanja dela sem si veliko pomagal predvsem s projektno dokumentacijo in
literaturo, internetom in pa seveda z znanjem sodelavcev in mentorja. Naučiti sem se moral
osnov jezika XML, in dela z njim. Prav tako sem moral preučiti obstoječe programske produkte,
in loaderje narejene v drugih programskih jezikih ( Delphi )

3.2. Pristop k projektu in potek izvedbe projekta v podjetju
K vsakem projektu je potrebno izdelati ustrezno dokumentacijo. Vsak izdela dokumentacijo
za del, ki ga je implementiral. Za splošno dokumentacijo o projektu je zadolžen vodja projekta.
Dokumentacija mora zajemati:
Projektna dokumentacija
Tehnična dokumentacija
Vse listine, ki so predmet podjetja in predstavljajo
komunikacijo med izvajalci projekta in naročnikom
Je del projektne dokumentacije in vsebuje strokovno
dokumentacijo ki spremlja znanstveno-tehnično izvajanje
projekta
Dokument Je listina z uradno veljavnostjo
Vsebuje opis nekega dogodka, seznanja z določenim
Poročilo
dogajanjem, stanjem, brez osebnih pojasnil in pripomb
Tabela 3-1 Projketne listine
3.3. Izvedba projekta poteka po naslednjih izvedbenih korakih:
3.3.1. Definicija zahtev
Definicija zahtev je del projekta, ki traja od trenutka, ko predstavnik podjetja kontaktira
naročnika, do trenutka, ko so naročnikove želje definirane in potrjene z obeh strani. Hkrati je
opredeljena tehnologija, ki se uporablja za razvoj.
• Aktivnosti:
• Rezultati:
o Posnetek naročnikovih zahtev
o Analiza naročnikovih zahtev
o Globalni cilji
o Opis naročnikovih zahtev in preliminarna ocena obsega del za izvedbo projekta
o Groba ocena stroškov in časovnih okvirjev projekta
o Seznam pričakovanih dogodkov, predvidevanja, opažanja

• Spremljajoča dokumentacija
• Aktivnosti:
• Rezultati:
o Pismo o nameri ( gentlemans agreement )
o Dokument “Definicija zahtev” vsebuje:
� Poročilo “Posnetek naročnikovih zahtev” – kratek opis problema, ki ga
rešujemo. Opis je zastavljen idejno in služi globalni razsvetlitvi tematike
� Dokument “Analiza naročnikovih zahtev” – globalna analiza s tehničnega
vidika, uporaba diagramskih tehnik za predstavitev problema ( Use Case,
Activity diagram ... )
� Dokument “Uporabljene tehnologije” – prva ocena zahtev po razvojnih
orodjih
� Dokument “Splošno” – groba ocena stroškov, časovnih okvirjev projekta,
dogodki, ...
� Dokument “Uporabljene tehnologije” – prva ocena zahtev po razvojnih
orodjih
� Dokument “Splošno” – groba ocena stroškov, časovnih okvirjev projekta,
dogodki, ...
3.3.2. Definicija projekta
o Definicija osnovnih pravil, iz katerih izhajajo vsi udeleženci projekta
o Definicija aktivnosti posameznih udeležencev projekta
o Definicija projektne dokumentacije
o Definicija potrebnih resursov
o Projektni načrt [ milestones, resursi/aktivnosti, stroški ]
• Spremljajoča dokumentacija
o Dokument “splošne definicije” – opis novih spoznanj iz podrobnejše analize
projekta in korespondence z ostalimi udeleženci na projektu, ter naročnikom

o Dokument “Projektni načrt” ( dopolnitev )
• Aktivnosti
• Rezultati
� Dokument “Rokovnik tehnične izvedbe”
� Dokument “Organizacijska struktura projekta”
� Poročilo “Ocena stroškov”
3.3.3. Specifikacija produkta
o Ponovna ocena obsega projekta, funkcionalnosti, potrebnih resursov in
pričakovanega vloženega napora
o Sprejetje dokumentacije, ki bo spremljala projekt
o Pridobiti morebitne dodatne resurse
o Pridobiti morebitna nova razvojna orodja
o Sprejetje pogodbe o implementaciji
o Definirana ali izpolnjena projektna dokumentacija
o Cilji projekta [ cilji projekta so posnetki naročnikovih želja po funkcionalnosti
produkta. Cilji so splošni in so glavna smernica vsem udeležencem projekta ]
o Primarni scenariji [ na podlagi ciljev projekta, se s pomočjo Use Case diagramov
predstavi problematika, ki jo produkt rešuje. V ospredju so zmeraj globalni cilji
projekta. V opisu primarnih scenarijev se opiše in določi primarna ( vrhnja,
osnovna ) funkcionalnost produkta ]
o Sekundarni scenariji [ na podlagi ciljev projekta se s pomočjo Use Case
diagramov predstavi problematika, ki jo zajemajo posamezni primarni scenariji. V
ospredju so zmeraj globalni cilji projekta. V opisu sekundarnih scenarijev se opiše
in določi podrobna funkcionalnost primarnih scenarijev ( zahtev ) ]
o Arhitektura produkta [ na podlagi primarnih in sekundarnih scenarijev se sestavi
arhitektura produkta ]
o Uporabljeni tehnološki postopki in metodologija izvedbe [ določi se uporabljena
tehnologija, razvojna platforma, razvojna orodja in način izvedbe. Kot način

izvedbe gre za določitev ( ločitev ) slojev produkta na podlagi izsledkov sprejetih
scenarijev ( tri-slojno načrtovanje ) ]
o GUI – opcija
o Način testiranja in določitev publikacij k produktu [ opiše se način testiranja
aplikacije. Določi se publikacija, ki mora biti sestavni del produkta ( Help,
definicija API, ... ) ]
o Doplonjen projektni načrt
• Na podlagi izdelane projektne dokumentacije se sestavi projektni načrt, ki vsebuje:
o Določitev spremljajoče dokumentacije k projektu in način komuniciranja
[ določi se dokumentacija in način komuniciranja med udeleženci projekta ter
odgovorne osebe ]
o Milestones - časovni okvirji izvedbe projekta
o Resursi/aktivnosti - kadrovske potrebe za uspešno izvedbo projekta in
razdelitev delovnih področij
o Stroškovna opredelitev
• Spremljajoča dokumentacija:
• Aktivnosti
o Dokument "Specifikacija produkta" – vsebuje dokument "Primeri uporabe"–
use case s primarnimi in sekundarnimi scenariji
o Dokument "Arhitektura produkta" – razredni diagrami, dataflow, modeli stanj
in ostali prijemi definiranja arhitekture
o Dokument "GUI" – diagram grafičnega vmesnika
3.3.4. Implementacija
o Vsi udeleženci na projektu imajo dodeljen svoj del projekta in prestopijo v fazo
implementacije razdelane problematike
o Nadziranje korakov izvajanja in merjenje napredka razvoja
o Sestankovanje ekipe na dnevni bazi za ugotavljanje težav, preden eskalirajo v
nedosegljive okvirje

• Rezultati
o Poročanje o napredku projekta;
o Dodajanje projektne dokumentacije, korespodenca z naročnikom glede
odstopanj v sprejetih projektnih listinah;
• Spremljajoča dokumentacija
• Aktivnosti
• Rezultati
o Dokument "Dnevnik tehnične izvedbe" je dejanski potek dokumenta
"Rokovnik tehnične izvedbe"
o Dokument "Produkt" - vsebuje kopije dokumentov iz prejšnjih faz, ki jih
zdaj obdelamo podrobneje in za namene implementacije – to so zdaj novi
dokumenti, ki izhajajo iz definicij faz 1 – 3
o Dokument "Source – oblika" definicije oblike programskega koda
o Programski kod – ostane izključno v elektronski obliki
o Poročilo "Testiranje" – zapis o testiranju produkta, inštalaciji beta verzije
o Dokument "Publikacije" – vsebuje API, help, priročnike, ...
o Dokument "Organizacija projekta" je kopija Dokumenta "Organizacijska
struktura projekta", ki je podrobneje razčlenjen na diagrame nosilec/naloga,
tehnične opise nalog, ... za potrebe koordinacije implementacije
o Dokument "Računovodske listine" – vsebuje kopije računovodskih listin
(avansnih računov, računov, plačil ...), ki so vezane na projekt
3.3.5. Tehnični prevzem
o Predstavitev izdelka in funkcionalnosti
o Testiranje ustreznosti izdelka
o Ocena ustreznosti na podlagi testiranja ustreznosti

• Spremljajoča dokumentacija
o Dokument “Tehnični prevzem” – s tem dokumentom se potrdi, da produkt
zadovoljuje zahtevam, definiranim v pogodbi
o Dokument “Zaključek” – z izdajo tega dokumenta je projekt zaključen. Vsebuje
potrditve, da so obveznosti vseh strani poravnane
3.4. VCL Loaderji
3.4.1. Uvod
Prva naloga katero sem dobil pri opravljanju prakse je bilo programiranje VCL
Loaderjev. VCL Loaderji omogočajo prikazovanje različnih vrst podatkov na različne načine.
Osnova za VCL Loaderje je XML dokument, v katerem se nahajajo vsi podatki ki so potrebni za
pravilno nalaganje in prikazovanje željenih podatkov.
Podatke lahko prikazujemo v različnih komponentah, in na različne načine. Prav tako
mora biti loader neodvisen od podatkovnega vira. Mora omogočati nalaganje iz čim več različnih
virov ( XML, SQL, podatkovna baza, URL …. ).
Predstavitev projekta je potekala na naslednji način:
• Seznanitev s projektom
• Predstavitev modula, ki ga je bilo potrebno implementirati;
• Predstavitev dokumentacije;
• Predstavitev ključnih faz projekta;
• Predstavitev ciljev v posameznih fazah;
• Predstavitev podatkovnega modela aplikacije;
• Predstavitev sprecifikacije projekta

3.4.2. Zahteve
Glavna naloga je bila implementirati modul, ki bo znal črpati podatke iz različnih virov,
ter prikazovati dobljene podatke v različnih vizualnih komponentah.
Modul mora znati črpati podatke iz različnih virov ( DB, SQL, XML, URL .. ). Vsakega
izmed teh virov mora znati obravnavati, in posredovati podatke naprej v isti obliki.
Za razvojno okolje je bil določen prvo .NET ( C# ), in kasneje še Borland Delphi 7, z
dodatno nameščenimi “Developer Express” komponentami.
Modul mora znati polniti različne vrste vizualnih komponent, tudi če si te med seboj niso
podobne. To je pomenilo implementacijo modula ki se bo znal čim bolj popolno prilagoditi
različnim vizualnim komponentam, in omogočati prikazovanje podatkov v pravilni obliki.
Potrebno je bilo definirati standardni XML dokument, kateri bo uporabljen pri izvajanju
modula. V XML datoteki je bilo potrebno definirati “poglavja” ki vsebujejo podatke o grafičnem
izgledu komponente, o podatkovnem viru iz katerega mora modul črpati podatke, in o načinu
dostopa do podatkovne zaloge, v primeru da je le-ta podatkovna baza.
3.4.3. Opis VCL komponent
• cxTreeView in cxDBTreeView
TreeView komponenta omogoča prikaz podatkov v drevesni strukturi z
nastavitvijo “Parent – Child” relacije. Podobno kot uporablja “Raziskovalec” za prikaz
structure map v računalniku. Komponenta prikazuje samo en »stolpec« podatkov
naenkrat. Tabela ki je povezana na komponento lahko ima več stolpcev, prikazan je pa
tisti ki je definiran kot DisplayField, torej “Prikaznio polje” v komponenti.
Obstajata dve TreeView komponenti, čeprav sta po delovanju popolnoma enaki.
Edina razlika je oblika podatkovne zaloge s katero zna komponenta delati. TreeView
uporablja DATASET podatkovno zalogo, kar pomeni da so podatki prečrpani iz
podatkovnega vira v podatkovno zalogo znotraj delovanja programa. Takšna podatkovna
zaloga se v C# in Borland Delphi okolju imenuje “DataSet”. DBTreeView pa uporablja
podatkovno zalogo DATASOURCE, ki predstavlja povezavo do podatkovne baze.

Slika 3-1: cxTreeView komponenta
• TreeList in DBTreeList
Slika 3-2: cxTreeList komponenta
TreeList komponenta omogoča prikazovanje podatkov podobno kot zgoraj
opisana TreeView komponenta, le da TreeList omogoča prikazovanje vseh stolpcev v
podatkovni zalogi naenkrat.
Tako kot zgoraj opisani TreeView in DBTreeView, obstajata tudi dve TreeListi:
TreeList in DBTreeList, ki se razlikujeta samo po tipu podatkovne zaloge.

• cxGrid
Komponenta je podobna navadni tabeli, le da lahko vsebuje še dodatne
komponente, kot so npr. navaden gumb, “Checkbox”, “Drop-down” meni in podobno.
Komponenta omogoča tudi avtomatsko gnezdenje podatkov z nastavljenimi
relacijami “Parent – Child”, omogoča lahko tudi grupiranje podatkov ter urejanju
stolpcev in skupin.
Slika 3-3: cxGrid komponenta

3.4.4. Struktura razredov
Slika 3-4: Struktura razredov modula
Vsaka komponenta ima loader v svojem razredu, vsi razredi pa imajo skupni nadrazred
imenovan TmiXMLVCLoader.
3.4.5. XML Datoteka
Za brezhibno delovanje VCL Loaderjev potrebujemo natančno definiran XML dokument,
ki je osnova za nalaganje component, črpanje podatkov iz podatkovnih zalog, in prikazovanje na
komponentah.
XML datoteka je sestavljena iz naslednjih “Node-ov”:
• Views
• DataBases
• DataSets
TmiXMLVCLoader
TmiXMLDBTreeList TmiXMLTreeList TmiXMLDBTreeView TmiXMLTreeView
View node vsebuje vse podatke o vizualnem izgledu komponente ( barve, stolpci, skupine ),
obnašanju komponente in načinu prikazovanja podatkov v komponenti.

Slika 3-5: View node
View del vsebuje tudi podatke o povezavi s podatkovnim delom ( xml tabela, SQL
stavkek .. ). Povezava s podatkovnim delom se nahaja v nodu DataController.
DataController skrbi za to da se komponenta katero nalagamo pravilno poveže z
ustreznimi podatki.

Slika 3-6: DataController node
Database node vsebuje podatke o podatkovni bazi, in povezavi na njo. Database je najbolj
pogosto Access podatkovna baza. Za dostop do te podatkovne baze program potrebuje pot do
fizične lokacije na trdem disku, tip podatkovne baze, ime baze, alias, uporabniško ime in geslo
ter ostale podatke potrebne za povezavo.

Slika 3-7: DataBase node
Dataset node pa lahko vsebuje tabelo s podatki in njeno schemo. V primeru da nimamo
na voljo podatkovne baze, lahko podatke prenesemo kar v XML dokumentu, v Dataset nodu.
Loader med delovanjem prebere da se podatki nahajajo v tabeli, in te podatke prečrpa v
podatkovno zalogo ( DataSource ). Shema, ki se nahaja zraven podatkov predstavlja definicijo
vseh polj v XML podatkovni zalogi.

3.4.6. Funkcionalnost in delovanje modula
Slika 3-8: Program pred inicializacijo
Prikazan je testni program, ki je bil uporabljen za programiranje modula, in za testiranje
obnašanja in delovanja modula. Prikaz je zgolj zaradi namenov demonstracije, dokončani moduli
se lahko uporabljajo tudi v drugih aplikacijah. Ob zagonu programa so vse komponente v
neinicializiranem stanju, kot je vidno na sliki zgoraj. Za začetek izvajanja v meniju ( številka 1 )
izberemo kateri razred želimo uporabiti, v drugem meniju ( številka 2 ) pa izberemo katero
funkcijo želimo zagnati.
Slika 3-9: Meni - zagon modula
Po izbiri opcij prvo odpremo privzeti xml, in zaženemo izvajanje modula. Modul s pomočjo
privzete XML datoteke začne z izvajanjem. Od tu naprej poteka vse samostojno, brez
uporabnikove pomoči. Prebere se View odsek v XML datoteki, iz katerega se naložijo vizualne
opcije gradnikov v programu, za tem se preveri katera podatkovna zaloga pripada katerem
gradniku, in s pomočjo Databases in Datasets node-ov v XML-ju prebere podatke iz podatkovnih

virov in jih pretvori v ustrezne podatkovne zaloge, katere so pripravljene za prikaz v
komponentah.
Končni rezultat izvajanja programa so inicializirani gradniki v aplikaciji, ki že vsebujejo
vse podatke kateri so bili za njih predvideni v XML datoteki.
Slika 3-10: Inicializirani gradniki

Slika 3-11: Primerjava Xml in gradnika
3.4.7. Zaključek
Modul “VCL Loader” nam omogoča dinamično in hitro nalaganje različnih vrst
podatkov, brez spreminjanja programske kode. Aplikacijo s takšnim modulom lahko
uporabljamo v najrazličnejše namene. Z dobro definiranim XML dokumentom lahko poljubno
oblikujemo aplikacijo, saj lahko samo z XML dokumentom določamo kakšne podatke želimo, od
kod jih želimo črpati, kako jih želimo prikazati. S pomočjo XML dokumenta lahko
manipuliramo tudi z gradniki na aplikaciji, lahko določamo katere komponente bodo vidne in
katere ne in kako se bodo obnašale.

3.5. Razred za prevod programa
3.5.1. Uvod
Naloga, katero sem dobil, je zahtevala izdelavo razreda in pripadajočih funkcij, ki
omogočajo izbiro jezika v nastavitvah programa. Program je bil napisan za slovenski trg, in so
tako vsa besedila znotraj vseh oken programa bila v slovenskem jeziku. Bilo je potrebno
spremeniti program tako, da je v oknu “Nastavitve” omogočal izbiro različnih jezikov. Prav tako
je bilo potrebno spremeniti pripadajočo .INI datoteko, v kateri so se nahajale vse nastavitve
programa. Program je ob potrditvi nastavitev iz inicializacijske datoteke prebral potrebne
podatke, in glede na izbran jezik nadaljeval delovanje.
3.5.2. Zahteve
Naloga je zahtevala implementacijo razreda, ki bi iz vnaprej določenih tekstovnih datotek
prebirala prevedene beside, in jih vstavljala na pravilna mesta v programskih formah. Pred samo
implementacijo razreda je bilo treba določiti format tekstovne datoteke. Tekstovna datoteka je
vsebovala podatke o objektu, katerega je potrebno prevesti, kateremu razredu ta objekt pripada, v
kateri formi se nahaja in prevedeno besedo, katero je treba vnesti.
Razred je bilo potrebno implementirati v razvojnem okolju Borland Delphi 7, moja
naloga je bila načrtovati, implementirati in dokumentirati omenjeni modul.
Zahtevano je bilo da program uproablja dve tekstovni datoteki. Prva vsebuje vse podatke
o objektih katere prevajamo, in prevedene besede, oz. reference do prevedenih besed. Druga
datoteka je vsebovala prevode, do katerih je mogoče dostopati preko referenc iz prve datoteke.
Program mora prevajati vsako formo posebej, v trenutku ko se prvič naloži z namenom
skrajševanja časa začetnega nalaganja programa.

3.5.3. Opis datotek
Za pravilno delovanje funkcij potrebujemo dve različni datoteki, in sicer, datoteko s
podatki o komponentah katere je treba prevesti, in referenčno datoteko, ki vsebuje prevode ki se
večkrat pojavljajo.
Ime
Ime
Tip
Tag Tip tekst namig tekst namig
Agent Btn1 TButton 0 VCL Text Gumb1 N1 Button1 #2
Agent Btn2 TButton 0 VCL Text Gumb2 N2 Button2 #3
Tabela 3-2: Datoteka s prevodi
Datoteka vsebuje vse podatke ki jih potrebuje, da lahko poišče in zamenja pravilni tekst v
pravilnem gradniku. V primeru da je namesto prevoda navedena referenca ( # ), program preveri
referenčno datoteko za pravilen prevod.
Privzeti tekst Prevedeni tekst
N1 Hint1
N2 Hint2
Tabela 3-3: Referenčna datoteka
Na referenčno datoteko se sklicujemo z znakom “#” in številko – indeks na katerem se
nahaja ustrezni prevod. Za izvoz vseh originalnih tekstov je bilo potrebno izvoziti v tekstovno
datoteko s pomočjo že napisane funkcije, katera ustrezno formatira tekstovno datoteko. Datoteko
je potrebno dati v prevod, po katerem je datoteka pripravljena da služi kot slovar katerega
funkcija uporablja za prevajanje.
Funkcije za delovanje potrebujejo še inicializacijsko datoteko programa, v kateri so
zapisani vsi jeziki ki so na voljo, ter absolutne poti do slovarjev, oz. do datotek s prevodi in
referenčnih datotek.
3.5.4. Delovanje razreda
V oknu za nastavitve aplikacije na začetku nastavimo jezik katerega želimo uporabljati.
Ko nastavimo jezik in kliknemo Shrani, se izbrane nastavitve shranijo v inicializacijsko datoteko

“.ini”, kjer se shrani izbrani jezik. Izbrane nastavitve ostanejo privzete, in se bodo ob vsakem
zagonu programa znova upoštevale, dokler jih spet ne spremenimo v nastavitvah. Za uporabo
nastavitev je potrebno program ponovno zagnati, da se nastavitve inicializirajo.
[Import Language_Files]
0=Default@E:\Projects\Merkur\MLMlanguage.txt@E:\Projects\Merkur\refLanguage.txt
1=Deutsch@C:\MLMlanguage.txt@C:\refLanguage.txt
Slika 3-12: Vnos v .ini datoteki
Slika 3-13: Nastavitve
Ob zagonu programa se ob vsakem kreiranju katerekoli forme oz. okna zažene funkcija
za prevod, ki iz .ini datoteke prebere kateri jezik je izbran v nastavitvah ter kje so jezikovne
datoteke, ki jih za prevod potrebuje, shranjene. Funkcija se nato pomika čez vse vizualne
komponente v oknu, in preveri če je ime te komponente kje v datoteki. Če je komponenta
najdena, preveri s kakšnim tipom komponente ima opravka, in nato glede na tip komponente
prevede napis in morebitni namig.
Obstajajo še nekatera besedila za prevod, ki se pa ne nahajajo na vizualnih komponentah,
ampak se pojavljajo v programski kodi. Takšna besedila se prevedejo malo drugače, in sicer
tako, da funkcija prestreže tekst kateri se mora prikazati, poišče če se kje ta tekst pojavlja, in kot
rezultat vrne najdeni prevod ( v primeru da ga najde ).

Med izvajanjem programa ne sme prihajati do napak, zato so v primerih ko ne najde
ustreznega prevoda, implementirane zaščite ki skrbijo za to, da se program lahko normalno
nadaljuje.
3.5.5. Zaključek
Razred za prevajanje je omogočal enostavno in hitro uporabo več jezikov brez
spreminjanja samega programa. Pred implementacijo funkcij je bil program razumljiv samo
uporabnikom ki razumejo slovenski jezik. Vsako spreminjanje programa brez the funkcij bi bilo
dolgo in mukotrpno delo. Za vsak drugi jezik bi bilo potrebno imeti svojo verzijo programa.
Funkcije za prevod pa omogočajo uporabo istega programa v vsakem jeziku, brez spreminjanja
samega programa.
Ker so vse funkcije katere potrebujemo za prevajanje shranjene v istem razredu, lahko te
funkcije uporabimo tudi pri drugih aplikacijah. Za vključitev in uporabo funkcij v programu
potrebujemo le slovarje, v programski kodi so pa potrebne le minimalne spremembe.

4. Pridobljeno znanje in izkušnje
V času opravljanja dela v podjetju Modan Informatika d.o.o sem spoznal, kako v praksi
poteka delo v manjšem podjetju, ki se ukvarja z razvojem programskih produktov. Komaj s
pomočjo dela v praksi sem lahko dokončno dojel nekatere teoretične stvari, ki sem jih spoznal v
času študija na fakulteti. Seznanil sem se z mnogimi razvojnimi orodji (Delphi 7, ASP.NET, C#),
podatkovnimi bazami(Access, MS SQL), programi za obdelovanje XML datotek ( XMLSpy ) in
ostalimi orodji. Sodeloval sem pri mnogo različnih projektih in s tem pridobil velik spekter
različnega znanja.
Praksa je zelo pomemben del izobraževanja v računalništvu, saj študent na ta način pozna
kako poteka delo v podjetju in si pridobi potrebno praktično znanje.

5. Mnenje o praksi
Mislim, da praktično izobraževanje po končanih predavanjih zelo pozitivno vpliva na
študente, saj se srečamo s praktičnimi primeri in težavami, ki jih prinašajo vsakodnevni problemi
v poslovnem svetu.
V okviru praktičnega izobraževanja naučil veliko novih stvari, pridobil pa sem tudi
vpogled v delovanje nekaterih podjetij.