Univerza v Mariboru Fakulteta za organizacijske vede. Programska rešitev za grafično prikazovanje najema in rezervacij vozil

Transcription

1 Univerza v Mariboru Fakulteta za organizacijske vede Smer: Informatika v organizaciji in managementu Programska rešitev za grafično prikazovanje najema in rezervacij vozil Mentor: doc dr. Werber Borut Kandidat :Aleksander Gabrovšek Kranj, september 2008

2 ZAHVALA Mentorju doc. dr. Werber Borutu se zahvaljujem za pomoč, svetovanje in vodenje pri opravljanju diplomske naloge.

3 POVZETEK V diplomski nalogi je predstavljena programska rešitev za grafično predstavitev podatkov najema in rezervacij vozil v časovni odvisnosti - gantogram. Predstavljeni sta podjetji Result d.o.o. in Sixt Rent A Car, ki sodelujeta pri razvoju programske rešitve. Opisane so uporabljene tehnologije, baza podatkov, programski jeziki in metodologije dela. Namen programske rešitve je omogočiti uporabnikom, da bodo hitreje dostopali do informacij in imeli pregled nad celotnim poslovanjem. Opisane so težave pri razvoju, kot tudi možnosti za nadaljnji razvoj programske rešitve. Predstavljena je uporabljena datotečna struktura zapisa programske kode. Delovanje gantograma je prikazano s slikovnim gradivom. KLJUČNE BESEDE Grafični vmesnik, gantogram, SQL, Cobol, najem, rezervacija, metodologija dela, programska arhitektura. SUMMARY This dissertation presents software solution for graphical presentation of rental agreement and reservation information s, related to time. It introduces companies Result d.o.o. and Sixt Rent A Car that are working together on this software solution. It describes used Technologies, database, programming languages and project methodologies. Purpose of this software solution is to enable users faster access to needed information and better business view. It describes difficulties in development stage and also new possibilities for additional development of this software solution. It presents file model structure for used programming code. Working Gantt Chart will be presented with pictures. Key Words: Graphical user interface, Gant Chart, SQL, Cobol, rental agreement, reservation, project methodologies, software architecture.

4 KAZALO 1. UVOD PREDSTAVITEV PODJETJA RESULT D.O.O POSLOVANJE PODJETJA TEHNIČNI RESURSI PODJETJA SIXT RENT-A-CAR POSLOVANJE PODJETJA TEHNIČNI RESURSI PODJETJA OPIS UPORABLJENIH PROGRAMSKIH JEZIKOV COBOL JAVASCRIPT XUL SQL RAZVOJNO ORODJE METODOLOGIJE DELA PROGRAMIRANJA ANALIZA BAZ PODATKOV PREDSTAVITEV BAZ PODATKOV POTEK PRIDOBITVE PODATKOV IZ BAZE NA ZASLON TRINIVOJSKA ARHITEKTURA PREDNOSTI SLABOSTI PREDLAGANA REŠITEV RAZVOJ PROGRAMSKE OPREME PROGRAMSKI DESIGN ANTIPATERN BLOB OBJEKTNO ORIENTIRAN DESIGN ANTIPATERN POLTERGEIST PROGRAMIRANJE ANTIPATERN SPAGETTI CODE PREDSTAVITEV REŠITVE - GANTOGRAM ZGRADBA PO DATOTEKAH NAMEN INICIALIZACIJA IN UPORABA UVEDBA REŠITVE MOŽNOSTI ZA NADALJNJI RAZVOJ PROGRAMSKE REŠITVE PROBLEMI PRI RAZVOJU PROGRAMSKE OPREME SLIKE UPORABE GANTOGRAMA LITERATURA PRILOGE... 39

5 1. UVOD Naloga je nastala na podlagi mojega dela na področju razvoja internetnih aplikacij v podjetju Result d.o.o., kjer za podjetje Sixt Rent-a Car razvijam podporne programe za oddelek mednarodnih franšiz. V podjetju Result d.o.o. delam od junija Moje zadolžitve in naloge se nanašajo na izdelavo in vzdrževanje podprogramov za oddelek mednarodnih franšiz. Ti programi so na primer: program za pregledovanje podatkov o strankah podjetja in njihova shranitev v bazo, program za menjavo lokacije vozila, pri čemer, program opravi vse pravilne vnose v bazo, kot da gre za transakcijo s stranko. Program, ki sem ga pomagal izboljšati, prikazuje podatke o floti podjetja, natančneje, podatke o skupinah avtomobilov in njihovih lastnostih. Gre za program z internim imenom»prosti avtomobili«, v katerem dobimo vpogled v vse informacije v zvezi z lokacijo avtomobilov. Lokacije so porazdeljene po državah in nato znotraj posameznih držav na poslovalnice. Program nam omogoča vpogled v informacije o avtomobilih, kot so: podatki o poreklu, tipu, znamki, tehničnih lastnostih vozila, starosti vozila, podatki o prevoženih kilometrih in kilometrih do naslednjega obveznega servisa, informacije o vseh najemnih pogodbah, rezervacijah, lokacijskih transakcijah avtomobila ter trenutno stanje vozila, ki ga opisujejo naslednje možnosti: v uporabi, poškodovan, na servisu, čiščenje, na voljo. Kot dodatek k izboljšani uporabnosti programov se je pojavila potreba po samostojnem objektu gantogramu, ki bo objektna nadgradnja že obstoječih programov v celotnem programskem ogrodju. Glavna lastnost gantograma na grafični način prikaže posamezne aktivnosti v časovnem zaporedju, z možnostjo prekrivanja. Uporabljen bo v možnostih prikaza podatkov na časovni premici, kot so: - vse najemne pogodbe in rezervacije posameznega avtomobila, - vse najemne pogodbe in rezervacije posameznega voznika. V nalogi je predstavljena tehnologija, ki je potrebna za izgradnjo gantograma, uporabljene metode programiranja v procesu izgradnje, opis podatkovnega modela, opis obstoječega stanja aplikacije, katere objektna nadgradnja je gantogram. Delovanje gantograma je prikazano s slikovnim gradivom. Stran 1

6 2. PREDSTAVITEV PODJETJA RESULT Računalniški sistemi d.o.o. Zaloška 69, 1000 Ljubljana Slovenija 2.1 RESULT D.O.O POSLOVANJE PODJETJA RESULT je družba, ustanovljena leta Njeni člani so specialisti za svetovanje na področju informacijskih tehnologij, zasnovi, razvoju in uvajanju kompleksnih informacijskih sistemov ter razvoju kakovostne sistemske in aplikativne programske opreme, z vso potrebno pomočjo svojim strankam. RESULT je tudi zastopnik nekaterih tujih proizvajalcev programske opreme. Njihov cilj je ostati neodvisen od strojne platforme in uporabljati orodja, ki delujejo na širokem spektru računalniških strojnih in programskih platformah. RESULT se uveljavlja s programsko opremo, kot je analitično programsko orodje za potrebe poslovnega odločanja, s programsko opremo za digitalno podpisovanje, programsko opremo, ki je namenjena obdelavi in nadzoru računalniško vodene steze tehničnih pregledov motornih vozil ter tudi programsko opremo za vodenje stanja in objavo javnih naročil TEHNIČNI RESURSI PODJETJA Podjetje ima svoj informacijski sistem, ki ga sestavljajo: - omrežje, - strežniki, - delovne postaje. Strežniki imajo nameščen operacijski sistem Windows 2003 Server Enterprise Edition in Linux Ubuntu LAMP Server Edition. Strežniki imajo vzpostavljen active directory, dns, cvs - sistem za kontrolo izvorne kode (Concurrent versions system) ter domenski strežnik. Med seboj so povezani z giga bitnimi stikali. Podjetje ima oblikovano internetno stran, na kateri najdemo informacije o podjetju in storitvah. Dostop do interneta je omogočen preko širokopasovne VDSL povezave. Za povezavo s poslovnimi partnerji podjetje uporablja kriptirano povezavo VPN virtual private networking. V razvojnem - testnem okolju ima podjetje vzpostavljene podatkovne baze Mysql in Oracle. Na delovnih postajah je nameščena zadnja različica Microsoftove programske opreme. Kot poslovni program podjetje uporablja Navision. Razvojna okolja so Eclipse, JDeveloper,.NET, IBM... Stran 2

7 2.2 SIXT RENT-A-CAR POSLOVANJE PODJETJA Trenutno je Sixt Rent-a-car vodilno podjetje na področju mobilnosti v Nemčiji. Po Evropi se uspešno širi in ima sedaj že več kot 3500 poslovalnic. Rent-a-car posluje v 80 državah sveta. Martin Sixt je leta 1912 ustanovil podjetje Sixt Autofahrten und Selbstfahrer. Začel je s sedmimi avtomobili, s štirimi znamke Mercedes in tremi Luxus Deutz Landaulets. Med obema svetovnima vojnama, vojska podjetju zapleni avtomobile in voznike. V drugi svetovni vojni, natančneje leta 1939, uspe Martinu Sixtu pred vojsko skriti sedem sedežnega Mercedesa 230 Landulet. Po drugi svetovni vojni sin Martina, Hans Sixt, z ohranjenim mercedesom ponovno odpre podjetje. Večino zaslužka pridobi s taksi službo za člane ameriške vojske. Leta 1951 Hans Sixt kot prvi v Evropi in sicer v Münchnu, začne v taksi vozilih uporabljati radio. Radijska oprema je iz ZDA. Leta 1967 pa kot prvo nemško podjetje, ponudi leasing program za svoja podjetja. Leta 1969 postane direktor podjetja Eric Sixt, ki v floto uvede tovornjake, odpre veliko poslovalnic po vseh letališčih v Nemčiji, z nizko cenovno dostopnimi avtomobili. V 80. postane vodilni v izposoji limuzin, na vseh 5 kontinentih, v 50 državah in 400 mestih. Trenutno se podjetje Sixt Rent-a-Car nahaja v več kot 80 državah sveta TEHNIČNI RESURSI PODJETJA Podjetje ima za delovanje celotne aplikacije več strežnikov, med katerimi jih je polovica namenjena za razvojne aplikacije. Podjetje uporablja trinivojsko sistemsko arhitekturo, ki jo uspešno nadgrajuje in izpopolnjuje. Podjetje je mnenja, da natančnejše opisovanje določene sistemske infrastrukture lahko razkrije informacije, katerih zloraba bi lahko škodovala poslovanju podjetja. Za razvoj aplikacij ima podjetje svoj razvojni center z več kot 30 zaposlenimi. Razvijalci razvijajo programsko opremo v jezikih php, xul, cobol in javascript. Za uporabo aplikacij uporabnik potrebuje računalnik z dostopom do interneta in možnostjo uporabe kriptirane povezave VPN. Imeti pa je treba tudi nameščen operacijski sistem Windows ali Linux, ki podpira namestitev aplikacije XulRunner ali brskalnika Mozilla, od verzije naprej oziroma najnovejšo različico internetnega brskalnika Mozilla FireFox. Stran 3

8 3. OPIS UPORABLJENIH PROGRAMSKIH JEZIKOV 3.1 COBOL Cobol je eden najstarejših programskih jezikov, ki se še vedno aktivno uporablja. Njegovo ime je akronim za COmmon Business-Oriented Language. S samim imenom predstavlja svojo glavno usmerjenost, to je v poslovne, finančne in administrativne sistemske rešitve, za podjetja in vlado. Uporabljajo se oziroma tečejo na operacijskih sistemih, kot so»ibm-ov System Z«, Microsoft Windows in družina POSIX, ki zajema operacijske sisteme UNIX, LINUX... Cobolov začetek sega vse nazaj do leta Ustvarila ga je»the Short Range Committee«, in sicer 28. in 29. maja na sestanku v Pentagonu, ki ga je organiziral Charles Phillips iz Agencije za nacionalno varnost Združenih držav Amerike. Komite je bil sestavljen iz članov, ki so predstavljali šest računalniških podjetij in tri vladne agencije. Specifikacija je bila narejena oziroma navdihnjena s programskim jezikom FLOW-MATIC, katerega izumitelj je Grace Hopper in iz IBM-ovega jezika COMTRAN, njegov»oče«pa je izumitelj Bob Bemer. (Wiki - prevedeno v slo, 08) Programski jezik COBOL je eden prvih kakovostnejših programskih jezikov. Zadnja standardizirana različica Cobola se je pojavila leta 2002, izdana s strani ameriškega nacionalnega inštituta za standarde. (wiki - cobol) Cobol 2002 standard vsebuje podporo za objektno orientirano programiranje in tudi druge funkcije novejših programskih jezikov. Tako kot ima programski jezik C++, je Cobol leta 1997 dobil objektno orientirane združevalnike (compiler). Leta 1997 je Gartner Group objavila, da 80 % svetovnega poslovanja»teče«na COBOL-u, z več kot 200 bilijonov obstoječih vrstic kode in s 5 bilijonov novih vrstic kode letno. Čeprav 55 % ljudi v anketi ne želi uporabljati cobola, ker je»star«jezik, vseeno ugotovimo, da v organizacijah še vedno uporabljajo cobol v 62 % kot razvojni jezik za aplikacije. 58 % anketirancev meni, da se bodo nove aplikacije razvile v Cobolu. (Anketa: revija Computerworld vzorec: 352 bralcev) 3.2 JAVASCRIPT JavaScript je programski jezik, ki se največkrat uporablja pri gradnji aplikacij znotraj požarnega zidu client-side. Je dinamičen, slabše tipiziran, prototipno orientiran jezik z razrednimi funkcijami. JavaScript je programski jezik, ki spada v skupino tolmačev. To pomeni, da se napisana koda programa ne prevede v program, ki bi ga lahko shranili v obliki izvršilne datoteke, pač pa poseben tolmač po vrsti razčlenjuje in izvršuje ukaze, ki smo jih napisali. Stran 4

9 Je objektno usmerjen programski jezik, na prvi pogled precej podoben programskima jezikoma Java in C++. Kdor je že kdaj napisal kakšen program v enem od teh dveh jezikov, z JavaScriptom ne bo imel posebnih težav. Precej objektov je v JavaScriptu že definiranih in jih lahko takoj uporabimo v svojih programih. JavaScript lahko sodeluje s kodo HTML in s tem poživi stran z dinamičnim izvajanjem. JavaScript je podprt s strani velikih programskih podjetij in kot odprt jezik ga lahko uporablja vsakdo, ne da bi pri tem potreboval licenco. Podpirajo ga vsi novejši spletni brskalniki, kot so Internet Explorer 7, Mozilla FireFox, Opera 9... (Wiki - prevedeno v slo, 08) JavaScript je programski jezik, ki ima več uporab. Največkrat ga srečamo v spletnih brskalnikih (Client-Side JavaScript), pri Netscape-u pa so ga vgradili tudi v svoj omrežni strežnik (Server-Side JavaScript). Poleg tega lahko JavaScript vključujemo v različne vrste dokumentov, kot so: HTML HyperText Markup Language jezik za označevanje nadbesedila, XML Extensible Markup Language razširljiv označevalni jezik, VRML Virtual Reality Modeling Language - jezik za modeliranje navidezne resničnosti, in celo PDF Portable Document Format prenosljiva oblika dokumenta. Elemente jezika JavaScript lahko razdelimo na tri nivoje: 1. Core - jedro Jedro vsebuje tiste elemente jezika, ki so skupne vsem različnim uporabam. Sem spadajo pravila o zgradbi programa (sintaksa), pravila o sestavljanju izrazov in stavkov, vgrajeni objekti in funkcije, Host - gostitelj Glede na to, kje uporabljamo JavaScript, imamo na razpolago dodatne objekte, ki opisujejo trenutno stanje okolja. Če na primer uporabljamo JavaScript pri pregledovanju dokumentov HTML, imamo na razpolago objekte, ki opisujejo okno brskalnika, zgradbo dokumenta, evidenco o obiskanih straneh User - uporabnik Vsak uporabnik lahko v JavaScriptu definira svoje funkcije in objekte, ki jih nato uporablja, kot da so del jezika samega. Razred (class) Je definicijski vzorec za tvorbo in strukturiranje objektov z enakimi atributi in metodami. Atributi in metode v razredu so deklaracije, ki ne vsebujejo vrednosti, objekt nekega razreda pa ima lastne (svoje) vrednosti atributov in metod. Atribut razreda (class wide attribute) uporabljamo za predstavljanje informacije, ki je skupna vsem primerkom oziroma predstavlja skupno informacijo vseh primerkov. Stran 5

10 Atribut razreda je lahko konstanta ali spremenljivka. Metodo razreda (class wide method) uporabljamo za izvajanje operacij, ki so specifične za celoten razred, običajno nad atributi razreda in ne nad atributi posameznih primerkov tega razreda. Metodo razreda lahko uporabimo, ne da bi tvorili kakšen primerek tega razreda. Privatni (private) atributi in metode so vgrajeni v razred. Ne morejo jih videti klienti (uporabniki) tega razreda. Javne (public) metode definirajo vmesnik, ki ga razred nudi klientom. Enkapsulacija: Objekti komunicirajo med seboj s posredovanjem obvestil (messages). Obvestilo je klic metode s strani objekta, ki obvestilo pošilja k objektu, ta pa obvestilo prejema. Obvestilo vsebuje referenco objekta, ki kaže na prejemnika obvestila, ime metode (kar ustreza metodi prejemnika), in parametre (argumente klicane metode). Objektprejemnik obvestila, je strežnik za objekt-pošiljatelj obvestila; objekt-pošiljatelj obvestila je klient strežnika. Metoda: Obvestilo je veljavno, če ima sprejemajoči objekt ustrezno metodo z istim imenom metode, pravim številom argumentov, ki so pravega tipa. Metode razreda tipično vsebujejo kodo, ki razume in ravna s stanjem nekega objekta. Vsaka metoda ima svoj podpis (signature), ki vsebuje ime, število in tip njenih argumentov. Metoda lahko tudi vrača vrednost (return value). 3.3 XUL XUL (izgovorjeno»zool«) je mozillin jezik, zgrajen na podlagi tehnologije XML, ki omogoča izgradnjo bogatih uporabniških vmesnikov, delujočih na večini sedanjih operacijskih sistemih. Te aplikacije lahko normalno delujejo,»tečejo«, s povezavo do interneta ali brez nje. Aplikacijam se zelo enostavno spreminja grafika in dodaja alternativna tekstovna polja. To prilagajanje je zelo dobrodošlo, saj se lahko enostavno spremeni večina aplikacije za posamezni lokalni trg. (Monitor, 2006). Po dolgotrajnem pričakovanju so razvijalci dočakali stabilno, preizkusno različico izvajalnega okolja XUL Runner, ki omogoča preprostejše izvajanje aplikacij, razvitih v označevalnem jeziku XUL in z morebitnimi dodatnimi gradniki XPCOM. Najbolj znani primerki tovrstnih aplikacij so seveda mozillin spletni brskalnik Firefox, odjemalec za elektronsko pošto Thunderbird in skupek SeaMonkey. XUL Runner 1.8 temelji na kodi, ki poganja aktualni Firefox Seveda pa kombinacija XUL+XPCOM omogoča hiter razvoj praktično kakršnekoli aplikacije, ki ji je upodabljanje spletne vsebine in komunikacija preko omrežja toliko lažja. Opre se namreč lahko že na pripravljene zmogljivosti gradnikov Gecko Stran 6

11 (upodabljanje) in Necko (omrežje). Povrhu vsega je XUL izjemno preprosto orodje za oblikovanje zmogljivih uporabniških vmesnikov. Aplikacije za XUL Runner seveda tečejo na vseh podlagah, kjer je na voljo izvajalno okolje (trenutno Okna, Linux in Mac OS X). Poskrbeti moramo zgolj za ustrezne različice dodatnih gradnikov XPCOM, če smo jih pri razvoju naše aplikacije potrebovali. XUL Runner bo ponudil tudi mehanizme za nameščanje, vzdrževanje, nadgradnjo in odstranjevanje aplikacij. Projekt vključuje tudi razvoj knjižnice (libxul), ki bo omogočala vgradnjo zmogljivosti izvajalnega okolja neposredno v druge programe. Razvijalci, ki jih XUL zanima, lahko veliko informacij najdejo na spletišču XULPlanet. (Monitor ) XUL (extensible User-interface Language) je mozillina XML tehnologija uporabniškega vmesnika za različne operacijske sisteme. Ta tehnologija razvijalcem omogoča, da oblikujejo grafični uporabniški vmesnik za različne operacijske sisteme z mešanico XML, HTML, CSS in ECMAScript (JavaScript). Uporabnik lahko spreminja vse podrobnosti uporabniškega vmesnika mozillinega XUL programa (kar je Mozilla sama) preprosto s spreminjanjem datotek, ki uporabljajo standardno sintakso spletnih strani. XUL za izvajanje izbranega uporabniškega vmesnika uporablja Gecka. Kombinacija Gecko/XUL omogoča mozillinemu programu, da se razvije iz tako preproste oblike, kot je spletna stran, v prefinjeno podobo, kot je Mozilla 1.0. Podpira vse osnovne gradnike sodobnih grafičnih uporabniških vmesnikov, vključno z meniji, vnosnimi polji, pogovornimi okni, drevesnimi pogledi (eden je viden v nastavitvenem pogovornem oknu) in bližnjicami tipk. Pomen izgradnje uporabniškega vmesnika Spletne strani so zelo priljubljene tudi zaradi preprostosti HTML, s katerim lahko hitro sestavimo očesu privlačne uporabniške vmesnike, ki delujejo na najrazličnejših napravah. Žal, programa zgolj s HTML, ne moremo razviti. Številni razvijalci porabijo vse preveč časa za zunanjo podobo, namesto za ključno funkcionalnost programa. Okras je včasih celo pomembnejši od uporabne vrednosti. Težava pri današnjih orodjih, ki omogočajo razvoj spletnih vmesnikov, neodvisnih od podlage, je tudi previsoka sklopljenost vmesnika in programske logike. Sprememba enega, skoraj vedno povzroči tudi popravljanje drugega. Razvoj spleta je dokazal, da je mogoče z označevalnimi jeziki hitro graditi zmogljive uporabniške vmesnike. Mar ne bi bilo lepo, ko bi lahko tudi namenskim programom določili vmesnik kar s pomočjo HTML? To je osnovna zamisel XUL-a, označevalnega jezika za uporabniške vmesnike (extensible User interface Language, izg. zul). XUL je še eno izmed narečij priljubljenega XML, nastal pa je v projektu Mozilla, kot orodje za opis uporabniških vmesnikov. To orodje ni odvisno od podlage, na kateri Stran 7

12 se program izvaja. Uspešnost XUL-a dokazuje sama Mozilla, katere vmesnik je pravzaprav v celoti določen z njim. Vse, kar dobi od operacijskega sistema, je prazna površina glavnega okna. Meniji, orodjarne, seznami, e-nabiralniki in spletne strani - vse to upodabljajo gradniki XUL. Ker je XUL narečje XML, je uporabniški vmesnik odprt, urejamo pa ga lahko navsezadnje s preprostim urejevalnikom besedila, saj je njegov zapis človeku berljiv. (Mesojedec, 2004) 3.4 SQL SQL je računalniški bazni jezik, narejen za poizvedovanje in managiranje (management) podatkov v relacijskih baznih management sistemih, kreiranje in modifikacijo baznih shem. SQL je akronim za Strukturirani poizvedovalni jezik. SQL je standardni jezik za interakcijo in programiranje za poizvedbe, spreminjanje podatkov ter upravljanje z bazami. Jedro SQL-a je zgrajeno iz ukazov, ki omogočajo priklic, vnos, zbris in osveževanje podatkov, prav tako pa upravljavske in administrativne funkcije. Strukturirani poizvedovalni jezik, je generaliziran jezik do te mere, da obsega sredstva za definicijo podatkovnih struktur, specifikacijo integriranih omejitev, podeljevanje prestopnih dovoljenj in zaščito celovitosti baze podatkov. SQL jeziku kot veliko slabost pripisujejo: nezmožnost prenosljivosti podatkov med različnimi platformami različnih proizvajalcev, neprimerno ravnanje ob sprejetju praznega - nul podatka, nepotrebno zapletenost ter občasno dvoumno jezikovno gramatiko in lingvistiko. (Wiki - prevedeno v slo, 08) 3.5 RAZVOJNO ORODJE Osnovno razvojno orodje je produkt Eclipse verzija za razvoj Java IDE aplikacij fundacije Eclipse. Organizacija spada v skupino Odprti Poenoteni Procesi (Open Unified Process). Za pravilno delovanje Eclipse-a je potrebno namestiti zadnjo različico»java Runtime Enviroment«. Program Eclipse ima vgrajeno pomoč pri prepoznavanju pravilnega pisanja kode Javascript in xul. Za pregledovanje cobolskih metod in programov, lahko uporabimo internetni brskalnik Internet Explorer ali Mozilla Firefox, kajti vse te metode so dostopne na internih spletnih straneh podjetja Sixt. Razvojni računalnik z operacijskim sistemom Windows/Linux različice. Eclipse Strežnik php Stran 8

13 Aplikacijski strežnik Bazni strežnik Zaščitena povezava VPN Testni strežnik Produkcijski strežnik Stran 9

14 4 METODOLOGIJE DELA PROGRAMIRANJA Klasičen razvojni cikel razvoja programske opreme je še pogosto linearen. Zgleduje se po standardnem postopku razvoja tehničnih izdelkov. V takšnem razvoju si vse aktivnosti sledijo zaporedno. Da zagotovimo uspešen razvoj programske opreme, je že na samem začetku potrebno celovito in nedvoumno definirati zahteve naročnika. To opravimo s skrbno analizo zastavljenega problema in z dobrim sodelovanjem naročnika ali uporabnika. Klasičen razvoj ne omogoča vračanje na predhodne faze, zato sta skrbna analiza in dobro sodelovanje ključnega pomena. Da ne bi med razvojem prišlo do prevelikega odstopanja med sistemom, ki ga razvijamo in zahtevami uporabnikov, je smiselno po vsaki fazi, poleg preverjanja rezultatov, tudi njihovo vrednotenje. Edino tak način razvoja je bil v preteklosti ekonomičen, saj so bile vse aktivnosti od načrtovanja do kodiranja in testiranja, zaradi še neobstoječih orodij za podporo razvoja programske opreme, zelo zamudne. (Solina, 1997, str. 14) V praksi pa imajo projekti redkokdaj popolnoma sekvenčno naravo. Posebej individualni razvijalci radi med razvojem skačejo med različnimi ravnmi abstrakcije, od sistemskih funkcij do podrobnosti v programski kodi. Posamezne aktivnosti, ki naj bi bile med seboj strogo ločene in zaporedne, se tako med seboj prekrivajo in mešajo. Za to so krive tudi nejasne ali nepopolne zahteve na začetku projekta. Do tega pride zaradi same narave projekta ali zato, ker naročnik nima pravega vpogleda v naravo razvoja programske opreme. Pri klasičnem razvojnem modelu mora biti naročnik tudi potrpežljiv, saj je rezultat dela razviden šele na samem koncu razvojnega cikla. Bistvene pomanjkljivosti se tako lahko pokažejo šele na koncu razvoja, ko postane vsaka sprememba izredno draga. Klasičen razvojni cikel programske opreme zajema faze: Analiza kjer opredelimo problem, Modeliranje kjer določimo arhitekturo, Implementacija kjer zgradimo program, Testiranje kjer s testiranjem in odstranjevanjem napak ter razhroščevanjem zagotovimo kakovost programa... Za izpeljavo opisanih faz razvoja nam je na voljo več možnih modelov: extremno programiranje (XP programing), agilno programiranje (Agile programing),»slap«waterfall programiranje, Pospešen razvoj aplikacij (Rapid aplication development) RAD programing, Racionalni poenoten proces RUP Rational Unified Process, Iterativno programiranje (Iterative programing), Poenoteni proces razvoja programske opreme - Unified Software Development Process oziroma Poenoteni Proces (Unified Proces) itd... Stran 10

15 V našem podjetju za razvoj aplikacij uporabljamo metodo Poenoten Proces (Unified Process), ki je iteracijski in naraščajoči razvojni proces programske opreme. Glavna lastnost/ideja iteracijskega programiranja, ki jo moramo upoštevati v praksi, so kratka, časovno omejena obdobja, pri katerih imamo z uporabo iteracij zelo prilagodljiv razvoj. Metoda je zasnovana tako, da daje rezultate že v zgodnjem razvoju projekta, kjer so definirani samo osnovni gradniki in funkcije z namenom zagona osnovnih funkcionalnosti. Nekaj odličnih nasvetov in ključnih pravil, ki omogočajo kvalitetno uporabo metode in uspešen razvoj projekta so.: (Larman, str. 590) Investiranje v kritične in dražje dele projekta v začetnih iteracijah. Konstanten stik z uporabniki. V zgodnjih fazah razvoj enotne, dobro integrirane arhitekture jedra. Konstantno preverjanje kakovosti, dovolj zgodaj in pogosto. Vizualna predstavitev programske opreme. Previden nadzor/upravljanje vseh zahtev. Nadzor sprememb. V metodi UP Poenotenega procesa so posamezne faze iteracij: Spoznavanje - Inception Analiza, načrtovanje - Elaboration Izdelava - Construction Prenos v uporabo - Transition Omenjena metoda iteracij ne pomeni, da se najprej izdela pilot, ki se ga nato zavrže in izdela pravi izdelek. Posamezna iteracija je izvedena tako, da so njeni rezultati uporabni v naslednjih iteracijah. Po vsaki iteraciji je možno izdelek dejansko tudi uporabljati v funkcionalnosti, ki je bila predvidena za to iteracijo. Na tak način lahko končni uporabniki sodelujejo že v zgodnjih fazah projekta in vplivajo tudi na nadaljnji potek projekta. Metodologija»UP«poenotenih procesov se razlikuje od faznega pristopa v tem, da se posamezne iteracije med seboj prepletajo in dopolnjujejo. Tako je del rezultata predhodne iteracije tudi že del specifikacije naslednje iteracije. Stran 11

16 5 ANALIZA BAZ PODATKOV 5.1 PREDSTAVITEV BAZ PODATKOV Program mora prikazati vse podatke iz spodnjih tabel v smiselnih povezavah. Pri gradnji tabel v bazah se praviloma ne uporablja šumnikov, ki so trenutno uporabljeni pri imenih polj posamezne tabele v bazi in sicer zaradi lažjega razumevanja pomena polj. 1. Tabela: Tabela prikazuje možen izbor plačila za državo TABELA DRZ_NACPLACILA možni izbor plačila za državo IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA država mednarodna oznaka države DA AN 3 nač_plačila način plačila DA AN 2 2. Tabela: Tabela prikazuje podatke o državi. TABELA: DRZ_PLACILA - podatki o državi IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA št_podjetja številka podjetja DA N 5 nač_plačila: način plačila DA AN 2 yn_predplačilo dovoljeno predplačilo NE AN 1 yn_internet yn_dostava yn_dolgoročno omejitev_znesek_od omejitev_znesek_do dovoljen nakup preko interneta dovoljena dostava vozila dovoljen dolgoročni najem vozila minimalna možna plačilna vrednost Maksimalna možna plačilna vrednost NE AN 1 NE AN 1 NE AN 1 NE N 10 NE N Tabela: Tabela prikazuje razširjene podatke o posamezni državi. TABELA: VSI_PARAMETRI - tabela ki vsebuje vse splošne parametre IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA veljaven_datum1 datum veljavnosti NE N 8 veljaven_datum2 datum veljavnosti NE N 8 veljaven_datum3 datum veljavnosti NE N 8 veljaven_datum4 datum veljavnosti NE N 8 Stran 12

17 valuta trenutna veljavna DA AN 4 valuta v državi jezik uradni jezik države DA N 2 država uradna oznaka države DA AN 3 euro_datum vključena v evropsko unijo od: datum NE N POTEK PRIDOBITVE PODATKOV IZ BAZE NA ZASLON Podatke prikličemo z uporabo SQL poizvedb. Natančneje, programer dobi podatke preko naslednje kodne hierarhije: Javascript kreira batch s potrebnimi iskalnimi podatki, o Cobolska metoda preveri vnosne podatke in prikliče v uporabo, Izbrani sql stavek, ki nam vrne rezultate iskanja, Funkcija v batch-u obdela vrnjene podatke in jih prikaže na zaslonu. Tabele se kliče preko ukazov SQL, ki so»zaviti«v cobolske metode z že nekaterimi pravili. Ta pa morajo upoštevati aplikacije glede na poslovno logiko podjetja, cobolske metode se kličejo s programskim jezikom javascript, preko objektov, vgrajenih že v samo programsko ogrodje. Najbolj pogosto uporabljen objekt je sxbatch, podatki, vrnjeni iz cobolske metode, pa se predstavijo s pomočjo grafičnega vmesnika XUL. Celotna programska rešitev deluje asinhrono. 5.3 TRINIVOJSKA ARHITEKTURA Namen zasnove novega objekta gantograma v obstoječi aplikacijski sistem, ki temelji na trinivojski arhitekturi podatkovni strežnik-aplikacijski, strežnik-uporabniški vmesnik, je odprava pomanjkljivosti trenutnega sistema, poleg tega pa razširitev funkcionalnosti in povezljivosti ter omogočanje enostavnejše uporabe že obstoječih aplikacij. Nivoji trinivojske arhitekture so: uporabniški nivo, ki opisuje uporabnikov pogled na okolje, skozi katero dostopa k sistemu in upravlja z njim. Uporabniški nivo predstavlja delovna postaja odjemalca; poslovni nivo je nov nivo glede na dvonivojsko arhitekturo. V njem se oblikuje in odvija problematika aplikacije; nivo dostopa do podatkovne baze, ki omogoča dostop sistema k podatkom, vključuje shranjevanje in doseganje podatkov, dostop na disk in do podatkovne baze. Dostopni nivo predstavlja strežnik podatkovne baze. Stran 13

18 PREDNOSTI Prednost takšne strukture informacijskega sistema se v prvi vrsti odraža v povečanju skupnih zmogljivosti celotnega sistema. Poleg izboljšanja zmogljivosti sistema zaradi zmožnosti integracije raznovrstnih orodij, trinivojska arhitektura omogoča, rešitve za izdelavo boljših in uporabniku prijaznejših vmesnikov. Za razvoj poslovnega nivoja se odpira možnost istočasne uporabe različnih razvojnih orodij, ki lahko dostopajo do različnih podatkovnih baz, kar je lahko zelo koristno pri prehodu na drugo podatkovno bazo ali pri delu z različnimi podatkovnimi bazami. Skalabilnost trinivojske arhitekture aplikacij je naslednja velika prednost. Povečanje števila uporabnikov dvonivojske aplikacije istočasno povečuje tudi količino podatkov in število operacij, ki se izvajajo na strežniku. Edina možnost, da se ohranijo zmogljivosti celotnega sistema, je povečanje kapacitete strežnika, kar pa ima seveda svoje meje. Ta problem se lahko pri trinivojski aplikaciji zelo enostavno reši z dodajanjem novega strežnika za poslovni nivo. Na vsakem od strežnikov se lahko odvija isti proces, uporabnik pa dostopa do tistega, ki je trenutno najmanj obremenjen. Vsi strežniki poslovnega nivoja komunicirajo istočasno s podatki na istem strežniku s podatkovno bazo, ki je v tem primeru manj obremenjen, ker se na njem ne odvijajo več procesi poslovnega dela aplikacije. Zelo pomembna lastnost trinivojske arhitekture je možnost uporabe raznovrstnih platform uporabniškega vmesnika. Aplikacija se odvija na enem podatkovnem strežniku in na enem ali več strežnikih poslovnega nivoja, medtem ko se uporabniški nivo lahko razvije tako, da se istočasno odvija na različnih odjemalčevih platformah, priključenih na iste strežnike poslovnega nivoja. Poleg tega so prednosti tako zasnovanega sistema še: s tehničnega vidika: o zagotovitev visokega nivoja varnosti podatkov (dostopi, transakcije), o stabilnost sistema neodvisnost podatkov od odjemalca, večja konsistentnost... o enostavnejša komunikacija in integracija z drugimi sistemi prek XML-a, o omogočanje sledljivosti spreminjanja pomembnih podatkov, o praktično neomejeno število zapisov v tabelah, o učinkovit sočasen dostop do podatkov, o možnost izgradnje podatkovnih skladišč (presekov na dan D), z ekonomskega vidika: o potrebno bo manjše število zaposlenih za enake poslovne rezultate, o višja raven kakovosti izdelka, o implementirano ogromno znanja, kar kupcem zmanjša strošek izobraževanja zaposlenih, saj jih informacijski sistem v veliki meri vodi sam (implementirano tudi poslovno predvidevanje), o ločevanje razvijalci aplikacij lahko razdelijo rešitve na več delov, ki jih je lažje upravljati, Stran 14

19 SLABOSTI o centralizirano shranjevanje podatkov obdelava podatkov v trinivojskem modelu je distribuirana, shranjevanje podatkov pa centralizirano. o podatkovni strežnik hrani podatke in deluje kot koordinator za dostop do njih in za njihovo spreminjanje. To zmanjšuje količino odvečnih podatkov in pomaga pri njihovi skladnosti, tudi če z njimi dela več uporabnikov/odjemalcev, o Varnost ker je ta model premaknil podatke z namizja in je centraliziran, je zagotavljanje varnosti podatkov lažje. Podatkovni strežnik je varno shranjen pod ključem, kar preprečuje namerne posege vanj, nepričakovane nesreče, nepooblaščen dostop ali nenadejane prekinitve, do katerih utegne priti. Slabosti sistema so: 1. zapletena implementacija: razvoj programske opreme pomeni drobljenje problema na koščke, da ga je lažje rešiti. Da bi bolje izkoristili prednosti distribuirane obdelave, postane nemalokrat zasnova rešitve odjemalec/ aplikacijski strežnik/podatkovni strežnik zelo zapletena; 2. cena: distribuirano računalništvo je že po svojem bistvu bolj zapleteno in zato zahteva bolj izučene/izkušene razvijalce in izdelovalce. S tem pa so stroški proizvodnje večji; 3. dolg proizvodni čas: ponovno je kriva večja zapletenost, saj je za izdelavo zahtevnejše rešitve potrebno več časa in znova se zvišajo stroški projekta. Stran 15

20 6. PREDLAGANA REŠITEV 6.1 RAZVOJ PROGRAMSKE OPREME Pri pripravi specifikacije za projekt, je potrebno organizirati sestanke z zadolženimi na projektu in definirati potrebno funkcionalnost objektne nadgradnje programa. Če je možno, se po internem dogovoru osnutek dokumentacije pripravi pred sestankom. Med sestankom in po njem, se nato lahko dokumentacijo že takoj popravi in dopolni. Na prvem sestanku se razdelijo zadolžitve: kreiranje osnovnega jedra objekta, ki opravi zahtevano osnovno funkcionalnost. To je prikaz podatkov na gantogramu v časovni odvisnosti. predlagajo se osnovne lastnosti oziroma zmogljivosti objekta o sprejem podatkov v časovni odvisnosti z omejitvijo»oddo«npr: : :05 o prikaz različnih tipov vsebin v različni barvi o prikaz podatkov je omogočen v več pogledih z uporabo smernih gumbov letno mesečno dnevno urno o možnost prikaza osnovnih podatkov enega sklopa v grafičnem prikazu»tooltip«o uporaba zoom funkcije, ki omogoči dodatno, do minute natančno preglednost podatkov. Poglavitna lastnost je, da razširi trenutni pogled neodvisno od velikosti okna o testiranje določenih še neuporabljenih grafičnih elementov xul in ugotovitev ali ima njihova funkcionalnost možnosti potencialne vgradnje ali kasnejše nadgradnje objekta. Ko se skreira osnovni xul grafični vmesnik s testnimi podatki in vsaj večino osnovnih lastnosti, se ponovno skliče sestanek za pregled delovanja in hiter popravek že definiranih lastnosti, ki se lahko izkažejo, da so bile predvidene napačno. V samem postopku je več kratkih posvetov, kjer se programer oziroma programerja, v primeru nejasnosti dogovorita za nadaljnje korake, kako rešiti določene probleme, na primer: z povezavo objektov in obdelavo podatkov za pravilen končen prikaz podatkov. Ker gre za integracijo v večji sistem, je potrebno imeti še toliko več preglednosti nad delovanjem in povezovanjem že obstoječih programov, kar zahteva osebo, ki je na projektu prisotna že dalj časa. Ti vmesni sestanki so pomembni zaradi preprečitve programerju, da zaide na»stransko pot«. Velikokrat se zgodi, da zaradi napačne interpretacije podatkov, navodil, dogovora med zaposlenimi ali pomanjkljive začetne specifikacije projekta, Stran 16

21 programer intenzivno dela na kreiranju zapletene osnovne funkcionalnosti objekta, z napačne predstave o končnem zgledu. Za popravke takšnih napak se lahko porabi veliko časa, ki je bil že v naprej predviden za naslednje korake razvoja programske opreme. Programska oprema Sixt je večinoma razvita na dvonivojnem objektnem modelu, in sicer za manjše tipe aplikacij, ki ne vsebujejo zapletene poslovne logike. Kot na primer: pregled vsebine tabel, pregled in popravek šifrantov, itd... Če aplikacija zahteva asinhrono delovanje, ter višji nivo poslovne logike v interakciji z zaslonom, potem se uporablja trinivojni ali več objektni razvojni model. To pomeni, da se aplikacija razdeli na več objektov, ki so zadolženi za določene funkcije. Vsi ti objekti so zaželeni v posameznih datotekah, ni pa pravilo. Pomožni objekti se lahko nahajajo v skupni datoteki, ki je prosto dostopna glavnemu programu. Programsko kodo, ki vsebuje poslovno in GUI logiko, ter komunikacijo z bazo, lahko napišemo tudi v eni sami datoteki, program bo ravno tako opravljal svojo funkcijo. Po končani osnovni zasnovi funkcionalnosti programa naročnik želi program nadgraditi z dodatno funkcionalnostjo. Nadaljnji razvoj programske opreme je možen na več načinov. Kodo lahko ponovno napišemo v isto datoteko in funkcionalnost pišemo v isti razred. Pri delu hitimo, ker smo omejeni s časovnim rokom oddaje projekta. Posledično premalo dokumentiramo kodo, kopiramo že uporabljene dele kode na več različnih mest, ki opravljajo podobno funkcionalnost, sčasoma kreiramo večje zapletene funkcije, itd... Rezultat tega je: program je že več kot leto dni star, v tem času so se zamenjali tudi programerji ki so bili zadolženi za začetni razvoj. Dodatne manjše»izboljšave«so dodali spet tretji programerji, kateri so dobili nalogo»samo popravi«pa bo dovolj. Problem nastane, ko želimo to kodo popravljati ali znova razširiti PROGRAMSKI DESIGN ANTIPATERN BLOB Ko pogledamo takšno kodo, nepregledno, nedokumentirano, z ogromnimi zapletenimi funkcijami vse skupaj v enem razredu, temu rečemo BLOB. Generalno gledano je»blob«procedurni design model, ne glede na to, da so uporabljene objektno orientirane smernice in je kreiran z uporabo objektnega jezika. Procedurni design ločuje proces od podatkov, za razliko od objektnega modela, ki pa združuje procesni in podatkovni model, skupaj z vsemi ostalimi razdelki.»blob«vsebuje poglavitni del procesa, ostali objekti pa vsebujejo podatke. Programski arhitekti Bloba ločijo proces od podatkov, z drugimi besedami, raje uporabljajo procedurni stil namesto objektno orientirane arhitekture.»blob«je rezultat napačnega lokacijskega pozicioniranja/planiranja kode. Primer: Lahko je programski modul, katerega naloga je, da je nadrejen vsem ostalim delom sistema za sistemsko kontrolo. Velikokrat je»blob«tudi rezultat iteracijskega razvoja programske opreme, saj se konceptna koda sčasoma razvije v prototip in na koncu v produkcijski sistem. To se velikokrat»zlorablja«pri uporabi programskih jezikov, ki so v osnovi centralizirani na GUI, npr: Visual Basic, ki dovoljuje preprosti formi, da razvije svojo funkcionalnost in Stran 17

22 namen že v začetnem razvoju ali po definiranju prototipa. Ker lokacijsko prepozicioniranje logično povezane kode z istimi obveznostmi, ni narejeno med samo evolucijo sistema, en modul postane dominanten. V»Blobu«najdemo tudi nepotrebno kodo, kar nam otežuje razlikovanje med uporabno funkcionalnostjo tega razreda in kodo, ki ni več v uporabi. (str. 74, 75. Anti Paterns). Kako prepoznati»blob«: Samostojni razred, ki ima veliko atributov in/ali operacij. Razred z več kot 60 atributi in operacijami nakazuje na»blob«. (Akroyd 96). Raznolika kolekcija nepovezanih atributov in operacij, vgrajenih v en sam razred. Nezdružljivost atributov in operacij je značilnost»blob-a«. Samostojni nadzorni razred, povezan z enostavnimi podatkovno-objektnimi razredi. Odsotnost objektno orientiranega design-a. Migriranje starejšega design-a, ki ni bil pravilno prenesen v objektno orientiran design. Razred je kompliciran za testiranje in ponovno uporabo. Lahko je neučinkovit, ali pa predstavlja kopleksno integracijo za ponovno uporabo. Razred preveč obremeni/zapolni delovni spomin, zavzame veliko resursov, tudi za najenostavnejše operacije. Tipični razlogi za nastanek»blob-a«: Pomanjkanje objektno orientirane arhitekture: Programerjem manjka poznavanje principov objektno orientiranih principov. Ekipi manjka primernih abstrakcijskih zmogljivosti. Pomanjkanje (katerekoli) arhitekture: Odsotnost definicij sistemskih komponent, njihovih interakcij in predpisane uporabe posameznih programskih jezikov. Pomanjkanje vztrajanja pri predpisani arhitekturi: Čeprav je bila arhitektura načrtovana, se to pogosto zgodi pri programerjih ali ekipi, ki je nova pri objektno orientirani arhitekturi. Preveč omejena intervencija: Programerji radi dodajo male koščke funkcionalnosti k obstoječim delujočim razredom, namesto, da kreirajo nove razrede ali pa ponovno pregledajo razredno hierarhijo za novo lokacijsko pozicioniranje funkcij po razredih. Izjema:»Blob«je spremenljiv, ko zavijamo»legacy«sisteme. Ni potrebe po razdeljevanju kode, samo dodamo zaključni sloj kode, da naredimo»legacy«sistem bolj dostopen OBJEKTNO ORIENTIRAN DESIGN ANTIPATERN POLTERGEIST V objektno orientiranem design-u moramo biti pozorni, da ne naredimo napak, ki jih kot skupno celoto lahko opišemo kot Antipatern Poltergeist. Poltergeist so razredi, ki Stran 18

23 vsebujejo omejene zadolžitve in pravice v celotnem sistemu. Omejuje programski design in ustvarja nepotrebne abstrakcije, ki so prezapletene, težko razumljive in težko vzdrževane. Značilen je v primerih ko je programer dobro poučen o procesnem designu in nov pri objektno orientiranem designu. V takšnem designu se velikokrat pojavi začasni razred samo za trenutek, da lahko zažene določeno operacijo ali pa celo zažene pomembnejši, stalni razred. Takšnem tipu razreda rečemo»gipsy Wagons«(Akroyd 96). Njihov namen je inicializirati določene metode drugih razredov, ponavadi že v vnaprej določenem zaporedju. Obstajajo trije pomembni razlogi, zaradi katerih je to slaba izvedba design-a: Prednosti objektne arhitekture: Lažje odpravljanje napak razhroščevanje. Lažja razširitev že obstoječih funkcij. Ponovna uporabljivost modulov se poveča. Enostavna zamenjava celotnega objekta. Objekti lahko odražajo entitete realnega sveta. Povečana kakovost programske opreme. Pri doslednem upoštevanju objektnega pristopa zmanjšamo čas razvoja. Slabosti objektne arhitekture: Časovno potratna. Visoka cena razvoja aplikacij. Kompleksne entitete včasih težko prestavimo z objekti. So nepotrebni in porabljajo nove resurse ob vsaki njihovi uporabi So pomanjkljivo zasnovani, saj uporabljajo več različno zasnovanih pomožnih navigacijskih poti. So v napoto k pravilni zgradbi objektno orientiranega design-a, ker nepotrebno zmanjšujejo zmogljivosti objektnega modela. Klasični simptomi in posledice: Redundantna navigacijska pot Prozorne asociacije Razredi brez»pomena«začasni, časovno kratki objekti in razredi. Razredi z eno samo operacijo, ki obstajajo samo zato, da za začasno asociacijo prikličejo druge razrede. Razredi poimenovani po operacijah z uporabniškega vidika, na primer:»zaženi proces alfa«. Tipični vzroki: Pomanjkanje objektno orientirane arhitekture: Programerji ne poznajo objektne arhitekture. Izbira napačnega»orodja«za delo: V nasprotju s splošnim prepričanjem, objektni design ni nujno prava izbira. Stran 19

24 Napačna specifikacija Kot v Blob-u, vodstvo projekta lahko predpiše arhitekturo med procesom analize. To ni priporočljivo, saj vodi k napačnim protivzorcem. 1. Slika: Slika prikazuje shemo povezanih razredov, ki vsebujejo omejene zadolžitve POVEZOVALNI OBJEKT OBJEKT 1 OBJEKT 2 GLAVNI RAZRED OBJEKT 3 OBJEKT 4 POMOŽNI OBJEKT Rešitev: Neprimerno kodo je potrebno v celoti odstraniti iz hierarhije razreda. Ker pa sedaj manjka funkcionalnost, ki je vse skupaj povezovala, to rešimo z dodajanjem podobne funkcionalnosti v razrede, ki jih je»poltergeist«klical. Kot vmesnik dodamo razred, ki ostale pomožne nadzoruje in povezuje z glavnim razredom. 2. Slika: Slika prikazuje shemo povezanih objektno orientiranih razredov GLAVNI RAZRED POMOŽNI OBJEKT KONTORLNI OBJEKT NADZO- RNI OBJEKT OBJEKT 1 OBJEKT 2 OBJEKT 3 OBJEKT 4 Stran 20

25 6.1.3 PROGRAMIRANJE ANTIPATERN SPAGETTI CODE»Spagetti«koda se pojavlja v programih ali sistemih, ki vsebujejo zelo malo programske arhitekture. Zato v takšnih primerih, pisanje kode in agresivno razširjanje ogrozi programsko strukturo. Programer, ki je program ali sistem zasnoval lahko zgubi preglednost nad strukturo. Če razvijamo z uporabo objektno orientiranega jezika, bo verjetno programska oprema vsebovala majhno število objektov ki vsebujejo metode z zelo velikimi implementacijami, ki kličejo en, večfunkcijski procesni»flow«tok. Zaradi tega so objektne metode klicane v zelo predvidljivem zaporedju in obstaja zanemarljiva stopnja dinamične interaktivnosti med posameznimi objekti v sistemu. (Anti Paterns, str 120) Takšen sistem je zelo težko vzdrževati in razširiti, in ne pojavi se nobena priložnost za ponovno uporabo objekta in modula v podobnih sistemih. Simptomi in posledice: Po končanem rudarjenju kode je samo del objekta in metod ponovno uporabnih. Treba je upoštevati, da je rudarjenje»spaghetti«kode lahko zelo visok finančni vložek pri izpeljavi oziroma izboljšavi projekta. Metode so zelo procesno orientirane. Občasno se celo pojavi poimenovanje objekta po procesu. Potek izvedbe je diktiran s strani objektne implementacije, ne pa s strani objektov klienta. Vzorec uporabe objektov je zelo predvidljiv. Koda je težko ponovno uporabna, ko pa je se uporabi kloniranje. V večini primerov koda ni mišljena za ponovno uporabo. Iz industrije je zelo težko pridobiti objektno orientirane talente. Programska oprema hitro doseže rok svoje uporabnosti. Vložen trud in posledično finančni znesek potreben za vzdrževanje, je večji kot strošek razvoja nove programske opreme. Tipični vzroki: Neizkušenost z objektno orientirano tehnologijo. Pomanjkanje mentorstva, revizije kode ne prinesejo rezultatov. Brez design-a pred implementacijo. Velikokrat delo programerjev, ki delajo v sami. Izjeme:»Spaghetti«kode je spremenljiva samo v primeru, če je grafični vmesnik logično povezan in je samo implementacija»spaghetti«. V tem primeru dejansko naredimo Stran 21

26 ovoj okoli dela kode, ki ni objektno orientirana. Če ima ta del kode kratko življenjsko dobo in je logično ter čisto ločen v samem sistemu, potem je takšno pisanje kode začasno upravičeno. Resničnost v industriji programske opreme je, da se programski koncerni podredijo poslovnim koncernom, kar je pomembno za njihov poslovni uspeh, posledično tudi za obstoj poslovnih koncernov. V večini primerov je tako potrebno dostaviti končano programsko opremo v najkrajšem možnem času. Če programerji nimajo dovolj izkušenj na določenem področju, je smiselno kreirati programsko opremo, z namenom, pridobiti izkušnje in kasneje tudi kreirati programsko opremo z novo pridobljenim znanjem ter izkušnjami. Prenova programske kode (kodno čiščenje) Prenova programske kode je nujni del programskega razvoja. Sedemdeset odstotkov ali več stroškov predstavljajo razširitve in dodelave pri razvoju programske opreme. Zato je zelo pomembno, da arhitekturo programske kode pišemo in vzdržujemo, tako da sprejema možne razširitve. Ko celotna struktura postane ogrožena, ker mora podpirati nepredvidene zahteve, možnosti razširitve postanejo minimalne, ob stopnjevanju zahtev celo nične. V idealnem primeru bi moralo biti kodno čiščenje del normalnega delovnega procesa. Ko se doda nov sklop kode, nova funkcionalnost, bi moralo slediti kodno čiščenje, ki bi popravljalo in izboljšalo kodno strukturo. Ta del delovnega procesa se lahko pojavi urno ali dnevno, odvisno od frekvence pogostosti dodajanja nove funkcionalnosti programski opremi. Čiščenje kode tudi podpira izboljšave na performančnem področju. Bistvo performančne optimizacije je, da spremembe ustvarimo na 10 % obstoječe kode in tako zagotovimo 90 % optimalnega delovanja. Za programiranje samostojnih podsistemov ali aplikacij, performančna optimizacija predstavlja kompromise h kodni strukturi. Vedno nam morajo biti poglavitni trije cilji: 1. Zadovoljiva kodna struktura. 2. Z meritvami ugotovimo kje obstaja performančno kritična koda. 3. Previdna implementacija vseh možnih popravkov in strukturnih kompromisov z namenom optimizacije. Lahko se tudi zgodi, da je potrebno popravke odstraniti in kodo vrniti v prvotno stanje, vse z namenom, da omogočimo možne razširitve. V takšnih primerih je pomembno da imamo kvalitetno dokumentacijo o vseh spremembah kode, s čimer si zagotovimo ohranitev programske strukture v prihodnjih različicah. Najprimernejši način za popravek/odpravo»spagetti«kode protivzorca je s preventivo. Preden začnemo pisati kodo, dobro razmislimo in predvidimo postopek Stran 22

27 izgradnje. Če pa je koda že v tako slabem stanju, da je neobvladljiva, ideja da projekt začnemo znova ni realna rešitev. Še vedno pa obstajajo koraki, ki omogočijo rešitev takšne kode, preden jo zavržemo. V združevalnem procesu moramo vedno, ko je dodana nova funkcionalnost k že obstoječi»spagetti«kodi, ne samo preprosto dodati novo kodo k obstoječi, temveč vedno skušati integrirati dodatno kodo z reorganizacijo obstoječe. S tem obstoječo in novo kodo združimo v boljšo in za vzdrževanje lažjo celoto. Reorganizacija kode, se pravi spremembe strukture kode ne da bi spremenili cilj njenega delovanje, zahteva izvedbo naslednjih operacij: 1. Pridobiti kontrolo nad spremenljivkami v razredu z uporabo»accessor«funkcij. Napisati novo in reorganizirano kodo, ki uporabljajo»accessor«funkcije. 2. Spremeniti delček sklopa kode v funkcijo, ki jo lahko ponovno uporabimo v prihodnjih vzdrževalnih in reorganizacijskih posegih. Zelo pomembno je, da se izognemo postopku»kopiraj prilepi«in tako omejimo možnost širjenja enakih napak. 3. Reorganizirati argumente funkcij, da pridobimo na konsistenci skozi celotno kodno strukturo. 4. Odstraniti dele kode, ki lahko postanejo ali pa so že zastarani, neuporabni oz nedostopni. S tem se izognemo prihodnjemu oteženemu razumevanju kode. 5. Preimenovati razrede in funkcije ter podatkovne tipe, da ustrezajo poslovnim in industrijskim standardom ali pa entitetam za lažje vzdrževanje. Večina programskih orodij nudi podporo za globalno preimenovanje PREDSTAVITEV REŠITVE - GANTOGRAM S programskimi orodji, ki so opisana v prejšnjih poglavjih, sem predlagal naslednjo rešitev: Grafični uporabniški vmesnik, zgrajen s tehnologijo XUL (grafični vmesnik, ki temelji na tehnologiji XML). Poizvedbe v bazo upravljajo cobolske metode, v katerih je po hierarhiji do zadnje metode, kjer se hrani samo SQL poizvedba, razdeljeno, katera vrne zahtevane podatke. Koda, ki združuje obe opisani tehnologiji, je JavaScript. Z njo pravilno povežemo kličoče cobolske metode, začasne hranitve podatkov, uredimo podatke za želeni izpis na zaslonu v namenska tekstovna polja, drevesne strukture podatkov, izbirne menije, mrežo, različne združljive elemente... in predvidevamo uporabniško interakcijo z grafičnim vmesnikom ZGRADBA PO DATOTEKAH Koda za izgradnjo grafičnega vmesnika se nahaja v datoteki z imenom programa ali dela programa, ki ga podpira (npr: gantogram.xul). Osnovna datoteka je nosilec Stran 23

28 obstoječega programa in povezovalec s celotnim sistemom. Vsak posamezen del programa in svojo datoteko s funkcijami ter datoteko z grafičnim vmesnikom. Vsak program ima tudi svojega konstruktorja, da lahko znotraj posameznega programa kreiramo funkcije za svoj objekt. Vsakemu programu kreiramo konstruktor in ga združimo z osnovnim konstruktorjem, tako da lahko do njega dostopamo preko katerekoli datoteke. Koda je razporejena po različnih datotekah. V eni datoteki, ki je nosilna imamo osnovno postavitev. Nato so tej datoteki pripete še ostale nosilne za posamezni del. Za delo z zunanjimi objekti imamo posebno datoteko, v kateri je koda, ki nam omogoča komunikacijo in usklajevanje s tem objektom in delo s trenutnimi podatki. Programska koda za povezavo objekta gantograma v samo aplikacijo se naredi v osnovni datoteki programa ki ga želimo razširiti. Potrebne klice v datoteki za komunikacijo z bazo, ostale dodatne funkcije, ki spremenijo podatke ali dodajo edinstveno funkcionalnost programu in gantogramu, pa dodamo v objektno datoteko programa, ki je temu namenjena. Programska koda je razdeljena na datoteke: kjer so povezave na bazo (JavaScript datoteka), kjer se upravlja s podatki (JavaScript datoteka), kjer je zrisan grafični vmesnik (Xul datoteka). Gantogram samostojna JavaScript datoteka vsebuje: funkcije za manipuliranje podatkov v časovni odvisnosti, funkcije za kontrolo dogodkov s strani uporabnika, funkcije za pravilen prikaz gradnikov v časovni premici. 6.3 NAMEN Gantogram bo uporabnikom omogočal preglednost podatkov na časovni premici. Z različnimi barvnimi kombinacijami bo omogočen pregled podatkov na mreži. Podatki, ki bodo prikazani za preteklo poslovanje, se pravi že zaključena izposoja avtomobilov, bodo označeni z zeleno barvo. Podatki, ki pa prikazujejo prihodnje poslovanje podjetja, to so že vnesene rezervacije, bodo pa označeni s temnejšim odtenkom modre. Z lebdenjem miške nad določenim zasedenim poljem se bodo prikazali podatki specifični glede na trenutno polje. Z izbiro desnega klika miške, kjer se bo prikazal padajoči izbirni meni, bo možno izbrati še dodatne, bolj podrobne podatke o rezervaciji ali pa najemnem sporazumu trenutno izbranega gledanega vozila. Enako lastnost oziroma funkcijo bo imel miškin dvoklik, ki pa bo prikazal samo nadrejeno opcijo, podatek ki je v zaporedju na gantogramu prvi. Preko funkcije razširitve, ki nam omogoča podrobnejši vpogled v časovno premico, bo uporabniku omogočen še bolj natančen pregled rezervacij in najemnih pogodb saj bo prilagodljiva polja možno raztegovati do tisočkratnika osnovne enote. Stran 24

29 Podatke se bo pregledovalo po omejenih kosih, se pravi glede na mesece (30 dni), dneve (24 h) in ure (60 min). Premikanje med vsemi podatki pa bo možno s pomočjo kontrolnih tipk (prejšnji naslednji mesec, dan, ura). Gantogram vsebuje kontrolno ploščo, kjer lahko nastavimo barvo posamezne prikazane enote. Kontroliramo lahko tudi trenutni želeni prikaz različnih vrst podatkov na gantogramu, z izbiro/ne izbiro»checkbox-a«za posamezno vrsto podatkov, kar nam omogoča večjo preglednost, izboljša funkcionalnost... Ob dodajanju novih podatkov na že obstoječi gantogram imamo možnost izbire: Ob pritrdilni izbiri se kreira nov pogled gantograma z želenimi novimi podatki. Ob nikalni izbiri se podatki dodajo k skupini podatkov ki so že prikazani na gantogramu. Ob dvokliku na časovno skalo bo omogočen poglobljen pogled izbranega nadrejenega podatka. Za trenutni dan v mesecu bo dvoklik na izbrani dan omogočil štiriindvajseturni pogled izbranega dneva, nadaljnji dvoklik na izbrano uro pa minutni pogled izbrane ure. INICIALIZACIJA IN UPORABA Gantogram lahko dodamo k programu z uporabo JavaScript funkcije programskega ogrodja,»uporabi_enkrat«ali pa popravimo datoteko Xul in dodamo pot do nje, da se zažene ob zagonu aplikacije in s tem omogočimo avtomatsko nalaganje ob zagonu programa. V programu, kjer želimo dodati gantogram kot novo funkcionalnost, programa moramo najprej deklarirati novo instanco objekta: this.gg = new GANTT_GRID(); nato pa v sklop funkcij, kjer dobimo vse potrebne podatke že iz baze, kličemo funkcijo set_gannt_data, ki je osnovna za sprejem podatkov. batch.add_cobol(params1, [this, function(ret, ud, batch) { ret.out.key = ud.resn; ret.out.mvnr = ud.resn; ret.out.type = "RS"; ret.out.color = "#33CC00"; ret.out.cb = function(vals) { ra_gc.open_win_res_info(parseint(vals.key)) }; bnl = ud.ra.concat(ret.out); this.gg.set_gantt_data(bnl, count_data); } batch.execute({async: 1}); Stran 25

30 V osnovni funkciji najprej vse sprejete podatke filtriramo skozi zanko, kjer iščemo največji in najmanjši datum, nato pa na podlagi tega naredimo novo tabelico z urejenimi podatki za nadaljnjo obdelavo. GANNT_CHART.prototype.set_gantt_data = function(ret, count_data) { var data = ret; this.counter = this.counter + 1; var udaa = {}; var rdaa = {}; var flex_data = []; for (var i = 0, fdat = , tdat = 0, utime = , rtime = 0; i < data.length; i++) { var uda = sixt.human_date_to_cobol(data[i].uda) == false? data[i].uda : sixt.human_date_to_cobol(data[i].uda); var rda = sixt.human_date_to_cobol(data[i].rda) == false? data[i].rda : sixt.human_date_to_cobol(data[i].rda); } } var nu = 3; var nt = 2; var nr = 1; Ko so podatki urejeni in imamo že možnost kreiranja za osnovni pogled, ki je v tem primeru dnevni pogled in prikazuje celotni mesec v dnevih, moramo pripraviti podatke glede na izbiro pogleda in jih temu primerno oblikovati. if (view == "DD") { for (i = 0; i < data.length; i++) { if (data[i].uda.slice(0,8) >= this.movetofirstdayofmonth(this.get_present_date(chk_date)) && data[i].rda.slice(0,8) <= this.movetolastdayofmonth(this.get_present_date(chk_date)) (data[i].uda.slice(0,6) <= chk_date.slice(0,6) && data[i].rda.slice(0,6) >= chk_date.slice(0,6))) { } } } Funkcija set_gantt_timeline pa nam omogoči zbrane podatke z xul elementi vizualno prikazati na časovni premici v obliki gantograma. Stran 26

31 GANNT_CHART.prototype.set_gantt_timeline = function(tl_s, tl_e, gap, all_sarr) { var ra_dc = parent.frames["ra34_chart"].document; var overgrid = ra_dc.getelementbyid("overgrid"); var st_timeline = ra_dc.getelementbyid("st_timeline"); var hbox = ra_dc.getelementbyid("timeline_prim"); var ogc = ra_dc.createelement("columns"); var ogr = ra_dc.getelementbyid("overgrid_rows"); this.add_gap = this.add_days; var gap_id = 0; switch (gap) { case "YYYY": this.add_gap = this.add_years; break; case "MM": this.add_gap = this.add_months; gap_id = "DD"; break; case "DD": this.add_gap = this.add_days; gap_id = "hh"; break; case "hh": this.add_gap = this.add_hours; gap_id = "mm"; break; case "mm": this.add_gap = this.add_minutes; break; }; hbox.setattribute("align", "center"); var all_dates = []; if (gap == "hh") { this.hrs_in_day = []; this.lbl_min = []; }; for (var i = tl_s; i <= tl_e ; i = this.add_gap(i, 1)) { var tb = document.createelement("textbox"); var co = document.createelement("column"); if (gap == "DD") { tb.setattribute("value", sixt.cobol_date_to_human(i.slice(0,8))); }; if (gap == "hh" gap == "mm") { Stran 27

32 tb.setattribute("value", i.slice(8,10)+":"+i.slice(10,12)); }; tb.setattribute("date_value", i); tb.setattribute("gap_value", gap_id); tb.setattribute("id", "tbox"); tb.setattribute("class", "min_label"); tb.setattribute("observes", "bc_column_width"); hbox.appendchild(tb); } co.setattribute("observes", "bc_column_width"); co.setattribute("class", "v_line"); co.setattribute("id", "v_line"); ogc.appendchild(co); all_dates.push(sixt.cobol_date_to_human(i.slice(0,8))); if (gap == "hh") { this.hrs_in_day.push(i); this.lbl_min.push( sixt.cobol_date_to_human(i.slice(0,8)) +" "+i.slice(8,10)+":"+i.slice(10,12) ); }; if(!this.day_create) { this.create_days(all_dates, all_sarr); this.day_create = true; }; overgrid.removechild(overgrid.childnodes[0]); overgrid.appendchild(ogc); overgrid.appendchild(ogr); } st_timeline.removechild(st_timeline.childnodes[0]); st_timeline.appendchild(hbox); return st_timeline; Sam program vsebuje veliko funkcij za manipuliranje podatkov v časovni odvisnosti, kot je na primer: GANNT_CHART.prototype.add_days = function(date, days) { var yyyy = date.slice(0,4); var mm = date.slice(4,6); var dd = date.slice(6,8); var d = new Date(yyyy, (mm-1), dd); d.settime(d.gettime() + ((86400-d.getTimezoneOffset()*60) * 1000)); d.settime(d.gettime() + ((d.gettimezoneoffset()*60) * 1000)); Stran 28

33 } return this.build_date(d); GANNT_CHART.prototype.diff_minutes = function(date1, date2) { var date1_msec = this.to_js_date(date1).gettime(); var date2_msec = this.to_js_date(date2).gettime(); return Math.round(Math.abs(date2_msec - date1_msec) / (60 * 1000)); } GANNT_CHART.prototype.add_minutes = function(date, minutes) { var date_msec = this.to_js_date(date).gettime(); date_msec += (parseint(minutes, 10) * 60 * 1000); var new_date = new Date(); new_date.settime(date_msec); return this.build_date(new_date); } GANNT_CHART.prototype.build_date = function(date) { var YYYY = date.getfullyear(); var MM = this.prefill(date.getmonth() + 1); var DD = this.prefill(date.getdate()); var hh = this.prefill(date.gethours()); var mm = this.prefill(date.getminutes()); var ss = this.prefill(date.getseconds()); var val = YYYY.toString() + MM.toString() + DD.toString() + hh.tostring() + mm.tostring(); } return val; Stran 29

34 6.5 UVEDBA REŠITVE Programska rešitev se razvija na testnem sistemu, kjer se po dokončanju zastavljenih faz razvoja lahko z naročniki testira delovanje in predlaga nadaljnje razširitve. Za kakovostno uvedbo rešitve moramo od naročnika na začetku projekta pridobiti specifikacijo programske rešitve, na podlagi katere se izdela načrt izvršitve. Samo specifikacijo lahko izvajalec pripravi za naročnika sam, priporočljivo pa je skupno sodelovanje naročnika in izvajalca. Pri uvedbi nove programske rešitve moramo čim natančneje poznati obstoječe okolje, da pravilno implementiramo dodatek k želenim programom in s tem zagotovimo nemoteno delovanje že obstoječega programskega ogrodja in aplikacije, ki jo nadgrajujemo. Programer, ki je na projektu prisoten šele krajši čas, mora na začetku obvezno intenzivno analizirati obstoječo strukturo in s tem zagotoviti uspešno integracijo nove programske rešitve v obstoječo. Testiranje alfa in beta verzije programske rešitve je zelo pomembno za uspešen razvoj nove programske rešitve in posledično odstranitev hroščev, saj je kasnejša uporaba programske rešitve merilo uspešnosti projekta. V obdobju testiranja poskušamo vključiti v uporabo aplikacije tudi končne uporabnike, saj s tem pridobimo veliko podatkov o kakovosti projekta.po začetku uporabe aplikacije se po določenem obdobju pridobijo informacije končnih uporabnikov. Koristne informacije se preveri, če so uporabne kot ideje za nadgradnjo aplikacije. Na željo kupca se lahko implementira dodatne razširitve. 4. Tabela:Naloge za izvedbo rešitve ter predvideni stroški. Naloge Stroški - človek/dan Izdelava načrta izvršitve 3 / 3 Izgradnja alfa verzije programske rešitve in testiranje 2 / 30 Izgradnja in postavitev beta programske rešitve 1 / 20 Implementacija popravkov da ustreza specifikaciji 1 / 20 Uvajanje p.r. pri uporabnikih in prenos na produkcijski strežnik 3 / 25 Začetek uporabe programske rešitve ter vzdrževanje 1 / - Stran 30

35 6.6 MOŽNOSTI ZA NADALJNJI RAZVOJ PROGRAMSKE REŠITVE Možne razširitve programske rešitve : - uporaba gantograma za prikaz različnih vrst podatkov v odvisnosti od časa: o delovnih ur zaposlenih, o delovnih aktivnosti zaposlenih, o zasedenosti v prihodnosti s projekti podjetja, o načrtovanje poteka proizvodnje, o zasedenosti športnih objektov, - možno dodajanje sms obveščanja o prekoračitvah, različnih omejitvah o sms lahko prejmejo tako zaposleni kot morebitni naročniki - že pripravljeni predlogi rešitev ob opozorilu: o možnosti podaljšanja, prekinitve, zaključka, kreiranje novega termina. - dodati funkcionalnost»drag & drop«(potegni in spusti): o kreiranje kopije že obstoječih podatkov v prihodnosti, o v preglednem okolju enostavno kreirati novo zasedenost termina. Z dodatno funkcionalnostjo»potegni in spusti«bi gantogram pridobil na boljši uporabnosti in povezljivosti z ostalimi programskimi rešitvami v celotnem informacijskem sistemu. Preko enotnega grafičnega prikaza podatkov bi lahko s preprosto označbo časovnega termina kreirali novo rezervacijo ali najemno pogodbo, ob časovni spremembi jo preprosto prestavili na ustreznejši termin, ki bi ga program predlagal za potrditev. Po potrditvi bi program avtomatsko naredil vse potrebne spremembe poslovne logike podjetja. 6.7 PROBLEMI PRI RAZVOJU PROGRAMSKE OPREME Pri razvoju programske opreme je velikokrat prišlo do sprememb osnovnega algoritma za prikaz in izračun pravilne razdalje med prikazanimi elementi. Največji problem je zagotoviti uspešno prekrivanje elementov v časovni odvisnosti. Izhajali smo iz predpostavke, da je vedno razmik v času pri podatkih, pridobljenih iz baze za posamezno najemno pogodbo oziroma rezervacijo. Ker pa se lahko začneta in končata ob istem času, je to povzročilo spremembo pri dodatnih preverjanjih podatkov za posamezno najemno pogodbo oziroma rezervacijo. Pravilno zaporedje gradnje elementov za pravilno prekrivanje samih elementov v tehnologiji Xul je ravno tako povzročalo težave. Usklajevanje propustnosti za uporabniške odločitve oziroma akcije med navidezno mrežo, ki prikazuje časovne horizontalne linije, ter elementi, ki prikazujejo trajanje same najemne pogodbe oz rezervacije je porabilo kar precej časa razvoja. Vsi uporabljeni elementi se namreč niso pravilno odzivali na atribute propustnosti oziroma neodzivanje na uporabniške akcije. Stran 31

36 6.8 SLIKE UPORABE GANTOGRAMA Naslednje slike nam prikazujejo uporabo gantograma kot dodatek k programu pregled vozil. 3. Slika: Prikaz izbranih podatkov na gantogramu. Stran 32

37 4. Slika: Prikaz izbranih podatkov z uporabo funkcionalnosti razširitve, nastavljeno na 88 odstotkov. Stran 33

38 5. Slika: Prikaz izbranih podatkov z uporabo funkcionalnosti razširitve, nastavljeno na 236 odstotkov, kar omogoča poglobljen pogled na prikazane podatke. Stran 34

39 6. Slika: Prikaz dodatnih informacij, z miško trenutno izbrano rezervacijo. Stran 35

40 7. Slika: Prikaz dodatnih informacij, z miško trenutno izbrano najemno pogodbo. Stran 36

41 8. Slika: Prikaz podatkov za določen mesec in meni z možnostjo izbire prikaza želenega dneva v mesecu. Stran 37

42 7. LITERATURA Applying UML and patterns CRAIG LARMAN Comments on the iterative delepment and the Unified Process, chapter 37. page 589, 2002 Anti Paterns Refactoring software, architectures, and projects in Crisis. Avtorji: William H Brown, Raphael C Malveau, Hays W.»Skip«McCormick III, Thomas J. Mowbray 1998 Future of COBOL (PDF) 5. Legacy J Corporation (2003). ( ) JavaScript Bible 5th edition, Danny Goodman with Michael Morrison 2004 Projektno vodenje razvoja programske opreme (Franc Solina, 1997) Revija Monitor, April 2004, Povzetek članka»xul, maščevanje plazilca«, avtor Uroš Mesojedec c&articleid=266156&intsrc=article_rfavs ( ) Stran 38

43 PRILOGE Priloga 1: Dodaten opis tabel Priloga 2: Dodaten prikaz slik KAZALO SLIK Slika 1: Shema povezanih razredov, ki vsebujejo omejene zadolžitve. Slika 2: Shema povezanih objektno orientiranih razredov. Slika 3: Prikaz izbranih podatkov na gantogramu. Slika 4: Prikaz izbranih podatkov z uporabo funkcionalnosti razširitve, nastavljeno na 88 odstotkov. Slika 5: Prikaz izbranih podatkov z uporabo funkcionalnosti razširitve, nastavljeno na 236 odstotkov, kar omogoča poglobljen pogled na prikazane podatke. Slika 6: Prikaz dodatnih informacij z miško trenutno izbrano rezervacijo. Slika 7: Prikaz dodatnih informacij z miško trenutno izbrano najemno pogodbo. Slika 8: Prikaz podatkov za določeni mesec in meni z možnostjo izbire prikaza želenega dneva v mesecu. KRATICE IN AKRONIMI: Antipatern: proti vzorec Client: odjemalec Client-side: na strani odjemalca Code Mining: rudarjenje kode Mining: rudarjenje CVS: Concurrent versions system: sistem za kontrolo izvorne kode DNS: Domain Name Server: Domenski strežnik za imena v omrežju HTML: HyperText Markup Language: jezik za označevanje nadbesedila LAMP: akronim za skupino programov, ki skupaj tvorijo dinamični mrežni strežnik Linux: odprtokodni operacijski sistem MySQL: Relational Database System: Podatkovni upravljalni sistem XUL: extensible User-interface Language: Razširljiv jezik za grafične vmesnike PHP: Personal Home Page Tools: Orodja za spletno stran PDF: Portable Document Format: prenosljiva oblika dokumenta Server: strežnik Server-side: na strani strežnika SQL: Structured Query Language: Strukturiran poizvedovalni jezik Tooltip: grafični element, ki prikaže dodatne informacije ob lebdenju miške na mestu VPN: Virtual private Network: Navidezno zasebno omrežje VRML: Virtual Reality Modeling Language: jezik za modeliranje navidezne resničnosti XML: Extensible Markup Language: razširljiv označevalni jezik Stran 39

44 KAZALO TABEL V PRILOGI 5. Tabela: Podatki o mednarodnih (ISO) standardih 6. Tabela: Podatki o mestih, krajih. 7. Tabela: Podatki o mestih z poslovalnicami. 8 Tabela: Podatki o voznem parku podjetja. 9. Tabela: Administrativni podatki o voznem parku 10. Tabela: Podatki o voznem parku za posamezne poslovalnice. 11. Tabela: Podatki o kategorijah vozil 12. Tabela: Podatki o zgodovinah najemnih pogodb. 13. Tabela: Podatki o doplačilih pri najemnih pogodbah. 14. Tabela: Podatki o doplačilih pri rezervacijah. 15. Tabela: Podatki o plačilih pri najemnih pogodbah. 16. Tabela: Podatki o plačilih pri rezervacijah. 17. Tabela: Podatki na pogodbi. 18. Tabela: Podatki na računu. KAZALO SLIK V PRILOGI 9. Slika: Prikaz možnosti spreminjanja barve za najemno pogodbo ali rezervacijo. 10. Slika: Prikaz spremenjene barvne kombinacije za trenutno prikazano vsebino. 11. Slika: Prikaz izbire samo rezervacij v oknu nastavitve. 12. Slika: Prikaz samo rezervacije iz trenutno izbranih podatkov. 13. Slika: Prikaz izbire samo najemnih pogodb. 14. Slika: Prikaz najemnih pogodb iz trenutno izbranih podatkov. 15. Slika: Prikaz možnosti, ki se pojavijo ob izbiri desnega miškinega gumba iz trenutno prekrivanih podatkov. 16. Slika: Prikaz vprašanja, ki se pojavi, če že na obstoječi gantogram želimo dodati podatke. Priloga 1 5. Tabela:. Podatki o mednarodnih (ISO) standardih TABELA: STANDARD tabela iso standardov IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA Polje ime polja DA AN 4 Vsebina vsebina polja DA AN 10 Isost iso številka NE N 10 Isokoda iso koda NE AN Tabela: Podatki o mestih, krajih. Stran 40

45 TABELA: MESTA tabela mest, krajev IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA Sifra_mesta interna številka DA N 5 mesta. Ime_posl ime sixt poslovalnice DA AN 30 Tip_mesta Koda_catl tip mesta / centralna poslovalnica, franšiza koda za mesta z ugodnostmi DA AN 2 NE AN 3 Zap_št_od začetna zaporedna NE N 10 številka za izdajanje računov Zap_št_do končna zaporedna NE N 10 številka za izdajanje računov Provizija provizija v odstotkih NE N 5 Regija oznaka regije DA N 5 (logistika) Hercul_koda hercul koda za NE N 6 franšize Čas_delavniki_od odpiralni čas med NE N 4 delavniki Čas_delavniki_do zapiralni čas med NE N 4 delavniki Čas_sobota_od odpiralni čas med NE N 4 delavniki Čas_sobota_do zapiralni čas med NE N 4 delavniki Čas_nedelja_od odpiralni čas med NE N 4 delavniki Čas_nedelja_do zapiralni čas med NE N 4 delavniki Tip_vozil tipi vozil na voljo v NE N 5 franšizi Država uradna oznaka DA AN 10 države. Yn_dolgoročno dovoljen dolgoročni NE AN 1 najem Načrt na voljo zemljevid v NE AN 1 pdf formatu Yn_rez_gds ali je dovoljen tip rezervacije NE AN 1 Stran 41

46 Yn_rez_interno Yn_rez_internet Yn_rez_mobilno ali je dovoljen tip rezervacije ali je dovoljen tip rezervacije ali je dovoljen tip rezervacije NE AN 1 NE AN 1 NE AN 1 7. Tabela: Podatki o mestih z poslovalnicami. TABELA: MESTA2 podrobni podatki o mestu kjer je poslovalnica IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA Šifra_mesta interna številka DA N 5 mesta. Www_skupina sortirana skupina NE AN 1 mest za internet Www_ime ime sixt NE AN 30 poslovalnice na internetu Ulica ime ulice DA AN 30 Postna_st poštna številka DA AN 10 Kraj ime kraja DA AN 30 Tel: telefonska številka DA AN 10 Fax številka faxa NE AN 10 Gsm številka mobilnega DA AN 10 telefona Yn_agencija ali ima mesto DA AN 1 agencijo Adac_tel adac telefonska NE AN 10 številka v kraju Yn_24ur ali je poslovalnica NE AN 1 dosegljiva 24ur na telefon Oddaljenost_max maksimalna NE N 5 oddaljenost za dostavo vozila Št_komentar številka NE N 10 komentarja Št_agencije mednarodna DA N 10 številka agencije Tip_agencije Licenca podjetja NE AN 10 ali postaje Regija oznaka regije DA N 5 (logistika) Yn_računovodstvo dovoljeno zunanje računovodstvo NE AN 1 Stran 42

47 Št_podjetja številka podjetja / franšize za računovodstvo Stopnja_davka stopnja davka v državi Yn_zunaj_letališča poslovalnica zunaj letališča DA N 10 NE N 5 NE AN 1 8 Tabela:. Podatki o voznem parku podjetja. TABELA: VOZNI PARK voznik park ki je na voljo posameznim poslovalnicam IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA Šifra_posl številka sixt DA N 5 poslovalnice Šifra_vozila interna številka vozila DA N 10 Šifra_mesta interna številka mesta. DA N 5 Tip_vozila tip vozila /karavan DA N 5 /športni Status trenutni status vozila DA N 2 /na voljo/rezerviran... Tren_km trenutni prevoženi DA N 6 kilometri Tren_gorivo trenutna količina NE N 5 goriva Park_lokac lokacija in tip NE AN 10 parkirišča Sp_datum datum spremembe NE N 8 Reg_datum datum registracije NE N 8 Reg_čas čas registracije NE N 4 Zad_aktiv zadnja aktivnost DA AN 3 znotraj podjetja Poškodbe opis poškodb na NE AN 40 vozilu. Dod_gorivo dotočeno gorivo NE N 5 Sprem_cen spremembe cen na NE AN 12 ceniku Dod_gorivo_st dotočeno gorivo stranka / zaračunano stranki NE N 5 9. Tabela: Administrativni podatki o voznem parku TABELA: VOZILA_OPIS voznik park ki je na voljo posameznim poslovalnicam administrativni del IME POLJA OPIS POLJA OBVEZEN FORMAT Stran 43

48 DA/NE POLJA Šifra_vozila interna številka vozila DA N 10 Šifra_države interna številka DA N 5 države. Šifra_mesta interna številka mesta. DA N 5 Centrala interna številka DA N 5 centrale Status_lastnik status lastnika DA N 5 Status_uporabnik status uporabnika DA N 5 Int_st_mesto interna številka mesta DA N 5 Status trenutno stanje vozila DA N 2 Fstatus finančno stanje vozila NE N 2 Dobavitelj podjetje kjer se je NE AN 20 opravil nakup vozila Št_ogrodja številka šasije DA AN 20 St_nar_voz številka naročila DA AN 20 vozila St_računa_dobavitelj številka računa dobav. DA AN20 St_zavarovanja številka zavarovanja DA N10 Tip_vozila tip vozila DA N5 Tip_zavarovanja tip zavarovanja DA AN1 Tip_davka tip davka DA N5 Št_komentar številka komentarja v DA N10 tabeli komentarji Tabela: Podatki o voznem parku za posamezne poslovalnice. TABELA: VOZILA voznik park ki je na voljo posameznim poslovalnicam IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA Šifra_države interna številka DA N 5 države. Tip int_vozila interni tip vozila DA N5 Znamka_vozila besedni opis vozila DA AN 60 Tip vozila tip vozila DA AN 1 Tank volumen rezervoarja DA N 5 Poraba poraba vozila DA N 4 Skupina_vozila interna skupina vozila DA AN 4 Cat_vozila interna kategorija vozila DA AN Tabela: Podatki o kategorijah vozil TABELA: VOZILA_KOR tabela za kategoriziranje voznega parka IME POLJA OPIS POLJA OBVEZEN FORMAT Stran 44

49 DA/NE POLJA Šifra_grupe šifra grupe DA AN 4 Cat_vozila interna kateg. vozila DA AN 6 Tip vozila tip vozila DA AN 1 Kont_vozila kontrola vozila DA AN 2 Prior_vozila prioriteta vozila Da N 9 Razred velikostni razred DA AN 2 vozila Kategorija kategorija vozila DA AN 40 Model model vozila DA AN Tabela: Podatki o zgodovinah najemnih pogodb. TABELA: POGODBE tabela zgodovine najemnih pogodb IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA St_pogodbe številka najemne DA N10 pogodbe Zap_st_pogodbe številka verzije DA N 3 pogodbe Šifra_vozila interna številka DA N 10 vozila Reg_vozila registracija vozila DA An 15 Tip int_vozila interni tip vozila DA N5 Izdaja_mesto mesto izdaje vozila DA N5 Izdaja_ime_mesta mesto izdaje vozila DA AN 20 Izdaja_datum datum izdaje DA N8 Izdaja_ura ura izdaje DA N4 Izdaja_zaposlen številka zaposlenega DA N 10 Izdaja_km število km ob izdaji DA N 6 Izdaja_gorivo količina goriva ob DA N 1 izdaji 1/8 Vračilo_mesto mesto vračilo vozila DA N5 Vračilo_ime_mesta mesto vračilo vozila DA AN 20 Vračilo_datum datum vračila DA N8 Vračilo_ura ura vračila DA N4 Vračilo_zaposlen številka zaposlenega DA N 10 Vračilo_km število km ob vračilu DA N 6 Vračilo_gorivo količina goriva ob DA N 1 izdaji 1/8 Gorivo_manjka dotočena količina DA AN 5 goriva Gorivo_tip tip goriva DA N 1 Sixt_telefon telefonska št telefona DA N 10 v vozilu km_omejitev Potrebna kontrola DA N 1 Stran 45

50 vozila ob št km 13. Tabela: Podatki o doplačilih pri najemnih pogodbah. TABELA: POGODBA_DOPLACILA doplačila ob sklenitvi najemne pogodbe IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA St_pogodbe številka najemne DA N10 pogodbe Zap_st_pogodbe številka verzije DA N 3 pogodbe Tip_računa tip računa primarni / DA AN 1 sekundarni Sr_pogodba serijska št. pogodbe DA N 3 Tip_doplačila koda doplačila DA AN 2 St_doplačil število doplačil DA N5 Cena_doplačila cena doplačila DA N5 Davek ddv DA N5 Yn_davek ali je davek potreben DA N5 14. Tabela: Podatki o doplačilih pri rezervacijah. TABELA: REZERVACIJA_DOPLACILA doplačila ob kreiranju rezervacije IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA St_pogodbe številka najemne DA N10 pogodbe Zap_st_pogodbe številka verzije DA N 3 pogodbe Tip_računa tip računa primarni / DA AN 1 sekundarni Sr_pogodba serijska št. pogodbe DA N 3 Tip_doplačila koda doplačila DA AN 2 St_doplačil število doplačil DA N5 Cena_doplačila cena doplačila DA N5 Davek ddv DA N5 Yn_davek ali je davek potreben DA N5 15 Tabela: Podatki o plačilih pri najemnih pogodbah. TABELA: POGODBA_ZNESEK Podatki o celotnem plačilu najemne pogodbe IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA St_pogodbe Številka najemne DA N10 Stran 46

51 pogodbe Zap_st_pogodbe Številka verzije DA N 3 pogodbe Tip_računa Tip računa primarni / DA AN 1 sekundarni Sr_pogodba Serijska št. pogodbe DA N 3 Šifra_plačila Interna koda plačila DA AN 2 Znesek_plačila Celotni Znesek plačila DA N Tabela: Podatki o plačilih pri rezervacijah. TABELA: REZERVACIJA_ZNESEK Podatki o celotnem predplačilu rezervacije IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA St_pogodbe Številka najemne DA N10 pogodbe Zap_st_pogodbe Številka verzije DA N 3 pogodbe Tip_računa Tip računa primarni / DA AN 1 sekundarni Sr_pogodba Serijska št. pogodbe DA N 3 Šifra_plačila Interna koda plačila DA AN 2 Znesek_plačila Celotni Znesek plačila DA N Tabela: Podatki na pogodbi. TABELA: POGODBA Vsi podatki na pogodbi IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA st_pogodbe številka najemne DA N10 pogodbe zap_st_pogodbe številka verzije DA N 3 pogodbe izdaja_mesto mesto izdaje vozila DA N5 izdaja_ime_mesta mesto izdaje vozila DA AN 20 izdaja_datum datum izdaje DA N8 izdaja_ura ura izdaje DA N4 vračilo_mesto mesto vračilo vozila DA N5 vračilo_ime_mesta mesto vračilo vozila DA AN 20 vračilo_datum datum vračila DA N8 vračilo_ura ura vračila DA N4 st_rezervacija številka rezervacije NE N 10 vavčer_dni število dni vavčer NE N 5 Št_let Številka leta NE AN 8 Šifra_jezik Interna Šifra jezika NE N 2 Številka_cenika Interna številka NE AN 12 Stran 47

52 cenika Grupa_vozila Interna grupa vozil NE AN 4 St_tip_vozila Interni tip vozila NE N Tabela: Podatki na računu. TABELA: RAČUN vsi podatki na računu IME POLJA OPIS POLJA OBVEZEN DA/NE FORMAT POLJA St_pogodbe številka najemne DA N10 pogodbe Zap_st_pogodbe številka verzije DA N 3 pogodbe Tip_računa tip računa primarni / DA AN 1 sekundarni Šifra_plačila interna koda plačila DA AN 2 Šifra_kupec interna številka kupca DA N 10 Račun_kupec plačilni račun kupca DA N 10 Locen_račun interna koda tipa DA N 2 računa Redna_stranka koda redne stranke DA N 2 Kred_kartica številka kreditne NE AN 20 kartice Kred_datum datum prenehanja NE N 8 veljavnosti kreditne k. Izdaja_datum datum izdaje DA N8 Izdaja_ura ura izdaje DA N4 Vračilo_datum datum vračila DA N8 Vračilo_ura ura vračila DA N4 Znesek znesek plačila z DA N 13 popustom Davek znesek davka DA N 13 St_davek stopnja davka DA N 5 Stran 48

53 Priloga 2 9. Slika: Prikaz možnosti spreminjanja barve za najemno pogodbo ali rezervacijo. Stran 49

54 10. Slika: Prikaz spremenjene barvne kombinacije za trenutno prikazano vsebino. 11. Slika: Prikaz izbire samo rezervacij v oknu nastavitve. Stran 50

55 12. Slika: Prikaz samo rezervacije iz trenutno izbranih podatkov. 13. Slika: Prikaz izbire samo najemnih pogodb v oknu nastavitve. Stran 51

56 14. Slika: Prikaz najemnih pogodb iz trenutno izbranih podatkov. Stran 52

57 15. Slika: Prikaz možnosti, ki se pojavijo ob izbiri desnega miškinega gumba iz trenutno prekrivanih podatkov Slika: Prikaz vprašanja, ki se pojavi, če na obstoječi gantogram želimo dodati podatke. Ob pritrdilni izbiri, se kreira nov pogled gantograma z želenimi novimi podatki Ob nikalni izbiri, se podatki dodajo k že skupini podatkov ki so že prikazani na gantogramu. Stran 53