Pek og klikk

---

Visuelle utviklingsverktøy for Windows spiser seg innover områder du tidligere bare nådde med C-programmering. Men planlegg før du bruker Windows-verktøy til bedriftsomfattende systemer.

---

Applikasjonutvikling betyr i stadig større grad det samme som Windows-utvikling, og de visuelle utviklingsverktøyenes popularitet har vokst i takt med Windows. Disse verktøyene lager nydelige vindusgrensesnitt. Og deres raske utviklingssykluser, samt det at de er lettlærte, gjør de velegnet for mange typer PC-utvikling. Sammen med det store utvalget av rimelige, kraftige PCer gir disse verktøyene utviklerne en brekkstang for et skifte i "maktbalansen" til fordel for skrivebordmaskinene.

Utviklingen går ugjenkallelig i retning av Windows og andre grafiske brukegrensesnitt, og utviklerne kan velge mellom en drøss av visuelt orienterte verktøy. Til de mest populære hører Microsofts Visual Basic, Powersofts Powerbuilder, Gupta Technologys SQL Windows, Dataease 5.0, Blyth Softwares Omnis 7, Computer Associates Internationals CA-Visual Objects, Sterling Softwares Key Objectview og Borland Internationals Delphi.

Og det finnes mange flere. Det disse verktøyene har til felles er en PC-arkitektur og at de er visuelt orientert, hvilket innebærer at utviklingsprosessen for en stor del skjer gjennom peking og klikking med mus, og ikke prosedyre-orientert koding. Hvert produkt inneholder et sett elementer som er typiske for brukergrensesnitt, f.eks. inntastingsfelter, knapper og ruter, samt en metode for kopling av disse elementene til koder.

Artitekturen er ofte lik: Visuelle utviklingsverktøy er utformet med tanke på selvstendige Windows-applikasjoner eller klientsiden i klient/tjener-applikasjoner.

Fete programmer

Borlands nye Delphi-produkter utnytter denne trenden ved å kompilere raske, tette eksekverbare programmer, ifølge Chet Geschickter, visepresident og forskningssjef ved Hurwitz Consulting.

-- Resultatet er at det går mye raskere, ettersom de store run-time eksekverbare programmene ikke lenger står i veien, mener Geschickter.

Muligheten til å gjøre mer på PCen, endrer dynamikken i applikasjonsutvikling, fordi det er mulig å lage relativt enkle applikasjoner som utfører oppgaver som er kompliserte rent databehandlingsteknisk, samtidig som disse applikasjonene kan legges inn på rimelige datamaskiner.

-- I bedriftssammenheng var man tidligere nødt til å bruke heterogene nettverk av stormaskiner og mellomstore computere, rett og slett fordi disse var de viktigste arbeidshestene, bemerker Jon Roskill, Microsofts forretningssjef Visual Basic, og tilføyer: -- Dagens mikroprosessorer kan takle stadig mer krevende applikasjoner, og mange bedrifter har nå opprettet PC-baserte arbeidsgrupper som dekker hele kloden.

Dette skiftet i "maktbalansen", til fordel for skrivebordsmaskinen, bidrar selvsagt til å øke behovet for visuelle verktøy. Microsoft har allerede solgt én million eksemplarer av Visual Basic. Målet er to millioner innen et par år, og Microsoft har nokså håndfaste planer om "infiltrere" forretningsmiljøer med basis i Visual Basic-motoren arbeidsgruppe-applikasjoner.

Ifølge Roskill vil Microsoft bygge språkkomponenten i Visual Basic, kjent som Visual Basic Application Engine, i Microsoft Excel, Microsoft Project, SQL Server 95 og and Microsoft Access,.

Etterspørselen etter andre visuelle utviklingsverktøy har også økt. Powersoft får mye skryt for sine "dra-og-slipp" grensesnittbyggere, skjermtegnemodulen og sluttbruker-orientert SQL-grensesnitt. Gupta har det tettest koplede skjema-til-database-miljøet, og Sterling har integrerert Key Objectview-familien med CASE og repository. Samlet har disse verktøyene nådd kritisk masse.

Tett kode

Det som gjør Delphi unikt er kombinasjonen av kompilert ytelse og tolket kode, sier Geschickter. Dessuten genererer den eksekverbare Intel-koder istedenfor de tregere, tolkede koden som de fleste andre verktøy i denne klassen produserer.

-- På prototype-stadiet kan du se hva som er i gang og raskt knytte den til et binært eksekverbart program. Delphi tillater uviklere en myk overgang fra prototype til produksjon med ett og samme verktøy. Det er en meget sterk sterk kapasitet, mener Geschickter.

Kritikere har pekt på at det nye Borland-verktøyet er basert på Pascal, som ikke er noe spesielt populært språk uansett hvordan man ser på det, og at dette vil gi produktet en lunken mottakelse. Geschickter er ikke enig.

- Hvis du for tre år siden hadde fortalt oss at Basic ville bli et strategisk språk for PC, hadde vi neppe trodd deg, sier han og tilføyer: -- Men idag vet vi bedre. Ethvert nytt utviklingsmiljø bærer med seg noen nytt som må læres. Om det er et nytt språk spiller vel liten rolle, hvis dette språket skal brukes om og om igjen?

Etter markedslitteraturen å dømme skulle man tro at alle visuelle utviklingverktøy er objektorienterte. Men det som går for å være objektteknologi i mange produkter, er gjerne bare en fremgangsmåte for å lage visuelle skjermobjekter som arver egenskapene til andre skjermobjekter. Selv om alle leverandørene bruker objektterminologi, er det svært varierende i hvilken grad de faktisk implementerer objektparadigmet.

Visual Basic tilbyr "pek-og-klikk"-utvikling med bruk av mus, lister og grafiske skjermelementer. Men kjernen i applikasjonen -- nøkkelfunksjonen -- er beskrevet ved bruk av et prosedyreorientert språk.

Delphi er helt og holdent objektorientert, og støtter objektorientert programmering av nøkkelfunksjonen med Object Pascal. Ulempen er at det kreves objekt-eksperter for å bygge nye komponenter. Som med alle objektverktøy, tar det litt tid å forstå metodikken og komme ajour.

Men dette har ikke vært noe problem ved First National Bank of Chicago, sier Art Hill, visepresident i bankens avdeling for kontantstyringssystemer:

-- Det er godt å ha et par objekt-guruer på laget med tanke på utvikling av nye komponenter og til å skrive bedriftsobjekter. Men de fleste utviklere kan gjøre god nytte av komponentene som leveres av Borland og forskjellige tredjeparter. Alt det enkle, som knapper og redigeringskontroll, er tilgjengelig rett ut av boksen, og du kan lage mange applikasjoner uten egentlig å kjenne selve objektteknologien.

Begrensninger

Delphi og de andre PC-aktørene vinner en knockout-seier med sin Windows-kompatibilitet, ettersom de kan by på en overlegen integrering av PC-applikasjoner ved hjelp av standard grensesnitt som DDE og OLE. Men det er et godt stykke fra disse PC-utviklingsverktøyenes klient-sentrerte verden til virkelig bedriftskapasitet -- uansett hvordan Microsoft definerer dette begrepet.

-- Visuelle utviklingsverktøy har dratt fordel av relasjonsdatabase-teknologien og PCens grafiske brukergrensesnitt, bemerker Geschickter og fortsetter: -- Med en gang du går utover deres kommunikasjonsdrivere for relasjonsdatabase og SQL, er du nede på C-nivå. Er det en dårlig dag, kan de kalles SQL-knusere. På en god dag er det database-utviklingsverktøy.

Utviklingsverktøy for bedrifter, derimot, som Seer Technologies' High Productivity-systemer og Andersen Consultings Foundation for Cooperative Processing, kan ikke lokke med alle de brukervennlige grensesnittene og andre fasliteter, men byr derimot på en rekke verdifulle ting når det gjelder infrastruktur: kommunikasjonsmodeller for mellomprogrammer, multilags applikasjonsarkitekturer, full livsyklus CASE og kompilering som kan generere koder for en rekke plattformer, fra stormaskin til PC.

Microsofts bedriftssyn avspeiler likevel den gjeldende trenden. Mye av den avanserte informasjons-infrastrukturen blir foreldet i og med at dagens Pentiumer, Power-PCer og andre ledende prosessorer utvider perspektivene for hva det er mulig å gjøre med en PC. Store selskaper beveger seg gradvis bort fra stormaskinen. Og ny utvikling er, som nevnt, for en stor del Windows-utvikling.

Det er ikke lett å forutsi hvor dette vil ende. Men så lenge skrivebordsmaskinene spretter opp som paddehatter og PC-teknologien får kapasitet for stadig større IT-oppgaver, vil utviklingsverktøyene på arbeidsgruppenivå spille en viktigere og viktigere rolle.

Er du objektorientert?

---

Objektteknologien er i fare. Om vi ikke er på vakt, står vi i fare for å miste det viktigste fremskrittet i programvareteknologien siden subrutinen ble oppfunnet.

---

Attpåtil kan objektteknologien gi overraskende bedriftsmessige fordeler. Ved å modellere organisasjonen ved hjelp av objekter, kan bedriftene oppdage nye måter å forenkle sin drift på. De kan redusere omløpstid, kutte ned på sløsing og tilegne seg en rekke andre konkurransefortrinn.

Hvorfor er da objektteknologien i fare? Faren ligger i at de fleste av de produktene som påstås å være objektorientert egentlig ikke er det. At et program er utstyrt med ikoner, komponenter eller koplinger betyr ikke at det er objektorientert. Disse produktene lover mer enn de holder.

Enda verre er det at forbukerne nå har blitt så til de grader forvirret med hensyn til hva objektteknologi egentlig innebærer, at de vanskelig kan vite om de virkelig har fått det de er ute etter.

La oss derfor gå tilbake til utgangspunktet og definere hva det er som gjør et produkt objektorientert. Et system er objektorientert bare dersom og hvis det støtter tre nøkkelmekanismer: innkapsling, polymorfisme og arv. På godt "norsk" betyr det følgende:

1. relaterte data og prosedyrer er pakket sammen inne i objekter;

2. forskjellige objekter kan implementere samme prosedyre på forskjellige måter;

3. objekter kan defineres som særlige varianter av hverandre.

Hvorfor bry seg om hvordan objekter er definert? Fordi man er avhengig av alle de tre mekanismene for at totalfordelen ved objektteknologi kommer for en dag. Det er altså ikke snakk om abstrakte ideer "objektpurisme" uten reelll betydning, men om fundamentale byggesteiner i selskapenes oppbygning og drift.

Ta for eksempel det forferdelige greske ordet "polymorfisme", som egentlig bare betyr at du setter et enkelt navn på en generisk oppgave og lar hvert objekt utføre denne oppgaven på sin måte. Dersom en økonomisjef ber de forskjellige gruppene i et selskap om å utarbeide inntekts- og utgiftsprojeksjoner, vil vedkommende kunne sende alle gruppene den samme forespørselen, hvorpå de svarer etter egne internprosedyrer. Økonomisjefen trenger da ikke å foreta en ny oppgavefordeling til hver gruppe for å få dem til å gjøre forskjellige ting. Det er likevel på denne måten programvaren må designes i systemer som ikke støtter polymorfisme.

Likeledes avspeiler kapasiteten til å definere objekter i et type-hierarki organiseringen i arbeidslivet. Vi bruker grunnleggende erkjennelsesprosesser, generalisering og kategorisering, for å organiserere produkter, kunder og annet i spesifikke enheter. På denne måten kan vi forstå og kommunisere det som er generisk for alle kunder og produkter, og samtidig skille mellom de spesialiserte formene. Når programvaren inneholder en arve-mekanisme, kan denne forståelsen uttrykkes direkte i systemdesignet. Dersom denne mekanismen mangler, har vi ikke den muligheten.

Microsofts egne proprietære arkitektur, Common Object Model (COM), vil føre til mye forvirring om hva objektteknologi er og hvilken verdi den har. Navnet bedrar, for COM er ikke objektorientert. Arkitekturen støtter bare en svak form for innkapsling, og mangler helt støtte for polymorfisme eller arv.

Det betyr ikke at COM er en dårlig teknologi. Den er faktisk ganske tilstrekkelig til det den er beregnet for, nemlig bygging av programvare-komponenter. Men programvarekomponenter utgjør bare en liten del av en helhetlig bedriftsløsning. Viktigst er det at disse komponentene ikke kan støtte den sofistikerte modellbyggingen som objektteknologien muliggjør.

Når man er vant med virkelige objekter, er det fryktelig slitsomt å være uten. Prøv for eksempel å få Visual Basics "objekter" til å oppføre seg på en objektorientert måte. Bare det å sende meldinger vil by på problemer -- Visual Basic-objektene kan nemlig ikke snakke med hverandre engang. De kan innstille hverandres variabler, noe som generelt anses som et brudd på innkapslingsmekanismen, men de kan ikke kalle opp hverandres prosedyrer.

Microsofts tekniske støttefolk hevdet at måten jeg kunne oppnå dette på, var å opprette en usynlig knapp for hver enkelte melding som skulle sendes til et objekt, for så å få avsenderen til å innstille verdien for denne knappen på "true" når meldingen skal sendes. Dermed lures den usynlige knappen til å tro at en bruker liksom har klikket på den og satt igang en intern prosedyre. Akkurat.

Likevel var dette problemet barnemat sammenliknet med å finne ut hvordan man skal simulere arv.

Microsoft snakker varmt om en teknikk de kaller aggregering, som et alternativ til arv. Men denne teknikken gjør akkurat det motsatte av det du er ute etter -- den ekskverer prosedyrer i feil objekter. Og det holder bare ikke.

Kort sagt: hvis du ønsker å blande og tilpasse programvarekomponenter på PCen, er COM "objektene" helt utmerket. Trenger du totalfordelen av objektteknologi, må du nødvendigvis bruke objekter som er kompatible med Object Management Group.

Artikkel automatisk generert, 30/05-95, kl. 15.59 cw@oslonett.no