Abstract. Webbsida för lagring av alumner i en databas. Website containing a database for the storage of alumni contact information.

Transkript

1 Abstract Webbsida för lagring av alumner i en databas Website containing a database for the storage of alumni contact information Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box Uppsala Telefon: Telefax: Hemsida: Joel Sundström In supporting an efficient way to gather and develop contact information for the Uppsala Association of Technology Physicist alumni, it is crucial to have in place an adequate and user-friendly system allowing the continuous collection and storage of such contact information. This can achieved by the creation of a website where alumni can enter information about themselves and where such information in turn is stored in a database. A database containing relevant tables has been developed in MySQL. In utilizing phpmyadmin, the programming language PHP and Web Server Apache, a fully functional website to be included on the Association's website has been created. Handledare: Ingen handledare Ämnesgranskare: Roland Bol Examinator: Urban Lundin ISSN: , TVE

2 TVE Examensarbete 15 hp Juni 2011 Webbsida för lagring av alumner i en databas Självständigt arbete i teknisk fysik Joel Sundström

3 Institutionen för teknikvetenskaper Webbsida för lagring av alumner i en databas Självständigt arbete i Teknisk fysik Vårterminen 2011 Uppsala Författare: Joel Sundström

4 Sammanfattning För att samla och utveckla kontakterna till Föreningen Uppsala Tekniska Fysikers alumner är det avgörande att på ett effektivt och användarvänligt sätt kontinuerligt samla och lagra alumnernas, personer som har en examen från teknisk fysik, personuppgifter. Detta kan åstadkommas genom att konstruera en webbsida där alumner kan skriva in information om sig själva och där informationen lagras i en databas. En databas med relevanta tabeller arbetades fram i MySQL. Användandet av phpmyadmin, programmeringsspråket php och webbservern Apache resulterade i en fullt funktionell webbsida som kommer att användas på föreningens hemsida. 2

5 Innehållsförteckning 1. Inledning Bakgrund Syfte Teori Databas Design av databas SQL Normalformer Från ER till tabeller Kopplingen mellan de olika delarna i systemet Metod Verktyg XAMPP Apache MySQL PHP Inbyggda metoder phpmyadmin Implementation Designen av databasen Resulterande tabeller i databasen Design av webbsidan Metoder och klasser till webbsidan Klasser och metoder Diskussion Åtgärder innan lansering Utvecklingsmöjligheter Referenser Appendix

6 1. Inledning 1.1 Bakgrund Föreningen Uppsala Tekniska Fysiker har under en längre tid haft en alumnverksamhet som inte har levt upp till de mål som föreningen har satt upp för denna verksamhet. Anledningen till detta har till största del varit att hitta de alumner som tagit examen från civilingenjörsprogrammet Teknisk fysik och samla information om dem på ett och samma ställe. Föreningens alumnverksamhet har som mål att bland annat anordna alumnmiddagar där gamla studenter kan träffas och utbyta erfarenheter. En väl fungerande alumnverksamhet är viktigt för föreningen då alumnerna utgör en värdefull resurs för programmet och således även studenterna. 1.2 Syfte Målet med detta projektarbete har varit att konstruera ett effektivt sätt att samla alla alumner på samma ställe och att detta ska kunna ske på ett långsiktigt hållbart sätt. För att erhålla detta smidiga lagringssätt har syftet varit att databasen och tillhörande interface ska vara designat på ett sådant sätt att alumnerna ska kunna logga in med mailadress och valfritt lösenord. Syftet med detta har varit att man på ett enkelt sätt ska kunna ändra sina personliga uppgifter när man till exempel flyttar eller byter jobb. 4

7 2. Teori 2.1 Databas Design av databas Med databas menas ofta en samling data som hör ihop på något sätt och där data inte försvinner även när datorn stängs av eller programmet avslutas. 1 När något från verkligheten ska beskrivas i en databas rekommenderas det att man börjar med att skapa en översiktsbild av hur verkligheten ser ut. Detta görs lämpligast genom en ERmodell, entitet-relationsmodell, där verkligheten beskrivs på ett schematiskt sätt. Detta leder till en bättre design än om tabellerna skulle bestämmas från början. Det som bestämmer vilken typ av data som kan lagras i databasen är schemat. Schemat kan ses som en tabell där kolumnerna bestämmer typen av data som kan lagras. Schemats utseende avgörs av den datamodell som används. Den konceptuella datamodellen skapar en datamodell som beskriver hur verkligheten ser ut, resultatet blir då ett konceptuellt schema som illustreras med ett ER-diagram, se figur 1. Figur 1: Förenklad bild över de olika delarna i ett ER-diagram. Ett ER-diagram är en skiss över den information som ska lagras i databasen, entiteter, och hur dessa förhåller sig till varandra, relationer. Relationer kan ses som samband mellan entiteter där entiteter ofta är namn på saker och ting, till exempel Alumn, Företag och Land. Attributen talar om vilken typ av information som finns om entiteten, till exempel attributen förnamn och efternamn till entiteten Alumn. För att det ER-diagram som gjorts ska kunna implementeras i en dator måste skissen beskrivas med hjälp av någon implementationsmodell. 1 Thomas Padron-McCarthey, Tore Risch, Databasteknik, sid 8 5

8 Den vanligaste implementationsmodellen är relationsmodellen där ER-diagrammet översätts till tabeller där data lagras. 2 En databas där data lagras och organiseras i tabeller, relationer, kallas relationsdatabas och den som använts i detta projekt är MySQL SQL SQL, Structured Query Language, används för att kommunicera med databasen genom att bland annat hämta, sätta in, uppdatera och radera data i en databas. Detta görs genom att ställa frågor till databasen som då returnerar ett svar i form av en tabell Normalformer När en databas ska designas är det viktigt att undvika en dålig design. Med dålig design menas att samma data lagras på mer än ett ställe och att vissa typer av data inte lagras alls. För att undvika en dålig design utnyttjas normalformer. Det finns fyra olika typer av normalformer; första normalformen, andra normalformen, tredje normalformen och Boyce- Codds normalform. Innan de olika typerna av normalformer kan förklaras närmare måste en del begrepp presenteras. 4 Funktionellt beroende: Funktionellt beroende kan beskrivas genom att analysera attribut A och attribut B. Om A som kan innehålla flera attribut entydigt bestämmer värdet på attribut B sägs B vara funktionellt beroende av A. Fullständigt funktionellt beroende: Om samma exempel som ovan används för att beskriva fullständigt funktionellt beroende sägs B vara fullständigt funktionellt beroende av A om det ur A inte går att ta bort några attribut för att B ska vara funktionellt beroende av A. Primärnyckel: En primärnyckel är en eller flera kolumner i en tabell som har ett unikt värde för varje rad. 2 Ibid, sid 18 3 Thomas Padron-McCarthey, Tore Risch, Databasteknik, s 7 ff 4 Ibid, s 217 ff 6

9 Kandidatnyckel: Då en tabell har flera olika kandidater till primärnyckel sägs tabellen ha flera kandidatnycklar. En kandidatnyckel är en kolumn eller flera kolumner i en tabell som entydigt pekar ut varje rad i tabellen. Icke-nyckel attribut: Ett attribut som inte ingår i någon kandidatnyckel. Första normalformen, 1NF Första normalformen säger att varje kolumn ska innehålla atomära värden vilket innebär att det endast får förekomma ett värde per ruta. Till exempel är inte Nils Nilsson ett atomärt värde men Nils är det. Andra normalformen, 2NF Tabellen ska ha första normalform men för att det ska vara andra normalformen måste även varje icke-nyckelattribut vara fullständigt funktionellt beroende av varje kandidatnyckel. Tredje normalformen, 3NF Tabellen ska ha andra normalformen men det får inte förekomma något fullständigt funktionellt beroende mellan attribut utanför någon av kandidatnycklarna. Boyce-Codds normalform, BCNF Tabellen ska ha första normalformen samt att determinanten, det eller de attribut som bestämmer ett annat attribut, ska vara en kandidatnyckel Från ER till tabeller Det finns bestämda regler för hur översättningen från ER-modellen till relationsmodellen ska ske. En vanlig entitetstyp med tillhörande attribut översätts till en tabell där attributen utgör kolumner i denna tabell och där primärnyckeln i tabellen blir entitetstypens nyckel. En sambandstyp som har ett N:M-förhållande och tillhörande attribut blir en tabell där kolumnerna består av attributen samt primärnycklarna från de entiteter som sammankopplas 5 Thomas Padron-McCarthey, Tore Risch, Databasteknik, s 217 ff 7

10 genom sambandstypen. Primärnyckeln i tabellen är sammansatt av primärnyckeln från respektive entitet. Om en sambandstyp med ett N:1-förhållande används i ER-modellen kommer entiteten på N- sidan att erhålla ett referensattribut i form av primärnyckeln från den andra entiteten. Det vill säga att primärnyckeln från entiteten på 1-sidan kommer bli en kolumn i tabellen för N-sidans entitet Kopplingen mellan de olika delarna i systemet Då en webbsida programmeras där flera olika program används är det viktigt att förstå kommunikationen mellan programmen. För att den information som skrivs på webbsidan ska kunna sparas i databasen krävs en mellanhand som hämtar informationen och adderar den i databasen, se figur 2. I detta fall är det programmeringsspråket php som fungerar som länken mellan databasen och webbsidan. PhpMyadmin används för att skapa tabeller i databasen och kommunikationen sker med hjälp av php. PhpMyadmin utnyttjas även för att kontrollera att den information som läggs in eller uppdateras i tabellerna stämmer överens med tanken bakom ändringen eller adderingen av information. Figur 2: Schematisk bild över kommunikationen mellan de olika delarna i systemet. 3. Metod Kravställaren för detta arbete har varit Föreningen Uppsala Tekniska Fysiker och genom diskussion med styrelsen i denna förening bestämdes utformningen av arbetet. Med anledning av att endast en del av föreningens hemsida programmeras i detta arbete utnyttjades den 6 Ibid, s 85 ff 8

11 programmeringskunskap som fanns hos de personer som gjort andra delar av hemsidan. Förutom att dessa personers kompetens utnyttjats har även litteratur och internet använts för att hitta information, se Referenser. För att användarvänligheten ska vara tillfredställande kommer sidan att felsökas av mig men även av personer som inte varit insatta i projektet. Webbsidan kommer även att granskas av de personer som programmerat föreningens hemsida för att den programmeringskod som skrivits ska följa de riktlinjer som föreningen satt upp gällande hemsidan. Anledningen till att webbsidan kommer granskas av personer med varierande inblandning i projektet beror på att olika typer av fel kommer att detekteras och således kommer risken för fel vid lansering minimeras. Efter att felen åtgärdats kommer sidan att lanseras på föreningens hemsida och alumner kommer kunna registreras i föreningens alumnnätverk. 4. Verktyg Anledningen till valet av de verktyg som kommer presenteras i detta kapitel var att dessa använts vid programmering av föreningens hemsida. För att den webbsida som programmeras i detta projektarbete skulle kunna implementeras på ett smidigt sätt användes således Xampp, Apache, MySql, php och phpmyadmin, se figur 3. Figur 3: En schematisk bild över systemet där de tekniska bitarna har implementerats. 4.1 XAMPP Då en webbsida ska konstrueras är det bra att experimentera lokalt på en webbserver. I XAMPP, som är ett open source program, ingår de flesta program som behövs för att 9

12 genomföra detta. Dessa är bland annat webbservern Apache, databashanteraren MySQL och programmeringsspråket PHP. För att använda den lokala servern måste servrarna Apache och MySQL startas upp. Serverns aktivitet kan kollas genom att skriva som refererar till den dator eller det system som används. När php-filen skrivits sparas den i Xampp/htdocs som filnamn.php och filen kan köras genom att skriva i webbläsaren Apache Webbservern Apache exekverar den php-kod som programmerats om php installerats på webbservern. När ett anrop kommer från användaren behandlas denna på Apacheservern och eventuellt exekveras php-kod och resultatet skickas därefter tillbaka till användaren. Användaren tolkar resultatet genom webbläsaren. Om webbservern har php-kod som motsvarar anropet från användaren kommer php-koden inverka på resultatet som skickas tillbaka till användaren. 4.3 MySQL MySQL är en databashanterare där frågespråket SQL används för att kommunicera mellan databasen och tillämpningsprogrammet. Genom att ställa frågor till databasen kan data matas in, uppdateras eller raderas på ett smidigt sätt. MySQL är open source (datorprogram där källkoden kan användas, modifieras, läsas och vidaredistribueras) och kan således laddas ner och användas gratis. På grund av att det är gratis och lättillgängligt, men även anpassat för många olika programmeringsspråk, har det många användare vilket gör det lätt att få hjälp PHP PHP är ett programmeringsspråk som främst används till programmering av webbsidor där innehållet hämtas från en databas eller från användarens formulärdata. Programmeringsspråkets huvudsakliga uppgift är att fungera som ett filter där källkoden tolkas och omvandlas till en textström som skrivs ut. Vid programmering med php sker ofta kommunikation med databasen där information hämtas och skrivs ut av mottagaren som oftast 7 ( ) 8 Thomas Padron-McCarthey, Tore Risch, Databasteknik, s 615 ff 10

13 är en webbläsare. En av de största fördelarna med php är att stödjer många olika typer av databasprogram vilket underlättar arbetet med webbsidor Inbyggda metoder För att programmera webbsidan utnyttjades de inbyggda metoderna i Codeigniters bibiliotek. I klassen helper användes metoder som underlättade programmeringen av formuläret där informationen av alumnerna skrivs in. Dessa metoder genererade bland annat textfält, rullistor och submit-knappar. 9 Metoden post() som ligger i Codeigniter s klass input användes för att hämta ut information från de olika fälten som skapats i formuläret. Inparametern motsvaras av namnet på fältet som skapades i formuläret. Om den andra parametern sätts till TRUE kommer alla värden från fältet att hämtas. 10 Metoden phpsession som använts ingår inte i Codeigniter s bibliotek men är väldigt användbar då sidor med login programmeras. Phpsession används för att lagra information om användaren på servern men denna information är endast temporär och kommer raderas då användaren stänger sidan. Då ett login ska programmeras ska informationen om användaren sparas och således rekommenderas att informationen lagras i en databas phpmyadmin PhpMyadmin är ett gratis program skrivet i php som användes för administrering av MySQL på webben. Programmet underlättar hanteringen av databasen och det stödjer även vanliga SQL-frågor som används vid skapande av nya tabeller. Data från tabellerna kan exporteras till bland annat Excel, Word, PDF och vanliga textdokument ( ) 10 ( ) 11 ( ) 12 ( ) 11

14 5. Implementation 5.1 Designen av databasen ER-modellen användes för att analysera och få en helhetsbild av hur databasen skulle konstrueras. För att undvika en dum design på databasen analyserades först vilken typ av information som skulle lagras i databasen. Den naturliga utgångspunkten för designen av databasen blev alumn eftersom syftet med webbsidan var att information om alumner skulle lagras, se figur 3. Nästa steg i designen av databasen var att bestämma vilken typ av information som skulle lagras, det vill säga vilka attribut entiteten Alumn skulle ha. För att informationen om alumnerna skulle lagras på ett effektivt sätt med bra semantik gjordes en del attribut till entiteter där de kopplades till alumn med en sambandstyp. Detta var tanken då alumnerna anger vilka arbetsgivare de haft efter examen samt vilket land de bor i. Istället för att varje företagsnamn lagras som ett attribut för varje alumn skapades entiteten Företag med attributen företagsid och namn. Entiteten Företag länkades samman med alumn genom sambandstypen, Jobbar på. Detta gjordes för att undvika att samma företagsnamn lagras flera gånger för olika alumner men även för att göra lagringen mer effektiv. Sambandstypen mellan entiteten Alumn och entiteten Företag sattes till ett N:M-samband, många till många samband. N:M-sambandstypen valdes eftersom en alumn kan ha haft flera olika arbetsgivare efter examen och olika alumner kan ha haft samma arbetsgivare. För att mer information om varje alumns arbetsgivare sedan examens skulle kunna erhållas adderades en del attribut till sambandstypen Jobbar på. En tabell med alla världens länder användes i formuläret vilket gjorde att det blev smidigare att införa en sambandstyp, Bor i, mellan entiteten Alumn och Land. Sambandstypen mellan Alumn och Land sattes till N:1-samband eftersom varje alumn endast kan bo i ett land men flera alumner kan bo i samma land. 12

15 Figur 4: ER-diagram av databasen Mellan sambandstypen Bor i och entiteten Alumn infördes ett fullständigt deltagande eftersom en alumn måste bo i ett land. Mellan Bor i och Land är det ett partiellt deltagande eftersom varje land inte behöver vara bebott av en alumn. Det fullständiga deltagandet mellan Jobbar på och Företag innebär att varje företag måste ha en alumn vilket beror på att ett företag inte läggs in i databasen om inte en alumn har angett det företaget. Attributet presentation lagrar information om alumnen är intresserad av att hålla en inspirerande presentation för nuvarande studenter på programmet. Engagemang innehåller information om alumnens engagemang under studietiden och PUL lagrar information om alumnen accepterar att föreningen behandlar informationen om alumnen enligt personliga uppgiftslagen. I övrigt lagras information om alumnen som de andra fälten i formuläret inte täcker. För att kunna implementera designen i ER-diagrammet till en användbar databas utnyttjades relationsmodellen där ER-diagrammet översättas till vanliga tabeller. Dessa tabeller skapades sedan i relationsdatabasen MySQL genom att utnyttja SQL-frågor. 5.2 Resulterande tabeller i databasen Designen av databasen och översättningen från ER-modellen till relationsmodellen resulterade i fyra tabeller. Normalformen BCNF erhölls i tabellerna Alumnjobb, Alumnföretag och Alumnland. Tabellen Alumn erhöll ingen normalform eftersom den innehöll värden som inte var atomära och således inte uppfyllde 1NF. 13

16 Alumntabellen innehåller all information om alumnen där alumnid valdes till primärnyckel eftersom det är unikt för varje rad samt att sökningar i tabellen underlättas. Mailadressen och mobilnummer är kandidatnycklar. Av praktiska skäl och för att inte få en dålig semantik, det vill säga att tabellen blir svår att förstå, analyserades inte fler kombinationer av attribut som skulle kunna bilda en kandidatnyckel. Anledningen till att denna tabell inte erhöll BCNF var att värdena i kolumnerna adress, engagemang och övrigt inte var atomära, se figur 4. Figur 5: Tabellen Alumn med kolumnerna inom parenteserna samt funktionella beroenden. Alumnjobb innehåller all information om vilka arbetsgivare samt vilken position i företaget alumnen haft efter examen. Genom attributen startyear, startmonth, endyear och endmonth kan den period alumnen befunnit sig på det företaget registreras. Primärnyckeln i denna tabell består av fyra attribut, dessa är alumnid, företagsid, startyear och startmonth. Anledningen till denna primärnyckel är att alumnen kan byta titel inom samma företag under samma år. Anser även att en alumn kan ha två olika titlar på samma företag under samma år. Detta ger en tabell med normalformen BCNF eftersom alla attribut pekas ut av en kandidatnyckel, se figur 5. Figur 6: Tabellen Alumnjobb med kolumnerna inom parenteserna samt funktionella beroenden. Alumnföretag innehåller de företag som alumnerna jobbar på eller har jobbat på och primärnyckeln är företagsid som företaget erhåller då det läggs in i tabellen. Namn är kandidatnyckel i denna tabell eftersom flera företag inte kan ha samma namn. Tabellen erhöll normalformen BCNF eftersom varje attribut pekas ut av en kandidatnyckel, se figur 6. 14

17 Figur 7: Tabellen Alumnföretag med kolumnerna inom parenteserna samt funktionella beroenden. Alumnland innehåller alla länder i världen och varje land är kopplade till ett landid. Primärnyckeln i denna tabell är landid och namn är kandidatnyckel eftersom att det inte finns flera länder med samma namn. Tabellen erhöll normalformen BCNF eftersom varje attribut pekas ut av en kandidatnyckel, se figur 7. Figur 8:Tabellen Alumnland med kolumnerna inom parenteserna samt funktionella beroenden. Att tabellerna Alumnland, Alumnföretag och Alumnjobb erhöll normalformen BCNF innebär att databasen har designats på ett bra sätt. Tabellen Alumn som inte erhöll normalformen BCNF bör inte tolkas som någonting dåligt i detta fall eftersom det blir praktiskt svårt att lagra stora textsträngar som atomära värden. Om vikten vid designen av databasen låg i att erhålla normalformen BCNF för tabellen Alumn hade detta givit en tabell som varit svår att förstå. 5.3 Design av webbsidan Webbsidorna för alumner resulterade i tre stycken olika sidor där ena sidan enbart hanterar registrering av alumner, se figur 8. De resterande två sidorna blev inloggningssidan och sidan med all personlig information om alumnen. Registreringssidan och inloggningssidan programmerades på i stort sett samma sätt med två textfält för mailadress och lösenord samt submitknappar för att komma till nästa steg, se figur 9. 15

18 Figur 9: Webbsidan där alumnerna registrerar sig för att sedan kunna logga in på de personliga sidorna Figur 10: Inloggningssidan för att komma till den personliga sidan Mina sidor skiljer sig från de andra två genom att den visar den personliga informationen om alumnen vid inloggning och har avsevärt många fler textfält av olika slag. Sidan delas upp av två formulär. Ett formulär med kontaktuppgifter och studietidsrelaterade fält där alumnen kan beskriva mer utförligt vad som gjordes under studietiden. Det andra formuläret inriktas enbart på vilka företag alumnen har jobbat på efter examen, se appendix. 16

19 5.4 Metoder och klasser till webbsidan Programmet Xampp användes för att konstruera webbsidan som programmerades i php där koden skrevs i en vanlig texteditor. Xampp användes främst till att exekvera den kod som skrevs och genom att exekvera den via erhölls även felmeddelanden som annars brukar stå direkt i programmeringsmiljön vid programmering med till exempel Java och Matlab. I programmeringen utnyttjades en del färdigskrivna metoder från Codeigniters helperklass och inputklass. Programmeringen delades upp i två olika typer av php-filer, en av filerna hanterar endast kommunikationen med databasen och den andra innehåller programmeringen för webbsidan. Användaren måste först registrera sig som alumn på sidan Registrera dig innan hon eller han kan logga in. När alumnen loggar in på Mina sidor via Logga in kan den personliga informationen läggas in och när detta är gjort kan alumnen logga ut Klasser och metoder Dessa metoder användes vid programmering av webbsidan och skrevs i klassen app_alumn: output() det som skrivs i denna metod är det som skrivs ut på webbsidan, det vill säga det som användaren ser. Metoden kollar om användaren är inloggad genom att använda phpsession. Om användaren är inloggad anropas användarens personliga sida annars skickas användaren till inloggningssidan, se figur 10. login() anropas från output() om användaren inte skulle vara inloggad. Denna metod skapar formuläret för inloggningssidan. login_alumn() hämtar de data som skrivits in i fälten skapade i login() och jämför inloggningsuppgifterna med de som är lagrade i databasen. logout() när användaren trycker på Logga ut -knappen som skapas i metoden minasidor() anropas denna metod och användaren loggas ut. 17

20 Figur 11: Klassen Alumn och hur de olika metoderna är kopplade till varandra i denna klass minasidor() anropas från output om användaren är inloggad. Här skapas formuläret med de olika fälten där alumnen kan skriva in den personliga informationen. Den personliga informationen laddas även in från databas när användaren loggar in på sina sidor. Detta gäller även de arbetsgivare som användaren haft, se figur 11. addalumn_information() plockar ut alla information som har skrivits in i fälten som skapats i metoden minasidor() och formaterar det som skrivits in i textfälten. Det vill säga att alla namn som skrivs in i fälten lagras i databasen med första bokstaven stor och resten små. Sker en kontroll i denna metod så att inte användaren byter mailadress till en mailadress som någon annan alumn redan har. Anropar därefter en metod som lagrar den formaterade informationen i databasen. addforetag() hämtar all information från fälten som är knutna till vilka arbetsgivare man haft efter examen. Formaterar denna information för att alla företagsnamn ska börja med stor bokstav och resten av bokstäverna ska vara små. I denna metod görs en kontroll för att undvika att samma företag lagras fler gånger. Om det är ett nytt företag som skrivits in i företagsfältet lagras det i företagstabellen, om inte så lagras det ej och det företagsid som motsvarar företagsnamnet hämtas istället från företagstabellen. 18

21 Figur 12: Beskriver vad som sker i metoden minasidor() I klassen alumn skrevs metoderna för att hämta ut, lägga in och uppdatera information i databasen. Detta gjordes genom att ladda in Codeigniter s bibliotek för databasmetoder och således kunde informationen hanteras med SQL-frågor. Metoderna i denna klass anropas från klassen app_alumn då information i databasen ska hanteras. För hanteringen av nya alumner programmerades två separata klasser, app_alumnregistrering och alumnregistrering. app_alumnregistreing programmerades webbsidan som hanterar nya oregistrerade alumner där alumnerna får ange valfri mailadress och valfritt lösenord som sedan ska användas för att logga in på de personliga sidorna. I denna metod kontrolleras även om den inskrivna mailadressen redan existerar i databasen och om mailadressen är skriven på rätt form genom att utnyttja metoden valid_ () i klassen helper, se figur 12. alumnregistrering programmerades metoder där Codeigniter s bibliotek för databashantering utnyttjades. Således kunde SQL användas för att lägga in nya alumner i databasen samt plocka ut relevant information ur databasen. 19

22 Figur 13: Klassen Alumnregistrering och hur metoderna är kopplade till varandra i denna klass. För att öka säkerheten för användaren och inte riskera att deras lösenord sprids vidare i klartext programmerades en metod password_encrypt() för att hasha det lösenord som användaren skriver in. Detta innebär att lösenordet inte sparas i klartext utan som en sträng med 40 tecken innehållande siffror, stora bokstäver och små bokstäver. Även om någon nu skulle komma över lösenorden så måste de fortfarande lista ut hashning vilket är en väsentlig skillnad jämfört med om lösenordet hade stått i klartext. 6. Diskussion 6.1 Åtgärder innan lansering Innan sidan kan lanseras behöver webbsidan göras mer användarvänlig för att alumnerna ska kunna fylla i formuläret på rätt sätt. En av delarna som behöver införas före lansering handlar om att hjälpa användaren då något fel har uppstått vid inmatning i formuläret. Vid detta tillfälle ska en röd text skrivas ut där felet har uppstått för att alumnen ska kunna hitta det. 20

23 Alumnen kan vid ett sådant tillfälle ha fyllt i alla fält och tryckt på spara för att sedan märka att ett fel har uppstått och informationen i de fält som var korrekt ifyllda har försvunnit. Detta är något som återstår att programmera för att underlätta användningen för alumnen. För att göra formuläret och webbsidan mer tilltalande återstår det att programmera presentationsstilen av sidan och detta görs i programmeringsspråket CSS, cascading style sheets. Med CSS programmeras bland annat vilket typsnitt, färg och storlek texten ska ha men även de olika knapparnas och textfältens position på hemsidan. Detta är enbart designprogrammering men även detta är viktigt för att göra sidan mer attraktiv och tilltalande. Detta behöver även göras för att alumnsidan ska följa den standardmall som upprättats på föreningens hemsida. Hemsidan fick önskat utseende och fungerar väl förutom de få åtgärder som återstår innan den kan tas i drift. För att kunna ta webbsida i drift måste den flyttas från den lokala servern till det webbhotell som föreningen hyr. 6.2 Utvecklingsmöjligheter För att förbättra kontakten mellan alumnerna och för att alumnerna sinsemellan ska kunna planera återträffar skulle ett diskussionsforum behöva utvecklas. Detta skulle förbättra gemenskapen mellan de tekniska fysiker som befinner sig ute i arbetslivet och det skulle även ge alumnerna en plats att diskutera och upprätthålla kontakten på. Genom diskussionsforumet ska de studenter som sitter i föreningens styrelse kunna snappa upp när alumnerna är intresserade av en återträff och hjälpa till med arrangemanget av detta. En koppling till de sociala medierna Linkedin och Facebook skulle underlätta kontakten med alumnerna. Även spridningen av alumnverksamheten till icke-registrerade alumner skulle gynnas. Förhoppningen och målet med denna verksamhet är att i framtiden kunna anordna alumnsittningar med gamla studenter och att alumner ska ha kvar kontakten med studenttiden. Med denna databas av alumner kommer det även att bli lättare för föreningen att hitta framgångsrika personer som kan komma och inspirera studenterna på programmet. 21

24 7. Referenser Thomas Padron-McCarthey, Tore Risch, Databasteknik, Studentlitteratur, Indien 2010 Apachefriends. (Elektronisk) Tillgänglig: ( ) Codeigniter. (Elektronisk) Tillgänglig: ( ) Codeigniter. (Elektronisk) Tillgänglig: ( ) W3Schools. (Elektronisk) Tillgänglig: ( ) Phpmyadmin. (Elektronisk) Tillgänglig: ( ) 22

25 8. Appendix 23