EXIT - Examinatorer inom Informationsteknik

(1)

EXIT - EXAMINATORER INOM INFORMATIONSTEKNIK

EXIT- Examiners in Information Technology

Linda Eriksson Sara Hägglund

Examensarbete inom Informationsteknik Kandidat

Degree Project in Information Technology

Stockholm, Sweden 2011 Kurs II121X, 15hp

(2)

EXIT EXAMINATORER INOM INFORMATIONSTEKNIK

15 juni 2011

Sara Hägglund Linda Eriksson sarhag@kth.se lierikss@kth.se KUNGLIGA TEKNISKA HÖGSKOLAN

Skolan för informations- och kommunikationsteknik

(3)

Sammanfattning

Det är inte lätt för en examinator att hålla ordning på antalet arbetstimmar denne förväntas lägga på handledningstid för examensarbeten. Beroende på vilken typ av examensarbete det gäller och vilket budgetår (kalenderår) som är aktuellt kan olika regler gälla. EXIT är ett system där studierektorer kan lägga till budgetår och examinatorer. Genom att sedan specicera hur mycket arbetstid varje examinator skall lägga på handledning vid examensarbeten gör studierektorn det möjligt för examinatorerna att hålla reda på hur mycket tid de förväntas lägga på handledning och hur mycket tid de har kvar för det aktuella budgetåret. Även studenter har nytta av systemet eftersom de kan se vilka examinatorer som nns tillgängliga när de söker examensarbeten.

Abstract

It is not easy for an examiner to keep track of the number of working hours he/she is expected to spend on tutoring students doing their degree projects.

Depending on the type of degree project and on the current budget (calendar) year, dierent rules may apply. EXIT is a system where directors of studies can add budget years and examiners. By specifying how much working hours each examiner shall use for tuition of degree projects, the director of studies makes it possible for the examiners to keep track of how much time they are expected to spend tutoring degree projects, and how much time they have left for the current budget year. Students can also benet from the system because they can see which examiners that are available when they are looking for an examiner to their degree project.

(4)

EXIT - Examinatorer inom Informationsteknik Innehåll

Innehåll

1 Inledning 1

1.1 Bakgrund . . . . 1

1.2 Syfte . . . . 1

1.3 Arbetsmetod . . . . 1

2 Förstudie 1 2.1 Databashanteringssystem . . . . 2

2.1.1 PostgreSQL . . . . 2

2.1.2 MySQL . . . . 2

2.1.3 PostgreSQL vs MySQL . . . . 2

2.2 Webbutveckling . . . . 3

2.2.1 HTML . . . . 3

2.2.2 CSS . . . . 3

2.2.3 PHP . . . . 3

2.3 CAS . . . . 4

2.4 LDAP . . . . 4

2.5 Ramverk . . . . 4

2.5.1 Yii . . . . 4

2.6 Omvärldsanalys . . . . 5

3 Systemspecikation 5 3.1 Utvecklingsmiljö . . . . 5

3.2 Systemkrav . . . . 5

3.3 Användargrupper . . . . 5

3.3.1 Administratör . . . . 5

3.3.2 Studierektor . . . . 5

3.3.3 Examinatorer . . . . 6

3.3.4 Studenter . . . . 6

3.4 Installationsspecikation . . . . 6

3.5 Arbetsprocess . . . . 6

3.6 Säkerhetskrav . . . . 6

4 Systemarkitektur 7 4.1 Databas . . . . 7

4.2 KTH:s inloggningssystem . . . . 7

4.3 LDAP . . . . 8

4.4 Webbserver . . . . 8

5 Design 9 5.1 Databas . . . . 9

5.2 Graskt gränssnitt . . . . 9

5.3 Aktörsvyer . . . 10

5.3.1 Administratörsvy . . . 10

5.3.2 Studierektorsvy . . . 11

5.3.3 Examinatorsvy . . . 12

5.3.4 Studentvy . . . 12

5.4 Beskrivning av ett specikt användarfall . . . 13

5.4.1 Källkodsler för användarfallet . . . 14

5.5 Spårbarhet . . . 14

6 Implementation 14 6.1 Databas . . . 14

6.2 PHP . . . 14

(5)

EXIT - Examinatorer inom Informationsteknik Innehåll

7 Systemtester 14

7.1 Felkontroller . . . 14 7.2 Webbläsare . . . 15

8 Diskussion 15

8.1 Möjliga förbättringar . . . 16

9 Källförteckning 17

A Listning av källkodsler 18

A.1 Skapade källkodsler . . . 18 A.2 Modierade ler i ramverket . . . 19 A.3 Exempel på källkodsl 'Add examiner' . . . 20

B Databaskod 23

C Användarfallsmodell

D Användarfallsspecikationer

(6)

EXIT - Examinatorer inom Informationsteknik 2 Förstudie

1 Inledning

Att tilldela examinatorer vid examensarbeten kan vara en arbetskrävande uppgift eftersom det är många faktorer som skall tas hänsyn till. Till exempel får examinatorer per budgetår ett visst antal tilldelade timmar som skall användas till handledning vid examensarbeten. För att studierektorerna (och examinatorerna) skall hålla reda på hur många timmar en viss examinator har använt av dessa timmar är det praktiskt att ha ett system som hjälper till att hålla reda på detta.

1.1 Bakgrund

År 2007 ändrade KTH sina utbildningar för anpassning till bolognaprocessen.

Detta har medfört att alla civilingenjörer måste skriva både ett examensarbete för kandidatexamen och ett för master/civilingenjörsexamen, istället för bara ett för civilingenjörsexamen. Detta innebär att antalet examensarbeten har ökat kraftigt, vilket har gjort att det krävs mer arbete för studierektorerna att hitta examinatorer till dessa.

1.2 Syfte

Syftet med examensarbetet är att skapa ett system som hjälper studierektorer att hålla koll på hur mycket handledningstid en examinator har lagt på examensarbeten under det aktuella budgetåret. Ytterligare ett syfte med systemet är att examinatorer själva skall kunna hålla reda på den handledningstid som de förväntas lägga på examensarbeten. Ifall de har mycket kvarvarande handledningstid uppmuntras de att ta på sig er examensarbeten så att deras han- dledningskvot fylls. Ett annat syfte med systemet är att studenter ska kunna se tillgängliga examinatorer när de söker examensarbeten.

1.3 Arbetsmetod

Under projektets gång har vissa delar av agila metoder tillämpats. I början av projektet användes användarberättelser (user stories) som är en form av in- dexkort där en eller några få meningar denierar systemkrav. Senare i projektet byttes dessa ut mot användarfall (use cases). Dessa innehåller en händelse som beskriver hur en aktör skall kunna använda systemet. Orsaken till bytet var att dessa ansågs vara mer lämpliga för detta projekt. Användarfallsmodellen och användarfallsspecikationerna nns som bilagor.

2 Förstudie

Det fanns ett antal utvecklingsmiljöer att välja mellan när applikationen skulle utvecklas. Ett önskemål från kunden var att PHP skulle användas och för att kunna använda KTH:s inloggningssystem krävdes användning av en CAS-klient.

En undersökning gjordes för att se om någon annan hade gjort något liknande system tidigare.

Nedan presenteras de system och webbutvecklingsverktyg som ingick i förstudi- en.

(7)

2.1 Databashanteringssystem

Det nns några olika varianter på databashanteringssystem som har öppen käl- lkod. Valet för detta projekt stod mellan PostgreSQL och MySQL. (SQL står för Structured Query Language).

2.1.1 PostgreSQL

PostgreSQL är ett relationsdatabashanteringssystem baserat på öppen källkod och är släppt under BSD-licens, vilket innebär att vem som helst kan använda, modiera och distribuera PostgreSQL-kod utan kostnad [1].

PostgreSQL är en vidareutveckling på Postgres95 som i sin tur är baserat på POSTGRES som utvecklades på Berkley-universitetet i Kalifornien [2]. Post- greSQL kan användas från i princip alla större programmeringsspråk, till exempel C, C++, Java, Perl och PHP, och följer i stort sett branschens standard för frågespråk [3].

PostgreSQL innehåller de esta funktioner som nns i databashanteringssystem, både i kommersiella och i varianter med öppen källkod, samt en del ytterligare funktioner som det kan vara svårt att nna i andra system [3].

Det nns olika verktyg för att hantera PostgreSQL. Dels nns det textbaserade och dels nns det graska verktyg. Det mest kända textbaserade verktyget heter psql och några exempel på graska verktyg är pgAdmin och pgAccess [1].

2.1.2 MySQL

MySQL är ett relationsdatabashanteringssystem som ger användaren möjlighet att spara information i databaser, vilket gör informationen både sök- och sorter- bar. MySQL använder sig av SQL som är standardspråket för databaser [4].

MySQL kan användas i era olika operativsystem, t.ex. era olika varianter av UNIX-system samt Windows [4].

MySQL släpps under GNU General Public Licence för icke-kommersiellt bruk.

Den kan läggas in i kommersiell mjukvara som inte har öppen källkod, men då krävs en särskild licens som inte är gratis [1].

MySQL saknar vissa funktioner som kan behövas i databaser som t.ex sparade procedurer, triggers, referensintegritet, SQL unions och subqueries men för de

esta användare nns det tillräckligt med funktioner för att de skall vara nöjda.

MySQL är väldigt snabbt för små till mediumstora databaser [5].

2.1.3 PostgreSQL vs MySQL

Efter att ha gjort förstudien av de olika databashanteringssystemen visar resul- tatet att det inte spelar någon större roll vilken av dem som används i detta projekt.

Eftersom det i detta fall inte spelade någon roll vilken av dessa som användes valdes PostgreSQL då det till skillnad från MySQL inte ägs av något vinstdri- vande företag.

(8)

2.2 Webbutveckling

Vid webbutveckling kan era olika verktyg användas. Nedan listas några av dessa.

2.2.1 HTML

HTML (HyperText Markup Language) är ett instrument för att skapa webbsidor. Huvudtanken bakom HTML är att det skall möjliggöra ihoplänkning av dokument så att en användare kan klicka sig vidare från en sida till en annan [6].

Många olika versioner av HTML har släppts. Från och med version 4.0 som gavs ut 1998 inkluderades bland annat skriptspråk och style sheets (stilmallar) [6].

Mellan år 2000 och 2002 utvecklades XHTML som är en utökning av HTML men har striktare syntax [6].

2.2.2 CSS

CSS (Cascading Style Sheets) (stilmallar) är ett språk som används för att sepa- rera presentationen från strukturen och innehållet på en webbsida. CSS hjälper till att skapa en enhetlig design som kan appliceras på hela sidan. Genom att ändra i CSS-len kan designen för hela webbsidan ändras på en gång utan att

er ler behöver modieras [6].

En viktig sak att tänka på är när era olika stilmallar skapas parallellt och berör samma element så kommer de att skriva över varandra. Om de berör olika element kommer stilarna att sammanfogas [7].

Webbstandarder planerar att i framtida versioner av HTML ta bort stödet för font-taggar. (En font-tagg ändrar textens utseende på en webbsida). Detta kommer leda till att de som programmerar webbsidor kommer att bli tvungna att använda CSS. Eftersom font-taggar inte behöver användas resulterar detta i att hemsidan upptar mindre diskutrymme vilket gör att sidorna visas snabbare i webbläsaren [7].

2.2.3 PHP

PHP är ett skriptspråk särskilt designat för att producera dynamiska hemsidor.

PHP stod ursprungligen för Personal Home Page men ändrades sedan så att det nu står för PHP Hypertext Preprocessor [4].

Inuti en webbsida kan PHP-kod läggas in och kommer då att köras varje gång sidan besöks. PHP-koden interpreteras av webbservern och genererar HTML- kod eller annan utskrift som besökaren kommer att se. Således kan inte besökare av webbsidan se PHP-koden, utan enbart HTML-koden och webbläsaren be- höver inte kunna förstå PHP-kod [4].

En av fördelarna med PHP är att det kan användas på många olika operativsystem och webbservrar som t.ex Windows, Unix, Apache och ISS. PHP har också inbyggt stöd för mycket som kan komma till användning vid skapandet av webbsidor som t.ex PostgreSQL, MySQL, LDAP, CAS och mycket mer [5].

(LDAP och CAS beskrivs senare i kapitlet.)

(9)

PHP baseras på öppen källkod, vilket innebär att vem som helst kan använ- da, ändra och distribuera källkoden utan kostnad [4]. Eftersom PHP baseras på öppen källkod nns många programmerare som dagligen försöker förbättra källkoden vilket gör att PHP konstant förbättras [5].

2.3 CAS

CAS (Central Authentication Service) är ett system som används bland annat av universitet för att autentisera användare. Genom att använda CAS kan säkerheten på systemet öka. Detta eftersom lösenord bara behöver skickas till CAS-servern, vilket innebär att de system som ansluter till CAS aldrig får till- gång till lösenord, utan endast användarnamn [8].

Att logga ut ur CAS och att logga ut ur ett system som använder CAS är två olika saker. När en användare loggar ut ur CAS innebär det att denne ej kan logga in på andra system som använder CAS utan att göra en ny inloggning. Däremot påverkar inte en utloggning ur CAS aktiva sessioner mot redan uppkopplade system [8].

Användaren loggar ut från de använda systemen på vanligt sätt, men varje anslutet system skall då också fråga om denne också önskar logga ut från CAS.

Om användaren stänger webbläsaren kommer denne automatiskt att loggas ut från CAS, varför det rekommenderas att användare alltid stänger webbläsaren efter att ha använt system som använder CAS [8].

2.4 LDAP

LDAP (Lightweight Directory Access Protocol) är en standardmetod för åtkomst och uppdatering av information i en katalog [9].

Till skillnad från vanliga databaser har LDAP en begränsad funktionalitet. Van- ligtvis är det bara små mängder information som skickas i varje förfrågan/svar och informationen i LDAP uppdateras inte lika frekvent som i en vanlig databas [10].

Varje rad i katalogen refereras av en specik nyckel, vilket innebär att det är möjligt att genom att ange ett namn erhålla övrig information som t.ex.

mailadress [10].

2.5 Ramverk

Ett ramverk innehåller färdiga byggblock och designstrukturer för att hjälpa en programmerare att snabbt bygga upp ett fungerande system.

Det nns ett antal olika ramverk för PHP och efter testning av några av dessa valdes tillslut ramverket Yii.

2.5.1 Yii

Yii är ett komponentbaserat PHP5-ramverk som släpptes 2008. Namnet Yii är en akronym för Yes (som uttalas Yee) och står för easy, ecient and extensible.

Yii gör det lättare att skapa och underhålla stora webbapplikationer [11].

(10)

EXIT - Examinatorer inom Informationsteknik 3 Systemspecifikation

Ramverket uppmuntrar till återanvändning av kod vid webbprogrammering, vilket kan påskynda utvecklingsprocessen markant. Det är lätt att modiera koden för det egna systemets behov [11].

Alla Yii-applikationer bygger på Model-View-Controller (MVC)-arkitektur, vilket innebär att 'aärsregler' (business logic) separeras från användargränssnitt. Det- ta gör att utvecklarna t.ex. kan ändra användargränssnittet utan att det påverkar aärsreglerna. MVC-arkitekturen representeras av tre delar: vyer, användar- gränssnitt och kontroller [12].

2.6 Omvärldsanalys

En undersökning har gjorts huruvida någon har gjort något liknande system tidigare, dock utan resultat.

Sökningen gjordes dels på internet och dels i KTH:s bibliotekssystem.

3 Systemspecikation

I detta kapitel denieras systemkraven samt de användargrupper som skall kunna använda systemet.

3.1 Utvecklingsmiljö

Systemet skall implementeras i PHP kombinerat med något databashanteringssystem.

3.2 Systemkrav

Alla systemkrav presenteras i användarfallsmodellen (se Bilaga C). Mer detal- jerad information nns i användarfallsspecikationerna (se Bilaga D).

3.3 Användargrupper

De användargrupper som systemet skall kunna hantera presenteras nedan. Gemen- samt för alla användargrupper är att de skall kunna logga in via KTH:s inloggningssystem, men de har i övrigt olika rättigheter.

3.3.1 Administratör

Administratörerna skall kunna lägga till och se tillagda studierektorer.

3.3.2 Studierektor

Studierektorerna skall kunna lägga till och visa tillagda examinatorer, specicera antalet timmar för varje examinator samt lägga till och se specicerade budgetår.

De skall också kunna se antalet kvarvarande handledningstimmar och uppdatera dessa för varje examinator.

(11)

EXIT - Examinatorer inom Informationsteknik 3 Systemspecifikation

3.3.3 Examinatorer

Examinatorerna skall kunna se antalet kvarvarande handledningstimmar, se till- gängliga examinatorer och lägga till examensarbeten till deras egna examina- torskvoter. En examinator skall också kunna se dennes tillagda examensarbeten och se specik information om dessa. Denne skall även kunna markera examensarbeten som avslutade/avbrutna.

3.3.4 Studenter

Studenterna skall kunna se alla tillgängliga examinatorer för det aktuella bud- getåret.

3.4 Installationsspecikation

Detta kapitel beskriver vad som behöver göras för att starta upp systemet.

Systemet är utvecklat för att använda PHP-version 5.2.4 och Apache 2.0.

Den katalog som behöver kopieras till webbserverns rootkatalog är exit/.

Följande l behöver ändras i katalogen:

connection.php

/exit/protected/connection.php

Det som behöver ändras är uppkopplingen mot databasen.

För att starta applikationen skriv följande:

http://adress-till-webbservern/exit/

3.5 Arbetsprocess

Detta kapitel beskriver i vilken ordning saker bör göras i systemet.

• Någon lägger till en administratör i databasen. (Detta måste göras direkt i databashanteringssystemet till skillnad från i alla andra fall där tillägg av information görs via det graska gränssnittet.)

• Administratören lägger till en studierektor i systemet.

• Studierektorn lägger till ett budgetår för det aktuella året.

• Studierektorn lägger till examinatorer i systemet.

• Studierektorn specicerar handledningstimmar för examinatorerna på det aktuella budgetåret.

• Examinatorerna kan nu använda alla funktioner i systemet.

3.6 Säkerhetskrav

Applikationen skall se till att användaren måste autentisera sig för att kunna använda systemet, och därmed skall dennes behörighet kunna verieras. Inga obehöriga skall kunna läsa, skriva till eller på något annat sätt modiera systemet.

(12)

EXIT - Examinatorer inom Informationsteknik 4 Systemarkitektur

4 Systemarkitektur

I detta kapitel presenteras systemets olika delar. Dessa består av en databas, KTH:s inloggningssytem, KTH:s LDAP-databas och en webbserver. Figur 1 ger en illustrativ bild över systemets arkitektur.

Figur 1: Systemets arkitektur.

4.1 Databas

I databasen lagras all information som det utvecklade systemet kräver för att fungera. Denna information lagras i tabeller som presenteras i ett UML-diagram i designkapitlet.

4.2 KTH:s inloggningssystem

Den teknik som KTH:s inloggningstjänst använder heter CAS (Central Authen- tication Service) och gör så att ej inloggade användare omdirigeras till KTH:s inloggningssida. Då KTH redan har en bentlig inloggningstjänst behövdes ej någon sådan implementeras. Det enda som krävdes var att koppla ihop det utvecklade systemet med inloggningstjänsten.

(13)

EXIT - Examinatorer inom Informationsteknik 4 Systemarkitektur

4.3 LDAP

KTH har en LDAP-databas som endast går att nå från KTH:s servrar. LDAP- databasen används för att plocka ut användarinformation som till exempel för- namn, efternamn och mail på inloggade användare genom att skicka med den inloggade användarens användar-ID.

4.4 Webbserver

För att systemet skall kunna användas måste det ligga på en webbserver på KTH. (Annars kan inte KTH:s LDAP-databas användas.)

(14)

EXIT - Examinatorer inom Informationsteknik 5 Design

5 Design

I detta kapitel presenteras databasdesignen, det graska gränssnittet, de skapade aktörsvyerna samt en beskrivning av ett specikt användarfall.

5.1 Databas

I gur 2 visas ett UML-diagram över tabellerna i databasen.

Figur 2: UML-diagram över tabeller i databasen.

5.2 Graskt gränssnitt

Systemets graska användargränssnitt är tänkt att likna det som används på KTH:s hemsida. Därför valdes färger som liknar de som nns på denna.

I systemet navigerar användaren mellan olika 'ikar' i menyn. Flikarna är synli- ga/osynliga beroende på vilka användarbehörigheter den inloggade användaren har.

(15)

5.3 Aktörsvyer

Systemet har fyra användargrupper och varje grupp har en egen aktörsvy. Varje aktörsvy har i sin tur era användarfallsvyer.

De olika användargrupperna är: administratörer, studierektorer, examinatorer och studenter. Figur 3 visar systemets startsida. Nedan beskrivs de olika ak- törsvyerna.

Figur 3: Startsidan.

5.3.1 Administratörsvy

Administratörsvyn ger administratörerna möjlighet att lägga till och visa alla tillgängliga studierektorer. Dessa funktioner nns endast om den inloggade användaren har administratörsbehörighet till systemet. Administratörsvyn presenteras i gur 4.

Figur 4: Administratörsvyn.

(16)

5.3.2 Studierektorsvy

I studierektorsvyn kan studierektorerna lägga till budgetår och deniera parame- trar för hur många handledningstimmar som krävs för examensarbeten på master- respektive kandidatnivå. När budgetåret läggs till denieras även faktorer som skall tas med i beräkningen när ett examensarbete innehåller er än en student. Studierektorn kan lägga till examinatorer och sedan för varje examinator deniera hur mycket arbetstid denne bör lägga på handledning för examensarbeten. Studierektorn kan se alla examinatorer denne lagt till och hur mycket tid de lagt på handledning det aktuella budgetåret i förhållande till hur mycket tid de förväntas lägga på detta. Studierektorsvyn presenteras i gur 5 och gur 6.

Figur 5: Studierektorsvyn 'Specify tutoring hours'.

Figur 6: Studierektorsvyn 'Specied budget years'.

(17)

5.3.3 Examinatorsvy

I examinatorsvyn kan examinatorerna lägga till examensarbeten samt lägga till studenter på dessa. När examinatorn lägger till ett examensarbete dras handledningstid bort från dennes kvot. Examinatorn kan se alla examensarbeten som denne tagit på sig i en listvy där det är möjligt att se specik information om varje examensarbete samt markera dessa som avslutade/avbrutna. Exami- natorn har även en prolsida där det är möjligt att se hur många arbetstimmar denne förväntas lägga på examensarbeteshandledning under det aktuella bud- getåret, hur mycket tid denne har kvar tills kvoten är fylld samt de specicerade parametrarna för det aktuella budgetåret. Examinatorn kan även lägga till och uppdatera sitt arbetsområde. Examinatorsvyn presenteras i gur 7.

Figur 7: Examinatorsvyn.

5.3.4 Studentvy

Studenter kan se tillgängliga examinatorer, men har i övrigt inga rättigheter i systemet. Studenterna kan bara se de examinatorer som inte har uppfyllt sin kvot under det aktuella budgetåret. Studentvyn visas i gur 8.

Figur 8: Studentvyn.

(18)

5.4 Beskrivning av ett specikt användarfall

Detta delkapitel beskriver ett av användarfallen som nns beskrivna i användar- fallsspecikationen (se Bilaga D). Det användarfall som beskrivs är 'Tillägg av examinatorer' som tillhör studierektorsvyn. Användarfallet beskrivs av gur 9.

Figur 9: Tillägg av examinatorer.

Figur 10: Diagram som visar hur de olika systemen och vyerna kommunicerar med varandra vid tillägg av examinatorer.

Användaren av systemet kommer först till systemets startsida. Sedan trycker denne på iken 'Log in' och skickas då vidare till KTH:s autentiseringstjänst.

Efter lyckad inloggning skickas användaren tillbaka till inloggningslen där det sker en kontroll av vilken typ av behörighet användaren har och loggar då in denne i EXIT (som i gur 10 representeras av Yii-ramverket). Sedan klickar användaren på iken 'Add examiner' som skickar vidare inparametern (använ- darnamnet på den examinator som skall tilläggas) till KTH:s LDAP-databas.

Där görs en kontroll att det är ett giltigt användarnamn och då skickas använ- daruppgifter från LDAP-databasen till EXIT och lagras i systemets databas.

När examinatorn har blivit tillagd i databasen skrivs ett meddelande ut i 'Add examiner' om att tilläggningen lyckades. Figur 10 ger en illustrativ bild av an- vändarfallet. Koden för användarfallet nns i Bilaga A.3.

(19)

EXIT - Examinatorer inom Informationsteknik 7 Systemtester

5.4.1 Källkodsler för användarfallet addexaminer.php

/exit/protected/views/site/pages/addexaminer.php login.php

/exit/protected/views/site/login.php UserIdentity.php

/exit/protected/components/UserIdentity.php connection.php

5.5 Spårbarhet

I användarfallsspecikationen (se Bilaga D) nns det möjlighet att spåra de källkodsler som används för de olika användarfallen.

6 Implementation

Detta kapitel beskriver hur systemet implementerades.

6.1 Databas

Databasen implementerades i PostgreSQL. Koden för att implementera databasen

nns i Bilaga B.

6.2 PHP

Systemet implementerades i PHP. Webbsidan genereras av ramverket som i sin tur renderar de skapade vyerna. Dessa kommunicerar inte med varandra (annat än i det fall när en vy anropar en popup-ruta vars kod ligger i en annan l).

Den största delen av koden i vyerna utgörs av databasförfrågningar, insättning av data och listning av bentlig data från databasen. Vad koden för de olika användarfallsvyerna gör nns specicerat i Bilaga A.

7 Systemtester

Under projektets gång har systemet testats kontinuerligt. Efter varje använ- darfall implementerats har systemet testats för att fastställa att det fungerar korrekt. De problem som upptäcktes under testningen kunde sedan åtgärdas.

7.1 Felkontroller

Alla inmatningsfält har felkontroller som upptäcker om användaren försöker mata in felaktig datatyp eller strängar längre än den specicerade maxlängden i databasen. Om detta sker kommer ett felmeddelande som beskriver orsaken till felet att skrivas ut.

(20)

EXIT - Examinatorer inom Informationsteknik 8 Diskussion

Om användaren inte fyller i alla obligatoriska fält skrivs ett felmeddelande ut som påpekar detta.

Systemet har felkontroller som gör att användaren inte kan lägga till information i fel ordning. Till exempel kan inte en examinator lägga till ett examensarbete om denne ej har några handledningstimmar specicerade för det aktuella bud- getåret.

När studierektorer och examinatorer läggs till i databasen kontrollerar systemet att dessa existerar i KTH:s LDAP-databas. Om de inte gör det skrivs ett felmeddelande ut.

7.2 Webbläsare

Vid utveckling av webbapplikationer är det viktigt att applikationen ser likadan ut i olika webbläsare. Detta kan ställa till med problem eftersom inte alla webb- läsare följer den angivna standarden helt. Systemet har testats och fungerar väl med de webbläsare som presenteras nedan.

• Mozilla Firefox 4

• Google Chrome 10

• Internet Explorer 8

• Internet Explorer 9

Dessa webbläsare valdes eftersom de antogs vara de vanligaste.

I Internet Explorer 8 ser webbsidan lite annorlunda ut eftersom stilmallarna som används inte verkar fungera i denna, vilket gör att sidan blir mindre es- tetiskt tilltalande. I Internet Explorer 9 fungerar stilmallarna bättre, bortsett från layouten på en popup-ruta. Systemets funktioner fungerar utan problem i båda versionerna.

8 Diskussion

I stort sett har det fungerat bra att arbeta med projektet. I början uppstod dock en del problem på grund av bristande PHP-kunskaper, vilket bland annat ledde till problem med att förstå strukturen på ramverket som användes. Detta resulterade i att MVC-arkitekturen som ramverket använder inte tillämpades i projektet.

I början av projektet användes användarberättelser för att deniera de olika deluppgifterna. Dessa byttes senare ut mot användarfall på grund av att dessa ansågs vara bättre lämpade för detta projekt. Användningen av användarfall underlättade systemutvecklingen då det var lätt att se om systemet hade den funktionalitet som krävdes för specika användarfall. Användarfallen gjorde det också lättare att upptäcka de möjliga felen som skulle kunna uppstå.

(21)

EXIT - Examinatorer inom Informationsteknik 8 Diskussion

8.1 Möjliga förbättringar

En möjlig utökning av systemet skulle kunna vara att skapa ytterligare en vy där examinatorer kan lägga in examensarbetesförslag och där studenter kan se och eventuellt kan anmäla sig till dessa. Det vill säga - utöka systemet så att det kan ta över den funktionalitet som Kistas exjobbspool erbjuder idag.

Något annat som skulle kunna förbättras är skydd mot SQL-injektioner, något som i dagsläget ej är helt implementerat. Systemet tillåter bara administratörer, studierektorer och examinatorer att skriva in något i systemet. Eftersom dessa troligen ej har onda avsikter har det antagits att skydd mot SQL-injektioner inte är nödvändigt i dagsläget. Skulle systemet utökas och er än de ovannämnda ha rättigheter att lägga till information torde det vara nödvändigt att göra systemet säkrare.

I dagsläget måste en examinator som lägger till en student på ett examensarbete specicera all information om studenten. Detta på grund av att studenten inte nödvändigtvis måste vara en student på KTH. En möjlig förbättring skulle kunna vara att låta examinatorn vid tillägg av studenter välja om studenten är en student på KTH eller annat universitet. Om det är en student på KTH skulle möjligheten nnas att hämta ut studentinformation från KTH:s LDAP-databas, (liknande det som görs vid tillägg av studierektorer och examinatorer), istället för att låta examinatorn skriva in den informationen.

(22)

EXIT - Examinatorer inom Informationsteknik 9 Källförteckning

9 Källförteckning

[1] Silberschatz, A. Database System Concepts. 6th edition. McGraw-Hill, 2011.

[2] PostgreSQL 7.2 Programmer's Guide. [www].

www.postgresql.org/les/documentation/pdf/7.2/programmer-7.2-US.pdf Hämtat 27 maj 2011.

[3] Matthew, N. Stones, R. Beginning Databases with PostgreSQL. From Novice to Professional. Apress, 2005.

[4] Welling, L. Thomson, L. PHP and MySQL Web Development. Sams Pub- lishing, 2001.

[5] Greenspan, J. Bulger, B. MySQL/PHP Database Applications. M & T Books, 2001.

[6] Stobart, S. Parsons, D. Dynamic Web Application Development using PHP and MySQL. Cengage Learning EMEA, 2008

[7] Cascading Style Sheets - An Introduction. [www].

http://www.csus.edu/training/handouts/workshops/css-introduction.pdf Hämtat 27 maj 2011.

[8] Karlstads Universitet - Central authentication service (CAS). [www].

http://www1.kau.se/corral/intra.lasso?page_id=2487 Hämtat 27 maj 2011.

[9] Tuttle, S, m..Understanding LDAP Design and Implementation. Redbooks, 2004.

[10] Lightweight Directory Access Protocol (LDAP). [www].

www.cs.rpi.edu/ hollingd/netprog/notes/ldap/ldap.pdf Hämtat 27 maj 2011.

[11] Winsett, J. Agile Web Application Development with Yii 1.1 and PHP.

Packt Publishing, 2010.

[12] Yii Framework. Model-View-Controller. [www].

http://www.yiiframework.com/doc/guide/1.1/sv/basics.mvc Hämtat 27 maj 2011.

(23)

EXIT - Examinatorer inom Informationsteknik A Listning av källkodsfiler

A Listning av källkodsler

A.1 Skapade källkodsler

addbudgetyear.php

/exit/protected/views/site/pages/addbudgetyear.php

Innehåller den kod som behövs för att lägga till ett budgetår.

adddegreeproject.php

/exit/protected/views/site/pages/adddegreeproject.php

Innehåller den kod som krävs för att lägga till ett examensarbete.

adddirector.php

/exit/protected/views/site/pages/adddirector.php

Innehåller den kod som krävs för att lägga till en studierektor i systemet.

addexaminer.php

/exit/protected/views/site/pages/addexaminer.php

Innehåller den kod som krävs för att lägga till en examinator i systemet.

availableexaminers.php

/exit/protected/views/site/pages/availableexaminers.php

Innehåller den kod som behövs för att visa tillgängliga examinatorer för examinatorer och studenter.

budgetyears.php

/exit/protected/views/site/pages/budgetyears.php

Innehåller den kod som krävs för att visa de specicerade budgetåren.

connection.php

Innehåller kod för uppkoppling mot databasen. Denna l inkluderas i alla ler som gör databasanrop.

directors.php

/exit/protected/views/site/pages/directors.php

Innehåller den kod som används för att visa de tillagda studierektorerna.

examiners.php

/exit/protected/views/site/pages/examiners.php

Innehåller den kod som behövs för att visa tillagda examinatorer för studierektorer.

help.php

/exit/protected/views/site/pages/help.php

Innehåller den kod som ger användaren information om lösningar till möjliga problem.

(24)

index.php

/exit/protected/views/site/index.php Innehåller koden för startsidan.

login.php

/exit/protected/views/site/login.php

Innehåller den kod som krävs för inloggning i systemet. Inkluderar len CAS.php.

mydegreeprojects.php

/exit/protected/views/site/pages/mydegreeprojects.php

Innehåller den kod som krävs för att visa alla tillagda examensarbeten för en specik examinator.

prole.php

/exit/protected/views/site/pages/prole.php

Innehåller kod för att visa prolinformation för en examinator.

showinfo.php /exit/showinfo.php

Innehåller kod som visar information om ett specikt examensarbete.

specifytutoringhours.php

/exit/protected/views/site/pages/specifytutoringhours.php

Innehåller den kod som krävs för att en studierektor skall kunna specicera antalet handledningstimmar för en examinator.

A.2 Modierade ler i ramverket

UserIdentity.php

/exit/protected/components/UserIdentity.php

Innehåller kod för autentisering av användare vid inloggning i ramverket. Denna kod ändrades så att Yii:s loginfunktion kunde användas utan att den behövde modieras.

main.php

/exit/protected/views/layouts/main.php

Innehåller kod för visning av de olika vyerna beroende på användarens be- hörigheter i systemet.

main.css

/exit/css/main.css

Innehåller kod för modiering av webbplatsens utseende.

screen.css

/exit/css/screen.css

Innehåller kod för modiering av webbplatsens utseende.

(25)

A.3 Exempel på källkodsl 'Add examiner'

// Add breadcrumbs to the page.

$this->pageTitle=Yii::app()->name . ' - Add examiner';

$this->breadcrumbs=array('Add examiner');

// Connect to the database.

include 'protected/connection.php';

// Function to show the input form function show_form () {

echo "<h1>Add examiner</h1>";

echo "<p>Please insert the username of the person you want to add as an examiner. Do not include \"@kth.se\".

</p>";

echo "<form method=\"POST\" action=\"\">";

echo "KTH-username <br /><input type=text name=\"mail\">

<br />";

echo "<br />";

echo "<input type=\"submit\" name=\"submit\"

value=\"Insert\">";

echo "</form>";

}

// Check if the user is a director.

if (Yii::app()->user->getState('director')) {

// If the user has not pressed the button, show the form.

if(!isset($_POST['submit'])) { show_form();

} else {

// Get the mail address from the form

$mail = $_POST["mail"];

// Check if the user didn't enter anything in the mail // address field.

if ($mail == NULL) {

echo ("<b><div class=\"box\">You must specify a username!</div></b>");

echo ("<p></p>");

show_form();

}else {

// Connect to KTH's LDAP.

$ldapconn=ldap_connect("ldap.kth.se");

if(!$ldapconn) {

fwrite(STDERR, "Could not connect to LDAP server.");

exit(1);

}// Try to bind to the LDAP.

if(!ldap_bind($ldapconn)) {

fwrite(STDERR, "Could not bind to LDAP server.");

exit(1);

}// Do a LDAP search for the the specified mail address.

(26)

$sru=ldap_search($ldapconn, "ou=Addressbook,dc=kth, dc=se","ugUsername=$mail");

// Get the entries from the search.

$infouser = ldap_get_entries($ldapconn, $sru);

ldap_unbind($ldapconn);

// If the search was unsuccessful, print an error message.

if (!isset($infouser[0]["givenname"][0])) {

echo "<div class=\"box\"><b>ERROR: The username does not exist in LDAP. Try again!</b></div>";

echo ("<p></p>");

show_form();

}else {

// Get first name and last name from the search results.

$first_name = utf8_decode($infouser[0]["givenname"][0]);

$last_name = utf8_decode($infouser[0]["sn"][0]);

// Get this director's mail

$director_mail = Yii::app()->user->getName();

// Do a query to check if the examiner already exists // in the database.

$result = pg_query($connection, "SELECT mail FROM EXAMINER WHERE mail = '$mail';");

// Count the result from the query.

$rows = pg_num_rows($result);

// Check whether the examiner already exists // in the database.

if ($rows == 1) {

// Show error message.

echo ("<div class=\"box\"><b>$first_name $last_name already exists the database!</b></div>");

echo ("<p></p>");

show_form();

}else {

// Insert the examiner into the database.

pg_query($connection, "INSERT INTO EXAMINER

VALUES ('$mail','$first_name','$last_name','', '$director_mail')");

// Print success message when done.

echo ("<h2>Success</h2>");

echo ("You added examiner <b>$first_name

$last_name</b> with mail <b>$mail@kth.se</b>.");

} } } } }else {

// Print error message.

echo "<div class=\"box\"><b>Please log in before trying to add an examiner!</b></div>";

(27)

}// Close the database connection.

pg_close($connection);

?>

(28)

EXIT - Examinatorer inom Informationsteknik B Databaskod

B Databaskod

CREATE TABLE ADMIN (

mail VARCHAR(20) PRIMARY KEY, first_name VARCHAR(60) NOT NULL, last_name VARCHAR(60) NOT NULL);

CREATE TABLE DIRECTOR_OF_STUDIES ( mail VARCHAR(20) PRIMARY KEY, first_name VARCHAR(60) NOT NULL, last_name VARCHAR(60) NOT NULL);

CREATE TABLE EXAMINER (

mail VARCHAR(20) PRIMARY KEY, first_name VARCHAR(60) NOT NULL, last_name VARCHAR(60) NOT NULL, area VARCHAR(100),

director_mail VARCHAR(20));

CREATE TABLE BUDGET_YEAR ( director_mail VARCHAR(60), budget_year INTEGER,

master_hours INTEGER NOT NULL, bachelor_hours INTEGER NOT NULL, factor_two DOUBLE PRECISION NOT NULL, factor_three DOUBLE PRECISION NOT NULL, factor_four DOUBLE PRECISION NOT NULL, factor_five DOUBLE PRECISION NOT NULL, factor_six DOUBLE PRECISION NOT NULL, factor_seven DOUBLE PRECISION NOT NULL, factor_eight DOUBLE PRECISION NOT NULL, factor_nine DOUBLE PRECISION NOT NULL, factor_ten DOUBLE PRECISION NOT NULL, PRIMARY KEY(budget_year, director_mail), FOREIGN KEY (director_mail) REFERENCES

DIRECTOR_OF_STUDIES(mail) ON DELETE CASCADE);

CREATE TABLE EXAMINER_WORK_YEAR ( budget_year INTEGER,

director_mail VARCHAR(60), examiner_mail VARCHAR(20), tutoring_hours INTEGER,

remaining_tutoring_hours INTEGER,

PRIMARY KEY (budget_year, director_mail, examiner_mail), FOREIGN KEY (budget_year,director_mail)

REFERENCES BUDGET_YEAR(budget_year,director_mail) ON DELETE CASCADE,

FOREIGN KEY (examiner_mail) REFERENCES EXAMINER(mail) ON DELETE CASCADE);

CREATE TABLE DEGREE_PROJECT ( id SERIAL,

examiner_mail VARCHAR(60),

(29)

EXIT - Examinatorer inom Informationsteknik B Databaskod

number_of_students INTEGER,

description VARCHAR(200) NOT NULL, credits INTEGER NOT NULL,

start_date DATE NOT NULL, stop_date DATE NOT NULL, in_progress BOOLEAN, out_of_date BOOLEAN,

all_information_specified BOOLEAN, PRIMARY KEY (id, examiner_mail), FOREIGN KEY (examiner_mail)

REFERENCES EXAMINER(mail) ON DELETE CASCADE);

CREATE TABLE COMPANY ( project_id INTEGER,

examiner_mail VARCHAR(60), name VARCHAR(60) NOT NULL, address VARCHAR (100), phone_number VARCHAR(30), tutor VARCHAR (60),

PRIMARY KEY(project_id, examiner_mail), FOREIGN KEY (project_id, examiner_mail) REFERENCES DEGREE_PROJECT (id, examiner_mail) ON DELETE CASCADE);

CREATE TABLE STUDENT (

personal_number VARCHAR(10), project_id INTEGER,

examiner_mail VARCHAR(60), first_name VARCHAR(60) NOT NULL, last_name VARCHAR(60) NOT NULL, program VARCHAR(10),

kth_mail VARCHAR(30),

alternative_mail VARCHAR(30),

PRIMARY KEY (personal_number, project_id, examiner_mail), FOREIGN KEY (project_id,examiner_mail) REFERENCES

DEGREE_PROJECT(id,examiner_mail) ON DELETE CASCADE);

(30)

ANVÄNDARFALLSMODELL

EXIT Examinatorer inom informationsteknik 15 juni 2011

(31)

Användarfallsmodell Innehåll

Innehåll

1 Inledning 1

2 Användarfallsdiagram 1

3 Aktörskatalog 2

4 Användarfallskatalog 2

(32)

Användarfallsmodell 2 Användarfallsdiagram

1 Inledning

Syftet med detta dokument är att ge en överblick över hur systemet fungerar, vilka aktörer som förväntas använda systemet och vad dessa kan göra i systemet.

2 Användarfallsdiagram

Figur 1 visar de primära användarfallen för systemet. Korta beskrivningar av aktörerna och användarfallen nns i användarfalls- respektive aktörskatalogen.

Figur 1: Primära användarfall.

(33)

Användarfallsmodell 4 Användarfallskatalog

3 Aktörskatalog

Tabellen nedan visar vilka aktörer som nns samt namn och en kort beskrivning av dessa.

Figur 2: Aktörskatalog.

4 Användarfallskatalog

Tabellen nedan visar användarfallen.

Figur 3: Användarfallskatalog.

(34)

ANVÄNDARFALLSSPECIFIKATIONER

EXIT Examinatorer inom informationsteknik 15 juni 2011

(35)

Användarfall Innehåll

Innehåll

1 Inledning 1

2 Tillägg av studierektorer 1

2.1 Förutsättningar . . . . 1 2.2 Basöde . . . . 1 2.3 Alternativa öden . . . . 2 2.3.1 Studierektorn nns redan i databasen . . . . 2 2.3.2 Studierektorn nns inte i KTH:s LDAP-databas . . . . . 2 2.4 Källkodsler för användarfallet . . . . 2

3 Visning av tillagda studierektorer 2

3.1 Förutsättningar . . . . 2 3.2 Basöde . . . . 3 3.3 Alternativa öden . . . . 3 3.3.1 Administratören har ej lagt till någon studierektor . . . . 3 3.4 Källkodsler för användarfallet . . . . 3

4 Tillägg av budgetår 4

4.1 Förutsättningar . . . . 4 4.2 Basöde . . . . 4 4.3 Alternativa öden . . . . 5 4.3.1 Studierektorn glömmer att fylla i obligatoriska fält . . . . 5 4.3.2 Studierektorn råkar skriva in felaktig datatyp . . . . 5 4.3.3 Studierektorn skriver in för många tecken . . . . 5 4.3.4 Det angivna budgetåret är redan specicerat . . . . 5 4.4 Källkodsler för användarfallet . . . . 5

5 Visning av specicerade budgetår 5

5.1 Förutsättningar . . . . 5 5.1.1 För en studierektor . . . . 6 5.1.2 För en examinator . . . . 6 5.2 Basöde . . . . 6 5.2.1 För en studierektor . . . . 6 5.2.2 För en examinator . . . . 7 5.3 Alternativa öden . . . . 7 5.3.1 Studierektorn har inte specicerat något budgetår . . . . 7 5.4 Källkodsler för användarfallet . . . . 7

6 Tillägg av examinatorer 7

6.1 Förutsättningar . . . . 7 6.2 Basöde . . . . 8 6.3 Alternativa öden . . . . 8 6.3.1 Examinatorn nns redan i databasen . . . . 8 6.3.2 Examinatorn nns inte i KTH:s LDAP-databas . . . . 9 6.4 Källkodsler för användarfallet . . . . 9

7 Visning av tillgängliga examinatorer 9

7.1 Förutsättningar . . . . 9 7.1.1 För en studierektor . . . . 9 7.1.2 För en examinator . . . 10 7.1.3 För en student . . . 10 7.2 Basöde . . . 10 7.3 Alternativa öden . . . 10

(36)

7.3.1 Det nns inget tillagt budgetår . . . 11 7.3.2 Examinatorn är ej tillagd på det aktuella budgetåret . . . 11 7.4 Källkodsler för användarfallet . . . 11 8 Specicering / uppdatering av handledningstimmar 11 8.1 Förutsättningar . . . 12 8.2 Basöde . . . 12 8.3 Alternativa öden . . . 12 8.3.1 Studierektorn har ej specicerat handledningstimmar . . . 12 8.3.2 Studierektorn råkar skriva in felaktig datatyp . . . 12 8.3.3 Det nns inget tillagt budgetår . . . 12 8.4 Källkodsler för användarfallet . . . 13

9 Visning av kvarvarande handledningstimmar 13

9.1 Förutsättningar . . . 13 9.2 Basöde . . . 14 9.2.1 För en studierektor . . . 14 9.2.2 För en examinator . . . 14 9.3 Alternativa öden . . . 14 9.3.1 Det nns inget tillagt budgetår . . . 14 9.3.2 Examinatorn har inga handledningstimmar specicerade . 14 9.4 Källkodsler för användarfallet . . . 15 10 Tillägg och uppdatering av arbetsområde för examinatorer 15 10.1 Förutsättningar . . . 15 10.2 Basöde . . . 15 10.3 Alternativa öden . . . 16 10.3.1 Examinatorn skriver in för många tecken . . . 16 10.4 Källkodsler för användarfallet . . . 16 11 Tillägg av examensarbeten till examinatorskvot 16 11.1 Förutsättningar . . . 16 11.2 Basöde . . . 17 11.3 Alternativa öden . . . 17 11.3.1 Examinatorn glömmer fylla i något obligatoriskt fält . . . 18 11.3.2 Examinatorn fyller i ett ogiltigt datum . . . 18 11.3.3 Examinatorn skriver in för många tecken . . . 18 11.4 Källkodsler för användarfallet . . . 18

12 Visning av tillagda examensarbeten 18

12.1 Förutsättningar . . . 19 12.2 Basöde . . . 19 12.3 Alternativa öden . . . 19 12.3.1 Det nns inga examensarbeten . . . 19 12.4 Källkodsler för användarfallet . . . 19 13 Visning av specik information om examensarbeten 20 13.1 Förutsättningar . . . 20 13.2 Basöde . . . 20 13.3 Källkodsler för användarfallet . . . 21

(37)

14 Markering av examensarbeten som avslutade / avbrutna 21 14.1 Förutsättningar . . . 21 14.2 Basöde . . . 22 14.3 Alternativa öden . . . 22 14.3.1 Det nns inga examensarbeten . . . 22 14.4 Källkodsler för användarfallet . . . 22

(38)

Användarfall 2 Tillägg av studierektorer

1 Inledning

Syftet med detta dokument är att beskriva de olika användarfallen, vilka förut- sättningar som måste vara uppfyllda samt förklara basödet och alternativa

öden för varje användarfall.

2 Tillägg av studierektorer

Detta användarfall beskriver hur en administratör lägger till en studierektor i systemet. Figur 1 ger en illustrativ bild av användarfallet.

Figur 1: Tillägg av studierektorer

2.1 Förutsättningar

För att en administratör skall kunna lägga till en studierektor krävs följande:

• Administratören måste ha ett giltigt inloggningskonto på KTH.

• Administratören måste ha blivit tillagd som administratör i databasen.

• Studierektorn som skall läggas till måste ha ett giltigt inloggningskonto på KTH.

2.2 Basöde

Detta kapitel beskriver basödet.

• Administratören loggar in i systemet genom att klicka på 'Log in'.

• Systemet skickar administratören vidare till KTH:s inloggningssida.

• Administratören fyller i dennes inloggningsuppgifter, klickar på 'Logga in' och skickas tillbaka till systemet.

• Systemet skriver ut att inloggningen lyckades och kontrollerar rättigheter- na för den inloggade aktören.

• Administratören klickar på iken 'Add director of studies'.

(39)

Användarfall 3 Visning av tillagda studierektorer

• Administratören skriver in ett giltigt KTH-användarnamn.

• Administratören klickar på 'Insert'.

• Systemet kontrollerar att KTH-användarnamnet nns i KTH:s LDAP- databas.

• Systemet hämtar ut för- och efternamn för den specika studierektorn och lagrar informationen i databasen.

• Systemet visar att den tillagda studierektorn nu nns i systemet.

2.3 Alternativa öden

Detta kapitel beskriver vad som händer om något oväntat eller något fel inträar.

2.3.1 Studierektorn nns redan i databasen

Om studierektorn redan nns i databasen skriver systemet ut detta.

2.3.2 Studierektorn nns inte i KTH:s LDAP-databas

Om administratören angivit ett felaktigt KTH-användarnamn kommer systemet att skriva ut ett felmeddelande.

2.4 Källkodsler för användarfallet

adddirector.php

/exit/protected/views/site/pages/adddirector.php login.php

/exit/protected/components/UserIdentity.php connection.php

3 Visning av tillagda studierektorer

Detta användarfall beskriver hur en administratör lägger till en studierektor i systemet. Figur 2 ger en illustrativ bild av användarfallet.

För att en administratör skall kunna se tillagda studierektorer krävs följande:

• Administratören måste ha ett giltigt inloggningskonto på KTH.

• Administratören måste ha blivit tillagd som administratör i databasen.

• Någon administratör måste ha lagt till en studierektor.

(40)

Användarfall 3 Visning av tillagda studierektorer

Figur 2: Visning av tillagda studierektorer

3.2 Basöde

• Administratören loggar in i systemet genom att klicka på 'Log in'.

• Systemet skickar administratören vidare till KTH:s inloggningssida.

• Administratören fyller i dennes inloggningsuppgifter, klickar på 'Logga in' och skickas tillbaka till systemet.

• Administratören klickar på iken 'Directors of studies'.

• Systemet visar en lista på tillagda studierektorer.

3.3 Alternativa öden

Detta kapitel beskriver vad som händer om något oväntat eller något fel inträar.

3.3.1 Administratören har ej lagt till någon studierektor

Om någon administratör ej har lagt till någon studierektor kommer följaktligen ingen att se någon.

3.4 Källkodsler för användarfallet

directors.php

/exit/protected/views/site/pages/directors.php login.php

/exit/protected/components/UserIdentity.php

(41)

Användarfall 4 Tillägg av budgetår

connection.php

4 Tillägg av budgetår

Detta användarfall beskriver hur en studierektor lägger till ett budgetår i systemet. Figur 3 ger en illustrativ bild av användarfallet.

Figur 3: Tillägg av budgetår

För att en studierektor skall kunna lägga till ett budgetår krävs följande:

• Studierektorn måste ha ett giltigt inloggningskonto på KTH.

• Studierektorn måste ha blivit tillagd som studierektor i databasen.

4.2 Basöde

• Studierektorn loggar in i systemet genom att klicka på 'Log in'.

• Systemet skickar studierektorn vidare till KTH:s inloggningssida.

• Studierektorn skriver in dennes inloggningsuppgifter, klickar på 'Logga in' och skickas tillbaka till systemet.

• Studierektorn klickar på iken 'Add budget year'.

• Studierektorn specicerar år, antalet handledningtimmar som förväntas läggas på de olika typerna av examensarbeten, samt faktorer som skall multipliceras med de specicerade timmarna om er än en student läggs till på ett examensarbete.