Formålet med dette kapitel er at beskrive en række konkrete programudviklingsmiljøer. Beskrivelsen skal i hvert enkelt tilfælde munde ud i en karakteristik af det pågældende programudviklingsmiljø.

I slutningen af hvert afsnit vil vi sammenholde karakteristikken af det konkrete programudviklingsmiljø med den generelle karakteristik, der blev opstillet i kapitel 2.

Vi har valgt denne fremgangsmåde for at undgå, at den karakteristik, vi opstillede i kapitel 2 skal være styrende for karakteristikken af de enkelte programudviklingsmiljøer. Vores arbejdshypotese er jo netop, at den oprindelige karakteristik ikke er dækkende for f.eks. de visuelle programudviklingsmiljøer, og derfor må vi være åbne overfor eventuelle nye elementer til karakteristikken; men naturligvis kommer vores beskrivelser også til at omhandle forhold, som omtales i karakteristikken.

Vores valg af produkter afspejler til en vis grad, hvad vi i forvejen har kendskab til og interesserer os for; men de er også valgt ud fra et "udbredthedskriterium". Vi har desuden valgt at koncentrere os om produkter, som er velegnede til at fremstille traditionelle, administrative applikationer og applikationer til sagsbehandling.

Vi har valgt to traditionelle programudviklingsmiljøer, og tre visuelle. Ifølge arbejdshypotesen skal taksonomien være dækkende for de traditionelle miljøer, mens den ikke skal være det for de visuelle. I overensstemmelse med vores problemformulering og arbejdshypotese har vi valgt at bruge flest kræfter på de visuelle produkter.

De fem udvalgte produkter er:

• Unix/C++
• Turbo Pascal
• Visual Basic
• Access
• Delphi

I Unix-miljøet er vi-editoren den typiske editor, som bruges til indtastning af programmer og anden tekst. Vi-editoren er en generel editor, som ikke giver programudvikleren nogen støtte i forhold til det konkrete programmeringssprog, der arbejdes med.

Vi-editoren arbejder i et antal tilstande, hvor man i de enkelte tilstande har et antal muligheder. Ofte er betydningen af forskellige kontroltaster afhængig af, hvilken tilstand editoren er i. Det betyder, at editoren af uøvede anses for at være lidt af et mareridt at arbejde med, og man kan med det samme slå fast, at den ikke egner sig som værktøj i hænderne på slutbrugere.

I programmets linie 1 kan man se, hvordan en makro kaldes i et C eller C++ program. Det sker ved kald af et direktiv til compileren: "#include" efterfulgt af navnet på den fil, hvor makroens kildetekst befinder sig.

Figur 3-1. Et C++ program i vi-editoren.

Programudviklingsprocessen fortsætter med forsøget på at oversætte programmet. Det sker i dette tilfælde ved hjælp af C++ oversætter, som kaldes ved at indtaste en kommando med tilhørende parametre til Unix operativsystemet.

Det ligger uden for rammerne af dette speciale at komme nærmere ind på opbygningen af kommandoen og de mere end 100 mulige parametre, som man kan variere kommandoen med. Antallet af muligheder bliver ikke mindre af, at man i Unix/C++ konceptet har indbygget en vis integration mellem de forskellige værktøjer.

Således vil C++ oversætteren normalt automatisk kalde linker programmet, hvis der ikke er nogen alvorlige fejl i oversættelsen. Derfor er det også muligt at medgive oversætteren parametre, som i virkeligheden er bestemt for linkeren, og det øger selvfølgelig kommandoens kompleksitet.

Figur 3-2. Et C++ program er forsøgt oversat.

Resultatet af forsøget på oversættelse fremgår af figur 3-2. Kommandoen "cxx test0006.cxx" er blevet indtastet. Kommandoen fortolkes således:

• Programmet cxx (C++ oversætteren) indlæses
• Filen test0006.cxx, der indeholder C++ programmet, er input til oversætteren

I dette tilfælde er der som bekendt en fejl i programmet, som vi med vilje har introduceret. Oversætteren udskriver derfor en liste over de fundne fejl og afslutter med beskeden "Compilation terminated with errors".

Bemærk i øvrigt, at oversætteren ikke kan identificere den faktiske fejl, som jo består i, at der mangler et "{" i fjerde linie. I stedet rapporteres der om "invalid declaration" i femte linie. Dette er et glimrende eksempel på de udfordringer programmøren er konfronteret med i denne proces, hvor programmets syntaktiske fejl skal findes og rettes. Man kommer meget ofte ud for, at der rapporteres om helt andre fejl, end de fejl, der rent faktisk er.

Dette er bl.a. et udslag af de programmeringsteknikker, man benytter, når man laver oversættere; men det kan vi ikke berøre nærmere, da det er et emne, der ligger uden for rammerne af dette speciale.

Programudviklingsprocessen indebærer nu, at fejlene findes og rettes. Fejlene rettes i kildeteksten, hvilket indebærer, at programmet indlæses i vi-editoren, hvor det editeres. I dette tilfælde er der kun en enkelt fejl; men meget ofte (især i starten af processen) er der flere fejl, der skal rettes. I det traditionelle programudviklingsmiljø forudsætter man, at man forsøger at rette så mange fejl som muligt efter hvert oversættelsesforsøg. Det skyldes det princip, som f.eks. Brooks kalder slow compilation - fast execution [Brooks95]. Jo længere tid oversættelsen tager, jo mere fordelagtigt er det at rette så mange fejl som muligt, inden man oversætter påny.

Efter at fejlen er rettet, prøver vi igen at oversætte programmet. Resultatet af det nye forsøg fremgår af figur 3-3. Tilsyneladende går oversættelsen denne gang bedre. I hvert fald udskrives der ingen liste over fundne fejl.

Figur 3-3. Oversættelsen lykkes, og programmet afprøves.

Da oversættelsen er gået godt, kan vi gå videre til den næste fase - afprøvningen eller testen af om programmet virker efter hensigten. I dette tilfælde kan resultatet aflæses direkte på skærmen, fordi programmet ikke gør andet end at indsætte data i nogle objekter og udskrive disse data på skærmen. Det eneste, som vi i dette tilfælde behøver at holde øje med, er om programmets output svarer til det output, vi havde forventet.

Det færdige program i maskinkode får navnet "a.out". Dette er en defaultværdi, som selvfølgelig kan ændres med en parameter til oversætteren.

I dette afsnit vil vi forsøge at give en samlet karakteristik af Unix/C++ udviklingsmiljøet.

Udviklingsmiljøet må siges at have en lav grad af integration. De tilgængelige værktøjer er fritstående og uensartede i opbygning og anvendelsesmåde. Disse forhold kan ikke opveje den integration, der er etableret mellem oversætter og linker, selv om denne integration er med til at lette opgaven for programudvikleren.

Graden af inkrementalitet har vi vurderet til middel, hvilket for os er det samme som tilfredsstillende. Oversætteren har mulighed for indsættelse af makroer, og der er mulighed for at lave moduler med oversatte programstumper, der senere samles med linkeren. Til gengæld understøtter udviklingsmiljøet ikke et eventuelt behov for inkremental systemudvikling i form af prototyping i systemudviklingsprocessen.

Graden af interaktivitet er lav i Unix/C++ udviklingsmiljøet. Interaktionen kommer alene til udtryk i forbindelse med brug af editoren. Standard editoren (vi) må i sammenligning med editorer fra andre udviklingsmiljøer anses for at være kompliceret at bruge og meget lidt brugervenlig. Det skyldes især de mange tilstande editoren kan være i, og at det samme tastetryk kan have vidt forskellige konsekvenser i de forskellige tilstande.

Det skal dog siges, at erfarne brugere af vi-editoren nærmest tilbeder den; men det hører også med til definitionen af brugervenlighed, at produktet kan bruges af mindre erfarne brugere, og af brugere, som kun lejlighedsvis bruger produktet.

Der er mulighed for at anvende debugger, selv om vi ikke har medtaget et eksempel herpå i vores gennemgang af udviklingsmiljøet.

I den følgende tabel 3-1 har vi forsøgt at opsummere karakteristikken af udviklingsmiljøet. De kriterier, der er medtaget i taksonomien, er dækkende for karakteristikken af Unix/C++ udviklingsmiljøet.

Tabel 3-1. Bedømmelse af Unix/C++ udviklingsmiljøet i forhold til taksonomien.

Dette er en beskrivelse af programudviklingsmiljøet i den tredie version af Turbo Pascal, som blev lanceret omkring 1985. Turbo Pascal var oprindelig et dansk udviklet produkt med navnet Poly Pascal, som blev udviklet af en gruppe programmører, som samtidig var studerende på det daværende Polyteknisk Læreanstalt. I spidsen for denne gruppe programmører stod Anders Hejlsberg.

Da produktet var blevet overtaget af det amerikanske firma Borland International ændredes markedsføringen af produktet på en måde, som blev stærkt medvirkende til, at produktet fik stor udbredelse både blandt hobbyprogrammører og blandt seriøse softwareudviklere. Udviklingsmiljøet var det første af den type udviklingsmiljøer, som vi har kaldt integrerede og simuleret interaktive udviklingsmiljøer.

Udviklingsmiljøet blev udviklet til det hastigt voksende PC-marked, og har, så vidt vi ved, aldrig været forsøgt flyttet til andre softwareplatforme. Det betyder, at programudviklere, der primært har arbejdet i et mainframe eller Unix-miljø, måske aldrig har stiftet bekendtskab med noget lignende.

Det er mere korrekt at karakterisere Turbo Pascal som et udviklingsmiljø fremfor et programmeringssprog. Faktisk har der fra tid til anden været rejst kritik af Turbo Pascal fra mange inkarnerede Pascal programmører. Kritikken har bl.a. gået på, at Turbo Pascal ikke var kompatibel med de versioner af standard Pascal, der bliver brugt på de højere læreanstalter.

Efter vor mening er der tale om polemik uden reelt indhold. En systemudvikler er ligeglad med, om programmeringssproget lever op til en bestemt standard, hvis blot sproget - som i dette tilfælde - indgår i et programudviklingsmiljø, som er effektivt til udvikling af software.

Den følgende figur 3-4 viser det skærmbillede, som programmøren bliver modtaget af, når Turbo Pascal er startet.

Af opstartsmenuen fremgår de muligheder, man har for at vælge værktøj. Man kan ændre drev og stinavn til det område, hvor kildeteksten til ens programmer ligger. Herefter vil den første kommando typisk være angivelse af det program, man ønsker at arbejde med. Navnet på programmet er den Work file, man angiver.

På figur 3-5 har man indtastet et programnavn (BOG000). Programmet kvitterer med meddelelsen "Loading C:\BOGSYS\BOG000.PAS".

Figur 3-5. En workfile er blevet udpeget.

Herefter kan man f.eks. vælge Edit, hvis programmet skal editeres. Figur 3-6 viser editorens udseende. Der er tale om en generel editor med en lille smule hjælp til strukturering af teksten med mulighed for automatisk indrykning af teksten i programblokke.

Figur 3-6. Turbo Pascal i Editor tilstand.

I programeksemplets linie 3, 4 og 5 kan man se, hvordan makroer indarbejdes i Turbo Pascal. Der er tale om et direktiv til compileren. Alle direktiver i Turbo Pascal består af følgende "(*$ *)". Efter tegnet "$" angiver et bogstav, hvilken type direktiv, der er tale om. I dette tilfælde netyder et "I", at det er et Include-direktiv, hvor det efterfølgende filnavn peger på den fil, der indeholder de programlinier, der skal inkluderes i dette program.

Der er introduceret en mindre fejl i programmet i figur 3-6, idet der mangler ordet "BEGIN" i starten af programmet.

Det næste naturlige led i programudviklingen vil være at forsøge at oversætte eller køre programmet; men forinden er det klogt at gemme det rettede program på disk eller diskette, fordi en testkørsel altid vil kunne medføre, at maskinen skal genstartes, hvis programmet kører fast i f.eks. en uendelig løkke.

Man har mulighed for at vælge mellem oversættelse eller afprøvning af programmet. Hvis man vælger oversættelse, får man et oversat program gemt i maskinkode repræsentation på disk eller diskette ud af det. Dette giver noget, der ligner en traditionel situation med slow compile - fast execute.

Hvis man derimod vælger afprøvning gemmes det oversatte program i maskinkode repræsentation i PC'ens hukommelse, hvorfra det eksekveres. Dette giver til gengæld noget, der mere ligner en situation med acceptable compile - fast execute.

Det er denne situation, hvor man tilsyneladende har kombineret fordelene fra det traditionelle programudviklingsmiljø med fordelene fra det integrerede og interaktive programudviklingsmiljø. Den nye opståede situation har vi kaldt det integrerede og simuleret interaktive programudviklingsmiljø (se afsnit 1.5.4).

Figur 3-7. Resultatet af forsøget på at oversætte programmet.

Af figur 3-7 kan man aflæse resultatet af forsøget på at oversætte programmet. Der rapporteres om "Duplicate identifier or label" i linie 1000 (programlinierne i makroerne er medregnet). Man opfordres til at trykke på <ESC> (escape). Hvis man gør det, skiftes til editor tilstand, hvor cursoren er placeret på det sted, hvor oversætteren mener fejlen er.

I dette tilfælde rapporteres fejlen ved det, der skulle have været kaldet af proceduren "BogStart"; men fordi der mangler "BEGIN", tror oversætteren, at man stadig er i gang med at definere variabler og procedurer. "BogStart" er allerede defineret i en af makroerne, og derfor rapporterer oversætteren om et forsøg på at definere duplikater.

Som i eksemplet med Unix/C++ kan man se, at oversætteren ikke kan finde den reelle fejl, når fejlen er, at der mangler noget.

I denne version af Turbo Pascal har man ikke mulighed for at arbejde med inkremental udvikling i form af separat oversatte moduler, som senere lænkes sammen. Denne facilitet blev tilføjet fra og med Turbo Pascal version 4.

Fra og med version 5.5 blev det underliggende Pascal sprog udbygget med objektorienterede faciliteter med det resultat, at det fjernede sig yderligere fra standard Pascal.

Fra og med version 4 har man haft integreret debugger med alle tænkelige hjælpefunktioner integreret i Turbo Pascal. For at give et indtryk af disse muligheder, har vi i figur 3-8 medtaget en oversigt over mulighederne i Turbo Pascal version 6.0.

Figur 3-8. Mulighederne for debugging i Turbo Pascal version 6.

Borlands Turbo Pascal udviklingsmiljø har været et eksempel for mange andre udviklingsmiljøer - først og fremmest i PC-verdenen. I betragtning af den succes, de har haft i PC-verdenen, kan det undre, at man ikke har forsøgt at lancere lignende udviklingsmiljøer på andre maskin platforme som f.eks. i Unix verdenen.

Borland har dog selv udnyttet successen ved at lancere identiske udviklingsmiljøer baseret på andre programmeringssprog som f.eks. C, C++ og Prolog.

Det vil være mest rimeligt at tage udgangspunkt i den seneste version af Turbo Pascal ved opstillingen af denne karakteristik. I forbindelse med selve beskrivelsen har vi derimod valgt at fokusere på en af de tidlige versioner, fordi disse giver et bedre indtryk af den oprindelige idé med et integreret og simuleret interaktivt programudviklingsmiljø.

Graden af integration er høj, især fordi de forskellige værktøjer er integreret med hinanden. Man har opnået en høj grad af integration, uden at det er gået ud over effektiviteten, som sikres med en oversætter i stedet for en fortolker, som ellers kendetegner de integrerede miljøer. De enkelte værktøjer er samtidig ensartet opbygget, således at der er en ensartet brugergrænseflade og ensartethed i brug af funktionstaster og genvejstaster.

Udviklingsmiljøet tillader en høj grad af inkrementalitet i programudviklingen, hvorimod mulighederne for inkrementalitet i systemudviklingen ikke er tilgodeset.

Man kan ikke kalde Turbo Pascal for et velegnet værktøj til prototyping. Det medfører bl.a., at udviklingsmiljøet ikke er særlig velegnet i forbindelse med eksperimentel systemudvikling, ligesom det heller ikke lægger op til brugerdeltagelse i programudviklingsprocessen.

Graden af interaktivitet har vi vurderet til at være høj. Det skyldes, at programmøren er i en stadig dialog med udviklingsmiljøet under hele udviklingsprocessen.

I tabel 3-2 er karakteristikken af Turbo Pascal udviklingsmiljøet opsummeret. Den opstillede taksonomi er dækkende for dette udviklingsmiljø, idet der ikke er tilføjet yderligere kriterier som følge af denne gennemgang.

Tabel 3-2. Bedømmelse af Turbo Pascal udviklingsmiljøet i forhold til taksonomien.

Vi har valgt at beskrive disse to produkter under en samlet hovedoverskrift, idet en del af komponenterne har overordentlig meget til fælles, og vi kan derfor nøjes med at beskrive disse én gang.

Det kan virke noget ensidigt tage fat i hele to MicroSoft-produkter; men det begrunder sig dels i produkternes forskellige systemudviklingsfilosofier, som vi straks skal vende tilbage til, dels i den kendsgerning, at MicroSofts produkter har tilkæmpet sig en helt dominerende plads på software markedet i de senere, hvilket man må anerkende, uanset om man bryder sig om virksomhedens produkter eller ej.

Vores specifikke, summariske produktbeskrivelser starter med Access. I det omfang at tingene fungerer ens, henvises blot hertil i afsnittet om Visual Basic, hvilket er forklaringen på, at dette er noget kortere end afsnittet om Access.

De to produkter kan ved første øjekast minde en hel del om hinanden. Der er tale om udviklingsværktøjer rettet mod Windows brugergrænseflader, og programmeringsdelene baserer sig på Basic-fortolkere.

Visual Basic har brugergrænsefladen som udgangspunkt. Det er den, man starter med at definere. I Access, derimod, begynder man med at beskrive sin database . Produkterne baserer sig således på forskellige systemudviklingsfilosofier, idet Visual Basic nærmest kan betegnes som prototype-agtig, mens Access mere går i retning af en traditionel vandfalds-model, idet det forudsættes, at man har været igennem analyse- og designforløb, før man giver sig til at definere databaser.

Der er for så vidt ikke noget i vejen for, at man anvender andre udviklingsmetoder end dem produkterne lægger op til, det bliver bare meget mere besværligt, og i Access' tilfælde kan det ende katastrofalt, hvad vi siden skal vende tilbage til.

Basic er programmeringssproget for begge produkter, og de programmer, som indgår i applikationerne, er en hel del anderledes end programmer i traditionel forstand. Man kan sige, at den overordnede afvikling af applikationerne er frataget programmørens kontrol, og han er henvist til at gøre sin indflydelse gældende, når prædefinerede hændelser indtræffer.

Disse hændelser er knyttet til alle elementer i brugergrænsefladen, dog således at de mulige hændelser afhænger af elementets type.

I figuren på næste side er vist et eksempel fra Acces med en kodestump til 'click'-hændelsen på en trykknap - én af hele 12 forskellige hændelser.

For hver eneste af disse hændelser har man så mulighed for at lægge programstumper ind, typisk af mindre omfang. Men der kan sagtens være tale om at man hensigtsmæssigt kan lægge større programmer (over 200 kodelinjer) ind - dette vil især kunne være tilfældet for kommandoknapper.

En Visual Basic eller Access applikation, som indeholder store mængder Basic kode kan virke uoverskuelig og kompleks, fordi kode kan ligge og putte sig, hvor man mindst venter det. Omvendt kan man sig, at tingene principielt simplificeres ganske meget ved, at systemets tilstand er entydigt defineret, når enhver kodestump eksekveres. Men på et skærmbillede med mange felter, som hver har over ti hændelser, kan det selvsagt være noget svært for programmøren at holde styr på i hvilken rækkefølge, hændelserne indtræffer.

Kodestumper kan udskrives enkeltvis; men af en eller anden grund har man fravalgt muligheden for at udskrive al kode på én gang.

En nybegynder i Access eller Visual Basic vil uundgåeligt blive forvirret, når vedkommende første gang skal finde rundt i en større applikation, også selv om personen er en erfaren programmør. Det ligger i den grundlæggende anderledes struktur; men det er vores oplevelse at blot en smule erfaring med produkterne løser op for problemet, fordi man hurtigt finder ud af, hvor man skal lede efter de forskellige stumper.

Udviklingen af programmeringssproget Basic fandt sted i 1963 i USA, og dets målgruppe var studerende, som skulle lære at programmere. [Ferdinand96] At sproget overhovedet har kunnet overleve, og i dag endog fremstår stærkere end nogensinde kan virke overraskende; men det er der en række gode grunde til.

Både Visual Basic og Acces er velegnede til programming-in-the-small og hændelsesbaseret programmering. Til den slags mindre og ofte relativt simple programstumper er Basic velegnet.

Det bør endelig nævnes, at MicroSoft nu satser på Basic som programmeringsværktøj i stort set alle PC-produkter, hvor det er muligt (regneark, tekstbehandling, projektstyringsværktøj, etc.). Sproget kaldes VBA (Visual Basic for Applications), og det forventes, at mange andre udbydere vil være mere eller mindre tvunget til at gøre det samme [Mansfield94].

MicroSoft Access, som er den korrekte betegnelse, er et forholdsvis nyt produkt sammenlignet med de fleste andre udbredte databaseprogrammer. Produktet blev introduceret så sent som i slutningen af 1992, og modtagelsen blandt potentielle købere var meget entusiastisk.

Den nuværende version af Access hedder 7.0; men det skyldes, at alle produkter i Office-pakken har samme versionsnummer. Reelt har der kun været to, højest tre, versioner af Access, før den nuværende.

I det efterfølgende vil komponenterne i en Access-applikation blive kortfattet beskrevet. De ledsagende kommentarer stammer fra egne erfaringer med produktet. En applikation udviklet i Access kan bestå af følende komponenter:

• Tabeller (database)
• Forespørgsler
• Formularer (skærmbilleder)
• Rapporter
• Makroer
• Moduler (Basic-procedurer)
• Design guides

Ovennævnte rækkefølge er den samme som i hovedmenuen (minus design guides), og det er vores opfattelse, at udover at signalere en smule kronologi, er det også fra producenternes side en indikation af komponenternes vigtighed. Dette understreger igen Access' manglende egnethed som prototypeværktøj - et aspekt vi senere skal vende tilbage til.

I princippet kan man nøjes med at definere tabellerne, idet der findes standardformater til vedligeholdelse af data; men hvis man ikke har bruge for mere, vil et regneark nok være en mere velegnet løsning.

Set fra brugerens synspunkt er databasen en traditionel, rendyrket relationsdatabase. Man starter med at definere sine felter med type, længde, format, valideringsregler og nøglefelter. Herefter kan tabellerne visuelt forbindes med relationer, og programmet kan (som regel) selv finde ud af, hvorledes relationen (1:m) vender.

Figur 3-10. Eksempel på visuel repræsentation af databasestruktur i Access

Der sker imidlertid ting bag om ryggen på brugeren, hvilket man finder ud af, når man dykker ned i programmeringsdelen. Acces tilføjer sin egen primære nøgle, baseret på løbenummer, på trods af at duplicate keys er forbudt for de brugerdefinerede nøgler. Det betyder, at hvis man læser en tabel sekventielt i en Basic-procdure, får man records i den rækkefølge, de er blevet oprettet, og ikke i stigende primærnøgle orden.

Tabelindhold og relationer kan ændres 'flyvende', dvs. også i databaser, som allerede indeholder data. Her er Access imidlertid ikke særlig pålidelig, idet det ofte ses, at kraftigt redigerede databaser, som ser rigtige ud, faktisk er så 'beskadigede', at man hele tiden får uforklarlige fejlmeddelelser og i sidste ende bliver nødt til at starte helt forfra med tabeldefinition! Dette kedelige fænomen understreger, at Access ikke er noget særlig godt prototypeværktøj, med mindre man nøjes med at indtaste få data og hele tiden er forberedt på at starte forfra.

Formularer er Access-applikationens brugergrænseflade, og hver enkelt formular baserer sig på en tabel eller en forespørgsel. Skærmbilleder kan tegnes ved at trække attributter ind fra de udvalgte elementer, og man kan tilføje alle de velkendte Windows-elementer (listefelt, comboboks, rullepanel etc.). Antallet af kontroller kan virke overvældende stort; men eftersom man kan vælge at forlade sig på standardindstillinger, og ikke behøver eksplicit at tage stilling til hver enkelt, behøver det ikke at blive et større problem.

Ønsker man flere forekomster af en tabel vist på et skærmbillede (fx en ordre med et antal ordrelinjer) kan man anvende underformularer. Skærmbilleddefinitioner i Access giver ikke anledning til mange kommentarer i øvrigt. Det foregår i et brugervenlig og fleksibelt miljø.

For hver attribut på en formular er der defineret et antal hændelser, afhængig af datatypen, og for hver af disse hændelser kan man programmere funktionalitet, også kaldet hændelsesprocedurer, i Basic.

Rapportdelen er helt traditionel i forhold til de mest anvendte 4. generationsværktøjer. Man kan udvælge felter fra tabeller og forespørgsler, og sortere og redigere sine data, som man har lyst. Det hele foregår i visuelle omgivelser, og der kan udarbejdes rapporter til såvel printer som skærm.

Makro-faciliteten i Access er veludviklet og forholdsvis brugervenlig. Som i alle andre miljøer, hvor makroer kan anvendes, gælder det, at det tager tid at komme i gang og at anvendelsen skal være betydelig, for at udbyttet står mål med anstrengelserne.

Procedurer er beregnet til vedligeholdelse og aftestning af procedurer og funktioner kodet i Basic. Især det såkaldte brugerudtryksvindue er særdeles anvendeligt, idet det tillader brugeren en hurtig, effektiv og gennemskuelig aftestning af de kodede procedurer. Denne facilitet, som i den nyeste version kaldes for fejlfinding, er sammen med en række andre, enkeltstående faciliteter Acces' bud på en debugger. Som omtal andetsteds er Basic en fortolker; men det er dog muligt at få checket/compileret sine kode inden eksekvering.

Som de fleste andre MicroSoft produkter har Access veletablerede forbindelser til mange andre produkter ved hjælp af standardprotokoller som DDE og OLE. Det er endvidere forholdsvis nemt at konvertere databaser fra andre produkter (Paradox, dBaseV, m.fl.). Dog skal tabellerne konverteres enkeltvis, og relationerne etableres efterfølgende.

Access tilbyder brugeren en række såkaldte 'design guides' i forskellige situationer blandt andet i forbindelse med oprettelse af forespørgsler. Fænomenet er at sammenligne med, hvad i andre sammenhænge kaldes 'application wizards', og er en slags guided tour, hvorved man lynhurtigt kan få udført sit forehavende. Problemet med den slags værktøjer (og formentlig årsagen til at det anses for 'mindre fint' at bruge dem) er, at man risikerer at fravælge ønskværdige muligheder, og at man til en vis grad mister kontrollen. I nogle situationer kan det anbefales at anvende design guides i Access, i andre kan det bestemt ikke; men at træffe det rigtige valg er naturligvis vanskeligt for den uerfarne bruger.

Den nyeste version af Visual Basic hedder 5.0. Det meste materiale, som vi har kunnet finde, har vedrørt tidligere versioner; men vi har ikke opfattet det som et problem at lave vores vurdering på en lidt ældre version. Dels er det vores helt klare fornemmelse, at produktet ikke har ændret substans siden version 3.0, dels er nye versioner af softwareprodukter ikke nødvendigvis bedre end de gamle.

I det følgende vil elementerne i MicroSoft Visual Basic blive kortfattet beskrevet. De ledsagende kommentarer stammer primært fra egne erfaringer med produktet. Vi har valgt at basere vores beskrivelse på følgende elementer:

• Designform
• Modul
• Projekt
• Database
• Debugger

At designform står først er ingen tilfældighed. Når man går ind i Visual Basic, er en tom designformular nemlig det første, man præsenteres for, hvilket må ses som et tegn på, hvorledes producenten vurderer vigtigheden af komponenten.

Til sammenligning kan det nævnes, at database funktionen er gemt som nederste funktion i sidste menupunkt før 'Hjælp'.

Værktøjskassen i designformularen er temmelig stor, og indeholder således væsentlig flere valgmuligheder end tilsvarende i Access: men ellers er princippet nøjagtig det samme. Man tegner sit skærmbillede i et brugervenligt, visuelt miljø og kan definere hændelsesprocedurer efter samme grundprincip som i Access.

I designformularen kan man åbne et vindue, hvorved man får mulighed for at bladre i koden af hændelsesprocedurer, hvilket er en såre nyttig facilitet, hvis man ønsker et hurtigt overblik over hvilken kode, der er knyttet til en bestemt formular. Vi har ikke kunnet finde noget tilsvarende i Access.

Projekter i Visual Basic svarer til, hvad der blev kaldt en database i Access, og vil i alle andre sammenhænge blive kaldt for applikationer. Denne anvendelse af begreber, som man tror, man ved hvad betyder, men som så alligevel betyder noget andet, kan godt være lidt irriterende, og det gælder begge produkter.

Moduler svarer fuldstændig til det tilsvarende begreb i Access og vil derfor ikke blive beskrevet yderligere.

Databasedelen i Visual Basic er blot et interface til den tilsvarende funktion i Access og for at kunne benytte denne, er det således et krav at have Access installeret. Der henvises i øvrigt til afsnittet om Access.

I modsætning til Access har Visual Basic en egentlig debugger. Den indeholder en ret stor værktøjskasse af muligheder for assistance ved fejlfinding: muligheder for tracing, etablering af forskellige former for breaks med meget mere. En ganske nyttig facilitet giver brugeren mulighed for at definere tilstande, hvorunder programmet skal afbrydes og vise, hvor man er kommet til. Derudover giver 'Help' en ganske fornuftig indføring i, hvordan man finder fejl i sine programmer.

Figur 3.12 Eksempel på opsætningsmuligheder til et skærmbillede i Visual Basic. Hele 44 parametre kan brugeren skrue på; men man kan naturligvis også vælge at forlade sig på standardindstillingerne.

Tabel 3-3. Bedømmelse af Access udviklingsmiljøet i forhold til taksonomien.

Editoren, som den fremtræder i Access, er ikke dækket af den traditionelle taksonomi, hvilket skyldes at programobjekter fremtæder i flere forskellige former. Disse forskellige former eller komponenter tyder også på udvidelser i bregrebsapparatet vedrørende inkrementalitet.

I antal af repræsentationer har vi skrevet 'få'; men set ud fra antallet af former for repræsentationer skulle svaret have været 'mange'. Taksonomien mangler altså den dimension, at programelementer kan have mange forskellige former, selv om hvert element kun er repræsenteret én gang.

Beskrivelsen af værktøjer er ikke længere dækkende. Et eksempel på en helt ny type af værktøjer er design guides.

Interaktivitet opfattes traditionelt som et mellemværende mellem programmør og miljø. Begrebet bør udvides til også at omfatte kommunikation mellem miljø og bruger med hensyn til definitioner af brugergrænseflader.

Nedenstående bemærkninger vedrører kun forhold, hvor Visual Basic adskiller sig fra Access. Hvor elementer i taksonomien er udeladt, henvises tilforegående afsnit.

Tabel 3-4. Bedømmelse af Visual Basic udviklingsmiljøet i forhold til taksonomien.

Væsentlige forhold, som ikke dækkes af taksonomi: som i Access

Figur 3-13. Opstartsbilledet i Delphi version 3.

Allerede når man betragter opstartsbilledet, bliver det klart, at der er tale om noget andet end et traditionelt programudviklingsmiljø. Udviklingsmiljøet præsenterer sig umiddelbart med fire vinduer.

Øverst er anbragt et vindue, der indeholder en menubjælke samt en række genvejsknapper til de mest benyttede kommandoer. Til højre findes komponent paletten, som er et af de vigtigste værktøjer, når man udvikler programmer med Delphi.

Til venstre findes Object Inspectoren, som er en editor, hvormed man dels kan redigere i et objekts egenskaber, og dels kan få overblik over de hændelser (events), der er relevante for det pågældende objekt.

Til højre ses Forms editoren og under den kan man lige se kode editoren. Ved hjælp af forskellige funktionstaster kan man skifte frem og tilbage imellem de forskellige editorer.

De her nævnte tre editorer er kun en lille del af de mange forskellige specialiserede editorer, der er integreret i Delphi. De gemmer sig bl.a. under menupunkterne Project, Component, Database og Tools.

I det følgende afsnit vil vi prøve at beskrive, hvordan et typisk programudviklingsforløb i Delphi kan være udformet.

Udviklingen af et nyt program i Delphi starter typisk med en tom form i Forms editoren, sådan som det fremgår af figur 3-13. Hvis der skal arbejdes med data i en database, vil man typisk starte med at definere denne database.

Delphi adskiller sig fra andre programudviklingsmiljøer ved at have indbygget editorer til definition af databaser. Man kan endda arbejde med flere forskellige af de mest populære databasesystemer samtidigt.

Når databasen er defineret, kan man begynde at opbygge skærmbilledet, som man ønsker det skal se ud. Det gør man ved at vælge komponenter fra komponent paletten, og trække dem ned på formen i Forms editoren. Figur 3-14 viser en situation, hvor man har opbygget et skærmbillede til håndtering af en database med telefonnumre.

 Figur 3-14. Skærmbilledet til telefon applikationen.

Hver eneste komponent på skærmbilledet bliver til et objekt i det færdige program; men udviklingsmiljøet tager sig af det grove arbejde med at initiere objektets egenskaber. Programmørens opgave består efterfølgende i at tilpasse de enkelte objekters egenskaber med de værdier, som udviklingsmiljøet ikke kan gætte sig frem til.

Vi vil i det næste eksempel se på, hvordan man tilpasser en gruppe med radioknapper, så der er det ønskede antal svarmuligheder. Man starter med at pege på det objekt, hvis egenskaber man vil ændre. Når man peger på et objekt skifter Object Inspectoren udseende, så den viser det aktuelle objekts egenskaber. Object Inspectorens indhold er vist i figur 3-15.

Figur 3-15. Med Object Inspector kigger vi på en gruppe med radioknapper.

Øverst oppe i Object Inspectoren ser man navnet på det valgte objekt (det står også i egenskaben Name). Man kan vælge, hvilket objekt man vil behandle, ved at vælge et objekt på den tilhørende drop-down liste, hvor alle formens objekter er listet.

Under navnet er alle egenskaberne listet i alfabetisk orden. Foran nogle navne er der et lille plus, hvilket betyder, at der gemmer sig en hel liste af egenskaber herunder. Dette er f.eks. tilfældet for egenskaben Font, som i sig selv er et objekt med sine egne egenskaber. Man kan få adgang til disse egenskaber ved at trykke på plus tegnet.

Den egenskab vi er interesseret i er Items. Her ser man i værdifeltet teksten "(Tstrings)" og yderst til højre tre små prikker. Det betyder, at dette felt skal editeres med en speciel editor, som f.eks. aktiveres ved klik på prikkerne.

Figur 3-16 viser udseendet af denne editor. Man indtaster ganske enkelt de tekster, som man ønsker skal stå ud for de enkelte radioknapper. Komponenten sørger selv for at sætte det fornødne antal radioknapper op i layoutet.

Dette er det typiske billede overalt i udviklingsværktøjet. Man forsøger at løse problemerne ved hjælp af små stærkt integrerede hjælpeværktøjer i stedet for at overlade det til programmøren at forsøge at kode sig ud af problemerne.

På figur 3-14 bemærker man, at der er data i felterne. Dette er ikke tilfældige data, der er indtastet; men derimod de rigtige data hentet i databasen. Der er altså på designtidspunktet adgang til databasens data. Dette er en stor hjælp i tilfælde af, at man skal lave en hurtig prototype. Et skærmbillede med rigtige data fra databasen gør altid større indtryk ved en demonstration end konstruerede data. Endelig kan man sige, at der åbner der sig nogle nye perspektiver for systemudviklingsprocessen, fordi det nu er realistisk at lave systemudvikling med regulær brugerdeltagelse i selve programmeringsprocessen.

Figur 3-16. Editering af teksten på linierne i radiogruppen.

Som programmør vil man måske spørge, hvor koden er henne? Svaret er, at den trivielle kode bliver automatisk indsat og vedligeholdt i kode editoren af udviklingssystemet.

Figur 3-17. Kodning af eventhandler.

Der er dog stadig opgaver for programmøren. Hvad skal der f.eks. ske, når man trykker på den radioknap, der står "telefonnumre" ud for. Man må forvente, at knappen skal skifte udseende, så der kommer en sort prik i den. Samtidig skal den knap, der står "navne" ud for skifte udseende, så prikken her forsvinder.

For at få dette til at ske, skal man skrive en såkaldt event-handler. En event er en hændelse - hændelsen er i dette tilfælde tryk på musens knap mens pilen peger på radioknappen. Vi kan initiere event-handleren ved at dobbelt-klikke på radioknappen. Der åbnes et vindue med kode editoren og cursoren anbragt mellem begin og end i den relevante event-handler. I figur 3-17 har vi rullet teksten ned, så man også kan se event-handlerne for begge radioknapper. Som det ses aktiverer henholdsvis deaktiverer man radioknappen ved at ændre værdien i egenskaben Checked til True eller False.

Man kan straks afprøve, om den indtastede kode virkelig skulle have den ønskede effekt. Det gøres ved at aktivere punktet Run i menuen.

I nedenstående tabel 3-4 har vi opsummeret vores karakteristik af Delphis programudviklingsmiljø i forhold til den taksonomi, der blev opstillet i slutningen af kapitel 2. Som det vil fremgå af vores efterfølgende kommentarer, er vi af den opfattelse, at taksonomien langt fra er rig nok til at kunne bruges som bedømmelsesgrundlag for et visuelt programudviklingsværktøj som Delphi.

Tabel 3-5. Bedømmelse af Delphi udviklingsmiljøet i forhold til taksonomien.

Delphi og flere andre lignende programudviklingsmiljøer er tilsyneladende ved at omdefinere rollerne i forbindelse med systemudvikling. Værktøjet er visuelt; men hermed menes især opbygningen af brugergrænsefladen til det kommende program samt de ikoner, der designes til knapper og andre kontrolkomponenter. Her er et nyt kriterium, idet grafiske editorer af denne type ikke uden videre kan indplaceres i den taksonomi over editorer, som vi opstillede i kapitel 2.

Ydermere ser vi i dette produkt, at begrebet integration får en ny dimension. Hidtil har vi talt om, at værktøjerne var integreret med hinanden; men nu kan vi også tale om, at værktøjerne er integreret i hinanden. Her tænkes f.eks. på eksemplet, hvor man under editering af en egenskab i Object Inspector (det første værktøj) aktiverer en editor (det andet værktøj) til den specielle editering af det pågældende felt.

Integrationen af databaseværktøjerne direkte i prigramudviklingsmiljøet er heller ikke set tidligere i denne type programudviklingsmiljøer. Det findes i såkaldte fjerde generations udviklingsmiljøer; men i så fald er det altid ét konkret databasesystem koblet sammen med et sprog, som er designet til formålet. Her er der tale om integration af mange forskellige databasesystemer fra flere forskellige producenter.

Prisen for den høje grad af integration er et stort antal repræsentationer. Udover selve koden og de repræsentationer, der følger af kodens oversættelse til maskinkode, er der også repræsentationer af de visuelle data i forbindelse med designet af skærmbilleder, ikoner osv. En afledt effekt af de mange repræsentationer er, at man nemt kommer til at mangle dokumentation af det færdige program. Der er meget af programmørens arbejde, som bliver omsat til repræsentationer, som det er meget vanskeligt at lave en pæn udskrift af.

Værktøjet tillader en høj grad af inkrementalitet både i programudviklingsprocessen og i hele systemudviklingsprocessen. Udover makroer og moduler har man også mulighed for at bygge komponenter, som er en udbygning af begrebet objektklasse.

Værktøjet nærmest forudsætter en høj grad af interaktivitet. Graden af interaktivitet øges yderligere, fordi værktøjet giver systemudviklere og brugere mulighed for at mødes med programudviklingsmiljøet som det fælles værktøj. Brugerdeltagelse i selve programudviklingsprocessen er derfor en oplagt mulighed med dette værktøj.

Vores erfaringer fra arbejdet med Delphi er, at selv om udviklingsmiljøet bygger på et objektorienteret programmeringssprog, så spiller det ingen rolle i forhold til programudviklingen. Programmøren koncenterer sin indsats om kodningen af event-handlere, som hver for sig løser et lille delproblem i forhold til den samlede løsning. Programmøren behøver ikke være bevidst om, at hver event-handler kommer til at udgøre en metode i en objektklasse, ligesom programmøren heller ikke er bevidst om, at den form, som han er ved at opbygge, er identisk med en objektklasse, og at de enkelte komponenter i skærmbilledet tilføjes som attributter i denne objektklasse.

I Delphi er der integreret nye typer af editorer, som kan afbilde strukturer grafisk (visuelt). Denne type editorer er ikke i sig selv nye, idet man har brugt dem i forbindelse med CASE værktøjer og tegneprogrammer; men det er nyt, at de bliver integreret i et egentligt programudviklingsmiljø.

Forståelsen af inkrementalitet fra kapitel 2 må udvides, så den udover makroer og moduler også omfatter komponentbegrebet i de visuelle programudviklingsmiljøer. Delphi programudviklingsmiljøet har allerede ført til et verdensomspændende marked, hvor programmører via internettet distribuerer genbrugelige komponenter.

Forståelsen af begrebet integration må ligeledes udvides, fordi værktøjerne nu via objekterne bliver integreret i hinanden, og ikke kun med hinanden. Hvis man f.eks. klikker på menu-komponenten i skærmbilledet, åbnes en særlig menu-editor. Tilsvarende åbnes ved klik på tabel komponenten en editor, hvor man kan tilføje og fjerne links mellem databasens attributter og de tilsvarende felter på skærmen. Der er tale om en hidtil uset stærk integration, som ikke lader sig beskrive med den kendte taksonomi.

Som det blev nævnt tidligere, spiller det i praksis ingen rolle, om det sprog, man baserer programudviklingsmiljøet på, er objektorienteret eller proceduralt. Det er vores erfaring fra praksis, at det er forbundet med betydelige vanskeligheder at udnytte det forhold, at sproget er objektorienteret.

Det fører til overvejelser om, hvorvidt man kan tale om en ny grundfilosofi indenfor systemudvikling - en grundfilosofi, som vi kan kalde visuel systemudvikling. I kapitel 4 vil vi komme med vort bud på en sådan visuel systemudviklingsfilosofi.