I dette kapitel vil vi introducere begrebet visuel programmering, beskrive fænomenets baggrund og give et bud på en definition, og eftersom området visuel programmering er forholdsvis stort, vil vi opstille en række begrænsninger med hensyn til hvilke områder og problemstillinger, vi ønsker at beskæftige os med.

Langt de fleste innovative tiltag på softwaresiden i de sidste mange år er blevet foretaget for at løse det, man har kaldt softwarekrisen.

Softwarekrisen har efterhånden varet i over tyve år. Begrebet opstod, da prisen på hardware, hjulpet af ny store teknologiske landvindinger, for alvor begyndte at falde, uden at prisen på nyudvikling af software på nogen måde kunne følge med. Softwarekrisen som begreb blev første gang beskrevet i forbindelse med en NATO konference om software engineering i 1968.

Utallige projekter blev søsat for at løse op for denne krise. Meget omtalt var det japanske 5. Generations projekt, som havde det formål at skabe helt nye rammer og grænser for programmering - projektet kan næppe kaldes en succes målt i forhold til de oprindelige ambitioner [Sterling94].

I 1987 opsummerede Brooks situationen i en meget ofte refereret artikel [Brooks87], hvor han anlægger et meget pessimistisk syn med hensyn til mulighederne for at løse softwarekrisen [Vi er grundlæggende enige med Brooks i, at softwarekrisen ikke kan løses, hvis det man stræber efter er en produktivitetsudvikling, som kan sammenlignes med det, vi har set på hardwaresiden, og vi er også enige i, at produktivitetsforbedringer af beskeden, men dog signifikant, størrelse kan opnås på en række områder, hvis tingene gribes rigtigt an. Der ses imidlertid også ofte eksempler på det modsatte.]. Brooks foretager en kritisk gennemgang af mulige strategier, som eventuelt kunne løse op for softwarekrisen, herunder blandt andet:

1. Objektorienteret programmering
2. Programmeringsmiljøer generelt
3. Arbejdsstationer
4. Program verifikation
5. Automatisk programmering (baseret på specifikationer)
6. Ekspertsystemer
7. Kunstig intelligens
8. Visuel programmering

Visuel programmering skal altså ses som et blandt mange tiltag for at forbedre produktiviteten i softwareudviklingsprocessen og opstod som fænomen, da de generelle priser på hardware faldt, og der blev udviklet forholdsvis prisbilligt udstyr med grafisk repræsentation.

At det visuelle ville blive inddraget i programmeringsarbejdet er der ikke noget overraskende i. Den menneskelige hjernes uovertrufne evne til mønstergenkendelse på meget kort tid ved visuelle indtryk har været velkendt i årtier, og hvis blot en lille del af denne effektivitet kunne overføres til programudviklingsprocessen, ville meget være vundet.

Ovenstående kan illustreres ved et ganske simpelt, lille eksempel: hvis vi forestiller os, at man giver en tegning, som blandt andet forestiller to sorte katte, til et fire-års barn og stiller spørgsmålet: "Hvor mange sorte katte er der på tegningen?", så vil det rigtige svar komme uden tøven, dvs. på under to sekunder. Hvis man prøver at overveje, hvor lang tid, det vil tage at skrive et program efter traditionelle metoder, som tager en hvilken som helst tegning som input, og giver det rigtige svar på bemeldte spørgsmål på under to sekunder med samme sikkerhed som barnet, så snakker vi utvivlsomt om adskillige mandemåneder.

Følgende er en række af de fordele den grafiske repræsentation kunne tænkes at have i forhold til det skrevne ord (efter Chu [Chu92]):

1. Billeder kan være en mere effektiv måde at kommunikere på en ord (jf. den urgamle floskel: "a picture paints a thousand words…")
2. Billeder fremmer forståelsen og hjælper hukommelsen
3. Billeder kan fremme incitamentet til at lære at programmere
4. Billeder har ikke sproglige barrierer

Eksemplet med de sorte katte kan også bidrage til at illustrere, at det ikke stod ganske klart for forskerne på hvilken måde den hurtige menneskelige, visuelle mønstergenkendelse skulle overføres til programmeringsverdenen, og det betød, at udviklingen inden for det visuelle område til at starte med bevægede sig i ganske mange, temmelig forskellige retninger for at finde en farbar vej.

Nedenstående opremsning af visuelle programmeringsområder lægger sig ganske tæt op af Chu’s [Chu92], idet hendes skelnen mellem de forskellige delområder er mere nuanceret og detaljeret end andres, f.eks. Burnett et al. [Burnett94], som udelukkende koncentrerer sig om objektorienteret visuel programmering. Det er i øvrigt en meget udbredt opfattelse, at visuel programmering også pr. definition er objektorienteret. Dette er selvsagt ikke tilfældet.

Ifølge Chu kan visuel programmering hensigtsmæssigt opdeles i følgende discipliner:

1. Visualisering af data og datastrukturer
2. Visualisering af program-udvikling og -afvikling ("vis mig hvad der foregår")
3. Visualisering af software design ("vis mig, hvad jeg har")
4. Visuel "coaching" ("gør hvad jeg viser dig")
5. Sprog til håndtering af visuel information
6. Sprog til support af visuel interaktion
7. Diagram systemer (Baseret på Nassi-Shneiderman diagrammer)
8. Ikoner og ikonsystemer
9. Tabel og formular baserede systemer

I det følgende vil vi kort redegøre for, hvilke af ovennævnte områder, der er interessante i forhold til vores overordnede produktkriterier og de faktisk valgte produkter.

1 og 3 samt til dels 2 kan betragtes som visuelle udvidelser til traditionelle programmer og kun af begrænset interesse i denne fremstilling. Dog er visualisering af datastrukturer en del af nogle af de valgte produkter; men faciliteten tillægger vi kun underordnet betydning. Visualisering af programafvikling er derimod særdeles relevant.

Visuel coaching (4) går ud på, at produktet qua nogle eksempler som programmøren (eller snarere brugeren) indtaster selv er i stand til at udlede sammenhængen og dermed konstruere programmet. Metoden har begrænset anvendelse, og vi har derfor fravalgt den.

5 og 6 retter sig imod mere specialiserede applikationer og ikke imod den type, som vi har valgt at koncentrere os om.

7, 8 og 9 repræsenterer, hvad man tilsammen kunne betegne som visuelle programmeringssprog, og det er naturligvis her vores primære indsatsområde vil være.

Vi vender for et kort øjeblik tilbage til Brooks, som er ret kategorisk i sin afvisning af visuel programmerings muligheder for at forbedre produktiviteten i softwareudvikling. Hans primære begrundelse er, at visuel programmering ikke bidrager til at forbedre overblikket og at skærmene er for små.

Brooks har imidlertid, efter vores mening, kun fat i et par hjørner af det vi i dag henregner til visuel programmering, især diagramsystemer (#7 på listen). At konkludere alene på et delområde virker kritisabelt, og synspunktet bør i hvert fald i dag, hvor tingene har flytte sig meget inden for dette område, revurderes. Brooks lader selv en dør stå åben, idet han påpeger, at med den nuværende hardware teknologi virker et gennembrud ikke realistisk, men udelukker altså heller ikke, at det kan ske en gang i fremtiden. Det falder uden for denne rapports rammer at revurdere Brooks’ synspunkter, og vi vil nøjes med at fastslå, at vi faktisk tror på, at visuel programmering allerede har bidraget til, og fremover vil bidrage yderligere til, ikke uvæsentlige produktivitetsforbedringer i softwareudviklingsprocessen. Den faktiske forbedring afhænger dog meget af produktet - visse produkter udviser faktisk negative forbedringer.

Vores definition af et visuelt programudviklingsmiljø kan herefter fastlægges på følgende måde:

Efter gennemgang af tre visuelle programudviklingsmiljøer i kapitel 3 har vi fundet frem til en række kriterier, som vi mener skal tilføjes til karakteristikken af programudviklingsmiljøet. Her følger en præsentation af de enkelte kriterier.

Det er et gennemgående træk ved de visuelle værktøjer, at der er mange forskellige og ofte stærkt specialiserede editorer integreret i programudviklingsmiljøet. Nogle af disse kan karakteriseres som struktur-orienterede editorer i henhold til Nørmarks terminologi [Nørmark89]. Andre editorer kan derimod være svære at indplacere i taksonomien over editorer, hvilket indikerer, at taksonomien ikke er rig nok til at beskrive de editorer, man støder på i moderne visuelle programudviklingsmiljøer.

Desværre har tiden ikke tilladt os at fordybe os yderligere i dette område; men det står klart for os, at området kan gøres til genstand for yderligere udforskning.

Det er et karakteristisk træk i de undersøgte visuelle programudviklingsmiljøer, at der må tilføjes noget i forhold til den definition af begrebet inkrementalitet, der blev opstillet i kapitel 2. Det begrunder vi med den kraftige fokusering på begrebet komponent i de undersøgte visuelle udviklingsmiljøer.

Begrebet komponent er en videreudvikling af det objektorienterede klasse begreb. Komponenterne vælges fra en komponentpalette og en forekomst af komponenten indsættes på formularen.

Man har mulighed for at definere egne komponenter - enten i form af videreudviklinger af de eksisterende komponenter, eller i form af helt nyudviklede komponenter. Denne mulighed medfører, at de visuelle programudviklingsværktøjer kan gøres til genstand for en målrettet tilpasning, således at den enkelte udviklingsorganisation eller den enkelte programmør kan tilpasse udviklingsmiljøet til sit individuelle behov.

Vi har bemærket, at mængden af værktøjer i de visuelle programudviklingsmiljøer er meget stor - vi har ikke talt efter; men vi vil skønne, at der i Delphi er mere end 50 forskellige værktøjer, som er integreret i udviklingsmiljøet.

Integration i en så stor målestok stiller naturligt nok krav om en stor ensartethed i opbygningen af de forskellige værktøjer, hvis det ikke skal blive en uoverkommelig opgave for systemudvikleren at lære at bruge de mange forskellige værktøjer.

Ligeledes har vi bemærket, at værktøjerne nu i høj grad bliver integreret i hinanden, og ikke kun med hinanden.

Vi foreslår, at karakteristikken af integration udvides med begrebet skala, som kan fortælle, om der er mange eller få værktøjer integreret.

Med hensyn til antallet af repræsentationer er karakteristikken for snæver, og skal suppleres med dimension, hvorunder man kan angive antallet (få eller mange) af former for repræsentationer af programelementer.

Vi har gjort den erfaring, at det i praksis ingen rolle spiller, om det sprog, man baserer programudviklingsmiljøet på, er objektorienteret eller proceduralt. Det undrer os egentlig - og især når sproget er objektorienteret. Det hænger sammen med, at objektorientering af de fleste anses for at være en filosofi, der er overlegen i forhold til den procedurale top-down filosofi.

Det har fået os til at overveje, om det vi oplever er en ny grundfilosofi indenfor systemudvikling - en grundfilosofi, som vi kan kalde visuel systemudvikling. Vi vil senere i kapitlet prøve at beskrive, hvordan vi opfatter denne nye grundfilosofi.

Interaktivitet handler om dialog. Vi er tilbøjelige til først og fremmest at tænke på dialogen mellem computer og programmør; men de visuelle programudviklingsmiljøer åbner mulighed for, at dialogen også kan være mellem computer og bruger i selve programmeringsaktiviteten.

Hermed er vejen banet for en ny epoke i systemudviklingens historie - en epoke præget af brugerdeltagelse i hele udviklingsprocessen. Dette emne vil vi behandle i et særligt afsnit.

I kapitel 2 beskrev vi nogle modeller for systemudvikling i forbindelse med vores tilføjelse af kriterier vedrørende systemudviklingsprocessen til karakteristikken af programudviklingsmiljøet.

Vi vil i dette afsnit give et bud på, hvordan en tilsvarende model for visuel systemudvikling kan se ud. Modellen er primært baseret på vores egen erfaring med visuel systemudvikling; men vi er blevet inspireret af diskussioner med kolleger og medstuderende i forbindelse med dette speciale.

En anden vigtig inspirationskilde har været en artikel af Alexander Repenning og Tamara Sumner [Repenning95].

Figur 4-1. Den visuelle systemudviklingsproces.

Efter vores mening kan den visuelle systemudvikling blive en ny grundfilosofi indenfor systemudvikling på linie med den hierarkiske og den objektorienterede filosofi. Til illustration af vores opfattelse har vi fremstillet figur 4-1, som en pendant til beskrivelserne af den hierarkiske og den objektorienterede systemudviklingsfilosofi i figur 2-10 og 2-11.

Det væsentlige i modellen er, at aktiviteten realisering har bevæget sig fra at være en aktivitet udført af programmører i computerens domæne til at være en aktivitet, hvor brugere og systemudviklere kan mødes på neutral grund med et visuelt programudviklingsmiljø som kommunikationsmedie.

Tidligere har brugerdeltagelse været forbundet med udvikling af prototyper, som blev udviklet netop med henblik på kommunikation med brugerne i en proces, hvor det handlede om at få fastlagt specifikationen af systemets virkemåde. I den endelige realisering er prototypen ofte blevet smidt væk og erstattet af "rigtige" programmer.

Hvis realiseringsaktiviteten virkelig flytter sig som beskrevet i modellen bliver de nye spørgsmål: hvad så med aktiviteterne analyse og design?

Efter vores mening er der i hvert fald et uændret behov for analyseaktiviteten. Den abstrakte model, der er resultatet af analyseaktiviteten, er livsvigtig for systemudviklerne i deres bestræbelser på at skaffe sig overblik over det kommende system. Modellen tjener ofte også som bilag i forbindelse med specificering af systemet i kontrakter og lignende.

Vi har blot skrevet analyse i aktiviteten på figur 4-1; men i en tidligere udgave af modellen stod der objektorienteret analyse. Det havde vi skrevet, fordi objektorienterede fremgangsmåder efter vores mening er bedre og især langt hurtigere til at skaffe sig overblik end de strukturerede fremgangsmåder; men strengt taget kan man uden problemer bruge en struktureret fremgangsmåde.

Når vi er af den opfattelse, at den objektorienterede fremgangsmåde giver hurtige resultater, er det med henvisning til bl.a. objektorienteret analyse af Lars Mathiassen m.fl. [Mathiassen93], hvor man fremhæver, at der skal fremstilles en kortfattet dokumentation af høj kvalitet. Det er en opfattelse, som vi er helt enige i. Efter vores mening vil en sådan analyse i langt de fleste tilfælde kunne gennemføres på to - tre uger - i øvrigt også med aktiv deltagelse af brugerne - hvorefter man kan gå i gang med realiseringen.

Jamen hvad så med designet? vil nogen sikkert spørge. Efter vores mening er designaktiviteten integreret i realiseringsaktiviteten. Det, man skal være særlig opmærksom på i denne forbindelse, er at man får dokumenteret de designbeslutninger, der træffes i forbindelse med realiseringen.

Disse designbeslutninger får man helt sikkert brug for at konsultere (og måske ændre) mange gange i løbet af realiseringen. Derfor har vi også tegnet en dobbeltrettet pil mellem realisering og designdokumentation. Man skal heller ikke glemme, at systemudvikleren stadig vil have brug for de abstrakte beskrivelser, som bedre end den konkrete virkelighed er egnet til at give overblik.

Som eksempel vil vi vise en situation fra løsningen af en opgave i Delphi, hvor man under realiseringen var tæt på at miste overblikket. Opgaven bestod i, at man skulle udvikle et bibliotekssystem, der kunne bruges til registrering af tidsskriftartikler i en database med henblik på senere søgning i databasen.

I figur 4-2 er vist et layout for det primære skærmbillede til systemet. Dette layout er den tredie i rækken af i alt 6 prototyper, der blev fremstillet. Den bagvedliggende database består af fire tabeller: Bogtabel med beskrivelse af bog/tidsskrift, Beskrivelsestabel med sammendrag af artikler, nøgleordstabel med nøgleord knyttet til en bestemt artikel og en synonymtabel med synonymer for nøgleord.

Som det fremgår af skærmbilledet manglede man i denne tredie prototype stadig at få tilføjet nøgleordene; men det var planlagt, at de i den fjerde prototype skulle tilføjes til beskrivelsespanelet.

Skærmbilledet består ud over beskrivelsespanelet af et bogpanel og et database navigationspanel, som skal være fælles for de to andre paneler. Navigationspanelet skal virke på det panel, der har kontrollen, hvilket skiftes med radioknapper i øverste venstre hjørne af panelerne.

Hvis man ikke har opdaget det før, går det op for én i forbindelse med realiseringen, at der er et tidsmæssigt forhold mellem de forskellige hændelser, der kan forekomme i systemet. Hændelserne udløses primært ved tryk på skærmbilledets knapper med musen eller ved aktivering af de tilsvarende genvejstaster på tastaturet.

Der er hændelser, der skal forekomme i en tvungen sekvens, og der er hændelser, der udelukker andre hændelser. Det kan man afbilde i skærmbilledet ved midlertidigt at aktivere og deaktivere de forskellige knapper og menupunkter.

Figur 4-2. Layout for skærmbillede til et bibliotekssystem.

Hvis man f.eks. har trykket på knappen "Ny", fordi man vil indsætte en ny bog i bogtabellen, kan det ikke nytte noget, at man tillader brugeren bagefter at navigere frem og tilbage med knapper som "Første", "Næste" osv. Faktisk er de eneste tilladelige hændelser i denne situation, at brugeren trykker på "OK" for at oprette en ny bog, eller på "Fortryd" for at fortryde.

Når man trykker på "Ny", skal alle andre muligheder end "OK" og "Fortryd" faktisk blændes af. Hvis oprettelsen går godt, eller hvis man fortryder, genaktiveres de afblændede muligheder. Til gengæld afblændes "OK" og "Fortryd", indtil der bliver brug for dem igen. Typisk nok er der ingen lærebøger i visuel programmering, der omtaler netop denne problemstilling, som ellers må siges at være særdeles relevant i praksis.

Løsningen blev i vort tilfælde såre simpel, idet vi valgte at beskrive forløbet af programmets tilstandsskift ved hjælp af et tilstandsdiagram. Det er nu fast rutine for os i forbindelse med udvikling af visuelle programmer, at udarbejde et tilstandsdiagram for alle forms, som indeholder noget ud over det helt trivielle.

I figur 4-3 er vist et tilstandsdiagram, der svarer til skærmlayoutet i figur 4-2.

Det er diagrammer af denne type, der efter vor mening er resultatet af en designaktivitet, der opstår mere eller mindre spontant i forbindelse med realiseringen. I dette tilfælde er der tale om et formelt diagram med tilhørende tegneregler, så systemudvikleren er nok ikke i tvivl om, at det har værdi som dokumentation og derfor skal gemmes.

Værre er det med de mange mere eller mindre uformelle skitser og udkast til layout og løsningsforslag, der udarbejdes spontant under realiseringen. Der er en reel fare for, at disse finder vej til papirkurven i stedet for til dokumentationsmappen. Efter vores mening må det betegnes som en dødssynd at smide noget væk, der senere kan tænkes at få værdi som dokumentation. Hvis systemudvikleren er i tvivl, er det vores opfattelse, at han hellere må gemme end smide væk.

Figur 4-3. Tilstandsdiagram for bibliotekssystem.

Dette afsnit er inspireret dels af de muligheder, der tilbydes i de visuelle programudviklingsmiljøer, og dels af en artikel af Alexander Repenning og Tamara Sumner i IEEE Computer fra marts 1995 [Repenning95].

Et afgørende spørgsmål i enhver systemudvikling er, hvordan man sikrer, at det system, der er resultatet af processen, bliver så brugbart som muligt. En metode til sikring af kvaliteten er at lade brugerne deltage i processen; men som regel er brugerne kun med i de indledende analyseaktiviteter. Analysen er den aktivitet, hvor systemets begrebsapparat defineres og hvor funktionaliteten specificeres. Man definerer hvad opgaven går ud på.

Når brugeren ikke deltager senere i processen hænger det sammen med, at aktiviteterne design og programmering handler om at definere hvordan opgaven skal løses. Dette forhold er stærkt bestemmende for udformningen af de værktøjer der bruges i design og programmering. Det kræver specielle forudsætninger at bygge bro mellem den begrebsmæssige model og den computerbaserede model i programmet - forudsætninger som man ikke med rimelighed kan forvente hos en almindelig bruger.

De visuelle værktøjer åbner en ny mulighed for at bygge bro mellem den begrebsmæssige og computerbaserede model. Begrebet visualisering kan defineres som en syntaktisk egenskab, som beskriver, hvordan begreber skal præsenteres [Repenning95], og her kan også brugere deltage.

Repenning og Sumners artikel handler om udvikling af domæne-specifikke visuelle programmeringsværktøjer. De programudviklingsværktøjer, vi har beskæftiget os med, er rettet mod løsning af generelle problemstillinger; men efter vores mening kan den udviklingsmetode, Repenning og Sumner foreslår, uden videre overføres til løsning af generelle problemer.

Den systemudviklingsproces, Repenning og Sumner foreslår, kalder de samarbejdende design, og den består af 5 trin, der gentages i en iterativ proces. De fem trin er

1. Brugeren afprøver systemet (prototypen) ved at prøve at løse en typisk forekommende opgave fra forretningsområdet.
2. På et eller andet tidspunkt oplever man et sammenbrud, hvor prototypen ikke løser opgaven som forventet.
3. Brugeren og systemudvikleren forhandler om, hvordan problemet skal løses.
4. Systemudvikleren ændrer prototypen, som man er blevet enige om det.
5. Systemudvikleren tester, om systemet virker efter hensigten efter ændringen.

Herefter vender man tilbage til punkt 1 og begynder på en ny cyklus i iterationen.

Hele processen kan illustreres grafisk som vist i figur 4-4.

Det usædvanlige ved den her beskrevne udviklingsproces er at ændringerne af prototypen foretages i real-tid, mens brugeren kigger med. Det er selvfølgelig langt fra hele systemudviklingen, der skal foregå på den skitserede måde. Det vil i det lange løb blive for ineffektivt. Såvel bruger som systemudvikler har brug for perioder i selskab med ligesindede for at undgå, at det skal gå dem ligesom de antropologer, som har opholdt sig så længe sammen med indianerne, at de selv er begyndt at opføre sig som indianere.

Indledningsvis må man også forestille sig, at systemudvikleren alene har fremstillet den første prototype, sådan at man har noget at afprøve, når man mødes. Tilsvarende vil det være naturligt at afbryde mødet, når systemudvikleren kan forudse, at en aftalt ændring vil tage så lang tid at lave, at det ikke giver mening at lade brugeren sidde og vente imens ændringen foretages.

Meningen med at lade parterne observere hinanden arbejde er bl.a., at de herigennem forhåbentlig får en bedre indsigt i og respekt for hinandens arbejde.

Figur 4-4. Skematisk oversigt over udviklingsprocessen i samarbejdende design.

Samarbejdende design kan naturligvis kun fungere som beskrevet, hvis programudviklingsmiljøet tillader det; men vi mener at den beskrevne arbejdsform vil være ideel til løsning af meget komplekse opgaver, som man f.eks. finder i forbindelse med sagsbehandling og lignende opgaver. Derfor vil vi også i taksonomien medtage et kriterium, der kan fortælle, om udviklingsværktøjet tillader samarbejdende design.

Som det blev nævnt i forbindelse med gennemgangen af de visuelle programudviklingsmiljøer i kapitel 3 er der behov for et stort antal forskellige repræsentationer til opbevaring af informationer om de datastrukturer, der tilsammen udgør et visuelt program.

Mange af disse repræsentationer er vanskelige at dokumentere i traditionel forstand, hvor man laver udskrifter på papir af de kildetekster, som programmet består af.

Det gør kun ondt værre, at systemudviklingsprocessen tilsyneladende også er i fare for at blive meget fattig på dokumentation. Vi har f.eks. beskrevet en systemudviklingsproces, som kaldes samarbejdende design, hvor bruger og systemudvikler i samarbejde udvikler og afprøver prototyper. Problemet er, at hverken bruger eller systemudvikler føler behov for dokumentation af en proces, hvor begge parter har oplevet processen på nærmeste hold. Begrundelsen for at lave dokumentation er tit, at man laver den af hensyn til dem, der ikke havde mulighed for at deltage i processen.

Vi har forsøgt at tage højde for den manglende dokumentation ved i vores visuelle systemudviklingsmodel at fremhæve, hvor vigtig dokumentationen er. Vi lægger således vægt på at der laves en analyse inden selve programmeringen påbegyndes. Resultatet af denne analyseproces dokumenteres, bl.a. fordi det skal være med til at afklare tvivlsspørgsmål, der måtte opstå senere i forløbet.

Opdateret 12. oktober 1997