IT og Programmering eksamens projekt

IT og Programmering eksamens projekt Visualisering af Gravitation Roskilde HTX Anders Kær Bennetsen D. 20-05-2010 IT og Programmering

1.1 Indledning:... 4 1.2 Beskrivelse af Ide:... 4 1.3 Definition af målgruppe:... 4 1.3.1Persona:... 4 1.3.1.1Persona 1:... 4 1.3.1.2 Persona 2:... 4 1.3.2 Scenarier:... 4 1.3.2.1 Scenario 1:... 4 1.3.2.2 Scenario 2:... 4 1.3.3 Konklusion på persona og scenarier:... 5 1.4 Krav:... 5 1.5 Løsnings forslag:... 5 1.6 Afgrænsning:... 5 1.7 Valg af værktøj:... 6 1.7.1 Krav til værktøj:... 6 1.7.1 Begrundelse for valg:... 6 2. Teori:... 6 2.1 Ekstra biblioteker til Python:... 6 2.1.1Hvad er API?... 6 2.2 GUI brugt i Python:... 6 2.3 Iteration:... 7 2.3.1 Indledende aktivitet:... 7 2.3.1.1Hvem siger hvad:... 7 2.3.1.2 Til hvem:... 7 2.3.1.3 Gennem hvilket medie:... 7 2.3.1.4 Med hvilken effekt:... 7 2.3.1.5 User stories:... 7 2.3.2 Planlægning:... 8 2.3.3 Krav og test specifikation:... 8 2.3.4 Design:... 8 2.3.5 Test:... 8 2.3.6 Afsluttende fase:... 8 3. udvikling:... 8

3.1 User stories:... 8 3.1.1 Spørgsmål:... 8 3.1.1.1 Hvordan vil du forvente at hastigheden af en simulation af planeters bevægelse:... 8 3.1.1.2 Hvor mange objekter skal en simulation have(antal planeter):... 9 3.1.1.3 Skal en model bruge predefinerede værdier eller bruger definerede værdier:... 9 3.2 Endelig Kravspecifikation:... 9 3.3 Design:... 9 3.3.1 Indre Design:... 9 3.4 Prototype 1:... 10 3.5 Prototype 2:... 10 3.6 Prototybe 3... 11 3.7 Prototype 4:... 11 3.8 Prototype 5:... 12 3.9 Prototype 6:... 12 3.10 Prototype 7:... 13 3.11 Endelig version:... 13 4.Test... 13 4.1test metode:... 13 4.2 test resultat:... 13 5. Evt. forbedringer:... 14 6. Konklusion:... 14 7. Kommenteret kildekode(billag):... 15

1.1 Indledning: 1.2 Beskrivelse af Ide: I dette projekt vil jeg gerne beskæftige mig med formidlingen af hvordan gravitation påvirker ting i rummet, en ting der kan være svært at visualisere hvis man ikke har en god rummelig sans. For at kunne visualiser dette må man nødvendigvis have et display med en form for bevægelse af planetare modeller. For at lave en model der udregner gravitationen i et system skal man bruge 3 informationer. Position, masse og fart. Med disse kan man så finde den næste position ud fra de kræfter der virker på hver objekt. 1.3 Definition af målgruppe: Den målgruppe der sigtes efter er elever med fysik på A eller B niveau og deres lærere i faget fysik. Dette betyder at der er tale om en målgruppe med varierende viden inden for IT produkter. I følgende skal vi se på 2 persona som hver skal bruge programmet i en case for at forbedre deres forståelse af de rummelige aspekter af hvordan tyndekraft fungere. 1.3.1Persona: 1.3.1.1Persona 1: Persona nr.1 er en jens, en 52 år gammel fysik lære som skal bruge en metode til at vise sine elever effekten af gravitations kraften mellem læmmer i rummet. Jens har et udmærket forhold til programmel og har ikke problemer med at ændre konfigurationer for optimeret brug af sine programmer. Herud over er jens meget fascineret af den balance som styre vores solsystem så planeterne ikke banker sammen selv efter mange år. 1.3.1.2 Persona 2: Persona nr. 2 er lotte, hun er 18 og har fysik på A niveau hvor hun har svært ved at forstille sig hvordan gravitation virker i et rum og styrken af disse kræfter. Hun har ikke meget styr på computere og en fejl meddelelse på hindes pc bliver hun nød til at spørge om hjælp. Programmer må ikke være for svære eller for udregningsmæssigt da hun ikke har så meget processor kraft i sin pc. 1.3.2 Scenarier: 1.3.2.1 Scenario 1: Jens skal for sine 3.g er starte et nyt emne, gravitation. For at give eleverne en bedre forståelse at dette har han hentet programmet og køre et par simulationer. For at vise eleverne hvor skrøbeligt det system vi lever i er ændre han på nogle koefficienter så læmmer i stedet for at kredse ignorer hinanden og flyver ud i rummet eller blot støder sammen. 1.3.2.2 Scenario 2: Lotte skal har udtrukket fysik som mundtlig eksamenen og vil gerne læse op i sine emner. Hun kan dog ikke finde ud af hvordan planeter kan tiltrække hinanden og hvordan det kan se ud. Hun henter derfor programmet for at se hvordan dette ser ud. Da hendes vinde inden for computere er begrænset vælger hun en simpel version hvori der ikke er mange muligheder for at ændre på værdier eller hastighed. Da hun køre programmet kan hun se at hendes pc ikke kan følge med og hun genstarter derfor programmet og ændre hastigheden så den visuelle del sænker hastigheden.

1.3.3 Konklusion på persona og scenarier: For at tage højde for målgruppens svingene evner inden for computer kundskaber skal programmet have flere versioner eller settings der f.eks. låser nogen værdier så man uden det store arbejde kan få et konstruktivt billede af hvordan den valgte problemstilling. Dog skal der også være mere avancerede versioner hvori man kan ændre koefficienter så man kan får andre udgaver. 1.4 Krav: De foreløbige krav er at - Programmet skal kunne vise en simpel model. - Programmet skal derudover have en funktion til at reducere antallet af udregninger til svagere maskiner. - Programmet skal visuelt vise bevægelser af lemmer der bevæger sig pga. gravitation. 1.5 Løsnings forslag: Til venstre ses en skitse af løsning 1 hvilket er en visuel fremstilling hvor der i venstre side er nogle tekst bokse hvor i man kan skrive specifikationer for den ønskede model. Derudover er der nogle knapper der ændre synsvinklen og en knap der reseter modellen. I den højre del er det visuelle medie som viser virkningen af gravitationen ud fra nogle figurers bevægelser. 1.6 Afgrænsning: For at holde programmet simpelt holder jeg programmet som en model af maksimalt 3 lemmer. På den måde kan jeg også minimere belastningen af pc en da man for hvert lemme man tilføjer skal lave udregninger på hvert af de andre objekter. Således at antallet af udregninger følger tabellen til højre. Derudover bruges en idealiseret udregning i det man antager at masserne er punktformede i modellen. Lemmer: Udregninger: 1 0 2 1 3 4 4 8 5 13

1.7 Valg af værktøj: 1.7.1 Krav til værktøj: Når man skal vælge værktøj ser jeg først på hvad jeg skal bruge for at programmet virker efter hensigten. For at virke efter de opstillede krav skal værktøjet have mulighed for at renderer 3d objekter. Der skal også være mulighed for en hvis HC interaktion idet brugeren skal kunne indtaste nogle værdier. 1.7.1 Begrundelse for valg: Af de værktøjer jeg er kendte med som overholder disse krav er Visual Python som har en nem kode når det gælder at flytte visuelle objekter rundt i en scene. Visual Python er desuden objekt baseret hvilket betyder at man kan lave det der hedder en class eller et objekt som er et bibliotek for et objekt. Dette betyder at man kan sammen holde 2 hele biblioteker mod hinanden eller blot enkelte dele. Som eks. Kan man have objektet earth. Earth har i sig selv ikke nogen værdi eller funktion. Man kan så tilføje værdier til classen earth som masse eller position. Man kan f.eks. tilføje nogle variable til en sphere som f.eks. mass eller radius. Disse har så nogle værdier som til sammen giver earth. 2. Teori: 2.1 Ekstra biblioteker til Python: Som tidligere nævnt bruger jeg Visual Python til at udvikle programmet. Det vil sige at jeg anvender python og tilføjer så Visual som er et API der fokusere på at tilføje visuelle dele til python og går det nemmere at lave ting i 3d. Derud over ændre den python så programmet kan bruge classes. 2.1.1Hvad er API? API er en computerens ordbog og check liste for hvad den skal gøre ved en kode. API en fortæller programmet at når der f.eks står print i koden skal den printe det der komme efter. Det er også API en der fortæller computeren hvordan programmet skal reagere på andre programmer. Alt dette kræver dog at det er indskrevet i API en 2.2 GUI brugt i Python: Når man arbejde i visual Python har man et GUI og en shell der ligger bagved. GUI en er bygget op af en eller flere scenes som er objekter med visse attributter. Disse scenes er vinduer. Inde i disse scenes kan man placere andre visuelle objekter som her vil optræde under dette objekt. Man anvender nedarvning som betyder at man underordner et objekt under et andet objekt. Man har så en forældre og en efterkommer. Efterkommeren arver så egenskaber fra forælderen. I dette tilfælde kan er de 2-3 lemmer som beskrives (disse er objekter) indordne dem under scenen som er et objekt i sig selv (rummet som de placeres i har nogle egenskaber som de underordnede objekter skal følge). I python kan man have flere aktive scenes. Man skifter mellem disse scenes med scenenavn.scelect() Dog kan programmet sagtens regne og ændre på variable/attributter der høre til andre scenes. At vælge en scene betyder blot at denne bliver default for nye objekter der bliver lavet.

2.3 Iteration: Når vi udvikler programmer bruger vi en udviklings metode som er den checkliste der skal løbes igennem. Man kan se dette som et while loop idet hvert trin er en opgave der skal løses før man går videre. Den metode vi anvender, er en metode inspireret af en metode kaldet Extreme programing. Denne metode tager udgangs punkt i at intet produkt er færdigt. Man vil altid kunne fortsætte metoden. Når man afslutter projektet er det af andre grunde så som tid eller penge. 2.3.1 Indledende aktivitet: Den indledende aktivitet er så og sige det tidspunkt man gør status. Man ser på hvad problemet er. Hvad skal der til for at løse dette. Man skal samtidig se på Laswells 5 spørgsmål. - Hvem siger hvad - Til hvem - Gennem hvad medie - Med hvilken effekt 2.3.1.1Hvem siger hvad: Først identificere vi afsenderen. Afsenderen af programmet er som udgangs punkt programmøren eller personen der har bestilt programmet. Dog kan man i dette tilfælde se dette projekts afsender som en oplyst lærer der udbreder en bedre forståelse for de rummelige konsekvenser af gravitationskraften. Hvilket også giver hvad hvilket er en visuel præsentation af konsekvenserne af gravitationskræften mellem lemmer. 2.3.1.2 Til hvem: Nu skal man så finde modtageren. Modtageren er enten en lærer eller elev. Kortsagt en person inden for målgruppen. 2.3.1.3 Gennem hvilket medie: Mediet i dette tilfælde er programmet som informationerne formidles igennem. 2.3.1.4 Med hvilken effekt: Den ønskede effekt er en bedre forståelse af de rummelige konsekvenser af gravitationskraften. 2.3.1.5 User stories: For at finde ud af hvad der er ønsket af brugeren anvender man de såkaldte user stories hvilket er et simpelt spørgsmål til en bruger om hvad personen forventer af programmet eller hvad der ønskes af programmet. F.eks. kan en bruger ønske at programmet skal kunne ændre hastighed eller vise en printe noget data. Forventningerne fra disse User stories bruges så i den samlede udviklings metode under testog krav- specifikation.

2.3.2 Planlægning: I planlægnings fasen udvælger man de user stories man vil arbejde med i denne iteration. Dette gør man ud fra de kriterier man har opstillet i den indledende fase. 2.3.3 Krav og test specifikation: I krav og test specifikations fasen ser man på hvad user storien beder om og hvad de generelle krav beder om. Det er også på dette tidspunkt man se på hvordan man kan teste programmet og beslutter om hvilke tests der skal bruges til de tests der skal ligge til grund for næste iteration. 2.3.4 Design: Man har nu alle kravene der skal bruges for at forbedre programmet. I design fasen finde man så den løsning der skal til for at overholde de krav der er blevet opstillet i de foregående faser. 2.3.5 Test: I denne fase tester man programmet med de tests man lavede i fase 4. herefter konkludere man på udviklingen over denne iteration Herfra ser man om man har midlerne til at gentage processen en gang til. Hvis man har, starter man med det nye udgangspunkt i fase 2. Hvis man ikke har, er produktet færdigt 2.3.6 Afsluttende fase: I den afsluttende fase konkluderes så på produktet som en helhed og man ser om det lever op til de overordnede krav. Man kan dog selv om et produkt er gået i den afsluttende fase sagtens starte ved fase 2 igen hvis man får mere tid eller flere midler så man kan fortsætte iterationen. 3. udvikling: Nu kan selve produkt udviklingen gå i gang. Da jeg følger metoden som er beskrevet tidligere er jeg nået til kravfangsten. Indkredsning af de specifikke krav samt bruge af nogle user stories. Planlægningen og den indledende fase er beskrevet i indledningen(1-1.7.1). 3.1 User stories: For at få en ide om hvad brugerne forventer, anvender man user stories til at indsnævre hvad programmet skal kunne. 3.1.1 Spørgsmål: 3.1.1.1 Hvordan vil du forvente at hastigheden af en simulation af planeters bevægelse: Jeg forventer at hastigheden af en sådan simulation skal være mindst 10 timer i sekundet for at man kan se noget hastigheden skal være variable så man kan ændre den fra et par timer i sekundet til 1 uge per sekund

3.1.1.2 Hvor mange objekter skal en simulation have(antal planeter): ikke ret mange, hvis der er for mange bliver det for uigennemskueligt og man kan ikke se hvad der betyder hvad i en evt. model 2-3 vil være et godt antal, måske 4 hvis det er en mere avanceret model 3.1.1.3 Skal en model bruge predefinerede værdier eller bruger definerede værdier: som udgangs punk vil det være mest visende hvis man kan se f.eks. en stor planet med 2 kredsende omkring i en simpel model til fremvisning og forståelse vil det være bedst at det ikke er for avanceret, dog tror jeg at det stadig vil være lærende at lege rundt med koefficienterne og se udfaldet af dette 3.2 Endelig Kravspecifikation: Nu se man så på de endelige krav som er en videreudvikling af de første krav og user stories - Programmet skal kunne vise en simpel model og kunne aktiveres så man selv kan indtaste værdier. - Programmet skal derudover have en funktion til at reducere antallet af udregninger til svagere maskiner. Samt farten på udregningerne så man kan sænke hastigheden af simulationen. - Programmet skal kunne aktivere at man selv kan indtaste værdier til modellen. - Programmet skal visuelt vise bevægelser af lemmer der bevæger sig pga. gravitation. 3.3 Design: Nu skal der udvikles et design der overholder karvende både et indre og ydre design. Jeg vil først starte med det indre design som er den kode der skal drive programmet. 3.3.1 Indre Design: For at se på hvordan koden skal virke har jeg lavet et flow chart som kan ses til højre. Programmet starter ved start. Herefter spørges til om man vil have en avanceret eller simpel model. Den simple model indlæser så nogle data fra programmet hvor den avancerede version spørge til indput fra brugeren. Herefter sættes data fra enten den simple eller den avancerede model. Man skal så udregne kraften fra disse data. Her efter rykkes objekterne til deres nye position. Nu tester man at knapperne ikke er blevet trykket ned i mellem tiden, hvis de er rykkes syns punktet, hvis ikke fortættes loopet. Nu testet om knappen sluk er blevet brugt og hvis den er lukker programmet. Ellers går loopet tilbage til det sted hvor kræfterne udregnes.

3.4 Prototype 1: Først prototype af programmet viser udregninger af afstands vektoren mellem planeterne vist i shellen. I det grafiske output fra VPython ses 2 objekter som repræsentere planet 1 og planet2 som er de først 2 objekter der bliver arbejdet med. Denne udgave er lavet med fokus på at lave objekterne i rummet og udregning af kræfterne bag ved. Denne udgave printer afstanden mellem de 2 planeter. 3.5 Prototype 2: Den anden prototype fokusere på flere udregninger af størrelser mellem objekterne samtidig er der blevet defineret nogle konstanter. Så som G

3.6 Prototybe 3 Den 3. prototype er en model hvor det ene objekt bevæger sig i forhold til det andet fokus ligger stadig i at få den fysiske del til at passe så modellen passer. Den hvide kugle bevæger sig i denne udgave i elliptiske baner. I forhold til de foregående prototyper er udregningerne der regner afstanden i stedet for afstands formlen fra matematik bruger funktionen magnitude (mag) som giver en størrelse ud fra størrelsen af 2 vektorer. Derudover brugers der også en retnings vektor som er de 2 normal vektorer trukket fra hinanden dette gøre i stedet for at bruge en vektor og dele med størrelsen. Herudover er der indbygget en differantial ligning hvad man lægger den samlede acceleration til farten for at få en ny fart vektor. 3.7 Prototype 4: Den 4 prototype begynder at nærme sig et punkt hvor man kan tale om en egentlig UI og hvor designet. Begynder at kunne blive bearbejdet. De 2 objekter efterlader nu en curve som er små spheres der efterlades på de koordinater der passeres. Disse koordinater gemmes i et bibliotek. Man kan så rette på disse punkter senere. I denne udgave er objekt blevet rettet så denne også bevæger sig.

3.8 Prototype 5: Den 5. prototype tilføjer et nyt objekt dette betyder at alle udregninger skal gentages 2 gange mere. 3.9 Prototype 6: Den 6. prototype arbejder med et af de generelle krav. Her ændres rate hvilket er antallet af udregninger per sekund til en lav værdi. For at gøre op for dette tilføjes en faktor der bliver kaldt speed, speed bliver ganget med bevægelseslængden per sekund. Man får så nogle hop der gør at modellen ikke er så præcis dog gør det at antallet af udregninger der skal bruges på en bevægelse bliver 1 speed af de normale udregninger. Dette er i overensstemmelse med det generelle krav.

3.10 Prototype 7: Den 7. prototype er her hvor der sker udvikling i forhold til brugerfladen. I denne prototype kan man selv vælge om det skal være en avanceret eller simpel model. den avancerede model starter et tricker et if statement som beder om 9 inputs. Herudover er der en ændring i de trails som objekterne efterlader idet de nu alle er dele af et if loop der gør at længden maksimalt bliver 300 units. Dette er gjort for at minimere udregningerne der skal til når kameraet bevæger sig. Sidst men ikke mindst er der lavet et nyt vindue som indeholder knapper der ændre synsvinklen. Dette gøres ved at når der kommer en ændring på en knap ændres den variabel der hedder forward som er den retning kameraet ser i. 3.11 Endelig version: Den endelige version (som kun er endelig fordi der ikke er mere tid(se iteration)) er en udvikling af prototype 7, hvor værdierne fra vores solsystem er indsat så de 3 objekter der beregnes på er solen,jorden og månen. Herudover er der lavet 4 ekstra knapper som fokusere på en af de 3 objekter og følger dette objekt samt en quit knap. 4.Test 4.1test metode: For at teste programmet har jeg ladet mine medstuderende gennemgå en tænkehøjt test. De fik til opgave at producere en model. 4.2 test resultat: Som resultat fik programmet en smule kritik af at der mangler kontekst og at radius af objekterne skal kunne ændres.

5. Evt. forbedringer: Af forbedringer til dette projekt kan man evt. lave en funktion der ændre radius af objekterne i forhold til afstanden og zoom længde. Man kan også lave en styring så man selv kan vælge antallet af objekter og sidst men ikke mindst kan man lave flere objekter. 6. Konklusion: Jeg har arbejdet med at visualisere effekten af gravitation. For at gøre dette har jeg anvendt visual python til at udregne disse funktioner. Jeg har indsamlet user stories til at forbedre det grafiske bruger interface. Som test hat jeg ladet mine medstuderende teste gennem en tænke højt test. Det endelige resultat er et program der kan indstilles til 2 kontrol niveauer. Som viser 3 objekter i et 3D rum, disse objekter bevæger sig i forhold til hinanden pga. deres indbyrdes tyndekraft og den hastighed de starter med. Programmet overholder både de generelle krav samt de brugeropstillede krav.

7. Kommenteret kildekode(billag): Den første del af koden importere de funktioner jeg skal bruge. Visual importere alt i mappen visual og giver så mulighed for at lave de visuelle dele. Visual.controls giver mulighed for at lave knapper. Den næste del er en masse definitioner på variable i programmet. Dette indeholder også kontrollen af de 2 vinduer. Dele window 2 er det sted hvor vindue 2 bliver valgt og passet til. Herefter laves 9 knapper som gives en position,text og 2 dimensioner.

Denne del definere en variable planet som en global variabel for at den kan bruges mellem de 2 vinduer. Herefter kommer en masse definitioner som tester om man trykker på knappen samt ændre retningen af kameraet. De nederste 3 spørgsmål rette på den globale variabel planet som inde i while loopet gør at kameraet følger den valgte planet. Denne del af koden printer noget tekst i shellen som samt giver variablen simpel en værdi. Der bedes så om et indput for en avanceret eller simpel udgave. Hvis man vælger den avancerede version opfylder man if statementet og der stilles krav til nogle bruger indput. Efter dette sættes simpel til 0

Denne del er kerne i programmet og er det sted hvor programmet flytter objekterne. Og udregner alle værdier der skal bruges i modellen.

i denne sidste del af koden laves sporet efter hver af planeterne. Da et spor består af mange koordinater som alle skal opdateres når kameraet flyttes sørger jeg for at holde antallet af disse nede. Dette gør jeg ved at tælle antallet af koordinaterne i den array der hedder trail. Hvis der er mere en henholdsvis 900 eller 300 punkter i de 3 arrays finder funktionen de sidste 900 eller 300 punkter og printer dem. Nu skal man bruge den globale funktion planet som man bruger i en if/elseif funktion denne tester størrelsen af planet og rykker centeret af scene 1 til det rigtige sted.