Agilni projekti - lahek dostop do izkušenih uporabnikov

Najprej bi omenil razliko med domenskimi strokovnjaki (business experts) in izkušenimi uporabniki (expert users). Ni nujno, da sta to različni osebi, je pa v praksi to večkrat res.

Po domače povedano bi rekel, da domenski strokovnjaki obvladajo teorijo, izkušeni uporabniki pa poznajo vsakdanje operacije v delovnih postopkih. Prvi imajo pregled nad poslovnimi strategijami, drugi pa vedo katere informacije so v določenem trenutku pomembne za izvedbo konkretnega postopka.

Kaj pridobimo z lahkim dostopom do slednjih?

• Ljudi, ki jim lahko dajemo vmesne produkte v testiranje.
• Hiter odziv o kvaliteti produkta.
• Razvojna ekipa pridobi odzive na uporabljene prijeme pri načrtovanju aplikacije.
• Pridobimo ažurne podatke o funkcionalnih zahtevah

Raziskave (Kiel, Carmel) so pokazale veliko večji uspeh pri projektih, ki so imeli neposredno povezavo med razvojno ekipo in izkušenimi uporabniki sistema, ki ga želimo informatizirati ali izboljšati procese. Razlika se pokaže že pri tedenski frekvenci komunikacije. V odvisnosti od faze projekta je seveda odvisna tudi komunikacija. Ob začetku sta dva sestanka tedensko in dostop prek telefona ali druge elektronske komunikacije običajna.

Pri pomembnih projektih naročnik tudi "posodi" take uporabnike razvojnim ekipam ali pa obratno, nekdo iz razvojne ekipe se začasno "zaposli" pri naročniku in tako pridobi neprecenljive informacije procesov, ki jih želimo informatizirati. V slednjem primeru se tudi ublaži razlika med običajno dvema različnima svetovoma programerjev in uporabniki njihovih izdelkov - lahko se okrepi spoštovanje do drugega dela in zadovoljstvo ob rešitvi.

XML členitelji

Med tri-črkovnimi kraticami je verjetno med bolj znanimi v programerskih vodah - XML (Extensible Markup Language). Ima burno zgodovino in mislim, da se prah okoli te kratice le polagoma poseda. Koliko zvenečih besed je bilo izrečenih in nekaj prav gotovo utemeljeno. No, izkazalo se je, da XML le ni naš odrešitelj, je "le" zelo uporabno orodje, če ga lahko tako kličem. Ker se ta blog ukvarja predvsem z jezikom Java, bom danes poskusil razdelati XML členilnike (XML parsers) po več kriterijih.

Slika po znanem reku pove več kot 1000 besed, zato bom pokomentiral posamezne standarde oziroma značilnosti le-teh.

Najbolj groba delitev je na drevesni objektni model (Document Object Model) in na pretočne (streaming) členitelje. Za odločitev katero družino uporabiti je odločina velikost dokumentov, ki jih nameravamo obdelovati. Najbolje je, da na pričakovanih realnih primerih izmerimo porabo pomnilnika in procesorskega časa, velja pa ocena, da za dokumente velikostnega razreda nekaj 10 MB ni več optimalna uporaba DOM členiteljev. Seveda je brezpredmetno tudi za Java ME. Če si vseeno lahko privoščimo uporabo DOM Java APi-jev, pa so nekatere rešitve precej elegantne, kot na primer uporaba XPath jezika za poizvedbe po drevesnem objektnem modelu.

Priporočam JDOM, ki je zelo "očiščen" Java API za manipulacijo z XML DOM drevesom. Očiščen pravim zato, ker je DOM W3C-jev standard in členitelji, ki temeljijo na njem morajo upoštevati razne obskurnosti, ki so v specifikaciji zaradi pokrivanja splošnosti med programskimi jeziki.

Naslednja velika delitev je med pretočnimi izvedenkami. Povlečni (pull) in potisni (push) način. Bolj znan je SAX, ki je starejši, a ga začetniki vseeno neradi uporabljajo zaradi kompliciranosti. Sam API je dokaj enostaven, vendar je uporaba v aplikacijah nepotrebno komplicirana. Ima pa zelo dobro lastnost - hitrost. Zaradi zelo majhnega števila objektov, ki se morajo kreirati med členjenjem, je tudi poraba sistemskih virov majhna. Razne skupine so kmalu ugotovile pomanjkljivosti potisnega načina, kot je na primer dejstvo, da členitelj kliče našo aplikacijo in ne obratno, kot se to počne pri potisnih izvedenkah. Iz tega so nastali XPP serija in nazadnje (oktober 2003) tudi StAX standard.

Razlika je v tem, da SAX členitelj prebere XML dokument in nato kliče metode v naši aplikaciji, povlečne členitelje pa kontroliramo iz aplikacije, torej mi povemo členitelju kdaj naj procesira. Imamo torej kontrolo nad aplikacijsko nitjo.

Bistvene prednosti povlečnih pred potisnim SAX so:

• Členjenje preprostih XML dokumentov lahko izvedemo s preprosto kodo.
• Lažje je napisati kodo za rekurzivno členjenje.
• Če med členjenjem enega dokumenta ugotovimo, da potrebujemo informacije iz drugega, lahko to storimo v isti niti.
• Lahko preskakujemo dele XML dokumenta, ki nas ne zanimajo in tako prihranimo čas in procesorsko moč.
• Lahko ustvarimo pretočne cevovode (streaming pipelines).

Iz slike je razvidna še ena delitev in sicer na take povlečne, ki uporabljajo iteratorje, kurzorje in take, ki se obnašajo mešano (kreiranje dogodkovnih objektov med členjenjem lahko preprečimo s ponovno uporabo starih). Pri StAX standardu, ki bo mimogrede vključen v Java 6 (Mustang), so se odločili za izvedbo dveh API-jev, enega, ki uporablja iteratorje in drugega, ki uporablja kurzorje. Iz tega razloga imamo možnost izbire glede na kontekst aplikacije, ki jo razvijamo. Odločimo se glede na:

• Če razvijamo Java ME aplikacijo, uporabimo kurzor API.
• Če želimo imeti brezkompromisno hitrost procesiranja, uporabimo kurzor API.
• Če želimo spreminjati dogodkovni tok, uporabimo iterator API.
• Če delamo ekstenzibilne module, uporabimo iterator API.
• Če smo v dvomih, uporabimo iterator API.

Priporočam StAX, ki ga lahko uporabimo tudi za kreiranje XML dokumentov (bolj intuitivno pa to počnemo z JDOM).