Datalogi 0 GA 2002 Rapportopgaven K: grafisk sprog

Transkript

1 Datalogi 0 GA 2002 Rapportopgaven K: grafisk sprog Espen Højsgaard Rune Højsgaard 1

2 Resumé BEMÆRK: Denne version af dokumentet er mangelfuld; kildekode samt flere figurer manger. Er du interesseret, kan en komplet version genereres - mail rune@hojsgaard.dk. Indhold 1 Sammenfatning Vores løsning Resultat Forløb Problemorienteret analyse Notation Hovedoperator side Grundlæggende egenskaber for en side Størrelsesangivelse Værktøjer Opsamling Begrænset implementation Tilnærmelse Programmeringsovervejelser Overordnet forløb Datatyper og algoritmer Fleksibel samling af data Intern DVI Størrelser Halerekursion Advarsler og fejl Konsistente meddelelser Options Tegning Værktøjer Tegnekontekst Tegneresultat Hjælpefunktioner Optimering Oversættelse Programbeskrivelse Læsevejledning Kommentarer i koden Typer, datastrukturer og undtagelser Gennemgang af modulerne Uafhængige hjælpefunktioner, datatyper og funktore Advarsler Fejl

3 4.4.4 Enheder Papirstørrelser Options Værktøjer intern DVI til symbolsk DVI Anvend værktøjer Hoved del Programmerings Miljøet Afprøvning Afprøvningsstrategi Ækvivalensklasser Generelt om længde enheder Generelt Options Værktøjer cirkel definer linie rektangel Test længdeenheder generelt options Værktøjer Cirkel Definer Linie Rektangel Opsumering Brugervejledning Det kan Knap Så CAD Installation Ind- og uddata S-udtryk Enheder Indstillinger Værktøjer cirkel rektangel linie definer Fejl og advarsler Kendte fejl A Overordnet flow 53 3

4 B Obligatorisk tegningsbeskrivelse 54 C Udskrift fra obligatorisk tegning 56 D Obligatorisk tegning 57 E Gyldigt inddata - beskrivelse 1 58 F Gyldigt inddata - tegning 1 60 G Gyldigt inddata - beskrivelse 2 61 H Gyldigt inddata - tegning 2 62 I Juletræ - beskrivelse 63 J Juletræ - tegning 68 K Kildekode 69 L Litteratur 101 4

5 1 Sammenfatning Dette er en besvarelse af den karaktergivende rapportopgave på Datalogi 0 GA 2002, Københavns Universitet [1]. Læseren forventes at have læst opgaveformuleringen samt at have et kendskab til Moscow ML 2.0 svarende til en elev, der har fulgt kurset. Formålet med opgaven var at udvikle en notation til beskrivelse af simple stregtegninger samt at implementere denne notation i et program, der kunne generere den tilsvarende tegning i formatet DVI. 1.1 Vores løsning Vores ambitioner for notationen var, at den skulle være intuitiv og hensigtsmæssig for brugeren samt være fleksibel i sine konventioner, så den senere ville kunne udvides og få større anvendelsesmuligheder. I tråd med dette, var vores mål med programmet at lave en grundstruktur, der ville kunne følge med udviklingen af notationen Resultat Resultatet er blevet en notation og et program, der lever op til opgaveformuleringens krav, men som i funktionalitet ikke strækker sig væsentligt udover disse krav. Det er derfor svært at bedømme om notation og program lever op til vores ambitioner om at være fleksible, men vi tror at begge på trods af visse uhensigtsmæssige aspekter faktisk ville kunne udvides og gøres særdeles brugbare. Med hensyn til brugervenlighed, så er det vores egen oplvelse at både notation og program er lette at bruge og at meddelelserne fra programmet er konstruktive. Vi har i vores afprøvninger erfaret en enkelt fejl, der kan resultere i at programmet stopper, uden at give en sigende fejlmeddelelse til brugeren. Dette skyldes en overløbsfejl, der ikke bliver fanget. Fejlen er dog ikke af stor betydning, da det inddata, der fremprovokerer den, alligevel ville resultere i en fejlmeddelelse til brugeren Forløb Opgaveforløbet har været præget af, at vores ambitioner nok har været lidt for store, i forhold til vores erfaring med denne type opgaver. Vi er dog alligevel tilfredse med resultatet, men har noteret os en række ting, der kunne have været udført mere hensigtsmæssigt. Af de mere betydende er f.eks. at vi bruger en række binære træstrukturer, hvoraf kun få bliver lavet med samme funktor. Ved at have udvidet funktionaliteten af denne funktor, kunne den have været grundlag for samtlige af disse træstrukturer, hvilket ville have gjort koden mere klar og sparet en del linier. Et andet punkt, hvor programmet kunne have været klarere og kortere, er i forbindelse med samlingen af hjælpefunktioner til vores værktøjer. Denne samling kunne med fordel have været udvidet, da vi bagefter har konstateret, at flere af værktøjerne foretager ens rutiner, der med fordel kunne have været generaliseret. 5

6 2 Problemorienteret analyse Det overordnede formål med denne opgave er, som beskrevet i opgaveformuleringen [1], at fremstille et program, der kan oversætte en tekstbaseret beskrivelse af en tegning til en binær 1 repræsentation af tegningen. En væsentlig del af opgaven er at udvikle en for brugeren hensigtsmæssig notation med hvilken simple stregtegninger kan beskrives. Da denne notation ligger til grund for resten af opgaven, vil vi starte med at afdække dette problemdomæne. 2.1 Notation Det er et krav for notationen, at den skal følge konventionerne for S-udtryk [1, s. 1] og en beskrivelse af disse konventioner kan findes i opgaveteksten [1]. Udover denne begrænsning, så pålægger opgaveformuleringen os et minimumskrav: notationen skal kunne beskrive tegningen på s. 15 i [1]. Da tidsrammen for denne opgave ikke giver mulighed for at interviewe brugere og dermed afdække de behov, som notationen skal kunne dække, vil vi fokusere på at notationen bliver meget fleksibel. På den måde undgår vi at lave en notation, der efter kort tids anvendelse viser sig at have væsentlige begrænsninger, der ikke kan overkommes uden fundamentale ændringer Hovedoperator side Det er vores opfattelse at tegninger oftest skal bruges på papir og det vil derfor være oplagt at udnytte brugerens associationer i den retning, ved at bruge termer og konventioner fra dette medie. Som grundlæggende begreb og operator vælger vi derfor at bruge side, der afpejler den begrænsede tegneflade, som den ene side af et ark papir udgør. Dette valg udelukker at brugeren angiver tegninger på flere sider i en fil, men da det er simple stregtegninger, der skal kunne beskrives, mener vi ikke at dette er en væsentlig begrænsning Grundlæggende egenskaber for en side Da der findes mange papirformater, vil det være meget begrænsende for brugeren, hvis han 2 ikke har mulighed for at vælge, hvilket format han vil tegne på. Det skal derfor i notationen være muligt at angive papirets format. Endvidere vil man ofte af tekniske eller layoutmæssige årsager gerne operere med en margin. Det er selvfølgeligt muligt for brugeren selv at sørge for at overholde en margin, men det vil være bekvemt at kunne angive marginstørrelsen og derefter kunne fokusere på selve tegningen. Vi vælger derfor at indføre en operator i notationen, der kan specificere en margin. Da margin ikke nødvendigvis er ens langs hver af papirets kanter, skal margin kunne angives separat for hver kant. En sidste generel angivelse, som vi mener er praktisk at kunne angive for en tegning, er et størrelsesforhold. Hvis tegningen f.eks. skal forestille noget i den virkelige verden et grundplan f.eks. så vil det være mest hensigtsmæssigt for brugeren, hvis han kan angive de faktiske mål samt størrelsesforholdet frem for manuelt at skulle omregne hvert enkelt mål, så det passer til tegningen. En ofte anvendt notation for størrelsesforhold, er at skrive x:y, hvor x og y henholdsvis er dividend og divisor i en brøk af heltal, der udtrykker skaleringsfaktoren. 1 med binær forstås ikke-tekst 2 Denne opgavebesvarelse bruger konsekvent han for ubestemte personer, men disse kunne ligesågodt være benævnt hun 6

7 Da dette er en almindeligt kendt notation f.eks. ofte brugt på kort vælger vi at assimilere den. Da vi har ikke belæg for at antage at de tre nævnte grundlæggende valgmuligheder er tilstrækkelige og da vi som sagt stræber efter en fleksibel notation, finder vi det nødvendigt at notationen skal kunne tolerere vilkårlige parametre, der forventes at have indflydelse på hele siden. Standardværdier For alle tre parametre, vil det være en fordel for brugeren, hvis han ikke behøver at angive dem, men i stedet kan antage at de har en standardværdi. Da der i sagens natur ikke er en skala, der kan bruges både i mikro- og makroskopiske kontekster, vil et størrelsesforhold på 1:1 være et naturligt valg som standardværdi, således at den faktiske størrelse stemmer overens med den brugeren angiver i beskrivelsen af tegningen. Til margin har vi ikke kunnet finde anden standard -margin end den det endelige format, DVI, har som udgangspunkt, nemlig én engelsk tomme til venstre og foroven. I mangel af andre kandidater vælger vi at bruge denne størrelse til alle fire sider. Papirstørrelsen vælger vi ud fra egne behov skal have A4-fomatet som standard-værdi. Dette skyldes at notationen for os mest oplagt blive anvendt til diagrammer i rapporter, der afleveres i dette papirformat. options De tre ovenstående parametre har alle indflydelse på hele tegningen. Det vil derfor ikke være hensigtsmæssigt i.f.t. til læsbarheden af notationen og endvidere sjældent brugbart hvis notationen tillader at disse parametre ændres løbende, hvilket vi derfor udelukker. Da parametrene således kun kan sættes en gang og da de har stor indflydelse på tegningen som hele både forståelsesmæssigt og teknisk vil det ikke være et urimeligt krav, nok nærmere en hjælp, at kræve at de skal angives som det første i en tegning. For at markere disse parametres særlige status, som grundlæggende valgmuligheder for tegningen, vælger vi at samle dem under en operator. Denne får i mangel af et kortere og bedre dansk ord navnet options. Indførelsen af denne operator er endvidere nødvendig, hvis vi skal leve op til kravet om, at vilkårlige parametre med samme virkefelt som de tre nævnte skal tolereres. Hvis der ikke var en overordnet operator til at adskille denne type parametre fra resten af tegningsbeskrivelsen ville dette krav medføre, at alle operatorer ville blive klasificeret som grundlæggende valgmuligheder, hvorved vi var afskåret fra at indføre andet end denne slags operatorer. Rækkefølge Hvis vi vedtager at grundlæggende valgmuligheder, der er direkte under options operatoren, ikke må være indbyrdes afhængige, så kan vi uden problemer lade deres rækkefølge være uden betydning. Denne konvention vil rent faktisk ikke gøre det umuligt at angive grundlæggende options, der er indbyrdes afhængige, men forudsætter blot at de bliver samlet under en fælles operator. For brugeren betyder det at han ikke skal huske om margin skal angives før skala eller omvendt. Den eneste rækkefølge som vi mener kunne være logisk ville være alfabetisk, men valgfrihed på dette punkt betragter vi, som værende en fordel. Indførte operatorer I dette afsnit har vi fastlagt, hvordan brugeren skal kunne angive grundlæggende valg for tegningen. Vi har fastlagt tre valgmuligheder og deres standardværdier, 7

8 samt vedtaget at tolerere angivelsen af andre valgmuligheder, hvis betydning endnu ikke er bestemt. Disse valgmuligheder skal i vilkårlig rækkefølge samles under operatoren options, der skal være det første i tegningsbeskrivelsen. Dette giver os foreløbigt følgende struktur for en tegningsbeskrivelse side options margin top og bund højre og venstre Den øverste operator i hierakiet. Operanden options er valgfri, men skal være den første operand, hvis den er angivet. Operator, hvis operander angiver grundliggende valgmuligheder for tegningen. Ingen af operanderne behøver at være angivet og deres rækkefølge er irrelevant. Angiver margin for hver af papirets kanter. Standardværdien er én engelsk tomme for alle fire. Angiver henholdsvis øverste og nederste margin. Angiver henholdsvis højre og venstre margin. papirstørrelse Angiver papirets størrelse. Standardværdien er A4. skala Angiver størrelsesforholdet for tegningen i på formen x:y. Standardværdien er 1:1.. Endnu udefinerede operander, der ikke må have samme navn som de tre foregående, men som skal tolereres Størrelsesangivelse Vi har allerede været inde på en operator, der har brug for størrelsesangivelser eksempelvis 2 cm nemlig margin. Da man i de fleste sammenhænge efterstiller enheden for længder, vil vi i vores notation opfordre til at samme konvention følges. For dog at åbne muligheden for at enheden i andre typer størrelsesangivelser kan foranstilles uden tab af læsbarhed, så vælger vi at kræve, at alle størrelsesangivelser skal omsluttes af parenteser. På den måde vil det altid være entydigt om en enhedsangivelse er foran- eller efterstillet, hvilket må siges at øge læsbarheden uden tab af fleksibilitet. Eksempel Længden to centimeter udtrykkes (2 cm. Længdeenheder Da notationen tager udgangspunkt i det danske sprog og forventes at blive anvendt af danskere, er det oplagt at notationen skal omfatte enheder fra det metriske system. Der er dog også i en dansk kontekst ofte brug for andre systemer, men da vi ikke har kendskab til hvilke, der er særligt relevante en prioritering, der formentlig er forskellig fra bruger til bruger og da vi ikke allerede har kendskab til, og ikke har tiden til at undersøge, alle enhedssystemer, vælger vi kun at bruge metersystemet i denne udgave af notationen. Det må dog understreges at en udvidelse af mulighederne på dette område har høj prioritet i en senere revidering, hvilket implementerende programmer bør tage højde for. De længdeenheder, der som minimum skal kunne bruges i notationen, har vi valgt skal være: millimeter, centimeter, meter og kilometer. 8

9 2.1.4 Værktøjer Vi er nu kommet til den del af notationen, hvor de operatorer, der producerer den egentlige tegning, skal defineres. I et forsøg på at følge vores analogi til den virkelige verden vil vi benævne disse operatorer, tegneværktøjer eller blot værktøjer. Som med operanderne til options, så vil vi ikke på forhånd fastlægge samtlige muligheder, men blot definere et minimum af værktøjer, der på fornuftig vis gør det muligt at lave den obligatoriske tegning. Før vi kommer nærmere ind på de konkrete værktøjer, som vi vil fastlægge i denne udgave af notationen, vil vi først fastlægge de generelle regler for tegneværktøjer og deres notation. Navn Vi vælger, at hvert værktøj skal have et navn, der ifølge konventionerne for S-udtryk (se [1] er et atom. Dette udelukker bl.a. at brugeren bruger mellemrum, men dette er ikke en væsentlig begrænsning, da man ved at bruge tegnet _ kan opnå en læsevenlig opdeling af ordene. Man kunne i stedet vælge at navne skulle bestå af en række operatorer eller måske af en enkelt operator med en eller flere operander, men vi mener at disse fremgangsmåder vil komplicere notationen unødigt og at den valgte konvention er fuldt tilfredstillende til navngivning. Da operatoren options har en særlig betydning når den optræder som første operand til side, vil vi, for at undgå misforståelser hos brugeren, udelukke at værktøjer kan have navnet options. Struktur og placering Da navnet på et værktøj formentlig er det, der i tekstform frembringer de grundlæggende associationer til dets anvendelse og ikke de nærmere detaljer som f.eks. størrelsen så vil det være logisk for brugeren at skulle angive navnet på det værktøj han vil anvende før han angiver detaljerne. Derfor vælger vi at lade detaljerne være operander til værktøjets navn, hvorved det også vil være tydeligt, hvilke detaljer, der hører til hvilket værktøj. Da vi ikke mener, at der er brug for flere grundlæggende operander til side end options og værktøjsnavne, så vedtager vi, at alle operander direkte under side er værktøjer, med undtagelse af options. Positionering af værktøjer En vigtig ting når man skal beskrive en tegning, er beskrivelsen af hvor de forskellige dele befinder sig. Da dette er gennemgående for alle de værktøjer, der har en synlig indflydelse på tegningen, vil det for brugeren være nemmest, hvis disse værktøjer deler den samme notation for positionering. I det følgende vil vi derfor fastlægge en sådan. Absolut placering De fleste er fra flere sammenhænge vant til at arbejde med koordinater og har en intuitiv forståelse af koordinatsystemer. Det er derfor oplagt at opfatte et ark papir som et udsnit af en plan i et to-dimensionalt, retvinkelt koordinatsystem. Spørgsmålet er blot hvorledes akserne skal være orienteret og hvor origo skal placeres. Man kunne bl.a. vælge et kartesisk koordinatsystem, med origo i nederste venstre hjørne. Der er dog flere ting, der taler imod dette valg. Den vigtigste for brugeren er det faktum, at vores notation indeholder marginangivelser, og fordelen ved disse er (jf. afsnit netop at brugeren ikke selv skal tage højde for marginen i selve beskrivelsen af tegningen. Derfor vil det være logisk at placere origo i et af skæringspunkterne mellem de fire marginer. Som det andet, så vil et koordinatsystem 9

10 med 2.-aksen rettet nedaf være nemmere at implementere, da DVI-formatets koordinatsystem er indrettet på den måde. Vi vælger derfor et koordinatsystem, hvor origo er placeret i skæringen mellem den øverste og den venstre margin og hvor 1.-aksen løber mod højre parallelt med papirets vandrette kanter og 2.-aksen nedaf, vinkelret på 1.-aksen. Placering direkte i dette koordinatsystem vil vi kalde for absolut placering. Denne betegnelse vælger vi fordi det for visse værkøjer kan være praktisk at operere med et andet koordinatsystem, og placering i et sådant vil vi kalde relativ placering, således at det er tydeligt, hvornår der er tale om hvilken type placering. Relativ placering En relativ placering vælger vi som sagt skal være afhængig af konteksten, der kan fastlægge et referencepunkt, et midlertidigt origo. For værktøjer på yderste niveau vil relativ placering svare til absolut, da side er disse værktøjers kontekst og det absolutte origo er jo netop defineret ud fra side. Man kunne vælge at tillade relative koordinatsystemer, hvor orienteringen af akserne var anderledes end ved den absolutte placering, men det ville kun øge funktionaliteten betydeligt, hvis der var tale om ikke-retvinklede systemer. For andre retvinklede systemer er det blot et spørgsmål om andre fortegn til koordinaterne. For de ikke-retvinklede vil komplikationerne for værktøjerne være så betydelige, at vi i denne generelle placeringsnotation ikke vil tillade dem. Relationel placering Vi er i dagligdagen vant til at placere ting i forhold til hinanden, f.eks. stolen står til højre for bordet. Denne intuitive placeringsmåde vil vi inkludere i vores notation; det skal være muligt at placere værktøjer der er på samme niveau i strukturen i forhold til hinanden. En sådan placeringsnotation skal være konsistent selvom den bliver anvendt af forskellige typer værktøjer der kan have forskellige former og resultatet skal være forudsigeligt. Vi vælger derfor, at hvert værktøj skal definere en rektangulær boks, der kan bruges til denne type placering. Boksen kunne også have andre former, men vi mener at rektangler muliggør mange placeringer samtidig med at de er ret intuitive. For rektangler er der fire overordnede placeringer, der er oplagte: til venstre og højre samt over og under. Disse angiver dog kun placeringen i en dimension og vi udvider dem derfor med tre hver: højre og venstre: oppe, nede og midt for over og under: til venstre, til højre og midt for Der er selvfølgelig uendeligt mange andre muligheder, men vi mener at disse giver tilstrækkeligt med muligheder uden at gøre det uverskueligt. Følgende tabeller beskriver, hvorledes disse placeringer skal fortolkes og figur 1 illustrerer det. Kolonnerne repræsenterer hovedangivelserne mens rækkerne er de nærmere specificeringer. (1 er det rektangel, der placeres i forhold til og (2 er det rektangel, der placeres 10

11 oppe nede midt for højre: (2 s venstre kant ligger op ad (1 s højre venstre: (2 s højre kant ligger op ad (1 s venstre (1 og (2 s øverste kanter ligger i forlængelse af hinanden (1 og (2 s underste kanter ligger i forlængelse af hinanden (1 og (2 er centreret om samme vandrette akse til venstre til højre midt for over: (2 s underste kant ligger op ad (1 s øverste under: (2 s øverste kant ligger op ad (1 s underste (1 og (2 s venstre kanter ligger i forlængelse af hinanden (1 og (2 s højre kanter ligger i forlængelse af hinanden (1 og (2 er centreret om samme lodrette akse Figur 1: Placering af det lille, udfyldte rektangel i forhold til det store position For at samle positionsangivelsen i en enhed og dermed tydeliggøre hvordan et værktøj bliver placeret, indfører vi operatoren position, der skal have en af følgende strukturer: (position absolut længde længde (position relativ længde længde (position <højre venstre> <oppe nede midt_for> 11

12 (position <over under> <til_højre til_venstre midt_for> hvor længde er en længdeangivelse, som diskuteret i afsnit <op1 op2 > betyder at der er valgfrihed mellem operanderne op1 og op2, men at én af dem skal vælges. Hvis brugeren ikke angiver en position, vedtager vi at værktøjet vil blive placeret, som om en relativ position med koordinaterne (0,0 var angivet. Dette er for at følge ideen fra options om at tillade standardværdier. rektangel Det første værktøj vi vil definere i notationen, er rektangel. De følgende ting mener vi er væsentlige for brugeren at kunne angive ved tegning af rektangler bredde og højde stregtykkelse om det skal være udfyldt positionen Af disse vil vi kun kræve at bredden er angivet, da vi ellers er bange for at lægge op til, at værktøjet kunne have en variabel størrelse alt efter konteksten. Dette er ikke meningen med dette værktøj, men kunne være en interessant ide ved en senere tilføjelse af nye værktøjer. For højdens vedkommende, mener vi at det vil være en fordel for brugeren, hvis han kan lave et kvadrat uden at skulle angive to sidelængder. Derfor lader vi højdens standardværdi være bredden. Det er vores erfaring fra forskellige tegneprogrammer, at stregen langs en linie sværter en halv tykkelse på hver side. Denne konvention vælger vi også at følge i denne notation, da de fleste brugere vil kende den. Den synlige effekt af denne beslutning er, at et rektangel med en bredde på 2 cm og en stregtykkelse på 5 mm, faktisk vil sværte 2,5 cm i bredden. Stregtykkelsens standardværdi skal være 0,4pt, da dette er den stregtykkelse de to i opgaven nævnte tegne-fonte lcircle10 og line10 bruger 3. Da valget om rektanglet skal være udfyldt er et enten-eller valg, så vil det være nemmest for brugeren, kun at skulle angive det ene af tilfældene. Vi vælger derfor at tilstedeværelsen af operanden udfyldt afgør dette. Placering af dette værktøj følger den tidligere i afsnittet udviklede notation. Ved absolut og relativ placering, er det det øverste venstre hjørne uden stregtykkelsen af rektanglet der placeres. Ved relationel placering, placeres der ud fra den angivne bredde og højde. Følgende er en tabel over de operander, der kan bruges til rektangel med angivelse af deres betydning og krav/begrænsninger. Position er blot nævnt uden detaljer, da disse er blevet gennemgået fyldestgørende tidligere i afsnittet. Denne tabelform vil vi også bruge for de andre værktøjer. 3 Dette kan læses i deres definitionsfiler lcircle10.mf og line10.mf, der er tilgængelige på CTAN i mappen fonts/latex/mf/ (f.eks. på adressen 12

13 operand krævet værdier standard eksempel betydning bredde ja 0 ingen (bredde (2 cm Rektanglets bredde med enhed højde nej 0 bredde (højde (2 cm Rektanglets højde med enhed tykkelse nej 0 0,4pt (tykkelse (1 mm Linjernes tykkelse med enhed. Skaleres ikke. udfyldt nej boolsk tom udfyldt Angiver at rektanglet skal være udfyldt. position nej Rektanglets position på standardform cirkel Værktøjet cirkel er et meget simpelt værktøj, der skal kunne tegne cirkelomrids og udfyldte cirkler. Som med rektangel vælger vi at bruge operanden udfyldt. Derudover skal brugeren angive en radius med standard længdeangivelse samt implicit eller eksplicit en position. Absolutte og relative positioner angiver placeringen af centrum, mens relationelle angivelser tager udgangspunkt i det omskrevne kvadrat. operand krævet værdier standard eksempel betydning radius ja 0 ingen (radius (1 cm Cirklens radius med enhed udfyldt nej boolsk tom udfyldt Angiver at cirklen skal være udfyldt. position nej Cirklens position på standardform linie Det er oplagt at en notation til stregtegninger skal have mulighed for at beskrive linier. Det er dog ikke helt lige så oplagt, hvordan det skal gøres. Man beskriver ofte linier, som gående fra et punkt til et andet og dette kunne i vores notation ret intuitivt gøres med to sæt koordinater. Denne beskrivelsesform hænger dog ikke så godt sammen med den relationelle placeringsnotation vi har indført, da det ikke vil være intuitiv at angive start- og slutkoordinater, i et system, hvorefter linjen bliver parallelforskudt til andre koordinater. Man kunne dog vælge at betragte det på den måde at det var linjens koordinatsystem, der blev placeret relationelt, hvorved det måske ville være nemmere for brugeren at forstå hvordan linjer blev placeret relationelt. Vi har dog i stedet valgt en lidt anderledes notation, som vi mener giver brugeren en mere forudsigelig placering. Vi vælger at angive linier i en polær notation, hvor positionsangivelsen tager udgangspunkt i begyndelsespunktet, hvilket for absolut og relativ placering ikke er meget anderledes end 13

14 førnævnte notationsmulighed. Ved relationel placering vælger vi at lade liniens position blive bestemt ud fra et rektangel, hvor både bredde og højde er nul, dvs. et punkt, som vi lader være liniens startpunkt. Et efterfølgende relationelt placeret værktøj skal på samme måde tage udgangspunkt i et punkt-rektangel placeret i liniens endepunkt. På den måde vil det være nemt for brugeren at forbinde værktøjer med linier ved hjælp af relationel placering. operand krævet værdier standard eksempel betydning vinkel ja 0 ingen (vinkel (20 grader Liniens vinkel i forhold til 1.-aksen længde ja 0 ingen (længde (2 cm Liniens længde med enhed position nej Liniens position på s- tandardform definer Som nævnt i overvejelserne om positioneringsnotationen, så kan det for nogle værktøjer være praktisk at kunne operere med et andet koordinatsystem end det absolutte. definer er et sådant værktøj. Hovedformålet med definer er at tillade brugeren at definere genbrugelige tegningsdele bestående af andre værktøjer; en sættekasse kunne man kalde det. definer fastlægger et koordinatsystem, hvor akserne har samme orientering som selve siden, men dets origo ligger ikke fast i det absolutte system. I dette koordinatsystem kan brugeren så placere andre værktøjer med relatativ og relationel placering. definer definerer så et nyt værktøj/operator med sin første operand der skal være et atom som navn. Dette værktøj har brugeren så til rådighed i resten af tegningen og ved absolut og relativ placering at dette nye værktøj, er det origo brugeren placerer. Men hvordan skal det definerede værktøj bruges i relationel placering? Man kunne vælge et placerings-rektangel, der lige præcis omsluttede de indeholdte værktøjers placeringsrektangler. Dette ville give en ret intuitiv placering, men vi har valgt en lidt mere kompliceret konvention, som vi mener vil give brugeren et mere brugbart værktøj. Som det ene vil vi give brugeren muligheden for at definere en bredde og højde, der er uafhængig af det faktiske indhold. På den måde kan brugeren f.eks. definere et mellemrum, der kan bruges ved relationel placering. Eller brugeren kan definere et rektangel, der er mindre end indholdet, hvilket ved relationel placering vil give mulighed for overlapning af værktøjer. Som det andet beslutter vi, at hvis bugeren ikke angiver en bredde og/eller højde, så bliver disse afgjort af de værktøjer, der befinder sig i den positive kvadrant af definer s koordinatsystem. Mere præcist, så lader vi bredden og højden være sidelængderne af at rektangel placeret i det relative origo og som præcist omslutter den del af de indeholdte værktøjers placerings-rektangler, der befinder sig i den positive kvadrant. På den måde behøver brugeren ikke holde styr på hvor stort det, der skal bestemme bredden og højden, er, men kan blot sørge for at det befinder sig i den positive kvadrant. Endvidere har brugeren stadig mulighed for at opnå førnævnte overlapning ved at placere værktøjer eller dele af disse i de tre andre kvadranter. 14

15 operand krævet værdier standard eksempel betydning <navn> ja atom ingen def_vrkt Navnet på det værktøj, der skal defineres. Skal være først <værktøj> nej ingen (cirkel (radius (2 cm Værktøj som skal være indeholdt i det definerede værktøj. nej ingen Opsamling Vi har nu indført de operatorer og operander, der indgår i denne udgave af vores notation samt retningslinierne for tilføjelser. Vi har i notationen taget udgangspunkt i, at værktøjerne ikke er begrænsede i deres tegnemuligheder. Dette skyldes at det vil være hæmmende for brugeren, hvis notationen lader sig begrænse af evt. tekniske vanskeligheder. I stedet vil vi i det følgende afsnit fastlægge retningslinier for hvorledes programmer med begrænsede tegnemuligheder som vores eget bør opføre sig. 2.2 Begrænset implementation P.g.a. af manglende kendskab til DVI-formatet samt en tidbegrænsning for løsning af opgaven, er det ikke muligt for os at implementere den fastlagte notation til fulde. Vi har f.eks. kun mulighed for at tegne cirkler med bestemte størrelser, en begrænsning, som ikke er en del af notationen Tilnærmelse Vi har valgt at programmet skal tegne tegningen så godt det kan lade sig gøre indenfor begrænsningerne og underrette brugeren om de korrektioner programmet har foretaget. Disse underretninger skal så vidt muligt gøre det muligt for brugeren at lokalisere, hvor i tegningen, der er blevet ændret og hvor meget. Denne fremgangsmåde overlader det til brugeren at beslutte om den producerede tegning kan accepteres eller om han bliver nødt til at ændre i beskrivelsen. Relationel placering? Der er dog et væsentligt spørgsmål, der skal afklares for at programmet kan implementere den relationelle placering: skal der placeres efter den størrelse brugeren har angivet eller skal der placeres efter den tilnærmede størrelse? Det andet forslag sikrer at f.eks. to cirkler, der er placeret ved siden af hinanden faktisk også vil blive tegnet helt op ad hinanden. Ved mere komplicerede kæder af relationelt placerede værktøjer vil denne fremgangsmåde dog give et fuldstændig uforudsigeligt resultat. Dette vil også formindske brugerens kontrol over tegningen, hvilket vi ikke mener er hensigtsmæssigt. 15

16 Da vi som sagt vil lade det være op til brugeren at bedømme den tilnærmede tegning og derefter evt. tilrette den, beslutter vi at bruge den størrelse brugeren har angivet til relationel placering, således at han nemt kan forudsige resultatet og dermed bedre kan foretage de nødvendige justeringer. 16

17 3 Programmeringsovervejelser I dette afsnit vil vi afklare, hvorledes vi kan implementere den fastlagte notation; ikke blot i dens nuværende form, men på en fleksibel og fremtidsorienteret måde. 3.1 Overordnet forløb Der er i opgaven stillet moduler til rådighed [1], der kan oversætte S-udtryk fra tekstform til en intern repræsentation og fra symbolsk DVI til DVI. Opgaven for vores program er derfor at fortolke den interne repræsentation af S-udtrykkene ud fra den fastlagte notation, og derudfra producere den tilsvarende symbolske DVI. Overordnet forestiller vi os processen som angivet på figur 2: efter at have oversat tegningsbeskrivelsen til den interne repræsentation af typen exp 4 tolkes de grundlæggende valgmuligheder. Herefter tolkes resten af beskrivelsen, der angiver den egentlige tegning og resultatet heraf er en liste af DVI kommandoer i et internt format. Denne liste kan så optimeres, således at DVI-filen bliver mindst mulig. Efter optimeringen oversætter vi det interne format til symbolsk DVI, der så kan oversættes til DVI og skrives til en fil. Figur 2: Det overordnede forløb fra beskrivelse til DVI Før vi uddyber, hvordan de forskellige dele af programmet skal gribe deres arbejdsopgaver an, vil vi først diskutere hvilke datatyper og algoritmer, der grundlæggende skal bruges i programmet. 3.2 Datatyper og algoritmer I den problemorienterede analyse, besluttede vi, at notationen skulle være meget fleksibel, således at den nemt kunne udvides senere. Denne fleksibilitet vil vi også indarbejde i programmet, således at det uden problemer kan tilpasses i takt med udvidelserne af notationen Fleksibel samling af data De tre områder, som notationen lægger op til skal være fleksible, er: længdeenheder, options og værktøjer. Ud fra vores kendskab til SML, er der grundlæggende to passende fleksible 4 se [1] for beskrivelse af exp 17

18 strukturer: lister og træer. Data i de tre tilfælde kan behandles associativt, dvs. som en entydig nøgle, der passer til en bestemt værdi f.eks. navnet på et værktøj, der er associeret til en tegnefunktion så det er oplagt at sortere data efter nøglerne. Spørgsmålet er så blot om vi skal bruge lister eller binære træer. Effektivitet er ikke væsentlig i denne udgave af programmet, da der ikke er meget data, der skal sorteres og søges i, men det kan i fremtiden blive særdeles relevant, når der kommer flere værktøjer, options og enheder i notationen. I den forbindelse finder vi det sandsynligt, at der i selve tegneprocessen vil blive foretaget væsentligt flere opslag i data end det antal gange, der i initialiseringsfasen og under tegneprocessen vil blive sat data ind. I dette tilfælde vil et afbalanceret, binært træ være at foretrække (jf. s. 150 i [3]. Vi vil i denne udgave derfor bruge binære træer, der senere når behovet opstår kan gøres selvafbalancerende. Eller man kunne f.eks. balancere træet i slutningen af initialiseringsfasen, da man ved at der i denne fase ikke vil blive foretaget opslag Intern DVI Som det kan ses af vores overordnede diagram over forløbet, så har vi valgt at bruge en intern respræsentation af DVI i visse dele af programmet. Dette skyldes at vi gerne ville simplificere tegneprocessen mere herom senere og at vi herefter gerne ville have mulighed for at optimere den genererede symbolske DVI. I symbolsk DVI er der en række kommandoer, med lidt forskellig udformning alt efter talargumenternes størrelse 5. Hver af disse kommandogrupper vælger vi i vores interne repræsentation at samle i en kommando, således at vi indtil oversættelsen til symbolsk DVI kan undgå at skulle overveje, hvilken af kommandoerne, der er mest optimal i.f.t. de argumenter vi giver. Endvidere vil det være nemmere at optimere, hvis kommandoer, der egentlig har samme effekt, kan behandles ens. I vores interne repæsentation af DVI, slår vi derfor f.eks. alle kommandoer, der kan placere et tegn, sammen til én, hvis argument bliver repræsenteret af en int. I den forbindelse er det vigtigt at bemærke, at de DVI kommandoer, der tager fire oktetter som argument, kan tage argumenter, der ligger i intervallet 2 31 c < 2 31 mens heltal i Moscow ML version 2.00 kun kan have værdier i intervallet 2 30 c < Vi mener dog ikke at dette er et problem; tegnsættet Unicode bruger f.eks. kun to oktetter, svarende til intervallet 0 c < 2 16 og vi tror ikke, at der i dette programs levetid vil blive brug for større tegnsæt end dette. For kommandoer, hvor argumenterne angiver længder, vil den maksimale længde vi kan beskrive i den interne DVI-repræsentation være (2 30 1sp = ( , m 5, 76m hvilket er flere gange større end hvad der kan være på et ark A0 (jf. [2], hvilket vi mener er mere end rigeligt Størrelser Da notationen lægger op til at brugeren kan bruge forskellige enhedssystemer og da vi p.g.a. begrænsningerne for brudne tal formentlig ikke kan regne frem og tilbage mellem disse systemer 5 Se The DVI Driver Standard, Level 0, der er vedlagt [1] 18

19 uden tab af præcision, skal vi overveje hvorledes enheder kan repræsenteres hensigtsmæssigt i programmet. Man kunne vælge blot at omregne de angivne størrelser til skalerede punkter så snart man tolkede brugerens input. Dette vil dog give et problem, hvis der i senere udgaver af programmet skal være mulighed for at få skrevet længder ud på tegningen. Disse længder vil sandsynligvis skulle skrives i samme enhed som brugeren har angivet dem i, hvilket ville kræve at de blev regnet tilbage til denne enhed. Dvs. der skulle ske to konverteringer, hvilket højst sandsynligt vil give uhensigtsmæssige præcisionsfejl. F.eks. kunne man forestille sig, at en længde brugeren havde angivet til 2 cm kunne få prædikatet 1, cm 6. For at undgå dette, vælger vi at opbevare størrelser i den enhed/det system de er blevet angivet i og kun omregne til skalerede punkter, når længden skal bruges til tegning. For at dette kan gøres på en fleksibel måde indfører vi en abstrakt type, enhed, der har konstruktører til de relevante enheder/systemer. Konvertering af enheder For på en fleksibel måde at kunne implementere dette system, vælger vi at der for hver enhed, som programmet skal kunne håndtere, skal laves to funktioner: en der kan oversætte en streng til en værdi af typen enhed og en der kan kan lave den omvendte omregning. Disse funktionspar skal jf. afsnit indsættes i en sorteret, binær træstruktur, hvor nøglerne er enhedsangivelsen, f.eks. cm. At hver enhed skal have et unikt navn hvilket et sådant træ forudsætter er ikke et problem, da enheder i notationen er nødt til at være unikke for at undgå tvetydighed. Herudover skal typen enhed evt. udvides, hvis den ikke indeholder en for enheden passende konstruktør. Konvertering til skalerede punkter Konvertering til skalerede punkter skal foretages af en funktion, der kan omregne fra samtlige systemer, der optræder i enhed, til skalerede punkter. Denne funktion vil skulle opdateres hver gang typen enhed ændres Halerekursion Der vil i programmet være en del gennemløb af lister, da typen exp, som programmet gennemgående bruger meget, indeholder en liste. Behandlingen at disse lister vil vi så vidt muligt gøre halerekursiv, da vi ved at Moscow ML 2.0 behandler sådanne funktioner mere effektivt end rekursive funktioner, der både behandler data når de folder sig ud og når de folder sig ind. 3.3 Advarsler og fejl Det er væsentligt for brugere af programmet, at meddelelser er så beskrivende som muligt. Desværre kan vi ikke oplyse linienumre i vores meddelelser, da vi ikke selv står for oversættelsen af beksrivelsen til den interne repræsentation. I stedet vælger vi at oplyse dybdestrukturen til det, der har genereret meddelelsen. 6 antallet af decimaler er ikke baseret på noget teknisk materiale, men skal blot illustrere ideen 19

20 3.3.1 Konsistente meddelelser Som nævnt i afsnit 2.2.1, så har vi besluttet at tilnærme brugerens angivelser ud fra de tekniske muligheder, og derefter informere om tilnærmelsen. Til dette formål vil vi lave et advarselssystem, der udskriver advarsler med specifikationer om, hvad der er tilnærmet og hvor meget afvigelsen er. Ved på den måde at samle advarslerne et centralt sted, er det for det første nemt for en vedligeholder at danne sig et overblik over de mulige meddelelser og desuden vil det være nemmere at gøre advarslerne konsistente, en ting brugeren nok vil sætte pris på. På samme måde vil vi lave et fejlsystem, der udskriver en meddelelse om, hvad og hvor fejlen er og derefter stopper programmet ved at kaste en exception, FATAL_FEJL, der ikke må fanges af programmet. 3.4 Options Det er Options-modulets opgave at tolke evt. options som brugeren skulle have angivet og ellers vælge de passende standardværdier, der kan bruges videre i programmet. Da notationen kun fastlægger tre options, men tillader vilkårlige, er det nødvendigt at den type, som modulet danner af de tolkede options, er fleksibel. Jf. diskussionen ovenfor om fleksible datasamlinger, vælger vi at bruge et binært træ til de options vi endnu ikke kender betydningen af. Man kunne vælge blot at ignorere disse uden at omgås notationen i dens nuværende form, men det kunne tænkes, at der i en senere udgave af notationen ville være værktøjer, der lod grundlæggende parametre blive placeret i options-delen af beskrivelsen. Disse værktøjer vil med den valgte fremgangsmåde have adgang til disse globale parametre uden at Options-modulet ville skulle ændres. De fastlagte options margin, papirstørrelse og skala placerer vi ikke i træet, da de formentlig vil blive tilgået ofte og det vil derfor være mest effektivt, hvis de er direkte tilgænglige. 3.5 Tegning Det modul, vi på det overordnede diagram har kaldt Tegning, er det der skal generere den interne DVI, der tegner de forskellige værktøjer. Da antallet af værktøjer er en fleksibel størrelse allerede i denne udgave af notationen pga. definer vælger vi endnu en gang at bruge et binært træ til opbevaringen af værktøjer. Men hvordan skal vi repræsentere et værktøj? Værktøjer Notationen lægger op til at man opfatter værktøjer som separate enheder, der kan tegne noget veldefineret på tegningen. Dette abstraktionsplan vil vi også følge i programmet. Derfor vælger vi at et værktøj skal være en funktion. Eller rettere: to funktioner. Info Hvert værktøj skal have en funktion, info, der ud fra de argumenter det er givet samt dets kontekst, kan informere om hvor det er placeret og hvor stort dets omgivende rektangel er. Dette er for at et evt. omsluttende værktøj som f.eks. definer kan beregne sin størrelse og placering, uden at der bliver genereret kode (intern DVI. 20