Figur 1-1. Samspillet mellem systemudvikling, programudvikling og hardware.
Siden starten af 1990'erne har en række visuelle programudviklingsværktøjer set dagens lys. Disse værktøjer er mest udbredt i Windows miljøet i PC-verdenen; men der findes også visuelle udviklingsværktøjer til andre platforme som f.eks. Unix.
På basis af vort forudgående praktiske kendskab til nogle af disse visuelle værktøjer til Windows miljøet er vi af den opfattelse, at den traditionelle taksonomi [En traditionel taksonomi er et sæt alment anerkendte retningslinjer, hvorefter et fænomen kan bedømmes med hensyn til indhold og kvalitet. Mere herom i indledningen til kapitel 2] for programudviklingsmiljøer ikke er tilstrækkelig til at beskrive de visuelle værktøjer.
Formålet med denne opgave er derfor at udforske nogle af de mest udbredte visuelle værktøjer med henblik på opstilling af en taksonomi, som også er dækkende for de visuelle værktøjer.
Der opstilles en taksonomi for programudviklingsmiljøer, som afspejler, hvordan disse normalt behandles i litteraturen for så vidt angår indholdet af programudviklingsmiljøer. Vigtigheden af værktøjer og egenskaber beskrives med udganspunkt i egne erfaringer og holdninger til kilderne.
Derefter udforskes og afprøves en række traditionelle og visuelle programudviklingsmiljøer med henblik på at finde ud af, om den tidligere beskrevne taksonomi for programudviklingsmiljøer også er dækkende for de visuelle miljøer. Arbejdshypotesen er, at taksonomien ikke er dækkende.
Endelig opstilles en taksonomi som er dækkende for de visuelle programudviklingsmiljøer.
I kapitel 1 vil vi give et historisk rids af programudviklingsmiljøet, inden vi i kapitel 2 går over til at beskrive elementerne og begreberne mere detaljeret og opstiller en taksonomi. I den historiske gennemgang har vi fundet det på sin plads at forklare nogle helt centrale begreber af hensyn til læsbarheden. Disse vil naturligvis ikke blive gentaget i kapitel 2, og det er derfor vigtigt for os at understrege, at de to kapitler i høj grad supplerer hinanden, og at det vil være særdeles uhensigtsmæssigt at læse kapitel 2 uden først at have læst kapitel 1.
I kapitel 3 gennemgår vi en række programudviklingsmiljøer og vurderer dem med henblik på i hvilket omfang den opstillede taksonomi er tilstrækkelig. I kapitel 4 beskrives den modificerede taksonomi og i kapitel 5 konkluderes.
Programudvikling er en aktivitet, der som sit primære formål har realisering af en løsning på et problem ved hjælp af den computerhardware, brugeren har til rådighed; men aktiviteten indgår i en større og mere omfattende aktivitet: systemudvikling. Samspillet mellem disse aktiviteter kan illustreres som vist i figur 1-1.
Figur 1-1. Samspillet mellem systemudvikling, programudvikling og hardware.
Det er vigtigt for os at fremhæve denne sammenhæng, fordi vi mener, at netop forståelsen af programudviklingsaktivitetens indplacering i forhold til systemudviklingsaktiviteten er af afgørende betydning for at kunne opstille en taksonomi, der også er dækkende for de visuelle programudviklingsmiljøer.
Vores vigtigste kilde til forståelse af programudviklingsmiljøer er Kurt Nørmark [Nørmark89]; men Nørmark afgrænser sin analyse af begreber, arkitekturer og værktøjer til programudviklingsaktiviteten - tilsyneladende i overensstemmelse med traditionen inden for denne del af datalogien. Det vil sige, at Nørmarks analyse beskæftiger sig med processen at fremstille et program til den underliggende hardware på basis af en foreliggende specifikation.
Den omsluttende systemudviklingsaktivitet beskæftiger sig primært med processen at fremstille den specifikation, der kan danne grundlag for fremstillingen af programmet. Denne opsplitning i systemudviklings- og programudviklingsaktiviteter er baseret på den opfattelse, som vi her vil kalde den traditionelle, at den første aktivitet er en forudsætning for den anden, og at de to aktiviteter derfor kan forstås og beskrives uafhængigt af hinanden.
Der har dog altid inden for datalogien været skeptiske røster imod den opfattelse, at aktiviteterne kunne forstås og beskrives uafhængigt af hinanden; men især inden for de sidste ti år er denne skepsis blevet konkretiseret i en række publikationer, der påpeger, at det i praksis er umuligt at holde de enkelte aktiviteter adskilt fra hinanden. Som eksempel på en sådan publikation, vil vi inddrage Pål Sørgaards "Programming Environments and System Development Environments". [Sørgaard88]
Nørmark definerer begrebet programmeringsmiljø (programming environment) som en integreret samling af programmeringsværktøjer. Et programmeringsværktøj defineres som en software- eller hardwarekomponent, der understøtter en veldefineret opgave i programudviklingsprocessen. [Nørmark89]
De vigtige aspekter ved definitionen er ifølge Nørmark selv
I relation til begrebet integration nævner Nørmark yderligere to begreber, som efter hans mening er nøglebegreber, selvom de altså ikke indgår i selve definitionen af begrebet programmeringsmiljø. Det drejer sig om begreberne inkremental og interaktiv.
Integration betyder kombination af dele ind i en større helhed. I denne sammenhæng er delene de forskellige programmeringsværktøjer, og den større helhed er programmeringsmiljøet.
Ordet inkremental bruges til at beskrive den situation, at en opgave deles op i mange mindre delopgaver, som løses hver for sig med det samme resultat, som hvis opgaven havde været løst i sin helhed. Indenfor systemudvikling bruges inkremental også som betegnelse for vertikal prototyping.
Ordet interaktiv indebærer, at der er en dialog mellem nogle parter, hvoraf den ene part som regel er et menneske. I denne sammenhæng er parterne typisk en programmør og et eller andet programudviklingsværktøj. [Nørmark89]
Vi vender i kapitel 2 tilbage med en mere udtømmende beskrivelse og præcis definition af de forskellige begreber og værktøjer, der indgår i forståelsen af programudviklingsmiljøer.
Nørmark pusler med den tanke, at en løsning på den meget omtalte softwarekrise kunne være udviklingen af bedre værktøjer til støtte for programudviklingsprocessen. [Nørmark89] CASE værktøjerne, som der i lang tid var knyttet store forhåbninger til, var et godt eksempel på sådanne værktøjer, der lovede brugerne konkrete gevinster i form af mindre udviklings- og vedligeholdelsesomkostninger. Nørmark henviser til, at der indenfor den datalogiske verden er meget lidt prestige forbundet med udvikling af værktøjer, og at det skulle være årsag til, at de udviklede af værktøjer ikke altid kan indfri de forventninger, der stilles til dem.
Men grunden kunne også være den, at de ændringer i arbejdsform og metoder, som til syvende og sidst kan gøre noget radikalt ved softwarekrisen, ikke skal udspringe af teknologiske forandringer, som udviklingen af nye værktøjer repræsenterer; men snarere af kulturelle forandringer.
Dette er et synspunkt, som måske mest præcist er blevet formuleret af Brad J. Cox [Cox90] i artiklen "There IS a silver bullet" fra 1990. Artiklen var et svar på en artikel med titlen "No Silver Bullet" af Frederick P. Brooks fra 1987 [Brooks87], hvor Brooks fremfører det synspunkt, at softwarekrisen er en realitet, som man må indstille sig på at leve med, fordi man ikke kan gøre noget ved den.
Cox er uenig i Brooks' pessimisme med hensyn til softwarekrisen. Selvfølgelig kan der gøres noget ved den; men løsningen forudsætter en kulturel snarere end en teknologisk revolution.
Når man skal forsøge at beskrive, hvad systemudvikling - og herunder altså programudvikling - går ud på, opdager man snart, at sproget er fattigt på ord, der tilstrækkeligt præcist kan beskrive, hvad det handler om. I den situation er det en naturlig reaktion, at man prøver at beskrive situationen ved at bruge metaforer og billeder, som bedre end sproget kan beskrive situationen.
Et eksempel herpå er den henvisning, som Nørmark starter med, da han som første sætning i sin lille afhandling erklærer, at programudvikling er et håndværk, og som i forbindelse med alle slags håndværk, må man forvente, at forskellige værktøjer spiller en essentiel rolle for håndværkeren - i dette tilfælde programmøren. [Nørmark89] Programmørens værktøj er dog ikke af jern og træ; men af den bløde slags i form af computerprogrammer.
En anden og mere rammende metafor er foreslået af Fred Brooks [Brooks96], som sammenligner programudviklerens arbejde med værktøjsmagerens. Begge arbejder selv med værktøj; men deres opgave er i virkeligheden at fremstille værktøj til andre. De er håndværkere; men samtidig lider de begge under det paradoks, at jo bedre de har været til at udføre deres arbejde, jo mindre bemærkes det af slutbrugeren.
Som tidligere nævnt er programudvikling en aktivitet, der som sit primære formål har realisering af en løsning på et problem ved hjælp af den computerhardware, brugeren har til rådighed; men der er stor forskel på programudviklingsprocessen i forbindelse med løsning af forskellige typer af programmeringsopgaver. Sørgaard nævner f.eks. følgende typer af programmeringsopgaver:
[Sørgaard88]
Hver type programmeringsopgave afspejler forskellige tilsvarende systemudviklingsmiljøer. Hver type programmeringsopgave stiller sine særlige krav til programudviklingsmiljøet. Disse krav dukker op på forskellige steder i den følgende gennemgang af programudvikling set i et historisk perspektiv.
Når man vil se på programudvikling i et historisk perspektiv, skal man være opmærksom på, at ens egne erfaringer fra de programudviklingsmiljøer, man selv har arbejdet med, spiller en ikke uvæsentlig rolle for den vægt, man tillægger forskellige begivenheder i det historiske perspektiv. Vi vil derfor i det følgende give en beskrivelse af vort eget udgangspunkt, og dermed også for grundlaget for de vurderinger, vi efterfølgende vil foretage.
Fælles for os er, at vi efter at have taget en uddannelse som edb-assistenter for ca. 20 år siden på forskellig vis har gjort karriere i erhvervslivet som programmører og systemudvilklere. Undervejs har vi begge suppleret vore uddannelser med henholdsvis datanom (Bjarne) og HD-eksamen (Ole).
Da vi begyndte at arbejde i erhvervslivet (i slutningen af 1970'erne) fik vi i første omgang erfaring med systemudvikling og programmering med den tids mest benyttede hardware-koncept, mainframe computeren. De fleste opgaver var såkaldte batch-løsninger. Der var primært tale om den type programmeringsopgaver, som ovenfor blev omtalt som programmering i relation til systemudvikling; men i mindre omfang stiftede vi også bekendtskab med programmeringsopgaver i relation til systemprogrammering.
I takt med den løbende modernisering af systemerne op gennem 80'erne, som bl.a. bevirkede, at brugerne kom i mere direkte dialog med computeren via on-line systemer eller via mindre systemer som mini-computere, fik vi også erfaring med de opgaver, hvor programmering i et vist omfang bliver udført af brugerne ved hjælp af 4. generations værktøjer.
Da vi efter kortere (Bjarne) eller længere (Ole) erfaring i erhvervslivet blev ansat som undervisere ved datamatikeruddannelsen, som er en kort, videregående, datalogisk uddannelse fik vi også erfaring med programmering i relation til undervisning. Denne programmering foregår hovedsagelig på PC'er og i Client/Server miljø, som vi således også har et indgående kendskab til.
Den eneste af de typer programmeringsopgaver Nørmark nævner, som vi ikke har så indgående kendskab til, er videnskabelig programmering; men generelt synes vi selv, at vores baggrund må betegnes som særdeles alsidig og meget bred. Det er på denne baggrund og på basis af denne erfaring, at vi i det følgende vil forsøge at give et historisk overblik over programudvikling.
Nørmark henviser til, at når man ser på programudvikling i et historisk perspektiv, var det i begyndelsen især udviklingen af programmeringssprog og programmeringsværktøj, der spillede den største rolle. [Nørmark89]
Efter vor mening er situationen i dag langt mere nuanceret, hvilket giver sig udslag i, at der kan peges på en række forskellige faktorer, der gennem gensidig påvirkning er med til at bestemme udviklingen af programudviklingsmiljøerne. Disse faktorer omfatter
Den gensidige påvirkning kommer bl.a. til udtryk på den måde, at teoretiske eller teknologiske landvindinger inden for ét felt uvægerligt kommer til at påvirke udviklingen inden for de øvrige områder.
Det er et karakteristisk træk, at især den teknologiske udvikling med hensyn til computerhardware sker hurtigere, end udviklingen indenfor de øvrige områder. Derfor ser det også ofte ud som om, de øvrige felter er nogle år bagefter i udvikling.
Man skal være varsom med at betegne noget som traditionelt, fordi betegnelsen traditionel let kan blive opfattet som synonym med forældet eller gammeldags. Det er dog ikke i den betydning, vi bruger ordet traditionel; men snarere i betydningen noget oprindeligt og stadig gyldigt. At det stadig er gyldigt betyder, at også nyere og mere moderne programudviklingsmiljøer stadig bygger på ideer og rummer elementer, der blev udviklet i forbindelse med det traditionelle programudviklingsmiljø.
Det traditionelle udviklingsmiljø (illustreret ved figur. 1-2) er karakteriseret ved fritstående værktøjer med svag integration imellem værktøjerne. Grundfilosofien er som regel baseret på top-down nedbrydning, og den foretrukne arbejdsform er struktureret. Målet er at fremstille programmer, der kan afvikles effektivt på den aktuelle hardwareplatform, idet det antages, at processor og memory er knappe og kostbare ressourcer, der skal udnyttes optimalt.
Dette udviklingsmiljø er typisk i relation til mainframe- og unix-systemer. Det karakteristiske for denne type installationer er, at de er opbygget omkring en centralt placeret computer med tilhørende driftsmiljø. Systemerne udvikles af programmører, som programmerer på grundlag af specifikationer udarbejdet af systemanalytikere og systemdesignere.
Fordelen ved dette miljø er, at det giver en optimal udnyttelse af ressourcerne på den centrale computer.
Det traditionelle programudviklingsmiljø afspejler på mange måder den arbejdsdeling, der stadig ofte er almindelig i forbindelse med større virksomheders udviklings- og driftsmiljø. De enkelte arbejdsopgaver udføres af specialister indenfor hver sit felt, fordi man antager, at det giver den mest optimale udnyttelse af ressourcerne.
Udviklingen af det traditionelle udviklingsmiljø tog reelt sin begyndelse engang i slutningen af 1950'erne, da de første programmeringssprog og compilere blev udviklet. Hvis man ser bort fra assemblersproget, som er et sprog, der ligger meget tæt op ad maskinsprog, plejer man at regne FORTRAN som det første egentlige programmeringssprog. Dette sprogs styrke ligger primært i relation til teknisk/videnskabelige opgavetyper, hvorimod sprog som COBOL og senere PL/1 blev langt mere udbredt i relation til de opgaver, der sigtede mod udvikling af systemer til erhvervslivet. Det er disse sprog, som vi har størst erfaring med.
Når vi beskriver et traditionelt programudviklingsmiljø er det således et udviklingsmiljø opbygget omkring en COBOL-compiler, som vi har i tankerne; men bortset fra det, er programudviklingsmiljøet stort set identisk med det Algol-baserede miljø, Nørmark beskriver [Nørmark89].
Figur 1-2. Typisk arbejdsgang i et traditionelt programudviklingsmiljø.
At det traditionelle programudviklingsmiljø stadig er gyldigt, ses af den kendsgerning, at det stort set er den samme form for programudvikling, der er grundlaget i ethvert Unix-miljø, der ofte er baseret på programmeringssprogene C eller C++. I PC-verdenen genkendes det traditionelle programudviklingsmiljø i forbindelse med udvikling af programmer i DOS-miljøet.
Det karakteristiske for det traditionelle programudviklingsmiljø er som nævnt princippet om arbejdsdeling. Denne arbejdsdeling kommer f.eks. til udtryk i en række specialiserede værktøjer, som hver for sig har til opgave at assistere programmøren med at omsætte programmet fra én repræsentation til en anden.
I begyndelsen eksisterer programmet som en idé inde i hovedet på programmøren eller eventuelt skrevet ned på papir. Dette er den første form for repræsentation, som programmet kan være på.
Ved hjælp af en editor overføres programmet til digital (maskinlæsbar) form. Opgaven er temmelig rutinepræget, idet det som regel drejer sig om at overføre programmet uændret fra papir til computer. Den kreative del af processen er knyttet til selve nedskrivningen eller konstruktionen af programmet.
Hvis der er knaphed på arbejdspladser, hvor indtastning kan finde sted, regnes det ikke for god skik at konstruere programmet samtidig med, at man indtaster det; men det forekommer alligevel så hyppigt, at man nok må betegne denne teknik som de fleste programmørers foretrukne arbejdsform.
Når programmet er indlagt som såkaldt kildetekst på computeren skal den oversættes til en repræsentation, som er hensigtsmæssig i den videre proces. Hvor det skrevne program består af sekvenser af ord, der sammensættes til sekvenser af sætninger, er det oversatte program repræsenteret ved en pyramideformet, hierarkisk struktur.
Input til oversættelsen kan også stamme fra makroer. En makro er en stump kildetekst, der udløst af en makrokommando i kildeteksten indføjes i denne før oversættelsen. Da det sker før selve oversættelsen, er det almindeligt at omtale denne del af oversættelsen som prækompilering.
Via de nævnte hierarkiske mellemformer oversætter compileren nu programmet til en ny repræsentation, objektkode. Når programmet er oversat til objektkode er det i princippet klar til at blive udført på computerens processor.
Før programmet kan afvikles, skal det dog sættes sammen med en række elementer, der ligeledes findes objektform. Disse elementer omfatter standardrutiner, som f.eks. håndterer input og output. Programmøren har også mulighed for at lave egne standardrutiner, som så kan indlægges i et bibliotek, hvorfra de kan være tilgængelige som standardrutiner både for programmørens egne programmer og for andre programmørers programmer. Den her beskrevne måde at konstruere programmer på betegnes også som modularitet.
Sidste led i programudviklingsprocessen kaldes linkeren eller lænker. Lænkerens opgave er at samle objektkoderne for hovedprogrammet og de forskellige moduler til en helhed i et eksekverbart program.
I det traditionelle programudviklingsmiljø er det næsten umuligt for brugeren at programmere noget selv. De anvendte programmeringssprog er meget fremmedartede og de værktøjer, der skal anvendes i forbindelse med programudviklingen kræver en høj grad af specialistviden hos programmøren.
Det betyder, at brugeren i høj grad bliver afhængig af udviklingsorganisationen og dens prioriteringer af opgaverne. Man kan nemt forestille sig, at begrebet softwarekrise er opstået som følge af de frustrationer, der er opstået i brugerorganisationen på grund af meget lange leveringstider på software, som kunne have lettet løsningen af en opstået ad-hoc opgave betydeligt.
Som en reaktion på dette problem, og også for at imødekomme nogle behov for ad-hoc programmer i den videnskabelige verden udvikledes i begyndelsen af 1970'erne forskellige integrerede og interaktive programudviklingsmiljøer - hvoraf et af dem var opbygget omkring sproget Basic.
Som følge af den teknologiske udvikling på hardware-området kom der på samme tid nye mini-datamater frem, som kunne opstilles i et almindeligt kontormiljø, i stedet for det driftsmiljø, der er så karakteristisk for mainframe-computere. Denne udvikling medvirkede også til at gøre afstanden mellem bruger og computer mindre, idet den relativt korte fysiske afstand mellem brugeren og computeren spillede en psykologisk rolle. Computeren som fænomen blev simpelthen afmystificeret.
I takt med at computeren blev afmystificeret, var der naturligvis nogle brugere, der fik mod på også at prøve kræfter med programmering. Sproget BASIC er netop skabt som et begyndersprog med denne type brugere/programmører som målgruppe.
At miljøet er interaktivt betyder, at programmøren er i dialog med computeren under programudviklingen. At miljøet er integreret betyder, at programmøren fra det samme værktøj har mulighed for at aktivere og styre editor, oversætter og programafvikling.
Figur 1-3. Principskitse for opbygningen af et integreret uviklingsmiljø.
Dette miljø åbnede nogle store muligheder for mange mennesker, som nu pludselig fik mulighed for at programmere computere selv. Også mange professionelle systemudviklere kastede sig over det nye værktøj. Det skyldes måske især miljøets integrerede faciliteter, som er en stor lettelse for programmøren i udviklingsprocessen.
Sproget er stadig meget udbredt, hvilket ikke mindst hænger sammen med, at det altid har været en integreret del af styresystemet på enhver DOS-baseret PC. Det har haft den virkning, at utroligt mange mennesker over hele verden har stiftet bekendtskab med sproget, når de skulle prøve kræfter med programmering af deres egen PC. Der udvikles stadig mange ad-hoc programmer såvel som kommercielle systemer i Basic.
Selve oversættelsen af programmet er baseret på et andet princip end oversættelsen i det traditionelle programudviklingsmiljø. Der er faktisk ikke tale om nogen egentlig oversættelse, idet programmet i kildetekst aldrig oversættes til objektkode eller maskinkode. I stedet fortolkes og udføres kildeprogrammets linier én ad gangen, når programmet udføres. Programmet forefindes altså kun i én repræsentation: kildetekst.
Dette koncept giver en ganske smidig og behagelig arbejdsform i forbindelse med udvikling og afprøvning af nye programmer - altså i programudviklingsprocessen. Programmøren indtaster programmets kildetekst med den integrerede editor. Når programmet er indtastet bruges kommandoen RUN, hvorefter programmet straks begynder at køre. Dette er i modsætning til det traditionelle udviklingsmiljø, hvor programmet først skal oversættes til eksekverbar kode, før det kan afprøves. Denne oversættelsesproces kunne på datidens maskiner tage flere minutter.
I det integrerede og interaktive udviklingsmiljø strækkes oversættelsesprocessen over hele programmets køretid, og ventetiden i starten er altså kun den tid, det tager at oversætte (fortolke) den første linie i programmet. Desværre går det alvorligt ud over effektiviteten, idet man kan risikere, at den samme sætning bliver oversat (fortolket) adskillige gange i løbet af programmets køretid. Det gælder f.eks. de sætninger i programmet, der indgår i løkker, som ofte gentages et stort antal gange.
En anden ulempe ved fortolkede sprog er, at man kun får testet en programsætning, hvis den bliver udført. Hvis en programsætning således er placeret i et afsnit af programmet, der kun bliver aktiveret under helt særlige betingelser, bliver sætningen måske ikke afprøvet under aftestning af programmet, og man risikerer derfor at programmet bliver sat i drift med indbyggede fejl, der venter på at blive udløst første gang de specielle betingelser er opfyldt.
Dette er udslag af det fortolkede sprogs dynamiske (svage) typekontrol, der først virker på kørselstidspunktet, i modsætning til statisk (stærk) typekontrol, der ses i relation til oversatte sprog.
Det her beskrevne udviklingsmiljø kommer i sin virkemåde meget tæt på det Lisp udviklingsmiljø, der beskrives af Nørmark. [Nørmark89]
Også de fleste af de såkaldte 4. generations udviklingsmiljøer er opbygget som integrerede og interaktive udviklingsmiljøer.
Det integrerede og interaktive udviklingsmiljøs popularitet voksede yderligere, da mikrodatamaterne og PC'erne gjorde deres indtog i begyndelsen af 80'erne. Computere var fra da af ikke længere en kostbar ressource, som var forbeholdt større erhvervsvirksomheder. Også små virksomheder og privatpersoner havde nu råd til at anskaffe sig egen computer.
Programmering blev som en konsekvens heraf udbredt til et langt større udsnit af befolkningen. Basic var således i første omgang det naturlige valg som udviklingsmiljø for denne nye store gruppe af hobbyprogrammører.
Til udvikling af kommercielle systemer til PC'erne savnede man imidlertid et alternativ, som kunne bruges til udvikling af programmer, der kunne udnytte maskinerne mere effektivt, sådan som man kendte det fra de oversatte sprog som f.eks. COBOL eller PL/1 i det traditionelle mainframe miljø.
Der blev derfor udviklet programmeringssprog med tilhørende programudviklingsmiljøer, som lignede de kendte traditionelle programudviklingsmiljøer. Faktisk kan man sige, at historien gentog sig, idet man først fik assemblersprog og siden de fra mainframe miljøet kendte programmeringssprog som f.eks. COBOL. Men også andre sprog, som f.eks. sprogene Pascal og C har vundet indpas i PC-verdenen.
Pascal er et sprog, der oprindeligt er udviklet til undervisningsbrug på højere læreanstalter, så mange ingeniører og dataloger har stiftet bekendtskab med sproget i forbindelse med deres studie. Netop i undervisningsmiljøet på de højere læreanstalter fandtes mange af de potentielle købere og programmører af PC'erne.
Senere blev også sproget C meget udbredt til løsning af programmeringsopgaver i forbindelse med udvikling af applikationssystemer. C kommer fra Unix-miljøet, hvor det er systemets basissprog - det sprog, som systemets grundmoduler er programmeret i.
I begyndelsen var Pascal dog det mest udbredte programmeringssprog i forbindelse med systemudvikling, og udviklingsmiljøet var en gentagelse af det kendte traditionelle udviklingsmiljø.
En gruppe unge danske studerende ved det daværende Polyteknisk Læreanstalt udviklede i denne periode et udviklingsværktøj, Poly Pascal, som forenede fordelene fra det integrerede og interaktive udviklingsmiljø med fordelene i det traditionelle miljø. Man fik et integreret og interaktivt miljø og et oversat sprog (Pascal) med en stærk typekontrol.
Vi har kaldt denne nye type udviklingsmiljø for det integrerede og simuleret interaktive udviklingsmiljø. Betegnelsen simuleret interaktiv hentyder til, at der faktisk sker en oversættelse af programmet til maskinkode, før det kan afprøves; men oversættelsen foregår så hurtigt, at det er rimeligt alligevel at tale om en interaktiv afvikling.
Da udviklingsværktøjet efter nogen tid blev overtaget af Borland International og lanceret på verdensmarkedet til en særdeles konkurrencedygtig pris under navnet Turbo Pascal, skete der en nærmest eksplosiv udvikling i udbredelsen og anvendelsen.
Udviklingsmiljøets popularitet kan naturligvis ikke alene tilskrives den lave pris - udviklingsmiljøets kvalitet spillede også en stor rolle. Turbo Pascal blev en milepæl i udviklingen af programudviklingsmiljøet, og værktøjet blev en de facto standard standard for en lang række andre udviklingsværktøjer, der er fremkommet sidenhen.
I en senere version af Turbo Pascal er der blevet tilføjet objektorientering, hvilket har bidraget til at gøre udviklingsmiljøet endnu mere populært. I de sidste år har udviklingsmiljøet dog tilsyneladende tabt en del markedsandele til fordel for udviklingsmiljøer, der er baseret på sprogene C eller C++.
Næste spring i udviklingen af udviklingsmiljøet kom som en reaktion på den stigende udbredelse af grafiske brugergrænseflader, som f.eks. Windows platformen på PC'erne og X-Windows eller Motif til Unix-miljøet. Programmering til en grafisk brugergrænseflade er en yderst kompliceret affære, som stiller uhyre store krav til programmørens evner.
I en periode var programmering til denne type brugergrænseflade derfor igen forbeholdt en lille gruppe af eliteprogrammører, som beherskede teknikken.
Når en grafisk brugergrænseflade som f.eks. Windows bliver så udbredt, som tilfældet er, vokser softwarebehovet igen eksplosivt, og softwarekrisen begynder igen at kradse. Som vi tidligere har set, er en af de mulige løsninger, at flere bliver i stand til at programmere. Men for at det skal kunne lade sig gøre, må man tilføje en effektiv hjælp til nogle af de elementer fra processen, som bidrager mest til kompleksiteten.
I tilfældet med de grafiske brugergrænseflader er noget af det, som bidrager mest til kompleksiteten, de mange variationsmuligheder man har til rådighed, når man skal opbygge brugergrænsefladen.
I begyndelsen bestod programmering af den grafiske brugergrænseflade i, at programmøren sammensatte skærmbilledlayoutet ved at kalde et antal procedurer fra et standardbibliotek. Hver procedure tilføjer et eller andet element til den grafiske brugergrænseflade, det kan f.eks. være en label, en edit-box eller en knap. Programmøren skal i hvert enkelt tilfælde tage stilling til en lang række spørgsmål som f.eks. skrifttype, font, størrelse, placering, tekstens orientering osv. Svarene på alle spørgsmålene medgives procedurerne som parametre.
Det kræver en del forsøg, før skærmbilledet tager sig ud på en måde, som man er tilfreds med. Problemet er, at programmet skal indtastes og afprøves, før man kan se resultatet på skærmen.
I det visuelle, integrerede og interaktive udviklingsmiljø, som f.eks. Visual Basic, er dette problem løst ved hjælp af en visuel skærmbilled editor, hvor man kan redigere sit skærmbillede, indtil det ser ud, som man ønsker. Skærmbillededitoren genererer løbende de procedurer med tilhørende parametre, som programmet skal bruge i forbindelse med opbygning af skærmbilledet.
Den største effekt ses måske i de tilfælde, hvor man skal flytte et større antal elementer på skærmbilledet, f.eks. for at give plads for nye ønskede komponenter. Uden en visuel skærmbilledgenerator til sin rådighed er det være et stort arbejde for programmøren at lave sådanne ændringer, idet man skal ændre i parametrene på en masse procedurer.
Skærmbilledgeneratoren har gjort det så let at lave ændringer, at det har betydet en ændring i den måde systemudviklingen foregår på, hvilket bl.a. også fremgår af en artikel om udvikling af visuelle programmeringssprog til Unix-miljøet. [Repenning95]
Der er således skabt mulighed for en langt højere grad af brugerdeltagelse i systemudviklingsprocessen. Det er nu muligt for systemudvikleren og den kommende bruger i fællesskab at udvikle prototypen til det kommende skærmbillede. De kan sidde sammen omkring skærmbillededitoren og eksperimentere med forskellige layout.
Med fremkomsten af de første visuelle værktøjer sker der også en ændring i den måde programmet er repræsenteret på. Vi har tidligere fortalt, at programmets kildetekst er en lineær tekst - en sekvens af ord, der er sat sammen i sætninger. I de visuelle værktøjer er der behov for andre repræsentationer, når man f.eks. skal fastholde og gemme informationer om et antal komponenter på den grafiske brugergrænseflade.
En objektorienteret struktur eller et semantisk netværk er oplagte muligheder, når man skal vælge en brugbar repræsentation. Desværre rejser sådanne repræsentationer nogle nye problemer - et af dem er, at de er meget vanskelige at dokumentere på papir.
Manglende dokumentation er derfor også et meget påtrængende problem i alle visuelle udviklingsmiljøer - et problem, som stadig savner en tilfredsstillende løsning.
Vi har tidligere skrevet, at historien har en tendens til at gentage sig selv. Det ser vi encnu et eksempel på i forbindelse med fremkomsten af det visuelle, integrerede og simuleret interaktive udviklingsmiljø. Tidligere beskrev vi, hvordan man havde forenet fordelene fra det traditionelle udviklingsmiljø - de oversatte programmers effektivitet og compilerens statiske typecheck - med det integrerede og interaktive udviklingsmiljøs fordele - fleksibilitet og integrerede værktøjer.
Kravet om mere effektive programmer og programmeringssprog med mulighed for statisk type check har siden fremkomsten af det visuelle, integrerede og interaktive udviklingsmiljø betydet en udvikling af programudviklingsmiljøer baseret på C++ (Visual C++), Object Pascal (Delphi) og flere andre.
Blandt disse er Delphi fra Borland International uden tvivl det udviklingsmiljø, som i de kommende år vil blive de facto standard for denne type udviklingsværktøjer. Denne påstand bygger vi på den kendsgerning, at Delphi og senere C++ Builder har føjet en ny dimension til integrationen af værktøjer.
Begge udviklingsmiljøer er blevet udstyret med integrerede værktøjer, som giver let og direkte adgang til flere forskellige typer databaser. Desuden har man valgt at efterligne den meget brugervenlige skærmbillededitor fra Visual Basic.
Begge dele er på afgørende måde med til at gøre det muligt for mindre rutinerede programmører at fremstille programmer med et professionelt udseende og med en indbygget funktionalitet, som i mange tilfælde svarer til, hvad man kan forvente af programmer fremstillet af professionelle programmører.
Man har således mulighed for at skabe systemer, der vedligeholder data i relationelle databaser blot ved at svare på en række spørgsmål, der bliver præsenteret på skærmen af en såkaldt application wizard.
Det er dog stadig sådan, at når man kommer til løsning af mere komplicerede opgaver, vil værktøjet være for vanskeligt for den uprofessionelle programmør. Sådanne systemer skal selvfølgelig stadig udvikles af professionelle programmører. Men det, som dette udviklingsværktøj har bidraget til, er at rykke grænsen betydeligt for, hvornår en opgave er for kompliceret for en uprofessionel programmør.
Der er for os derfor ingen tvivl om, at Delphi vil komme til at definere standarden for denne type udviklingsmiljøer i en årrække fremover.
Med nedenstående figur 1-4 har vi forsøgt at give et samlet billede af den historiske udvikling af programudviklingsmiljøerne.
I begyndelsen udvikledes det traditionelle udviklingsmiljø, kendetegnet ved compileren, statisk typecheck og fritstående værktøjer. Udviklingsmiljøet opstod i mainframe miljøet, hvor det stadig eksisterer; men princippet er siden blevet brugt i både MS/DOS og Unix verdenen.
Senere udvikledes et integreret og interaktivt udviklingsmiljø, kendetegnet ved fortolker, dynamisk typecheck og integrerede værktøjer. Udviklingsmiljøet opstod i minidatamat verdenen; men er siden blevet brugt i mainframe, Unix og PC-verdenen.
I det integrerede og simuleret interaktive udviklingsmiljø kombineredes fordelene fra de to oprindelige udviklingsmiljøer, således at der blev skabt et fleksibelt udviklingsmiljø, kendetegnet ved compiler med statisk typecheck og integrerede værktøjer. Udviklingsmiljøet kendes især fra PC-verdenen.
Som en reaktion på den øgede kompleksitet i forbindelse med udvikling af programmer med grafiske brugergrænseflader udvikledes visuelle udviklingsmiljøer. Disse var i første omgang baseret på fortolker, dynamisk typecheck og integrerede værktøjer. Forskellen fra de tidligere integrerede værktøjer er tilføjelsen af en skærmbillededitor som et nyt værktøj. Udviklingsmiljøet findes både i PC-verdenen og i Unix-verdenen.
Endelig gentager historien sig, og man kombinerer i det visuelle, integrerede og simuleret interaktive udviklingsmiljø fordelene fra det integrerede og simuleret interaktive miljø med de visuelle værktøjer. Integrationen øges yderligere med tilføjelse af værktøjer til databasekonstruktion og manipulation.
Figur 1-4. Oversigt over programudviklingsmiljøernes historiske udvikling.
opdateret 21. august 1997
.