RAZVOJ GENERATORJA POSLOVNIH SPLETNIH APLIKACIJ

Transcription

1 UNIVERZA V MARIBORU FAKULTETA ZA ORGANIZACIJSKE VEDE Smer: Informatika v organizaciji in managementu RAZVOJ GENERATORJA POSLOVNIH SPLETNIH APLIKACIJ Mentor: izr. prof. dr. Robert Leskovar Kandidat: Boštjan Martinek Kranj, april 2010

2 ZAHVALA Zahvaljujem se mentorju dr. Robertu Leskovarju za mentorstvo in nasvete pri izdelavi diplomske naloge. Hvala podjetju Četrta pot d.o.o., ki je finančno podprla moj študij informatike. Zahvaljujem se tudi lektorju Miranu Štempiharju, ki je lektoriral diplomsko delo. Posebej bi se zahvalil družini za podporo in potrpežljivost v času študija.

3 POVZETEK Naloga obravnava razvoj generatorja poslovnih spletnih aplikacij. Temelji na trinivojski arhitekturi. Za potrebe manjšega podjetja s področja inženiringa programske opreme je bil razvit generator, ki temelji na odprtokodnih rešitvah Apache, MySql, GWT in Eclipse. Podan je kratek pregled obstoječih generatorjev. Ugotovili smo, da noben od njih v celoti ne zadošča zahtevam konkretnega podjetja. Razvit je bil prototip generatorja poslovnih aplikacij in preizkušen na več primerih. Delovanje generatorja je zanesljivo, uporaba je enostavna in prihrani programerjem veliko časa. Glavna slabost je premajhen nabor vizualnih elementov. KLJUČNE BESEDE - Generator poslovnih spletnih aplikacij - RAD (Rapid Application Development) - GWT (Google Web Toolkit) ABSTRACT This work deals with development of business web application generator. It is based on a three-tier architecture. The generator has been developed for the needs of a small company and it is based on open-source solutions Apache, MySql, GWT and Eclipse. A short overview of existent generators is given. We found out, that none of them satisfy the requirements of an actual business. A prototype generator of business applications was developed and it was tested in several cases. The generator is reliable, easy to use and it saves developers time. The main disadvantage is a small set of visual elements. KEYWORDS - Web based business application generator - RAD (Rapid Application Development) - GWT (Google Web Toolkit)

4 KAZALO 1 UVOD METODOLOGIJA DELA Opredelitev problema Opredelitev ciljev Predvideni rezultati Uporabljene metode in orodja ter njihove omejitve Pregled obstoječih rešitev Oracle Application Express Sybase PowerBuilder CodeGear Razvoj prototipa Predstavitev idejne rešitve Odjemalec Podatkovni strežnik Struktura podatkovnega modela Podatkovni tipi, ki jih podpira orodje...11 Prezentacija Predstavitev glavnih tabel in relacij Uporabniški vmesnik Grafični vmesnik Programska logika Predstavitev okolja in orodja za gradnjo aplikacij Testiranje Metoda testiranja Rezultati KAKOVOST IN UPORABNOST Kakovost Uporabnost Ocena uspešnosti Ocena učinkovitosti Ocena zadovoljstva uporabnikov Zaključek...35 LITERATURA IN VIRI...36 KAZALO SLIK...38 KAZALO TABEL...39 KRATICE IN AKRONIMI...40 PRILOGE...42

5

6 1 UVOD V diplomski nalogi se bomo osredotočili na področje razvoja programskih rešitev. Opisali bomo proces snovanja in izdelave prototipnega generatorja za hiter razvoj poslovnih aplikacij (RAD - Rapid Application Development). Aplikacija bo trinivojska. Načrtujemo izdelavo uporabniškega vmesnika za spletno uporabo. Predstavili bomo zasnovo podatkovnega modela, izbiro programskih orodij in tehnologij, ki bodo vključene v sam prototip. Pri izboru tehnologij in orodij se bomo opirali predvsem na cenovno ugodnejše odprtokodne programske rešitve. RAD je ena od metod za razvoj programskih aplikacij. Ta metoda je predvsem usmerjena v hiter, enostaven in kvaliteten razvoj. Primerna je za snovanje prototipnih in tudi produkcijskih aplikacij. Kot navaja Whitten (2004), je metoda združitev več različnih strukturiranih tehnik (zlasti podatkovno usmerjenih) s tehnikami za pospešitev razvoja programskih rešitev. Ker ni potrebno predhodno podrobno načrtovanje posameznih modulov, je gradnja in dograjevanje aplikacij precej hitrejše kakor pri ostalih metodah. Dobra lastnost je pospešitev razvojnega cikla. Seveda pa ima tudi ta metoda svoje slabosti. Zaradi poenostavljanja in opuščanja posameznih korakov pri gradnji aplikacije, lahko prihaja do nekonsistentnosti. Zaradi tega je potrebna visoka stopnja sodelovanja med vsemi člani razvojne ekipe. Pogosto RAD orodja omogočajo nek končen nabor funkcionalnosti, ki pa jih je težko dograjevati in prilagajati željam uporabnikov. Na trgu je širok spekter produktov, ki na tak ali drugačen način omogočajo hiter razvoj aplikacij. Izbira je zelo pestra (CodeIgniter, OpenROAD, APEX, RadRails, Servoy, HyperNext, Sybase PowerBuilder in CodeGear), vendar le malo produktov omogoča celovito uporabniško okolje za razvoj in uporabo. Sem sodi tudi večuporabniški vmesnik in integrirano določanje privilegijev in pravic razvijalcem in uporabnikom aplikacije. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 1

7 2 METODOLOGIJA DELA 2.1 OPREDELITEV PROBLEMA Obstoječa orodja za hiter razvoj aplikacij so pogosto zelo specializirana in zahtevajo točno določena znanja in specifično platformo za svoje delovanje. Cene takih orodij so zelo visoke. Njihova okornost končnim uporabnikom ne omogoča naknadno dodelavo obstoječih funkcionalnosti. 2.2 OPREDELITEV CILJEV Cilj naloge je razvoj prototipnega orodja, ki bo imel naslednje lastnosti: enostaven in hiter razvoj poslovnih aplikacij, spletni uporabniški vmesnik (neodvisnost od programskih platform), trinivojska arhitektura (podatkovni strežnik, spletni strežnik, uporabniški vmesnik), odprtost in fleksibilnost, naknadna dodelava končnih uporabnikov, uporaba odprtokodnih orodij (zniževanje cen licenčnin uporabljenim strežnikom in končnemu produktu). 2.3 PREDVIDENI REZULTATI Rezultat naloge bo delujoč prototip, ki bo zadostil potrebam manjšega podjetja s področja razvoja informacijskih sistemov. Izdelana bo testna aplikacija, ki bo vsebovala več vnosnih mask, šifrantov in prometnih tabel. 2.4 UPORABLJENE METODE IN ORODJA TER NJIHOVE OMEJITVE Metodologija: študij literature in obstoječih konceptov in orodij prototipni razvoj programske rešitve testiranje izdelane rešitve Orodja : spletni odjemalec: Java prevajalnik GWT (Java to JavaScript compiler) spletni strežnik: Apache + php modul podatkovni strežnik: MySql integrirano razvojno okolje: Eclipse administracija podatkovnega strežnika: phpmyadmin Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 2

8 3 PREGLED OBSTOJEČIH REŠITEV Želja po hitrem in učinkovitem razvoju programskih rešitev verjetno obstaja že od samega začetka razvoja računalnikov. Vendar so bile teoretične podlage podane šele v osemdesetih in začetku devetdesetih let. Temeljile so na različnih pristopih in modelih, skupno pa jim je zagotavljanje dobrega okvirja za razvoj programov, izboljševanje kakovosti programske kode in skrajševanje razvojnega cikla produktom. Od prvih začetkov pa vse do danes se je pojavilo precej rešitev, ki temeljijo na RAD paradigmi. Paleta je zelo široka in raznovrstna. Na tem mestu pa bi bilo smiselno predstaviti le nekaj bolj znanih orodij. 3.1 ORACLE APPLICATION EXPRESS Prvoten naziv je bil HTML DB in se je kasneje preimenoval v APEX. Je orodje za hitro razvijanje aplikacij podjetja Oracle. Temelj za delovanje je Oraclova relacijska baza podatkov. Uporabniški vmesnik pa temelji na PL/SQL-u in je implementiran za spletnega odjemalca. Ključni moduli, ki jih aplikacija podpira, so: poročila obrazci grafikoni preglednice tiskanje v PDF formatu podpora spletnim servisom Proizvajalec promovira enostavno uporabo, varnost in zanesljivost. Za izdelavo preprostih aplikacij ni potrebno poglobljeno znanje v programiranju. Večino poročil in obrazcev je mogoče oblikovati kar preko priročnih čarovnikov, ki poenostavijo delo. Slabost omenjenega orodja je popolna navezanost na Oraclovo podatkovno bazo. Uporabniki omenjajo slabo prilagodljivost uporabniškega vmesnika. Implementacija specialnih funkcionalnosti, ki jih standardni vmesnik ne podpira, je zelo zamudna. Moteča je tudi nepreglednost in slaba berljivost programske kode. To močno otežuje popravljanje, razhroščevanje in kasnejše dograjevanje. Samo razvojno okolje je sicer brezplačno (različica XE), obstoječe Oraclove licence pa precej drage za končne uporabnike. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 3

9 3.2 SYBASE POWERBUILDER Orodje so prvotno razvili v podjetju Powersoft, kasneje pa ga je kupilo podjetje Sybase, ki ga vseskozi tudi razvija in dograjuje. Orodje je v prvi vrsti namenjeno razvoju poslovnih aplikacij. Zaradi tega je večina komponent, ki so na voljo, prilagojenih za delo s podatkovnimi zbirkami in interakcijo z uporabnikom. Orodje je zasnovano kot uporabniški vmesnik nad podatkovnimi zbirkami, v katere je mogoče podatke dodajati, urejati, brisati in pregledovati. Podpira»Stored Procedures«in osnovno SQL sintakso, preko katere aplikacija dostopa do podatkov. Podpira izvoren dostop do več relacijskih baz. Dostop do podatkov pa je mogoč tudi preko ODBC-ja in OLE-DB-ja. Specialna orodja omogočajo razvijalcem prilagajanje in dograjevanje uporabniškega vmesnika. Ta omogoča končnemu uporabniku preprost dostop do vsebine baz podatkov. K osnovnemu modulu je dodan še skriptni jezik, ki je popolnoma objektno orientiran. Omogoča učinkovit nadzor nad dogodki in vizualnimi objekti. PowerBuilder podpira tudi Active-X in OCX komponente kakor tudi OLE Automation. Proizvajalec namerava v naslednji različici podpreti tudi.net platformo, kar ga bo približalo modernim programskim orodjem. Kritiki omenjajo, da produkt zaradi okorelosti obstoječe platforme čaka težaven prehod na.net platformo. Negotova prihodnost in slaba razširjenost le stežka prepričajo podjetja, da se odločijo za dolgoročno uporabo opisanega produkta. 3.3 CODEGEAR Orodje je razvilo podjetje Borland, kasneje pa ga je prodalo podjetju Embarcadero Technologies. To podjetje je omenjen produkt preimenoval v»rad Studio«. Orodje je primerno za gradnjo Windows,.NET in spletnih aplikacij. Temelj so programski jeziki Delphi, C++ Builder in Delphi Prism. Prizvajalec promovira do 5-kratno pospešitev razvojnega cikla Windows aplikacij. Orodje že v osnovi podpira številne programske kontrole in dostope do različnih relacijskih baz, kot so : Microsoft SQL Server, InterBase, DB2, Oracle, Sybase, MySQL in Firebird. Delphi Prism pa naj bi podpiralo gradnjo.net aplikacij. Skeptike skrbi predvsem negotovost glede prihodnosti produkta zaradi menjave produktnih imen in konceptov programiranja. Sodobna orodja skušajo biti neodvisna od operacijskih sistemov in ostalih platform, kar pa za pravkar opisano orodje ne velja. Orodje je popolnoma vezano na operacijski sistem Windows. Vse naštete rešitve in tudi ostale, ki niso podrobno opisane, ne izpolnjujejo ene ali več osnovnih zahtev, ki so bile predstavljene v uvodu (enostaven in hiter razvoj, spletni uporabniški vmesnik, trinivojska arhitektura, odprtost in fleksibilnost, uporaba odprtokodnih tehnologij). Zato smo se lotili izdelave lastnega prototipa, ki bo zadovoljil naše cilje in pričakovanja. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 4

10 4 RAZVOJ PROTOTIPA 4.1. PREDSTAVITEV IDEJNE REŠITVE Kot je bilo že uvodoma povedano, idejna rešitev temelji na osnovnih predpostavkah, kot so: uporaba najsodobnejših spletnih tehnologij, uporaba odprtokodnih razvojnih programskih jezikov in podatkovnih relacijskih baz. Hkrati pa je potrebno zagotoviti neodvisnost od operacijskega sistema, na katerem bo orodje teklo. Orodje za hiter razvoj poslovnih aplikacij (v nadaljevanju orodje), je zaključena programska enota. Je temelj, ki zagotavlja celovito okolje, v katerem je mogoče zagotoviti celoten življenjski cikel neke poslovne aplikacije (v nadaljevanju aplikacija). S tem mislimo na faze, kot so: analiza načrtovanje kodiranje testiranje implementacija vzdrževanje (dograjevanje, popravljanje... ) Ker je orodje prototipno, smo se osredotočili predvsem na dva bistvena dela: na eni strani na razvoj in na drugi strani implementacijo. Ostali deli pa so na tak ali drugačen način povezani z enim ali drugim. Najprej je bilo izdelano orodje za razvoj. Ta omogoča opis grafičnih, logičnih in podatkovnih lastnosti. Orodje za razvoj grafičnega vmesnika aplikacije temelji na osnovnih grafičnih objektih, ki jih načrtovalec pozicionira in tako gradi vizualni vmesnik aplikacije. Skriptni jezik pa skrbi za interakcijo med vizualnimi objekti in podatkovnim strežnikom (več v nadaljevanju). Ker želimo pospešiti cikel razvoja, smo morali določene stvari poenostaviti, določene pa predpripraviti za kasnejši hiter priklic in implementacijo. Ker je okolje namenjeno gradnji poslovnih aplikacij, smo s pridom upoštevali zakonitosti, ki se pojavljajo pri uporabi le-teh. Da bi pripomogli k poenostavitvi grafičnega vmesnika, orodje omogoča nekaj osnovnih objektov, ki so pogosto uporabljeni v poslovnih aplikacijah (npr. vnosna polja, izborna polja, gumbi, tabele itd.). Kar se tiče podatkov, pa smo se predvsem osredotočili na osnovne pojme, kot so: dodajanje, spreminjanje, brisanje in pregledovanje podatkov. Za osnovo je uporabljena trinivojska arhitektura 1 strežnik in podatkovni strežnik. (tabela 1): odjemalec, spletni Naloga odjemalca je grafični prikaz vseh vrst podatkov in interakcija med aplikacijo in uporabnikom. Ker smo zahtevali, da je uporabniški vmesnik prilagojen za spletno uporabo, bo program tekel znotraj spletnega brskalnika. Z izbiro ustreznega orodja za razvoj pa bomo zagotovili neodvisnost odjemalca od večine spletnih brskalnikov in operacijskega sistema. 1 Trinivojska arhitektura (Three-tier architecture) povezava med odjemalcem aplikacijskim strežnikom in podatkovnim strežnikom. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 5

11 Večina aplikacijske in poslovne logike se bo izvajala na spletnem strežniku. Ta skrbi tudi za manipulacijo zahtev tako z odjemalcem kot s podatkovnim strežnikom. Za shranjevanje podatkov smo uporabili relacijsko podatkovno bazo. Podatkovni strežnik skrbi za hrambo, zajem in spreminjanje podatkov, vezanih na samo delovanje okolja in hkrati tudi na delovanje poslovne aplikacije. Na podatkovnem strežniku se ne bo uporabljalo funkcij in procedur. Vse to pa omogoča razvojnemu okolju neodvisnost od različnih relacijskih baz. Večina relacijskih baz je med seboj kompatibilna na nivoju standarda SQL-92, ki je bil izbran za temelj. Z minimalnimi spremembami je mogoče zamenjati tip podatkovne baze in pri tem ohraniti funkcionalnosti orodja. Sloj 1. Odjemalec prezentacijski sloj, grafični vmesnik (GUI 2 ) (ang. user interface) 2. Spletni strežnik (Apache + PHP modul) (ang. web server) 3. Podatkovni strežnik podatkovni sloj (ang. data server) Naloge izvaja uporabniški vmesnik, zahteva podatke. koordinira komuniciranje med aplikacijami, izvaja obdelave, izmenjevanje podatkov med obema ostalima slojema, procesiranje komand. odgovarja na zahteve logičnega sloja, shranjuje podatke, izvaja shranjene procedure, zaklepa zapise, skrbi za integriteto in varnost podatkov. Tabela 1: Trinivojska arhitektura 2 GUI (graphical user interface) grafični vmesnik. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 6

12 4.1.1 Odjemalec Ker je ena od zahtev tudi delovanje aplikacije preko spleta, mora odjemalec (vmesni člen med aplikacijo in uporabnikom) delovati na spletnem brskalniku. Da bo okolje dostopno čim večjemu številu uporabnikov, mora aplikacija podpirati večino uveljavljenih spletnih brskalnikov (IE, FF, Safari, Opera in Chrome). Ker imajo različni brskalniki različne programske zmogljivosti, se pogosto pojavljajo težave pri obdelavi in prikazovanju podatkov. Zaradi tega je bilo potrebno izbrati razvojno okolje, ki upošteva omejitve brskalnika in se jim tudi prilagodi. To pomeni, da mora ena programska koda delovati na vseh brskalnikih enako. Vse naštete omejitve upošteva programsko orodje z imenom GWT 3 in je bilo zaradi tega razloga tudi izbrano za razvojno okolje odjemalca. GWT je orodje, ki je namenjeno programiranju spletnih aplikacij in temelji na AJAX 4 tehnologiji. Omogoča prevajanje programske kode, napisane v jeziku Java, v skriptni jezik JS 5 (tako imenovan Java to JavaScript prevajalnik). Programska koda se piše v Javi (popolnoma objektno orientirano), potem pa se v fazi prevajanja generira neka mešanica HTML in JS kode. Vse skupaj teče na HTTP strežniku kot klasična spletna stran. Zajemanje in shranjevanje podatkov (komunikacija) poteka preko HTTP protokola. Podatki so zapisani v JSON- 6 ali XML-formatu. To omogoča hitro in standardizirano izmenjevanje podatkov. Za omenjen produkt smo se odločili, ker: podpira večino uveljavljenih spletnih brskalnikov, je eno najbolj inovativnih orodij za izdelavo spletnih aplikacij, ima zelo dobro dokumentacijo in kvalitetne primere programske kode, je sam produkt odprtokodni projekt, licenciran z Appache licenco (ena od zahtev), obstaja zelo dobro integrirano razvojno okolje (za razvoj se uporablja okolje Eclipse 8 ), omogoča objektno orientirano programiranje. 3 GWT (Google Web Toolkit) odprtokodni Java v JavaScript prevajalnik podjetja Google 4 Inc. AJAX (Asynchronous JavaScript and XML) skupina več med seboj povezanih programerskih tehnik za razvoj spletnih aplikacij. 5 JS (JavaScript) skriptni programski jezik, namenjen programiranju dinamičnih spletnih vsebin. 6 JSON (JavaScript Object Notation) standardiziran računalniški format za izmenjavo strukturiranih podatkov preko spleta. 7 Apache 2.0 (Apache Software License 2.0) free-software licenca, ki jo zastopa združenje Apache Software Foundation (ASF). 8 Eclipse je večjezično razvojno programsko okolje; GWT s svojimi vtiči omogoča integracijo z Eclipse okoljem in poenostavlja samo programiranje. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 7

13 V fazi izbire ustreznega orodja so bila v igri tudi orodja, kot so SilverLight 9 in Adobe Flash. Vendar oba delujeta kot vtiča v spletni brskalnik, kar pa že pogojuje njihovo nameščanje in uporabo ter odvisnost od nastavitev samega brskalnika. Neposredni tekmec GWT-ja je produkt Volta 10. Ta pa se je izkazal za neuporabnega, ker je projekt še v razvojni fazi in je omejen predvsem na brskalnik IE. Vse naštete tehnologije so povezane tudi s plačevanjem razvojnih licenc, kar pa ne zagotavlja skladnosti z zastavljenimi okvirji Spletni strežnik Za spletni strežnik je bil izbran HTTP strežnik Apache, ki ima dodan PHP modul. Sama izbira je bila sorazmerno preprosta. Strežnik je del odprtokodnega projekta in podpira številne dodatne programske module, ki omogočajo razširljivost in povezljivost z ostalimi produkti. Podpira PHP skriptni jezik, ki bo služil kot programski jezik razvojnega okolja. Za ta namen smo izkoristili lastnost dinamičnega prevajanja programske kode v realnem času. Ta nam bo pomagala izvajati posamezne programske sklope poslovne aplikacije. V prid izbranemu strežniku govorijo tudi atributi, kot so : odprtokodnost, razširjenost (eden najbolj razširjenih spletnih strežnikov), brezplačnost ( Apache License 2.0 ena od zahtev), razširljivost in nadgradljivost (številni moduli, ki omogočajo povezljivost in nadgradljivost), enostavna uporaba in vzdrževanje, stabilnost delovanja. 9 Silverlight (Microsoft Silverlight) vtič za spletne brskalnike, ki deluje samo na IE in Safari brskalnikih. 10 Volta razvojno okolje, namenjeno razvijanju multi-tier spletnih aplikacij, razvija ga podjetje Microsoft Corporation. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 8

14 4.1.3 Podatkovni strežnik Že na začetku smo se odločili, da za zastavljeno nalogo potrebujemo relacijsko bazo. Izbirali smo med več možnostmi in se na podlagi že zapisanih kriterijev odločili za MySql relacijsko bazo. Zaradi licenčnin so v prvi fazi izbora izpadli Oracle, DB2 in MS SQL. Med ostalimi priljubljenimi relacijskimi bazami pa sta ostala samo še MySql in PostgreSQL 11. Zaradi boljšega poznavanja je bil na koncu izbran MySql podatkovni strežnik. Razlogi za izbor so: v obsegu uporabe, ki je planirana, ni potrebno plačati licenčnine, velika popularnost, teče na številnih operacijskih sistemih, enostavna povezljivost z izbranim spletnim strežnikom, odlična dokumentacija in številni primeri. 11 PostgreSQL odprtokodna relacijska podatkovna baza razvojne ekipe PostgreSQL Global Development Group. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 9

15 4.2 STRUKTURA PODATKOVNEGA MODELA Ena izmed najpomembnejši stvari, ki jih je bilo potrebno zasnovati, preden smo se lotili programiranja, je bil ravno podatkovni model. Podatkovni model je eden izmed temeljev celotnega okolja. Je na nek način vezivo, ki zagotavlja konsistentnost in integriteto podatkov. Določa posamezne povezave med podatki in njihovo urejenost. Dobro zasnovan podatkovni model mora zagotavljati enoznačnost podatkov, razširljivost in preprečevati nepotrebno podvajanje zapisov. Najprej so bile kreirane temeljne tabele. V kasnejših fazah so se dodajale pomožne tabele. Izkazalo se je, da so začetna previdnost, temeljit razmislek in predvidljivost pri načrtovanju zelo dober temelj za kasnejše delo. Če se je v kasnejših fazah pojavila potreba po širitvi funkcionalnosti, ki je nismo predvideli, nam je obstoječ podatkovni model omogočil realizacijo sprememb brez bistvenih modifikacij programske kode na strani odjemalca in spletnega strežnika. Pri načrtovanju smo upoštevali tudi osnovne zahteve samega projekta. Podatkovni model je prilagojen standardu SQL-92 in upošteva osnovno kompatibilnost med relacijskimi bazami. Okolje je bilo zasnovano tako, da podpira sobivanje več aplikacij hkrati (»multi app«). To pomeni, da na enem podatkovnem strežniku domujejo podatki več aplikacij hkrati. To lahko zagotovimo samo tako, da vsak zapis (vrstica v tabeli) poleg ostalih podatkov vsebuje tudi podatek o aplikaciji, ki je lastnica tega podatka. Opisana funkcionalnost velja samo za podatke, vezane na samo delovanje in lastnosti aplikacije. Podatki, ki so vezani na vsebino aplikacije, pa so shranjeni v ločenih tabelah. Vsaka aplikacija za svoje delovanje kreira lastne tabele (šifrante, prometne tabele) in skrbi za dostopnost in integriteto podatkov. Druga zelo pomembna funkcionalnost, ki jo podpira okolje, je večuporabniški vmesnik (»multi user«). Uporabnik, ki je vpisan v sistem, se lahko prijavi v več različnih aplikacij okolja z različnimi pravicami. Le-te pa določa administrator okolja. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 10

16 4.2.1 Podatkovni tipi, ki jih podpira orodje Zaradi poenostavitve so bili izbrani podatkovni tipi, ki se največkrat pojavljajo v poslovnih aplikacijah (tabela 2). Za potrebe okolja imajo vsi podatkovni tipi unikatno oznako (glej polje»oznaka tipa«). Večina tipov je nek skupni imenovalec tipov, ki jih podpira večina podatkovnih baz (glej polje»skupina tipov«) in razvojnih okolij. Nekateri pa so izpeljanka osnovnega nabora in se jih aplikativno prilagaja uporabi. Skupina tipov Oznak a tipa DB oznaka Opis Privzeta vrednost Prezentacija znak (string) C VARCHAR() krajši teksti null ' ' T TEXT daljši teksti null ' ' celo število (number) N INT celoštevilčni null '0009' datum, čas (date, date-time) logična vrednost (boolean) binarna vrednost (BLOB) F FLOAT decimalni null '0009,99' D DATE datumski null d DATETIME datum in čas null 'DD.MM.YY YY' 'HH:MI:SS DD.MM.YY YY' t TIME čas null 'HH:MI:SS' b VARCHAR(1) binarna ('n','0','1') null '0' ali '1' B BLOB binarni podatki null STR_HEX() Tabela 2: Tabela podatkovnih tipov, ki jih podpira okolje Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 11

17 4.2.2 Predstavitev glavnih tabel in relacij V nadaljevanju bo predstavljen podatkovni model razvojnega okolja (slika 1). Vse tabele, ki so povezane s samim delovanjem okolja, se pričnejo na iform_. Vsaka tabela ima polje id. Polje se avtomatično povečuje in predstavlja unikatni ključ do posameznega zapisa. S tem se poenostavi dostop do posameznih zapisov za urejanje in spreminjanje, hkrati pa je priročen mehanizem za uporabo tujih ključev. Slika 1: Podatkovni model Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 12

18 iform_apps Iz podatkovnega modela je razvidno, da je ena glavnih tabel iform_apps. To je šifrant aplikacij, ki jih vsebuje okolje. Tabela je povezana skoraj z vsemi tabelami okolja. Vsaka od tabel vsebuje polje app_id, ki je preko relacije (tuji ključ) povezano s poljem id v tabeli iform_apps. S stališča formalizacije podatkovnega modela bi bilo smiselno polje app_id v nekaterih tabelah izpustiti. Vendar se kljub vsemu polje namenoma pojavlja v vseh tabelah, predvsem z namenom eksplicitne ločitve podatkov posameznih aplikacij. Na ta način je mogoče brez vzpostavitve dodatnih relacij v vsakem trenutku ločiti podatke različnih aplikacij. To dostikrat pride prav, če se je potrebno osredotočiti na posamezni zapis v tabeli. iform_users Zelo pomembna je tabela uporabnikov iform_users (šifrant uporabnikov in njihovih gesel), ki je preko povezovalne tabele iform_user_apps povezana s tabelo iform_apps. Omenjena relacija omogoča, da ima uporabnik pravice za dostop do različnih aplikacij okolja. Ko se uporabnik želi prijaviti v aplikacijo, navede uporabniško ime in geslo. Po potrditvi mora izbrati tudi aplikacijo, v katero se želi prijaviti. iform_app_menu Eden od osnovnih grafičnih elementov je gotovo menu. Menu je hierarhično organiziran pregled obstoječih opcij aplikacije. Tabela, v kateri so shranjeni podatki o strukturi menijskih opcij, je iform_app_menu. Tabela vsebuje več polj, ki so preko tujih ključev povezani z ostalimi tabelami. Prvo polje je app_id in je povezano s tabelo iform_apps. Drugo polje je menu_parent_id, povezano s poljem id v isti tabeli. Ta tvori hierarhično strukturo (povezave med nadrejenimi in podrejenimi nivoji). Zadnje polje je menu_form_id, ki je povezan s tabelo iform_forms. iform_forms Tako kot menu je tudi obrazec (form) eden od osnovnih grafičnih elementov orodja. Tabeli iform_forms in iform_form_objs tvorita osnovo za vizualno prezentacijo vnosnih obrazcev in pregledov. Tabela iform_forms služi kot osnovni šifrant in referenca podrejenih tabel. Da bi zagotovili vsaki aplikaciji svoj nabor obrazcev je dodano polje app_id, ki je povezano kot referenca s tabelo iform_apps. Tabela iform_form_objs hrani podatke o objektih, ki se dinamično generirajo ob prikazu. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 13

19 iform_fields Edini stik uporabnika s samo aplikacijo poteka prek grafičnega vmesnika. Tega sestavljajo meniji in obrazci kot nek okvir, na katerem se dinamično generirajo grafični objekti. Če se osredotočimo na področje poslovnih aplikacij, potem bi lahko s poenostavitvijo ta objekt vseboval vse grafične lastnosti in hkrati lastnosti enega vnosnega polja (tip podatka, vnosna maska, opis polja, maksimalno število znakov, morebitne povezave s tabelami in šifranti itd.). Vse te lastnosti se shranjujejo v tabeli iform_fields. Na nivoju posamezne aplikacije (tuji ključ na tabelo iform_apps) je možno generirati poljubno število objektov, ki jih po potrebi dodajamo na posamezne obrazce. En objekt s svojimi specifičnimi lastnostmi se lahko dinamično generira na več med seboj neodvisnih obrazcih (več v povezavi s tabelama iform_form_objs in iform_objs v nadaljevanju). Omenjena funkcionalnost nam pomaga poenostaviti opisovanje objektov, ki se pogosto ponavljajo v aplikaciji in jih razvijalec želi vzdrževati na enem mestu. iform_class Vsak objekt ima neko grafično preddefinirano obliko in tudi lastnosti. Zaradi poenostavitve je bilo izbrano le nekaj osnovnih preddefiniranih atomarnih vizualnih objektov. Imenujemo jih razredi (»classes«). V našem primeru so razredi abstraktna definicija grafične prezentacije objekta. Po definiciji vsebujejo lastnosti in metode. Tabela, ki hrani in združuje vse pomožne tabele, je iform_class. Tabela nima povezave s tabelo iform_apps, tako kot večina ostalih tabel. Polni se hkrati z dodajanjem novih razredov in je vezana na temeljne funkcionalnosti samega orodja. To pomeni, da se vsebina ne spreminja glede na gradnjo posamezne aplikacije, ampak je preddefinirana tako kot izvorna koda orodja. Tabela je povezana s tabelo iform_class_pr_me, ta pa je vmesni člen do tabel iform_class_metods in iform_class_props. V tabeli iform_class_metods so shranjeni nazivi vseh dogodkov (»events«), ki jih določen razred podpira (npr. OnClick, OnChange, OnDelete itd.). Tabela iform_class_props vsebuje nazive vseh lastnosti in njihove podatkovne tipe, ki jih vsebuje razred. iform_form_objs Tabela združuje vse objekte, ki se nahajajo na enem obrazcu. Povezana je s tablo iform_apps (to polje bi lahko tudi izpustili, ampak zaradi že omenjenih razlogov vzpostavitve integritete na nivoju zapisa je polje del tabele) na eni strani in na drugi z naborom vseh objektov aplikacije, ki je shranjen v tabeli iform_objs. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 14

20 iform_objs V tabeli se nahaja seznam vseh objektov, ki so vezani na eno aplikacijo (povezava s tabelo iform_apps). Objekti so že konkretizirana oblika abstraktne definicije razreda (povezava s tabelama iform_class in iform_fields). Prva tabela določi razred, ki mu pripada objekt, druga tabela pa zagotovi podatke, namenjene povezavam s tabelami in vnosnimi omejitvami. iform_types Tabela vsebuje definicije vseh podatkovnih tipov, ki jih podpira okolje (tabela 2). Ker je vsebina vezana na temeljne funkcionalnosti orodja, se spreminja samo z dodajanjem podpore novim podatkovnim tipom okolja. iform_tables Seznam vseh tabel, ki pripadajo aplikaciji, se nahaja v tabeli iform_tables. To so tabele, ki niso vezane na samo delovanje okolja, ampak so bile dodane za potrebe delovanja posamezne aplikacije (pomožni šifranti, povezovalne tabele, prometne tabele itd.). Omenjeni šifrant tabel je povezan tudi s tabelo iform_table_fields (povezovalna tabela s tabelo iform_fields), ki določa polja in so del vsake posamezne tabele posebej. Omenjeni mehanizem omogoča okolju fizično generiranje tabel na podatkovnem strežniku. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 15

21 4.3 UPORABNIŠKI VMESNIK Vse poslovne aplikacije vsebujejo neka skupna pravila, koncepte in zakonitosti. Te lastnosti smo razdelili v dve podskupini: lastnosti grafičnega vmesnika, lastnosti programske logike. Ločitev in osredotočenje na vsako skupino posebej je bilo potrebno že v fazi načrtovanja in obikovanja. V fazi programiranja pa je bilo potrebno usklajevati in združevati posamezne lastnosti. Grafični vmesnik skrbi za interakcijo z uporabnikom. V njem so predvsem integrirane zakonitosti grafičnega vmesnika. Poleg tega del programske logike nadzoruje tok podatkov in interakcijo med objekti. Spletni strežnik skrbi za obvladovanje programske in poslovne logike. Podatkovni strežnik (v našem primeru MySql) omogoča manipulacijo s podatki, ki so potrebni za osnovno delovanje aplikacije, kakor tudi manipulacijo s podatki, namenjenimi poslovnemu delu Grafični vmesnik Programiranje aplikacije je sestavljanje osnovnih gradnikov v kompleksnejše oblike (procedure, funkcije, objekte) in nato združevanje le-teh v neke zaključene enote - module. Več modulov sestavlja neko zaključeno celoto, ki jo imenujemo aplikacija (računalniški program). Da bi se uspešno soočili z zastavljeno nalogo, smo se odločili, da poiščemo neke osnovne grafične gradnike, ki bodo omogočali sestavljanje vnosnih mask in interakcijo med njimi. Slika 2: Osnovni grafični objekti in njihova grafična postavitev Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 16

22 Ker v tem poglavju govorimo o grafičnem vmesniku, bodo pojmi, kot so aplikacija, obrazci (forme) in objekti, predstavljeni predvsem z vidika vizualne predstavitve, medsebojne odvisnosti in hierarhične povezanosti (Slika 2). Osnovni vizualno-grafični gradnik smo poimenovali»osnovni objekt«. Ta je lahko prikazan kot gumb 12, tekstovno vnosno polje 13, spustni seznam 14, seznam vrednosti 15, datumsko vnosno polje s koledarčkom 16 in preglednica 17. Poleg osnovnih objektov so dodani tudi nadrejeni vizualno-grafični objekti. Prvi objekt, ki služi kot osnova, smo poimenovali obrazec (form). Obrazec je matični objekt (temelj) za vse zgoraj naštete osnovne objekte. Vsak obrazec je zaključena celota zase. Uporabniku omogoča, da preko njega vnaša, pregleduje in spreminja podatke. Pogosto obrazec v poslovni aplikaciji podpira nek zaključen del procesa. Za logično razvrstitev več obrazcev in njihov klic skrbi nadrejeni objekt z imenom menu 18. Objekt je hierarhično organiziran, vsaka veja pa je povezana s posameznim obrazcem. Uporabnik preko menuja izbira prikaz posameznega obrazca, ta pa preko podrejenih objektov omogoča izvajanje predvidenih funkcionalnosti aplikacije. Krovni objekt, ki združuje in povezuje vse naštete objekte, pa je kar sama aplikacija (Slika 3). Njena naloga je sodelovanje pri avtentikaciji, komunikaciji, koordinaciji, integraciji in prikazovanju podrejenih objektov kot celota. Vsaka aplikacija vsebuje natanko en objekt menu. Ta pa preko svoje hierarhične strukture omogoča klicanje podrejenih obrazcev. 12 Gumb (Button) osnovni grafični objekt, ki omogoča potrjevanje akcij (Slika 1, zaznamek številka 4). 13 Tekstovno vnosno polje (TextBox) osnovni grafični objekt, ki omogoča vnos alfanumeričnih znakov (Slika 1, zaznamek številka 1). 14 Spustni seznam (ComoBobox) osnovni grafični objekt, ki omogoča izbor vrednosti iz spustnega nabora vrednosti (Slika 1, zaznamek številka 3). 15 Seznam vrednosti (ListBox) osnovni grafični objekt, ki omogoča izbor vrednosti iz nabora vrednosti. 16 Datumsko vnosno polje s koledarčkom osnovni grafični objekt, ki omogoča izbor ali vnos datuma (Slika 1, zaznamek številka 2). 17 Preglednica (Table) osnovni grafični objekt, ki omogoča pregledovanje, spreminjanje in popravljanje tabelarično prezentiranih podatkov (Slika 1, zaznamek številka 5). 18 Menu (termin zaradi razumljivosti nismo prevajali) meni. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 17

23 Slika 3: Konceptualen pogled na aplikacijo. Našteti termini so del splošno sprejete terminologije (GUI), ki jo uporabljajo vsa sodobna grafično orientirana razvojna programska orodja. Ker je aplikacija prototip, je nabor osnovnih objektov zaenkrat omejen. Poslovne aplikacije v osnovi omogočajo prikaz, potrjevanje, vnos in spreminjanje alfanumeričnih znakov, to pa nam omogočajo tudi našteti objekti. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 18

24 4.3.2 Programska logika Programska logika skrbi za skladno delovanje celotnega okolja. Na nek način je to vezivo, ki veže aplikacijo v celoto. Skrbi za komunikacijo med objekti. Programska logika določa tudi osnovne lastnosti objektov. Skupek lastnosti in metod pa določa obnašanje objekta navzven. V našem primeru mora biti ta logika čim bolj univerzalna in mora omogočati čim večjo nastavljivost od zunaj. Seveda mora biti razmerje med odprtostjo in fleksibilnostjo dobro odmerjeno, saj v nasprotnem primeru postanejo stvari prevelike in nepregledne, s tem pa nismo zagotovili ene izmed osnovnih zahtev in to je poenostavljanje na nivoju poslovne aplikacije. Programska logika je porazdeljena na vse tri nivoje. Največ jo je na aplikacijskem nivoju, sledi odjemalec in na koncu podatkovni strežnik, ki preko relacij skrbi za konsistentnost podatkov. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 19

25 4.3.3 Predstavitev okolja in orodja za gradnjo aplikacij V nadaljevanju bo predstavljen postopek izgradnje in uporaba orodja za gradnjo uporabniških aplikacij. Postopek izgradnje poteka z lastnim orodjem, ki je neposredno integrirano v samo okolje. Vzporedno z izgradnjo bodo predstavljena tudi osnovna orodja in postopki Prijava v okolje Prijava v aplikacijo (slika 4) predstavlja mehanizem za identifikacijo uporabnika. Uporabnik svojo identiteto izkaže z uporabniškim imenom (polje»user name«) in geslom (polje»password«). Glede na uporabnika se v polju»application«prikaže ustrezen nabor aplikacij, za katere ima uporabnik pravice. Z opcijo»connect as«pa uporabnik izbere, ali bo aplikacijo uporabljal (opcija»user«) ali bo aplikacijo razvijal (opcija»developer«). Opcija»Developer«ni avtomatsko dodeljena z dodelitvijo pravice za uporabo aplikacije. Omenjene pravice dodeljuje administrator okolja, ki skrbi za dodajanje uporabnikov in dodeljevanje njihovih pravic. Slika 4: Začetno okno, namenjeno prijavi v okolje Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 20

26 Administracija aplikacij okolja Omenjena funkcija se uporablja za dodajanje aplikacije v sistem (slika 5), spreminjanje nazivov, brisanje aplikacij iz okolja pa je preprečeno. Samo v primeru, če je aplikacija kreirana, je mogoče nadaljevati z gradnjo pripadajočih objektov aplikacije (meniji, obrazci, vnosna polja, tabele itd.). Slika 5: Prikaz vnosa nove aplikacije v sistem Polje»ID«se avtomatsko generira in ga ni mogoče vnesti. Polje App name je namenjeno identifikacijskemu nazivu bodoče aplikacije. Sledi mu polje»app title«, ki je namenjeno naslovu aplikacije (kratek opis). Polje»App Descr«je namenjeno daljšemu opisu in morebitnim zaznamkom, ki so vezani na aplikacijo.»owner Id«je identifikacijska številka uporabnika, ki je lastnik posamezne aplikacije. V našem primeru je to kar uporabnik»admin«. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 21

27 Administracija menija V našem primeru je meni hierarhično organiziran (slika 6). Njegov namen je uporabniku na pregleden način ponuditi dostop do posameznih opcij aplikacije. Slika 6: Administracija menijev Uporabniški vmesnik za gradnjo aplikacijskega menija je zasnovan tako, da načrtovalec vnaša posamezne menijske opcije kot posamezne zapise in jih povezuje med seboj. Podrejene opcije menija imajo vedno navedeno referenco na nadrejen zapis (polje»parent ID«). Vrhnja menijska opcija ima omenjeno polje prazno. V poju»app ID«navedemo, kateri aplikaciji zapis pripada. Vnosno polje»form ID«je zelo pomembno, ker z njim določimo, kateri obrazec se bo klical ob izboru menijske opcije. Če je to polje prazno, menijska opcija nima uporabne vrednosti. Polje»Menu name«predstavlja kratek naziv aplikacijske opcije. Za vizualno prezentacijo so pomembna polje»menu label«(naziv, ki se neposredno prikazuje končnemu uporabniku kot izborna opcija),»menu icons«(navedemo naziv ikone, ki jo želimo prikazati pred nazivom),»m.order«(določitev zaporedja prikaza znotraj ene veje) in»menu tool tip«(razširjen opis, ki se prikazuje ob približanju kazalnika miške osnovnemu nazivu). Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 22

28 Administracija uporabnikov Uporabniki aplikacij se administrirajo na enem mestu (slika 7). To opcijo lahko uporabljajo samo uporabniki, ki imajo administratorske pravice v celotnem okolju. Po vnosu uporabnika se naknadno določa pravice nad posameznimi aplikacijami okolja. Administrator ima na ta način celovit nadzor nad dostopom uporabnikov do posameznih aplikacij. Ko uporabniku preteče pravica za delo z določeno aplikacijo, je mogoče z odvzemom pravice enostavno onemogočiti dostop in uporabo. Slika 7: Vnosni obrazec za dodajanje uporabnika Vsak uporabnik ob vnosu dobi unikatno številko (polje»id«) in unikatni naziv»user name«. Z njim in ustreznim geslom se lahko prijavi v sistem. Polje»Usr.Descr.«je namenjeno dodajanju opisov in opomb, ki so vezana na posameznega uporabnika. Za različne namene (npr. za dostavo ustreznega gesla) je potrebno navesti elektronski naslov (polje» «). Sledi mu polje»usr.active«, s katerim lahko zelo enostavno omogočimo ali preprečimo dostop in uporabo okolja. Uporabnik, ki ima polje»admin«izbrano (opcija»da«), ima administracijske pravice nad delom okolja. V nasprotnem primeru lahko uporablja samo aplikacije. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 23

29 Kreiranje obrazcev Obrazec služi kot vizualna osnova, na katerega razvijalec veže objekte, kot so gumbi, seznami, vnosna polja, spustni seznami itd. (vmesnik za administracijo obrazcev slika 8). Vsi obrazci, ki se aktivno uporabljajo, so neposredno povezani s posameznimi opcijami menija. Le-te omogočajo klic obrazca in posledično prikaz vizualnih objektov. Slika 8: Vmesnik za kreiranje obrazca Vsak obrazec je vezan na posamezno aplikacijo (vnosno polje»app ID«). Za primarno identifikacijo se uporablja polje»id«(polje se sekvenčno povečuje), za sekundarno pa polje»form name«. Polje»Form title«predstavlja naslov (navadno načrtovalci aplikacije izberejo nek smiseln tekst, ki opiše namen in vlogo obrazca), ki se prikaže nad vsakim obrazcem (zgornji levi kot). Polje»F. width«in»f. height«sta namenjena definiciji velikosti, polje»f. lab.width«pa določitvi širine teksta (»labele«) objektom, ki vsebujejo pred-tekst. Polje»On Load«pa je pripravljeno za vnos programske kode (skriptna koda), ki se izvede pred prikazovanjem obrazca. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 24

30 Dodajanje objektov na obrazec Kot je bilo že omenjeno, je obrazec podlaga za vizualne objekte (osnovne vizualnegrafične gradnike). Predstavljena opcija omogoča povezovanje objektov in določenega obrazca aplikacije. Nabor osnovnih objektov je omejen na uporabo v poslovnih aplikacijah. Osnovni vizualni objekti so: gumb, tekstovno vnosno polje, spustni seznam, seznam vrednosti, datumsko vnosno polje s koledarčkom in preglednica. Slika 9: Vmesnik za dodajanje objektov na obrazec Polje»Form ID«določi obrazec, na katerem bomo objekt pozicionirali. Potem določimo, kateri razred bo osnova (polje»class ID«). Objektu določimo ime (polje»oject name«) in vrstni red prikaza (polje»f. order«). Ko je objekt dodan na obrazec, mu je potrebno nastaviti njegove lastnosti in metode. Vsak razred ima svoj nabor. Nastavitve se opravijo v spodnjem delu opcije»lastnosti objekta«. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 25

31 Administracija polj Polja so namenjena povezovanju osnovnih objektov s podatkovnimi strukturami. Polje objektu določi podatkovni tip, obliko in dolžino vnosne maske (če je to potrebno), format prikaza podatkov, začetno vrednost, opis, povezavo z morebitnim pomožnim šifrantom itd. Ker polje vsebuje vse potrebne podatke za kreiranje tabele, se uporabljajo tudi pri sestavljanju posamezne tabele aplikacije. Iz tega pa se kasneje fizično kreirajo tabele (več v nadaljevanju). Slika 10: Administracija lastnosti in metod polja (prvi zavihek) V tabeli 3 so naštete vse lastnosti in metode, ki so na voljo za določeno polje. Za osnovno definicijo polja niso potrebni vsi našteti parametri, ampak samo nekaj osnovnih (»App ID«,»Field name«,»f. type«in»field label«). Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 26

32 Lastnost / metoda L/M Opis app id L ID aplikacije, kateri polje pripada field name L Naziv polja field type L Podatkovni tip field label L Tekst, ki se pojavlja pred poljem field pix size L Širina polja v pikah field max char len L Maksimalno število znakov polja field input format L Vnosni podatkovni format field tool tip L Dodatni opis field default val L Privzeta vrednost field default function M Funkcija, ki se izvede ob vnosu podatkov field descry. L Opis polja field default class Id L Privzeti razred field sortable L Ali lahko polje sortiramo (tabele)? field editable L Ali lahko polje spreminjamo? field hidden L Ali je polje skrito? field list sql L SQL stavek za pomožni šifrant field list_values L Predvideno za krajše liste vrednosti (z vejico ločene vrednosti) field force value L Forsirana vrednost field validate function M Funkcija, ki se izvaja za preverjanje vnosa field db len L Dolžina polja za kreiranje table field db type L Dodaten za kreiranje tabele Tabela 3: Lastnosti in metode polja Večina obveznih polj se izpolni na prvem zavihku opcije»administracija lastnosti in metod polja«(slika 10). Dodatna polja, ki pa niso obvezna, se vnesejo na drugem zavihku (slika 11). Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 27

33 Slika 11: Administracija lastnosti in metod polja (drugi zavihek) Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 28

34 Kreiranje tabel in šifrantov Vsaka definicija tabele je sestavljena iz imena in posameznih polj, ki jo sestavljajo. Za potrebe okolja sta predvideni dve tabeli. Prva je šifrant vseh tabel (slika 12»Administracija tabel«), v drugi so shranjena vsa polja posamezne tabele (slika 12»Polja tabele«). Po vnosu naziva tabele sledi še vnos ustreznih polj. Ko je tabela ustrezno opisana, sledi kreiranje fizične tabele. To omogoči opcija»kreiraj tabelo«. Ko je tabela kreirana, je pripravljena za uporabo znotraj aplikacije. Če tabela še ne vsebuje nobenega zapisa, jo je mogoče enostavno izbrisati z opcijo»briši tabelo«. Slika 12: Administracija tabel in posameznih polj Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 29

35 4.4 TESTIRANJE Metoda testiranja Prototip bomo testirali tako, da bomo generirali aplikacijo, ki bo vsebovala več vnosnih mask, šifrantov in prometnih tabel. Ob izgradnji bomo preverili, ali orodje ustreza zastavljenim ciljem Rezultati Ker želimo rezultate predstaviti v obliki delujoče aplikacije, smo si za predstavitev izbrali izdelavo preproste aplikacije (menijski del, nekaj obrazcev in šifrantov). Aplikacija se bo imenovala»evidenca partnerjev«in bo namenjena evidentiranju poslovnih partnerjev. Aplikacija vsebuje nekaj šifrantov (šifrant regij, šifrant poštnih številk, šifrant dejavnosti podjetij in šifrant davčnih zavezancev). Vsi našteti šifranti so pomožni del vnosa posameznega partnerja (opcija»vnos partnerja«). Za namene iskanja in pregledov pa je namenjena opcija»pregled partnerjev«. Postopek izdelava aplikacije je naslednji: Najprej smo kreirali tako imenovano»novo aplikacijo«. Preko razvojnega okolja smo v tabelo aplikacij dodali nov zapis. V naslednji fazi smo kreirali menijsko strukturo. Sledila je podrobna definicija vseh potrebnih polj, ki se pojavijo v aplikaciji. S pomočjo definiranih polj se v naslednji fazi definirajo potrebne tabele (šifranti in prometne tabele). Po definiciji tabel sledi kreiranje tabel iz teh definicij. Sledila je definicija vseh potrebnih obrazcev. Obrazci so sestavljeni iz vnosnih polj, gumbov in tabel. Kreiranje in določitev pravic uporabnikov. Na koncu je sledil postopek testiranja in željena aplikacije je bila končana. Za omenjen postopek je bilo porabljeno cca. 90 min, kar je v primerjavi s časom, ki ga bi porabili za klasično načrtovanje in izvedbo, zelo malo. Ne smemo pozabiti, da je aplikacija trinivojska. Namenjena je uporabi več uporabnikom hkrati. Z omejitvijo dostopa do posameznih opcij aplikacije je mogoče uporabnikom omogočiti uporabo opcij, za katere so jim dodeljene ustrezne pravice. Uporabniški vmesnik je prilagojen za spletno uporabo. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 30

36 Predstavitev nekaj opcij generirane aplikacije: Slika 13: Opcija generirane aplikacije»šifrant regij«slika 14: Opcija generirane aplikacije»vnos partnerja«boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 31

37 Slika 15: Opcija generirane aplikacije»pregled partnerjev«rezultati so popolnoma zadostili zastavljenim ciljem. Izkazalo se je, da je s predstavljenim orodjem mogoče zelo hitro izdelati poslovno aplikacijo, orodje pa je zaradi preproste uporabe primerno tudi za uporabnike, ki nimajo specialnih znanj pri gradnji spletnih aplikacij. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 32

38 5 KAKOVOST IN UPORABNOST 5.1 Kakovost Kakovost produkta je zelo pomemben pojem, ki ga je potrebno zasledovati in resno obravnavati že od samega začetka. To pomeni, da upoštevamo načela in metode za zagotavljanje kakovosti že v fazi načrtovanja in v vseh naslednjih fazah, ki ji sledijo. Le na tak način lahko zagotovimo tudi kakovost končnega izdelka. Pojem kakovosti je zelo širok in je podrobno opisan v seriji standardov ISO/IEC SQuaRE. Kot navaja Kukovica (2009) je mogoče spremljati kakovost v vseh treh osnovnih fazah življenjskega cikla programske opreme, in sicer pri razvoju, obratovanju in uporabi. Mi smo se predvsem osredotočili na zagotavljanje kakovosti v fazi razvoja. Ker je produkt šele v prototipni fazi, ga fazi obratovanja in uporabe šele čakata. Veliko pozornosti smo posvetili zagotavljanju varnosti prenosov podatkov, zanesljivosti delovanja in učinkovitosti podatkovnega modela. 5.2 Uporabnost Pri razvoju smo veliko pozornosti posvetili sami uporabnosti (angl. Usability) orodja. Uporabnost je eden ključnih elementov za merjenje usklajenosti produkta s potrebami in željami uporabnikov. Za oceno uporabnosti smo se naslonili na definicijo, ki je uporabljena v standardu ISO (1998) in pravi»uporabnost sistema je merilo uspešnosti, učinkovitosti in zadovoljstva, s katerim lahko tipičen uporabnik z uporabo tega sistema, v določenih pogojih in okolju, doseže zastavljen cilj.«v nadaljevanju bomo podali subjektivne ocene za posamezne elemente uporabnosti (uspešnost /angl. Effectiveness/, učinkovitost /angl. Efficiency/ in zadovoljstvo /angl. Satisfaction/) Ocena uspešnosti Glede na zastavljene cilje in pričakovane rezultate je stopnja izvedenih nalog zadovoljiva. Z orodjem je mogoče v zelo kratkem času uspešno izdelati delujočo poslovno aplikacijo (predstavljeno v poglavju»testiranje«) z vsemi pripadajočimi elementi. Pri samem postopku izgradnje in uporabi aplikacije ni prihajalo do nepredvidenih napak Ocena učinkovitosti Ocena učinkovitosti temelji na primerjavi porabljenega časa za izgradnjo testnega prototipa (predstavljeno v poglavju»testiranje«) in časa za gradnjo ekvivalentne aplikacije po klasični metodi programiranja. Testi so pokazali, da orodje močno pospeši cikel razvoja, posledično pa se poveča tudi učinkovitost gradnje in testiranja. Boštjan Martinek: Razvoj generatorja poslovnih spletnih aplikacij stran 33