Kapitel 5

Konklusion

 

Formålet med opgaven var at undersøge, om de taksonomier man traditionelt har brugt til beskrivelse af programudviklingsmiljøer også ville være dækkende for de visuelle programudviklingsmiljøer.

Vores arbejdshypotese var, at den traditionelle taksonomi ikke ville være dækkende. Denne arbejdshypotese var baseret på vort forudgående praktiske kendskab med nogle af de visuelle programudviklingsmiljøer. Gennem arbejdet med de visuelle miljøer havde vi fået en fornemmelse af, at de visuelle miljøer tilføjede nye dimensioner til de muligheder udviklingsmiljøer traditionelt stiller til rådighed for systemudvikleren.

Vi vil skynde os at konkludere, at vores arbejdshypotese holdt. Ellers kunne vi heller ikke have opfyldt problemformuleringens andet formål, som handler om opstilling af en taksonomi, som også er dækkende for de visuelle udviklingsmiljøer.

Omkring de opdagelser, vi gjorde undervejs, kan vi konkludere, at den største overraskelse var, at objektorienteret programmering, som vi stadig opfatter som en ny og forholdsvis umoden teknologi, faktisk allerede kan betragtes som en "klassisk" teknologi. Hvis et visuelt udviklingsmiljø f.eks. er opbygget omkring et objektorienteret programmeringssprog, er det ikke noget, der tillægges større betydning i beskrivelsen af det visuelle udviklingsmiljø.

Det var overraskende, fordi en af vore kilder [Nørmark89] fremhæver, at det programmeringssprog, udviklingsmiljøet er bygget op omkring, spiller en afgørende rolle for, hvordan udviklingsmiljøet udformes. Dette mønster er ikke typisk i de visuelle udviklingsmiljøer. Et af de undersøgte visuelle værktøjer, Delphi, som er baseret på sproget Object Pascal, har således en tvilling med navnet C++ Builder, der, som navnet siger, er baseret på programmeringssproget C++. De to udviklingsmiljøer er stort set identiske, når man ser bort fra programmeringssproget. Komponenter udviklet i det ene udviklingsmiljø kan uden problemer anvendes i det andet. I næste fase kan vi sikkert forvente et fælles udviklingsmiljø, hvor systemudvikleren tilbydes valgfrihed mellem en række forskellige programmeringssprog.

Et andet udslag af denne sproguafhængighed er som nævnt, at systemudvikleren næppe bemærker, om der arbejdes med et objektorienteret eller proceduralt sprog. Betydningen af sprogets karakter svinder i takt med, at det, der opfattes som besværligt, overtages af udviklingsmiljøet. I "klassisk" objektorienteret programmering er det f.eks. besværligt at skulle initiere de mange objekter, som programmet er opbygget af. I de visuelle udviklingsmiljøer er den besværlige del af arbejdet overtaget af en "Object Inspector, hvor man på designtidspunktet bliver præsenteret for en editor, der foreslår defaultværdier til de enkelte attributter i objektet. Selvfølgelig forekommer der stadig ændringer af disse værdier under programmets afvikling; men den besværlige (og kedelige) del af arbejdet slipper man for.

Noget af det, der har været mest spændende i arbejdet med opgaven, har været udformningen af en model for visuel systemudvikling (figur 4-1). Man kan altid diskutere værdien af sådanne modeller, fordi de har en tendens til at blive så abstrakte, så det kan være svært at relatere modellen til det, man oplever i virkeligheden.

Under alle omstændigheder har modellen dog vist sin berettigelse i forhold til at være et grundlag og et udgangspunkt for en diskussion med kolleger, medstuderende og vejleder om systemudviklerens rolle i forskellige typer af systemudviklingsmiljøer.

Vi betragter modellen som en dynamisk størrelse, som med sikkerhed vil blive modificeret og tilpasset efterhånden som vores forståelse og indsigt i emnet udvikles.

Vi synes også der er mange fremtidsperspektiver i kombinationen med Repenning og Sumner’s samarbejdende designproces, som vi opfatter som et godt bud på, hvordan realiseringsaktiviteten i praksis kan gribes an i en systemudviklingsproces, hvor der er brugerdeltagelse helt ind i realiseringsaktiviteten.


Opdateret 12. oktober 1997