EXIT - EXAMINATORER INOM INFORMATIONSTEKNIKkth.diva-portal.org/smash/get/diva2:432747/FULLTEXT01.pdf · CSS (Cascading Style Sheets) (stilmallar) är ett språk som anändsv för

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

TRITA-ICT-EX-2011:131

EXIT � EXAMINATORER INOM

INFORMATIONSTEKNIK

15 juni 2011

Sara Hägglund � Linda [email protected] � [email protected]

KUNGLIGA TEKNISKA HÖGSKOLANSkolan för informations- och

kommunikationsteknik

Sammanfattning

Det är inte lätt för en examinator att hålla ordning på antalet arbetstimmardenne 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 kanlägga till budgetår och examinatorer. Genom att sedan speci�cera hur myck-et arbetstid varje examinator skall lägga på handledning vid examensarbetengör studierektorn det möjligt för examinatorerna att hålla reda på hur myckettid de förväntas lägga på handledning och hur mycket tid de har kvar för detaktuella budgetåret. Även studenter har nytta av systemet eftersom de kan sevilka 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 hourshe/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, di�erent rules may apply. EXIT is a system where directors of studiescan add budget years and examiners. By specifying how much working hourseach examiner shall use for tuition of degree projects, the director of studiesmakes it possible for the examiners to keep track of how much time they areexpected to spend tutoring degree projects, and how much time they have leftfor the current budget year. Students can also bene�t from the system becausethey can see which examiners that are available when they are looking for anexaminer to their degree project.

EXIT - Examinatorer inom Informationsteknik Innehåll

Innehåll

1 Inledning 1

1.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Arbetsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Förstudie 1

2.1 Databashanteringssystem . . . . . . . . . . . . . . . . . . . . . . 22.1.1 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.2 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.3 PostgreSQL vs MySQL . . . . . . . . . . . . . . . . . . . 2

2.2 Webbutveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2.1 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2.2 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2.3 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.5 Ramverk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.5.1 Yii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.6 Omvärldsanalys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Systemspeci�kation 5

3.1 Utvecklingsmiljö . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Systemkrav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Användargrupper . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.3.1 Administratör . . . . . . . . . . . . . . . . . . . . . . . . . 53.3.2 Studierektor . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3.3 Examinatorer . . . . . . . . . . . . . . . . . . . . . . . . . 63.3.4 Studenter . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.4 Installationsspeci�kation . . . . . . . . . . . . . . . . . . . . . . . 63.5 Arbetsprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.6 Säkerhetskrav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Systemarkitektur 7

4.1 Databas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.2 KTH:s inloggningssystem . . . . . . . . . . . . . . . . . . . . . . 74.3 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.4 Webbserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5 Design 9

5.1 Databas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95.2 Gra�skt gränssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . 95.3 Aktörsvyer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.3.1 Administratörsvy . . . . . . . . . . . . . . . . . . . . . . . 105.3.2 Studierektorsvy . . . . . . . . . . . . . . . . . . . . . . . . 115.3.3 Examinatorsvy . . . . . . . . . . . . . . . . . . . . . . . . 125.3.4 Studentvy . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.4 Beskrivning av ett speci�kt användarfall . . . . . . . . . . . . . . 135.4.1 Källkods�ler för användarfallet . . . . . . . . . . . . . . . 14

5.5 Spårbarhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6 Implementation 14

6.1 Databas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146.2 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Sara Hägglund, Linda Eriksson i 15 juni 2011

EXIT - Examinatorer inom Informationsteknik Innehåll

7 Systemtester 14

7.1 Felkontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147.2 Webbläsare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

8 Diskussion 15

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

9 Källförteckning 17

A Listning av källkods�ler 18

A.1 Skapade källkods�ler . . . . . . . . . . . . . . . . . . . . . . . . . 18A.2 Modi�erade �ler i ramverket . . . . . . . . . . . . . . . . . . . . . 19A.3 Exempel på källkods�l � 'Add examiner' . . . . . . . . . . . . . . 20

B Databaskod 23

C Användarfallsmodell

D Användarfallsspeci�kationer

Sara Hägglund, Linda Eriksson ii 15 juni 2011

EXIT - Examinatorer inom Informationsteknik 2 Förstudie

1 Inledning

Att tilldela examinatorer vid examensarbeten kan vara en arbetskrävande uppgifteftersom det är många faktorer som skall tas hänsyn till. Till exempel får ex-aminatorer per budgetår ett visst antal tilldelade timmar som skall användastill handledning vid examensarbeten. För att studierektorerna (och examinator-erna) skall hålla reda på hur många timmar en viss examinator har använt avdessa timmar är det praktiskt att ha ett system som hjälper till att hålla redapå 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 examensarbeteför kandidatexamen och ett för master/civilingenjörsexamen, istället för baraett för civilingenjörsexamen. Detta innebär att antalet examensarbeten har ökatkraftigt, vilket har gjort att det krävs mer arbete för studierektorerna att hittaexaminatorer till dessa.

1.2 Syfte

Syftet med examensarbetet är att skapa ett system som hjälper studierektoreratt hålla koll på hur mycket handledningstid en examinator har lagt på exam-ensarbeten under det aktuella budgetåret. Ytterligare ett syfte med systemetär att examinatorer själva skall kunna hålla reda på den handledningstid somde förväntas lägga på examensarbeten. Ifall de har mycket kvarvarande han-dledningstid uppmuntras de att ta på sig �er examensarbeten så att deras han-dledningskvot fylls. Ett annat syfte med systemet är att studenter ska kunna setillgä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 avprojektet användes användarberättelser (user stories) som är en form av in-dexkort där en eller några få meningar de�nierar systemkrav. Senare i projektetbyttes dessa ut mot användarfall (use cases). Dessa innehåller en händelse sombeskriver hur en aktör skall kunna använda systemet. Orsaken till bytet var attdessa ansågs vara mer lämpliga för detta projekt. Användarfallsmodellen ochanvändarfallsspeci�kationerna �nns som bilagor.

2 Förstudie

Det fanns ett antal utvecklingsmiljöer att välja mellan när applikationen skulleutvecklas. Ett önskemål från kunden var att PHP skulle användas och för attkunna 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 liknandesystem tidigare.

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

Sara Hägglund, Linda Eriksson 1 15 juni 2011


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årför Structured Query Language).

2.1.1 PostgreSQL

PostgreSQL är ett relationsdatabashanteringssystem baserat på öppen källkodoch är släppt under BSD-licens, vilket innebär att vem som helst kan använda,modi�era 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 exem-pel C, C++, Java, Perl och PHP, och följer i stort sett branschens standard förfrå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 ytterligarefunktioner som det kan vara svårt att �nna i andra system [3].

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

2.1.2 MySQL

MySQL är ett relationsdatabashanteringssystem som ger användaren möjlighetatt 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 avUNIX-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 sparadeprocedurer, 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 dettaprojekt.

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



2.2 Webbutveckling

Vid webbutveckling kan �era olika verktyg användas. Nedan listas några avdessa.

2.2.1 HTML

HTML (HyperText Markup Language) är ett instrument för att skapa webbsi-dor. Huvudtanken bakom HTML är att det skall möjliggöra ihoplänkning avdokument 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 gavsut 1998 inkluderades bland annat skriptspråk och style sheets (stilmallar) [6].

Mellan år 2000 och 2002 utvecklades XHTML som är en utökning av HTMLmen 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älpertill 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 modi�eras [6].

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

Webbstandarder planerar att i framtida versioner av HTML ta bort stödet förfont-taggar. (En font-tagg ändrar textens utseende på en webbsida). Detta kom-mer leda till att de som programmerar webbsidor kommer att bli tvungna attanvända CSS. Eftersom font-taggar inte behöver användas resulterar detta i atthemsidan upptar mindre diskutrymme vilket gör att sidorna visas snabbare iwebblä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å attdet 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ångsidan 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ökareav 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 opera-tivsystem och webbservrar som t.ex Windows, Unix, Apache och ISS. PHP harockså inbyggt stöd för mycket som kan komma till användning vid skapandetav webbsidor som t.ex PostgreSQL, MySQL, LDAP, CAS och mycket mer [5].(LDAP och CAS beskrivs senare i kapitlet.)



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 baseraspå öppen källkod �nns många programmerare som dagligen försöker förbättrakä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 an-nat av universitet för att autentisera användare. Genom att använda CAS kansäkerheten på systemet öka. Detta eftersom lösenord bara behöver skickas tillCAS-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 ärtvå olika saker. När en användare loggar ut ur CAS innebär det att denne ejkan logga in på andra system som använder CAS utan att göra en ny inloggn-ing. Däremot påverkar inte en utloggning ur CAS aktiva sessioner mot redanuppkopplade system [8].

Användaren loggar ut från de använda systemen på vanligt sätt, men varjeanslutet 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 utfrån CAS, varför det rekommenderas att användare alltid stänger webbläsarenefter att ha använt system som använder CAS [8].

2.4 LDAP

LDAP (Lightweight Directory Access Protocol) är en standardmetod för åtkomstoch 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/svaroch informationen i LDAP uppdateras inte lika frekvent som i en vanlig databas[10].

Varje rad i katalogen refereras av en speci�k 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 enprogrammerare att snabbt bygga upp ett fungerande system.

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

2.5.1 Yii

Yii är ett komponentbaserat PHP5-ramverk som släpptes 2008. Namnet Yii ären akronym för Yes (som uttalas Yee) och står för easy, e�cient and extensible.Yii gör det lättare att skapa och underhålla stora webbapplikationer [11].


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 modi�erakoden för det egna systemets behov [11].

Alla Yii-applikationer bygger påModel-View-Controller (MVC)-arkitektur, vilketinnebä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åverkara�ä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 systemtidigare, dock utan resultat.

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

3 Systemspeci�kation

I detta kapitel de�nieras systemkraven samt de användargrupper som skall kun-na använda systemet.

3.1 Utvecklingsmiljö

Systemet skall implementeras i PHP kombinerat med något databashanter-ingssystem.

3.2 Systemkrav

Alla systemkrav presenteras i användarfallsmodellen (se Bilaga C). Mer detal-jerad information �nns i användarfallsspeci�kationerna (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 inlog-gningssystem, 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, speci�ceraantalet timmar för varje examinator samt lägga till och se speci�cerade budgetår.De skall också kunna se antalet kvarvarande handledningstimmar och uppdateradessa för varje examinator.


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 examensarbetenoch se speci�k information om dessa. Denne skall även kunna markera examen-sarbeten som avslutade/avbrutna.

3.3.4 Studenter

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

3.4 Installationsspeci�kation

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.phpDet 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 direkti databashanteringssystemet till skillnad från i alla andra fall där tilläggav information görs via det gra�ska 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 speci�cerar handledningstimmar för examinatorerna på detaktuella 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 kunnaanvända systemet, och därmed skall dennes behörighet kunna veri�eras. Ingaobehöriga skall kunna läsa, skriva till eller på något annat sätt modi�era sys-temet.


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 geren 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 attfungera. Denna information lagras i tabeller som presenteras i ett UML-diagrami 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:sinloggningssida. Då KTH redan har en be�ntlig inloggningstjänst behövdes ejnågon sådan implementeras. Det enda som krävdes var att koppla ihop detutvecklade systemet med inloggningstjänsten.


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 deninloggade 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.)


EXIT - Examinatorer inom Informationsteknik 5 Design

5 Design

I detta kapitel presenteras databasdesignen, det gra�ska gränssnittet, de skapadeaktörsvyerna samt en beskrivning av ett speci�kt 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 Gra�skt gränssnitt

Systemets gra�ska 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ändarenhar.



5.3 Aktörsvyer

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

De olika användargrupperna är: administratörer, studierektorer, examinatoreroch 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 al-la tillgängliga studierektorer. Dessa funktioner �nns endast om den inloggadeanvändaren har administratörsbehörighet till systemet. Administratörsvyn pre-senteras i �gur 4.

Figur 4: Administratörsvyn.



5.3.2 Studierektorsvy

I studierektorsvyn kan studierektorerna lägga till budgetår och de�niera 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 de�nieras även faktorer somskall tas med i beräkningen när ett examensarbete innehåller �er än en stu-dent. Studierektorn kan lägga till examinatorer och sedan för varje examinatorde�niera hur mycket arbetstid denne bör lägga på handledning för examensar-beten. Studierektorn kan se alla examinatorer denne lagt till och hur myckettid de lagt på handledning det aktuella budgetåret i förhållande till hur myckettid 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 � 'Speci�ed budget years'.



5.3.3 Examinatorsvy

I examinatorsvyn kan examinatorerna lägga till examensarbeten samt lägga tillstudenter på dessa. När examinatorn lägger till ett examensarbete dras han-dledningstid bort från dennes kvot. Examinatorn kan se alla examensarbetensom denne tagit på sig i en listvy där det är möjligt att se speci�k informationom varje examensarbete samt markera dessa som avslutade/avbrutna. Exami-natorn har även en pro�lsida där det är möjligt att se hur många arbetstimmardenne 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 speci�ceradeparametrarna för det aktuella budgetåret. Examinatorn kan även lägga till ochuppdatera 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 isystemet. Studenterna kan bara se de examinatorer som inte har uppfyllt sinkvot under det aktuella budgetåret. Studentvyn visas i �gur 8.

Figur 8: Studentvyn.



5.4 Beskrivning av ett speci�kt användarfall

Detta delkapitel beskriver ett av användarfallen som �nns beskrivna i användar-fallsspeci�kationen (se Bilaga D). Det användarfall som beskrivs är 'Tillägg avexaminatorer' 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 kommunicerarmed varandra vid tillägg av examinatorer.

Användaren av systemet kommer först till systemets startsida. Sedan tryckerdenne på �iken 'Log in' och skickas då vidare till KTH:s autentiseringstjänst.Efter lyckad inloggning skickas användaren tillbaka till inloggnings�len där detsker en kontroll av vilken typ av behörighet användaren har och loggar då indenne i EXIT (som i �gur 10 representeras av Yii-ramverket). Sedan klickaranvä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 'Addexaminer' 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.


EXIT - Examinatorer inom Informationsteknik 7 Systemtester

5.4.1 Källkods�ler 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

/exit/protected/connection.php

5.5 Spårbarhet

I användarfallsspeci�kationen (se Bilaga D) �nns det möjlighet att spåra dekällkods�ler 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 sintur 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ättningav data och listning av be�ntlig data från databasen. Vad koden för de olikaanvändarfallsvyerna gör �nns speci�cerat 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 fungerarkorrekt. 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ökermata in felaktig datatyp eller strängar längre än den speci�cerade maxlängdeni databasen. Om detta sker kommer ett felmeddelande som beskriver orsakentill felet att skrivas ut.


EXIT - Examinatorer inom Informationsteknik 8 Diskussion

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

Systemet har felkontroller som gör att användaren inte kan lägga till informationi fel ordning. Till exempel kan inte en examinator lägga till ett examensarbeteom denne ej har några handledningstimmar speci�cerade för det aktuella bud-getåret.

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

7.2 Webbläsare

Vid utveckling av webbapplikationer är det viktigt att applikationen ser likadanut 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älmed 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 stilmallarnasom 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, bortsettfrån layouten på en popup-ruta. Systemets funktioner fungerar utan problem ibåda versionerna.

8 Diskussion

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

I början av projektet användes användarberättelser för att de�niera de olikadeluppgifterna. Dessa byttes senare ut mot användarfall på grund av att dessaansågs vara bättre lämpade för detta projekt. Användningen av användarfallunderlättade systemutvecklingen då det var lätt att se om systemet hade denfunktionalitet som krävdes för speci�ka användarfall. Användarfallen gjorde detockså lättare att upptäcka de möjliga felen som skulle kunna uppstå.


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 vydär examinatorer kan lägga in examensarbetesförslag och där studenter kan seoch eventuellt kan anmäla sig till dessa. Det vill säga - utöka systemet så attdet 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ågotsom i dagsläget ej är helt implementerat. Systemet tillåter bara administratörer,studierektorer och examinatorer att skriva in något i systemet. Eftersom dessatroligen 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ämndaha rättigheter att lägga till information torde det vara nödvändigt att görasystemet säkrare.

I dagsläget måste en examinator som lägger till en student på ett examensarbetespeci�cera all information om studenten. Detta på grund av att studenten intenödvändigtvis måste vara en student på KTH. En möjlig förbättring skullekunna vara att låta examinatorn vid tillägg av studenter välja om studenten ären student på KTH eller annat universitet. Om det är en student på KTH skullemö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älletför att låta examinatorn skriva in den informationen.


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.pdfHämtat 27 maj 2011.

[3] Matthew, N. Stones, R. Beginning Databases with PostgreSQL. From Noviceto 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 PHPand MySQL. Cengage Learning EMEA, 2008

[7] Cascading Style Sheets - An Introduction. [www].http://www.csus.edu/training/handouts/workshops/css-introduction.pdfHämtat 27 maj 2011.

[8] Karlstads Universitet - Central authentication service (CAS). [www].http://www1.kau.se/corral/intra.lasso?page_id=2487Hä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.pdfHä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.mvcHämtat 27 maj 2011.


EXIT - Examinatorer inom Informationsteknik A Listning av källkodsfiler

A Listning av källkods�ler

A.1 Skapade källkods�ler

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 exam-inatorer och studenter.

budgetyears.php

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

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

connection.php

/exit/protected/connection.php

Innehåller kod för uppkoppling mot databasen. Denna �l inkluderas i alla �lersom 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 studierek-torer.

help.php

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

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



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 enspeci�k examinator.

pro�le.php

/exit/protected/views/site/pages/pro�le.php

Innehåller kod för att visa pro�linformation för en examinator.

showinfo.php

/exit/showinfo.php

Innehåller kod som visar information om ett speci�kt examensarbete.

specifytutoringhours.php

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

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

A.2 Modi�erade �ler i ramverket

UserIdentity.php

/exit/protected/components/UserIdentity.php

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

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 modi�ering av webbplatsens utseende.

screen.css

/exit/css/screen.css

Innehåller kod för modi�ering av webbplatsens utseende.



A.3 Exempel på källkods�l � '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.



$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>[email protected]</b>.");

}

}

}

}

}

else {

// Print error message.

echo "<div class=\"box\"><b>Please log in

before trying to add an examiner!</b></div>";



}

// Close the database connection.

pg_close($connection);

?>


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 (



last_name VARCHAR(60) NOT NULL);

CREATE TABLE EXAMINER (



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,



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,


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,



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);


ANVÄNDARFALLSMODELL

EXIT � Examinatorer inom informationsteknik

15 juni 2011




Användarfallsmodell Innehåll

Innehåll

1 Inledning 1

2 Användarfallsdiagram 1

3 Aktörskatalog 2

4 Användarfallskatalog 2


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.


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.


ANVÄNDARFALLSSPECIFIKATIONER

EXIT � Examinatorer inom informationsteknik

15 juni 2011




Användarfall Innehåll

Innehåll

1 Inledning 1

2 Tillägg av studierektorer 12.1 Förutsättningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Bas�öde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3 Alternativa �öden . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.3.1 Studierektorn �nns redan i databasen . . . . . . . . . . . 22.3.2 Studierektorn �nns inte i KTH:s LDAP-databas . . . . . 2

2.4 Källkods�ler för användarfallet . . . . . . . . . . . . . . . . . . . 2

3 Visning av tillagda studierektorer 23.1 Förutsättningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.2 Bas�öde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.3 Alternativa �öden . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.3.1 Administratören har ej lagt till någon studierektor . . . . 33.4 Källkods�ler för användarfallet . . . . . . . . . . . . . . . . . . . 3

4 Tillägg av budgetår 44.1 Förutsättningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44.2 Bas�öde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44.3 Alternativa �öden . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.3.1 Studierektorn glömmer att fylla i obligatoriska fält . . . . 54.3.2 Studierektorn råkar skriva in felaktig datatyp . . . . . . . 54.3.3 Studierektorn skriver in för många tecken . . . . . . . . . 54.3.4 Det angivna budgetåret är redan speci�cerat . . . . . . . 5


5 Visning av speci�cerade budgetår 55.1 Förutsättningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5.1.1 För en studierektor . . . . . . . . . . . . . . . . . . . . . . 65.1.2 För en examinator . . . . . . . . . . . . . . . . . . . . . . 6

5.2 Bas�öde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65.2.1 För en studierektor . . . . . . . . . . . . . . . . . . . . . . 65.2.2 För en examinator . . . . . . . . . . . . . . . . . . . . . . 7

5.3 Alternativa �öden . . . . . . . . . . . . . . . . . . . . . . . . . . 75.3.1 Studierektorn har inte speci�cerat något budgetår . . . . 7


6 Tillägg av examinatorer 76.1 Förutsättningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76.2 Bas�öde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86.3 Alternativa �öden . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6.3.1 Examinatorn �nns redan i databasen . . . . . . . . . . . . 86.3.2 Examinatorn �nns inte i KTH:s LDAP-databas . . . . . . 9


7 Visning av tillgängliga examinatorer 97.1 Förutsättningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

7.1.1 För en studierektor . . . . . . . . . . . . . . . . . . . . . . 97.1.2 För en examinator . . . . . . . . . . . . . . . . . . . . . . 107.1.3 För en student . . . . . . . . . . . . . . . . . . . . . . . . 10

7.2 Bas�öde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107.3 Alternativa �öden . . . . . . . . . . . . . . . . . . . . . . . . . . 10



7.3.1 Det �nns inget tillagt budgetår . . . . . . . . . . . . . . . 117.3.2 Examinatorn är ej tillagd på det aktuella budgetåret . . . 11


8 Speci�cering / uppdatering av handledningstimmar 118.1 Förutsättningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128.2 Bas�öde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128.3 Alternativa �öden . . . . . . . . . . . . . . . . . . . . . . . . . . 12

8.3.1 Studierektorn har ej speci�cerat handledningstimmar . . . 128.3.2 Studierektorn råkar skriva in felaktig datatyp . . . . . . . 128.3.3 Det �nns inget tillagt budgetår . . . . . . . . . . . . . . . 12


9 Visning av kvarvarande handledningstimmar 139.1 Förutsättningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139.2 Bas�öde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

9.2.1 För en studierektor . . . . . . . . . . . . . . . . . . . . . . 149.2.2 För en examinator . . . . . . . . . . . . . . . . . . . . . . 14

9.3 Alternativa �öden . . . . . . . . . . . . . . . . . . . . . . . . . . 149.3.1 Det �nns inget tillagt budgetår . . . . . . . . . . . . . . . 149.3.2 Examinatorn har inga handledningstimmar speci�cerade . 14


10 Tillägg och uppdatering av arbetsområde för examinatorer 1510.1 Förutsättningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1510.2 Bas�öde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1510.3 Alternativa �öden . . . . . . . . . . . . . . . . . . . . . . . . . . 16

10.3.1 Examinatorn skriver in för många tecken . . . . . . . . . 1610.4 Källkods�ler för användarfallet . . . . . . . . . . . . . . . . . . . 16

11 Tillägg av examensarbeten till examinatorskvot 1611.1 Förutsättningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611.2 Bas�öde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1711.3 Alternativa �öden . . . . . . . . . . . . . . . . . . . . . . . . . . 17

11.3.1 Examinatorn glömmer fylla i något obligatoriskt fält . . . 1811.3.2 Examinatorn fyller i ett ogiltigt datum . . . . . . . . . . . 1811.3.3 Examinatorn skriver in för många tecken . . . . . . . . . 18


12 Visning av tillagda examensarbeten 1812.1 Förutsättningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1912.2 Bas�öde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1912.3 Alternativa �öden . . . . . . . . . . . . . . . . . . . . . . . . . . 19

12.3.1 Det �nns inga examensarbeten . . . . . . . . . . . . . . . 1912.4 Källkods�ler för användarfallet . . . . . . . . . . . . . . . . . . . 19

13 Visning av speci�k information om examensarbeten 2013.1 Förutsättningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2013.2 Bas�öde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2013.3 Källkods�ler för användarfallet . . . . . . . . . . . . . . . . . . . 21

Sara Hägglund, Linda Eriksson ii 15 juni 2011


14 Markering av examensarbeten som avslutade / avbrutna 2114.1 Förutsättningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2114.2 Bas�öde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2214.3 Alternativa �öden . . . . . . . . . . . . . . . . . . . . . . . . . . 22

14.3.1 Det �nns inga examensarbeten . . . . . . . . . . . . . . . 2214.4 Källkods�ler för användarfallet . . . . . . . . . . . . . . . . . . . 22

Sara Hägglund, Linda Eriksson iii 15 juni 2011

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 isystemet. 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 inloggningskontopå 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'.


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 speci�ka studierektorn ochlagrar 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 systemetatt skriva ut ett felmeddelande.

2.4 Källkods�ler för användarfallet

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

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

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

connection.php/exit/protected/connection.php

3 Visning av tillagda studierektorer

Detta användarfall beskriver hur en administratör lägger till en studierektor isystemet. 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.


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.1 Administratören har ej lagt till någon studierektor

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


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




Användarfall 4 Tillägg av budgetår


4 Tillägg av budgetår

Detta användarfall beskriver hur en studierektor lägger till ett budgetår i sys-temet. 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 speci�cerar år, antalet handledningtimmar som förväntasläggas på de olika typerna av examensarbeten, samt faktorer som skallmultipliceras med de speci�cerade timmarna om �er än en student läggstill på ett examensarbete.


Användarfall 5 Visning av specificerade budgetår

• Systemet lägger till informationen i databasen.

• Systemet skriver ut att tilläggningen av budgetåret lyckades.



4.3.1 Studierektorn glömmer att fylla i obligatoriska fält

Om studierektorn glömmer att fylla i obligatoriska fält skriver systemet ut ettfelmeddelande om att alla obligatoriska fält måste vara ifyllda.

4.3.2 Studierektorn råkar skriva in felaktig datatyp

Om studierektorn skriver in fel datatyp i något av de fält som väntar sig ettnumeriskt värde kommer systemet att skriva ut ett felmeddelande om detta.

4.3.3 Studierektorn skriver in för många tecken

Om studierektorn skriver in �er tecken i en textruta än vad som är speci�cerati databasen kommer systemet att skriva ut ett felmeddelande om detta.

4.3.4 Det angivna budgetåret är redan speci�cerat

Om det angivna budgetåret redan är speci�cerat kommer systemet att skrivaut ett felmeddelande om att budgetåret redan �nns.


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




5 Visning av speci�cerade budgetår

Detta användarfall beskriver hur en studierektor och en examinator ser speci�-cerade budgetår. Figur 4 ger en illustrativ bild av användarfallet.


För att en studierektor och en examinator skall kunna se speci�cerade budgetårkrävs följande:


Användarfall 5 Visning av specificerade budgetår

Figur 4: Visning av speci�cerade budgetår

5.1.1 För en studierektor



• Studierektorn måste ha skapat ett budgetår.

5.1.2 För en examinator

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

• Examinatorn måste ha blivit tillagd som examinator i databasen.


• Studierektorn måste ha lagt till examinatorn på det aktuella budgetåret.

5.2 Bas�öde

Detta kapitel beskriver bas�ödet för de olika aktörerna.






• Studierektorn klickar på �iken 'Speci�ed budget years'.

• Systemet visar alla budgetår som studierektorn speci�cerat.


Användarfall 6 Tillägg av examinatorer


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

• Systemet skickar examinatorn vidare till KTH:s inloggningssida.

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


• Examinatorn klickar på �iken 'Pro�le'.

• Examinatorn klickar på knappen 'View budget year information'.

• Systemet visar information om det aktuella budgetåret.



5.3.1 Studierektorn har inte speci�cerat något budgetår

Om studierektorn inte har speci�cerat något budgetår kommer denne följaktli-gen ej att se något.


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




6 Tillägg av examinatorer

Detta användarfall beskriver hur en studierektor lägger till en examinator isystemet. Figur 5 ger en illustrativ bild av användarfallet.


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




Användarfall 6 Tillägg av examinatorer

Figur 5: Tillägg av examinatorer

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

6.2 Bas�öde






• Studierektorn klickar på �iken 'Add examiner'.

• Studierektorn skriver in ett giltigt KTH-användarnamn.

• Studierektorn 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 speci�ka examinatorn ochlagrar informationen i databasen.

• Systemet visar att den tillagda examinatorn nu �nns i systemet.



6.3.1 Examinatorn �nns redan i databasen

Om examinatorn redan �nns i databasen skriver systemet ut detta.


Användarfall 7 Visning av tillgängliga examinatorer

6.3.2 Examinatorn �nns inte i KTH:s LDAP-databas

Om studierektorn angivit ett felaktigt KTH-användarnamn kommer systemetatt skriva ut ett felmeddelande.


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




7 Visning av tillgängliga examinatorer

Detta användarfall beskriver hur en studierektor/examinator/student ser till-gängliga examinatorer. Figur 6 ger en illustrativ bild av användarfallet.

Figur 6: Visning av tillgängliga examinatorer


Eftersom det i detta användarfall är olika förutsättningar beroende på vilkenaktör det gäller, tas dessa upp i separata kapitel.


För att en studierektor skall kunna se tillgängliga examinatorer krävs följande:



Användarfall 7 Visning av tillgängliga examinatorer

• Studierektorn måste ha blivit tillagd i databasen.


För att en examinator skall kunna se tillgängliga examinatorer krävs följande:


• Examinatorn måste ha blivit tillagd i databasen.

• Studierektorn måste ha skapat ett budgetår för det aktuella året.

• Studierektorn måste ha speci�cerat handledningstimmar för en examina-tor det aktuella budgetåret och denne examinator måste ha �er än nollkvarvarande handledningstimmar.

7.1.3 För en student

För att en student skall kunna se tillgängliga examinatorer krävs följande:

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


• Studierektorn måste ha speci�cerat handledningstimmar för en examina-tor det aktuella budgetåret och denne examinator måste ha �er än nollkvarvarande handledningstimmar.

7.2 Bas�öde


• Aktören klickar på �iken 'Log in' för att logga in i systemet.

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

• Aktören skriver in dennes inloggningsuppgifter, klickar på 'Logga in' ochskickas tillbaka till systemet.


• Aktören klickar på �iken 'Available examiners'.

• Systemet visar de tillgängliga examinatorerna.




Användarfall 8 Specificering / uppdatering av handledningstimmar

7.3.1 Det �nns inget tillagt budgetår

Om det inte �nns något budgetår tillagt i systemet kommer det ej att �nnasnågra examinatorer tillgängliga. Om detta inträ�ar kommer systemet skriva utett felmeddelande för studierektorerna. De andra aktörerna kommer att se entom tabell.

7.3.2 Examinatorn är ej tillagd på det aktuella budgetåret

Om examinatorn inte är tillagd på det aktuella budgetåret kommer systemetatt skriva ut ett felmeddelande.


examiners.php (för studierektorer)/exit/protected/views/site/pages/examiners.php

availableexaminers.php (för studenter och examinatorer)/exit/protected/views/site/pages/availableexaminers.php




8 Speci�cering / uppdatering av handledningstim-mar

Detta användarfall beskriver hur en studierektor speci�cerar/uppdaterar antalethandledningstimmar för en examinator för ett speci�kt budgetår. Figur 7 geren illustrativ bild av användarfallet.

Figur 7: Speci�cering/uppdatering av handledningstimmar


Användarfall 8 Specificering / uppdatering av handledningstimmar


För att en studierektor skall kunna speci�cera/uppdatera antalet handledningstim-mar krävs följande:



• Studierektorn måste ha lagt till en examinator i systemet.


8.2 Bas�öde






• Studierektorn klickar på �iken 'Specify tutoring hours'.

• Studierektorn väljer ett budgetår och en examinator från rullisterna, speci-�cerar/uppdaterar antalet timmar för den examinatorn och trycker på'Insert'.

• Systemet lägger in informationen i databasen.

• Systemet skriver ut att tilläggningen av handledningstimmar lyckades.



8.3.1 Studierektorn har ej speci�cerat handledningstimmar

Om studierektorn glömmer skriva in antalet handledningstimmar kommer sys-temet att skriva ut ett felmeddelande om detta.

8.3.2 Studierektorn råkar skriva in felaktig datatyp

Om studierektorn skriver in fel datatyp för antalet timmar (som väntar sig ettnumeriskt värde) kommer systemet att skriva ut ett felmeddelande om detta.


Om det inte �nns något budgetår tillagt i systemet kommer ett felmeddelandeatt skrivas ut.


Användarfall 9 Visning av kvarvarande handledningstimmar


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




9 Visning av kvarvarande handledningstimmar

Detta användarfall beskriver hur en studierektor/examinator kan se kvarvarandehandledningstimmar för examinatorer. En studierektor kan se samtliga exam-inatorers kvarvarande handledningstimmar, medan en examinator bara kan sedennes egna. Figur 8 ger en illustrativ bild av användarfallet.

Figur 8: Visning av kvarvarande handledningstimmar


För att en studierektor/examinator skall kunna se kvarvarande handledningstim-mar för en examinator krävs följande:

• Studierektorn och examinatorn måste ha giltiga inloggningskonton påKTH.

• Studierektorn och examinatorn måste ha blivit tillagda i respektive tabelli databasen.


• Studierektorn måste ha speci�cerat handledningstimmar för examinatorndet aktuella budgetåret för att examinatorn skall kunna se de kvarvarandehandledningtimmarna.


Användarfall 9 Visning av kvarvarande handledningstimmar

9.2 Bas�öde







• Studierektorn klickar på 'Available examiners'.

• Systemet visar en tabell över examinatorerna.







• Systemet visar antalet kvarvarande handledningstimmar.




Studierektorn kommer ej att kunna se tillgängliga examinatorer om denne ejspeci�cerat ett budgetår. I det fallet kommer ett felmeddelande att skrivas ut.

9.3.2 Examinatorn har inga handledningstimmar speci�cerade

Om examinatorn inte har några handledningstimmar speci�cerade för det ak-tuella budgetåret kommer denne följaktligen inte kunna se några handledningstim-mar i dennes pro�l.


Användarfall 10 Tillägg och uppdatering av arbetsområde för examinatorer


examiners.php (för studierektorer)/exit/protected/views/site/pages/examiners.php

pro�le.php (för examinatorer)/exit/protected/views/site/pages/pro�le.php




10 Tillägg och uppdatering av arbetsområde förexaminatorer

Detta användarfall beskriver hur en examinator lägger till / uppdaterar dennesarbetsområde. Figur 9 ger en illustrativ bild av användarfallet.

Figur 9: Tillägg och uppdatering av arbetsområde för examinatorer


För att en examinator skall kunna lägga till ett examensarbete krävs följande:


• Examinatorn måste ha blivit tillagd som examinator i systemet.

10.2 Bas�öde



Användarfall 11 Tillägg av examensarbeten till examinatorskvot






• Examinatorn skriver in det önskade arbetsområdet och trycker på 'Insert'.

• Systemet skriver ut att insättningen lyckades.



10.3.1 Examinatorn skriver in för många tecken

Om examinatorn skriver in �er tecken i textrutan än vad som är speci�cerat idatabasen kommer systemet att skriva ut ett felmeddelande om detta.


pro�le.php/exit/protected/views/site/pages/pro�le.php




11 Tillägg av examensarbeten till examinatorskvot

Detta användarfall beskriver hur en examinator lägger till ett examensarbetetill dennes examinatorskvot. Figur 10 ger en illustrativ bild av användarfallet.


För att en examinator skall kunna lägga till ett examensarbete krävs följande:





Användarfall 11 Tillägg av examensarbeten till examinatorskvot

Figur 10: Tillägg av examensarbeten

• Studierektorn måste ha speci�cerat handledningstimmar för examinatorndet aktuella budgetåret.

11.2 Bas�öde






• Examinatorn klickar på �iken 'Add degree project'.

• Examinatorn skriver information om examensarbetet och väljer antal stu-denter och trycker på 'Next'.

• Systemet visar ett formulär för att fylla i rätt antal studenter och före-tagsinformation (ifall examensarbetet utförs på ett företag).

• Examinatorn fyller i studentinformation (och eventuell företagsinforma-tion) och trycker sedan på 'Insert'.

• Systemet kontrollerar vilken typ av examensarbete som är speci�ceratsamt angivet antal studenter, och räknar utifrån det ut hur många timmardet skall dra bort från examinatorns kvarvarande handledningstimmar.

• Systemet uppdaterar antalet kvarvarande handledningstimmar för exam-inatorn och lägger in det speci�cerade examensarbetet i databasen.




Användarfall 12 Visning av tillagda examensarbeten

11.3.1 Examinatorn glömmer fylla i något obligatoriskt fält

Om examinatorn glömmer att fylla i något obligatoriskt fält kommer systemetatt skriva ut ett felmeddelande om detta.

11.3.2 Examinatorn fyller i ett ogiltigt datum

Om examinatorn fyller i ett ogiltigt datum kommer systemet att skriva ut ettfelmeddelande.

11.3.3 Examinatorn skriver in för många tecken

Om examinatorn skriver in �er tecken i en textruta än vad som är speci�cerati databasen kommer systemet att skriva ut ett felmeddelande om detta.


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




12 Visning av tillagda examensarbeten

Detta användarfall beskriver hur en examinator ser tillagda examensarbeten.Figur 11 ger en illustrativ bild av användarfallet.

Figur 11: Visning av tillagda examensarbeten


Användarfall 12 Visning av tillagda examensarbeten


För att en examinator skall kunna se de examensarbeten som denne lagt tillkrävs följande:





• Examinatorn måste ha lagt till ett examensarbete.

12.2 Bas�öde






• Examinatorn klickar på �iken 'My degree projects'.

• Systemet visar en tabell över examinatorns examensarbeten.



12.3.1 Det �nns inga examensarbeten

Om examinatorn inte har lagt till något examensarbete kommer denne följak-tligen ej att kunna se något.


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





Användarfall 13 Visning av specifik information om examensarbeten

13 Visning av speci�k information om examen-sarbeten

Detta användarfall beskriver hur en examinator kan se information om speci�kaexamensarbeten. Figur 12 ger en illustrativ bild av användarfallet.

Figur 12: Visning av speci�k information om examensarbeten


För att en examinator skall kunna se speci�k information om examensarbetensom denne lagt till krävs följande:






13.2 Bas�öde








Användarfall 14 Markering av examensarbeten som avslutade / avbrutna


• Examinatorn klickar på det projekt som denne vill se speci�k informationom.

• Systemet visar en popup-ruta med speci�k projektinformation.



showinfo.php/exit/showinfo.php




14 Markering av examensarbeten som avslutade/ avbrutna

Detta användarfall beskriver hur en examinator markerar ett examensarbetesom avbrutet/avslutat. Figur 13 ger en illustrativ bild av användarfallet.

Figur 13: Markering av examensarbeten som avslutade / avbrutna


För att en examinator skall kunna markera ett examensarbete som avbrutet/avslutatkrävs följande:








14.2 Bas�öde








• Examinatorn klickar på det projekt som denne vill markera som avslu-tat/avbrutet.

• Systemet visar en popup-ruta där det �nns en knapp för att markera ettexamensarbete som avslutat/avbrutet.

• Examinatorn klickar på angiven knapp.

• Systemet markerar examensarbetet som avslutat/avbrutet.



14.3.1 Det �nns inga examensarbeten

Om examinatorn inte har lagt till något examensarbete kommer denne följak-tligen ej att kunna markera något som avslutat/avbrutet.



showinfo.php/exit/showinfo.php







Documents

EXIT - EXAMINATORER INOM INFORMATIONSTEKNIKkth.diva-portal.org/smash/get/diva2:432747/FULLTEXT01.pdf · CSS (Cascading Style Sheets) (stilmallar) är ett språk som anändsv för