Objekti-orientoutunut - ABL vai 4GL? Pegissä (Progress Group) oli jokin aikaa sitten mielenkiintoinen keskustelu ohjelmointikielemme nimestä.

Transkriptio

1 VUOSIKERTA 4 1/2014 NUMERO FinPUG News HUOM! Säästä luontoa älä tulosta tätä paperille! Tässä numerossa 1 ABL vai 4GL? 2 Puheenjohtajan palsta 2 EMEA PUG Challenge FinPUG Majvik 4 Progress Exchange FinPUG 2014 SEMINAARI 6 Progress Rollbase 8 Progress Rollbase työpaja 9 EMEA PUG Challenge 2013 / Bryssel 12 Tutkimusmatka olioiden maailmaan 20 Progress Exchange 2013-raportti 22 PUG Baltic 23 PUG CHALLENGE AMERICAS Objekti-orientoutunut - ABL vai 4GL? Pegissä (Progress Group) oli jokin aikaa sitten mielenkiintoinen keskustelu ohjelmointikielemme nimestä. Alkuperäinen nimihän oli Progress 4GL, samoin tietokannan nimi oli Progress RDBMS, sovelluspalvelimen Progress AppServer jne. Kun Progress laajensi tuotevalikoimaansa, nämä Progress-tuotteet nimettiin OpenEdge-tuotteeksi. Progress tarkoittaa edistystä OpenEdge niin mitä? Open on tietenkin suomeksi avoin, Edge on terä tai reuna. Edge tarkoittaa myös hivuttautumista. Kielen nimenmuutokseksi ei riittänyt OpenEdge 4GL, vaan uudeksi nimeksi tuli ABL, lyhenne sanoista Advanced Business Language. Monet meistä haluavat kuitenkin puhua 4GL:stä. 4GL sisälsi tietyn lupauksen: Se on kehittyneempi kuin kolmannen sukupolven ohjelmointikielet eli lausekielet (3GL), puhumattakaan konekielistä tai Assemblerista. Niinhän se onkin. Mutta mihin ovat kadonneet muut 80-luvulla kehitetyt 4GL-kielet? 4GL-konseptin epäonnistuminen taisi olla syy siihen, miksi Progressin markkinoinnissa päädyttiin 4GL-nimen vaihtamiseen. 4GL:t eivät menestyneet vaan katosivat markkinoilta - paitsi Progress. Toisaalta kieli ei ole enää niin siistiä englannin kieltä muistuttavaa lausekieltä, vaan sisältää mitä ihmeellisimpiä konstruktioita ja lähestymistapoja. Syynä on liiketoimintasovellusten laajeneminen eri osaalueille, uudenlaiset ohjelmointitekniikat, joista pienin ei ole oliosuuntautuminen eli luokkaobjektit. Se on tämän numeromme pääteema. Kirjoitukset FinPUG News:iin Ehdotukset seminaarien aiheiksi Kiinnostus hallituksen jösenyyteen Muu palaute finpug.fi FinPUG Kaikista uutuuksista on taas runsaasti tietoa FinPUG seminaarissamme, joten Tervetuloa Majvikiin! Welcome to Majvik! Tere tulemast Majvik! Добро пожаловать в Майвик! Teppo Määttänen toimittaja

2 SIVU 2 FINPUG NEWS Puheenjohtajan palsta Älä ohita tätä tilaisuutta! EMEA PUG Challenge 2014 Matti Kiviranta, Qvantel Business Solutions Tervehdystä kaikille lukijoille puheenjohtajan pöydän äärestä. Monille varmasti olen tuntemattomampi kasvo ja haluankin täten heiman esittäytyä. Olen Matti Kiviranta ja tulen Qvantel Business Solutionsilta josssa toimin vanhempana tietokanta-asiantuntijana. Progress maailmassa olen ollut hyvin lyhyen aikaa, vain vuodesta 2007 alkaen, kun verrataan moniin jäseniimme. Vuosien saatossa on OpenEdge on tullut läheiseksi ja monet sen kanssa työtä tekevät myös, lisäksi olen saanut tutustua moniin Progressin työntekijöihin niin Suomessa kuin muuallakin. Osana puheenjohtajan tehtäviä olen mukana myös Euroopan käyttäjäkokouksen järjestävässä porukassa. Tänä vuonna EMEA PUG Challenge järjestetään Düsseldorfissa, jossa järjestävien käyttäjäryhmien puheenjohtajat kokoontuivat helmikuun alussa. Edelliseistä vuosista poiketen puheenjohtajien kokous oli EMEA PUG Challengen järjestämä ja täten keskittyi täysin tapahtuman järjestämiseen. Oli hienoa päästä näkemään tilat etukäteen, sillä tänä vuonna tilat ovat reilusti tilavammat kuin esimerkiksi Brysselilssä tai Kölnissä. järjestetään tänä vuonna Saksan Dûsseldorfissa keskiviikosta perjantaihin. Euroopan Progress-käyttäjäryhmien yhdessä järjestämä konferenssi ei ole mainostilaisuus, vaan tiukasti asiapitoinen osaamisen lisäämispaikka, jossa esitelmoitsijät on valittu Progressmeriittien perusteella Euroopasta ja Yhdysvalloista. Tapaat kollegojasi eri puolilta Eurooppaa ja saat valita aiheita ainakin neljästä rinnakkaisesta sessiosta. Saat myös päivityksen Progressin strategiasta ja tiekartasta ilman, että joudut matkustamaan valtameren taakse. Tämä on viides kerta tällä konseptilla, että käyttäjäkerhot ovat isäntinä, ja joka kerralla tilaisuus on aina parantunut! Tilaisuuden ilmoittautuminen alkaa näinä viikkoina, ja Super Early Bird-hinnalla säästät jopa sata Euroa. FinPUG- ja muut PUG-jäsenet jäsenet saavat erityisalennuksen. Seuraa sivua: FinPUG 2014 seminaari on melkein ovella ja sinne toivonkin jäsenistömme tulevan runsain määrin. Pääpuhujiksi olemme tälle vuodelle onnistuneet haalimaan Richard Banvillen ja Shelly Chasen, joten rautaista ammattitaitoa ja tietoa Progressin tuotteista on tulossa. Heidän lisäksi lavalle nousevat Jarmo Nieminen ja Jami Lehtovirta. Nähdään FinPUG seminaarissa Majvikissa! Matti Kiviranta Puheenjohtaja

3 FINPUG NEWS SIVU 3 FinPUG Majvik FinPUG:in hallitus on tehnyt huolellista suunnittelua saadakseen aikaan tapahtuman, joka parhaiten palvelee Progress/OpenEdge-käyttäjiä juuri tällä hetkellä keväällä Progress (OpenEdge) on liiketoimintasovellusten kehittämisessä suhteellisen vanha teknologia. Monet meistä ovat aloittaneet sen kanssa jo ja 1990-luvulla. Menestyksellisimpien suomalaisten ITsovellusten juuret ovat samoilta ajoilta. Mitä uutta tässä enää tarvitaan? Ympäristö on muuttunut ja muuttuu kaiken aikaa ja myös tulevaisuudessa. Progress on kyennyt mukautumaan tähän kehitykseen, eikä sen ydinominaisuuksia (tietokanta, ohjelmointikieli) ole tarvinnut muuttaa. Sen sijaan kaikkea on laajennettu ja kehitetty samalla kun liiketoimintasovellukset ovat laajentuneet uusille osa-alueille. Mitä tälle vuodelle on suunniteltu: "Progress Rollbase työpaja" Vaikka Progressilla on tehty nettisovelluksia jo parikymmentä vuotta WebSpeedillä, tähän osaalueeseen ei ole tullut tuotteeseen uusia ominaisuuksia pitkään aikaan. Nyt tulee: Progress Rollbase on mitä modernein ja tehokkain nettisovellusten kehitin, joka perustuu JavaScript-kieleen, point&click-kehittämistekniikkaan ja valmiiden komponenttien ja sovellusmallien hyödyntämiseen. Tämä kannattaa ehdottomasti opetella! Samaan aihepiiriin kuuluu Shelley Chasen esitys: Progress Rollbase - Miten sitä käytetään OpenEdge tietokannan päällä. "Tietokantataulujen horisontaalinen partitiointi" Tietokannoistamme on tullut vuosien myötä valtavan kokoisia, kun tekniset ja loogiset rajoitteet on poistettu. Samanaikaisesti ongelmaksi on muodostunut tietokantojen hallinta, jota sitäkin on kehitetty koko ajan. Uusi projekti Progress/OpenEdge-tietokantaan on taulujen horisontaalinen partitiointi, jolla helpotetaan suurien taulujen hallintaa. "OpenEdge Mobile johdanto nopeaan käyttöönottoon" Jo vuoden meillä on ollut käytössämme sovelluskehitin älypuhelimiin ja tabletteihin aitojen mobiilisovellusten tekemiseksi. Kömpelöt webbisovellukset eivät enää riitä näihin laitteisiin. Mobile on nopeimmin kehittyvä IT-kehittämisen ala tällä hetkellä, jossa on runsaasti kysyntää kokonaan uusistakin sovelluksista. Olemassa oleviin OpenEdge-sovelluksiin ei välttämättä tarvitse tehdä kovin paljon muutoksia, koska OE Mobile osaa käyttää valmista business-logiikkaa uuden liittymän kautta. Haasteena on käyttöliitynnän tekeminen, johon siis on olemassa havainnollinen kehitin. <jatkuu>

4 SIVU 4 FINPUG NEWS "Käytettävyys" Tästä asiasta ei koskaan puhuta liikaa, ja kaikki uudet ideat kannattaa pyrkiä omaksumaan. "Oliopohjainen ABL - mistä aloittaa ja miten jatkaa" Progress/OpenEdge on parhaimmillaan ollut korkean tason proseduraalisena ohjelmontikielenä, jolla on voinut toteuttaa hankalimmatkin algortimit. Olio-ohjelmointi on kuitenkin tätä päivää, ja yliopistolta valmistuvat ammattilaiset ovat kouliintuneet puhtaaseen Java-oliotekniikkaa osaamatta perinteisiä lausekieliä, kuten Pascalia joskus ennen. ABL-kielessä voidaan käyttää rinnakkain proseduraalisia lauserakenteita ja luokka/oliotekniikkaa, eli kysymys ei ole joko/tai asetelmasta kuten esim. Javassa. Tästä aiheesta on tässä numerossa Veli-Matti Korhosen eriomainen kirjoitus, joka perustuu omakohtaiseen asioihin perehtymiseen. "Mitä uutta OpenEdge tietokannan versiossa 11" Jos työskentelet OpenEdge-tietokannan kanssa, sinun kannatta tietää, mitä uutta uudet versiot siihen aina tuovat. Valitettavasti tämän tietämyksen laiminlyöminen johtaa usein huonoihin ratkaisuihin - yksinkertaisesti siitä syystä, ettei tietoa ole ollut tarpeeksi. Muutakin ohjelmaa on, mutta näistä yksikin aihe riittää perusteeksi osallistua vuotuiseen tapahtumaamme! Äläkä unohda mahdollisuutta kokemusten ja näkemysten vaihtoon kollegojesi kanssa. Progress Exchange Orlando Florida! Floridassa kaikki on suurta! Progress Exchange tapahtumat ovat olleet aina menestyksekkäitä! Progress Exchange 2014 tapahtuma järjestetään tänä vuonna Floridassa (Orlando) Lisätietoa tapahtumasta, ilmoittautumisesta täältä:

5 FINPUG NEWS SIVU 5 FinPUG 2014 SEMINAARIN OHJELMA Aika: Paikka: Kokous -ja kongressihotelli Majvik, Kirkkonummi ( Esiintyjät: Jarmo Nieminen, Progress Software Oy ( Rich Banville, Progress Software Corporation Shelley Chase, Progress Software Corporation Jami Lehtovirta, CGI ( Matti Kiviranta, Qvantel Business Solutions Oy ( Ohjelma: Torstai Ilmoittautuminen ja aamukahvi Progress Softwaren aamupäivä (suomeksi) Jarmo Nieminen: Progress Rollbase työpaja Majoittautuminen Lounas Rich Banville: Tietokantataulujen horisontaalinen partitiointi Shelley Chase: OpenEdge Mobile johdanto nopeaan käyttöönottoon Kahvitauko / FinPUG vuosikokous Jami Lehtovirta: Tavoitteena käytettävyys, HTML5- ja JavaScript-pohjainen käyttöliittymäarkkitehtuurin ERPjärjestelmään (suomeksi) Shelley Chase: Oliopohainen ABL - mistä aloittaa ja miten jatkaa? Kokouksen ensimmäinen päivä päättyy. Liikuntatoiminnot, sauna, uima-allas Illallinen Iltaohjelmaa Perjantai Aamiainen Shelley Chase: Progress Rollbase - Miten sitä käytetään OpenEdge tietokannan päällä Rich Banville: Mitä uutta OpenEdge tietokannan versiossa Matti Kiviranta: Suuret tietokannat käytännössä, konfigurointi ja suoritusteho, kokemuksia taulujen horisontaalisesta partitioinnista (suomeksi) Kokous päättyy. Huoneiden luovutus Arpajaiset. 12:30 Lounas (Huom. Ohjelmaan voi tulla muutoksia.)

6 SIVU 6 FINPUG NEWS Progress Rollbase - Mitä se tarjoaa OpenEdge käyttäjille? Shelley Chase Progress Rollbase on pilvialustassa toimiva ohjelmiston kehittämisen ja toimittamisen ympäristö. Siinä tehdään liiketoiminnan sovelluksia, jotka toimivat palveluina (Software as a Service - SaaS). Kehittämisen työkalut toimivat "osoita ja napsauta", "vedä ja pudota" menetelmillä tavallisella selaimella ilman asennuksia. Koodia kirjoitetaan minimaalinen määrä. Progress Rollbase on lupaus nopeasta sovelluskehityksestä (RAD), joten sovellus syntyy pienemmässä ajassa kuin perinteisillä ohjelmistokehityksen menetelmillä. Progress Rollbasea voi käyttää sekä palveluna (Progress Rollbase Hosted Cloud ) että suljettuna asennuksena (Progress Rollbase Private Cloud). Näitä voidaan käyttää millä tahansa pilvi-infrastruktuurille tai omilla verkkoasennuksilla. Progress Rollbase on siis palveluna toimiva sovellusalusta (Application Platform as a Service - apaas) sekä loppukäyttäjäyrityksille että ohjelmistotoimittajille (ISV). Se tarjoaa täydellisen järjestelmän vuokralaishallintaan (multi-tenant) ja käyttöönoton hallintaan, sovelluskehitykseen, sovellusten julkaisemiseen ja käyttöönottoon. Progress Rollbase tarjoaa ISV- ja jälleenmyyjille etikettömän tuotteen (white label) ominaisuuksia, joten se on helppo ottaa käyttöön minkä tahansa brändin, tuotemerkin tai identiteetin merkeissä. Kaikki Progress Rollbase-sovellukset toimivat aitoina Progress Rollbase alustan palveluina heti, kun ne on rakennettu. Erillisiä manuaalisia käyttöönottoja ei tarvita. Käyttöönottoon liittyy vain käyttäjien lisääminen ja käyttöoikeuksien määrittelyt. Käyttäjät tarvitsevat sovelluksen käyttämiseen vain Internet-yhteyden ja ajan tasalla olevan selaimen. Rollbase jatkaa ja laajentaa Progressin sitoutumista missioonsa, joka on: mahdollistaa yrityskäyttäjien ja yksityisten kehittäjien luoda sovelluksia ilman vuosien ohjelmointikokemusta. Kuten myös OpenEdge BPM ja Progress Corticon tuotteiden tapauksissa, Rollbasesovelluksia voidaan luoda, muokata ja ylläpitää huomattavasti Shelley Chase on senior-arkkitehti Progressin OpenEdgekehitysryhmässä. Hän liittyi Progressiin Aikaisempaa kokemusta hänellä oli yrityssovellusten kehittämisessä ja olio-ohjelmoinnissa sekä UNIX- ja Windows-ympäristöissä. OpenEdge-tuotteissa Shelley on keskittynyt palveluarkkitehtuurin (SOA) OpenEdge-käyttöliittymään ja ohjelmointikielen (ABL - Advanced Business Language) kehittämiseen. Shelley on ollut keskeisesti mukana suunnittelemassa ja kehittämässä monia OpenEdge-ominaisuuksia kuten ActiveX, Web Services, avoimet rajapinnat (COM, Java ja.net), oliolaajennukset, OpenEdge GUI.NET ja OpenEdge Mobile. LinkedIn luettelee hänen taitojaan seuraavasti: SOA Web Services Software Development Agile Methodologies Distributed Systems XML Java Architecture Application Architecture Eclipse REST SOAP OpenEdge ClearCase Mobile Technology.NET Object Oriented Design Mobile Applications <jatkuu>

7 FINPUG NEWS SIVU 7 yhteistyökykyisemmässä ja ketterämmässä kehittämisen ja käyttöönoton toimintatavassa. Kuulostaa hyvältä! Uusi, ominaisuuksiltaan monipuolinen ja helppo sovellusten kehittämisen ja käyttöönottoa alusta. Mutta mitä se merkitsee Sinulle, joka olet OpenEdgeohjelmistotoimittaja tai OpenEdge-sovellusta käyttävä loppukäyttäjä? Ensinnäkin: Rollbase täydentää OpenEdgeä - se ei ole korvaava tai kilpaileva tekniikka. Toiseksi: Rollbasen tehtävänä on yksinkertaistaa liiketoiminnan sovelluksien kehittäminen ja käyttöönotto. Kuulostaako tutulta? Niin pitääkin. Tämä on myös OpenEdgen tehtävä ja missio. Sama missio, mutta eri ympäristöissä. Rollbase tarjoaa kehittämistä ja käyttöönottoa pilvessä. OpenEdge tarjoaa paikallista kehitystä ja erilaisia käytön asennusvaihtoehtoja. Itsenäiset OpenEdge-kehittäjät (ISV) ja suorat loppukäyttäjät (DEU) voivat käyttää Progress Rollbasea laajentamaan OpenEdge-sovelluksiaan monin tavoin, erityisesti siirtämällä sovellustaan pilveen. Selaimellasi voit suunnitella ja kehittää monipuolisiä, yhteistoiminnallisia, web-pohjaisia sovelluksia, jotka saat nopeasti käyttöön tiimillesi tai asiakkaillesi. OpenEdge sovelluksia ollaan laajentamassa kumppaneillemme seuraavilla tavoilla: - Rakenna uusi moduuli tai sovellus käyttäen Rollbasea. Tietoja voidaan välittää Rollbasen ja OpenEdgen välillä jakamalla OpenEdge tietokantaa D2C:n avulla tai käyttämällä API-kutsuja tiedonvälityksessä. - Tarjoa web- ja mobiili-versio OpenEdge sovelluksestasi. Jos OpenEdge sovellus käyttää sovelluspalvelinta eli AppServeriä, Rollbase tarjoaa integroidun OpenEdge Adapterin, jolla voi käyttää OpenEdge-sovelluksen businesslogiikkaa. Rollbase voi tarjota mekanismin lisätä perinteisen OpenEdge sovelluksen arvoa luomalla sille uusia käyttäjäryhmiä tai laajentaa sovelluksen ominaisuuksia ja käyttötapoja. Rakentamalla Rollbasella lisämoduuleita, sovellukseen tulee uusia web-selaimeen perustuvia käyttökanavia. Hyvä paikka etsiä uusia lisättäviä on tarkastella Rollbasen sovellusmalleja. <jatkuu> Richard Banvillen käyntikortissa lukee: "Progress OpenEdge Fellow - Progress Software". Hän tuli Progressille 1993, taustanaan käyttöjärjestelmien testaaminen ja kehitystyö. Richard on työskennellyt monissa OpenEdge-projekteissa osastojen ja tiimien rajat ylittäen, mutta painopiste on ollut tietokannan talletuksessa ja OpenEdge SQL:n eri osa-alueilla. Hänen kehityskohteitaan ovat olleet myös suoritustehoprojektit, tietokannan rinnakkaiskäsittely ja tietenkin multi-tenancy-projekti, jossa yksi tietokanta palvelee monta yritystä vuokrasovellusratkaisuissa. Hän on myös yksi harvoista Progresskehittäjistä, jotka ohjelmoivat edelleen Assemblerilla, kun tarve siihen ilmenee. Richard keskustelee mielellään kaikkien OpenEdge-tietokannan käyttäjien kanssa tietokantaan tarvittavista uusista ominaisuuksista. FinPUG-2014:ssa hänen aiheinaa ovat tietenkin tietokanta-asiat: Tietokantataulujen horisontaalinen partitiointi Mitä uutta OpenEdge tietokannan versiossa 11

8 SIVU 8 FINPUG NEWS Mallit eli templatet ovat olemassa CRM-sovelluksiin, Onlinetutkimuksiin ja kyselyihin, yhteystietojen hallintaan, koululuokkien aikataulutukseen, toivomusten pyyntöjärjestelmiin, yhteisöfoorumeihin ja moniin muihin. Näitä malleja voidaan käyttää sellaisenaan, räätälöidä, varustaa omalla brändillä tai tuotemerkillä sekä laajentaa lisäämällä niihin toiminnallinen moduuli uutuutena tai laajennuksena nykyiseen järjestelmään. Suurin Progresskäyttäjäkerho on PEG! Nämä voidaan ottaa käyttöön käyttämällä Progress Pacific pilveä tai paikallisesti. Ja meidän pitäisi huomata, että sovelluksen ja paikallisen tai Arcade-pilvessä toimivan OpenEdge-sovelluksen välinen yhteys vaihtelee käyttöasennuksen perusteella... Mutta jos sinulla on kysymyksiä, tutustu vilkkaaseeb keskusteluun, jota käydään foorumeilla: Mobiili-ja web-sovelluksista on tullut vaatimus monilla tuotannonaloilla ja erottuva tekijä muille. Ota vapaa koeajo Rollbasella ja katso mitä se voi tehdä Sinulle! Liity jo tänään: Progress Rollbase työpaja Majvik FinPUG 2014 seminaarin yhteydessä on mahdollisuus osallistua Progress Rollbase työpajaan. Se on suomen kielellä pidettävä kädestä pitäen-opetustilaisuus, jossa osallistujat luovat lyhyessä ajassa heti käyttöönotettavan apaas-sovelluksen. Saat omakohtaisen kokemuksen Progress Rollbasen tekniikasta. Tule siis paikalle jo torstaina aamulla kello 9:30. ** Jos et ehdi paikalle, ja sinulle kelpaa englanninkielinen Rollbase Workshop, klikkaa tätä:

9 FINPUG NEWS SIVU 9 EMEA PUG Challenge 2013 / Bryssel Osallistuin 8 muun suomalaisen kanssa neljänteen EMEA PUG Challenge tapahtumaan 6-8. marraskuussa 2013 Brysselissä. Yhteensä osallistujia oli maasta. Tapahtuma on jokasyksyinen: Ensimmäinen järjestettiin 2010 Kölnissä, sitten 2011 Amsterdamissa ja 2012 Manchesterissa. Alunperin tämä tapahtuma perustettiin korvaamaan Progressin järjestämiä käyttäjäkokouksia. Finanssikriisin takia Progress peruutti vuoden 2009 kokouksensa, ja muutti sen netin kautta pidettäväksi, joita pidettiinkin parina vuonna. Nyt Progress järjestää vuosittaisia käyttäjäkokouksia, mutta vain USA:ssa - tänä vuonna kolmatta kertaa. Sielläkin on vakiinnutettu käyttäjien itselleen järjestämä "PUG Challenge Americas", joka järjestetään joka vuonna alkukesällä. EMEA PUG Challenge on käyttäjäkerhojen yhteistyöhön perustuva. Järjestelytoimikunta koostuu maiden kerhojen puheenjohtajista. Kolmessa ensimmäisessä FinPUG:ia edusti Jouni Kokkonen, viime vuonna Matti Kiviranta. PUG Challenge paranee vuosi vuodelta Kolmeen tai kahteen päivään saadaan mahdutetuksi runsaasti tiiviitä ja laadukkaita esityksiä, joista saa irti niin paljon kuin riittää vastaanottokykyistä energiaa. Kolmipäiväinen tilaisuus oli itselleni suorastaan antoisa: Ensin kaksi neljätuntista koulutus-workshoppia aiheina Progress Rollbase ja Progress Mobile. Molemmissa tehtiin sovelluksia: Rollbasella CRM-websovellus ja Mobiililla mobiilisovellus asiakastietojen ylläpitoon. Seuraavat kaksi päivää menivät pääosin breakout-luennoilla, joissa keskityin uusiin tuotteisiin ja OpenEdgen uusiin ominaisuuksiin. Kokouksessa mukana olivat myös Progressin osuudet, joissa yhtiön tilannetta ja tulevaisuutta esiteltiin. Meille esiintyi myös uusi pääjohtaja Philip Pead. Hän vaikuttaa pätevältä ja sopivalta tehtäväänsä: 25 vuoden kokemus sovellusalalta näkyi hänen ymmärryksessään siitä, mikä on Progressin ja sen kumppanien vahvuudet ja sen mukaisesti osannee johtaa yhtiötä tulevaisuuteen. Hän myös ohimennen mainitsi, että firma on velaton ja käteistä rahaa on 100 miljoonaa dollaria. Progress Pacific Nykyisen tilanteen taustana on se, että toissa vuonna Progress karsi toimintaansa ja päätti keskittyä OpenEdge-tuotteisiinsa. Tässä yhteydessä mm. Sonic sanomanvälitys- ja ESB-tuotteista luovuttiin. Nyt Brysselissä puhuttiin jo avoimesti kymmenen vuoden "sekoilusta", josta nyt on siis opittu ja palattu kaidalle tielle. (Arviointieroja on siinä kestikö tämä jakso 5, 10 tai 15 vuotta.)

10 SIVU 10 FINPUG NEWS Progressin ominaisuus on aina ollut olemassa olevien sovellusten tukeminen, mutta samalla tehdään tuotteita ja ratkaisuja, joilla nämä sovellukset vastaavat ympäristön muutoksiin ja tulevaisuuden haasteisiin. Uusissa tuoteratkaisuissa näkyvät erityisesti sovellusten siirtyminen palveluiksi ja vuokrasovelluksiksi. Sovellusten pitää toimia pilvessä SaaS- ja PaaS-palveluina. Tästä tuotekokonaisuudesta käytetään nimeä nyt Progress Pacific. Progress OpenEdge-sovellusten siirrettävyys PaaS-sovelluksiksi on helpottunut huomattavasti, kun versiossa 11 tietokantaan tehtiin multi-tenancy-optio. Tällöin yksi tietokanta ja installaatio pilvessä voi palvella useampia asiakkaita ilman, että sovelluskoodiin tarvitaan muutoksia. Mobiililaitteet Mobiililaitteita varten Progress teki viime keväällä OpenEdge Mobile sovelluskehittimen. Myös monella ohjelmistotalolla oli Brysselissä esitteillä omia toinen toistaan hienompia ratkaisujaan, joilla sovelluksia käytetään älypuhelimella tai tabletilla. (Microsoftin käyttöliittymä ja.net eivät olleet konferenssissa kovin voimakkaasti esillä.) Progress Pacific ei ole pelkästään Progress OpenEdge-tuoteperhe (tietokanta, clientit, appserverit). Siihen kuuluu myös uusia tukijalkoja: OpenEdge BPM (Business Process Management) perustuu aikaisemmin hankittuun Savvion-tuotteeseen. Savvion-tuotteet myytiin pois mainitun karsinnan yhteydessä, mutta Progress piti lähdekoodin ja nyt BPMominaisuuksia integroidaan OpenEdgeen ja sitä kautta OpenEdgesovelluksiin. Kyse on toimintaorganisaatioiden prosesseista ja tehtävien ketjuttamisesta eri vastuualueiden välillä ja tämän kytkemisestä liiketoimintasovelluksiin. OpenEdge Corticon on business-logiikan hallintajärjestelmä. Kaikki tiedämme, että OpenEdge:n ohjelmointikieli ABL (a.k.a. Progress 4GL) on markkinoiden paras business-logiikan ohjelmointikieli. Nyt tämän toteuttamiseksi tuodaan lisää vaihtoehtoja. Corticonin lähestymistapa business-logiikkaan perustuu sääntöjen ylläpitoon tietokannassa. Hyvä sovellusesimerkki on sääntötietokanta lääkkeiden yhteisvaikutuksesta ja terveysriskeistä. Ennen kuin henkilölle X määrätään uutta lääkettä, olisi hyvä tietää taustatietoja henkilöstä (ikä, sukupuoli, sairaudet, perinnöllisyydet, allergisuudet, elintavat jne.) ja hänen jo käyttämistään lääkkeistä. Sääntökokonaisuus voidaan tietenkin ohjelmoida IF THEN ELSE- ja CASE, WHEN tekniikoilla tai monimutkaisemmin parametroimalla säännöt sovelluksen tietokantaan. Tällä tavalla rakennettu säännöstö on hankalaa ylläpitää. Corticonissa loppukäyttäjät itse ylläpitävät säännöstöä.

11 FINPUG NEWS SIVU 11 Toinen ongelma on sääntöjen testaus: Miten voidaan olla varmoja, että kaikki sääntöjen kombinaatiot on otettu huomioon tai ovatko säännöt keskenään päällekkäisiä? Corticon osaa tarkistaa säännöstön molemmat ominaisuudet. Säännöstön monimutkaisuuden kasvaminen yleensä vähentää päättelyn suoritustehoa eksponentiaalisesti. Corticonissa kuitenkin vain lineaarisesti patentoidun tekniikan ansiosta. Rollbase on oliopohjainen JavaScript-kieltä käyttävä point-and-click sovelluskehitin web-sovelluksille. Kehittäminen tehdään suoraan kohdeympäristössä eli verkossa uudelleenkäytettäviä olioita yhdistellen. Tuote ostettiin kalifornialaiselta startupilta. Näissä kaikissa kolmessa lähiaikojen haasteena on yhdistetty sovelluspalvelin (Unified AppServer), joka palvelee kaikkia sovelluksia ja osaa suorittaa sekä ABL-, JavaScript ja Java-koodia. Sitä saamme vähän aikaa odotella. Tämän vuoden EMEA PUG Challenge Conference pidetään Düsseldorfissa marraskuuta. Merkitse päiväys kalenteriisi, ja ilmoittaudu mahdollisimman aikaisin Super Early Bird-hinnalla. FinPUG-jäsenet saavat vielä lisäalennuksen! Teppo Määttänen Rollbase työpajassa opittiin JavaScript-ohjelmointi Point and Click menetelmällä. OpenEdge Mobile työpajassa tehtiin asiakkaiden ylläpitosovellus sports2000- tietokantaan

12 SIVU 12 FINPUG NEWS Velen tutkimusmatka olioiden ihmeelliseen maailmaan Kysymys ei useinkaan ole menetelmästä tai välineestä, vaan miten sillä on asioita tehty. "Missä pihvi, miettii kasvissyöjä." Mitä hyötyjä Object Oriented ABL-ohjelmointi voi antaa? Voiko olioilla tehdä jotain paremmin tai helpommin kuin ilman niitä? Vai onko olio-ohjelmointi vain saman asian tekemistä toisella tavalla? Näitä kysymyksiä minulla oli mielessä, kun aloin miettimään tätä juttua. Ohjelmistokehityksen alusta asti on ollut tavoitteena rakentaa yleisiä komponentteja, joista loppusovellus kootaan. Näitä komponentteja on kutsuttu eri aikoina ja eri malleissa erilaisilla nimillä kuten sovellusrungot, templatet, moduulit tai yleiset luokat. Idea ja tavoite on näiden yleiskäyttöisten osien osalta sama. Niillä pyritään yleistämään eli abstraktoimaan toistuvia osia ohjelmarakenteista. Tällä tavoitellaan sitä, että varsinaisen sovelluksen tekeminen on helpompaa ja nopeampaa, muutettavuus ja rakenteen hahmottaminen helpompaa, sovellukset ovat virheettömämpiä ja uusille kehittäjille helpompia omaksua. Eli tiivistettynä haetaan tuottavuutta ja sitä kautta taloudellisuutta. Kuten muutkin ohjelmointimallit ja uudet työkalut tätä samaa lupaa myös olio-ohjelmointimalli. Halusin ottaa selvää mitä tuo käytännössä tarkoittaa. Mitkä asiat voi tehdä paremmin ja helpommin kuin proseduureihin ja funktioihin perustuvilla ABL-ohjelmilla.

13 FINPUG NEWS SIVU 13 Minulla oli aavistus ja toive siitä, missä saisin itselleni suurimmat edut. Olin hyvin iloinen, kun tuo toive näyttää oliomallissa toteutuvan. Yllätyin muutenkin positiivisesti enkä pelkästään siinä, että huomasin taas kerran vanhan koiran voivan oppia uusia temppuja :) Hiukan historiaa Itse aloitin ohjelmoinnin Progressilla 1987 aikana kauan ennen kuin Progress 4GL-kielessä oli aliproseduureja, funktioita tai esiprosessorimuuttujia puhumattakaan dynaamisista objekteista. Noihin aikoihin ei buffereita välitetty ohjelmista toiseen. Siihen aikaan include-tiedostot olivat tärkeä tapa tehdä yleiset osat sovellusta. Jos oikein muistan, ei alkuvaiheessa voinut include-tiedostoon välittää edes parametreja. Kieli kehittyi ja aikojen kuluessa Progress alkoi lisäämään ominaisuuksia, joiden avulla saatiin oliokielten tarjoamia piirteitä. Isoja muutoksia olivat viittaaminen "objekteihin" osoittimen (handle) avulla ja välittämällä osoitin ohjelmien välillä, persistentit ohjelmat, aliohjelmien ja funktioiden kutsuminen toisissa ohjelmissa, SUPERproseduurit ja dynaamiset ohjelmarakenteet. Nuo uudistukset mahdollistivat entistä paremmin yleiskäyttöisten komponenttien rakentamisen. Tuosta tulikin mieleen ensimmäiset työvuoteni 1980-luvun loppupuolella, jolloin tein ohjelmia kauppojen kassajärjestelmiin. Kassat olivat kalliita erikoislaitteita. Mitä enemmän kassa muistutti ominaisuuksiltaan PC:tä sitä kalliimpi ja hienompi se oli. Minulle heräsi kysymys, miksi ei käytetä suoraan monta kertaa halvempia PC-laitteita, joissa on paljon isompi näyttö ja siihen voi tehdä ohjelmia Progressilla assemblerin tai C-kielen sijaan. Progressin suhde oliomalliin oli vähän samanlainen. Progress 4GL lähestyi sitä, mikä oli jo olemassa - oliomalli. Lopulta Progress teki lopullisen ison harppauksen ja lisäsi Progress-kieleen oliomallin mukaiset osat. Yleensä olen ottanut käyttöön Progress-kielen uudet ominaisuudet sitä mukaa kun niitä on tullut, mutta oliomalli oli poikkeus. Tutustuin kyllä pian oliomalliin ja piirteisiin niiden tullessa lukemalla Progressin käyttöohjeissa olevan hyvän oppaan jo elokuussa Nykyisin tuo opas löytyy dokumentaatiosta nimellä "OpenEdge Development: Object-oriented Programming" ja sitä voin suositella. Olen vuosien aikana kuunnellut ison joukon luentoja olioaiheesta. Myöhemmin olen käyttänyt olioita kehittäessäni sovelluksia OF-1- ja Skin-Client Mobilekehitystyökaluilla. On kuitenkin eri asia käyttää toisten tekemiä valmiita komponentteja kuin tehdä niitä itse. WAF-ohjelmarungon muuttaminen Object Oriented ABL-malliin Olin kehittänyt itselleni OpenEdge Reference Architecture:n mallin mukaisen sovellusrungon (WAF), mutta olin toteuttanut sen proseduureilla ja funktioilla. Olin rakentanut rungon sellaiseksi, että suurin osa yleisistä ominaisuuksista oli sijoitettu yleisiin ohjelmakirjastoihin. Jako oli hyvin tehty, mutta en ollut täysin tyytyväinen. Tiesin, että voisin järjestellä yleisten osien paikkoja ja vähentää koodia varsinaisissa sovellusohjelmissa ja siirtää sitä yleisiin osiin - samaan tapaan kuin matematiikassa sievennetään yhtälöitä. Pelkäsin, että liika yleistäminen tekisi ohjelmien muuttamisen haastavammaksi. Halusin pitää sovellusohjelmat selkeästi hahmotettavina.

14 SIVU 14 FINPUG NEWS Nyt halusin saada selville pystynkö toteuttamaan yleiset osat paremmin oliomallin avulla ja mikä onnistuisi paremmin. Valmistautuminen Päätin siis sukeltaa syvemmälle olioiden ihmeelliseen maailmaan. Perusteet olivat siis tuttuja. Aloitin verryttelyn lukemalla kirjan Ohjelmistotuotanto (Ilkka Haikala, Jukka Märijärvi) ja siitä erityisesti oliosuunnitteluun ja -ohjelmointiin liittyvät osuudet. Kirjassa korostettiin, että oli toteutusmenetelmä mikä tahansa, hyvään lopputulokseen edellytyksenä on huolellinen suunnittelu. Olio-ohjelmoinnissa suunnittelun tärkeys korostuu entisestään. Eikä varmaan kenellekään ole yllätys se, että kaikilla mahdollisilla menetelmillä ja työkaluilla voi tehdä huonoa jälkeä. Kysymys ei useinkaan ole menetelmästä tai välineestä, vaan miten sillä on asioita tehty. Olio-ohjelmointiin liittyy joukko omaa sanastoa. Vaikka ne saattavat alussa tuntua oudoilta, ei kannata hätkähtää. Käsitteillä on olio-ohjelmoinnissa oma tarkka merkityksensä, mutta niillä tarkoitetaan samoja asioita ja rakenteita, joita kehittäjät ovat aina etsineet ja joita he ovat eri tavoin ratkaisseet. Kirjassa todettiinkin, että kokeneen kehittäjän mielestä oliomallissa ei ole varsinaisesti uutta ja näin kirjan mukaan pitäisikin olla. (Poimin tuosta kirjasta oliosanastoa, jonka laitan jutun loppuun. Samat käsitteet on kuvattu Progressin oppaassa.) Jatkoin lämmittelyä katsomalla kahdeksanosaisen videosarjan. Siinä John Sadd esittelee esimerkein OO-ABL-piirteitä. Noiden avulla sai hyvän yleiskuvan. Tuo sarja löytyy ja sieltä hakusanalla ABL Videos: Introduction to ABL Classes. Kilautin myös kavereille eli kirjoitin kokeneille OO-ABL kehittäjille. Stefan Freystätter (IAP) on kokenut Java-kehittäjä, joka hallitsee nykyisin hyvin Progress-kielen. Bernd Hellman (IAP) on kokenut ABL-kehittäjä, joka on pitkään kehittänyt OO-ABL-kielellä mm. Skin-Client ja Skin-Client Mobile oliorajapintaa. Ensimmäinen ja tärkein vinkki oli se, että syvemmin voi oppia vain tekemällä. Stefanin kokemuksen mukaan oliomallin oppiminen on yksilöllistä kuten kaikki muukin oppiminen. Jotkut omaksuvat oliomallin intuitiivisesti eli ymmärtävät sen hyötyineen luonnostaan, toiset joutuvat tekemään enemmän työtä oppimisen eteen ja jotkut eivät koskaan sisäistä mallia. Oma kokemukseni on, että sama pätee muidenkin mallien ja työkalujen osalta. Kysyin mitä hyötyä Stefan ja Bernd näkevät oliomallissa. Tässä heidän vastauksiaan: - käännösaikainen syntaksin tarkistus (vrt. RUN lause) - vähemmän päällekkäistä ohjelma koodia ja r-koodia (vrt. include) - pakottaa selkeämpään kehittämiseen - helpompi tapa esittää todellisen sovelluksen malleja - aidot oliot - helpompi toteuttaa yleisiä ohjelmanosia (vrt. super procedure, include) - olioiden automaattinen siivoaminen muistista - garbage collector (vrt. delete object) - työvälineiden tuki ja integraatio kieleen Eclipse-ympäristössä Tämä kuulosti hyvältä, mutta miten se käytännössä näkyisi ja mikä olisi helpompaa?

15 FINPUG NEWS SIVU 15 Suurin odotukseni oli kontekstin (bufferit, temp-taulut, muuttujat...) eli sovellusohjelman käsittelyssä olevien tietojen välittäminen yleiseen osaan. Omassa WAF-rungossani olin toteuttanut yleiset osat proseduureina. Sovellusohjelmassa oli oma konteksti (bufferit, temp-taulut, muuttujat...) ja yleisessä osassa oma. Jos yleinen osa tarvitsi jotain tietoa, se piti välittää sinne. Vaikka tietojen välittäminen proseduurien välillä on helpottunut (handle, buffer, dataset), silti välittäminen asettaa haasteita ja vaikeuttaa ohjelman hahmottamista. Omassa WAF-ohjelmarungossani olivat esim. yleiset ominaisuudet tietojen haulle, näytölle, talletukselle, lisäykselle ja poistolle. Ylläpito-ohjelmassa käsiteltiin yhtä tiettyä taulua esim. asiakas. Kun yleisissä osissa käsittelin esim. asiakasta, täytyi tarvittavat asiakkaan tiedot välittää sinne. Olin ratkaissut asian pitämällä välitettävät kontekstitiedot temp-taulussa ja välittää ne siinä. Kyllä se toimi, mutta tiesin, että täytyy olla parempi ratkaisu. Ja totta - oliomalli ratkaisee tämän haasteen! WAF-ohjelmarungossa Business Entity kerros sisältää tietokantaa käsittelevät osat ja se voi olla eri koneessa kuin käyttöliittymäosat. Se on itsenäinen kerros ja ensimmäisessä vaiheessa en koskenut siihen. Pystyin käyttämään olioistani BE-palveluja ilman muutoksia BE-ohjelmiin. Aloitin siis käyttöliittymästä. Jaoin ylläpitoon liittyvät yleiset osat kahteen luokkaan. Ylimmässä luokassa BE-services on yhteydet BE- kerrokseen ja kaikki BE-palveluja tarvitsevat luokat voivat käyttää tuota luokkaa. Tätä alempi luokka update-container sisältää yleiset tauluista riippumattomat palvelut (haku, näyttö, talletus, lisäys, poisto...). Alimpana on varsinainen sovellusohjelma esim. customer-container. Tämä perii update-container ominaisuudet ja sen yläpuolella olevan BE-services luokan ominaisuudet (kuva: Luokka-esimerkki). Tässä oli minulle päivän kasvispihvi: Kun customer-container käynnistetään se perii ylemmät luokkansa ja niiden kaikki ominaisuudet. Ylemmät luokat eivät ole erillisiä ohjelmia, vaan niiden ominaisuudet tulevat osaksi customer-containeria. Eli käytännössä ylemmissä luokissa määritellyt muuttujat, propertyt, temp-tablet, bufferit, metodit ovat käynnistetyn luokan käytössä. Samoin yleisluokka update-container voi huoletta käyttää ja muuttaa isäluokkansa BE-services ominaisuuksia ja metodeja kuin omiaan. Ja nehän ovat omia, koska ne ovat perintöä. Tämä jos mikä poisti hyvin paljon ylimääräistä koodia ja teki varsinkin sovellusohjelmista lyhyitä ja ytimekkäitä. Pystyin siirtämään suurimman osan koodista ylempiin luokkiin. Tämä johtui siitä, että turha tiedon välittäminen sovellusohjelman ja yleisenosan välillä poistui.

16 SIVU 16 FINPUG NEWS Itse yritän löytää esimerkkejä jostain vanhasta tutusta. Ohjelmoijan näkökulmasta voisi ajatella, että ylemmät ohjelmat käyttäytyvät kuin include-tiedostot - siis include-tiedostoja, joista meitä Progress-kehittäjiä on varoiteltu ja suositeltu siirtymään proseduureihin ja funktioihin. Ohjelmassa voi viitata mihin tahansa include-tiedostossa määriteltyyn osaan (muuttujat, bufferit, temp-taulut) - luonnollisesti, koska kääntäjä kopioi include-tiedoston sisällön ohjelmakoodiin. Mitä haittaa include-tiedostoista sitten on ja miksi niistä varoitetaan? Jos yleisessä osassa oleva ohjelmakoodi kopioidaan jokaiseen ylläpito-ohjelmaan, käännettyjen r-ohjelmien koko on hyvin suuri. Toinen iso haaste on selkeys ja hahmotettavuus. Siihen voi tietysti vaikuttaa hyvällä suunnittelulla. OpenEdge Architect / Studio on tiukasti kytketty tukemaan OO-ABL olioita Eikö sitten samat ongelmat kuin include-tiedostoilla tule vastaan olioiden kanssa? Itselleni toinen todella suuri iloinen yllätys oli se tuki, mitä OpenEdge Architect / Studio antaa olioille. Ilman kehitysvälineen tukea vähänkin monimutkaisissa sovelluksissa kehittäminen ja ohjelman hahmottaminen olisi lähes mahdotonta. Mutta koska oliorakenne on selkeä ja yleispätevä, kehitysvälineiden on helpompi ymmärtää sitä. Vaikka ohjelma koostuu useasta eri luokkatasosta, käytännössä käyttämällä olioluokkia ohjelmien hallittavuus ja hahmotettavuus on helppoa ja voisi jopa sanoa hauskaa. Kun "perinteisessä" ohjelmoinnissa viitataan handle-muuttujaan tai ajetaan toisen ohjelman aliohjelmia, ei voida tietää viittaako handle oikeantyyppiseen objektiin tai ovatko parametrit oikein. Olio-ohjelmissa handlen sijasta käytetään muuttujaa, joka on tyyppiä oliotyyppi. Voisi ajatella, että muuttuja on handle, josta on kerrottu minkä tyyppisen objektin handle se on. Ilman olioita koodi voisi olla tällainen: DEFINE VARIABLE hcustomercontainer AS HANDLE NO-UNDO. RUN wonne/pro/customer-container.p PERSISTENT SET hcustomercontainer. RUN openrow (1) IN hcustomercontainer. Vastaavasti oliotyyliin: DEFINE VARIABLE ocustomercontainer AS CLASS wonne.customer-container.cls NO-UNDO. ocustomercontainer = NEW wonne.customer-container(). ocustomer:openrow(1). Muuttujaan ocustomer ei voi tallettaa muuta kuin wonne.pro.customer-container.cls object-handlen. Kääntäjä ja työkalut tietävät siis tarkkaan mitä metodeja ocustomer-handlessa voi olla. Kirjoittamalla ocustomer: saadaan lista mahdollista metodeista, muuttujista tai propertyistä. Tai tarkkaan ottaen niistä, joihin ko. ohjelmalla on oikeus. Metodien, muuttujien ja propertyjen määrittelyssä voidaan määritellä, kuka saa niitä käyttää (PUBLIC, PROTECTED, PRIVATE). Jos openrow metodia ei löydy wonne.pro.customer-container.cls luokasta tai sen isäluokista, ohjelma ei käänny. Jos parametri on väärää tietotyyppiä tai parametri puuttuu, ohjelma ei käänny. Käytännössä vähänkin monimutkaisissa sovelluksissa tämä alkaa nopeasti tuntua mukavalta. Ilman olioita kehittäjän pitää olla hyvin tarkkana ja joidenkin virheiden selvittäminen oli hankalaa. Olen kokeillut myös olioiden debuggausta Progress Debuggerilla, ja myös se tuntuu helpommalta olioiden kanssa.

17 FINPUG NEWS SIVU 17 Propertyt yksinkertaistavat koodia Olio voi määritellä muuttujan kahdella tavalla: variable tai property. Molempiin voi viitata suoraan toisesta ohjelmasta tyyliin ocustomer:rowavailable, jos siihen on lupa (PUBLIC, PROTECTED tai PRIVATE). Property mahdollistaa erikseen määrittelemään eri oikeudet luvulle ja kirjoittamiselle (GET ja SET). Moni tieto voi olla saatavissa kaikkialla (PUBLIC), mutta päivitettävissä vain sen määrittelevässä luokassa (PRIVATE) tai myös sen aliluokissa (PROTECTED). Lisäksi propertyn määrittelyyn voi kirjoittaa logiikkaa. Esim. DEFINE PUBLIC PROPERTY rowavailable AS LOGICAL NO-UNDO GET: IF VALID-HANDLE(hEntityBuffer) AND hentitybuffer:available THEN RETURN YES. ELSE RETURN NO. END GET. PRIVATE SET. Tämä on yksinkertainen esimerkki, mutta logiikka voi olla hyvinkin monimutkainen. Voidaan kutsua vaikka metodia property-asetuksen sisällä. Ulospäin kiinnostaa vain tuo yksittäinen tieto, mutta sen muodostuslogiikka on olion sisäistä tietoa ja se tehdään vain yhdessä paikassa. Staattiset oliot näkyvät kaikille Sovelluksissa on paljon tietoa, joka on sovellusistunnon aikana muuttumaton eli staattinen. Tällaista tieto on usein käyttäjään (kieli, tunnus), yritykseen (osasto, yritystunnus) tai ulkoasuun (värit, fontit) liittyvät tiedot. Oliot sopivat erinomaisesti yhteisten tietojen hallintaan ja jakamiseen. Oliot voivat olla staattisia, jolloin ne näkyvät kaikille. Myös esim. temp-tablet, muuttujat ym. voivat olla stattisia. Hyviä käyttökohteita staattisille osille ovat esim. käyttöoikeustiedot, virheiden käsittely tai kieliversiointi. Staattisiin olioita ei "käynnistetä" eli uutta instanssia ei luoda. Niihin viitataan suoraan niiden nimellä. Esim. staattinen luokka wonne/component/c-session.cls jossa on määritelty property UserId. DEFINE STATIC PUBLIC PROPERTY UserId AS CHARACTER NO-UNDO GET. PRIVATE SET. Login-ohjelmassa arvo asetetaan ja sitä voi käyttää mistä tahansa istunnon ohjelmasta: MESSAGE wonne.components.c-session:userid. Staattiset osat muistuttavat toiminnaltaan perinteisiä GLOBAL-määrityksiä, joissa piilee iso vaara. Mistä tahansa sovelluksen osasta GLOBAL-määriteltyä tietoa voi muuttaa. Staattisten osien

18 SIVU 18 FINPUG NEWS merkittävä ero on se, että esim. propertyn voi määritellä niin, että luku on mahdollista kaikille, mutta arvon päivitys on mahdollista vain propertyn määrittelevässä luokassa. Räätälöiminen luomalla uusia olioita periyttämällä Olioista on helppo tehdä uusia versioita. Kun olio perii ylemmän luokan, sillä on kaikki ylemmän luokan ja sitä ylempien luokkien ominaisuudet. Eli jos uudessa luokassa ei ole määritelty mitään, se on sama kuin luokka, josta peritään. Alempaan luokkaan lisätään vain ne ominaisuudet ja metodit, jotka laajentavat tai poikkeavat ylemmästä luokasta. Oma WAF-kehykseni käyttää Skin-Client käyttöliittymää. Otin käyttöön tämän kokeen yhteydessä Skin-Client oliorajapinnan. Esim. Skin-Client frame on olioluokka nimeltä P-FRAME. Tuolla P-FRAME oliolla on paljon erilaisia ominaisuuksia. Halusin muuttaa tiettyjä oletuksia ja loin uuden olioluokan WO-FRAME, joka perii P-FRAME:n. Määrittelin WO-FRAME luokkaan poikkeavat asiat. Tässä esimerkissä sijainti on taustan sinivalkea liukuväri ja automaattinen koon skaalaus ylemmän komponentin koon mukaan. CLASS wonne.wo-components.wo-frame INHERITS P-FRAME: CONSTRUCTOR PUBLIC WO-FRAME (oclass AS CLASS Progress.Lang.Object): SUPER(oClass). ASSIGN THIS-OBJECT:ANCHORS = "LEFT+TOP+RIGHT+BOTTOM" THIS-OBJECT:X = 1 THIS-OBJECT:Y = 1. THIS-OBJECT:SET-GRADIENT-PAINT (0, /* X1 */ 0, /* Y1 */ (J-COLOR:get-Color(190,220,255)), /* Color RGB */ 0, /* X2 */ 300, /* Y2 */ (J-COLOR:get-Color(255,255,255)), /* Color RGB */ NO). /* Cyclic */ END CONSTRUCTOR. END CLASS. Kun uusi instanssi WO-FRAME luodaan (NEW WO-FRAME), sille asetetaan automaattisesti esimerkissä määritellyt arvot. Tämän lisäksi rakensin uusia monimutkaisempia olioita, joissa käytin useita eri Skin-Client olioita. Esimerkkinä toolbar ja ylläpito-container, jossa on tietynlainen otsikko-osa ja muita yleiskäyttöisiä ominaisuuksia. Vaikka nämä sisäisesti koostuvat useista eri olioista, ulospäin ne näkyvät yhtenä oliona, jolla on yhdet ominaisuudet.

19 FINPUG NEWS SIVU 19 Onko olioista apua apua? Kyllä on ja paljon. Oliomalli antaa kehittäjälle uusia mahdollisuuksia ja tekee työskentelyn helpommaksi. Itse innostuin ja tekeminen niiden kanssa oli odotettua helpompaa ja jopa hauskaa. OpenEdge Architectiä / Studio-työkalu tarvitaan. Olioiden avulla yleisistä osista saadaan selkeämpiä, tiiviimpiä ja helpommin käytettäviä. Varsinaiset sovellusohjelmat saadaan tiiviiksi, mutta silti hahmotettavuus ja muutettavuus säilyy. Ylemmän luokan metodeja ja muuttujia voi alemmassa luokassa korvata erilaisella toteutuksella, kun poikkeuksia tarvitaan. Hienoa on se, että Progress ei pakota yhteen malliin. Proseduureista voi käyttää olioita ja olioista voi käyttää proseduureja. Tämä mahdollistaa sen, että muutosta voi tehdä kuin söisi elefanttia pala palalta. Stefan ja Bernd olivat oikeassa. Olioista saa kunnon otteen vain itse kokeilemalla. Veli-Matti Korhonen Wonne Oy Progress on tehnyt arkkitehtuuria esittelevän autokaupan mallisovelluksen. AutoEdge on toteutettu objekteilla ja se löytyy osoitteesta: Oliosanastoa Abstract class - Isäluokka jolla ei ole ilmentymiä Instance - Olion ilmentymä (instanssin luonti NEW-lauseella) Class - Koteloinnin yksikkö (OE.cls) Attribute - Ominaisuus, ilmentymä Method - Funktio, proceduuri, palvelu, operaatio, aliohjelma Message Veli-Matti Korhonen - Viesti, aliohjelmakutsu Inheritance - Periytyminen, lapsiluokassa isäluokan attribuutit ja metodit Specialization - Erikoistaminen, uuden luokan tekeminen periyttämällä Generalization - Uuden yhteisen isäluokan luominen Aggregation - Koostaminen, käytetään olion komponentteina muita olioita Overloading - Kääntäjä valitsee käytettävän metodin saman nimisistä metodin parametrien perusteella Polymorfism - Eri olioilla saman nimisiä metodeja ja attribuutteja./..

20 SIVU 20 FINPUG NEWS Progress Exchange 2013-raportti Muutaman vuoden tauon jälkeen Progress järjesti viime syksynä Bostonissa Progress Exchange-konferenssin, johon osallistui kehittäjiä, myyjiä, liiketoimintajohtoa ja muita alan ammattilaisia yli 30:sta eri maasta; yhteensä osallistujia oli n Konferenssi alkoi sunnuntai-iltana vapaamuotoisella verkostoitumistilaisuudella, jolloin pääsimme keskustelemaan mm. Progressin kehityksestä vastaavien ihmisten ja muista maista tulleiden kollegoiden kanssa. Suomesta ei tainnut osallistua muita kuin kolme meiltä CGI:ltä, kaksi LTC-Otsosta, kaksi LähiTapiolasta ja Niemisen Jarmo Progressilta. Maanantain aluksi Progressin melko tuore toimitusjohtaja Phil Pead piti alustuspuheenvuoron, jossa lanseerattiin Progressin uusi logo ja ilme. Phil toi hyvin vahvasti esiin sen, että Progress on nyt uudistunut ja pyrkii paremmin kohdistamaan tekemisiään valittuihin tekniikoihin pyrkien niissä johtavaan teknologia-asemaan. Phil myönsi, että Progress oli monta vuotta sivuraiteella eikä kuunnellut asiakkaita tarpeeksi. Nyt ollaan hänen mielestään "back on track". Kuvaavaa oli yhden pitkäaikaisen Progress-työntekijän luonnehdinta, että viimeisen vuoden aikana Progressilla on tapahtunut enemmän kehitystä kuin 10 edellisen vuoden aikana yhteensä. Myös markkinointiin tullaan panostamaan entistä voimakkaammin ja tuomaan Progress paremmin ihmisten tietoisuuteen. Tämä näkyi myös konferenssin järjestelyissä näyttävine ulkomainoksineen. Samalla on uudistettu myös Progress Community -portaali ( Aiemmin kesällä 2013 julkistetun Progress Pacificin merkitys tarkentui myös alustuspuheenvuoroissa. Progress Pacific on Progressin kuvauksissa PaaSratkaisu (Platform as a Service). Käytännössä se vaikuttaa olevan lähinnä markkinoinnillinen "sateenvarjo", jonka alla on mm. OpenEdge, Rollbase (kesällä 2013 tehty hankinta web-sovellusten tekemiseen), DataDirect (integrointiväline) ja Corticon (sääntökoneisto). Myös täysin uusi tuote julkistettiin: Easyl. Sillä voidaan yhdistää eri lähteistä poimittua dataa helposti (tietysti!) ja viedä yhdistetty data esim. Exceltaulukoksi. Mitään demoa aiheesta ei nähty, joten tuotteen käytettävyys ja hyötyarvo jäi kysymysmerkiksi. Toivottavasti tämä ei osoittaudu taas yhdeksi harhapoluksi... Maanantain ja tiistain aikana olleissa tunnin mittaisissa sessioissa oli valinnanvaraa osittain liiaksikin: enimmillään tarjolla oli 14 yhtäaikaista sessiota! Aiheista oli voimakkaasti esillä mm. mobiili/web-kehittäminen ja BPM. Sessiot olivat laadultaan vaihtelevia (sekä sisällön että esittämisen puolesta), joistakin en saanut kovinkaan paljon irti uutta tietoa, mutta oli joukossa hyviäkin esityksiä.