Computerens anatomi. Af Nicklas Jacobsen, Nicolai Godtfredsen Og Jonas Christoffersen

Transkript

1 Computerens anatomi Af Nicklas Jacobsen, Nicolai Godtfredsen Og Jonas Christoffersen

2 Indholdsfortegnelse Indledning...3 Computerens anatomi...3 PSU...3 SLI/Crossfire...3 RAM...4 BUNDKORT...4 Harddisk...4 LYDKORT...4 Projekt ( bruger: nicklas password: mmigsk)...6 Projektplanlægning...6 Opstilling af case, målgruppe og produkttype...7 Case...7 Afsender...7 Målgruppe...7 Målgruppeanalyse...7 Produktkrav og testspecifikationer...8 Produktkrav...8 Testspecifikationer...9 Designplanlægning...10 Implementering...13 Forberedning...13 Brugersystem:...14 User_check.php...14 Login.php...16 HTML og CSS...17 Grafisk design...19 Banner...19 Artikel bedømmelses stjerner...23 Prototypen...28 Lukket brugersystem...28 SQL injektion sikret...28 Websitet skal overholder HTML standarterne...29 Websitet skal kunne vises i de mest gængse browsere...29

3 Indledning Vi fik stillet opgaven at lave en beskrivelse af delene i en computer, eller sagt på en anden måde forklare computerens anatomi. Derudover skulle vi lave et produkt til at formidle vores viden om computerens anatomi. Denne viden har vi fået via ressearch og erfaringer. Vi fik muligheden for at skille en computer ad selv, dette nåede vi dog ikke at gennemføre. Rapporten er inddelt på den måde at, computerens anatomi først vil blive forklaret, hvorefter dokumentationen for produktet beskrives. Computerens anatomi PSU Computerens strømforsyning er en transformator der konverterer de 220 V. fra stikkontakten til lavere volt som bruges til de forskellige dele i computeren. Strømforsyningen i en computer hedder en PSU, hvilke står for Power Supply Unit. PSU'en ses som regel som en mellemstor kasse i øverste del af kabinettet. Da der er flere dele i en computer der skal havde strøm hver for sig, og ved forskellige volt, har PSU'er flere forskellige slags ledninger. 2 forskellige ledninger til bundkortet, to forskellige ledninger til diskdrev til henholdsvis SATA drev og ATA drev, evt. ledninger til floppydisk og grafikkort. PSU'er kan have forskellige maks watt forbrug, hvilke kommer an på computerens samlede strømforbrug, dog ligger de flest PSU'er på omkring w. SLI/Crossfire SLI (Scalable Link Interface) og Crossfire er henholdsvis Nvidia og ATI's navn for multi-gpu løsning. Disse teknologier forbinder flere grafikkort sammen, for at øge ydeevnen. Grafikkortene bliver forbundet via. et kabel, som man kalder en bridge.hver af grafikkortene skal være tilsluttet til et PCI-E stik. Med Nvidias teknologi kræver det at begge grafikkort er samme model. Hvor med Crossfire, kræver det at de individuelle grafikkort er beregnet til at sidde som f.eks nr. 1, nr. 2 osv.

4 RAM RAM står for Random Access Memory, og er computerens arbejdshukommelse. Det er i RAM'en alle variabler og midlertidige ting opbevares. Hvis man f.eks. har et program der regner noget ud, kan man skrive et midlertidigt resultat ned i hukommelsen, for så at hente, og bruge det senere. Der er 2 slags RAM: SRAM og DRAM Dynamisk RAM er, hvor den enekelte bit huskes af en kondensator, som bliver ladt op. Det betyder at man er nødt til hele tiden at opdatere rammen fordi kondensatoren taber spændingen, og kun kan holde en værdi i få millisekunder. DRAM er den mest almindelige type RAM, idet det er en meget billig og effektiv måde at 'opbevare' variable. Statisk RAM er, hvor en bit bliver skrevet ned i en lille flip-flip, som virker mekanisk. Det, at den virker mekanisk gør at der ikke hele tiden skal læses værdier ned i den, og på den måde sparer man det kredsløb, der hele tiden skriver værdier til DRAM'en. Til gengæld kræver det en del ressourcer, og er en ret dyr form for RAM. BUNDKORT Bundkortet i computeren er det kort, hvorpå alting er monteret, f.eks. CPU'en. Derfra er der ledninger til grafikkort, cd-rom drev, diskette-drev og strømforsyning. På de fleste bundkort er der indbygget nogle simple dele f. eks. grafikkort, lydkort ol. De dele der er indbygget på bundkortet er ofte ikke særligt avancerede, og kun til for at man kan tilslutte eksempelvis en skærm. Det betyder, at man kikke kan lave avancerede 3D-renderinger, men hvis den bare skal stå og vise lidt tekst er det helt i top. F.eks. hvis der skal stå en skærm og bare vise status af et par servere. Harddisk Harddisken er computerens hukommelse, det er der hvor alt på computeren er lageret. Den består af 1-6 magnetiske plader og et læsehoved. Pladerne er lavet af et ikke magnetisk materialle, som er overtrukket med magnetisk materialle. Den fungere på den måde at der er et læse/skrivehoved, som læser og skriver alt data på harddisken. Harddisken er inddelt i nogle små felter på skiven. I feltet kan der skrives et 1 eller et 0, og på den måde kan man gemme binære informationer. Harddisken kører rundt ved forskellige hastigheder, som regel 5400 og 7600 rpm (rounds per minute). Den plads som harddisken kan indeholde kan varierer meget, de fleste nu om dage, på de nye computere, indeholder 120 GB til 1 TB. LYDKORT Som navnet siger er lydkortet, kortet der laver lyd. Et 'simpelt' lydkort vil i de fleste tilfælde dække

5 behovet til lyd fra computeren. Der vil ofte blive brugt en ekstern forstærker hvis der er brug for mere lyd til f.eks. en fest. Der kan dog være lidt mere avancerede lykort. Eksempelvis et lydkort med 5.1 Surround. Det skal holde styr på flere højtalere og glere kanaler, så det skal også kunne noget mere.

6 Projekt ( bruger: nicklas password: mmigsk) Projektplanlægning Vi startede ud med at lave en kronologisk rækkefølge, af de ting der indgår i projektprocessen. Dette lavede vi som en figur som var nem at læse, og derved nem at holde sig til. Figuren kan ses nedenfor: Opstilling af case og målgruppe Research af computeren anatomi Beslutning af produkttype Beslutning af produktkrav Opstilling af produktets testspecifikationer Designplanlægning af produkt. (skitsering osv.) Produkt implementering Test af prototype Implementere rettelser

7 Opstilling af case, målgruppe og produkttype Case HardwareSupport A/S har ikke været i stand til at finde medarbejdere med nok computer kompetencer til at udføre support opgaverne fra deres kunder. Derfor har de valgt at hyre folk som kun har generel interesse for IT, og derefter uddanne dem. I den anledning har de valgt at lave et website, hvor man kan uddanne sig selv ved at læse faste artikler om hardware, ligge sin egne artikler op til andre og teste sig selv ved forskellige test. Afsender HardwareSupport A/S's supportafdeling Målgruppe Nylig supportansatte med generel computer interesse. Alderen ligger mellem 20 til 30 år. Størstedelen går på en videregående uddannelse. Målgruppeanalyse Da størstedelen og den nemmest tilgænglige information omkring computere ligger på nettet, må man antage at de computer interesseret er vant til at læse længere artikler og guides. Derudover er en stor del af målgruppen under uddannelse hvilke også gør at man må antage det samme som forrige konklusion. Man bliver nød til at gå ud fra at vores målgruppe ikke ved noget om computeres anatomi, da vi ikke kender vores målgruppes start kompetencer.

8 Produktkrav og testspecifikationer Produktkrav Vi har lavet to gange produktkrav. Krav for den første prototype og krav for det endelige produkt. Grunden til at vi har valgt at gøre det på denne måde, er fordi vi så har en liste over de ting vi kan teste af på vores prototype og en anden liste som vi videre kan stræbe efter at nå. Produktkravende for det endelige produkt er listet nedenfor: Designkrav Websitet skal være overskueligt og nemt at bruge. Websitet skal være rart at se på. Interaktionskrav Websitet skal have en artikel søgemaskine. Den skal være effektiv (dvs. hurtig). Man skal kunne vælge om man kun vil have faste artikler, skrevet af brugerne eller begge. Mulighed for at highlighte søgeord(et/erne). Mulighed for stemmevudering af brugerskrevet artikler. Mulighed for at kommentere brugeskrevet artikler. Programmeringskrav Websitet skal overholde HTML standarterne. Websitet skal være nemt at vedligeholde (overskuelige kode). Websitet skal kunne vises i de mest gængse browsere. Sikkerhedskrav Lukket brugersystem. SQL injektion sikret. Listen nedenfor er produktkrav til prototypen. Denne liste er dannet ud fra hvad vi mener er vigtigst og hvad der er nemmest at teste af. Sikkerhedskrav Lukket brugersystem. SQL injektion sikret. Programmeringskrav Websitet skal overholde HTML standarterne. Websitet skal kunne vises i de mest gængse browsere.

9 Testspecifikationer Vi har udarbejdet følgende metoder til at teste hvorvidt vores prototype overholde de satte krav. Lukket brugersystem. Der testes af hvorvidt man kan se index filen ud at være logget ind i systemet. Dette gøres mere præcist, ved at skrive adressen til index.php filen direkte ind i adressebaren i browseren. SQL injektion sikret. Der skrives forskellige sql koder ind i login og password tekstboxen på login-siden, med det formål at bryde login systemet. Websitet skal overholder HTML standarterne. Websitet testes af i W3C Markup Validation. Websitet skal kunne vises i de mest gængse browsere. Websitet testes af i henholdvis firefox 3, opera og internet explore 8. For at se om websitet bliver vist som hentænkt.

10 Designplanlægning Vi valgte at designe vores fiktive firmas logo. Dette gjorde vi da vi mente at det giver mest mening at give firmaet en form for profil, før vi lavede resten af websitet. Vi kom frem til følgende skitse.

11 Herefter designede vi login-siden. Vi mente at login-siden skulle være så simpel som overhovedet mulig men samtidig være professionel at se på. Derudover skulle brugeren ikke være i tvivl om hvad man skal gøre. Vi kom frem til følgende skitse.

12 Til sidst skitserede vi hvordan vi gerne vil havde selve websitet til at se ud efter man var logget ind. Da der skulle være en del funktioner valgte vi at bruge en del af skærmpladsen på en menu, som skulle indeholde disse funktioner. Derudover tegnede vi ind hvordan vi gerne vil havde artikel systemet til at se ud. Vi ente ud med følgende skitse.

13 Implementering Forberedning Vi valgte at dele opgaven op, så vi hver især lavet en del af hjemmesiden. Dette besluttet vi af hovedsageligt af tre grunde; 1. Vi vil gerne undgå at en sad og lavede noget mens en eller to af de andre bare sad og kiggede på. 2. Vi syntes at det var bedst hvis man havde et fokuspunkt så man kunne koncentrere sig om det man lavede. 3. Vi kunne udnytte vores evner bedst ved at dele det op på den måde at man lavede det man havde mest lyst til. Helt konkret lavede en lille liste med opgave som vi satte navne, listen kan ses nedenfor: *** Endnu ikke besluttet Opgave Navn Login system Nicklas Artikel system *** Grafisk Design Nicolai Bruger redigeringsystem *** Opsætning af basal html og css Jonas

14 Brugersystem: User_check.php User_check.php er filen, der logger folk ind og tjekker, om de er logget ind. Hvis man poster et brugernavn og password til den, vil den prøve at logge folk på den postede bruger. Derudover kan man inkludere den på de sider, der kun skal kunne ses af brugere. Hvis man inkluderer den på en side, vil den automatisk tjekke, om man er logget ind. Hvis dette ikke er tilfældet, vil den omdirigere forbindelsen til login.php (som bliver beskrevet senere under overskriften 'Login.php'). Selve udviklingen af denne fil var meget uplanlagt. Det eneste planlagte var, at filen skulle styre hele login proceduren. Derudover skulle alle de sider, der inkluderer den, blive låst, hvis man ikke er logget ind. Vi startede med at lave en if-sætning, der tjekker, om der er sat et brugernavn og password. Denne kode tjekker, hvorvidt der er sat en såkaldt 'session' med brugernavn og password. Hvis der er det, vil den gemme dem i en variable af samme navn. Hvis der ikke er sat en sådan session, vil koden sende brugeren over på login.php siden. Koden tjekker dog kun, om der er sat et brugernavn og password, men ikke hvorvidt brugeren eksisterer og/eller passwordet er rigtigt. Vi tilgår en mysql-database for at kunne holde styr på brugernavne og passwords. Så før vi kunne begynde på at tjekke databasen for rigtige brugere, blev vi nødt til at konstruere en kode, som opretter forbindelse til vores database. Koden ser således ud:

15 I den første kodelinje oprettes forbindelse til adressen localhost med et brugernavn og password til databasen. Næste kodelinje fortæller databasen, at vi vil vælge at arbejde i databasen web. Nu, hvor vi havde oprettet forbindelse til vores database, kunne vi konstruere en anden kode, der foretager et tjek på, om brugeren er logget ind med et gyldigt brugernavn og password. Den første linje siger til databasen: Giv mig den række fra tabellen HS_Users,hvor brugernavnet er identisk med det, som brugeren er logget ind som, og hvor password er identisk med det, brugeren har brugt som password. Hvis den ikke kan finde en række, der passe, giver den ingenting tilbage. Næste linje kopierer resultatet fra databasen ind i en variable, som vi kan bruge i php. Tredje linje er en if-sætning, der tjekker, om der kom noget resultat fra databasen. Hvis det ikke er tilfældet, betyder det, at det enten var et forkert brugernavn og/eller password. I det tilfælde sendes brugeren tilbage til login-siden med en fejlmeddelelse. Da vi måske gerne vil lave et brugersystem, som kan skelne mellem administratorer og almindelige brugere, sørgede vi for at lave et niveaudelt system. I det niveaudelte system kan brugeren enten have værdien 0 eller 1, hvor 0 er almindelig bruger og 1 er administrator. Derfor tilføjede vi disse to linjer kode til sidst i filen. Ovenstående kode bliver kun eksekveret, såfremt brugeren er logget ind med gyldig brugernavn og password. 1. linje kode hiver level -værdien ud af databasen og kopierer det ind i en session variable. Næste linje kode kopierer værdien fra den nylige oprettede session variable ind i en normal variable, til evt. senere brug. Da vi var nået hertil, kom vi i tanke om, at filen kun kunne tjekke, om brugeren var logget ind med det rigtige brugernavn og password. Men den kunne ikke logger folk ind. Derfor tilføjede vi denne linje kode til toppen af filen:

16 Den først linje kode tjekker, hvorvidt post variablen user er sat. Hvis den er det, skyldes det, at en bruger prøver på at logge ind. De to næste linje koder tager så det brugernavn og password, brugeren prøver at logge ind med, og sætter dem i hver sin session variabel. Disse session variabler vil senere blive tjekket af den forrige kode med henblik på gyldigheden af login'et. Som konklusion på denne forklaring af filen kan man sige, at den er lidt omvendt af, hvad man plejer at gøre. Ved de fleste andre login-systemer plejer man at tjekke, hvorvidt brugeren er logget ind. Denne fil tjekker hele tiden for det modsatte, det vil sige om man ikke er. Dette implicerer at hvis php koden bliver læst til ende uden at brugere omdirigeres til login-siden, betyder det at brugeren er logget korrekt ind. Sagt på en anden måde, så handler koden ikke, medmindre den opdager, at man ikke er logget ind. Dette system, mener vi, er meget overskueligt i forhold til mange andre login-systemer, og derved nemt at vedligeholde. Login.php Login.php er sådan set bare en fil, der giver brugeren to tekst-bokse og en knap, hvor vedkommende kan logge sig ind. Når brugeren trykker login, vil den sende oplysningerne til User_check.php. Koden kan ses nedenfor: Udover den normale html-kode, er der - for at give brugeren noget visuelt - tilføjet php-kode på linje 15 og linje 20. Php-koden på linje 15 modtager et evt. brugernavn, som brugeren har skrevet før, i tilfælde af at brugeren har skrevet forkert password. Linje 20 skriver en fejlmeddelelse ud, hvis brugeren har skrevet forkert brugernavn eller password. Dette er dog ikke noget denne fil tjekker, men noget der tjekkes af User_check.php, som aktiverer linje 20, hvis der er sendt et forkert brugernavn eller password til User_check.php.

17 HTML og CSS Når man ser på det første billede er der en masse HTML kode. Den øverste linje er en DOCTYPE, og den fortæller browseren hvordan den skal vise på skærmen. Den næste er et HTML-tag og den fortæller browseren at nu starter websiden. Det næste tag vi har er et HEAD-tag. I HEAD'et står der en masse data som ikke bliver brugt grafisk, men som alligevel er meget vigtige for opbygningen af siden. Nu kommer der et LINK-tag. LINK-tags kan fortælle en masse forskellige ting, som vi ser senere, men lige nu fortæller den browseren at vi har et favicon, og hvor det ligger. Et favicon er et lille logo for siden. Det er det logo man kan se når man gemmer et link til Favorites. Det er også derfra den har fået sit navn: FAVorites ICON Nu kommer der et META-tag. Også META-tag kan fortælle mange ting til browseren, men her er det brugt til at fortælle browseren, at siden er formatteret i UTF-8. Her er igen et LINK-tag, men denne gang fortæller den, at der bliver brugt en CSS-fil, og hvor den ligger. Det næste der kommer er et TITLE-tag. Det sætter overskriften på websiden. Alle tags der hedder noget i stil med '</TAG>' er lukke-tags. Hvis man ikke havde dem ville browseren ikke vide hvornår den skulle stoppe med at læse TITLE-tag'et, og derfor ville overskriften være indholdet af siden. </HEAD> lukker for HEAD-sektionen. Alt der i BODY-tag'et bliver visuelt på skærmen. Nu kommer der et DIV-tag. Et DIV-tag bliver ikke vist på skærmen. Det er mere som en slags kasse man kan bruge til at holde orden på siden, og man kan gave denne kasse en specifik egenskab f.eks. Kan man sige at alle elementer i kassen har rød baggrund. Når man giver et tag 'id= Navn ' er de for at give den et navn eller id. Det kan man senere bruge når man vil give dem egenskaber i CSS. Efter endnu en DIV kommer der to IMG-tags. De fortæller, at nu vil browseren indsætte et billede. 'src' fortæller hvor billedet ligger, og 'alt' er en tekst der bliver vist hvis der ikke bliver vist et billede.

18 Nu kigger vi på vores CSS-fil. Når det der står: '#Navn' betyder det, at alle de elementer der har id 'Navn' får alle de egenskaber der står i de efterfølgende krøllede paranteser. 'background-color: #123456' Sætter en farve for det givne element. '#123456' er hex, hvor de to første tegn står for rød, de næste grøn og de sidste blå. Da det er i hex går talrækken op til F; 0-F. Den næste, 'height' sætter højden på et element. 'background: #FFFFFF url('gfx/fadeimage.png') repeat-x scroll top left' Sætter baggrundsfarven til hvid, og så tager den et billere 'FadeImage.png' og gentager vandret. Det er 'repeat-x' der sørger for det. 'scroll' Gør at den bliver sat fast på siden. 'top left' er den position hvor baggrunden skal starte.

19 Grafisk design Banner Her er vores skitse for banneret: Vi besluttede af bruge teksttypen Osaka til logoet, men da det bliver lavet til et billede, er det ligegyldigt om teksten understøttes af browser. Så vi startede med at lave et billede med teksten HardwareSupport A/S, med gennemsigtig baggrund. Billedes størrelse er 300 px i bredde og 150 px i højden.

20 Derefter eksporterede vi billedet til png, da det er understøttet af alle browsere. Vi har valgt at baggrunden på logoet, skal være orange, som fader over i en grå. Så lavede vi et billede med de farver, på 2 px bredde og 150 px højde. Vi laver det i 2 px bredde da vi derefter kan duplikere det i css. Dette gør vi pga. at vi altid vil have tekst og logo i samme størrelse, så det kun er mellemrummet imellem de to ting, som ændre størrelse. Det gør vi ved at først at lave et nyt billede i programmet Gimp, først så fylder vi hele billedet med den orange farve, ved hjælp af udfyldningsværktøjet. Derefter laver vi en fade nedad, ved hjælp af blandingsværktøjet i Gimp. Vi har taget et billede af en printplade, som hvor vi derefter overførte til computeren. Vi tog det derefter ind i Gimp, for at kunne redigere i billedet.

21 Derefter roterede vi og flyttede billedet, ved hjælp af gimps flytteværktøj og roteringsværktøj, for at kunne få vores udtænkte logo.

22 Derefter skulle vi have den halve cirkel i vores logo, som vi havde udtænkt. Det gjorde vi ved at bruge værktøjet ellipsemarking. Hvor vi derefter slettede det markerede, ved hjælp af funktionen ryd. Så eksporterede vi billedet til en.png fil, da alle browsere understøtter det. Så fik vores færdige logo.

23 Artikel bedømmelses stjerner Vi har besluttet os for at man skal kunne vurdere artikler. Til det skulle det vurderes i stjerne, dertil skulle vi lave 2 slags stjerner, en der er grå for tom og en der er guld for fyldt. Stjernerne blev lavet i programmet Gimp. Vi startede med at lave en trekant markering, som skal udgøre halvdelen af stjernen. Derefter brugte vi udfyldningsværktøjet til at udfylde det med en farve.

24 Så skulle vi have den anden halvdel af stjernen, det gjorde vi, som på samme måde som vi lavede den første halvdel på, ved at markere en trekant. Derefter brugte vi udfyldningsværktøjet, til at udfylde den sidste halvdel med farve.

25 Så har vi en stjerne, men som ser kedelig ud. For at få lidt mere liv i den, gør vi det at vi markere halvdelen af den, på skrå. Så bruger vi udfyldningsværktøjet, til at udfylde det markerede med en farve.

26 Så har vi slutproduktet af den første stjerne, som skal stå for at man ikke har stemt på det antal stjerner. Så skulle vi have en stjerne som illustrer at du vil vurdere det. For at vi ikke skulle lave hele proceduren om, gjorde vi det at vi markere de forskellige farve og udfyldte det med to andre farver.

27 Prototypen Lukket brugersystem. Som nævnt tidligere i denne rapport, testes dette ved at skrive adressen til index filen direkte i adressebaren i browseren. I dette forsøg er firefox 3 linux version brugt. Hvis dette gøres inden man har logget ind, og derved ikke sat nogen gyldig session med brugernavn og password vil man blive stillet om til login.php, se billedet nedenfor. Dette ser vi som bestået i forhold til vores testspecifikationer. SQL injektion sikret. Ved denne test, testet vi sikkerheden med SQL injektionen '; or 1=1 i password feltet og i brugernavn feltet. Hvis dette gøre fås ikke nogle serverfejl, men tilgengæld en valid fejl om forkert brugernavn eller password.

28 Dette ser vi som bestået i forhold til vores testspecifikationer. Websitet skal overholder HTML standarterne. Dette krav blev testet af ved at bruge W3C html valiator. Vi startede ud med at validere login.php filen. Den havde desværre nogle fejl og bestod derfor ikke testen. Vi har haft nogle problemer med at validere index.php filen, da login systemet blokere for W3C. Derudover var det ikke muligt at uploade den, da den også består af php kode. Vi ser ikke denne test som bestået, da login.php ikke bestod testen. Websitet skal kunne vises i de mest gængse browsere. Vi har testet hjemmesiden af i både firefox 3, opera og Internet explore 8. I alle tre browsere bliver websitet vist som det skal. Dette vil sige at alle browsere fortolker html koden efter hensigten. Vi ser denne test som bestået.