Aalborg University SYNOPSIS: TITEL: TOOL - et objektorienteret sprog for nybegyndere. EMNE: Værktøjer, sprog og oversættere

Størrelse: px
Starte visningen fra side:

Download "Aalborg University SYNOPSIS: TITEL: TOOL - et objektorienteret sprog for nybegyndere. EMNE: Værktøjer, sprog og oversættere"

Transkript

1 Aalborg University Institut for Datalogi, Fredrik Bajers Vej 7E, DK-9220 Aalborg Øst SYNOPSIS: TITEL: TOOL - et objektorienteret sprog for nybegyndere EMNE: Værktøjer, sprog og oversættere PROJEKTPERIODE: 4. februar maj, 2002 PROJEKTGRUPPE E1-207: Mikkel F. S. Andersen Mads Mørk Ole K. Thomsen Lars Otto S. Sørensen Klaus Jensen Thomas Jacobsen VEJLEDER: Per Madsen ANTAL KOPIER: 8 ANTAL SIDER: 79 Denne rapport beskriver TOOL, et objektorienteret programmeringssprog, beregnet til undervisning af nybegyndere. Det er valgt at designe dette sprog, så det indeholder nogle grundlæggende objektorienterede begreber, er nemt at gå til, samt har integreret UML begreberne generalisering/specialisering, aggregering og associering. På baggrund af en analyse af brugen af UML blev det bestemt at implementere aggregering og associering vha. et specielt relationsobjekt. Dette relationsobjekt indeholder referencerne til de relaterede objekter, samt kontrollerer kardinaliterne. Det blev valgt at implementere generalisering/specialisering ved at bruge Javas nedarvningsstruktur. For at gøre TOOL nemt at gå til, blev syntaksen designet med strenge regler for, hvad der skal stå i koden. En TOOLklasse skal derved bestå af en række blokke, hvori de enkelte dele bliver deklareret. TOOLcompileren blev lavet vha. programmerne JLex og JavaCup. Det var bestemt, at compileren skulle kompilere til Java Bytecode. Til at opnå dette blev det valgt at bruge Java Assembleren JASMIN som backend compiler, hvorfor TOOLcompileren fra en given TOOL-fil genererede JASMINkode, som JASMIN compileren oversatte til Java Bytecode.

2 2

3 Forord Denne rapport er udarbejdet på Dat2 på datalogi uddannelsen ved Aalborg Universitet i foråret Rapporten omhandler teori og konkret udvikling af et programmeringssprog med dertilhørende compiler og indeholder flere dele: analyse, teori, implementation og test, i hvilke vi belyser de problemstillinger, der kan være i konstruktion af et programmmeringssprog. Projektet udvikles med udgangspunkt i kurset Sprog og Oversættere. Mikkel F. S. Andersen Mads Mørk Lars Otto S. Sørensen Ole K. Thomsen Klaus Jensen Thomas Jacobsen 3

4 Indhold 1 Indledning Problemformulering Analyse Analyse af programmeringssprog Udvælgelse af sprog Opsummering Indlæringsfaktorer Begyndervenlige sprogelementer UML-begreber i koden Grafisk udviklingsmiljø Type påkrævet i variabelnavn Objektbaserede datatyper Afgrænsning UML UML - introduktion UML - analysemæssigt Analyse/design vs. implementation Abstraktionsniveau Brug af UML Opsummering Integration af UML MatLab Together Rational Rose Opsummering Løsningsmodel Generalisering og specialisering Aggregering Associering UML-strukturer i TOOL Fordele

5 INDHOLD Ulemper Et konkret eksempel Sproget Generelt om TOOL TOOLs syntaks Opsummering Compilerteori Generelt om compilere Leksikalsk analyse Syntaks analysen Definition af syntaks Symboltabel og fejl-håndtering Valg af parser Top-down Bottom-up Fordele og ulemper Typecheck Kodegenerering Sammenligning af assemblere Valg af assembler Delkonklusion Implementering JLex JLex specifikations-fil Eksempel fra vores Jlex fil Java Cup Java Cup grammatikfil Eksempel fra vores CUP fil Oprettelse af parsetræ Generering af Jasmin kode Et kodeeksempel i Jasmin Test og evaluering Implementerede TOOL-elementer Evaluering af sprog TOOL s effektivitet Konklusion 72 Litteraturliste 74 5

6 INDHOLD A Grammatik for TOOL 76 6

7 Kapitel 1 Indledning Objektorienteret programmering er et af de nyeste bud på et programmeringsparadigme. Men mange, der bruger det idag, har ikke lært at programmere ved hjælp af dette princip. Objektorienterede sprog kan godt være svære at gennemskue for folk, der ikke har beskæftiget sig med programmering tidligere, hvorfor mange nybegyndere stadig lærer at programmere ved hjælp af mere simple sprog. 1.1 Problemformulering Med udgangspunkt i temaet værktøjer, sprog og oversættere er det vores intention at udvikle TOOL (The Object Oriented Language), et objektorienteret programmeringssprog specielt designet til undervisning af nybegyndere, der lever op til to grundlæggende krav: Sproget skal være objektorienteret Sproget skal være begyndervenligt For at finde elementer, der gør et sprog begyndervenligt, vil vi lave en analyse af eksisterende sprog, og udfra fra denne opstille en række krav til designet af sproget. Desuden vil vi undersøge en række nye elementer for at se om nogle af disse kunne være relevante at integrere i TOOL. Sproget skal være let at gå til, men samtidig indeholde de grundlæggende objektorienterede begreber, som f.eks. indkapsling. Vores mål er at udvikle en fungerende compiler, som kan oversætte vores sprog til Java Bytecode, da dette er platformsuafhængigt. Vi vil prøve at finde nogle elementer fra forskellige sprog som f.eks. Java og Pascal, som vi mener vil lette indlæringen af et programmeringssprog. Disse elementer vil sammen med vores egne ideer udgør undervisningssproget. 7

8 Kapitel 2 Analyse I dette kapitel vil vi undersøge, hvad der gør et programmeringssprog specielt velegnet til undervisning. Dette gøres ved at lave en analyse af forskellige programmeringssprog og undersøge hvad, der gør dem anvendelige. Desuden bliver der opstillet en række forslag til nye sprogelementer, der kan hjælpe nybegyndere til bedre forståelse af sproget. 2.1 Analyse af programmeringssprog Projektet har et grundlæggende pædagogisk aspekt i form af, at der skal konstrueres et programmeringssprog til undervisningsbrug for nybegyndere. Vi vil derfor analysere og sammenligne forskellige sprog, som benyttes på uddannelsesinstitutioner med henblik på at udrede de egenskaber, som har gjort dem så udbredte. Samtidigt vil vi se på, hvorvidt de stemmer overens med aspekter, som kunne være interessante for projektet. Et vigtigt designkriterium for undervisningssproget er, at det skal indeholde grundlæggende programmeringselementer og -begreber fra den objektorienterede verden, således at vi skaber de bedste rammer for indlæring for en nybegynder. Vi vil derfor i analysen se på, hvordan forskellige programmeringssprog understøtter førnævnte samt give vores kritik af, hvorvidt det eventuelt kunne gøres anderledes og/eller bedre med tanke på det sprog, vi selv er i færd med at konstruere. Sprog kan sammenlignes på mange områder, men vi har valgt at se nærmere på følgende egenskaber, som er relevante for os: Paradigmegrundlag (eks. objektorienteret) Grad af begyndervenlighed (høj/lav) Omgivelser (eks. udviklingsværktøj) 8

9 2.1. ANALYSE AF PROGRAMMERINGSSPROG Anvendelsesområder (typiske anvendelsesmuligheder) Syntaks (letlæselig, kompleks osv.) Målgruppe (nybegyndere, erfarne programmører o.lign.) Automatisk typegenkendelse (skal typer konsekvent angives?) Teknisk platform (Windows, Unix m.m.) Garbage collection (Oprydning/frigivelse af ressourcer) Udvælgelse af sprog Følgende programmeringssprog er blevet udvalgt til analyse: SML Pascal Basic Java C/C++ SML SML (Standard ML, hvor ML er Meta Language) er et funktionsbaseret programmeringssprog med strengt formulerede typer og automatisk typegenkendelse. [7] Det benyttes bl.a. på basisuddannelsen på AAU til at undervise nybegyndere i programmering, fordi det er meget matematisk orienteret og har en forholdsvis simpel syntaks. SML er designet med henblik på store projekter med generelle formål, men har dog nok den største udbredelse blandt studerende. Umiddelbart har vi ikke kendskab til udviklingsmiljøer der er designet til SML. Sproget har automatisk garbage collection til at rydde op for sig og indeholder gængse datatyper som boolean, char, string, integer, real m.m. Det findes til Unix såvel som Windows, er gratis og distribueres som Open Source. SML er et medlem af ML-familien og findes i mange forskellige varianter. 9

10 2.1. ANALYSE AF PROGRAMMERINGSSPROG Pascal Pascal er et imperativt sprog af ældre dato med fastdefinerede typer, som er blevet lanceret i flere forskellige, variationer, bl.a. de populære Turbo Pascal og Object Pascal [15]. Borland har lavet Delphi, et udviklingsværktøj baseret på Object Pascal, en objektorienteret version af Pascal. Ligesom SML har Pascal i en eller anden form været meget brugt til undervisning i programmering på diverse uddannelsesinstitutioner, bl.a. AAU s basisuddannelse og datamatikeruddannelsen i Aalborg. Pascal har nydt stor popularitet, blandt andet fordi det var et af de første gennemførte programmeringssprog, som havde en letforståelig syntaks, og som man kunne lære uden at skulle vide en masse om den underlæggende datamatarkitektur. Pascal findes til diverse tekniske platforme og blev oprindelig designet til undervisningsbrug, men er med tiden gået hen og blevet et rigtigt programmeringssprog, som har været benyttet i megen software. Det indeholder standarddatatyper, men giver også brugeren mulighed for at lave sine egne samtidig med, at det var et af de første sprog, man kunne lave struktureret kode i. Til dette formål introduceredes brugen af funktioner og procedurer. Basic Basic er et sprog med simpel syntaks af ældre dato, der dog er kommet i enkelte fornyelser i nyere tid, bl.a. Visual Basic fra Microsoft [16]. Denne version har også haft mange tilhængere og var blandt de førende med sin implementation af objekter i sproget. På trods af dette kan man ikke betegne Visual Basic som et rigtigt objektorienteret sprog, som vi kender det fra Java og C++. En af grundene til Visual Basic s udbredelse har nok været, at det kom med et fint visuelt udviklingsværktøj, som sparede programmøren for at programmere knapper, vinduer osv. Visual Basic var på det punkt revolutionerende, men har ikke i så stor stil som Pascal været benyttet som undervisningssprog for nybegyndere. Visual Basic understøtter automatisk typegenkendelse, idet compileren forsøger at finde typen på en variabel udfra dens værdi. Derudover kan VB benyttes til almene formål og er for tiden meget brugt som scriptsprog på Internettet i form af Microsofts Active Server Pages. Visual Basic fungerer dog kun på Windowsplatforme. 10

11 2.1. ANALYSE AF PROGRAMMERINGSSPROG Java Java er et objektorienteret programmeringssprog, der nyder stor udbredelse på tværs af mange målgrupper [11]. Det benyttes både som sprog for nybegyndere og avancerede brugere og er designet med Internettet i tankerne. Java er et meget omfangsrigt programmeringssprog, der er yderst stabilt og sikkert, har faste typer, har en syntaks lig C/C++ og er meget udbredt. Java har alle gængse datatyper fra andre lignende sprog, men har den klare fordel, at kode skrevet i Java kan eksekveres på en virtuel maskine, som gør det platformsuafhængigt. Det gør Java ved at generere bytecode istedet for binær maskinkode, som skal tilpasses den pågældende platforms instruktionssæt for at kunne køre. Derudover har sproget en garbage collector, som ligger i Java Virtual Machine (JVM) og sørger for, at der frigives objekter fra hukommelsen, som ikke benyttes længere. Java findes i flere variationer, bl.a. indbygget i udviklingsværktøjer, i script- og appletform til Internettet. C/C++ C/C++ er to meget populære sprog med faste typer. De er dog ikke særligt begyndervenlige, hvorfor det ofte er sprog, som kun mere erfarne programmører giver sig i lag med [8]. De er til gengæld meget effektive, idet programmøren har stor mulighed for at manipulere med elementerne i sin kode. C er imperativt, mens C++ er en overbygning af C med objektorienterede aspekter. Syntaksen er meget lig Java, men på flere områder mere besværlig at programmere i, idet man selv skal styre nedlæggelse af objekter, pointere m.m. Ligesom Java findes C/C++ i flere variationer til diverse platforme bl.a. med udviklingsværktøjer fra Microsoft og Borland og både sprogene samt deres respektive compilere har desuden et ry for at være de mest effektive i verden Opsummering Vi har nu kigget på et par af de mest populære programmeringssprog, som benyttes på uddannelsesinstitutioner. Det står klart, at et begyndersprog bør være simpelt med en beskrivende syntaks og begrænset funktionalitet. Samtidigt er det måske nødvendigt at skjule visse ting for brugeren for at undgå for stor frustration og forvirring. Det behøver ikke være verdens mest effektive sprog, men alligevel understøtte grundlæggende programmeringsprincipper, så nybegynderen kan få så fornuftigt et forhold til programmering fra starten af som muligt. 11

12 2.2. INDLÆRINGSFAKTORER En af de ting vi er stødt på er automatisk typegenkendelse og brugen af garbage collectors. Automatisk typegenkendelse kan være ganske praktisk, idet man ikke selv skal angive en variabels type. Istedet er det noget, compileren skal finde ud af udfra variablens givne værdi og sammenhæng. Dog finder vi det upraktisk, at programmøren ikke selv skal angive typer. Det kan for det første være svært for compileren at udlede den rigtige type. Og for det andet mener vi, at vi ikke giver brugeren en fornuftig indstilling til det at programmere, blandt andet fordi kun få sprog understøtter automatisk typegenkendelse, og det dermed kan blive et problem, når brugeren skal benytte andre sprog. Det gør også, at programmøren ikke får det fulde overblik over, hvad det er hans kode skal gøre. Et godt udviklingsværktøj er med til at gøre sprog populære især blandt nybegyndere. Nogle af de helt populære er Borland og Microsofts produkter, der understøtter blandt andet Java, C++ og Turbo- og Object Pascal. Man kan sige, at visuelle værktøjer i alle henseender er nyttige, specielt for nybegyndere. På baggrund af den ovenstående analyse af udvalgte programmeringssprog har vi fastlagt, hvilke designkriterier vi vil basere vores sprog på. Beskrivende syntaks Begrænset funktionalitet 2.2 Indlæringsfaktorer Mange faktorer har indflydelse på indlæring af et programmeringssprog for en nybegynder. På de fleste uddannelsesinstitutioner starter man ofte ud med at undervise i et simpelt, imperativt sprog. Grunden til at man normalt ikke lærer objektorienterede sprog som det første, skyldes at de kan være svære at forstå som nybegynder, bl.a. på grund af det høje abstraktionsniveau. Det er vort mål at konstruere et sprog, som er velegnet til undervisningsbrug, og som samtidig er objektorienteret og brugervenligt. Vi skal tage højde for, at brugeren eventuelt har meget lidt eller slet intet kendskab til programmering i forvejen. Med andre ord: det pædagogiske element i sproget skal være et af de bærende. Vi er derfor nødt til at formulere en klar definition af brugervenlighed, som vi kan basere sproget på: Brugervenlighed: Et sprog der er let at lære, let at anvende og let at huske. Overordnet har vi defineret tre hovedpunkter, der har indflydelse på indlæring generelt: 1. Personens generelle viden og logiske sans før introduktion til det nye stof 12

13 2.3. BEGYNDERVENLIGE SPROGELEMENTER Ad1 2. Hjælpsomme elementer der stilles til rådighed under indlæringsprocessen 3. Evaluering/muligheden for feedback efter introduktionen Vi må formode, at vores målgruppe har en vis mængde kendskab til blandt andet matematik, sprog/grammatik og en gennemsnitlig persons sans for logik og sammenhæng. For at skabe den bedste overgang bør et begynderprogrammeringssprog ikke stride imod disse allerede indlærte evner, men understøtte en forståelig og logisk syntaks. Det står dog klart, at dette må blive på bekostning af performance og effektivitet, idet beskrivende sætninger sjældent er korte. I mange populære sprog såsom C++ er det muligt at skrive kort, men effektiv, multifunktionel kode. Dette er dog praktisk talt umuligt for en nybegynder at sætte sig ind i. Ad2 Når man som nybegynder sidder og skriver sine første linier kode er det betryggende og hjælpsomt, hvis sprogets omgivelser virker støttende. Det kan eksempelvis være mulighed for syntakscheck, online hjælp og manualer, en god editor eller udviklingsmiljø med farvesegmentering af ens kode (reserverede ord, headers m.m.). Denne faktor drejer sig dog mere om omgivelserne for sproget end om sproget selv. Ad3 Evaluering er vigtigt for alle former for indlæring, idet det er væsentligt at vide, om det, man har lavet, er korrekt, eller om man har misforstået noget. I programmeringssammenhæng kan det eksempelvis være informative fejl fra compileren eller i form af, at det udviklede software går ned og giver en besked om grunden dertil, eller muligheden for at debugge. 2.3 Begyndervenlige sprogelementer Med udgangspunkt i det ovenstående afsnit omkring indlæringsfaktorer vil vi her give nogle eksempler på udvidelser i vores programmeringssprog, der kan hjælpe en nybegynder til større forståelse i brugen af det UML-begreber i koden En måde at skabe bedre overblik er ved at anvende de mest almindelige UMLbegreber i koden. Da man på nogle uddannelsesinstitutioner, f.eks. AAU, lærer at 13

14 2.3. BEGYNDERVENLIGE SPROGELEMENTER anvende UML-notation i forbindelse med analyse og design af systemer, sidestillet med indlæringen af et programmeringssprog, finder vi det oplagt at inddrage disse begreber i sproget. Man kan forestille sig, at UML-begreber i forbindelse med klassediagrammer, som f.eks. aggregering, associering og specialisering, skrives direkte i koden, så denne afspejler UML-diagrammet. Det, der i denne sammenhæng oftest volder nybegyndere problemer, er overgangen mellem designet og implementationen, og ved at anvende samme begreber i koden som i analysen og designet, kan man mindske dette problem. I den sammenhæng kunne det eksempelvis være interessant at have en kontrollerende instans på strukturer mellem to objekter, der sikrer at det givne forhold overholdes og styres på den pågældende relation. Dermed gøres UML til en integreret del af implementationen. Da vi ikke har kendskab til programmeringssprog, der håndterer UML fuldt ud i koden, ser vi dette som et spændende aspekt af at udvikle et nybegyndersprog Grafisk udviklingsmiljø En god måde at give større forståelse for et emne er ved at visualisere problemstillingen og måden, hvorpå denne kan løses. I vores tilfælde kan det være et udviklingsmiljø i hvilket man kan modellere sine UML-diagrammer og ud fra disse skrive koden. Endvidere kan man forestille sig, at udviklingsværktøjet danner et overblik over de skabte objekter og deres relationer ved hjælp af figurer. Et eksempel på et sådant værktøj er Together, der omtales i detalje i afsnit I dette værktøj kan man modellere sin problemstilling i et UML-diagram og få lavet et kodeskelet ud fra det. Det omvendte er også muligt, dvs. hvor Together udvikler et klassediagram ud fra de klasser og metoder, der er angivet i et givent kodeeksempel. Der hersker ikke nogen tvivl om, at et udviklingsmiljø for ethvert programmeringssprog er en stor hjælp til en nybegynder indenfor programmering. Man skal dog sikre sig, at brugeren lærer mere om selve sproget end det miljø, der udvikles i, forstået på den måde, at man ret hurtigt kan vænne sig til brugen af en masse ekstra funktioner i et udviklingsmiljø, uden egentlig at have forstået selve sproget fuldt ud. Der bør derfor fortsat være fokus på selve programmeringssproget, og dermed også en glidende overgang fra dette programmeringssprog til andre. 14

15 2.3. BEGYNDERVENLIGE SPROGELEMENTER Type påkrævet i variabelnavn Når man i et programmeringssprog som f.eks. Java vil tildele en variabel værdien af en anden variabel, laves der først et type-check for at se om dette overhovedet er muligt. Er disse to variable af hver sin type, må man i nogle tilfælde se sig nødsaget til at konvertere den ene. Problemet med at man skal konvertere sine variable, kan til dels afhjælpes ved at kræve, at typenavnet er inkluderet i variabelnavnet. Hvor man normalt skriver noget i denne stil: A = B; vil man, med ovenstående forslag, have følgende: int_a = float_b; Idet brugeren skriver dette, vil vedkommende altid være klar over, at der er tale om variable af to forskellige typer, hvor man i det første eksempel med variabelnavne som A og B har nemmere ved at glemme, hvilken type de har. Compileren skal da melde fejl, hvis ikke typen er angivet på denne måde i variabelnavnet. Der vil dog meget hurtigt blive meget skrivearbejde for programmøren. Nybegyndere lærer også at give forholdsvis lange, beskrivende variabelnavne, og hvis de ovenikøbet skal tilføje type til dette navn, kan det let blive uoverskueligt. Man kan også forestille sig, at nybegynderen ville skrive for korte, ikke-beskrivende variabelnavne for at undgå dette problem, og dette kan på et tidspunkt lede til en anden mangel på overblik, idet variabelnavnene i så fald ikke er særligt sigende. Vi mener dog stadig, at det er en god ide for nybegyndere at bruge denne metode, selvom sproget formentlig blot vil blive brugt til udvikling af relativt små programmer Objektbaserede datatyper Ved at holde et programmeringssprog 100 % objektorienteret kan man repræsentere de simple datatyper, f.eks. integers som objekter. En fordel kan være at man slipper for diverse matematiske misforståelser. Mange nybegyndere vil formentlig have en eller anden form for matematisk baggrund og vil derfor studse lidt over eksemplet A = A + 1, hvis de ser på dette som en ligning. Der vil dog ret hurtigt vise sig at være en række praktiske problemer med denne løsning, i stil med dem fra eksemplet med variablene ovenfor. Man kan forestille sig følgende: 15

16 2.4. AFGRÆNSNING A = A + B: A = B + C: A.set(A.add(B)); A.set(B.add(C)); set fungerer her som et assignment, og add adderer værdien af det talobjekt der kaldes med til det der kaldes fra. Endvidere er problemet i det andet kodeeksempel, at hvis dette statement skal udføres på een linje, vil værdien af B også ændres, og det er formentlig ikke det, man ønsker. Skal det udføres korrekt, er man nødt til at splitte det op, så man derved får: A.set(B); A.add(C); Som det ses øges kompleksiteten ret hurtigt til noget, der gør at disse simple matematiske operationer bliver til noget forholdsvis uoverskueligt. Endnu værre bliver det, hvis der ligeledes skal anvendes beskrivende variabelnavne, som under afsnittet om type i variabelnavnet. int_a.set(int_a.add(int_b)); 2.4 Afgrænsning I kapitel to har vi set på nogle forskellige elementer, som kunne være interessante at integrere i vores undervisningssprog. Denne del af analysen kan deles op i to hovedretninger: undersøgelse af eksisterende programmeringssprog og værktøjer og ideer til nye elementer i et undervisningssprog. Det er vigtigt at understrege at visse elementer i de to kapitler, er baseret på vore egne erfaringer med en begrænset mængde programmeringssprog. Vi vælger ud fra det foregående afsnit omkring nye sprogelementer i vores programmeringssprog at gå videre med ideen om integration af UML i koden. Grunden dertil er, at det er relevant i forbindelse med et undervisningssprog, da det kan være fordelagtigt at benytte UML-begreberne i relation til indlæring af objektorienterede begreber. Endvidere er det ikke lykkedes os at finde andre der har forsøgt sig med denne ide, hvorfor vi finder det interessant at inddrage. Vi er kommet frem til at det vi vil koncentrere os om i dette projekt, er at lave et programmeringssprog, som understøtter nogle udvalgte UML begreber. 16

17 Kapitel 3 UML I dette kapitel vil vi se på, hvad der gør UMLnotationsformen (Unified Modeling Language) anvendeligt inden for programudvikling, og hvorfor det kunne være en god ide at integrere det i vores programmeringssprog. Endvidere beskrives overgangen fra UML-analyse og -design til implementation og endelig en beskrivelse af UML-strukturen i vores programmeringssprog TOOL. 3.1 UML - introduktion Udvikling af større applikationer skal have en vis form for strukturering, for at processen kan forløbe smertefrit. Man kan sammenligne det med at bygge et hus. Arkitekter designer bygninger, hvorefter håndværkere bygger dem. Jo mere kompliceret designet af den pågældende bygning er, jo vigtigere er det at kommunikationen mellem arkitekt og håndværker fungerer optimalt. For at lette dette udarbejder arkitekterne en række skitser og tegninger. På samme måde fungerer UML-sproget som bro mellem programdesigner og programmør. Det er noget begge parter er nødt til at sætte sig ind i, men hjælper til en bedre forståelse af det system, der skal udvikles. Det er dog sjældent arkitekten selv, der bygger huset, hvorimod man, indenfor udvikling af programmel, godt kan komme ud for, at den samme person både designer og implementerer det pågældende system. UML er især anvendeligt til problemstillinger, hvor det er muligt at oprette objektorienterede modeller, og netop derfor finder vi det interessant at inddrage i vores programmeringssprog. Da UML er forholdvist omfattende vælger vi kun at medtage udvalgte relevante features. For at lave en abstraktion over et problem, oprettes en model, der indeholder de enkelte klasser. Disse klasser kan så have en række relationer og attributter. 17

18 3.2. UML - ANALYSEMÆSSIGT Objekter er instanser af de klasser, man har i systemet, og netop klasserne svarer til en arkitekts tegninger, altså en slags opskrift for, hvordan et objekt skal være. 3.2 UML - analysemæssigt På figur 3.1 ses et typisk klassediagram med en række klasser og deres indbyrdes relationer[12]. De tre relationer, der her er vist, er beskrevet i det følgende: Figur 3.1: Et klassediagram med de mest almindelige UML-begreber Association: En relation mellem instanser af to klasser. Der er en association mellem to klasser, hvis f.eks. den ene klasse bør kende til en metode fra den anden klasse. I ovenstående eksempel svarer det til, at en instans af Customerklassen kan anvende metoden calctotal fra klassen Order. Endvidere 18

19 3.2. UML - ANALYSEMÆSSIGT er det muligt at angive de såkaldte kardinaliteter: et mængdeforhold, hvor man angiver, hvor mange instanser der kan være af en klasse i forhold til den klasse, der er associeret med. Aggregering: En aggregeringsstruktur indikerer en relation mellem to eller flere klasser, hvor en klasse er en del af en anden. En aggregering angives med en rombe, der peger mod den klasse, der indeholder de underliggende klasser. Ligeledes er det muligt at angive kardinaliteter for aggregeringer. Modsat associationsstrukturen skal der ved aggregering dog altid være mindst en instans af den overordnede klasse (Klassen med romben). I eksemplet ovenfor svarer dette til, at en ordre består af en eller flere ordredetaljer. Generalisering / specialisering: En generalisering er en struktur, der indikerer, at en klasse er en superklasse af en anden. Dvs. at de specialiserede klasser nedarver superklassens egenskaber. På den måde er Payment superklasse til Cash, Check og Credit, da disse skal nedarve attributten amount. Denne bindingstype vises med en trekant, der peger mod superklassen. Ovenstående klassediagram er dog kun et af 12 mulige diagramtyper i UML. De er opdelt i tre kategorier: Fire diagrammer der repræsenterer statiske programstrukturer: Klasse-, objekt-, komponent- og fordelings-diagram. Fem diagrammer der repræsenterer dynamiske programstrukturer: Brugsmønster-, sekvens-, aktivitets-, samtidigheds- og tilstands-diagram. Endelig findes der tre diagramtyper til at organisere program-moduler, som pakker og underliggende systemer. Vi vælger kun at se på klassediagrammet, da det er et af de mest anvendte inden for objektorienteret analyse. En nybegynder vil måske undre sig over, hvorfor et sådan diagram bør laves inden den egentlige implementering påbegyndes, men erfaringen har vist at det giver bedre struktureret kode og større overblik over systemet og dets udvikling. Det interessante ved UML er, at man kan modellere stort set alle former for applikationer, der kan køre på en hvilken som helst kombination af hardware, operativsystemer, programmeringssprog og netværk [4]. Det er netop denne fleksibilitet, der gør det så anvendeligt. Det er specielt velegnet til objektorienterede sprog og omgivelser, som vist ovenfor i eksemplet med klassediagrammet. Det er relativt enkelt at skabe sig et meningsfyldt overblik, også selvom man ikke har været med til at designe det. UML kan også anvendes til modellering af systemer udviklet i ikke-objektorienterede sprog, som f.eks. Fortran og COBOL [4]. 19

20 3.3. ANALYSE/DESIGN VS. IMPLEMENTATION 3.3 Analyse/design vs. implementation De fleste nybegyndere, som er startet med teori om programmering, undervisning i analysemetoder og notationsformer såsom UML, møder en kløft mellem analyse/designfasen og selve implementationsfasen. Selvom en designfase fungerer som springbræt til programmering, kan det være svært at se sammenhængen mellem de modeller, man har udarbejdet og til deres konkrete implementation. Dette og de følgende afsnit er baseret på [9]. Vi har forsøgt at kategorisere de problemer, der gør sig gældende for kløften mellem analyse/design og implementation: Abstraktionsniveau Brug af UML Abstraktionsniveau I analyse- og designfasen modelleres systemer udfra en abstrakt tankegang og med det formål at skabe overblik uden at være for konkret eller detaljeret. Man taler overordnet om forhold, strukturer, elementer og hændelser, der befinder sig i problemområdet, om arbejdsgange og personer der eksisterer i selve anvendelsesområdet og klassificerer/generaliserer mængden heraf og laver derefter et design, der skal implementeres. Abstraktionsniveauet er dog helt anderledes for en programmør, der skal implementere modellen. Alt er meget konkret og detaljeret, til tider uoverskueligt og fagsprogligt mere teknisk. Der skal vælges programmeringssprog, skrives metoder, oprettes og nedlægges objekter, fejl skal håndteres, persistens skal sikres, pointere skal styres, hukommelse skal allokeres, og det hele skal måske kunne køre på en bestemt teknisk platform under et bestemt operativsystem og meget andet. Dette kan give anledning til megen bekymring og frustration specielt blandt nybegyndere, som vil stå overfor en række mulige løsningsmetoder, standardfunktioner, andre alternativer m.m. i de omfangsrige og komplicerede programmeringssprog. Derfor er det vigtigt, at vi designer sproget, så det indeholder en høj grad af abstraktion. Det kan vi gøre ved at minimere de tekniske muligheder for brugeren, pakke ting ind og skjule implementationen af visse ting, som vi synes er for stor en mundfuld for nybegynderen at skulle tage stilling til. Vi ønsker, at det stadig er muligt at have et godt overblik, og at det samtidigt er muligt at udvikle avancerede systemer selv med et simpelt sprog med kun få funktioner. 20

21 3.4. INTEGRATION AF UML Brug af UML UML er den foretrukne notationsform for modellering af systemer, når det drejer som om objektorienteret systemudvikling. Nybegyndere undervises som oftest i denne notationsform for at kunne visualisere det problem, som skal løses. Dog er det et problem, at de færreste programmeringssprog har taget UML-begreberne til sig i deres fulde form. Det gør det svært at se sin model i koden og efterfølgende kontrollere om den model, man har implementeret stemmer overens med den model, man ønskede at implementere. Grundene til den manglende integration kan være mange. Det kan måske vise sig at være svært at realisere i sprog. Man kan have den indstilling, at programmører skal have den størst mulige frihed til at implementere sin model, hvorfor man har valgt at udelade UML helt eller delvist. Det kan også være, at sprogudviklere mener, at UML-strukturer (kardinaliteter) hæmmer systemets fremtidige skalering og begrænser genbrug. Desværre gør denne mangel det svært for nybegynderen at skabe sig et overblik over, hvordan han skal få omdannet modellen til konkret kode Opsummering De fleste sprog understøtter simpel nedarvning men ikke aggregering og associering. Er det for svært at styre objekters dynamiske struktur (modsat nedarvning som er en statisk struktur på klasseniveau), eller kan man kun bruge UML til forståelse, og ikke realisering? Vi ser gerne, at man udnytter UMLs styrke i implementationsfasen istedet for mere eller mindre at forkaste meget af den information, man er kommet frem til og har modelleret i sit klassediagram. Ligeledes er det ønskeligt, at man bruger begreberne fra UML som en fuldt ud integreret del af programmeringssproget for at skabe høj genkendelighed og dermed give en blødere overgang fra analyse/design til implementation. 3.4 Integration af UML Efter at have undersøgt og kategoriseret de væsentligste problemer i overgangen fra analyse og design til implementation, vil det være naturligt at se nærmere på et par værktøjer, der har taget problemstillingen med UML op, og forsøgt at integrere UML på et lidt højere niveau end programmeringssprog, som kun understøtter en eller flere former for nedarvning. Disse undersøgelser skal så danne grundlag for inspiration til UML-integrationen i vores sprog. Grunden til at vi ser på værktøjer frem for deciderede sprog er, at vi er interesseret i at studere den sammenhæng, der er mellem de modeller, man kan tegne med værktøjerne 21

22 3.4. INTEGRATION AF UML og den kode, som de efterfølgende er i stand til at generere. Vi ønsker kun at se, hvordan man har integreret UML, hvorfor denne analyse ikke vil dække for værktøjernes fulde brug og funktionalitet. Vi har valgt at se nærmere på: MatLab Together Rational Rose MatLab MatLab er et interaktivt højniveausprog, som blandt andet benyttes til at udvikle modeller, analysere data, optimere systemers effektivitet og konstruere algoritmer med en stærk understøttelse af matematiske begreber. Grundstenen i MatLab er igen objektet og udover almindelig nedarvning understøttes aggregering (containment), hvor et objekt kan indeholde et andet underliggende objekt som et af dets attributter. Metoder på det underliggende objekt kan kun tilgås via metoder på det aggregerende hovedobjekt. Dette kan ses på figur 3.2. Dette giver en stærk form for aggregering, idet det aggregerende objekt indkapsler det underliggende. Eksempelvis i relationen Bil-Motor. Problemet her er dog, at det underliggende objekt kun må eksistere i form af det overliggende, og dermed ikke kan indgå (umiddelbart) i relationer med andre objekter undtagen via et bil-objekt. Men Motor kan ikke genbruges til andet end Bil, og Motor kender heller ikke til den Bil, den tilhører. Kommunikationen mellem Bil og Motor kan derfor kun ske den ene vej Together Together er et udviklingsværktøj, der bl.a. understøtter reverse engineering. Ideen er, at man ud fra kildekode skal kunne generere et klassediagram over kildekodens klasser og et sekvensdiagram for en metode i UML. Together skal blot have en kildekodefil i eksempelvis Java eller C++ som input. Værktøjet sørger for, at modellen altid er konsistent med kildekodeskabelonen, idet ændringer foretaget i modellen med det samme afspejles automatisk i koden og omvendt. Derudover understøtter Together en lang række testcases og designpatterns til udvikling samt generering af dokumentationsmateriale. 22

23 3.4. INTEGRATION AF UML Dog ligger Togethers styrke ikke i selve modelleringen. Det eneste der sker, når man tegner et klassediagram er, at der skabes en kodeskabelon i et 1:1 forhold i det valgte programmeringssprog. Nedarvning understøttes i det omfang, at klasser der indgår i en nedarvnings-relation kender hinanden. Men det er stadig op til udvikleren at styre, hvad der skal nedarves samt hvordan (private, public, protected), og multipel nedarvning tillades ikke. Aggregering understøttes kun på det visuelle niveau i modellen, idet der kun angives en relation i koden skrevet som en simpel kommentar. Associering vises kun med en reference den ene vej imellem to sidestående objekter. Med hensyn til brugen af kardinaliteter så er værktøjet mangelfuldt både i diagrammerne og i koden Rational Rose Rational Rose er et UML-baseret caseværktøj til bl.a. styring, udvikling samt dokumentation af objektorienterede systemer. Det er et værktøj (eller rettere sagt en samling af værktøjer), der søger at understøtte hele udviklingsprocessen (meget lig Together), fra analyse til implementation, ved at samle hele processen i et og samme værktøj. På denne måde får man en meget konsistent model med hele vejen i processen. Man har ikke problemet med, at analysen udarbejdes i et værktøj, figurer laves i et andet og koden skrives i et tredie, eksempelvis Microsoft Word, FlowChart og Borlands C++ Builder. I sådanne tilfælde kan der let opstå inkonsistens i modellen, idet informationen måske ikke overføres korrekt, men på fejlagtig vis konverteres således, at man i den efterfølgende fase arbejder videre på en inkonsistent model. Ofte arbejder flere personer også på samme projekt, hvorfor styring af selve projektet er utrolig vigtig, og jo flere personer og jo flere værktøjer, der arbejdes med, desto større er risikoen for at der opstår fejl. Da Rational Rose er bygget op omkring rammerne for UML betyder det, at UML er med hele vejen i udviklingsprocessen. Den model man sidder og arbejder med i analyse- og designfasen er den samme, der til slut generes en kodeskabelon for. Det vil sige, at modellen principielt overføres i et 1:1 forhold fra analyse til kode, som man skal kunne arbejde videre med. Rational Rose har det samme problem som Together. Ganske vist laver man relationerne mellem klasserne i diagrammet, men når de skal overføres til kode, er det kun nedarvning, der kommer med som brugbar kode, og kardinaliteter benyttes ikke. 23

24 3.5. LØSNINGSMODEL Opsummering Spørgsmålet er, om det er realistisk at kunne mappe 1:1 mellem analyse/design og implementation. Ideen er god nok, idet man gerne skulle kunne genkende sin model i kildekoden. Her kommer reverse engineering ind i billedet, hvor det i teorien ikke blot skal være muligt at kunne gå både fremad, men også tilbage i systemudviklingsprocessen og dermed kontrollere, at den implementerede model er konsistent med den fra analyse og design. Der er flere forskellige løsningsmodeller til, hvordan man implementerer strukturer mellem objekter og klasser, og det er måske grunden til, at det ikke viser sig i den kode, som caseværktøjerne genererer. Det kan være let nok at implementere nedarvning, idet det er en statisk relation, forstået på den måde, at et objekt lever og dør med relationen. Aggregerings- og associeringsstrukturer kan derimod dynamisk opstå og bortfalde. Og hvordan styrer man kardinaliteter? Vi anser de løsninger vi fandt ved at undersøge værktøjerne mangelfulde, hvorfor vi vil gå lidt mere i dybden med forskellige løsningsmodeller, deres fordele og ulemper samt hvordan de implementeres i sproget. 3.5 Løsningsmodel I det følgende afsnit vil vi kigge på de måder, man idag benytter i programmeringssprog for at integrere UML-strukturer i sin kode. Derudover vil vi komme med eksempler på, hvordan man eventuelt kunne gøre det, så UML bliver en mere naturlig del i implementationen Generalisering og specialisering Nedarvning (generalisering og specialisering) betegnes i UML som værende en statisk struktur. Grunden hertil er, at objekter i en sådan relation fødes, lever og dør med nøjagtig den samme uændrede struktur. De kan ikke skifte relation til andre objekter af samme type og eksisterer dermed altid som en fast helhed. Nedarvning er en stærk struktur, som tillader genbrug af kode, herunder både metoder og attributter på objekter. Det betyder også, at strukturen er forholdsvis let at implementere, idet man normalt ikke skal kontrollere objektets nedarvningsstruktur i dets levetid. Der eksisterer dog varianter af nedarvningsstrukturer, der øger kompleksiteten. Det kan blandt andet dreje sig om multipel nedarvning, hvor et subklasseobjekt kan nedarve fra mere end een superklasse eller polymorfi, hvor metoder på objektet udføres alt efter deres form eller specialisering. Nedarvning (både simpel og multipel) implementeres normalt med en form for 24

25 3.5. LØSNINGSMODEL reference (eksempelvis via extends i Java) i subklasserne til den eller de superklasser, det pågældende objekt arver fra. Mange programmeringssprog tillader ikke multipel arv, selvom det kan ses som en meget naturlig måde at betragte arv på. Man kan i så fald vælge at udvikle sin model, så den på anden vis kan klare multipel arv. UML siger ikke rigtigt noget om, hvilke egenskaber man kan arve i en subklasse, og hvilke man ikke kan. I nogle sprog er det muligt at angive en access modifier på en attribut eller metode, der angiver, hvorvidt den pågældende egenskab kan nedarves eller overskrives i subklasserne. Vi har dog valgt at designe TOOL så UML-nært som muligt, så alle private egenskaber fra en superklasse automatisk nedarves og intet kan overskrives Aggregering Aggregering er den mest interessante struktur i vore øjne, idet den kendetegner en stærkere relation imellem to objekter af forskellig type, hvor det ene objekt (eller eventuelt dem begge to) ikke kan leve uden det andet. Man udtrykker graden af indbyrdes forhold ved hjælp af kardinaliteter, eksempelvis 1 til 1..* hvor eet objekt af en type kan være tilknyttet 1..* af den anden type. Dette kan ses på figur 3.6. Forholdet den anden vej kan måske være eet, fordi det andet objekt kun kan tilhøre eet objekt af den første type. Implementationsmæssigt vil en aggregering som oftest være symboliseret ved hjælp af en reference fra det aggregerende objekt til det underliggende objekt eller en liste af underliggende objekter, hvis der er et 1..* forhold. Drejer det sig om et 1..* til 1..* forhold skal en ny klasse introduceres (se 3.5.3). Der findes umiddelbart to måder at implementere aggregering på: Embedded Reference Embedded En måde at implementere aggregering på er ved at angive en klasse i en klasse. På denne måde angiver man et stærkt forhold imellem de to klasser, eksempelvis Bil-Motor, hvor motoren kun kan eksistere gennem en bil, hvilket ses på figur 3.2. Motoren kan ikke umiddelbart tilgås uafhængigt af bilen, hvorfor bilen ses som det styrende objekt. I Java er det dog muligt at omgå denne form for indkapsling, selvom det i vore øjne strider imod brugen af indkapsling og struktur. Ulempen ved embedded aggregering er, at det ikke er helt konsistent med UML og objektorienteret tankegang. En klasse bør være en beskrivelse af en mængde af objekter med samme struktur, adfærdsmønster og attributter [9], s.70, der 25

26 3.5. LØSNINGSMODEL Figur 3.2: Embedded aggregering abstraherer over en mængde objekter med samme adfærd og egenskaber. Er en klasse ikke en isoleret helhed, bør man, jævnfør UML, splitte den op i flere klasser med passende strukturer imellem sig, hvorved det er muligt at anbringe information, der hvor den bedst hører hjemme, og hvor det er muligt at genbruge kode på den mest optimale måde. Embeddede egenskaber er ikke noget, vi ønsker at give TOOL, som er et nybegyndersprog og fordi, vi ser det som misbrug af den objektorienterede tankegang. Reference Den mest anvendte implementering af aggregering er nok via brugen af referencer, der kan ses på figur 3.3. Hvis man har et 1:1 forhold, kan man vælge at implementere strukturen som en fast attribut på den aggregerende klasse eller som en decideret reference til et eksternt objekt. Har man derimod en 1..* relation, kan man inkludere en form for liste eller en reference til en liste. I alle tilfælde siges der dog intet om kardinaliteter eller kontrol heraf. Fordelen er at man viser et Figur 3.3: Reference aggregering indbyrdes forhold mellem to objekter (eventuelt af samme type) uden direkte at inkludere det ene i det andet. Det betyder, at man kan genbruge klasser til andre formål, bytte objekterne ud og stadig se på dem som selvstændige i det store hele. Ulempen er dog, at man ikke umiddelbart kan kontrollere denne reference, ej heller gå den modsatte vej af, hvor referencen peger. 26

27 3.6. UML-STRUKTURER I TOOL Associering Objekter, der indgår i en associering, har et løsere forhold til hinanden end aggregering. De kender dog hinanden og kan oprette og nedlægge en forbindelse til hinanden på runtime. Objekterne er i den forstand sidestillede, idet de kan leve helt uafhængigt af hinanden. Men de kan også arbejde sammen om opgaver, eksempelvis ved objekterne Bil og Chauffør, hvor en bil ikke behøver have en Chauffør, og en Chauffør ikke behøver at være tilknyttet en Bil. Men er opgaven en Køretur, oprettes en midlertidig (eller måske permanent) forbindelse, idet en Køretur ikke kan eksistere uden en Bil med en Chauffør. Implementation af en associeringsstruktur kan være den samme som for aggregering. Det afhænger af kardinaliteterne mellem de to involverede klasseinstanser. Da det ikke giver mening at tale om embeddede klasser, eksempelvis klassen Bil indeholder klassen Chauffør, idet vi snakker om uafhængige objekter, så må løsningen være en reference til et objekt eller til en liste af objekter. Hvis kardinaliteterne imellem de to objekter er en 1..* til 1..* relation skal en ny klasse involveres. Denne klasse skal indeholde informationer om hvilke to objekter har en relation til hinanden på et givent tidspunkt. I ovennævnte tilfælde kunne dette dreje sig om klassen Køretur, som minimum vil indeholde en reference til en bil og en chauffør, hvilket er at se på figur 3.4 Figur 3.4: 1..* til 1..* forhold uden relationsobjektet. 3.6 UML-strukturer i TOOL Vi ser det som et problem, at man i de fleste udviklingsværktøjer springer over, hvor gærdet er lavest, når det kommer til integration af UML. Det samme gælder de programmeringssprog der har valgt slet ikke at medtage UML i sproget. Megen information fra klassediagrammet går tabt, koden bliver uoverskuelig, og man har ringe mulighed for at håndhæve kardinaliteter og forhindre direkte misbrug mellem objekter. Vi vælger derfor at designe en alternativ implementeringsform til struktur og kardinalitet ved at introducere en abstrakt datatype Relation, som en decideret standardklasse i TOOL, der kan ses på figur 3.5. Ideen går ud på at bringe selve relationsbegrebet ind i kildekoden som et objekt fra en abstrakt klasse, der kan 27

28 3.6. UML-STRUKTURER I TOOL Figur 3.5: UML-relationer i TOOL indeholde vigtig information om forholdet mellem to objekter. Relationsobjektet abstraherer over strukturen og de kardinaliteter, man fodrer det med, og adgang til relaterede objekter skal foregå igennem relationsobjektet, der er tilknyttet netop de to objekter. Relationen skal hver gang kontrollere, hvorvidt de to objekters indbyrdes forhold overholdes, herunder kardinalitet, fødsel, liv og død samt forhindre at integriteten herimellem på nogen måde brydes. Relationsobjektet vil eksistere som en instans af en indbygget standardklasse og typisk indeholde en form for liste af referencer til et antal af objekter, der stemmer overens med kardinaliteterne og en bestemt type, en given struktur (nedarvning, aggregering eller associering) samt nogle metoder, hvorpå man kan tilgå objektet og dermed skaffe sig adgang til det strukturmæssigt tilknyttede objekt Fordele En af de store fordele med et decideret relationsobjekt er, at strukturerne indføres, kontrolleres og håndhæves i forhold til UML-modellen. Samtidig abstraheres der over objekters interne forhold, og man sikrer, at andre objekter ikke kan tilgå dem uden en relation Ulemper For programmøren kan det virke hæmmende at skulle implementere en sådan struktur. Det kan være, at denne helst så det implementeret på en sådan måde, at man selv kan styre strukturerne, nøjagtigt som de fleste sprog fungerer i dag. Men i så fald kan man undlade at bruge relations-objektet til styring heraf. En anden ulempe er, at der tages en klasse i brug, som ikke umiddelbart er til stede i ens klassediagram, og at man kan oprette instanser af en struktur, nøjagtig som man kan med mere konkrete objekter såsom et array. 28

29 3.6. UML-STRUKTURER I TOOL Et konkret eksempel Lad os tage et eksempel, hvor relationsobjektet indgår. Vi har to klasser, Bil og Hjul, som indgår i en aggregeringsstruktur. En instans af Bil kan have 0-til- 4 instanser af et hjul, mens en instans af klassen Hjul skal tilhøre 1 Bil. Med andre ord: en Bil kan godt eksistere uden Hjul, men et Hjul kan ikke eksistere uden at være tilknyttet en Bil. Dette kan ses på figur 3.6. Når en instans af Bil oprettes Figur 3.6: Et konkret eksempel på en aggregering skal kardinaliteter, den type man ønsker at aggregere med samt strukturtypen sendes med som parametre. Der oprettes herefter en reference til et bilobjekt med et relationsobjekt tilknyttet, der eksempelvis kunne indeholde et array med 4 tomme pladser. Efterfølgende vil det være muligt at tilføje maksimalt 4 Hjul til relationen. Metoder på relationsobjektet Da vores relationsobjekt skal kunne styre relationer og deres begrænsninger, skal det selvfølgelig have noget funktionalitet, så vi kan tilgå og kontrollere kommunikationen mellem de to relaterede objekter i den pågældende struktur. Metoderne afhænger muligvis af den pågældende struktur, der skal implementeres, men umiddelbart har vi brug for følgende: Insert: Metode der kan indsætte en reference til et objekt i strukturen Remove: Metode der kan fjerne en reference til et objekt i strukturen CheckReferences: Metode der kan kontrollere antallet af referencer til objekter i strukturen 29

Exceptions i Delphi. Try except

Exceptions i Delphi. Try except Exceptions i Delphi Exceptions er en teknik til at fange fejl under programafviklingen. Ikke programmeringsfejl, men fejl der opstår i forskellige situationer, f.eks. en fil der mangler en fil der er skrivebeskyttet,

Læs mere

UML til kravspecificering

UML til kravspecificering UML til kravspecificering UML mini-kompendium - til brug i forbindelse med modellering af kravspecifikationer. Copyright 2006 Teknologisk Institut, IT-Udvikling Aktivitetsdiagram 2/9 Aktion Aktionsnavn

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin BACKEND

Hassansalem.dk/delpin User: admin Pass: admin BACKEND Hassansalem.dk/delpin User: admin Pass: admin BACKEND 1/10 Indledning Dette projekt er den afsluttende del af web udvikling studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med Del-pin

Læs mere

Studieordning del 4-2014

Studieordning del 4-2014 Studieordning del 4-2014 Fagbeskrivelser Datamatiker AP Graduate in Computer Science Version 1.1 Revideret august 2014 Side 0 af 8 Indhold del 4 Fagbeskrivelser 1. Faget Programmering (PRO)...2 2. Faget

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2016 Projekt, del I Institut for matematik og datalogi Syddansk Universitet 29. februar, 2016 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

Abstrakte datatyper C#-version

Abstrakte datatyper C#-version Note til Programmeringsteknologi Akademiuddannelsen i Informationsteknologi Abstrakte datatyper C#-version Finn Nordbjerg 1/9 Abstrakte Datatyper Denne note introducerer kort begrebet abstrakt datatype

Læs mere

Objects First with Java A Practical Introduction Using BlueJ

Objects First with Java A Practical Introduction Using BlueJ Objects First with Java A Practical Introduction Using BlueJ En introduktion til objektorienteret programmering for begyndere ud fra et software engineering aspekt Om at programmere i Java, ikke om værktøjet

Læs mere

Programmering I Java/C#

Programmering I Java/C# Programmering I Java/C# Dit første projekt Datatekniker Intro to C# C# (C Sharp) Et enkelt, moderne, generelt anvendeligt, objektorienteret programmeringssprog Udviklet af Microsoft, ledet af danskeren

Læs mere

Åben uddannelse, Efterår 1996, Oversættere og køretidsomgivelser

Åben uddannelse, Efterår 1996, Oversættere og køretidsomgivelser 3/10/96 Seminaret den 26/10 vil omhandle den sidste fase af analysen og de første skridt i kodegenereringen. Det drejer sig om at finde betydningen af programmet, nu hvor leksikalsk og syntaktisk analyse

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2019 Projekt, del I Institut for matematik og datalogi Syddansk Universitet 27. februar, 2019 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

IT opgave. Informationsteknologi B. Vejleder: Karl. Navn: Devran Kücükyildiz. Klasse: 2,4

IT opgave. Informationsteknologi B. Vejleder: Karl. Navn: Devran Kücükyildiz. Klasse: 2,4 IT opgave Informationsteknologi B Vejleder: Karl Navn: Devran Kücükyildiz Klasse: 2,4 Dato:03-03-2009 1 Indholdsfortegnelse 1. Indledning... 3 2. Planlægning... 3 Kommunikationsplanlægning... 3 Problemstillingen...

Læs mere

Hvad er Objekter - Programmering

Hvad er Objekter - Programmering Denne guide er oprindeligt udgivet på Eksperten.dk Hvad er Objekter - Programmering En rigtig god gennemgang af hvad objekter er! Hvordan de oprettes og anvendes! Det er helt klart til nybegyndere, som

Læs mere

Andengradsligninger. Frank Nasser. 12. april 2011

Andengradsligninger. Frank Nasser. 12. april 2011 Andengradsligninger Frank Nasser 12. april 2011 c 2008-2011. Dette dokument må kun anvendes til undervisning i klasser som abonnerer på MatBog.dk. Se yderligere betingelser for brug her. Bemærk: Dette

Læs mere

Programmering C RTG - 3.3 09-02-2015

Programmering C RTG - 3.3 09-02-2015 Indholdsfortegnelse Formål... 2 Opgave formulering... 2 Krav til dokumentation af programmer... 3 ASCII tabel... 4 Værktøjer... 5 Versioner af ASCII tabel... 6 v1.9... 6 Problemer og mangler... 6 v2.1...

Læs mere

Brugergrænseflader i VSU

Brugergrænseflader i VSU 28-10-09 Side 1/5 Brugergrænseflader i Dette notat giver et praktisk eksempel på, hvordan brugergrænsefladen kan håndteres i. Notatet er en konsekvens af en lidt overfladisk beskrivelse i [B&D00] samt

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2018 Projekt, del II Institut for matematik og datalogi Syddansk Universitet 20. marts, 2019 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5 Databaser og SQL Introduktion til SQL Kap 1-5 1 Dagens gang Databaser Database begreber Mapning af klasser til relationel model Normalisering Opgaver til næste gang 2 Databasebegreber A database is a:

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2018 Projekt, del II Institut for matematik og datalogi Syddansk Universitet 13. marts, 2018 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

Rolf Fagerberg. Forår 2013

Rolf Fagerberg. Forår 2013 Forår 2013 Mål for i dag Dagens program: 1 2 3 4 5 6 Forudsætninger: DM536 og DM537 Timer: 50% forelæsninger, 50% øvelser Forudsætninger: DM536 og DM537 Eksamenform: Skriftlig eksamen: Timer: 50% forelæsninger,

Læs mere

Andreas Lauge V. Hansen klasse 3.3t Roskilde HTX

Andreas Lauge V. Hansen klasse 3.3t Roskilde HTX IT -Eksamen Andreas Lauge V. Hansen klasse 3.3t Roskilde HTX [Vælg en dato] Indhold Indledning... 2 Teori... 3 Hvorfor dette design... 4 Produktet... 4 Test og afprøvning... 9 Konklusion... 10 Indledning

Læs mere

Indhold. Maskinstruktur... 3. Kapitel 1. Assemblersprog...3. 1.1 Indledning...3 1.2 Hop-instruktioner... 7 1.3 Input og output...

Indhold. Maskinstruktur... 3. Kapitel 1. Assemblersprog...3. 1.1 Indledning...3 1.2 Hop-instruktioner... 7 1.3 Input og output... Indhold Maskinstruktur... 3 Kapitel 1. Assemblersprog...3 1.1 Indledning...3 1.2 Hop-instruktioner... 7 1.3 Input og output... 9 Kapitel 2. Maskinkode... 13 2.1 Den fysiske maskine... 13 2.2 Assemblerens

Læs mere

Studieordning del 4-2014

Studieordning del 4-2014 Studieordning del 4-2014 Fagbeskrivelser Datamatiker AP Graduate in Computer Science Version 1.2 Revideret januar 2015 Side 0 af 10 Indhold del 4 Fagbeskrivelser 1. Faget Programmering (PRO)...2 2. Faget

Læs mere

Software Construction 1 semester (SWC) Spørgsmål 1

Software Construction 1 semester (SWC) Spørgsmål 1 Spørgsmål 1 Objekter #1 Giv en kort præsentation af begrebet objekt, samt hvorledes du erklærer(declare), opretter(create) og bruger objekter Du kan beskrive o Datatyper o Variable / Instans variable /

Læs mere

Dokumentation af programmering i Python 2.75

Dokumentation af programmering i Python 2.75 Dokumentation af programmering i Python 2.75 Af: Alexander Bergendorff Jeg vil i dette dokument, dokumentere det arbejde jeg har lavet i løbet opstarts forløbet i Programmering C. Jeg vil forsøge, så vidt

Læs mere

Lektion 3. Grundlæggende programmering i VR

Lektion 3. Grundlæggende programmering i VR Lektion 3 Grundlæggende programmering i VR Plan for i dag UML Usecase diagrammer Aktivitets diagrammer Klasse diagrammer Udforskning af forskelligt VR og andre måder at udvide virkeligheden på Cardboard

Læs mere

App til indmelding af glemt check ud

App til indmelding af glemt check ud App koncept til indmelding af glemt check ud App til indmelding af glemt check ud 5. mar. 2015 Side 1 App koncept til indmelding af glemt check ud 1 Introduktion Flg. er en besvarelse til en idekonkurrence

Læs mere

Andengradsligninger. Frank Nasser. 11. juli 2011

Andengradsligninger. Frank Nasser. 11. juli 2011 Andengradsligninger Frank Nasser 11. juli 2011 2008-2011. Dette dokument må kun anvendes til undervisning i klasser som abonnerer på MatBog.dk. Se yderligere betingelser for brug her. Indhold 1 Introduktion

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2013 Projekt, del I Institut for matematik og datalogi Syddansk Universitet 5. marts, 2013 Dette projekt udleveres i to dele. Hver del har sin deadline, således

Læs mere

ER-modellen. Databaser, efterår Troels Andreasen. Efterår 2002

ER-modellen. Databaser, efterår Troels Andreasen. Efterår 2002 Databaser, efterår 2002 ER-modellen Troels Andreasen Datalogiafdelingen, hus 42.1 Roskilde Universitetscenter Universitetsvej 1 Postboks 260 4000 Roskilde Telefon: 4674 2000 Fax: 4674 3072 www.dat.ruc.dk

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2019 Projekt, del III Institut for matematik og datalogi Syddansk Universitet 10. april, 2019 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

Kursusgang 11. Oversigt: Sidste kursusgang Værktøjer til udvikling og implementering af HCI-design Oversigt over Java Swing

Kursusgang 11. Oversigt: Sidste kursusgang Værktøjer til udvikling og implementering af HCI-design Oversigt over Java Swing Kursusgang 11 Oversigt: Sidste kursusgang Værktøjer til udvikling og implementering af HCI-design Oversigt over Java Swing Design af brugerflader 11.1 Samme sted Forskellige steder Sidste kursusgang Samtidigt

Læs mere

Videregående Programmering for Diplom-E Noter

Videregående Programmering for Diplom-E Noter Videregående Programmering for Diplom-E Noter 1. Uddelegering Ét af de væsentlige principper i objektorienteret programmering er, at enhver klasse selv skal kunne "klare ærterne". Enhver klasse skal altså

Læs mere

Spil Rapport. Spil lavet i GameMaker. Kevin, Mads og Thor 03-02-2011

Spil Rapport. Spil lavet i GameMaker. Kevin, Mads og Thor 03-02-2011 Spil Rapport Spil lavet i GameMaker Kevin, Mads og Thor 03-02-2011 Indholdsfortegnelse Indledning... 2 HCI... 2 Planlægning / Elementær systemudvikling... 2 Kravspecifikationer... 4 Spil beskrivelse...

Læs mere

IFC Egenskaber. Mohammad Hussain Parsianfar s102951 BYG DTU

IFC Egenskaber. Mohammad Hussain Parsianfar s102951 BYG DTU Mohammad Hussain Parsianfar s102951 Indholdsfortegnelse 1 Introduktion... 3 1.1 Hvorfor er det interessant... 3 1.2 Formål... 4 2 Simplebim... 5 2.1 Præsentation af softwaren... 5 2.1.1 Brugergrænseflade...

Læs mere

Procesbeskrivelse - Webprogrammering

Procesbeskrivelse - Webprogrammering Procesbeskrivelse - Webprogrammering Indholdsfortegnelse Forudsætninger... 1 Konceptet... 2 Hjemmesiden... 2 Server-side... 3 Filstrukturen... 3 Databasehåndtering og serverforbindelse... 4 Client-side...

Læs mere

BAAN IVc. Brugervejledning til BAAN Data Navigator

BAAN IVc. Brugervejledning til BAAN Data Navigator BAAN IVc Brugervejledning til BAAN Data Navigator En udgivelse af: Baan Development B.V. P.O.Box 143 3770 AC Barneveld Holland Trykt i Holland Baan Development B.V. 1997. Alle rettigheder forbeholdes.

Læs mere

Visualiseringsprogram

Visualiseringsprogram Visualiseringsprogram Programmering C - eksamensopgave Rami Kaddoura og Martin Schmidt Klasse: 3.4 Vejleder: Karl Bjarnason Roskilde Tekniske Gymnasium Udleveringsdato: 02-03-2012 Afleveringsdato: 11-05-12

Læs mere

Lærer nye styresystemer Installerer programmer som kun kan bruges i ældre versioner

Lærer nye styresystemer Installerer programmer som kun kan bruges i ældre versioner Virtuel PC Fordele/ulemper Fordele: Lærer nye styresystemer Installerer programmer som kun kan bruges i ældre versioner Ulemper: Reserverer RAM (Windows 7) Problemer med at ureglementeret lukke ned Mister

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Ugeseddel 4 1. marts - 8. marts

Ugeseddel 4 1. marts - 8. marts Ugeseddel 4 1. marts - 8. marts Læs følgende sider i kapitel 6 i lærebogen: s. 233 258 og s. 291 317 (afsnit 6.3 overspringes). Begynd at overveje, hvad afleveringsopgaven skal omhandle. Læs vejledningen,

Læs mere

Studieordning del 4-2014

Studieordning del 4-2014 Studieordning del 4-2014 Fagbeskrivelser Datamatiker AP Graduate in Computer Science Version 1.3 Revideret august 2015 Side 0 af 12 Indhold del 4 Fagbeskrivelser 1. Faget Programmering (PRO)...2 2. Faget

Læs mere

Object-Relational Mapping

Object-Relational Mapping Databaser for udviklere () Datamatiker TietgenSkolen Underviser: Allan Helboe 06-06-2010 Problemformulering Denne opgave er et forsøg på at beskrive problemerne der opstår ved anvendelsen af en relationel

Læs mere

Software Dokumentation

Software Dokumentation Software Dokumentation Jan Boddum Larsen Teknologi B og A på HTX Dokumentation af software i Teknologi I samfundet sker der en bevægelse mod mere digitale løsninger i teknologi. Det betyder at software

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2016 Projekt, del III Institut for matematik og datalogi Syddansk Universitet 20. april, 2016 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

Objektorientering. Programkvalitet

Objektorientering. Programkvalitet 1 PROSA-Bladet nr. 4 1993 Objektorientering = Programkvalitet? Af Finn Nordbjerg, adjunkt ved Datamatikeruddannelsen, Aalborg Handelskole 1. Indledning Objektorientering er blevet et edb-fagets mest udbredte

Læs mere

Database for udviklere. Jan Lund Madsen PBS10107

Database for udviklere. Jan Lund Madsen PBS10107 Database for udviklere Jan Lund Madsen PBS10107 Indhold LINQ... 3 LINQ to SQL og Arkitektur... 3 O/R designere... 5 LINQ Den store introduktion med.net 3.5 er uden tvivl LINQ(udtales link): Language-INtegrated

Læs mere

Arkitektur for begyndere

Arkitektur for begyndere Denne guide er oprindeligt udgivet på Eksperten.dk Arkitektur for begyndere Denne artikel beskriver forskellige basale n-tier arkitekturer. Som man bør kende og have valgt inden man går igang med at udvikle

Læs mere

4 Basal Objekt-orienteret Programmering I.

4 Basal Objekt-orienteret Programmering I. 4 Basal Objekt-orienteret Programmering I. Klasser i forhold til abstrakte datatyper og record-typer. Variable og operationer. Klasse-interfaces. Klasser og typer. Klasse-instantiering og initialisering.

Læs mere

Læringsprogram. Christian Hjortshøj, Bjarke Sørensen og Asger Hansen Vejleder: Karl G Bjarnason Fag: Programmering Klasse 3.4

Læringsprogram. Christian Hjortshøj, Bjarke Sørensen og Asger Hansen Vejleder: Karl G Bjarnason Fag: Programmering Klasse 3.4 Læringsprogram Christian Hjortshøj, Bjarke Sørensen og Asger Hansen Vejleder: Karl G Bjarnason Fag: Programmering Klasse 3.4 R o s k i l d e T e k n i s k e G y m n a s i u m Indholdsfortegnelse FORMÅL...

Læs mere

Arduino Programmering

Arduino Programmering Microcontroller, Arduino I teknologi skal vi lære at lave programmer til uc for at have muligheden til eksamen at kunne lave intelligente el-produkter. I hvert fald skal vi have set mulighederne, og forstået

Læs mere

13 Objekt-orienteret Design.

13 Objekt-orienteret Design. 13 Objekt-orienteret Design. Analyse i forhold til design. Programbeskrivelse og designbeskrivelse. Sømløs udvikling. Design i forhold til OO Eiffel programmering. Kategorisering af klasser i et design.

Læs mere

Grundlæggende OOA - OOD

Grundlæggende OOA - OOD Grundlæggende OOA - OOD Dette kursus henvender sig til personer, der har lille eller ingen erfaring med softwareudvikling. Med udgangspunkt i UML opbygges et solidt kendskab til softwareudviklingens kunst

Læs mere

Design dit eget computerspil med Kodu

Design dit eget computerspil med Kodu Design dit eget computerspil med Kodu I sensommeren var vi to CFU-konsulenter ude i SFO en på Borup Ris Skolens Grønbro-afdeling. Her var vi sammen med børnene for at få erfaringer i arbejdet med platformen

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2017 Projekt, del III Institut for matematik og datalogi Syddansk Universitet 6. april, 2017 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

Svendeprøve Projekt Tyveri alarm

Svendeprøve Projekt Tyveri alarm Svendeprøve Projekt Tyveri alarm Påbegyndt.: 8/2-1999 Afleveret.: 4/3-1999 Projektet er lavet af.: Kasper Kirkeby Brian Andersen Thomas Bojer Nielsen Søren Vang Jørgensen Indholds fortegnelse 1. INDLEDNING...3

Læs mere

Delphi og Databaser for begyndere

Delphi og Databaser for begyndere Denne guide er oprindeligt udgivet på Eksperten.dk Delphi og Databaser for begyndere Denne artikel handler om hvordan man udnytter noget af det bedste i Delphi: Dets gode muligheder for integrering med

Læs mere

Udvidelse og specialisering. Klassehierarkier. Nedarvningsterminologi. Interfaces. Statiske og dynamiske typer. Polymorfi. Abstrakte klasser.

Udvidelse og specialisering. Klassehierarkier. Nedarvningsterminologi. Interfaces. Statiske og dynamiske typer. Polymorfi. Abstrakte klasser. 10 Nedarvning I. Udvidelse og specialisering. Klassehierarkier. Nedarvningsterminologi. Interfaces. Statiske og dynamiske typer. Polymorfi. Dynamisk binding og virtuelle operationer. Decentraliseret/centraliseret

Læs mere

Kommentar fra KMS til Specifikation af Serviceinterface for Person

Kommentar fra KMS til Specifikation af Serviceinterface for Person Kommentar fra KMS til Specifikation af Serviceinterface for Person Organisation Side Kapitel Afsnit/figur/tabel /note Type af kommentar (generel (G), redaktionel (R), teknisk (T)) Kommentar KMS-1 G Godt

Læs mere

Rolf Fagerberg. Forår 2012

Rolf Fagerberg. Forår 2012 Forår 2012 Mål for i dag Dagens program: 1 2 3 4 5 6 Forudsætninger: DM502 og DM503 Timer: 50% forelæsninger, 50% øvelser Forudsætninger: DM502 og DM503 Eksamenform: Skriftlig eksamen: Timer: 50% forelæsninger,

Læs mere

Hvem er vi? Kursus Introduktion. Kursuslærerne. Agenda for i dag

Hvem er vi? Kursus Introduktion. Kursuslærerne. Agenda for i dag Hvem er vi? Kursus Introduktion Anne Haxthausen ah@imm.dtu.dk Informatics and Mathematical Modelling Technical University of Denmark 100 studerende med forskellig baggrund: software teknologi It og Kom

Læs mere

Rolf Fagerberg. Forår 2015

Rolf Fagerberg. Forår 2015 Forår 2015 Dagens program 1 2 3 4 5 Underviser:, IMADA Forskningsområde: algoritmer og datastrukturer Underviser:, IMADA Forskningsområde: algoritmer og datastrukturer Deltagere: BA i Datalogi BA i Software

Læs mere

Softwaretest. - også af "ikke testbar" software. DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco.

Softwaretest. - også af ikke testbar software. DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco. Softwaretest - også af "ikke testbar" software DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco.dk Hvorfor softwaretest? Software er sjældent fejlfri Test sikrer at softwaren

Læs mere

Objektorienteret Programmering

Objektorienteret Programmering Objektorienteret Programmering Struktureret Systemudvikling Jan Bendtsen Automation and Control Indhold Lidt om programmeringssprog Klasser i Java Klasser i C++ Oversættelse og kørsel af kode Et eksempel:

Læs mere

Klasser og Objekter i Python. Uge 46 Learning Python: kap 15-16, 19-22.

Klasser og Objekter i Python. Uge 46 Learning Python: kap 15-16, 19-22. Klasser og Objekter i Python Uge 46 Learning Python: kap 15-16, 19-22. Klasser og objekter En klasse beskriver en klump af samhørende funktioner og variable En klasse er en beskrivelse. En kage form Klassens

Læs mere

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning:

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning: Introduktion til EA3 Mit navn er Marc de Oliveira. Jeg er systemanalytiker og datalog fra Københavns Universitet og denne artikel hører til min artikelserie, Forsimpling (som også er et podcast), hvor

Læs mere

Component based software enginering Diku 2005 Kritikopgave

Component based software enginering Diku 2005 Kritikopgave Component based software enginering Diku 2005 Kritikopgave Nicolas Møller Henschel 17. april 2005 1 Indhold 1 Indledning 3 2 Indhold 3 2.1 Introduktionen.......................... 3 2.1.1 Mangler..........................

Læs mere

Objektorienteret design med arv og polymorfi:

Objektorienteret design med arv og polymorfi: Note til Programmeringsteknologi Akademiuddannelsen i Informationsteknologi Objektorienteret design med arv og polymorfi: Substitutionsprincippet Composite Design Pattern Finn Nordbjerg Side 1 Objektorienteret

Læs mere

Lær Python dag 1 - modul 1

Lær Python dag 1 - modul 1 Lær Python dag 1 - modul 1 Introduktion, basis python Steffen Berg Klenow Jonas Bamse Andersen Syddansk Universitet Indhold 1. Velkommen 2. Programmering i python 3. Typer, variabler og udtryk 1 Velkommen

Læs mere

Sikre Beregninger. Kryptologi ved Datalogisk Institut, Aarhus Universitet

Sikre Beregninger. Kryptologi ved Datalogisk Institut, Aarhus Universitet Sikre Beregninger Kryptologi ved Datalogisk Institut, Aarhus Universitet 1 Introduktion I denne note skal vi kigge på hvordan man kan regne på data med maksimal sikkerhed, dvs. uden at kigge på de tal

Læs mere

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Stamoplysninger til brug ved prøver til gymnasiale uddannelser Termin Institution Uddannelse Fag og niveau Lærer(e) Hold Termin hvori undervisningen afsluttes: maj-juni 2014 HTX

Læs mere

Afsnittet er temmelig teoretisk. Er du mere til det praktiske, går du blot til det næste afsnit.

Afsnittet er temmelig teoretisk. Er du mere til det praktiske, går du blot til det næste afsnit. Afsnittet er temmelig teoretisk. Er du mere til det praktiske, går du blot til det næste afsnit. XML (eng. extensible Markup Language) XML er en måde at strukturere data på i tekstform. På samme måde som

Læs mere

BlogReader 1.0.0 Af Jonas F. Jensen.

BlogReader 1.0.0 Af Jonas F. Jensen. BlogReader 1.0.0 Af Jonas F. Jensen. Indholdsfortegnelse Forord.....3 Hvad er BlogReader?......4 RSS, XML og sematic web......4 Klasse struktur i UML......4 Overordnet opbygning......5 UML diagram over

Læs mere

Program for møde fredag d. 22/2-2002

Program for møde fredag d. 22/2-2002 Program for møde fredag d. 22/2-2002 Disposition for den indledende præsentation af problemstillinger Kort beskrivelse af projektets struktur, hvilket leder frem til hovedtemaet for den efterfølgende diskussion

Læs mere

Michael Jokil 11-05-2012

Michael Jokil 11-05-2012 HTX, RTG Det skrå kast Informationsteknologi B Michael Jokil 11-05-2012 Indholdsfortegnelse Indledning... 3 Teori... 3 Kravspecifikationer... 4 Design... 4 Funktionalitet... 4 Brugerflade... 4 Implementering...

Læs mere

GESA, et GEnerelt System til Analyse af naturlige sprog, udformet som et oversætter-fortolker system med virtuel mellemkode

GESA, et GEnerelt System til Analyse af naturlige sprog, udformet som et oversætter-fortolker system med virtuel mellemkode Jens Erlandsen laml Njalsgade 96 DK 2300 kbh. S. GESA, et GEnerelt System til Analyse af naturlige sprog, udformet som et oversætter-fortolker system med virtuel mellemkode. Parsingsystemer til automatisk

Læs mere

educasoft - en professionel samarbejdspartner med speciale i uddannelse!

educasoft - en professionel samarbejdspartner med speciale i uddannelse! Velkommen til educasoft's hjemmeside educasoft - en professionel samarbejdspartner med speciale i uddannelse! Professionelle undervisere Undervisning i virksomheden Undervisning dag/aften eller week-end

Læs mere

applikation----x----odbc driver manager----foobar ODBC driver----foobar database

applikation----x----odbc driver manager----foobar ODBC driver----foobar database Denne guide er oprindeligt udgivet på Eksperten.dk ODBC i C/C++ Denne artikel beskriver hvordan man bruger ODBC i C/C++. Der er beskrivelse af build med forskellige compilere. Den forudsætter lidt kendskab

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Introduktion til kurset Rolf Fagerberg Forår 2019 1 / 20 Hvem er vi? Underviser: Rolf Fagerberg, Institut for Matematik og Datalogi (IMADA) Forskningsområde: algoritmer

Læs mere

XProtect-klienter Tilgå din overvågning

XProtect-klienter Tilgå din overvågning XProtect-klienter Tilgå din overvågning Tre måder at se videoovervågning på For at skabe nem adgang til videoovervågning tilbyder Milestone tre fleksible brugergrænseflader: XProtect Smart Client, XProtect

Læs mere

Projektbeskrivelse. IT B og Programmering C. Klasse 3.4. Louis Drejer, Markus Duus og Mikkel Jensen. Fra

Projektbeskrivelse. IT B og Programmering C. Klasse 3.4. Louis Drejer, Markus Duus og Mikkel Jensen. Fra Projektbeskrivelse IT B og Programmering C Klasse 3.4 Louis Drejer, Markus Duus og Mikkel Jensen Fra 0 05 04 05 Analyse I dagens danmark spiller computeren kæmpe rolle. Man kan se på en statistik fra Gallup,

Læs mere

Sider og segmenter. dopsys 1

Sider og segmenter. dopsys 1 Sider og segmenter dopsys 1 Lokal vs global sideallokering (1) Med (a) som udgangspunkt giver (b) lokal hhv. (c) global allokering forskellige resultater dopsys 2 Lokal vs global sideallokering (2) Den

Læs mere

Roskilde Tekniske Gymnasium. Eksamensprojekt. Programmering C niveau

Roskilde Tekniske Gymnasium. Eksamensprojekt. Programmering C niveau Roskilde Tekniske Gymnasium Eksamensprojekt Programmering C niveau Andreas Sode 09-05-2014 Indhold Eksamensprojekt Programmering C niveau... 2 Forord... 2 Indledning... 2 Problemformulering... 2 Krav til

Læs mere

Sider og segmenter. dopsys 1

Sider og segmenter. dopsys 1 Sider og segmenter dopsys 1 Lokal vs global sideallokering (1) Med (a) som udgangspunkt giver (b) lokal hhv. (c) global allokering forskellige resultater dopsys 2 Lokal vs global sideallokering (2) Den

Læs mere

Integration mellem OpenBizBox og E conomic

Integration mellem OpenBizBox og E conomic Integration mellem OpenBizBox og E conomic 1. Introduktion Integrationens formål er at sørge for at ordre der laves i OpenBizBox automatisk bliver eksporteret som en ordre i E conomic. Hvorved det gøres

Læs mere

Læseplan for valgfaget teknologiforståelse

Læseplan for valgfaget teknologiforståelse Læseplan for valgfaget teknologiforståelse (forsøg) Indhold Indledning 3 Trinforløb for 7.- 9. klassetrin 4 Design 4 Programmering 5 Indledning Valgfaget teknologiforståelse er etårigt og kan vælges i

Læs mere

Internet Information Services (IIS)

Internet Information Services (IIS) Internet Information Services (IIS) Casper Simonsen & Yulia Sadovskaya H1we080113 06-11-2013 Indholdsfortegnelse Problemformulering... 2 Hvorfor:... 2 Hvad:... 2 Hvordan:... 2 Problembehandling... 3 Introduktion...

Læs mere

LEVERANCE 1.3. Model for kvalitetssikring

LEVERANCE 1.3. Model for kvalitetssikring LEVERANCE 1.3 Model for kvalitetssikring Udarbejdelse af kvalitetssikringsmodel, krav til open source kode og dokumentation og godkendelsesprocedurer m.v. Samt fokus på understøttelse af CE-mærkning. 1

Læs mere

Programmering 19/03-2012 ROSKILDE TEKNISKE GYMNASIUM. Projektbeskrivelse. Programmering. Rasmus Kibsgaard Riehn-Kristensen

Programmering 19/03-2012 ROSKILDE TEKNISKE GYMNASIUM. Projektbeskrivelse. Programmering. Rasmus Kibsgaard Riehn-Kristensen ROSKILDE TEKNISKE GYMNASIUM Projektbeskrivelse Programmering Rasmus Kibsgaard Riehn-Kristensen 19-03-2012 Indholdsfortegnelse 1. Indledning... 3 2. Problemobservation.... 4 2.1 Egen erfaring... 4 3. Problemformulering...

Læs mere

Pointen med Funktioner

Pointen med Funktioner Pointen med Funktioner Frank Nasser 0. april 0 c 0080. Dette dokument må kun anvendes til undervisning i klasser som abonnerer på MatBog.dk. Se yderligere betingelser for brug her. Bemærk: Dette er en

Læs mere

Administration af subsites BRUGERVEJLEDNING FOR ADMINISTRATOREN

Administration af subsites BRUGERVEJLEDNING FOR ADMINISTRATOREN Administration af subsites BRUGERVEJLEDNING FOR ADMINISTRATOREN Indholdsfortegnelse Introduktion... 2 Definitioner... 2 Generelt... 3 Oprettelse af en skabelon... 4 Sidetypeskabeloner... 5 Globale displaymoduler...

Læs mere

IT Support Guide. Opsætning af netværksinformationer i printere

IT Support Guide. Opsætning af netværksinformationer i printere IT Support Guide Denne guide er hentet på www.spelling.dk Program: Hardware / Software Program sprog version: Guide emne: Opsætning af netværksinformationer i printere Publikationsnr.: 040109.02.01 Udgivet

Læs mere

Postregistrering Eksamensprojekt i Programmering C Lavet af: Frantz Furrer Svendborg Erhvervsskole HTX Vejleder: Claus Borre

Postregistrering Eksamensprojekt i Programmering C Lavet af: Frantz Furrer Svendborg Erhvervsskole HTX Vejleder: Claus Borre Postregistrering Eksamensprojekt i Lavet af: Frantz Furrer Vejleder: Claus Borre Side af 4 Titelblad: Skolens navn: Svendborg Tekniske Gymnasium - Rapport: Rapportens titel: Postregistrering Side antal:

Læs mere

Hvilke overvejelser bør materialeproducenten gøre om produktdata?

Hvilke overvejelser bør materialeproducenten gøre om produktdata? Data på BIM-objekter Data bliver en stadig vigtigere del af BIM-objekter. I dag har data lige så stor og i flere tilfælde større betydning end 3D-geometrien på BIM-objektet. Hvilke overvejelser bør materialeproducenten

Læs mere

Datalogi OB, Efterår 2002 OH er, forelæsning 3/9-2002 - forstå datastrukturer og algoritmer (teoretisk forståelse og intuition)

Datalogi OB, Efterår 2002 OH er, forelæsning 3/9-2002 - forstå datastrukturer og algoritmer (teoretisk forståelse og intuition) Datalogi OB, Efterår 2002 OH er, forelæsning 3/9-2002 Datastrukturer og algoritmer Henning Christiansen henning@ruc.dk http://www.ruc.dk/~henning Formål: at kunne - forstå datastrukturer og algoritmer

Læs mere

Hvorfor skal vi bruge objekt orienteret databaser?

Hvorfor skal vi bruge objekt orienteret databaser? OODBMS Vs. RDBMS 1 Indholdsfortegnelse Hvorfor skal vi bruge objekt orienteret databaser?... 3 OODBMS i erhvervslivet... 4 Bagsiden af medaljen... 5 OODBMS i praksis... 6 Konklusion... 8 2 Hvorfor skal

Læs mere

Bits DM534. Rolf Fagerberg, 2012

Bits DM534. Rolf Fagerberg, 2012 Bits DM534 Rolf Fagerberg, 2012 Resume af sidst Overblik over kursus Introduktion. Tre pointer: Datalogi er menneskeskabt og dynamisk. Tidslinie over fremskridt mht. ideer og hardware. Algoritme er et

Læs mere

Introduktion til DM507

Introduktion til DM507 Introduktion til DM507 Rolf Fagerberg Forår 2017 1 / 20 Hvem er vi? Underviser: Rolf Fagerberg, IMADA Forskningsområde: algoritmer og datastrukturer 2 / 20 Hvem er vi? Underviser: Rolf Fagerberg, IMADA

Læs mere

5. OPSÆTNING DOKUMENTSKABELONER 5.1 TRIN

5. OPSÆTNING DOKUMENTSKABELONER 5.1 TRIN 5. OPSÆTNING DOKUMENTSKABELONER Under fanen Dok. skabeloner kan du arbejde med de skabeloner som du har i systemet, eller du kan oprette nye. I denne vejledning kigger vi på hvordan du kan tilrette selve

Læs mere

RMI introduktion. Denne artikel beskriver Java RMI (Remtote Method Invocation).

RMI introduktion. Denne artikel beskriver Java RMI (Remtote Method Invocation). Denne guide er oprindeligt udgivet på Eksperten.dk RMI introduktion Denne artikel beskriver Java RMI (Remtote Method Invocation). Den beskriver teorien bag RMI, viser et simpelt kode eksempel og forklarer

Læs mere