Bachelorprojekt. EQATEC Analytics Plugin. efterår 2009 jan 2010

Størrelse: px
Starte visningen fra side:

Download "Bachelorprojekt. EQATEC Analytics Plugin. efterår 2009 jan 2010"

Transkript

1 Bachelorprojekt efterår 2009 jan 2010 Rapport nr.: IMM-B.Eng DTU-vejleder: Bjarne Poulsen Virksomheds-vejleder: Richard Flamsholt Aflevering: Mandag den 11/ kl. 9:00 Studie nr, Efternavn, Fornavne Underskrift S Svendsen, Rasmus Hvidtfeldt Denne rapport indeholder 73 sider incl. denne side. Side 1 af 73

2 Indledning Denne rapport afspejler bachelorprojektet for undertegnede som diplomingeniør på DTU årgang 2010 forår. Projektet strækker sig over perioden d. 31/ til d. 11/1 2010, men overvejelser samt ide beslutning for projektet eksistens er truffet før perioden. Projektet er lavet i samarbejde med konsulentvirksomheden Linkage, hvor projektet gerne skulle være med til at give flere kunder til EQATEC Analytics servicen. I rapporten vil der være en detaljeret analyse samt en fyldestgørende beskrivelse af designfasen i projektet. Der vil blive redegjort for, hvilke teknologier der er brugt for at implementere løsningen til virksomheden. Målet med denne rapport er både at gøre brugeren i stand til at vedligeholde og videreudvikle systemet (Linkage), samt give en forståelse for hvilke overvejelser, der er truffet igennem analyse, design samt implementerings faserne. Rapporten indeholder tekniske termer og forkortelser. En oversigt over de mere specifikke termer og forkortelser findes i appendiks. For at læseren får den fulde forståelse af rapporten, er et vis kendskab til programmering en forudsætning. En person som har taget diplom-it på DTU vil have forudsætningen. God læsning Rasmus Svendsen DTU S Side 2 af 73

3 Indholdsfortegnelse 1. Introduktion Om virksomheden Linkage A/S Motivation Vision Problemformulering Krav til produktet Rapportoversigt Analyse Risikoanalyse EQATEC Analytics Monitor-modulet Usecase Usecase beskrivelser Aktør beskrivelser WPF eller Winforms Program arkitektur GUI MVC Model View Controller MVP Model View Presenter Supervising Controller og Passive view Design patterns Applikations lag NET Framework arkitektur Kompilere til CIL Cecil CIL assembly PDB filen Delkonklusion Design Plugin eller standalone applikation Overordnede plan Mockups Simpel Entitetsdiagram Sidestruktur Datastruktur Objekt serialisering Side 3 af 73

4 3.6.1 Save og load Settings objekt Brugervenlighed Standardløsninger PDF filen Filter Hjælp ved forkert brug Udvidelser til brugervenlighed Delkonklusion Implementering Projekt strukturen Exception PDB-filen Injekte Monitor-Modulet Track udvælges Konfigureringsdelen af programmet Delkonklusion Test nunit test Konfigurerings Test Settings test Injektion test Blackbox test Aktivere Analytics Plugin Opsætning af Analytics Plugin Analytics Plugin tilføjer kode Brugerflade test Delkonklusion Konklusion Virksomhedens udtale Appendiks Termer og forkortelser Klassediagrammer Korte usecase beskrivelser Skærmdump Kildekode Side 4 af 73

5 1. Introduktion Formålet med kapitel 1 er at give en introduktion til, hvad der ligger til grund for projektet, hvad der er projektets formål og hvad visionen er. I kapitlet vil problemstillingerne blive beskrevet, som projektet i sidste ende gerne skulle løse. Til sidst i kapitlet vil der være en oversigt over, hvad resten af rapporten kommer til at omhandle. Først en beskrivelse af virksomheden Linkage A/S, som dette projekt er laves i samarbejde med. 1.1 Om virksomheden Linkage A/S Linkage er en softwareudviklingsvirksomhed, som udover at lave programmer til pc/server platform, også har specialiseret sig i at udvikle software til embedded systemer, såsom Windows CE og Windows Mobile. Kunder, som virksomheden Linkage A/S har udviklet software for, rummer både store og små navne, der kan blandt andet nævnes 1 : Siemens Wind Power Ametek Radiometer Medical Danfoss Thrane & Thrane Greenwood Engineering B&O Dette projekt er udviklet i samarbejde med virksomheden Linkage A/S. Virksomheden ejer også navnet EQATEC som bruges til egenudviklings løsninger rettet mod hele verden, hvorimod konsulentvirksomheden Linkage mere er knyttet til det danske marked. Da projektet er egenudviklet og bliver distribueret internationalt kommer projektet til at gå under navnet EQATEC. Projektet bliver ikke det første der kommer til at gå under navnet EQATEC. Der findes en række produkter/programmer, som er blevet distribueret ud til brugere verden over, der kan blandt andet nævnes EQATEC Tracer og EQATEC Profiler. Det sidst nævnte program er blevet downloadet mere end gange. EQATEC Profiler er det eneste profiler program, som kan profile.net Compact Fremework. EQATEC Analytics, som bachelorprojektet skal være et plugin til, er allerede et etableret produkt. Sideløbende med at rapporten bliver skrevet er der andre udviklere, som arbejder på at forbedre og tilføje nye funktioner til EQATEC Analytics. 1 Linkage s hjemmesiden: %20SW%20konsulentydelser%20%28high%20res%29.pdf Side 5 af 73

6 1.2 Motivation Under mit praktikforløb var jeg med til at udvikle et service kaldet EQATEC Analytics. EQATEC Analytics er et projekt, som går ud på at lave en service til applikationsudviklerne, på samme måde som Google Analytics er en service til webudviklere. Det adresserer det problem, at man som applikationsudviklerne ikke ved, hvor mange brugere, der anvender ens programmer, samt adfærdsbrugen af programmerne. Figur 1. Illustration af EQATEC Analytics funktionalitet 2 Systemet fungerer på den måde, at man skal oprette en konto på analytics.eqatec.com, hvorefter man kan logge ind og se statistikker samt en oversigt over, hvor ofte ens programmer bliver anvendt. For at disse programmer kan indmelde statistikinformationer til EQATEC Analytics serveren, skal man tilføje et Monitormodul (DLL fil) i de enkeltes programmers kode. Monitor-modulet kan downloades fra kontoen på analytics.eqatec.com. Monitor-modulet sørger for at statistikinformationerne kommer fra programmet til serveren, og at intet går tabt. Oversigt over EQATEC Analytics servicen: 1. Udvikleren tilføjer det udleverede Monitor-modul i koden. 2. Programmer hvor Monitor-modulet er tilføjet, sender statistikinformationer via Internettet til EQATEC Analytics serveren, som lagrer alle data. Monitor-modulet modtager informationer om ny releases. 3. Udvikleren og marketingschefen kan på hjemmesiden analytics.eqatec.com se statistikker over deres programmer. Datagrundlaget til statistikker og grafer hentes fra EQATEC Analytics serveren. 2 Figur fra analytics.eqatec.com Side 6 af 73

7 1.3 Vision Visionen for er at give brugerne af EQATEC Analytics et værktøj til at opsætte og konfigurere deres eget program således, at der indsendes så brugbare informationer som overhovedet muligt. Hvis disse informationer ikke bliver sendt rigtig ind, kan der ikke laves meningsfyldte grafer og andre statistikker. Fordelen ved værktøjet er også, at vi er sikre på at brugerne får implementeret Monitormodulet rigtigt. En forkert opsætning af Monitor-modulet vil i værste tilfælde medføre, at ingen data bliver sendt til Analytics serveren. Hvis en bruger af EQATEC Analytics ikke inden for kort tid kan opsætte Monitor-modulet og få sendt data til Analytics serveren, så er der stor sandsynlighed for, at han vælger et andet produkt end EQATEC Analytics. Det er derfor et mål med projektet at lave et værktøj, som kan opsætte og konfigurere deres program på en guidende måde, så brugeren hele tiden føler, at det er nemt at bruge og at de er på den rigtige vej. Det skal ikke bare være en guideliner, men også gøre det nemmere for udviklerne at se et overordnet billede af, hvilke metoder og exceptionshandlere der bliver sporet. Et andet mål med projektet er at gøre folk glade for brugen af EQATEC Analytics, så de ikke dropper tanken om at implementere statistik i deres applikation, da det bliver for besværligt. Fortalt på en anden måde handler det om at få brugerne af EQATEC Analytics til at bruge programmet igen og igen. Det er vigtigt at det endelige produkt ikke kun bliver godt for dem, der ønsker at teste EQATEC Analytics her og nu, men også at produktet kan bruges på længere sigt af udviklerne. Programmet skal derfor designes sådan, at man ikke gør det for besværligt at prøve det her og nu, men det må heller ikke blive en gene i dagligdagen for udviklerne efter de har testet EQATEC Analytics af. Det er ikke tidskrævende eller svært at tilføje en reference til EQATEC Analytics monitor inde i fx udviklingsmiljøet Visual Studio og derefter instantiere den, men det er derimod konfigurationen af monitoren som tager tid. Med EQATEC Analytics har brugeren fx mulighed for at lave statistikker over de metoder, man selv ønsker, hvilket gør at man kan lave sine egne statistikker. Brugeren har også mulighed for at indsende exceptions forskellige steder i eget program, men igen er der noget, man skal konfigurere. Det er målet at lave et program som automatiserer dette. Det skal altså læse udviklerens exe filer og dll er, ved af lave refleksion på de kompilerede filer. Derefter kan man tage og tilføje mere kode til deres program, så det får Monitor-modulet implementeret. skal ikke kun give brugerne mulighed for at tilføje kode til deres program, så de slipper for at kode det selv. Det er også målet, at programmet skal give brugerne nogle muligheder for at lave nogle gode statistikrapporter, ved at indsende relevante data. Derudover skal programmet have en vis intelligens, således at det selv kan finde fx alle menupunkter, så man kan få en graf over hvilke menupunkter, der bliver brugt mest, uden at man som bruger af selv skal lave det manuelle arbejde. Analytics Plugin skal altså foreslå forskellige sporings punkter, som en standardbruger vil have glæde af. Side 7 af 73

8 1.4 Problemformulering Idet brugeren selv skal implementere Monitor-modulet, kan der være nogle, der fravælger brugen af EQATEC Analytics. Dette kan skyldes, at de ikke selv er i stand til at programmere, fx marketingschefen, eller at de bare har lyst til at afprøve det hurtigt uden at kode. Det store problem, som dette produkt gerne skulle løse, er at gøre det nemmere og mere overskueligt at implementere EQATEC Analytics monitor i brugerens program. Det er ikke fordi det tager lang tid som udvikler at tilføje en Reference til en DLL fil (Monitor-modulet), og instantiere den. Men det der er tidskrævende er at konfigurere Monitor-modulet til eget program. Monitor-modulet kan fx sende informationer om exceptions ind til serveren. Som udvikler kan det være rigtig brugbart at se, hvilke fejl brugeren får i programmet. Men det giver ikke mening at sende informationer ind ved alle exceptions, der sker i programmet. Hvis man fx har implementeret en hjemmebygget TryParse(), hvor man tager højde for at en exception kan smides, ønsker man ikke at den logges. Eller hvis man bruger en WebClient som kan smide en WebException, hvis der ikke er forbindelse til internettet (netværksstikket kan være taget ud). Disse typer exception er ikke brugbare for de fleste udviklere, og vil bare give udvikleren en masse arbejde at skulle tage stilling til. Men alle de steder i koden, hvor det giver mening at spore exception, skal man kalde Monitor-modulets metode TraceException(Exception exc). Derfor skal man tænke sig godt om, når man skal konfigurere Monitor-modulet, hvilke steder der kan ske fejl og om det er interessant at få fejlene indrapporteret. Denne problemstilling skal håndteres i projektet. Figur 2. Øverst del viser formålet med projektet (med få klik er Monitor-modulet implementeret). Nederst del viser hvordan det er nu (man skal selv skrive koden for at kalde Monitor-modulet alle steder i programmet). Det kan blive et stort problem at brugerne af EQATEC Analytics ikke vil anvende det, hvis de synes det er for svært at implementere i deres egne programmer. En anden problemfaktor kan være, at brugerne kan komme til at lave fejl i implementeringen eller konfigureringen af Monitor-modulet. Hvis det sker tænker brugerne af EQATEC Analytics er uanvendeligt, da det ikke virker eller bare er for svært at bruge. Nogle brugere ville måske også synes, det tager for lang tid at konfigurere Monitor-modulet, og derfor aldrig giver det en chance. Side 8 af 73

9 1.4.1 Krav til produktet Nedenfor er listet en række krav i punktform til det endelige produkt. Herunder kravet fra virksomhedens side: 1. Programmet skal have et GUI interface, for at gøre det nemmere for brugerne. 2. Brugeren skal præsenteres for et overskueligt interface. o Mulighed for at søge efter metodenavn. 3. Programmet skal opbygges så der er mulighed for senere at køre programmet fra kommandolinjen. Fx ved autobuild. o Mulighed for at skifte frontend delen. 4. Efter injektion skal programmets signatur være det samme som inden injektion. 5. Efter injektion skal programmet have samme assembly informationer såsom Version, Titel, Company, Guid m.m. 6. Hvis noget går galt i injektningen af programmet skal det logges og sendes til virksomheden. 7. Hvis noget går galt skal fejlbeskeder vises til brugeren. 8. Programmet skal gemme opsætningen. o Formatet skal være af XML, så det er nemt for brugerne selv at læse og rette opsætningen. 9. Programmet skal implementere Monitor-modulet i alle dll filer, som er knyttet til projektet, dog ikke system dll er. Underkrav til programmet: 1. Brugeren skal kunne vælge nogle intelligente opsætningsmuligheder, som letter dele af konfigurationsarbejdet for brugeren o Track exception o Track alle knapper o Track alle menu-items 2. Brugeren skal selv kunne vælge hvilke metoder, der skal spores. 3. Brugeren skal selv kunne vælge hvilke exceptionhandlere, der skal spores. 4. Brugeren skal kunne vælge at tracke UnhandledException i deres program. 5. Brugeren skal have mulighed for at vælge, om der skal komme en pop-up meddelelse, når der er kommet en ny version af deres program. Evt. flere forskellige pop-up vinduer at vælge imellem. Herunder hardware og software krav: 1. Programmet skal udvikles i.net Framework Programmet skal være et Plug-in til Visual Studio Programmet skal kunne installeres ved en MSI installer. Performance: Der er ikke specificeret noget performanskrav, det betyder dog ikke, at man kan tillade sig at skrive en dårlig kode, som resulterer i et langsomt program. Kode skal være fornuftig og kunne eksekveres på en fornuftig tid. Side 9 af 73

10 1.5 Rapportoversigt Rapporten er delt op i nogle overordnede afsnit, Introduktion, Analyse, Design, Implementering, Test og Konklusion. En kort gennemgang af hvad resten af rapporten indeholder, ses her: Analyse: Analyseafsnittet kommer til at beskæftige sig med hvilke teknologier, der kan bruges til at udforme produktet. Der vil være en beskrivelse af, hvad Design Patterns er, hvad forskellen mellem WPF og Winforms er, og fordele og ulemper ved Visual Studio plugin. Der vil også blive beskrevet hvilke teknologier, som vil blive brugt i produktet. Afsnittet vil også forklare hvad.net Frameworket er, samt de forskellige lag fra højniveau kode til lavniveau kode. Der vil blive gjort særligt meget ved de punkter, som har en høj relation til produktet, blandt dem er det fælles instruktionssprog CIL. Analyseafsnittet vil desuden indeholde informationer om de mest anvendte arkitektur opdelinger af applikationer, samt om det bliver MVC, MVP eller en anden arkitektur opdeling som vælges i produktet. Af andre punkter i afsnittet kan nævnes risikoanalyse, system usecase, hvad Mono Cecil er og andre mindre afsnit. Design: Designafsnittet bygger på viden fra analyseafsnittet. Her er beskrevet hvordan mockups har udformet sig fra første design ide til det endelige design. Der er også en beskrivelse af designets sammenhæng (hvordan sidestrukturen samt datastrukturen er tiltænkt), og diagrammer som understøttelse. Der er afsnit om, hvordan man kan give brugerne en bedre oplevelse, fx ved at foreslå forskellige standard sporingsmuligheder og hvordan man kan gøre det nemmere at bruge produktet. Designafsnittet indeholder en beskrivelse af, hvordan man skal kalde EQATEC Monitor-modulet, når man ønsker at injekte kode. Implementering: I implementeringsafsnittet af rapporten er der lagt vægt på det tekniske ved implementeringen af produktet. Der er et afsnit om, hvordan produktet injekter nye instruktioner ind i det eksisterende program, og om hvordan det er teknisk muligt at læse exceptionhandlere m.m. fra et allerede kompileret program. Endvidere er der en beskrivelse af, hvordan man ved hjælp af PDB filen kan vise dele af brugerens kildekode. Der vil også være en teknisk beskrivelse af brugen af bindings samt hvordan knapper, menu-items bliver fundet i brugerens assembly. Afsnittet går i dybden med implementeringen af og hvordan man kan bruge Mono Cecil til at injekte kode i et allerede kompileret program. Side 10 af 73

11 Test: I testafsnittet er der en gennemgang af hvilke test, der er udført og af testresultaterne. Der er også en beskrivelse af, hvordan der er lavet test og hvilke typer test der er gennemført. Endvidere er der en beskrivelse af, hvordan brugergrænsefladen er blevet testet og resultaterne af testen. Konklusion: Konklusionsafsnittet er det sidste afsnit udover appendiks og der beskriver jeg, hvordan projektet er afsluttet og hvad projektet har gjort for virksomheden og ikke mindst for mig. Under konklusionsafsnittet findes der også virksomhedens udtale om projektet. Fremtiden for projektet vil også være beskrevet under konklusionen. Side 11 af 73

12 2. Analyse Analyseafsnittet kommer til at beskæftige sig med hvilke teknologier, der kan bruges til at udforme det færdige produkt. Der vil blandt andet være afsnit om de forskellige arkitektur-patters og design patters. Analyseafsnittet skal også gøre det klart, hvordan systemet skal spille samme med det allerede udviklede Monitor-modul, endvidere skal afsnittet give en forståelse af det færdige produkt. 2.1 Risikoanalyse Når man skal i gang med et projekt, af denne størrelse og som strækker sig over længere tid, er det en god ide at lave en risikoanalyse. I en risikoanalyse lister man de punkter, som kan gå galt eller ændre den oprindelige plan for projektet. En risikoanalyse er med til at skabe overblik over, hvad der kan ske med projektet ved forskellige hændelser, og man bliver derfor mere opmærksom, når en hændelse er ved at indtræffe. Herunder listes de mest tænkelige hændelser, hvad det kommer til at betyde for projektet, samt hvad man skal gøre for at komme videre i processen. De første hændelser er der størst sandsynlighed for sker: Teknologiske udfordringer Når man laver et projekt kan man aldrig vide hvilke udfordringer der vil vente en. Der er derfor en fordel, at tage højde for forskellige afvigelser allerede i opstartsfasen. Det kan alligevel ske, at man løber ind i problemer, som kræver længere tid at løse end den estimerede tid. De tekniske problemer kan være lige fra et Framework element funktionelle opsætning til styling af elementer. Det kan også være, at det injektet IL kode ikke fungerer som først antaget. De fleste af disse udfordringer løses ved at arbejde mere intens eller ved overarbejde. Der kan dog komme nogle teknologiske problemer, som gør at det bliver nødvendigt at vurdere vigtigheden af funktionaliteten af det tekniske problem, og derefter tager stilling til, om man ønsker at bruge tiden på problemet. Ellers må problemet nednoteres så man senere kan vende tilbage til det, hvis der opstå mere tid, eller de kan implementeres i en senere version. Fejl-implementeringer Når man laver softwareprojekter kan der opstå fejl-implementeringer i koden. Man kan simpelthen komme til at over-engineere projektet, så man har brugt en masse tid på at lave det så smart, men efter noget tid opdager man, at det kan gøres simplere og mere effektivt på en anden måde. Derfor skal fejl-implementeringen rettes til, så det endelige projekt bliver så godt som muligt. Man kan også lave en fejl-implementering, idet man har testet en mindre del af projektet og tror det virker, men i den samlede helhed virker det ikke. Det er en fejl, som skal rettes med det samme, men det kan tage tid at rette den slags fejl. De fleste fejl-implementeringer løses ved et større tidsforbrug og retligt omhu. Side 12 af 73

13 Projekt ændringer Der opstår ofte ændringer i et projekt undervejs. Dette skyldes hovedsagligt, at der ikke har været enighed om projektets funktionalitet fra starten af. Nye funktionelle funktioner kommer oftest når man sidder og snakker eller viser projektet frem til midtvejsmøder. Det er derfor vigtigt, at der holdes en del møder i starten af projektforløbet for at kunne inddrage projektforbedringer så tidligt som muligt. Jo før jo bedre, da en ændring sent i forløbet kan koste dyrt, hvis den ikke passer ind i den tænkte arkitektur. Når der opstår projektændringer skal disse estimeres så godt som muligt ud fra projektets status, hvis der ikke kan findes tid til ændringen må der prioriteres mellem de resterende opgaver. Projektafgræsning Da dette projekt bliver udviklet til en etableret virksomhed, er det vigtigt, at projektet bliver færdigt til det aftalte tidspunkt. Viser det sig, at projektet er mere tidskrævende end først antaget, bliver man nødt til at tage et møde for at klarlægge, hvilke dele af projektet, der færdiggøres først, og hvilke dele som kan undlades i første version. Det kan i værste tilfælde blive nødvendigt at sætte flere udviklere på projektet. Det er vigtigt med en tidlig orientering, hvis projektafgrænsningen ikke holder. Dette ville blive beskrevet tydeligt hvis det sker. Sygdom Sygdom kan altid komme i vejen for projektets tidsplan. Hvis det er en kort sygdomsperiode, kan det indhentes ved at lave overarbejde de efterfølgende dage. Hvis det er en længere periode eller i slutningen af projektet kan det blive nødvendigt at skære ned i projektets omfang, for at blive færdig med projektet til tiden. Data tab Som udvikler er man altid sårbar over for tab af sine data. Der kan være mange årsager til, at man mister sine data, fx ved systemfejl, uheldig overskrivning af filer, computernedbrud m.m. Der er ikke så meget man kan gøre, når først dataene er tabt, det handler derfor om at sikre at det ikke sker. For at sikre mod data tab bruger jeg et versionsstyringssystem, der sender data til en server ude på Internettet. Hvis jeg mister data på en computer kan jeg altid hente det ned fra serveren igen. Hvis serveren ude på Internettet mister mine data (ved brand m.m.), har jeg arbejdes versionen på min computer. Data tab bør derfor være meget begrænset eller helt uundgåeligt. Side 13 af 73

14 2.2 EQATEC Analytics Som tidligere beskrevet er EQATEC Analytics allerede en kørende forretning og dette projekt går ud på at gøre det nemmere at integrere og opsætte Monitor-modulet. Monitor-modulet er færdig implementeret, dog kommer der nye funktioner til, hvis modulet ikke er stærkt nok. For at applikationen automatisk skal kunne integrere og opsætte Monitor-modulet i brugerens programmer, skal applikationen vide, hvad brugeren ønsker at lave statistik over. Derfor går den ene del af applikationen ud på at gøre det muligt på en nem og overskuelig måde at konfigurere og opsætte hvordan der skal laves statistik i ens eget program. Den anden del af applikationen skal ændre brugerens program, så det er muligt at lave statistik over det, som er konfigureret i den første del af applikationen. Det næste afsnit handler om, hvad Monitor-modulet kan. Uden en forståelse af hvad Monitor-modulet kan, kan man ikke lave den endelige applikation Monitor-modulet Monitor-modulet er en dll fil som indeholder funktionaliteten til at sende og holde styr på en række statistik informationer. Modulet trækker selv en del statistik informationer ud fra operativsystemet, Frameworket m.m., men det har også brug for at blive fodret med brugeres statistikdata. Det kan ikke kun holde informationerne, det gemmer også regelmæssigt nogle af informationerne på disken, så man ikke mister sine data ved strømafbrydelse, crash m.m.. Modulet søger også for at sende informationerne til EQATEC Analytics serveren, så udviklerne og andre kan følge statistikken. For at udviklerne kan være med til at pære hvad der skal laves statistik over, er der udviklet et interface til Monitor-modulet. Figur 3. Eksempel på statistik data, Monitor-modulet har udtrukket. Hvilke funktioner er der i Monitor-modulet. Monitor-modulets interfaces funktioner er beskrevet her: Funktion Start / Stop funktioner Track Exception Beskrivelse Ved kald af Startfunktionen bliver Monitoren instantieret, og der oprettes en ny session, så man kan måle hvor længe programmet har været i brug, samt hvornår fx en exception skete i programmet. Ved Startfunktionen bliver der sendt en masse andre informationer til serveren, nogle af disse informationer er om operativsystemet, hvilken Framework version der er installeret, sprog, hvilken version af programmet der køres m.m. Stopfunktionen lukker sessionen, og frigiver resurser, som Monitoren har optaget. Efter kald af stop kan man ikke kalde nogle af de andre metoder før man har kaldet start igen. Ved kald af TrackException metoden, som tager en exception som parameter, Side 14 af 73

15 prøver Monitoren at sende exceptionen til serveren med det samme, hvis det ikke lykkes gemmer den exceptionen til næste gang, der skal sendes informationer til serveren. Track Feature TrackFeatureStart / TrackFeatureStop Send Log Ved at kalde metoden TrackFeature, der tage en string som parameter, kan man lave sine egne statistikker. Feature tracking er struktureret hieratisk ved brug af punktum notation. Hvis man fx ønsker at tracke hvor mange der eksporterer til HTML eller PDF, kan man kalde TrackFeature med strengen Export.HTML for alle der kalder html eksporten og Export.PDF for dem som kalder pdf eksporten. På statistik hjemmesiden bliver disse to nu sat i en selvstændig graf med overskriften Export og en linje for hver. TrackFeature bliver ikke indrapporteret ved hvert kald, men samles og kommer med når en Exception, SendLog eller en Start/Stop bliver sendt. Ved at kalde TrackFeatureStart, starter man en tæller i baggrunden, så man kan spore hvor lang tid en metode er om at blive afviklet m.m. Når man kalder TrackFeatureStop stopper tælleren og resultatet bliver gemt, så det kan indrapporteres på samme måde så ved et normalt TrackFeature kald. Kaldet SendLog tager en tekst meddelelse som parameter og sender den til serveren. Monitor-modulet melder selv ind, hvis der er forbindelse til serveren; hvis det ikke lykkes, så gemmer den informationerne. Næste gang der sendes data bliver de informationer, som ikke er sendt påhæftet, og på den måde kommer alle informationer frem til EQATEC Analytics serveren. I projektet gøres der brug af Monitor-modulet til at sende statistik til serveren. 2.3 Usecase Systemet består af 2 mindre systemer. Den ene halvdel af systemet går ud på at man kan opsætte og konfigurere, hvordan Monitor-modulet skal integreres i eget program. Den anden halvdel af systemet er der hvor Monitor-modulet bliver tilføjet til brugerens program samt ændrer brugerens eksisterende kode til at kalde Monitor-modulet, alt efter hvad der er konfigureret i den første del af systemet. De to dele af systemet er indikerede ved at trække en vandret linje igennem usecase diagrammet. (Se figur 4). De to aktører (menneskerne på tegningen) styrer hver deres del af systemet Usecase beskrivelser Som det ses af figur 4 er der en del usecase i systemet. Alle usecases i systemet er der lavet usecase beskrivelser over. Der er udvalgt 2 usecase, som er beskrevet nedenfor, resten af de korte usecasebeskrivelser kan ses i bilag 7.3. Side 15 af 73

16 Opret Feature track: Aktør: Analytics bruger (AB) Præ-kondition: Visual Studio indeholder et kompileret program Post-kondition: Feature track er oprettet. Scenariet: 1. System finder mulige feature track i programmet 2. AB finder ønskede feature track 3. AB aktiverer feature track 4. AB angiver et track navn Opret Exception track: Aktør: Analytics bruger (AB) Præ-kondition: Visual Studio indeholder et kompileret program Post-kondition: Exception track er oprettet. Scenariet: 1. System finder mulige exception track i programmet 2. AB finder exception track 3. AB aktiverer exception track Aktør beskrivelser Der er fundet nedenstående aktører i systemet. På figur 4 er der indtegnet de tre aktører. Aktørerne vil blive gennemgået, for at give overblik over, hvem der kommer til at gøre hvad i systemet. Analytics bruger GUI Kan bruge systemet til at styre konfigureringen af Analytics Plugin. Kan angive produkt nøgle. Kan gemme opsætningen. Kan finde informationer omkring hvilke metoder, der bliver sporet. Kan finde informationer omkring hvilke exception, der bliver sporet. Kan oprette ny metode til sporing. Kan oprette ny exception til sporing. Kan aktivere / deaktivere om versioncheck skal være aktiv. Kan aktivere / deaktivere om Analytics Plugin skal være aktiv. Brugeren kan opsætte systemet så det passer til eget program, herunder vælge hvilke metoder, knapper og menupunkter, der skal spores ved feature sporing. Hvilke exception som skal spores, samt om versioncheck skal være aktiveret. Brugeren kan angive produktnøglen, der fortæller, hvilket produkt det tilhører oppe på serveren. Side 16 af 73

17 Build program Kan hente Opsætningen Kan injekte kode i programmet Denne aktør henter seneste gemte opsætning og på baggrund af det, injekter den kode i brugerens eget program. System Systemet kan selv indsende fejlrapporter. Systemet sender fejlrapporter ind til virksomheden, når der opstår fejl i systemet. Dette skal ikke være synligt for brugerne af programmet. For at give overblik over systemets omfang, er der udarbejdet et system usecase diagram. Se nedenfor: Aktører: Usecase System: Angiv produkt nøgle Analytics bruger GUI Gem opsætning Opret Feature track Opret Exception track Vis Feature track Aktivere versioncheck Vis Exception track Vælg intelligens feature track Vælg intelligens exception track <<extends>> Hent opsætning Injekt kode / Monitor Build program Indsend fejl Automatisk Figur 4. System usecase diagram Side 17 af 73

18 2.4 WPF eller Winforms Når man designer nye applikationer skal man tage stilling til, hvilken teknologi man ønsker at bruge. Skal man bruge WPF eller Winforms? og hvad er deres styrker og svagheder? Det vil blive gennemgået kort i afsnittet. Winforms har mange år på bagen og har stort set været den eneste måde at lave sikre Microsoft.NET applikationer på. Winforms er.net erstatningen for MFC. 3 I modsætning til MFC biblioteket, så er Winforms et helt objekt-orienteret og hierarkisk svar til udvikling af Microsoft applikationer under.net platformen. I.NET Framework 3.0 kom så det nyeste bud fra Microsoft på hvordan man skal lave brugergrænseflader til Windows baserede applikationer, WPF (Windows Presentation Foundation). WPF giver en sammenhængende model for opbygningen af applikationer, og giver en klar adskillelse mellem brugergrænsefladen og forretningslogikken. Sammen med WPF kom også det nye kodesprog XAML, som er en måde at definere UI (brugergrænseflade) elementer, samt hvilke relationer der skal være mellem andre elementer i brugergrænsefladen. WPF kan ikke erstatte Winforms fra den ene dag til den anden, selvom Microsoft har udvalgt WPF til at være fremtidens platform 4. Eksempel på at Microsoft satser stort på WPF er at Visual Studio 2010 er blevet omskrevet til WPF, hvilket nok bliver den største WPF applikation der er udviklet. Omskrivningen bliver også en test om WPF teknologien kan bruges til så store applikationer. Det er ikke alle steder det kan betale sig at gøre brug af WPF. Hvis man i forvejen har et kørende program skrevet i Winforms, skal der være en virkelig god grund til, at man laver det om til et WPF program. Winforms er den mest testede platform, selvom der ikke findes så mange fejl i WPF mere, så er Winforms nu en gang blevet optimeret mere gennem de mange år. WPF er en god platform at bruge, hvis ens applikationer skal gøre brug af forskellige medietyper. For eksempel hvis man skal lave et program, der kan optage video, animerede overgange, billedbehandling eller 3D-indhold. WPF er også rigtig godt, hvis man skal binde sig til en datamodel eller anden dynamisk del, fx fra en webtjeneste. En sidste ting som WPF er god til, er at opdele brugergrænseflade så den kan genbruges samt gøre det muligt at have flere sprogunderstøttelser. Eftersom at WPF blev født sammen med.net Framework 3.0 så er det ikke alle, som kan køre WPF applikationer. Windows 2000 brugere og Windows XP brugere som ikke har SP2 kan ikke installere.net Framework 3.0 og har derfor heller ikke muligheden for at afvikle WPF applikationer. Da dette projekt skal munde ud i et program til udviklere og deres Visula Studio, er det vigtig, at det virker under deres forhold. Hvis man har en ren Visual Studie 2005 installation kan man ikke køre WPF, da den indeholder en.net Framework 2.0. Men det er nok de færreste udviklere som ikke i en eller anden sammenhæng har haft brug for.net Framework 3.0. Ud fra Google Trends kan man se, at der bliver færre 3 Kilde: 4 Kilde: Side 18 af 73

19 Visual Studio 2005 brugere og at det har været faldende efter Visual Studio 2008 frigivelsen 5. Frigivelsen af Visual Studio 2010 vil helt sikkert ændre meget på antallet af Visual Studio 2005 brugere. Da projektet går ud på at lave et opsætningsprogram, vil der være mange properties som skal sættes og læses. Der bliver altså en tæt forbindelse mellem datamodellen og brugergrænsefladen. En så tæt forbindelse kan nemmere løses med WPF end Winforms, da man i WPF kan benytte sig af data bindings. Data bindings er godt, fordi der ikke skal så meget kode til og fordi de kan skrives i XAML. Med data bindings opnår man på en nem og overskuelig måde at ens elementer reagerer efter datamodellen. Fordelene for at bruge WPF er større end ved brugen af Winforms, derfor vil projektet blive implementeret med WPF platformen. 2.5 Program arkitektur Når man skal i gang med at lave applikationer skal man fra starten af tænke over arkitekturen bag applikationen. Det er for dens sags skyld underordnet om det er en lille eller stor applikation. Hvis man ikke har en god arkitektur kan det blive et mareridt at lave ændringer i applikationen senere. Derfor er der med tiden kommet en række forskellige måder man kan designe sin arkitektur på, så den passer til netop den applikation man er ved at udvikle GUI Den grafiske brugergrænseflade (GUI) er det synlige i en applikation. Det har siden de første programmer været ønsket at den grafiske brugergrænseflade ikke må være bundet hårdt op mod domain laget (programmers logik). Den første model, der rigtig frigav GUI en fra domain laget, var MVC (Model-View- Control) modellen, som blev udviklet af firmaet Xerox PARC tilbage i Denne model er grundstenen for, hvordan man i dag 30 år efter laver GUI design. Det kan derfor være svært til tider at skelne mellem de forskellige modeller, da de alle samme bygger på MVC og har en del fælles formål. Formålet med de grafiske brugergrænsefladers modeller er, at holde model og view adskilt så meget som muligt. Når man snakker om GUI modeller svarer model til domain modellen og view er den grafiske præsentation. Nedenfor ses en liste over modellernes fælles formål: Muligt for at arbejde på domain modellen uafhængigt af view et Ændring i view kræver ikke ændring i domain modellen Mulighed for at have flere views på samme tid Gør det muligt at genbruge elementer og kode Mulighed for testning af GUI 5 Denne information bygger på data fra Google Trends som er en måling af hvad brugere har søgt på google. Det kan derfor kun bruges som vejledning. Kilde: o=all&date=all&sort=1 6 Kilde: Wikipedia - Side 19 af 73

20 Det sidste punkt har der ikke været så meget fokus på tidligere, men det er der ved at komme. Fx har Martin Fowler foreslået at afskaffe MVP til fordel for supervising controller og passive View (Dem kommer vi tilbage til senere). Det har han gjort, for at gøre det nemmere at teste GUI en. Men det er ikke nemt at teste GUI og de fleste udviklere synes, det er umuligt, da der ikke findes et værktøj som fx nunit-test. Martin Fowler har derfor konstrueret de to nye modeller. Men det er stadigvæk tæt på det umulige at teste ens brugergrænseflade MVC Model View Controller MVC modellen var den første, hvilket betyder, at de andre modeller bruger MVC en som grundstenen. MVC modellen er meget simpel og består af 3 komponenter. Se figur 5. Model Event View Event Controller Figur 5. Model View Controller Model: Model indeholder alle data for systemet, kaldet domain data, som skal vises i view et. Model indeholder ikke forretningslogik eller kender hverken til view eller controller. Det er en helt separat komponent, som kun kan kommunikere indirekte med view et via events. Modellen ved ikke hvem der lytter på eventene, men ved bare om der er nogle, der er interesseret i at få besked når dataene ændres. Når data ændres sendes et event til dem som lytter. View: View er det grafiske komponent, hvis eneste formål er at vise data fra model på skærmen. Som det ses af figuren kan view et få data fra model ved enten at kende den direkte eller indirekte, som var events drevet. I de fleste tilfælde bruger man det direkte kendskab til model, når man skifter skærmbillede (vindue m.m.), da man bare kan trække data ud fra model. Når først dette er gjort, er det en fordel, i de fleste tilfælde, at lytte til events fra Side 20 af 73

21 model og kun opdatere de ændrede værdier. Der findes dog udviklere, der ikke benytter sig af det direkte kendskab til model og kun får data fra de events som model sender. Controller: Controller er omdrejningspunktet i MVC modellen. Den har en direkte forbindelse til både model og view, og en indirekte forbindelse til view via events. Når brugeren fortager en handling i view, sender view et event til controller. Controller har nu mulighed for at hente informationer direkte fra view, afhængigt af hvad eventet drejer sig om, og skrive data direkte ned i model. Når model s data bliver ændret af controller sender model, som tidligere beskrevet, et event om ændring af data. View et reagerer på event et og dens data ændres igen. Som det kan ses af figuren 5 har modellen intet kendskab til view og controller og kan kun kommunikere via event, når der sker ændringer i dataene, hvilket er en af de centrale dele i MVC modellens opbygning. Det er denne centrale del, som den næste model MVP har valgt at bygge videre på MVP Model View Presenter MVP er et designmønster til hvordan man kan forbedre problemstillingen ved at adskille præsentationslogikken samt gøre det lidt lettere at lave automatiseret test af enhederne. MVP bestå også af et view og en model som MVC gør, MVP indeholder dog ikke en controller, men et komponent kaldet presenter. Model Event View Presenter Figur 6. Model View Presenter Nedenfor er beskrevet hvordan de forskellige komponenter hænger sammen. Side 21 af 73

22 Model: View: Presenter: Model er som i MVC et domain data objekt, og da denne er en god ting fra MVC forbliver den uændret. Model har intet kendskab til view eller presenter og forbliver derved et domain objekt. Model har igen mulighed for at sende events til view, når dens data er ændret. Model indeholder ingen logik, logikken vil ligge i enten presenter eller view. View repræsenterer som sagt tidligere den grafiske brugerflade, præcis som i MVC. Forskellen er at view i MVP har fået et større ansvarsområde, der nu inkluderer controller delen fra MVC modellen. Dvs. at view skal tage sig af brugers handlinger og input. Da viewet nu skal varetage controller delen, har det fået en direkte forbindelse til presenter delen. At controlleren er blevet en del af viewet, er en af det ting, der gør at MVP passer bedre til de moderne programmeringssprog. Viewet vil typisk holde sig opdateret ved at lytte til events fra model. Derfor passer MVP godt til WPF, da WPF er designet til databinding (se afsnittet 2.4 WPF eller Winforms). Når der sker ændringer i viewet, har det mulighed for at foretage opdateringen direkte ned i modellen. Presenter er en ny del i forehold til den gamle MVC model og det er her i presenter at forretningslogikken ligger. Viewet tager sig selv at de små opdateringer, der er mellem viewet og modellen, og presenteren tager sig at de store ændringer (forretningslogikken) som påvirker viewet og dens data (model). Presenter tager sig dog af størstedelen af arbejdet i en applikation, da rå data oftest skal bearbejdes inden de vises i viewet. I moderne programmeringssprog bruger man færdigbyggede moduler såkaldte widgets 7 for at man ikke skal udvikle det hele fra bunden hver gang. Disse widgets er også presenterens opgave at bruge (lytte på event, sætte data m.m.). I en MVP model kan man nemt komme til at lave en hård kobling mellem Presenter og View, da de begge arbejder med brugerfladen. For at lave en blødere kobling kan man tilføje interface mellem dem (på samme måde som beskrevet i Applikations lag afsnittet). Derved er der mulighed for, hvis det er designet godt, at skifte viewet ud uden at lave om i presenterdelen. MVP er en af de moderne måder at løse designproblemer på, men det er stadigvæk ikke nemt at teste den grafiske brugergrænseflade med automatiske test. Derfor findes der to GUI modeller mere, som er blevet introduceret af Martin Fowler, der begge tager udgangspunkt i MVP modellen. 7 Widgets, også kaldet control, er elementer af den grafiske brugerænsefladen som fx et windows, textbox og lignende. Side 22 af 73

23 2.5.4 Supervising Controller og Passive view Det hævdes ofte, at MVP design modellen er blevet pensioneret, da Martin Fowler har opdelt MVP i to modeller 8. MVP modellen er altså delt op i to modeller den ene er Supervising Controller og den anden er Passive view. Hvorfor han har valgt at fjerne MVP helt, kan man undre sig over, for begge modeller er stort set ens med MVP modellen. Den eneste forskel er, hvor stor frihed view har til at kommunikere uden om presenteren, altså benytte sig af den direkte forbindelse til model. Nedenfor ses hvordan de to nye modeller er opbygget. Forskellen mellem dem er illustreret med en pil hvorpå der kan bevæges en bjælke. Bjælken kan placeres et sted imellem presenter og view, jo tættere den placeres på en af de to, des mere logik indeholder den. Model Event View Supervising controller Logik Presenter Passive view Figur 7. Supervising controller og Passive view Passive view: Med passive view skal alt kommunikation og opdateringer af viewet ske igennem presenteren. Dette gør det nemmere at teste, idet at logikken nu udelukket ligger i presenteren. Det giver mulighed for at teste det ved simple unit test. I passive view modellen er views eneste funktion at modtage brugerens input og events, og udbyde en række properties så presenteren kan ændre indholdet i viewet. Ulempen ved modellen er, at det giver en masse ensformig implementering og masser af kode for at synkronisering kan virke for alle widgets. En del af disse synkroniseringer ville nemt kunne klares mellem view og model uden presenterns indblanding. I passive view modellen forsvinder den direkte forbindelse mellem view og model. Supervising controller: Supervising controller er i bund og grund den samme model som MVP, hvor presenter håndterer den krævende forretningslogik og view selv håndterer simpel synkronisering med model. 8 Kilde Martin Fowler: Side 23 af 73

24 Det er helt afhængigt af hvilken applikationstype man er i gang med at udvikle, om man vil benytte passive view eller supervising controller (eller en helt tredje). Hvis man fx bruger WPF kan det være en fordel at bruge supervising controller, da WPF indeholder et stærkt værktøj til at synkronisere properties med modellens properties. Værktøjet er databinding. Men man skal huske på at alle disse modeller kun er designet for at gøre det nemmere og mere overskueligt at designe sine applikationer. Alle applikationer er ikke ens og derfor er det ikke sikkert, at der findes en model som passer perfekt til det man udvikler. Modellerne skal betegnes som modeller og man kan derfor godt lave undtagelser uden at verden bryder sammen, men som udgangspunkt er det en god ide at følge en model. Da produktet vil benytte sig af WPF platformen, er det oplagt at vælge et arkitektur patterns, som passer dertil. Derfor vil det være MVP modellen, som vil være udgangspunkt for applikationen Design patterns Et design pattern, kaldes også for et designmønster, og er ikke et endeligt design, som man kan programmere direkte. Design pattern er en skabelon for hvordan man løser et givent problem i mange forskellige situationer. Design patterns er udviklet til at løse de problemer, som oftest opstår når man udvikler applikationer. Problemerne kan også løses på anden måde, men design patterns gør det nemmere og er tidsbesparende for udvikleren. Design patterns bygger på flere års erfaringer og er udviklet af udviklere efter bedst praksis at løse problemet på. Algoritmer og andre matematiske formler betragtes ikke som design patterns, da de løser et beregningsproblem og ikke et designproblem. Blandt de mere kendte tekniske design patterns kan nævnes Singleton, Observer og Command. De to vigtigste grunde til at bruge design patters, er at man får en renere kode og at man genbruger skrevet kode. Den renere kode skyldes, at man ved brug af design patters oftest ikke skal skrive så meget kode og det giver et bedre overblik for udvikleren. Renere kode er en vigtig ting, når andre udviklere skal læse koden eller for ens egen skyld, det gør det nemmere at forstå kode efter fx 3 måneders pause. En renere kode er mere overskuelig, og da design patterns er kendte designmønstre blandt udviklere, er det en del nemmere at sætte sig ind i koden. Design patterns bør kun bruges hvor man kan se, at det giver mening og at det kan spare dig som udvikler for en masse duplikeret arbejde. Ikke alle applikationer bør bruge design patterns, da design patters godt kan øge kompleksiteten af applikationen. En anden konsekvens ved at bruge design patters er risikoen for at man over-engineering sin applikation ved at misbruge eller overfylde den med designmønstre, som ikke er nødvendige. Side 24 af 73

25 2.5.6 Applikations lag En meget typisk måde at tænke på er, at applikationen skal splittes op i forskellige lag for at den kan genbruges ellers udskiftes. Der findes 2 forskellige modeller, en hvor man deler applikationen op i 2 lag, og en hvor man deler den op i 3 lag. Den første model (2-lags modellen) indeholder lagene applikation og data. Ved at have datalaget udskilt fra applikationen, kan man nemmere skifte datalaget ud. Ved denne model er det ikke nødvendigt at rette så meget kode i applikationslaget, som hvis man skifter datalaget ud. 2-lags modellen bliver ikke brugt mere, da man har problemer med at få forretningslogikken til at passe ind i modellen. I modellen er hele brugergrænsefladen blandet sammen med forretningslogikken, hvilket kobler de to ting hårdt sammen. Man kan ikke lave en ændring i forretningslogikken uden af man skal ændre brugergrænsefladen. Så det er ikke så effektivt. Derfor kom der også en udvidelse af 2-lags modellen, som kom til at hedde 3-lags modellen. 3-lags modellen indeholder lagene præsentation, domain og data. Det først nævnte lag indeholder kun brugergrænsefladens logik (laget kaldes også for UI laget). Det gør det nemmere at skifte brugergrænsefladen ud, på samme måde som det i 2-lags modellen var tilfældet med datalaget. Domainlaget indeholder forretningslogikken og datalaget indeholder dataene. For at gøre det endnu nemmere at skifte de forskellige lag ud, uden at det har indflydelse på de andre lag, kan man tilføje interfaces mellem de forskellige lag. Et interface er en skabelon, som er knyttet til et lag og fortæller hvilke muligheder laget tilbyder. I projektet vil der blive brugt 3-lags modellen og der vil være interface så udskiftning bliver nemmere. 2.6.NET Framework arkitektur Som tidligere beskrevet kan man dele programmet op i to dele. For at for at man kan ændre i brugerens program, skal man vide lidt om hvordan en.net applikation bliver kompileret og hvordan dens arkitektur er opbygget. Microsofts.NET Framework er et softwareprogram, som gør det muligt at afvikle programmer skrevet i forskellige.net-programmeringssprog som fx C# og VB.NET..NET Frameworket er et lag mellem programmerne og selve styresystemet. Det gør det muligt at udvikle programmer, uden at man skal tage højde for hvilken hardware (CPU) programmerne skal udføres på. Man laver ofte sammenligningen mellem Microsofts C# / CLR (Common Language Runtime) og Suns java / JVM (Java Virtual Machine), da de fungerer på samme måde. Begge teknologier bruger virtuel maskine (programmet ikke skal tage højde for hardwaren) og de bruger begge JIT (Just-in-time) kompilering. 9 Ideen bag.net Frameworket er, at Microsoft ønsker, at hver programmør kan bruge sit foretrukne programmeringssprog. Til hvert sprog findes der en kompiler, som oversætter kildekoden til et fælles 9 Wikipedia: & Side 25 af 73

26 kodesprog, kaldes for CIL Common Intermediate Language (tidligere hed det MSIL - Microsoft Intermediate Language). Figur 8. Oversigt over Common Language Infrastructure 10 Oversigt over.net Frameworkes flow: 1. Finder de(n) kompiler som passer til programmeringssproget. 2. Koden bliver oversat med de(n) fundne kompiler. Resultatet af oversættelsen er CIL kode, som er den fælles forståelige kode for alle JIT kompilere (en for hver processer type). 3. Ved udførelsestidspunktet (just-in-time JIT) oversætter en kompiler CIL-koden til native code. 4. Native koden bliver udført af computerens processor. Det interessante er ikke hvordan.net Frameworket finder den rigtige kompiler, eller hvordan Just-in-time oversætter CIL til native code. Det interessante er CIL koden, da det er den, som via injektion skal ændres. Senere i kapitlet er der nogle eksempler på, hvordan højniveau sproget C# kommer til at se ud efter oversættelse til CIL. 10 Figuren er fra Wiki: Side 26 af 73

27 2.6.1 Kompilere til CIL 11 Når man kompiler sin.net kildekode får man et program, som indeholder CIL kode (kaldes.net assemblies), hvilket var det CPU-uafhængige instruktions sæt, der senere kan omdannes til native kode. Assemblies indeholder en række informationer om indlæsningen, lagring, initialisering, og hvilke metoder der bliver kaldt på hvilke objekter, samt instruktioner for aritmetiske og logiske operationer, exception handling, og meget mere. En assembly kan også indeholde to nøgler: en public key, som er en unik hash genereret nøgle der dannes når en assembly bliver kompileret. Det betyder at to assemblies med samme public key vil være identiske fra frameworkeds synspunkt. Den private nøgle (private key) kan angive hvem skaberen af en assembly er. Dette kan bruges til at tilkendegive over for brugerne hvem der er ejeren, hvilket sikrer at ejeren af en assembly er den samme når der fx er en ny version af en assembly. 2.7 Cecil Mono.Cecil er en del af Mono projektet 12 og er et library udviklet af JB Evain til at generere og inspicere programmer og assemblies, som er kompileret til standart formatet CIL. Mono Cecil er open source hvilket giver en fordel, at man kan se hele kildekoden. I Mono Cecils licensbetingelser står der at det frit kan benyttes. Med Cecil kan man indlæse programmer, hvorefter man kan gennemse indholdet af programmet, dens typer, metoder m.m. Man kan lave ændringer i programmet ved at redigere instruktionerne, og man kan gemme ændringerne til et program igen. Mono Cecil modulet er blevet brugt til mange projekter. Fx har virksomheden Linkage brugt libraryet til deres EQATEC Profiler applikation. Linkage er ikke den eneste som gør brug af Mono Cecil, en liste af projekter kan ses her: Alternativ til Cecil Der findes andre programmer/moduler som kan det samme som Mono Cecil. Der kan blandt andet nævnes Microsoft.CCI og PostSharp's. Microsofts CCI (Common Compiler Instrastruture) er relativ ny og efter min mening et meget komplekst værktøj, som kan meget mere end nødvendigt, og derfor virker uoverskueligt. Der findes ikke mange moduler, som er så simple og lige til at gå til, som Mono Cecil. Mono Cecil er objekt orienteret opbygget, hvilket gør det nemt at arbejde med, når man er vant til objekt orienteret programmeringssprog. En anden væsentlig faktor er at Mono Cecil benytter de samme termer, som man gør i selve.net standarden, fx i bogen The Common Language Infrastructure Annotated Standard 13, der er biblen inden for området. I projektet vil der blive brugt Mono Cecil, da det virker som det simpleste og da virksomheden har kendskab til Mono Cecil fra deres EQATEC Profiler program. 11 Bogen: The Common Language Infrastructure Annotated Standard James S. Miller, Susann Ragsdale 12 Mono project: 13 Bogen: The Common Language Infrastructure Annotated Standard James S. Miller, Susann Ragsdale Side 27 af 73

28 2.7.1 CIL assembly CIL kode er lavniveau kode men dog læseligt for mennesker, selvom det er på binær form. CIL består af et instruktionssæt som alle andre native assembly sprog. Hvis man lyster kan man skrive CIL kode i en tekst editor og derefter kompilere samt udføre det. CIL kode er svært at skrive, da man selv skal lægge værdier på stack en, styre stackens størrelse osv. C# to CIL Kode For at give en bedre forståelse af hvad CIL er, og hvordan det er opbygget vil der blive gennemgået nogle eksempler, men først en kort introduktion til CIL. Hver CIL instruktion består af en operator og eventuelt en operand, hvor operator (opcode) er hvilken instruktion der skal kaldes og operanden er metadata information, som enten kan være en metode, en type eller en værdi. Det første eksempel viser hvordan en simpel metode ser ud. Her er det Main metode som skriver til consollen. Som det ses af CIL kode så opretter den stringen Dette er en Console write line tekst. og lægger den på stakken. Herefter kalder den System.Console::WriteLine(string) som tager en parameter. Da den skal bruge én parameter så læser metoden den første værdi på stakken. CIL kodeeksemplet indeholder også andre instruktioner. Der er fx nop instruktionen (No OPeration) som ikke gør noget. Nop instruktioner bruges fx i debug mode, hvor et breakpoint ofte ligger på en nop instruktion. Alle metoder indeholder en ret instruktion (return) som det sidste, også selvom metoden har void som returtype. Der kan dog godt være flere ret instruktioner i en metode. Det næste eksempel viser, hvordan lokale variabler bliver oprettet og brugt, samt hvordan stakken spiller en vigtig rolle. Stakken bruges til at gemme oplysninger i umiddelbart før udførelsen af et statement. Som i ovenstående eksempel hvor vi lægger strengværdien på stakken inden udførelsen af call statementet. Inden der bliver defineret hvilke instruktioner, der skal kaldes i den enkelte metode skal der defineres hvor stor kalde stakken skal være. C# koden som bliver brugt i eksemplet opretter to integer og lægger deres værdier sammen i en tredje integer. Side 28 af 73

29 Når det bliver kompileret og oversat til det fælles kode sprog CIL ser koden sådan ud: Som det kan ses af ovenstående billede så er kaldestakken på 2, da vi skal bruge 2 pladser når der udføres en add operation. Det kan også ses at alle lokale variabler bliver defineret i starten af metoden. De lokale variabler er indekserede. Når der skal gemmes i en lokal variabel kalder man stloc.[index] og instruktionen gemmer den sidste værdi på stakken i variablen. Man skal være opmærksom på at stloc.[index] kun virker på de første fire lokale variabler, hvis man skal have fat i en 5. variabel, kalder man instruktionen stloc.s og angiver variablens definition i operanden, som er det der står lige bagefter instruktionen. En stor del af forretningslogikken kommer til at beskæftige sig med, hvordan man læser fra CIL koden og finder de CIL instruktioner som er interessante i analyse sammenhæng. Den anden store del af forretningslogikken kommer til at beskæftige sig med, hvordan man kan tilføje flere CIL instruktioner, de rigtige steder i programmet for at Monitor-modulet bliver kaldt rigtigt og uden at ødelægge brugerens program. Den grafiske del af produktet kommer ikke kun til at bygge på informationerne fundet i assemblyen men også fra deres tilhørende PDB fil. Side 29 af 73

30 2.7.2 PDB filen En PDB fil bliver dannet hver gang man bygger projektet i Visual Studio og knytter sig til en assembly. En PDB file indeholder informationer, som er relevante når der skal debugges. Man kan sige at PDB filen er en mapning mellem den færdige applikation og den rå kildekode. En af de informationer, som PDB filen indeholder, er hvilket linenummer de forskellige instruktioner tilhører i den originale kodefil (fx.cs filen). Man kan også finde den fulde sti til kodefilen i en PDB fil. Disse ekstra informationer vil blive brugt i applikationen, for at gøre det nemmere for brugerne at genkende deres metoder m.m. fra deres egen applikation, og derved gøre det nemmere for brugeren at vælge, hvad der skal spores. 2.8 Delkonklusion Ved at gennemgå de risici, der kan opstå og forhindre projektet i at nå det ønskede mål, er der mulighed for at problemstillingerne opdages så tidligt som muligt i processen, således at der kan tages de rigtige beslutninger. Ud fra usecase og aktør beskrivelserne er grundlaget for produktet lagt, og der er derfor mulighed for at gå i gang med designdelen af projektet. Ved at gøre brug af virksomhedens allerede eksisterede Monitor-modul, skal der ikke tænkes på klient- / server kommunikationen. En gennemgang af modulet var en nødvendighed for at vide, hvilke kald der er mulige. Det blev besluttet, at det skal være en WPF applikation og at programmets arkitektur skal være MVP, da disse to passer godt sammen og skaber en mere opdelt arkitektur. En anden fordel er, at konfigureringsdelen af applikationen kommer til at benytte sig af en del bindinger mellem model og view. Analyseafsnittet gennemgik også.net Frameworkets arkitektur, for at give en forståelse af, hvordan det er muligt at ændre et allerede kompileret program og hvordan CIL koden er opbygget. Værktøjet som bruges i projektet til at ændre CIL kode er Mono Cecil, da det var nemt at komme i gang med, og da virksomheden allerede havde erfaring med det. Side 30 af 73

31 3. Design Designafsnittet bygger på viden fra analyseafsnittet. Her vil være beskrevet, hvordan mockups har udformet sig fra første design ide til det endelige design. Der vil også være beskrevet designets sammenhæng (hvordan elementerne skal kommunikere på kryds og tværs). Der vil være afsnits om hvordan man kan give brugerne en bedre oplevelse, fx ved at foreslå forskellige standard sporingsmuligheder eller hvordan man på andre måder kan gøre det nemmere for brugerne af systemet. Afsnittet vil også indeholde en større design overvejelse, om det skal være en almen applikation (standalone) eller om det skal være en del af udviklingsmiljøet Visual Studio. Som beskrevet under usecase afsnittet 2.3, kan systemet deles op i to dele. Den ene del hvor man kan konfigurere hvad Monitor-modulet skal indsende af statistik til serveren, og den anden del af systemet hvor selve injektionen af Monitor-modulet i brugeres program sker. Der vil igennem designafsnittet være design ideer fra begge dele af systemet. 3.1 Plugin eller standalone applikation Allerede tidligt i designprocessen skulle der tages stilling til om applikationen skulle være en selvstændig applikation, eller om det skulle være en del af Visual Studio miljøet. Der er både fordele og ulemper ved at lave applikationen som en integreret del af Visual Studio, såvel fordele som ulemper vil blive beskrevet i de kommende afsnit. Et add-ins til Visual Studio er et tillægsprogram som kan lytte på events, ændre kode m.m. Oftest er mindre tillægsprogrammer kun tilgængelige i menuen Tools i Visual Studio. Andre større add-ins er tilgængelige ved højre klik, genvejstaster m.m. (kaldes VSPackages) 14. Det er helt afhængigt af hvad ens add-ins skal kunne og hvordan man ønsker at det skal være en del Visual Studio, om man vælger VSPackages eller det mere simple add-ins. Et eksempel på et større add-ins er ReSharper som er et kode refaktorering værktøj, der gør det muligt at generere trivielt kode ved brug af genvejstaster. Et mindre add-ins er Create GUID som kan danne GUID er (er en del af Visual Studio 2008 installationen). En af de store fordele ved at applikationen er en integreret del af Visual Studio er, at udviklerne allerede sidder i programmet, når de udvikler deres program. Det gør det nemmere, at man ikke først skal til at starte et andet program op, men kan gå direkte i menuen Tools og åbne applikationen der. En anden stor fordel er at add-ins kan lytte på fx når Visual Studio kompilerer et program og derved gøre det muligt for applikationen selv at integrere Monitor-modulet hver gang man kompilerer et program. Men det er selvfølgelig ikke alle udviklere, som ønsker at Monitor-modulet bliver integreret i projektet hver gang man kompilerer sit program. Det tager tid at integrere Monitor-modulet som et post-step efter en kompilering (før debuggeren kører programmet). En anden ulempe er, at lige så snart Monitoren er integreret i brugeres program bliver der registreret statistik som sendes til serveren. Man har måske glemt at Monitoren automatisk bliver integreret, når man sidder og tester ens program, og det kan hurtigt få indflydelse på statistikkerne. Derfor skal der være et håndtag så udviklerne ikke føler at add-in et er til gene 14 En VSPackages er en tættere integration med Visual Studio og er svære at håndtere end add-ins. Side 31 af 73

32 i stedet for til hjælp. Hvis det er et selvstændigt program er det nemmere for udvikleren at vide, hvornår Monitor-modulet er integreret. Efter dialog med virksomheden samt fremlæggelse af fordelene og ulemperne er det blevet en add-ins løsning, som skal implementeres. Der skal arbejdes på at gøre det klart for udviklerne, hvorvidt Monitormodulet er integreret i deres program eller ej. 3.2 Overordnede plan Den overordnede plan for hvordan hele systemet gerne skulle komme til at fungere. Systemet skal være en del af Visual Studio miljøet, som beskrevet ovenfor. Nedenfor er vist hvordan brugerens flow er fra åbning af Analytics Plugin til de kan starte deres program op med Monitor-modulet injektet uden at brugeren skal røre koden. Brugeren starter Analytics Plugin fra Visual Studio menuen Analytics Plugin åbnes og har analyseret brugeres kode Brugeren opsætter hvad der skal laves statistik over Brugeren gemmer opsætningen Brugeren kompilerer programmet igen (Efter kompilering er Monitor-modulet injektet) De grundlæggende punkter som der skal arbejdes med er derfor: Lave et Add-ins til Visual Studio Analysere brugerens assembly Vise et konfigurerings vindue hvor brugeren kan vælge, hvad der skal laves statistik over Gemme brugerens data Injekte CIL kode i brugerens program De store og tidskrævende dele i projektet bliver at analysere brugerens kompilerede program og finde de steder, hvor der er mulighed for at lave feature- og exception-track. Det bliver også en stor opgave at injekte mere kode til deres assembly, således at deres program kan indsende statistik. Side 32 af 73

33 Men man skal ikke glemme at der også skal designes et UI applikation, for at brugerne overhovedet kan bruge programmet. Hvis UI applikationen ikke er let at bruge eller virker uoverskuelig, så gider brugerne ikke bruge programmet. 3.3 Mockups Når man går i gang med et softwareprojekt, som skal indeholde en brugerflade, er det en god ide at lave mockups inden man går i gang med det endelige design. Ved at lave mockups får man en ide om, hvordan brugerfladen kommer til at se ud, uden at man har brugt langt tid på at designe og style de rigtige elementer. En af de vigtigste ting ved mockups er, at man kan vise dem til kunden (i projektet er det virksomheden Linkage) og få snakket om designet var det sådan kunden havde tænkt sig det skulle se ud? Ved at snakke om Mockups og ikke det rigtige design, er kunden mere åben over for at komme med ændringer til brugerfladen. Mockups er også gode til at se, om designideen rummer alle de stillede funktionskrav. Når der er flere som arbejder på samme projekt er mockups næsten uundværlige, da alle udviklere tænker forskelligt og dette vil kunne præge brugerfladens endelige design. Her er det klart en fordel, at man kan tage og uddelegere mockups til de forskellige medarbejdere, der implementerer designet. Den første design-ide var at man skulle guides igennem de forskellige konfigureringsfaser af programmet. Da man skulle guides var det oplagt at designe programmet som en wizard. Nedenfor ses wizards mockupsene: Side 33 af 73

34 Da disse mockups blev lavet meget tidligt i projektforløbet, var de ikke tænkt som en del at et plugin til Visual Studio. Det vil virke forkert, hvis der kommer en wizard hver gang man i Visual Studio vælger programmet fra menuen Tools. Det vil også være en ulempe for dem, som har brugt programmet et par gange, hvis de ikke kan springe direkte til det punkt, der skal laves ændringer i. Det resulterede i at wizard ideen blev droppet og en opsætnings lignende ide blev skitseret. Ideen er, at man kan klikke på de faner man gerne ville arbejde med. Det er netop i sådanne situationer at mockups viser sig fra sin stærke side, da der ikke er blevet brugt en eneste time på at implementere designet. Efter en kort tilretning kom mockupsne til at se sådan ud: Side 34 af 73

35 Da muckups er et skitseværktøj, har jeg lavet et hurtigt og simpelt design i Visual Studio, for at få en ide om hvordan skelettet var tiltænkt. Det er ikke altid nemt at udtrykke sit design igennem skitser, derfor denne lille implementering. Menuen og teksterne i toppen er tilføjet til billedet i Photoshop bagefter. Figur 9. Skitse til hvordan skelettet er tiltænkt, udført i WPF og Photoshop Som det sker i alle udviklingsprocesser, så ændrer designet sig hele tiden. Det er også, hvad der er sket her. Efter at flere personer havde kigget på designet, kom der et forslag om helt at droppe menuen. Grunden til at man kan droppe menuen, skyldes at menuen kun indeholdt 3 punkter (Account hvor man skal angive en produktnøgle og hvornår man skal integrere Monitor-modulet, Tracking som indeholder alle de tænkelige sporingsmuligheder, Version som kan informere om nye versioner af brugerens program). Ved at fjerne menuen kommer der en bedre bredde på resten af siden. Account og Version kommer ind under nogle nye expander (folde ud menuer, som også bliver brugt på Tracking siden). De store sektioner (de tidligere menupunkter) skal adskilles ved at lave nogle vandrette bjælker. Fordelen er at man kan overskue hele opsætningen på én gang og gå i dybden hvor man vil. Det endelige design kan ses nedenfor. Side 35 af 73

36 Figur 10. Det endelige design, ved EQATEC Tracer applikationen 3.4 Simpel Entitetsdiagram Arkitekturen i systemet er designet ud fra 3-lags modellen. Der er en frontend, som indeholder den grafiske repræsentation af programmet (konfigurerings vinduet). Det andet lag er kontrollaget, hvor kontrolklasser styrer forretningslogikken. Det tredje lag er backend, hvor data opbevaringsenheden sørger for at data kan gemmes og hentes frem igen. Der vil ikke blive beskrevet hvordan det simple entitetsdiagram er blevet udvidet til et klassediagram. Alle klasse diagrammerne er vedlagt som bilag 7.2. (Se eventuelt afsnittet 4.1 Projekt strukturen for hvad de forskellige klassediagrammer håndterer). Nedenfor ses et diagram, med en forsimplet tre-lags model med entiteter. Side 36 af 73

37 Simpel Entitetsdiagram Frontend Control classes / logic Backend GUI Logic Controller Data Model Storage 3.4 Sidestruktur Konfigureringsvinduet består af en masse expandere, som deler siden op i sektioner. Der er brug for at disse expanderes indhold ligger i forskellige sider/filer. Hvis det hele lå i en side ville der være uoverskueligt at lave tilføjelser og ændringer i vinduet. Derfor er det designet sådan at alle expanderne ligger i hver deres side/file. Som det kan ses af nedenstående figur, så arver alle klasserne fra en BasePage klasse. Den nederste række klasser repræsenterer alle expanderne i vinduet. Selve vinduet som indeholder alle expanderne er ligger i klassen Page og arver ligeledes fra BasePage. Figur 11. Klassediagram over vinduets opbygning Side 37 af 73

38 3.5 Datastruktur Stort set alle applikationer har brug for at have dataobjekter. Objekterne gør det nemmere at flytte data fra en metode til en anden, men de er også en vigtig byggesten, når det gælder om at holde data opdateret i et WPF projekt. Når man laver WPF applikationer og gør brug af MVP (Se afsnittet 2.5.3) er det vigtigt at have en stærk datastruktur, idet View får sine data ved at binde sig til dataobjekter. Konfigureringsdelen af applikationen, hvor brugeren har mulig for at se hvilke metoder, exception m.m. som vil blive tracket, indeholder mange forskellige slags data. Alle disse data er opbevaret i dataobjekter, hvor størstedelen af dataene kommer ved at analysere brugerens eget program, resten af dataene er gemte brugerdata. Datastrukturen for projektet er designet sådan, at alle data er samlet i et databærende objekt, som indeholder en række objekter. Dette er gjort for at have det hele samlet, hvilket er en fordel når det senere skal bruges af forretningslogikken til at injekte kode i brugerens program. For at få overblik over, hvordan datastrukturen er designet er der udarbejdet nedenstående figur: Figur 12. Datastrukturen Hovedobjektet er Settings klassen, som indeholder 5 properties hvor kun den ene ikke er en repræsentation af et klasse-objekt. Activated er en properties som skal indikere om Analytics Plugin er slået til eller fra for den åbnede Solution i Visual Studio. Side 38 af 73

39 Account klassen indeholder informationer om, hvornår Monitor-modulet skal injektes i brugerens program, samt hvilken produktnøgle der skal bruges. Produktnøglen fortæller serveren, hvilket produkt det indsendte statistik skal tilhøre. VersionCheck klassen indeholder kun en properties, som er en enum der fortæller, hvilken versionboks der skal dukke op, hvis der er nye versioner af brugerens program tilgængeligt. Features klassen indeholder informationer om knapper og menu-items automatisk skal findes og spores. Klassen indeholder også en liste af FeatureTrack klassen, som repræsenterer et muligt featuretack i brugeres program. FeatureTrack er items som er tilknyttet til Features klassen. Alle metoder, knapper og menu-items i det analyserede program optræder som et featuretrack items. Brugeren bliver præsenteret for alle feature track og udvælger dem, han ønsker at lave statistik over. Hvert objekt har en masse informationer om det fx er en knap, fundet i WPF, metodens størrelse m.m. Disse informationer er med til at gruppere feature trackene for brugeren, samt at injekte de nødvendige IL instruktioner for at spore netop den ønskede feature. FeatureTrack objektet indeholder også properties om featuren skal spores (brugerens valg), hvilket navn featuren skal spores med og en objektreference. Referencen bruges, hvis det er en knap eller menu-items, så man kan finde det sted i brugerens program, hvor man skal indsætte IL kode, uden at gennemsøge hele programmet igen. På samme måde som med Features og FeaturesTrack klasserne findes der også her to klasser, som bruges til at opbevare data for fundene exceptions i programmet. Den ovenstående beskrevne datastruktur er ikke kun gældende, når der skal præsenteres data for brugerne i konfigurerings vinduet, men den bliver også brugt når brugerens program analyseres, samt når der skal injektets ny kode i brugerens program. Settings klassen har derfor en stor betydning for applikationen. 3.6 Objekt serialisering Der er mange måder, hvorpå man kan gemme data. I projektet drejer det sig om at gemme den opsætning, som brugeren har foretaget i konfigurerings delen af programmet. En af de simpleste måder, hvorpå man kan gemme data er ved brug af XML Serialization. XML Serialization er en del af.net framework og giver mulighed for at gemme objekter som XML data. Når man gemmer ved brug af XML serialization bliver ens properties navne brugt som XML tags, medmindre andet er angivet i propertiens attributter. XML er de seneste par år blevet en standard for, hvordan man kan gemme data i mindre applikationer. XML har også den fordel, at det er læseligt for mennesker, da det er i ren tekst og logisk opbygget. Endvidere kan man rette i XML en ved at åbne dokumentet i enhver teksteditor, hvilket gør det særdeles stærkt og brugbart. Hvis man har en god datastruktur kan serialisering spare udvikleren for en masse arbejde. Side 39 af 73

40 For at man kan gemme sine objekter som XML data, skal man fortælle hvilke objekter, der skal være serialization. Det gør man ved at sætte attributten [Serializable] på selve klassen, derudover er det et krav at man har en konstruktør, som ikke tager nogle parameter. Nedenfor ses hvordan klassen Exceptions er lavet, så den er serializable. Bemærk også at der er sat attributter på listen TrackExceptionList. Disse to attributter angiver, at i stedet for at bruge propertiens navn som XML tag for hele listen, så skal der bruges navnet TrackList og at hvert element i listen skal have navnet Track i stedet for det default navn, der i dette tilfælde ville være ExceptionTrack. For at man kan gemme sit objekt til et XML dokument, skal man angive, at man bruger en XML serializer. Her er vist, hvor lidt kode der skal til for at gemme et objekt som XML data. Når man skal hente dataene fra XML dokumentet igen, kaldes de-serialize. De-serialize er lige så nemt som når man gemmer (Serializer), og ens objekt kommer til at indeholde de samme data, som da man gemte det. Nedenfor er vist et udsnit af xml dokumentet, som er generet vha. serializer. Side 40 af 73

41 XML serializer og de-serialize er brugt i projektet fordi det giver en række fordele. Blandt disse fordele er, at det ikke tager lang tid at implementere, og at der ingen vedligeholdelse er af strukturen for hvordan man gemmer, når man fx har lavet om i ens objekter. En anden vigtig fordel er, at XML er læsevenlig og redigerbart af alle Save og load Settings objekt Det er ikke alle properties i Settings objektet, der er nødvendige at gemme på disken. Mange af dataene er overflødige, da dataene kan dannes ud fra assemblies igen. Fx gemmes ikke alle feature- og exceptionstrack der er fundet i programmet. Som beskrevet i et senere afsnit 3.7 er der lavet en række tiltag til at spore forskellige elementer uden at brugeren skal tage stilling til det. I det tilfælde gemmes der kun en properties, som indikerer om denne automatiske udvælgelse er aktiv og ikke alle de elementer der ville være påvirket af denne properties indstilling. Der gemmes altså kun de feature- og exception-track som brugeren manuelt har taget stilling til skal trackes eller skal ignoreres. Alle de andre tracks kan findes igen ved at bruge den samme logik, som da man fandt tracket i første omgang. Det er heller ikke alle properties under en feature track/exception track som gemmes, der bliver kun gemt data nok til, at man kan finde samme track ved logisk udvælgelse igen. Som det kan ses af figur 12 (Oversigt over datastrukturen) så har klassen FeatureTrack en del properties, men da mange af dem kan genereres ud fra en assembly igen, så er der kun 5 properties, som skal gemmes. Nedenfor er et xml udkast af hvad der nødvendigt at gemme, for at en featuretrack kan findes igen: Side 41 af 73

42 Ud fra bare disse 5 properties kan man finde det rigtige element (en knap). Det sker ved at sammenligne FullMethodName og ObjectName med alle de featuretrack, som er fundet i en assembly. De resterende 3 properties fortæller om vi skal tracke det eller ignorere det, skal det trackes som et klik eller som en tid, samt navnet som det skal tackes med. For at få overblikket over hvor mange properties, der er skåret væk når der gemmes, er der designet et klassediagram, som kun indeholder de properties, som bliver gemt. Nedenstående figur skal sammenlignes med figur 12 under afsnittet 3.5 Datastruktur. Figur 13. Oversigt over properties som gemmes 3.7 Brugervenlighed Når man designer applikationer handler det om at designe en som er brugervenlig. Det kan være lige fra farvevalget til hvordan knapperne sidder til funktionaliteten. Ikke alle programmets brugervenligheds tiltag vil blive gennemgået, men blot nogle af de væsentlige design-ideer, som kan højne applikationens værdi. Et af de væsentlige tiltag, der er gjort for at øge brugervenligheden i konfigureringsdelen af applikationen, er overblikket. Som ses på figur 10 (Det færdige design under mockups) er der prøvet at give brugeren overblikket over hvor mange knapper, menu-items, exception og metoder der bliver tracket. Det handler om at det skal være muligt at se en oversigt når expanderne er lukket. Så når vinduet åbner, har man overblikket over hvor meget der bliver sporet. Side 42 af 73

43 3.7.1 Standardløsninger En af de væsentlige grunde til at projektet er iværksat er, at det tager for lang tid at konfigurere Monitormodulet i kode manuelt, når man bare vil teste det af hurtigt. Det er vigtigt, at brugerne ikke skal bruge unødvendig tid på at konfigurere injektningen af Monitor-modulet og derfor skal der laves en standard løsning, som rammer de fleste brugerønsker, som fx at versioncheck er sat til, og at der som standard trackes alle knapper og menu-items som er fundet i programmet m.m.. Exception punktet er det eneste som ikke er så nemt at lave en standardløsning til. Det skyldes at mange exceptionhandler i et program ikke lave nået eller eneste formål er at kaste en ny exception. Hvis man trackede alle exceptionhandler i et program, så vil den samme exception optræde flere steder i statistikrapporten, da exceptionen vil indrapporteres hver gang den fanges af en exceptionhandler. Når en exception fanges af en catch-blok, er det første der sker, at den indrapporteres til Analytics serveren, hvis så den næste instruktion er en throw; (re-throw) eller throw new exception, så kastes der en ny exception, som vil blive fanget et andet sted i programmet. Nedenstående figur viser eksempler på exceptionhandler der ikke ønskes sporet. Figur 14. Exceptionhandler re-throw. Tom exceptionhandler. Throw ny exception Der findes også mange exceptionhandler, som kun indeholder return; eller return ;, de er heller ikke interessante. Det kunne fx være, at man prøver, at gøre et eller andet og hvis det fejler, returnerer man null eller noget andet. Man har som udvikler taget højde for at der kan ske fejl, og man håndterer fejlen et andet sted. Kort fortalt ønskes der kun de exceptionhandler sporet, som udvikleren virker interesseret i at spore herunder UnhandledException. Efter analyse af 5 mellemstore programmers 15 exceptionhandler, er der to betingelser, som skal være opfyldt for at en exceptionhandler automatisk bliver tracket. Må ikke indeholde throw, indre try-catchblokke tæller ikke med. Skal indeholde et metodekald. For at Monitor-modulet kan registrere et featuretrack skal det have et tracknavn. Men det er ikke meningen af brugeren af systemet skal sidde og finde på alle navnene for at bruge systemet. Derfor er det 15 EQATEC Profiler, EQATEC Tracer, EQATEC Analytics Monitor, NASA World Wind og Paint.net Side 43 af 73

44 også ønsket at tracknavnene skal være udfyldt på forhånd. Som standard er valgt klassenavnet plus methodes navn for metode featuretrack og for knapper og menu-items er standard tracknavn hhv. button_<klassenavn>.<knap navn> og menu_<klassenavn>.<menuitems navn> PDF filen Som beskrevet tidligere så indeholder en PDB fil en masse ekstra informationer, som bruges ved debug af programmet. Hvis PDB filen findes til den givende assembly, kan de data som den indeholder udnyttes, fx hvor kildekoden var placeret ved kompileringstidspunktet. PDB files informationer vil blive udnyttet i programmet til at hente dele af kildekode. Ved at hente dele af brugeres kildekode, kan man nemmere fortælle brugeren at et track hører til denne stump kode i dit program. Det har stor betydning for brugervenligheden, når man skal til at vælge hvilke exceptionhandler man ønsker at spore. Det kan være at man ikke kan huske hvilken exceptionhandler, der skal spores i en specifik metode, eller hvis der er flere exceptionhandlere i en metode. Kildekode udsnittet er også brugbart for brugeren, der undrer sig over, hvorfor en given exceptionhandler ikke er med som en standarttracking. For at se hvordan det bliver brugt i programmet, se da figur: 19 under afsnittet Filter For at gøre programmet mere brugervenligt er der lavet en række tiltag i brugergrænsefladen, et af dem er et filter. Hvis brugeren blev præsenteret for alle metoder i deres program, ville det nemt blive uoverskueligt at finde lige den metode, som man ønsker. Derfor skal der være mulighed for, at man kan søge efter metodenavn eller vælge det namespace, som metoden ligger i. Der samme gælder for featuretrack og exceptiontrack. Figur 15. Filter muligheder i konfigurerings programmet Hjælp ved forkert brug Det er umuligt at lave et program, hvor alle brugerne præcist ved, hvad de skal gøre og derfor ikke laver fejl. Derfor skal der i et opsætningsprogram tages højde for at brugerne indtaster ugyldigt tegn, laver fejlindtastninger, eller har glemt at indtaste en værdi i et felt. Systemet skal oplyse brugeren om, at her er sket en fejl, eller der mangler at blive indtastet en værdi. I det tiltænkte design findes der en masse fold-ud menuer, og der er derfor mulighed for at brugeren kommer til at kollapse menuen og derved skjuler fejlen. Systemet skal derfor, når man prøver at gemme, guide brugeren hen til stedet, hvor der er fejl eller manglende indtastning. De to figurer viser hvordan opsætningsvinduet ser ud hvis man hhv. har slettet navnet der skal spores med eller indtastet en invalid produktnøgle. Ved begge tilfælde vil menuen folde ud og feltet få fokus, samt en Side 44 af 73

45 fejlbesked vil dukke op nede ved gem-knappen. Hvis et sporingsnavn (trackname) ikke er udfyldt, vil der automatisk blive scrollet ned i listen, så fejlen kan ses med det samme. Det er gjort for at brugeren ikke selv skal scrolle op og ned for at finde stedet. Figur 16. Hvis der trykkes gem og et tracknavn ikke er udfyldt, findes fejlen og vises for brugeren Figur 17. Hvis brugeren indtaster en invalid produktnøgle. Side 45 af 73

46 3.7.5 Udvidelser til brugervenlighed Brugeren skal kunne vælge hvilken pop-up boks der skal dukke op, når der kommer en ny version af programmet. Fx hvis brugerens program er lavet i WPF er det ikke så smart at vise en Winforms dialog. Lige nu er programmet designet så det er nemt at implementere flere pop-up bokse. Hvis brugeren ikke allerede har en konto hos EQATEC Analytics, skal det være muligt inde fra programmet at oprette en ny konto. Fx ved et popup vindue hvor man kan indtaste og produktnavn, programmet vil kommunikerer med en webservice på serveren, som returnere produktnøglen. 3.8 Delkonklusion Produktet skal laves som en plugin-applikation til Visual Studio efter gennemgang af fordele og ulemper ved plugin og standalone applikationer. Mockups blev designet ud fra hvilke krav, der var stillet til projektet. Datastrukturen er blevet designet solidt, så det kan bruges i hele projektet, samt er brugbar ved datalagring af brugerens opsætning. I afsnittet Datastruktur er beskrevet de forskellige klasser og properties. Der er en gennemgang af hvorfor Objekt serialisering er den bedste måde at gemme data på. Objekt serialisering giver mulighed for at gemme brugeropsætningen på disken som en XML fil. I designafsnittet er der lagt vægt på, at programmet skal være så brugervenligt som muligt, da hele produktets eksistens bygger på, at det er for besværligt og tidskrævende selv at implementere Monitormodulet. Resultatet er blevet flere forskellige standardløsninger, som gør at den almindelige bruger ikke skal træffe noget valg. Programmet er også designet, så det hjælper brugeren, hvis der laves fejl, eller der søges efter bestemte oplysninger. Side 46 af 73

47 4. Implementering Der er mange linjer kode, der spiller en rolle i et større projekt som dette, men det er langt fra alle dele af programmet der kan gennemgås i dette afsnit. Der er udvalgt de dele, som er mest interessante for at systemet kan fungere. Afsnittet indeholder implementeringsdele fra både konfigureings- og injektings delen af systemet. 4.1 Projekt strukturen For at giver overblik over hvordan kode er bundet sammen af moduler, vil de forskellige projekter i solutionen blive beskrevet kort her: Projekt AnalyticsPluginAddin: AnalyticsPlugin: AnalyticsPluginEngine: AnalyticsPluginRuntime / AnalyticsPluginRuntimeCF: Installer: Beskrivelse Er projektet som danner et add-ins til Visual Studio 2005/2008. Det er her der lyttes på om projektet bliver buildet, som er en indikation på, om vi skal injekte kode i brugeres program. Projektet tilføjer også Analytics Plugin konfigurerings programmet til menu en Tools. Selve konfigurerings vinduet. Vinduet åbnes når man trykker på Analytics Plugin i menu en Tools. Projektet kan ses som viewet, da der ikke sker så meget andet end at brugeren bliver præsenteret for data. Når der gemmes og hentes data sker det igennem projektet AnalyticsPluginEngine s interfaces. Selve forretningslogikken er pakket ned i dette projekt. Her analyseres brugerens program og registrerer de fundne exception og featuretrack. Projektet stiller interface til rådighed, hvor der blandt andet er mulighed for at lytte på fejl-/informationsmeddelelser. Forretningslogikken i projektet sørger også for, at der bliver injektet kode i brugerens programmer, alt efter hvad brugeren har konfigureret det til. Projektet indeholder to runtime moduler og to Monitor-moduler, et til fuld.net og et til Compact Framework. Er runtime biblioteker. Det vil sige, at det er dem, der bliver injektet metodekald til, ved fx en knap eller exception i brugerens program. Når der bliver trykket på en tracket knap, bliver der kaldt en metode i runtime modulet. Modulets opgave er at håndtere kaldet og kalde EQATEC Monitormodulet. Grunden til at der ikke bliver kaldt direkte ned i Monitor-modulet er, at det kræver meget mere injektet kode. Fx er det noget nemmere i C# at tage højde for exception, null referencer m.m. Derfor er der indsat dette mellemmodul mellem brugerens program og selve Monitor-moduler, som indrapporterer til EQATEC Analytics serveren. (Figur 18. nedenfor - viser hvordan modulerne hænger sammen) Disse runtimemoduler er embedded resurser i AnalyticsPluginEngine, og bliver trukket ud af dll en og skrevet til disken som en dll fil, når det er besluttet hvilket af runtimemodulerne, der skal bruges. Projektet laver en MSI installer fil, og gør det muligt at installere Analytics Plugin på alle Windows maskiner, som har Visual Studio 2005 eller 2008 Side 47 af 73

48 installeret. Test_Engine: nunit test af projektet. Dette projekt tester dele af funktionaliteten, og vil blive brugt i test-afsnittet. Brugerens program Runtimemodul Monitormodul Analytics server Exception fanges Event Kald http request http respons Internettet Figur 18. Oversigt over hvordan modulerne hænger sammen 4.2 Exception Den måde Mono Cecil håndterer exceptionhandler på, er ved at samle alle exceptionhandler for en metode i en collection. Denne exceptionhandler collection indeholder exceptionhandler elementer, der hver især har informationer om deres start/slut på try- og catchblokke, samt typen. I dette program skal brugeren have mulighed for at vælge eller fravælge en exceptionhandler i at blive tracket. Og da Mono Cecil ikke har en unikhed på exceptionhandlere, så skal systemet derfor designes så det tager højde for at en metode kan have mange exceptionhandlere og nogle af dem kan være nestede exceptionhandlere. Til dette er der lavet et simpelt system, hvor en tæller bliver talt op for hver catch type. Nedenfor kan ses kode udsnittet, hvor vi løber alle exceptionhandler i metoden igennem, og hvis vi finder en exceptionhandler, som har samme exception type, så tæller vi tælleren op. På den måde kan vi have to ens exceptions typer (fx System.Exception) i programmet og brugeren kan vælge at tracke den ene og ikke den anden. Side 48 af 73

49 4.3 PDB-filen Som beskrevet under designafsnittet, så ønskes der at brugeren kan se udsnit af kildekoden ud fra hver exceptiontrack, for at brugeren nemmere kan træffe en beslutning om en given exceptionhandler skal spores eller ej. For at man kan bruge informationerne fra en PDB fil, såsom linjenummer og sti til kildekoden ved kompiler tidspunktet, så skal man indlæse PDB filen i Mono Cecil biblioteket ved følgende kommandoer: Hvor assemblydef er assemblyen og fi er FileInfo på PDB filen. Mono Cecil fletter så instruktionerne i en assembly med linjenummeret fra PDB filen. Det er dog ikke alle IL instruktioner som får et linjenummer. Fx skal alle parametre til et metodekald indlæses på stacken, inden man kalder metoden, det skal der bruges IL instruktioner til, men de har ikke noget linjenummer tilknyttet. Det samme er gældende for de fleste nop, samt leave-instruktioner, som afslutter en exceptionhandler catchblok. For at finde exceptionhandleren i kildekoden skal der først findes linjenumrene, som exceptionhandleren strækker sig over. Derfor tages der udgangspunkt i exceptionhandlerens startinstruktion og bevæger os en instruktion ad gangen baglæns, indtil vi finder en instruktion, som indeholder et SequencePoint, som er vores linjenummer. Det samme er gældende for slutpunktet for exceptionhandleren dog bevæger vi os nu fremad i stedet for tilbage for at få alle linjerne med. Nedenfor ses hvordan start linjenummer findes: Måden hvorpå vi henter kode snippen ud fra brugerens kildekode er vist nedenfor: Side 49 af 73

50 Metoden tager tre parametre FileInfo (kildekode filen), start og stop linjenummer. Da det tager lang tid at hente data fra en disk (sammenlignet med ram), så gemmes seneste kildekodefils indhold som et string[] en for hver kodelinje. Det første tjek der laves er derfor, om vi har indlæst kildekodefilen før, hvis det er tilfældet, så henter vi de linjer i kildekoden, vi skal bruge. Ellers må vi indlæse filen og dele den ved linjeskift, hvorefter vi kan hente kildekodestumpen, hvilket sker ved at loope over alle de linjer, vi skal bruge og lægge dem på en string. I programmet kommer det til at se således ud, når man holder musen over første linje i catchblokken: Figur 19. Catchblokken hentet fra kildekoden. Side 50 af 73

51 4.4 Injekte Monitor-Modulet Når brugeren har opsat konfigureringsdelen af programmet og skal til at injekte kode i egen assembly sker der en række processer. Fx tjekkes der hvilken version af frameworket, der er benyttet, er det fuldt.net eller Compact Framework der er brugt og om programmet/dll er allerede indeholder Monitor-modulet. Analytics Plugin programmet indeholder to runtime-moduler og to EQATEC Monitor-moduler, et kompileret i Compact Framework og et til det fulde framework. Det injektet kode skal kalde metoder i runtimemodulerne, og det er derfor nødvendigt at placere modulet ved siden af deres program. Alt efter hvad et tidligere tjek viser, finder vi de embedded resurcer, der passer til resultatet og skriver dem til samme mappe som deres assembly ligger i. Inden alle filer i deres output mappe bliver analyseret og Monitor-modulet tilføjet, oprettes der et RuntimeModule objekt, som er en samling af alle de referencer, som man kan gøre brug af ved injektion af IL kode. Objektet er også nemmere at håndtere end en hel række af parametre til hvert metodekald. Side 51 af 73

52 RuntimeModule oprettes og dens properties Assembly bliver sat til det in-loadede runtime bibliotek (enten fuld.net eller CF runtime-modul). RuntimeModulet indeholder en række ting, men det vigtigste er nok alle runtimens metoder. Nu er forarbejdet gjort og vi kan gennemløbe alle assemblies, som ligger i outputmappen igennem. Når vi har loadet en assembly ind, tilføjer vi vores Runtimemodul til assemblyen. Det sker i den første linje nedenfor. Derefter importerer vi alle vores tidligere fundne metodekald ind i den indlæste assembly, det giver os en reference, som kan bruges indenfor denne fil. Når vi senere ønsker at kalde en af runtimens metoder ved IL kode, kan vi kalde referencen. (Læg mærke til at vi bruger det tidligere oprettede runtimemodul objekt alle steder) Nu har vi indlæst vores file/assembly og vi har referencer til alle runtimens metoder. Vi er nu næsten klar til at injekte IL kode i brugerens program, vi skal dog først finde de feature- og exceptiontrack, som brugeren har ønsket at tracke. Vi gennemløber derfor alle metoder og konstruktører i filen. For hver af dem henter vi feature/exception track fra den gemte konfigureringsopsætning, hvor trackets metodenavn er det samme som den aktuelle metode. Vi henter også en liste med feature/exceptiontrack fra den intelligente selekter (Den vil blive forklaret her 4.5 Track udvælges). Grunden til at denne liste skal bruges er, at den indeholder referencer til de IL instruktioner, som skal spores. Vi har altså nu to lister for exceptiontrack, en som er fra settingsfilen (brugerens opsætning) og vores intelligente udvalgte liste (som indeholder alle exception, som er fundet i programmet og har referencer til IL koden). Listerne sammensmeltes til en liste og settingslisten er mest betydende. Hvis der i settingslisten står at en exception ikke skal trackes, og den i den anden liste står til at trackes, så bliver exceptionen sat til ikke at blive tracket. Brugeres valg vinder altså. Den sammenflettede liste indeholder alle exception i filen, og vi kan gennemløbe dem en for en. Side 52 af 73

53 Som det kan ses på ovenstående figurs næstsidste linje, så har vi nu den første IL instruktion i exceptionhandleren, og den skal vi bruge til at analysere, hvor exception-objektet er gemt. Med andre ord, det vi ønsker er at kunne putte exception-objektet på stacken, lige inden vi kalder vores runtimemodul, som tager en parameter (første værdi på stakken). Exception-objektet er i dette eksempel exc s værdi. (C# kode: try{}catch(exception exc){}). Det er helt afhængigt af hvor mange lokale variable og parametre metoden har, for hvor exceptionobjektet er gemt. Derfor må der ud fra den første instruktion findes den rette IL instruktion til at hente exception-objektet til stacken inden runtimemetode kaldet. Nedenfor er vist hvordan det gøres. Læg mærke til, at det findes 4 instruktioner til at hente de første 4 lokale variabler ud, derefter skal man gøre brug af instruktionens operand. En anden ting som er vigtig at bemærke er, at det ikke er sikkert at exception-objektet overhovedet bliver gemt. Fx ved denne C# kode try{}catch(){} bliver exception-objektet ikke gemt, men da objektet altid bliver lagt på stacken, kan vi udskifte pop-instruktionen med en ny oprettet lokal variabel. Vi ved nu hvor vores exception-objekt er gemt og har oprettet en instruktion til at hente objektet ud på stacken igen. Nu kan vi omsider tilføje IL kode instruktioner, som kalder runtimemodulets singleton, push exception en på stacken og kalde metoden som trackerexceptionen. Side 53 af 73

54 Herefter er den ene exceptionhandeler håndteret og gennemlæsning af den næste kan forestå. Der vil ikke blive gennemgået, hvordan en featuretrack bliver injektet, da det er en del mere kompliceret. Dette skyldes, at der er forskel på WPF og Winforms opbygning af deres grafiske IL kode, samt at der er forskel på, om man vil lave et featuretrack af en metode eller en knap ect. Featuretrack af en metode er mere kompliceret ved, at der er to forskellige måder, den kan trackes på, ved tidstracking skal der sikres at tiden stoppes. 4.5 Track udvælges For ikke at få duplikeret kode i systemet, er der lavet en klasse, der analyserer assemblyen samt registrerer alle exception- og featuretrack. Denne udvælgelsesproces bliver brugt både når der skal injektets kode og når brugeren skal konfigurere, hvilke track der skal spores. I konfigureringsdelen bliver listerne med mulige tracking items vist for brugeren. I injektningsdelen af systemet bliver disse lister med alle exception- og featuretrack sammenlignet med den gemte opsætning. Når der så skal injektes, er det med udgangspunkt i de intelligente lister, da de indeholder referencer til IL-instruktioner, hvor der skal indsættes mere kode. Der vil her blive gennemgået hvordan den intelligente udvælgelse virker for et featuretrack. Der er forskel på, om det er Winforms eller WPF der er brugt som arkitektur. I Winforms bliver der brugt ILinstruktionen Newobj, når der laves et nyt objekt fx en knap eller menu-items. I WPF er det IL-instruktionen Castclass som er brugt. Nedenfor er vist, hvordan alle instruktioner i metoden bliver tjekket om det er en Newobj-instruktion, hvis det er tilfældet, prøver vi at caste operand en til et MemberReference objekt. Ved en Newobj-instruktion er operanden typen på objektet. Side 54 af 73

55 Der kan derfor efterfølgerne tjekkes om operanden er af typen ToolStripMenuItems, som er typen for et menu-item i winforms. Nu ved vi, at vi har med et ToolStripMenuItems at gøre. For at kunne lave en featuretrack på menu-itemet, skal vi have fat i objektets navn, det gøres ved at tage operanden på den efterfølgende instruktion. Herefter oprettes et featuretrack med en række properties, så det er brugbart både for konfigureingensdelen af systemet men også for injektiondelen. For at vise hvordan IL-koden ser ud for instantiering af et ToolStripMenuItems, er der indsat denne figur. Som det ses af figuren, bliver der lavet et ToolStripMenuItems objekt og det får navnet exittoolstripmenuitems, endvidere ses, at det er tilknyttet klassen Form1 i namespacet testkodeiruntimemodul. Hvis man har valgt at tracke menu-itemet så kommer IL koden til at se sådan ud efter næste build. Side 55 af 73

56 4.6 Konfigureringsdelen af programmet Som beskrevet i analyseafsnittet, er der blevet brugt WPF til at lave viewet med. Viewet indeholder en del bindings både simple bindings men også lidt mere komplekse bindings, såsom multibindings med konvertere m.m. Et eksempel på en af de mere komplekse bindings ses nedenfor. Det er bindingen, som fortæller hvilket billede, der skal vises ud fra en given track. Der er tre billeder: et med et grønt rettehak (bliver tracket ud fra brugerens valg), grå rettehak (bliver tracket ud fra standardløsning) og et minus (bliver ikke tracket brugerens valg). Multibindingen består at 3 bindingsproperties. Den første properties TrackThis er om brugeren har valgt at tracke det, ikke tracke det eller ikke taget stilling til tracket endnu. Den anden properties er en bool, som indikerer om det som standard skal trackes og har kun betydning, hvis den første properties er None (Brugeren har ikke taget en beslutning). Den tredje binding er, om brugeren har valgt automatisk tracking til. Som det kan ses at ovenstående figur, så er den 3. binding lidt speciel. Det skyldes at vi binder til en property, som ikke er tilknyttet til datagrid et. Når man angiver hvilke data som et datagrid skal vise sætter man propertien ItemsScource på datagrid et. Det er gjort ved at lave en liste af FeatureTrack objekter. Men da den 3. binding skal have data fra en propertie, som ikke er tilknyttet et FeatureTrack object, skal man binde til et element højere oppe i det virtuelle træ. Man er derfor nødt til at finde et element højere oppe i det virtuelle træ, som ikke har fået sat deres DataContext property. For når man skal binde en propertie til et element, så skal DataContext på elementet være sat til et objekt eller en property. I ovenstående tilfælde ligger datagrid et inden i en Expander og da Expanderen ikke har sat dens DataContext, er det oplagt, at det er den som holder informationen om automatisk tracking af alle track inde i datagrid et. Det første der skal gøres er at sætte DataContext på Expanderen lig med et objekt som indeholder propertien. Objektet er Features klassen, da Features klassen indeholder propertien Se evt. Datastruktur på side 38. Det er vist her: Side 56 af 73

57 Eftersom Expanderen er højere oppe i det virtuelle træ, kan der inde fra et items i datagrid s DataTemplate søges op igennem det virtuelle træ, til vi finder det første element af typen Expander og binder os til dens DataContext s properties. Denne slags bindings er nødvendige af og til, når man vil have fat i en property, som ikke er med i fx Datagrid et items. Hvis man ikke er omhyggelig og har overblikket over det virtuelle træ, kan det tage lang tid at finde fejlen. 4.7 Delkonklusion Efter implementeringen af projektet kan det ses at applikationen indeholder mange moduler (dll). Dette er nødvendigt for at lave en lav kobling, som giver nemmere udskiftning af de enkelte moduler. Der har også været en gennemgang af, hvordan det teknisk er muligt at hente dele af kildekode ved brug af PDB filen. Implementeringsafsnittet har gennemgået, hvordan det tekniske er opbygget, for at man kan finde knapper, menu-items m.m. i brugerens program, samt hvordan det er muligt ved hjælp af Cecil at ændre brugerens program. Det at kunne ændre brugerens program, er den vigtigste teknik for at projektet kan laves. Dele af de tekniske implementeringer af konfigureringsdelen i projektet er også blevet gennemgået, herunder hvordan multibindings er lavet. Side 57 af 73

58 5. Test Man kan ikke designe og implementere applikationer under at der tages højde for testningen. Der findes alt for mange programmer ude i verden som laver fejl, fordi de ikke er testet godt nok. Testafsnittet kommer til at omhandle de test, som systemet er blevet udsat for, udover de test som er blevet lavet under selve udviklingen af systemet. 5.1 nunit test nunit test er test som kan køres igen og igen. Fordelen ved nunit test er, at de kan køres inden man udgiver en ny version af programmet, og på den måde sikrer man, at der ikke laves fejl ved implementering. Til større projekter laves der flere hundrede test, og testene køres dagligt, så man sikrer, at den nyeste kode også virker. Projektet er ikke så nemt at teste med nunit test, da meget at logikken går ud på at tilføje mere kode til et program. Det kan man ikke så nemt teste med nunit test, derfor er der også udført andre test- typer. Der er 3 hoveddele som testes med nunit test, disse vil blive beskrevet i de næste underafsnit. Figuren viser programmet nunit, som tester de skrevne nunit test. Figur 20. Oversigt over de kørte NUnit tests Side 58 af 73

59 5.1.1 Konfigurerings Test Der testes om konfigureringsdelen af forretningslogikken virker. Der benyttes det udstillede interface fra AnalyticsEngine modulet. Test navn Beskrivelse Resultat Test 1 Test 2 Test 3 Find alle featuretrack i assemblien. Test at de fundne featuretrack er af de rigtige typer. Fx knap og menu-items. Find alle exception i assemblien. Test at der er fundet det rigtige antal exceptions og at deres properties er sat korrekt. Test at sammenfletning af gemte featuretrack og de analyserede featuretrack fra assemblien kan ske. Samt at de analyserede featuretrack har fået de gemte værdier. Succes Succes Succes Test 4 Samme test som test 3. Dog er det for exception. Succes Settings test Testning om opsætningen kan gemmes og hentes ind igen korrekt. Der bliver også testet at der kun gemmes de featuretrack og exception, som brugeren har taget stilling til (ikke alle der er fundet i programmet). Test navn Beskrivelse Resultat Test 1 Test 2 Tester om der findes et XML dokument med opsætningen i, ellers gives der et settingsobjekt, som indeholder standard indstillingerne. Samme som test 1, dog har man angivet en fuld sti til XML dokumentet, som kun skal have en sti på mappe niveau. Succes Succes Test 3 Ser om en simpel gem og hentning af settingsobjektet lykkes. Succes Test 4 Test 5 Tester om et featuretrack kan gemmes og hentes ud igen. Er alle værdierne de samme efter en gem/hent udførelse. Ser om et featuretrack, som brugeren ikke har taget stilling til, bliver gemt. Der bør kun gemmes featuretrack, som brugeren har taget en aktiv stilling til. Succes Succes Side 59 af 73

60 5.1.3 Injektion test Der testes, om der kan injektes kode i en assembly. nunit delen af testen ser kun på, om det kan lade sig gøre, ikke om det er blevet gjort korrekt. Derfor skal det injektede program køres manuelt bagefter. Test navn Beskrivelse Resultat Test 1 Tester om der kan gennemføres en injektning i et program. Denne test ser kun på om det lykkes at tilføje mere kode. Ikke om programmet efterfølgende virker. Succes 5.2 Blackbox test Nedenfor er der beskrevet 3 blackbox test som er udført. Testens formål er at teste systemets funktionalitet i forhold til, om man kan aktivere Analytics Plugin add-in en, oprette track og om Monitormodulet bliver injektet korrekt i brugerens program. Der er først forklaret en kort testplan i punktform, hvor man kan læse, hvad der testes og rækkefølgen for udførelsen af testen. Da produktet bliver en integreret del af Visual Studio efter installationen, er det vigtigt, at det opfører sig rigtigt på alle computere. Derfor er der udarbejdet en blackbox test, som kommer rundt om Plugin ets funktionalitet Aktivere Analytics Plugin Test om Analytics Plugin kan aktiveres i Visual studio. Når Analytics Plugin er aktiveret så ændres dens tekst i Tools menuen til (Active). Der skal også komme en XML fil som indeholder standard opsætningen. Testplan: 1. Åbner Visual Studio Åbne et projekt 3. Åbne Analytics Plugin a. Menuen Tools -> Analytics Plugin 4. Sæt flueben ved aktivere Analytics Plugin. 5. Udfyld produktnøglen. 6. Tryk på knappen save. Side 60 af 73

61 Forløb: Efter udførelsen af testen ud fra testplanen så skiftede Tools menuen tekst samt XML filen blev oprettet korrekt. Figur 21. Menuen Tools indeholder Analytics Plugin Opsætning af Analytics Plugin For at denne test kan udføres skal den ovenstående blackbox test være udført korrekt. I testen ses om der kan navigeres rundt i Analytics Plugin vinduet, som er systemets konfigurerings del. Her opsætter man, hvad systemet skal lave statistik over, fx hvilke knapper, metoder m.m. Testen skal også vise, om alle brugerens opsætninger bliver gemt. Testplan: 1. Åben Analytics Plugin 2. Klik ind på fold-ud menuen Buttons 3. Fravælg en knap, ved at kikke på fluebenet under kolonnen Track This (ikonet skal være et minus) 4. Klik ind på fold-ud menuen Method 5. Vælg en metode at tracke, klik i kolonnen Track This (ikonet skal være et rettehak) 6. Klik på fold-ud menuen Build 7. Sæt flueben i Debug-mode 8. Tryk på knappen Save Side 61 af 73

62 Forløb: Testen lykkes, da det var muligt at navigere rundt i vinduet, samt at brugerens opsætning blev gemt i XML filen. På figuren ses indholdet af XML filen. Det ses, at der er gemt 2 track. Et som er knappen (den første xml node) og det andet som er metoden. Figur 22. Indholdet af XML dokumentet efter testen Analytics Plugin tilføjer kode For at denne test kan udføres skal begge ovenstående test være udført. Testen viser, om en kompilering af Visual Studio projektet også får tilføjet mere IL kode, som skal sende statistik til serveren og brugen af programmet. Testen skal vise, at den knap som er fravalgt i ovenstående blackbox test ikke bliver sporet, selvom der bliver trykket på den i programmet. Testplan: 1. Kompiler projektet. Ved fx at starte debuggning F5 2. Klik på knapperne i programmet også den som er fravalgt i forrige test 3. Luk programmet Side 62 af 73

63 Forløb: Testen lykkedes, som det kan ses af figuren. Figuren viser hvilke http kald der er foretaget, og vi kan også se ved hjælp at netværkssnifferen 16, hvilke data der er sendt til EQATEC Analytics serveren. Figur 23. Screen dump fra Fiddler2 Som det kan ses på figuren, sender vi en masse statistik-informationer til serveren, den sidste linje er featuretracket for den udvalgte metode. Feature navnet er det samme som oppe i XML dokumentet se figur 22. På screen-dumpet kan det også ses at resultatet fra serveren var success. Nedenstående figur viser, hvordan featuretracks dataerne bliver vist i en rapport på analytics.eqatec.com. Figur 24. Udsnit af rapporten på analytics.eqatec.com serveren 16 Programmet der bruges er Fiddler2 og kan hentes her: Side 63 af 73

64 5.3 Brugerflade test De to foregående testtyper, nunit og blackbox test, tester kun funktionaliteten af programmer. Brugerflade testen viser, om brugerne kan finde ud af systemet. Der er blevet foretaget en del mindre test af systemets udseende igennem udviklingen. Det færdige system har været præsenteret for virksomhedens medarbejdere, og der var en klar begejstring over systemets funktionalitet, og hvor intuitivt det var. Systemet er også blevet afprøvet af en person 17 som ikke kender til EQATEC Analytics. Det eneste der blev forklaret var at systemet var et plugin til Visual Studio, og at der ved hjælp at pluginet ville blive sendt statistikinformationer om ens applikation til EQATEC Analytics. Testpersonens reaktion var meget positiv. Han kunne på 2 minutter indsamle data om sin egen applikation, uden at han skulle kode en eneste linje kode. Systemet var enkelt, og han behøvede ikke lave de store indstillinger for at det virkede. 5.4 Delkonklusion Det lykkedes at lave de tests, som var defineret for nunit- og blackbox-test. Endvidere blev applikationen afprøvet på en testperson, som fandt det let at bruge. Konklusionen for testafsnittet må derfor være at programmet virker efter hensigten. 17 En med studerende på DTU Diplom IT retningen. Side 64 af 73

65 6. Konklusion Efter at have analyseret, designet, implementeret og til sidst testet applikationen er det på tide at drage den endelige konklusion over bachelorprojektet. Der er udviklet et plugin til EQATEC Analytics, som gør det muligt for brugeren hurtigt, nemt og uden at kode en eneste linje kode, at få tilføjet Monitor-modulet til deres allerede eksisterende applikation. Plugin applikationen giver brugeren mulighed for at lave brugerdefineret statistiker over brugen af deres programmer, på en nem måde. Det endelige produkt er et plugin til udviklingsmiljøet visual studio og er implementeret som en WPF applikation, der gør brug af MVP arkitekturen. Applikationen er endvidere op delt i flere moduler for at gøre det nemmere at skifte dele af applikationen ud. opfylder alle de krav som er stillet i kravspecifikationen og er et fuldt funktionsdygtig værktøj, som skal give flere kunder til EQATEC Analytics servicen. I projektet er brugervenligheden blevet vægtet høj, hvilket også kan ses i det færdige produkt. Mange af tiltagene har drejet sig om, at give brugeren et værktøj, som gør at de kan komme i gang med det samme, uden en masse opsætning eller kodning først. I programmet er der truffet en række standardløsninger, som gør at den almene bruger ikke selv behøver tage beslutningerne. Hvis standardløsninger ikke passer til brugeren har han mulighed for at ændre opsætningen så den passer ham. Som testpersonerne af brugerfladen også har erfaret, så er det endelige produkt enkelt at bruge, og man kommer hurtigt frem til det væsentlige, nemlig statistik over egne programmer. Ud fra testafsnittet kan der konkluderes at produktet virker efter hensigten, og at testpersonen ikke havde problemer med programmet. I fremtiden skal jeg stå for vedligeholdelsen af Analytics Plugin, samt udvikling af nye funktioner i applikationen. Programmet vil i den nærmeste fremtid blive udgivet, og alle brugerne som har registreret sig på analytics.eqatec.com men endnu ikke har fået indrapporteret data, vil modtage en mail med oplysninger om det nye værktøj. Side 65 af 73

66 6.1 Virksomhedens udtale 18 At have Rasmus som specialestuderende hos Linkage har entydigt været en positiv oplevelse. Han opfattes af os alle som dygtig, venlig og meget engageret. Som udvikler har han i praksis deltaget i "EQATEC Analytics" projektet på lige fod med firmaets andre ansatte. I dette speciale-projekt, om udvidelsen "", har han selvstændigt stået for arbejdet beskrevet i rapporten, naturligvis undervejs i samspil og diskussion med os andre udviklere. Projektets ambitionsniveau vurderer vi til at være relativ højt og mener også, at ambitionen er blevet indfriet. Resultatet er en avanceret og velafrundet løsning, som ikke blot på det teoretiske plan, men også i praksis, til fulde indfrier målene fra problemformuleringen og firmaets ønsker, både funktionelt og usabilitymæssigt og tilmed realiseret indenfor den afsatte tid. Godt gået! 18 Virksomhedens udtale skrevet af Richard Flamsholt, senior software udvikler hos Linkage A/S. Side 66 af 73

67 7. Appendiks 7.1 Termer og forkortelser Forkortelse CIL Beskrivelse CIL står for Common Intermediate Language (tidligere hed det MSIL - Microsoft Intermediate Language). CIL er det fælles kodesprog som alle.net programmer bliver kompileret til. CIL sproget bliver kompileret af CLR en, når det skal eksekveres (Just-In-Time). IL kode MSIL Native code IL kode er det samme som CIL kode. MSIL - Microsoft Intermediate Language, som nu bliver kaldt CIL. Native code er CPU specifik kode, dvs. maskinekode der ikke er læselig for mennesker. Består kun at 0 er og 1 er. Fx Klassediagrammer De næste par sider er klassediagrammer over hele systemet. Hver side indeholder et klassediagram som repræsenterer et modul, se side 47 hvor der er beskrevet, hvad de forskellige moduler/projekter gør. Engine: Side 67 af 73

68 Data: Runtime: Side 68 af 73

69 Plugin: Test: Side 69 af 73

70 Add-ins: Pages (under plugin projektet): Side 70 af 73

71 7.3 Korte usecase beskrivelser Her er alle usecase beskrivelserne samlet: Angiv produkt nøgle: Aktør: Analytics bruger (AB) Præ-kondition: Visual Studio indeholder et kompileret program Post-kondition: AB har indtastet produktnøglen han ønsker at knytte programmet til. Scenariet: 1. Denne use case starter når programmet åbner 2. AB indtaster den produktnøgle han ønsker at knytter programmet til. Opret Feature track: Aktør: Analytics bruger (AB) Præ-kondition: Visual Studio indeholder et kompileret program Post-kondition: Featuretrack er oprettet. Scenariet: 1. System finder mulige featuretrack i programmet 2. AB finder ønskede featuretrack 3. AB aktiverer featuretrack 4. AB angiver et track navn Opret Exception track: Aktør: Analytics bruger (AB) Præ-kondition: Visual Studio indeholder et kompileret program Post-kondition: Exceptiontrack er oprettet. Scenariet: 1. System finder mulige exceptiontrack i programmet 2. AB finder exceptiontrack 3. AB aktiverer exceptiontrack Gem opsætning: Aktør: Analytics bruger (AB) Præ-kondition: AB har lavet en ændring i opsætningen Post-kondition: Opsætningen er gemt i et overskueligt format. Scenariet: 1. Use casen starter når AB har lavet en ændring i opsætningen og ønsker at gemme 2. AB trykker på knappen gem 3. Systemet gemmer i et overskueligt format Vis feature track: Aktør: Analytics bruger (AB) Præ-kondition: Visual Studio indeholder et kompileret program Post-kondition: AB ser en liste over featuretrack, som vil blive sporet. Scenariet: Side 71 af 73

72 1. Systemet finder mulige featuretrack i programmet 2. Systemet sammenligner listen med tidligere gemte featuretrack (Track der ønskes sporet) 3. Systemet lister de mulige featuretrack, markere dem som bliver sporet Vis exception track: Aktør: Analytics bruger (AB) Præ-kondition: Visual Studio indeholder et kompileret program Post-kondition: AB ser en liste over exceptiontrack, som vil blive sporet. Scenariet: 1. Systemet finder mulige exceptiontrack i programmet 2. Systemet sammenligner listen med tidligere gemte exceptiontrack (Track der ønskes sporet) 3. Systemet lister de mulige exceptiontrack, markerer dem som bliver sporet Injekt kode / Monitor: Aktør: Build program (BP) Præ-kondition: Visual Studio indeholder et program og Analytics Plugin er aktiv Post-kondition: Deres program indeholder Monitor-modulet. Scenariet: 1. Når brugere kompilerer programmet, bliver der injektet kode i brugerens program. Hvad der bliver injektet i brugerens program afhænger af, hvad opsætningen siger. Indsend fejl: Aktør: Automatisk Præ-kondition: Der er opstået en fejl i Analytics Plugin programmet. Post-kondition: Fejl er rapporteret tilbage til virksomheden. Scenariet: 1. Der opstår en fejl, som sendes til virksomheden. Tanken er at bruge Analytics Monitor-modulet til at fejlrapportere med. Side 72 af 73

73 7.4 Skærmdump 7.5 Kildekode Kildekoden for hele projektet er vedlagt på CD en, samt installations fil. Side 73 af 73

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

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

ViKoSys. Virksomheds Kontakt System

ViKoSys. Virksomheds Kontakt System ViKoSys Virksomheds Kontakt System 1 Hvad er det? Virksomheds Kontakt System er udviklet som et hjælpeværkstøj til iværksættere og andre virksomheder som gerne vil have et værktøj hvor de kan finde og

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

Vistemmernu. Et webbaseret værktøj udviklet af Programdatateket i Skive. E-mail: programdatateket@viauc.dk Web: http://www.programdatateket.

Vistemmernu. Et webbaseret værktøj udviklet af Programdatateket i Skive. E-mail: programdatateket@viauc.dk Web: http://www.programdatateket. Vistemmernu Et webbaseret værktøj udviklet af Programdatateket i Skive E-mail: programdatateket@viauc.dk Web: http://www.programdatateket.dk Kolofon HVAL-vejledning Vistemmernu på HVAL.DK Forfatter: Susanne

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

ITWIN1. Afsluttende projekt. PhotoDays. Benjamin Sørensen (02284) Tomas Stæhr Berg (03539)

ITWIN1. Afsluttende projekt. PhotoDays. Benjamin Sørensen (02284) Tomas Stæhr Berg (03539) ITWIN1 Afsluttende projekt PhotoDays Benjamin Sørensen (02284) Tomas Stæhr Berg (03539) ITWIN1 - AFSLUTTENDE PROJEKT PhotoDays Benjamin Sørensen & Tomas Stæhr Berg 02284 & 03539 1 1 Underskrifter Rapporten

Læs mere

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø EG Data Inform Byggebasen WCF og webservices Jens Karsø 10 Indholdsfortegnelse Byggebasen Services indledning... 2 Målsætning... 2 Valg af teknologier... 3 Kommunikationsmodel for byggebasen... 3 Services.byggebasen.dk...

Læs mere

AO Værktøjer. Installationsvejledning. Version 3. Version 1.0

AO Værktøjer. Installationsvejledning. Version 3. Version 1.0 AO Værktøjer Version 3 Installationsvejledning Version 1.0 28. oktober 2006 AO Værktøjer 3.2 Installationsvejledning Side 2 Indholdsfortegnelse Baggrund...3 Værktøjsvalg...3 Forudsætninger...4 Hvad er.net

Læs mere

1 Ordliste 2. 2 Indledning 3 2.1 Problemstillinger... 3 2.2 Problemformulering... 4 2.3 Problemafgrænsning... 4 2.4 Mål med projektet...

1 Ordliste 2. 2 Indledning 3 2.1 Problemstillinger... 3 2.2 Problemformulering... 4 2.3 Problemafgrænsning... 4 2.4 Mål med projektet... Indhold 1 Ordliste 2 2 Indledning 3 2.1 Problemstillinger.................................. 3 2.2 Problemformulering................................ 4 2.3 Problemafgrænsning................................

Læs mere

INDHOLDSFORTEGNELSE. INDLEDNING... 7 Kristian Langborg-Hansen. KAPITEL ET... 9 I gang med App Inventor. KAPITEL TO...

INDHOLDSFORTEGNELSE. INDLEDNING... 7 Kristian Langborg-Hansen. KAPITEL ET... 9 I gang med App Inventor. KAPITEL TO... INDHOLDSFORTEGNELSE INDLEDNING... 7 Kristian Langborg-Hansen KAPITEL ET... 9 I gang med App Inventor Installation af App Inventor... 10 Trådløs installation... 11 Installation af emulator (Windows)...

Læs mere

MANUAL. Præsentation af Temperaturloggerdata. Version 2.0

MANUAL. Præsentation af Temperaturloggerdata. Version 2.0 MANUAL Præsentation af Temperaturloggerdata Version 2.0 Indholdsfortegnelse FORORD...3 INTRODUKTION...3 KRAV OG FORUDSÆTNINGER...3 INSTALLATION...4 OPSÆTNING...8 PROGRAMOVERBLIK...10 PROGRAMKØRSEL...11

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

Civilstyrelsen. Lex Dania editor 2010. Installationsvejledning. Version: 1.0 2012-03-09

Civilstyrelsen. Lex Dania editor 2010. Installationsvejledning. Version: 1.0 2012-03-09 Installationsvejledning Version: 1.0 2012-03-09 Indhold 1 INDLEDNING... 3 1.1 HVAD ER LEX DANIA EDITOR 2010?... 3 1.2 FORUDSÆTNINGER FOR ANVENDELSE... 3 1.2.1 Hardware... 3 1.2.2 Software... 3 1.3 DISTRIBUTION

Læs mere

Installation og Drift. Aplanner for Windows Systemer Version 8.15.12

Installation og Drift. Aplanner for Windows Systemer Version 8.15.12 Installation og Drift Aplanner for Windows Systemer Version 8.15.12 Aplanner for Windows løsninger Anbefalet driftsopsætning Cloud løsning med database hos PlanAHead Alle brugere, der administrer vagtplaner

Læs mere

Civilstyrelsen. Lex Dania editor. Installationsvejledning. Version: 1.0 2011-09-26

Civilstyrelsen. Lex Dania editor. Installationsvejledning. Version: 1.0 2011-09-26 Installationsvejledning Version: 1.0 2011-09-26 Indhold 1 INDLEDNING... 3 1.1 HVAD ER LEX DANIA EDITOR?... 3 1.2 FORUDSÆTNINGER... 3 1.2.1 Hardware... 3 1.2.2 Software... 3 1.3 POLICIES... 4 2 INSTALLATION

Læs mere

Installation og Drift. Aplanner for Windows Systemer Version 8.15

Installation og Drift. Aplanner for Windows Systemer Version 8.15 Installation og Drift Aplanner for Windows Systemer Version 8.15 Aplanner for Windows løsninger Tekniske forudsætninger Krav vedr. SQL Server SQL Server: SQL Server 2008 Express, SQL Server 2008 R2 eller

Læs mere

Carry it Easy Brugermanual

Carry it Easy Brugermanual Carry it Easy Brugermanual Brugermanual Version 2.0 2004-2006 CoSoSys SRL Carry it Easy Brugermanual Indholdsfortegnelse Indholdsfortegnelse...I 1. Introduktion...1 2. Systemkrav...2 3. Installation...2

Læs mere

OpenTele Server Performance Test Rapport

OpenTele Server Performance Test Rapport OpenTele Server Performance Test Rapport 17. marts 2015 Side 1 af 22 1Indholdsfortegnelse Indholdsfortegnelse Indledning Test forudsætning Beskrivelse af testscenarier Test af OpenTele kliniker web interface

Læs mere

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125 Tietgenskolen - Nørrehus Data warehouse Database for udviklere Thor Harloff Lynggaard DM08125 Juni 2010 Indhold Beskrivelse... 3 Data warehouse... 3 Generelt... 3 Sammenligning... 3 Gode sider ved DW...

Læs mere

ActiveBuilder Brugermanual

ActiveBuilder Brugermanual ActiveBuilder Brugermanual Forfatter: TalkActive I/S Dato: Juni 2004 Version: R. 1.01 Sprog: Dansk Copyright 2004 - Talk Active - all rights reserved. Indhold: 1. INDLEDNING...2 2. QUICK-START...3 3. OPBYGNINGEN

Læs mere

SQL ny front-end

SQL ny front-end SQL 2016 - ny front-end Overblik De største nyheder i SQL Server 2016 finder vi på front-enden, hvor en helt ny og redesignet rapporteringsplatform i Reporting Services er den fremadrettede grundstamme

Læs mere

Indhold. Grundmodul. Teknologisk opbygning og indhold. Mulighed for udbygning. Forretningsmæssig funktionalitet

Indhold. Grundmodul. Teknologisk opbygning og indhold. Mulighed for udbygning. Forretningsmæssig funktionalitet MVJTAS Indhold. Grundmodul Forretningsmæssig funktionalitet Teknologisk opbygning og indhold Mulighed for udbygning 2 Grundmodul Forretningsmæssig funktionalitet MVJ er specialtilpasset rammesystem til

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

Udfordringer og problemstillinger. En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling

Udfordringer og problemstillinger. En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling Java og JEE 1 2 Udfordringer og problemstillinger En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling 3 Generelt om Java og JEE 4 Generelt, I Man undervurderer hvor mange

Læs mere

02101 Indledende Programmering Introduktion til Eclipse

02101 Indledende Programmering Introduktion til Eclipse 02101 Indledende Programmering Introduktion til Eclipse Version 2018 1 Introduktion I dette kursus lægger vi op til at man bruger det integrerede udviklingsmiljø Eclipse. Basalt set er et integreret udviklingsmiljø

Læs mere

få en ny og bedre hjemmeside på få minutter Quick guide Del denne quick guide med alle som har glæde af en ny og bedre hjemmeside

få en ny og bedre hjemmeside på få minutter Quick guide Del denne quick guide med alle som har glæde af en ny og bedre hjemmeside få en ny og bedre hjemmeside på få minutter Quick guide Del denne quick guide med alle som har glæde af en ny og bedre hjemmeside 1 Alle har ret og råd til en professionel hjemmeside på få minutter GoMinisite

Læs mere

Trin for trin guide til Google Analytics

Trin for trin guide til Google Analytics Trin for trin guide til Google Analytics Introduktion #1 Opret bruger #2 Link Google Analytics til din side #3 Opret konto #4 Udfyld informationer #5 Gem sporings id #6 Download WordPress plugin #7 Vent

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

\ \ Computerens Anatomi / /

\ \ Computerens Anatomi / / HTX Roskilde - mat-it-prog, 1.4 \ \ Computerens Anatomi / / Introduktion En PC ( personlige computer ) eller computer er bygget op af forskellige komponenter. Vi vil hermed gennemgå størstedelen af computerens

Læs mere

09/03 2009 Version 1.4 Side 1 af 37

09/03 2009 Version 1.4 Side 1 af 37 Login til DJAS Gå ind på adressen http://www.djas.dk I feltet Brugernavn skrives den e-mail adresse som brugeren er registeret med i systemet. I feltet Password skrives brugerens adgangskode. Ved at sætte

Læs mere

Tillæg til Libris-hæftet: WordPress. Temaredigering og sikkerhed m.m.

Tillæg til Libris-hæftet: WordPress. Temaredigering og sikkerhed m.m. Tillæg til Libris-hæftet: WordPress Temaredigering og sikkerhed m.m. 1. Temaopbygning og -redigering I det trykte hæfte gennemgår jeg, hvordan du installerer temaer i WordPress. Der findes tusindvis af

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

Dygtig.NET / C# udvikler med stor erfaring fra både offentlige organisationer og private virksomheder.

Dygtig.NET / C# udvikler med stor erfaring fra både offentlige organisationer og private virksomheder. .NET UDVIKLER NATIONALITET: DANSK PROFIL Dygtig.NET / C# udvikler med stor erfaring fra både offentlige organisationer og private virksomheder. Stor erfaring omkring databasedesign, datahåndtering og MS

Læs mere

IT Support Guide. Installation af netværksprinter (direkte IP print)

IT Support Guide. Installation af netværksprinter (direkte IP print) IT Support Guide Denne guide er hentet på www.spelling.dk Program: Microsoft Windows Vista Program sprog version: ENG (US) Guide emne: Installation af netværksprinter (direkte IP print) Publikationsnr.:

Læs mere

har jeg hentet nedenstående anmeldelse af et godt program til

har jeg hentet nedenstående anmeldelse af et godt program til Software Fra design af hjemmesider: har jeg hentet nedenstående anmeldelse af et godt program til Wordpress er intet mindre end et genialt program til hjemmesider. For det første er det gratis, og for

Læs mere

Guide - Sådan opretter du en backup

Guide - Sådan opretter du en backup Guide - Varighed: ca. 10 min Denne guide gennemgår hvordan en backup oprettes i Excovery. Guiden vil trinvist lede dig igennem processen og vil undervejs introducere de grundlæggende indstillingsmuligheder.

Læs mere

Der er forsøgt skrevet en lille notits hver gang der er lavet noget, dog kan der være nogle ting som ikke er blevet kommenteret.

Der er forsøgt skrevet en lille notits hver gang der er lavet noget, dog kan der være nogle ting som ikke er blevet kommenteret. Indhold 1 Logbog 2 1.1 Log den 01-02-10.................................. 2 1.2 Log den 02-02-10.................................. 2 1.3 Log den 08-02-10.................................. 2 1.4 Log den

Læs mere

Daglig brug af JitBesked 2.0

Daglig brug af JitBesked 2.0 Daglig brug af JitBesked 2.0 Indholdsfortegnelse Oprettelse af personer (modtagere)...3 Afsendelse af besked...4 Valg af flere modtagere...5 Valg af flere personer der ligger i rækkefølge...5 Valg af flere

Læs mere

vorbasse.dk Redaktørmanual Kentaur

vorbasse.dk Redaktørmanual Kentaur Redaktørmanual Kentaur Indholdsfortegnelse Kapitel 1 - TYPO3 Brugerfladen 3 Log ind 3 Backend 4 Frontend 5 Hvor skal jeg klikke? 5 Gem, gem og vis, gem og luk 6 Kapitel 2 - Sider & menuer 7 Sammenhæng

Læs mere

Det Nye Testamente lyd-app. v. Stefan Lykkehøj Lund

Det Nye Testamente lyd-app. v. Stefan Lykkehøj Lund Det Nye Testamente lyd-app v. Stefan Lykkehøj Lund Indledning For nogle år siden, fik jeg Det Nye Testamente som lydbog på USB. I starten lyttede jeg en del med tiden blev det dog til mindre og mindre.

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

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

Studieordning del 3-2014

Studieordning del 3-2014 Studieordning del 3-2014 Valgfag Datamatiker AP Graduate in Computer Science Version 1.1 Revideret august 2014 Side 0 af 6 del 3 Valgfag 1. Valgfrie uddannelseselementer...2 2. Valgfaget Android...2 3.

Læs mere

GUIDE TIL CLOUD DRIVE

GUIDE TIL CLOUD DRIVE GUIDE TIL CLOUD DRIVE Dette er en guide du kan anvende til nemt at komme effektivt i gang med at anvende Cloud Drive Indholdsfortegnelse 1. Tilgængelige Cloud Drive klienter 2. Guide til Windows klienten

Læs mere

Opsætningsvejledning efter opdatering (ghostning) af hybriderne

Opsætningsvejledning efter opdatering (ghostning) af hybriderne Opsætningsvejledning efter opdatering (ghostning) af hybriderne Indholdsfortegnelse Login til Windows... 2 Aktivering af Office 365... 3 Kom i gang med Office 365 og OneDrive for Business... 4 Opsætning

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

Opsætning af xcon og Logix Controller

Opsætning af xcon og Logix Controller Indholdsfortegnelse Indledning... 2 Opsætning af MSEP... 3 Opsætning af MSEP Gateway... 3 Opsætning af akser... 5 Opsætning af PLC... 9 User-Defined Data Types... Fejl! Bogmærke er ikke defineret. Test

Læs mere

Installation og afvikling

Installation og afvikling 22. maj 2017 Installation og afvikling Indhold 1 Forskellige kendte fejlbeskeder... 2 2 Kan ikke se/finde ønsket netværksdrev ved installation... 3 2.1 Problem... 3 2.2 Løsning... 4 3 Installation/aktivering

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

Brugervejledning for Microstation til OpenSceneGraph konverter

Brugervejledning for Microstation til OpenSceneGraph konverter Brugervejledning for Microstation til OpenSceneGraph konverter - sidste rettelse: 10/06/2005 side 1 Indholdsfortegnelse Kort oversigt over dgn2osg... 3 Systemkrav... 3 Funktionalitet...4 Geometri...4 Materialer...

Læs mere

Indholdsfortegnelse for kapitel 3

Indholdsfortegnelse for kapitel 3 Indholdsfortegnelse for kapitel 3 Kapitel 3 Design............................................................ 2 Database........................................................... 3 ER-diagram.................................................

Læs mere

Online billede filtrering

Online billede filtrering Online billede filtrering Eksamensprojekt 2014 Andreas Lorentzen, klasse 3.4 Roskilde Tekniske Gymnasium Programmering C 09-05-2014 I dette projekt vil jeg demonstrerer en af de mange ting moderne browsere

Læs mere

LiveConnect CDS Installationsvejledning

LiveConnect CDS Installationsvejledning Installationsvejledning Rev. 2 september 2009 Side 1 1. Installation af MediaPlayer 1.1 Installationen består af følgende Anbefalet konfiguration Du skal bruge følgende for at installere Installation af

Læs mere

Viditronic NDVR Quick Guide. Ver. 2.0

Viditronic NDVR Quick Guide. Ver. 2.0 Viditronic NDVR Quick Guide Ver. 2.0 1 Indholdsfortegnelse 1. HOVEDMENU 3 1.1 START 5 1.2 AKTIVITETSINDIKATOR: 7 1.3 INFORMATIONS VINDUE: 7 1.4 PTZ KAMERA KONTROL: 7 1.5 SKÆRMMENU 8 1.5.1 AKTIVER BEVÆGELSE:

Læs mere

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB Det er Web Services, der rejser sig fra støvet efter Dot Com boblens brag. INTRODUKTION Dette dokument beskriver forslag til fire moduler, hvis formål

Læs mere

Fable Kom godt i gang

Fable Kom godt i gang Fable Kom godt i gang Vers. 1.3.1 Opdateret: 29-08-2018 Indholdsfortegnelse 1. Installer programmet 3 2. Pak robotten ud 5 3. I gang med at programmere 6 4. Programmér Fable til at køre fra 90 til -90

Læs mere

Kom godt i gang med I-bogen

Kom godt i gang med I-bogen Kom godt i gang med I-bogen At åbne bogen Det allerførste, du skal gøre, for at kunne arbejde med i-bogen, er at aktivere den. Det gøres ved at oprette en konto på systime.dk og derefter aktivere bogen

Læs mere

Tilslutning med Cisco AnyConnect VPN-klient (Windows) til AARHUS TECH P-net

Tilslutning med Cisco AnyConnect VPN-klient (Windows) til AARHUS TECH P-net 18. november 2011 Vejledning Windows 7 - eklient Opkobling via ADSL eller anden kabelforbindelse til P-net. Tilslutning med Cisco AnyConnect VPN-klient (Windows) til AARHUS TECH P-net Cisco AnyConnect

Læs mere

Indholdsfortegnelse. Hvorfor skal jeg tage backup af min blog? Side 3. Tag backup med UpDraft Side 4. Tag manuelt backup Side 8 - 2 -

Indholdsfortegnelse. Hvorfor skal jeg tage backup af min blog? Side 3. Tag backup med UpDraft Side 4. Tag manuelt backup Side 8 - 2 - - 1 - Indholdsfortegnelse Hvorfor skal jeg tage backup af min blog? Side 3 Tag backup med UpDraft Side 4 Tag manuelt backup Side 8-2 - Hvorfor skal jeg tage backup af min blog? Lige meget om du har opbygget

Læs mere

EasyIQ Opdatering 5.2.3 -> 5.4.0

EasyIQ Opdatering 5.2.3 -> 5.4.0 EasyIQ Opdatering 5.2.3 -> 5.4.0 Kunde: Forfatter: Thomas W. Yde Systemtech A/S Side: 1 af 17 1 Indholdsfortegnelse 2 GENERELT OMKRING FORUDSÆTNINGEN OG OPDATERINGS FORLØBET... 3 2.1 FORUDSÆTNINGER...

Læs mere

Koncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele

Koncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele LEVERANCE 2.1 Koncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele Konceptet beskriver, hvordan koden forvaltes, og hvordan

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

Opdatering af ISOWARE til version 6.1.0

Opdatering af ISOWARE til version 6.1.0 Opdatering af ISOWARE til version 6.1.0 September 2015 Indhold Kontaktoplysninger... 1 VIGTIGT... 2 Opdatering af trejdepartssoftware... 2 Opdatering til version 6.1.0.... 2 1. Backup af databasen... 3

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

ViTre ver. 91 Opdatering fra ScanDis A/S. Instruktion og nyheder i TAL. Automatisk ro Ny forbedret udtalebog. Automatisk ro

ViTre ver. 91 Opdatering fra ScanDis A/S. Instruktion og nyheder i TAL. Automatisk ro Ny forbedret udtalebog. Automatisk ro ViTre ver. 91 Opdatering fra ScanDis A/S Instruktion og nyheder i TAL Automatisk ro Ny forbedret udtalebog Automatisk ro ScanDis A/S ViTre version 91 opdatering Side 1 Ny indstilling af oplæsning med funktionen

Læs mere

Hensigten har været at træne de studerende i at dele dokumenter hvor der er mulighed for inkorporering af alle former for multimodale tekster.

Hensigten har været at træne de studerende i at dele dokumenter hvor der er mulighed for inkorporering af alle former for multimodale tekster. Projekt edidaktik Forsøg med multimodal tekstproduktion På Viden Djurs er der I to klasser blevet gennemført et forsøg med anvendelse af Microsoft Office 365. Hensigten har været at træne de studerende

Læs mere

Lærevejledning. - en introduktion til maskinarkitektur. faraz@butt.dk Faraz Butt mads@danquah.dk Mads Danquah doktor@dyregod.dk Ulf Holm Nielsen

Lærevejledning. - en introduktion til maskinarkitektur. faraz@butt.dk Faraz Butt mads@danquah.dk Mads Danquah doktor@dyregod.dk Ulf Holm Nielsen Lærevejledning - en introduktion til maskinarkitektur faraz@butt.dk Faraz Butt mads@danquah.dk Mads Danquah doktor@dyregod.dk Ulf Holm Nielsen Roskilde Universitetscenter Naturvidenskabelig Basisuddannelse

Læs mere

Worldtrack Tracking Platform BRUGERVEJLEDNING Version 2.01

Worldtrack Tracking Platform BRUGERVEJLEDNING Version 2.01 2018 Worldtrack Tracking Platform BRUGERVEJLEDNING Version 2.01 WORLDTRACK Ejby industrivej 2, 2600 Glostrup Indhold Introduktion... 2 Login... 2 Menu... 2 Overvågning... 3 Bevægelses status... 4 GPS data

Læs mere

Vejledning i installation af chipkortlæsere

Vejledning i installation af chipkortlæsere Vejledning i installation af chipkortlæsere fra Nets P. 1-15 Indholdsfortegnelse Vejledningens formål og indhold... 3 Formål... 3 Indhold... 3 Læsevejledning... 3 Rettigheder... 3 Softwareunderstøttelse

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

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

Test af It-komponent

Test af It-komponent Test af It-komponent I programmeringssproget Java Programmet Login service Elev: Mads Funch Klasse 2.4 Mat, It, Programmering Skole: Roskilde Tekniske Gymnasium HTX Underviser: Karl Dato: 31-08-2016 Side

Læs mere

TEKNISKE FORHOLD VEDR. ADGANG TIL VP.ONLINE. Brugervejledning

TEKNISKE FORHOLD VEDR. ADGANG TIL VP.ONLINE. Brugervejledning TEKNISKE FORHOLD VEDR. ADGANG TIL VP.ONLINE vp.online 2011 01-10-2011 Indholdsfortegnelse 1 PROBLEMER MED AT SE VP.ONLINE... 3 2 BROWSER KONFIGURATION... 6 3 SKRIVEADGANG TIL DREV... 7 4 SESSION TIMEOUT

Læs mere

Manual til AVG Antivirus

Manual til AVG Antivirus Manual til AVG Antivirus Det anbefales, at alle brugere benytter sig af et antivirus-program. Formålet med programmet er at forhindre din computer i at blive smittet med virus. Virus-inficerede computere

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

Indholdsfortegnelse for kapitel 2

Indholdsfortegnelse for kapitel 2 Indholdsfortegnelse for kapitel 2 Kapitel 2. Analyse.......................................................... 2 Analyse af 2.1...................................................... 2 Analysen af Database.................................................

Læs mere

ibooks Author Introduktion

ibooks Author Introduktion ibooks Author Introduktion Velkommen til ibooks Author, som giver dig en fantastisk måde at oprette flotte, interaktive Multi-Touch-bøger til ipad og Mac på. Du kan starte med de flotte skabeloner, der

Læs mere

Microcontroller, Arduino

Microcontroller, Arduino Microcontroller, Arduino Programmerbar elektronik. uc Vi skal lære at lave programmer til uc for at kunne lave el-produkter. Forstå princippet i programmering af en uc og se mulighederne. Programmeringen

Læs mere

EasyRun En løbers bedste ven

EasyRun En løbers bedste ven En løbers bedsteven Anders Arnfast 06525, Martin Søberg 0655, Ken Falk 06504 09 . INDHOLD. Indhold... 2 2. Introduktion... 3 Opsætning... 3 3. System arkitekturdesign... 4 4. Hardware Design... 5 Ethernet

Læs mere

Opsætning af klient til Hosted CRM

Opsætning af klient til Hosted CRM Opsætning af klient til Hosted CRM Dette dokument beskriver, hvordan der oprettes forbindelse til en Hosted CRM løsning hos TDC Hosting A/S Morten Skovgaard, 24. april 2006 1 Indledning... 2 2 Konfiguration

Læs mere

Vejledning, teknik, tips and tricks

Vejledning, teknik, tips and tricks Vejledning, teknik, tips and tricks Indhold 1 AUHRA pålogning og startside... 1 2 Ofte stillede spørgsmål og kendte fejl... 4 2.1 Har din computer adgang til AU s netværk og adm. systemer?... 4 2.2 Kan

Læs mere

DAXIF# - Delegate Automated Xrm Installation Framework. Delegate A/S

DAXIF# - Delegate Automated Xrm Installation Framework. Delegate A/S DAXIF# - Delegate Automated Xrm Installation Framework Delegate A/S Agenda Delegate A/S DAXIF# Kun et programmeringssprog Type stærke script (og selvdokumenterende) filer Unit tests afvikles før assembly

Læs mere

Installation af kalibreringsprogrammet. (BDE versionen)

Installation af kalibreringsprogrammet. (BDE versionen) Installation af kalibreringsprogrammet. (BDE versionen) Installationen består egentlig af to (3) dele: 1 del der vedrører selv programmet med tilhørende filer ( det kan opdateres ) 2 en del der vedrører

Læs mere

Dokumentation. Udbyder : sms1919.dk Service : sms-grupper Applikationer Facebook. : Facebook Integration med sms-grupper.

Dokumentation. Udbyder : sms1919.dk Service : sms-grupper Applikationer Facebook. : Facebook Integration med sms-grupper. Dokumentation Udbyder : sms1919.dk Service : sms-grupper Applikationer Facebook Moduler Påkrævet : Facebook Integration med sms-grupper Version : v1.00 Indholdsfortegnelse Versionshistorik... 3 Målet med

Læs mere

Kom godt i gang med Fable-robotten

Kom godt i gang med Fable-robotten Kom godt i gang med Fable-robotten 1. Først skal du installere programmet på din computer. Gå ind på shaperobotics.com og under support vælger du download: Her vælger du, under PC App om du kører Windows

Læs mere

Dan Rolsted PIT. Side 1

Dan Rolsted PIT. Side 1 Side 1 Side 2 Indledning I denne vejledning vil der vises hvordan Office 365 opsættes på de forskellige platforme, herunder IOS (ipad) og Android (HTC One). Derudover vil der også være vejledning til Windows

Læs mere

OS2faktor. AD FS Connector Vejledning. Version: Date: Author: BSG

OS2faktor. AD FS Connector Vejledning. Version: Date: Author: BSG OS2faktor AD FS Connector Vejledning Version: 1.3.0 Date: 16.04.2019 Author: BSG Indhold 1 Indledning... 3 2 Forudsætninger... 4 2.1 Connector softwaren... 4 2.2 API nøgle... 4 3 Installation... 5 4 Konfiguration...

Læs mere

BESLUTNINGSBARRIEREN ER HØJERE

BESLUTNINGSBARRIEREN ER HØJERE At lave innovation og tænke nye forretningsområder kræver et velfunderet grundlag, der sikre kendskab til målgruppens behov og forretningens strategiske mål. Det er vigtigt at være sin position bevidst

Læs mere

Vejledning Rapportbanken

Vejledning Rapportbanken Vejledning Rapportbanken Version 1.2 (opdateret 18. november 2013) Support KL yder kun begrænset support på anvendelse af Rapportbanken. Brug derfor gruppen KOMHEN 2.0 på Dialogportalen (http://dialog.kl.dk)

Læs mere

Indholdsfortegnelse for kapitel 1

Indholdsfortegnelse for kapitel 1 Indholdsfortegnelse for kapitel 1 Forord.................................................................... 2 Kapitel 1.................................................................. 3 Formål............................................................

Læs mere

Guide til Umbraco CMS

Guide til Umbraco CMS web Guide til Umbraco CMS Indhold Indledning 3 Kompatible browsere 3 Log ind i Umbraco 4 Content-delen 5 Indholdstræet 5 Tilføjelse af en side/sektion 7 Sortering af indhold 12 Galleri 14 Mediebibliotek

Læs mere

Manual til Wordpress. 1. Log ind på din Wordpress-side. Indhold: Sådan opdaterer du din hjemmeside i Wordpress.

Manual til Wordpress. 1. Log ind på din Wordpress-side. Indhold: Sådan opdaterer du din hjemmeside i Wordpress. Manual til Wordpress Sådan opdaterer du din hjemmeside i Wordpress. Dette er en manual til de mest grundlæggende ting, så du selv kan redigere indholdet og lægge nyt på din hjemmeside. Guiden er skrevet

Læs mere

PID2000 Archive Service

PID2000 Archive Service PROLON CONTROL SYSTEMS Herstedvesterstræde 56 DK-2620 Albertslund Danmark Tlf.: (+45) 43620625 Fax: (+45) 43623125 PID2000 Archive Service Bruger vejledning Juni 2002 Denne manual beskriver brugen af softwaren

Læs mere

SYSTEMDOKUMENTATION AF POC

SYSTEMDOKUMENTATION AF POC DIGITALISERINGSSTYRELSEN POC PÅ ORKESTRERINGSKOMPONENTEN SYSTEMDOKUMENTATION AF POC Version: 1.1 Status: Endelig Godkender: Forfatter: Copyright 2019 Netcompany. All rights reserved Dokumenthistorik Version

Læs mere

Arbejde med Regioner Lister, Playlists, og Cutlists i Sound Forge Pro

Arbejde med Regioner Lister, Playlists, og Cutlists i Sound Forge Pro Arbejde med Regioner Lister, Playlists, og Cutlists i Sound Forge Pro Gary Rebholz Du har sikkert allerede ved, at Sound Forge Pro software kan bruges til en imponerende række af audio opgaver. Alt fra

Læs mere