En analys av steg och konsekvenser vid införande av MVC

Uppsala universitet

Inst. för informationsvetenskap

En analys av steg och konsekvenser vid införande av MVC

Alexander Gertz och Harald Ericsson

Kurs: Examensarbete Nivå: C

Termin: VT12 Datum: 120519

Abstract

The purpose of this essay is to find difficulties and risks in the re-engineering process when restructuring to Model-View-Controller (MVC). A thoroughly theory study has been

conducted to be able to understand the important steps in the re-engineering process. The methods and concepts of this essay are re-engineering, UML, system development life cycle, design patterns and MVC. The science approach used is design science where the artifact being developed are a set of models.

In the analysis phase of the process the system is analyzed. The result of the analysis is notes of difficulties found and models showing the structure of the system. The results from the analysis is used to answer the questions. The steps taken in the re-engineering process are identified and described. All risks and difficulties found when following these steps are described. The guiding knowledge of this essay is to show when it's worth the effort of re- engineering the system instead of starting over from the beginning. When the problems are overwhelming and to time consuming re-engineering is not the best option.

1 Inledning ... 1

1.1 Bakgrund ... 1

1.2 Problembeskrivning ... 1

1.3 Uppdragsspecifikation ... 2

1.4 Syfte ... 2

1.4.1 Modeller ... 2

1.4.2 Re-engineering ... 3

1.5 Frågeställningar ... 3

1.6 Avgränsningar ... 3

1.7 Kunskapsintressenter ... 4

1.8 Disposition ... 4

2 Systemutvecklingsprocessen ... 5

2.1 Beskrivning ... 5

2.2 Vilka steg som används i SDLC ... 5

3 Metod ... 7

3.1 Strategi och datainsamling ... 7

3.1.1 Formulering av forskningsstrategi ... 7

3.1.2 Datainsamlingsmetodik ... 7

3.1.3 Metodik för dataanalys ... 7

3.2 Val av UML ... 8

3.3 Val av systemutvecklingsprocessen... 8

3.3.1 Praktisk tillämpning ... 8

3.4 Procedur ... 9

3.5 Kritik av metod ... 10

4 Re-engineering ...11

4.1 Beskrivning ...11

4.2 Reverse engineering ... 13

5 Mönster ... 14

5.1 Instruktion för att lösa ett särskilt problem i en särskild kontext ... 14

5.2 Designmönster inom mjukvaruutveckling ... 14

5.3 Fyra väsentliga beståndsdelar ... 15

5.3.1 Namn ... 15

5.3.2 Problem ... 15

5.3.3 Lösningen ... 16

5.3.4 Konsekvenser ... 16

5.4 Designmönster, Arkitekturmönster och idioms ... 17

5.4.1 Arkitekturmönster ... 17

6 MVC (Model-View-Controller) ... 18

6.1 Beskrivning ... 18

6.2 Beståndsdelar ... 20

6.2.1 Namn ... 20

6.2.2 Problem ... 20

6.2.3 Lösningen ... 20

6.2.4 Konsekvenser ... 21

7 UML ... 22

7.1 Beskrivning ... 22

7.1.1 Strukturdiagram ... 23

7.1.2 Interaktionsdiagram ... 24

7.1.3 Beteendediagram ... 25

8 Resultat ... 26

8.1 Analys av problemet ... 26

8.2 Problemlösning ... 26

8.3 Grundproblemet och lösning med MVC ... 27

8.4 Kod och andra specifikationer ... 28

8.5 Svårigheter, konsekvenser och risker ... 28

8.5.1 Risker ... 28

8.5.2 Konsekvenserna ... 28

8.5.3 Detaljstudie av modeller och svårigheter ... 28

8.5.3.1 Sektion: Nyhetslista ... 33

8.5.3.2 Exempel på MVC-struktur för Sektion: Nyhetlista ... 35

8.5.4 Övriga svårigheter ... 39

8.6 Krav på re-engineering ... 44

8.7 Kostnadseffektivitet... 44

8.8 Fortsatt arbete ... 45

9 Slutsats ... 46

9.1 Steg i re-engineeringprocessen ... 46

9.2 Svårigheter i re-engineeringprocessen ... 46

9.3 Konsekvenser och risker i re-engineeringprocessen ... 46

9.4 Rekommendation vid re-engineering mot MVC-arkitektur ... 47

9.5 Begränsningar i kontext ... 48

10 Källförteckning ... 49

1

1 Inledning

I följande kapitel beskrivs bakgrund, problembeskrivning, uppdragsspecifikation, syfte, frågeställningar, avgränsningar, kunskapsintressenter, samt dispositionen för denna uppsats.

1.1 Bakgrund

Bakgrunden till den här uppsatsen ligger i hur man väljer att skriva kod och strukturera de funktioner och komponenter som bygger upp en webbplats. Företaget som har specificerat detta arbete är Nyheter24-Gruppen (24 Media Network AB). 24 Media Network AB är ett stort företag som innefattar ett tiotal webbplatser med varierande användarbaser. Deras målgrupp är 16-44åringar. Företaget grundades 2011 och är idag Sveriges största digitala mediehus.(intervju med Pontus Eskilsson, ansvarig för fragbite, 16/4-12)

En av företagets webbplatser är ett datorspelscommunity som heter Fragbite. Webbplatsen utvecklades från början som ett intresseprojekt av två hemskolade webbutvecklare. Hemsidan växte till en stor community samtidigt som utvecklarna pluggade vid sidan om. Mellan år 2002 och år 2010 drevs webbplatsen vidare på detta sätt. Grunden till dagens kod är flera år gammal och endast en liten del av sidans funktionalitet har tagits fram de senaste fem åren.

Den databas och de databastabeller som finns kopplade till webbplatsen är inte optimerade enligt någon teori eller något mönster och har sett ut på det viset sedan webbplatsen byggdes.

Planer på att ta fram ny kod och att optimera databasstrukturen har funnits i över sex år men det har inte utförts eftersom att ingen har kunnat lägga ned den tid det tar för att förbättra webbplatsen.(intervju med Pontus Eskilsson, ansvarig för fragbite, 16/4-12)

1.2 Problembeskrivning

I början utav år 2011 köptes webbplatsen upp utav Nyheter24-Gruppen som tagit över arbetet och de ursprungliga ägarna/utvecklarna lämnade webbplatsen. Till webbplatsen finns en stor databas med ett stort antal tabeller och flera miljoner rader med data. Dessa tabeller är inte optimerade vad gäller tydlighet och snabbhet. Den kod som webbplatsen är byggd på idag är utformad på ett sådant sätt att det är svårt eller omöjligt att bygga nya funktioner. Det

eftersom att den har många snabbfixar. Dessa snabbfixar innebär att utvecklaren endast lagt till önskad funktionalitet på ett snabbt sätt utan att ta hänsyn till struktur och möjlighet till att vidareutveckla funktioner. Detta visar sig i deras indexfil där olika språk blandas och koden i helhet inte har någon uppenbar struktur. Det gör att det upplevs som att ett designmönster saknas. När man i ett sådant fall kommer in som utomstående utvecklare tar det lång tid att ta fram ny funktionalitet eller ändra befintlig funktionalitet och kostar således mer pengar än det

2

rimligen borde göra. Tidigare har Nyheter24-Gruppen anställt utvecklare som inte har slutfört arbetet främst av den anledningen att strukturen har varit svårbegriplig.

Eftersom Nyheter24-Gruppen är ett vinstdrivande företag så vill de kunna öka antalet

användare och på så sätt öka sina intäkter. För att nå ut till fler användare behöver utvecklarna för webbplatsen kunna lägga in ny funktionalitet eller ändra befintlig funktionalitet som i sin tur lockar fler användare till deras community. Att kunna utveckla ny funktionalitet, ändra befintlig funktionalitet och ta bort oanvänd funktionalitet är därför viktigt för att kunna växa som community.(intervju med Pontus Eskilsson, ansvarig för fragbite, 16/4-12)

1.3 Uppdragsspecifikation

På företaget finns en ansvarig för Fragbite som har specificerat uppdraget att ta fram modeller för webbplatsen. Modellerna ska representera samma eller snarlik funktionalitet som finns i dagsläget. Inga nya funktioner ska tas fram med hjälp av modellerna. Modellerna ska vara framtagna för att visa hur processerna byggs med ett designmönster. Uppdragsgivaren har begränsat arbetet på så sätt att det designmönster som kommer att används är MVC (Model- View-Controller). Detta eftersom företaget tidigare använt sig av detta designmönster för att ta fram så bra kod som möjligt för sina webbplatser. Att använda sig av ett designmönster innebär att följa ett mönster som har uppkommit och specificerats för att lösa ett visst problem. I detta fall för att lösa problem med struktur. Med strukturen är det tänkt att koden ska vara skriven på så sätt att det för andra utvecklare ska vara möjligt att sätta sig in i den och kunna utveckla sidan vidare med ny eller ändrad funktionalitet.

1.4 Syfte

Syftet med detta arbete är att visa på vilka problem som kan uppstå i samband med att man inför MVC i ett befintligt system. Användandet av designmönstret MVC innebär att designa systemets olika komponenter, från fil- och mapp-struktur till kodstandard och funktionalitet.

Målet med att designa enligt en MVC-arkitektur är att separera funktionalitet från design och sedan styra med en annan komponent. Det som kallas design i den här kontexten är det mönster som följs vid uppbyggande av ett systems struktur. De komponenterna som MVC består av är Model, View och Controller, där Model sköter behandling av data, View sköter design och Controller sköter kopplingen mellan dessa.

1.4.1 Modeller

Genom att utveckla modeller enligt MVC-arkitektur så kan djupare förståelse nås för systemets uppbyggnad och funktion men också för att se skillnaden med en strukturerad

3

design för vidareutvecklingsarbetet. För detta arbete så behövs djupare kunskap i

designmönstret MVC, designprinciper för MVC, systemutvecklingsmetod och modellering.

Modellerna ska tas fram enligt UML.

1.4.2 Re-engineering

Kunskapen som utvecklas genom detta arbete är att visa på vilka svårigheter som man kan stöta på när man väljer att använda re-engineering för att transformera ett system till MVC- arkitektur samt någon form av vägledande kunskap för hur man bör gå tillväga när man väljer att införa MVC i ett sent skede.

1.5 Frågeställningar

Utifrån syftet har följande frågor uppkommit:

- Vilka steg kan tas för att genom re-engineering skriva om ett system till MVC-arkitektur.

- Finns det några svårigheter som kan påverka denna process?

- Vilka konsekvenser och risker finns det när man utför re-engineering på ett system med flera hundra filer?

- När är det monetärt motiverbart att bearbeta och strukturera om till MVC istället för att börja om genom att skriva ny kod?

1.6 Avgränsningar

Arbetet avgränsas av att det är ett uppdrag specificerat av ett företag som vill passa på att förändra en del av funktionaliteten som de inte har specificerat hur och vad som ska förändras när de väljer att skriva om koden för hemsidan. Fokus för arbetet kommer ej vara att jobba med ny eller ändrad funktionalitet utan arbetet kommer utgå ifrån att samma funktionalitet som finns i dagsläget även ska finnas i det nya systemet. Anledningen är att fokus ligger på att förstå processen när man går över till MVC istället för att fokusera på nya

funktionsspecifikationer.

4

1.7 Kunskapsintressenter

Kunskapen som kommer att utvecklas i detta arbete riktar sig till personer som sysslar med utveckling allmänt och i synnerhet de som arbetar med re-engineering av stora system.

Studenter som studerar systemvetenskap eller motsvarande bör även kunna finna denna uppsats givande.

1.8 Disposition

I detta kapitel beskrivs problemet, syftet samt frågeställningar för uppsatsen.

Nästa kapitel beskriver systemutvecklingsprocessen som är den övergripande metodiken för denna uppsats.

Det tredje kapitlet beskriver det som utförs i uppsatsen. Metodiken och forskningsansats beskrivs och kritiseras.

De fyra följande kapitlen rör den teori som används i uppsatsen.

Det fjärde kapitlet beskriver re-engineeringprocessen. Processen består av elva steg och fem av dessa beskrivs utförligt i kapitlet.

Det femte kapitlet behandlar begreppet designmönster och vad det innebär.

Det sjätte kapitlet behandlar arkitekturmönstret MVC och dess beståndsdelar.

Det sjunde kapitlet beskriver modelleringsspråket UML samt de diagram och diagramtyper som UML består av.

Det åttonde kapitlet är en presentation av det resultat som nås i uppsatsen.

Det nionde kapitlet behandlar den slutsats som nås i uppsatsen.

Det sista kapitlet visar alla källor uppdelade efter vilken typ av källa det är.

5

2 Systemutvecklingsprocessen

I följande kapitel behandlas systemutvecklingsprocessen och de steg som behandlas i denna uppsats.

2.1 Beskrivning

Systemutvecklingsprocessen eller System development life cycle(SDLC) är en process vars syfte är att ta fram eller förändra ett informationssystem. SDLC består av fyra faser. Varje fas involverar särskilda processer som sedan producerar olika typer av resultat. Dessa faser är planering, analys, design och implementation. Hela processen innefattar flera aktiviteter i de olika faserna. De aktiviteter som utförs och när de utförs kan variera från projekt till projekt.

Processen föregås oftast av en förstudie eller föranalys för att se om det är värt att gå vidare till SDLC. SDLC kan liknas vid att bygga ett hus, en idé ligger till grund för grovskisser. Den som köper huset får säga sitt och väljer en grovskiss som husbyggaren sedan tar fram förslag utifrån och som finslipas med kunden och som ligger till grund för de ritningar som huset byggs efter. På samma sätt är SDLC en iterativ process där utvecklingen inte följer ett rakt spår. (Dennis, Wixom och Roth 2008; Arvidsson sept-11)

2.2 Vilka steg som används i SDLC

De steg som kommer att beröras i denna uppsats är planeringsfasen, analysfasen och designfasen.

Planeringsfasen

Är den första fasen i processen. I planeringsfasen ska svar tas fram för:

Varför ska systemet byggas?

Vilken struktur ska projektet ha?

För att svara på frågorna så utförs olika aktiviteter: identifiering av projektet, feasibility study, uppskattning av tidsåtgång, planering av projektet med personal.

Resultatet av denna fas är först en identifiering av vad systemet skulle innebära och en analys som visar om det är möjligt att fram systemet utifrån ekonomiska, tekniska och

organisatoriska aspekter. Det andra som fasen resulterar i är en projektplan. (Dennis, Wixom och Roth 2008)

Analysfasen

I analysfasen besvaras vem, vad, hur och när för systemet. Den första aktiviteten som utförs är framtagning av en analysstrategi. När strategin är bestämd så inleds analysen och insamlingen av information om och från kunden. Det kan till exempel ske genom intervjuer. Flera olika

6

metoder för informationsinsamling kan användas parallellt. Efter informationsinsamlingen tas användarfall fram som visar hur ett visst syfte uppfylls. Aktör- och systeminteraktion

modelleras för varje användarfall. Process- och datamodeller tas fram efter

användarscenarion. Dessa modeller kan tas fram med hjälp av UML. Resultatet för

analysfasen är ett utkast för hur systemet kan se ut. Utkastet innehåller dokumentation med definitionen för vad kunden vill ha samt modeller för data och processer. (Dennis, Wixom och Roth 2008)

Designfasen

I designfasen besvaras hur systemet ska fungera. Det första som sker är design av den fysiska uppbyggnaden av systemet. Val av mjukvara och hårdvara utförs. Genom användarscenarion tas prototyper för interfacedesign fram som sedan leder fram till att en interfacedesign blir vald. Design av databaser och filstruktur tas fram med hjälp utav dataflödesdiagram och Entity relationship diagram(ERD). Det resultat som designfasen ger är en systemspecifikation som ska visa alla aspekter rörande hur systemet ska fungera. (Dennis, Wixom och Roth 2008)

7

3 Metod

I detta kapitel beskrivs det arbete som bygger uppsatsens innehåll.

3.1 Strategi och datainsamling

Här beskrivs den forskningsstrategi och datainsamlingsmetodik som används i uppsatsen.

3.1.1 Formulering av forskningsstrategi

I uppsatsen används design science. Det som kommer att utvecklas är en ny IT-artefakt. Fokus är att genom IT-artefakten förstå den process som sker när ett system görs om till MVC- arkitektur. IT-artefakten som utvecklas är ett medel för att kunna komma fram till ny kunskap.

Som övergripande strategi kommer systemutvecklingsprocessens första punkter, conception, analysis och design att användas.

3.1.2 Datainsamlingsmetodik

För att samla in data kommer utgångspunkten vara en analys av det nuvarande systemet.

Eftersom det inte finns någon dokumentation för systemet så kommer det behöva upprättas modeller för hur webbplatsen ser ut i dagsläget. Resultatet av det är modeller som kommer att vara användbara som grund för designfasen.

3.1.3 Metodik för dataanalys

Den strategi som i uppsatsen används för att analysera data är induktiv då resultatet baseras på den artefakt som tas fram och egna erfarenheter av det. Litteratur som rör designmönstret MVC och designmönster i allmänhet kommer att användas. För att förstå det system som är tänkt att utvecklas med MVC så kommer en modell upprättas för det nya systemet som en del i hela re-engineeringprocessen. Modellerna ska representera kod och struktur på webbplatsen.

De modeller som kommer att tas fram kommer att vara gjorda med hjälp utav modelleringsspråket Unified Modeling Language (UML).

8

3.2 Val av UML

Unified Modeling Language(UML) väljs av flera anledningar och den första är att det är ett modelleringsspråk som är vida utbrett inom mjukvaruutveckling och modellering i

mjukvaruprojekt. Denna utbredning har gjort att UML i dagens läge är en så kallad de facto- standard (Bersini, 2012). UML återfinns i nästan alla verktyg för modellering och det gör att valet av verktyg blir mindre komplicerat. En av styrkorna med UML är att det är ett

modelleringsspråk som är mångsidigt vad gäller möjligheten att modellera olika delar och aspekter av ett system. UML har olika diagram och diagramtyper som ger möjlighet att effektivt kunna modellera ett helt system i helhet och gå ner i detalj till specifika klasser och titta på hur de ser ut och relaterar till varandra. Dessa diagram beskriver olika delar av ett system och situationer som kan uppstå i ett system. Det gör att det är lämpligt att använda sig av UML vid re-engineeringprocessen.

3.3 Val av systemutvecklingsprocessen

I denna uppsats berörs systemutvecklingsprocessen av den anledning att det är ett

väldokumenterat tillvägagångssätt och att processen överensstämmer med stegen i design science. Enligt Håkansson (Håkansson 03-12) innehåller design science stegen:

 Problemanalys

 Förslag(Kravframtagning)

 Utveckling (Artefaktdesign)

 Utvärdering

 Slutsats

3.3.1 Praktisk tillämpning

I denna uppsats innebär planeringsfasen den inledande planeringen och upplägget av arbetet med modeller. För att planera krävs en förståelse för det problem som ligger till grund för uppsatsen. Metoder och begrepp som används för att ta fram modeller bestäms. Kunskap som krävs för uppsatsen uppskattas. En feasibility study utförs och en tids- och aktivitetsplanering tas fram. Analysfasen innebär inläsning av den kunskap som väntas krävas för att kunna ta fram modeller. Fördjupning av begrepp och metoder samt användande av dessa inleds. I designfasen tas artefakten för uppsatsen fram som i denna uppsats är en samling modeller.

Dessa modeller används för utvärdering som slutligen leder till slutsatsen för uppsatsen.

9

3.4 Procedur

Arbetet i denna uppsats inleds med en analys av det problem som uppdragsgivaren specificerar. Uppdragsgivaren vill utföra re-engineering av det nuvarande systemet med anledning av att vidareutveckling av nuvarande system är svårt att definiera. En rimlig uppgift för uppsatsen specificerades genom samtal med handledare hos uppdragsgivaren och

handledare samt föreläsare på Uppsala Universitet. Uppgiften är att skapa modeller för det nuvarande systemet samt analys av svårigheter som kan uppstå i övergångsprocessen(re- engineeringprocessen) från det nuvarande systemet till ett system som bygger på MVC- arkitektur. För att förstå övergångsprocessen krävs grundläggande kunskap inom designmönster, MVC, re-engineering, UML och den övergripande

systemutvecklingsmetodiken. Med kunskap om dessa begrepp och vad de innebär kan förslag på lösningar för problemet tas fram. Problemet är hur man ska visa på övergångsprocessen och hur det ska kopplas till svårigheter som kan uppstå. För att kunna ta fram modeller för det nuvarande systemet används UML som är ett modelleringsspråk som stödjer modellering av olika aspekter av ett system. Dessa olika aspekter är knutna till olika diagram som innefattas av UML. Enligt re-engineeringprocessens olika steg påbörjas arbetet med den artefakt som utvecklas i form av modeller. I första steget är insamling av information om systemet.

Uppdragsgivaren frågas angående dokumentation men det visar sig att ingen sådan finns för systemet. För hela arbetet upprättas ett sekretessavtal. I det andra steget bestäms vilket tillvägagångssätt som ska användas för tillgång till koden.

Med tillgång till koden kan det tredje steget påbörjas med syfte att analysera och skapa en uppfattning om systemet. Genom förståelse för funktioners syfte samt uppbyggnad kan modeller tas fram. Det visar sig att systemet har mycket kod och över 200 filer. En avgränsning av artefaktens omfång är nödvändig. I systemet finns en fil som anses vara representativ för den övergripande strukturen i systemet. Denna fil valdes och i filen valdes en kodsnutt som representerar ett block i användargränssnittet. Kodsnutten refereras till som

”sektionen” i modeller samt text.

Kring den fil som tidigare valdes skapas fem modeller som visar olika aspekter av filen samt innehållet. Koden och relationerna för filen saknar motsvarande UML-diagram. Lämplig notation för modellerna lånas av olika UML-diagram. De modeller som tas fram är

motsvarande aktivitetsdiagram för sektionen i main.php, ett diagram för att visa struktur för sektionen i main.php, komponentdiagram för main.php samt en MVC-modell för sektionen i main.php.

Under arbetet med modellerna noteras eventuella svårigheter som dyker upp. De fem

modeller som tas fram visar på kärnstrukturen hos uppdragsgivarens nuvarande system. Den artefakt som utvecklas utvärderas med utgångspunkt i uppdragsgivarens problem.

I det fjärde steget inleds ännu en analysfas av de krav som ställs på re-engineeringprocessen.

Det krav som uppdragsgivaren angivit är en förbättring av koden för att få bukt med vidareutvecklingsproblem. Med alla förutsättningar, problem och mål med re-

engineeringprocessen identifierade påbörjas det femte steget. Syftet med det femte steget är att ta fram en plan för resten av re-engineeringprocessen(Briden 2000). Den plan som

10

beskrivs i det femte steget motsvaras av den rekommendation som skrivs i slutsaten.

Analysfaserna i de fyra första stegen leder fram till utvärderingen och slutsaten för uppsatsen.

3.5 Kritik av metod

Uppsatsen baseras på egna observationer. Det är svårt att uttala sig om tillförlitligheten.

Användandet av UML för modellering i re-engineeringprocessen är en viktig fas för att visa hur systemet ser ut. I den fasen grundades val av notation och modelltyp på egna erfarenheter.

Det system som analyseras är ett stort system sett till antalet mappar och filer. Utav över 200 filer valdes en stor fil för att undersökas närmare. Den filen analyseras extra noga och anses i uppsatsen ha en representativ struktur för hur systemet är uppbyggt vad gäller kod och kodstruktur. Osäkerhet kring frekvensen och utformningen av svårigheterna finns vad gäller systemet i helhet.

11

4 Re-engineering

I följande kapitel behandlas re-engineering samt tillämpning av re-engineering och reverse engineering.

4.1 Beskrivning

Re-engineering av mjukvara beskrivs av Chikofsky & Cross (1990) som ”undersökning och förändring av ett system för att rekonstruera det i en ny form”. Det betyder med andra ord modifikation av ett system som först har analyserats genom reverse engineering.

Re-engineering är en flerstegsprocess som kan beskrivas med elva enkla steg. I dessa steg utförs analys, modifikation, implementation och dokumentation. De elva stegen är enligt Briden (2000) följande:

1. Identification of Existing Source Code/Documentation 2. Verification of Identified Code and Setting up of a Baseline 3. Familiarisation with the Existing Application

4. Identification of Re-engineering Requirements 5. Writing a Re-engineering Plan

6. Production of a Test Plan, Test Data and Script 7. Producing Test Results for Original Version

8. Producing Test Results for Original Ported Version (unmodified) - if applicable

9. Restructuring the Code (in identifiable phases) 10. Testing the Code (after each phase)

11. Updating/Writing Documentation

De steg som behandlas i denna uppsats är det första, andra, tredje, fjärde och femte steget.

Utvecklaren/utvecklarna är den/de personer som utför re-engineering på ett system. Företaget är arbetsgivaren som har betalat för att utvecklarna ska utföra re-engineering på ett system.

1. Steget går ut på att samla in information om systemet. Om dokumentation finns tar utvecklaren kopior på dokumentationen för att lättare kunna förstå sig på systemet. De filer och den programvara som används i det nuvarande systemet samlas in. Om det hos företaget finns en person som är insatt i hur det nuvarande systemet är uppbyggt underlättar det för utvecklaren att prata med denna person för att skapa en uppfattning om viktiga aspekter rörande systemet. Resultatet av det första steget är en form av dokumentation av förutsättningarna för re-engineeringprocessen. (Briden 2000) 2. De filer som behövs för att utföra systemets aktiviteter dokumenteras.

12

3. Utvecklaren/utvecklarna skapar sig en uppfattning om systemet och

strukturen(Kontogiannis, Mylopoulos och Tahvildari 2002)genom att studera

systemet. Om det hos företaget finns en person som förstår systemet och dess kod är det en tillgång för utvecklaren. I koden kan utvecklaren skriva kommentarer och notera eventuella buggar som hittats i koden. Under denna fas dokumenteras eventuella förslag till förbättring, beskrivningar av funktionerna, diagram och modeller. Efter det tredje steget är det viktigt för utvecklaren att kunna svara på frågorna:

a. Vad gör funktionerna som systemet har?

b. Hur fungerar funktionerna internt i systemet?

4. De tre första stegen har ger utvecklaren en insikt i vilka funktioner systemet ger och hur dessa fungerar. Det fjärde steget ger svar på vilka krav som ställs på re-

engineeringprocessen. Enligt Briden (2000) är kraven en eller flera av nedanstående:

 Comment the code

 Modularise the code

 Document the code

 Enhance the code

 Identification and removal of unused code

 Identification and removal of duplicated code

 Identification and removal of duplicated parameter/data definitions

 Port the code to another platform

 Enhance the User Interface/Bring it up to date

 Bring the code up to a defined language standard

 Convert the Code into an alternative development language

 Improve/Maintain the performance

 Optimise the code

 Improve internal error handling

 Include additional functionality

 Fix existing bugs

 Use alternate third party products

Kraven kan delas in i underkrav. Ett exempel är om det finns ett krav på att koden ska kommenteras då kan exempelvis språkrestriktioner i kommentarerna vara ett underkrav.

5. Med vetskap om vilka krav som ställs på re-engineeringprocessen samt hur

funktionalitet ser ut kan utvecklaren skriva en plan för hur den kvarstående delen av processen ska skötas. Med hjälp av kraven i det föregående steget så delas planen upp i faser. Varje fas ser till att uppfylla ett eller flera krav. Den plan som tas fram

diskuteras med företaget för att utröna om den plan som tagits fram beskriver rätt tillvägagångssätt.(Briden 2000)

13

4.2 Reverse engineering

Reverse engineering är en del av re-engineeringprocessen. Konceptet för reverse engineering är i simpla drag att bryta ned något i mindre bitar för att kunna förstå hur det är uppbyggt och fungerar. Syftet med reverse engineering är att kunna svara på samma frågor som besvaras med hjälp utav steg tre i re-engineeringprocessen. (Schwartz 2001)

14

5 Mönster

I följande kapitel behandlas begreppet designmönster inom mjukvaruutveckling. Definitionen av mönster och designmönsters beståndsdelar samt varför det är viktigt med designmönster i mjukvaruutveckling.

5.1 Instruktion för att lösa ett särskilt problem i en särskild kontext

Arkitekten Christopher Alexander har varit väldigt inflytelserik i introduktionen av arkitektur- mönster (Christopher Alexander 10/5-12). Alexander (Alexander 1979) definierar mönster som följande:

Varje mönster är en tre-dels-regel som uttrycker en relation mellan en visst kontext, ett problem och en lösning.

Varje mönster är en relation mellan en särskild kontext, ett särskilt system av krafter som upprepade gånger uppstår i den kontexten och en särskild lösning som gör det möjligt för dessa krafter att lösa sig själva.

Ett mönster är en instruktion som visar hur lösningen kan användas upprepade gånger för att lösa det givna systemet av krafter där kontexten är relevant.

(Egen översättning)

Framgångsrika designlösningar dokumenteras och görs tillgängliga för andra designers att använda sig utav. Dokumentationen av en framgångsrik designlösning blir sedan vad som kallas ett designmönster. Designmönstren kan sedan användas av andra designers som vägledning till att göra bättre designlösningar för problemen de står inför. (Buschmann, Meunier, Rohnert, Sommerlad, Stal 1996)

Alexanders definition av mönster är för städer och byggnader. Enligt Erich Gamma (Gamma, Helm, Johnson, Vlissides 1994) gäller det även för objektorienterade system. De menar att även om lösningarna är uttryckta med olika sorters objekt, fysiska eller dataobjekt, så är båda mönstren i grunden en lösning på ett problem i ett särskilt kontext.

5.2 Designmönster inom mjukvaruutveckling

Designmönster inom mjukvaruutveckling används när system utvecklas för att bland annat lösa problem som gör att systemen kan bli oförändrings- eller oåteranvändningsbara och

15

därmed svåra att vidareutveckla om designern inte följer ett visst mönster vid designen av systemet. (Gamma m fl 1994)

System som är förändrings- eller återanvändningsbara är viktiga för vidareutvecklingen samt underhåll av systemet. När ett system ska underhållas eller vidareutvecklas är det oftast inte bara designern av systemet som utför detta utan även andra designers eller utvecklare. Då är det viktigt med ett givet designmönster eftersom det specificerar strukturen för systemets uppbyggnad och de kan snabbt förstå vilken del av systemet de ska använda sig utav, vilket sparar både tid och pengar. (Johnson, Foote 29/4-12)

5.3 Fyra väsentliga beståndsdelar

Enligt Gamma (Gamma m fl 1994) så består mönster generellt av fyra väsentliga beståndsdelar, ett namn, ett problem, lösningen samt konsekvenserna av att tillämpa designmönstret. Nedan följer en förklaring av delarna.

5.3.1 Namn

Att definiera ett bra namn för ett visst designmönster är viktigt då det ökar vokabulären som designers sedan kan använda i diskussioner med varandra samt vid dokumentation, vilket höjer abstraktionsnivån för design. (Gamma m fl 1994)

Frank Buschmann (Buschmann m fl 1996) menar att det är viktigt att vokabulären för designers ökar då det kan förenkla diskussioner mellan dem angående olika designproblem och lösningar. Att förklara en lösning för ett visst problem utan någon given standard kan göra att beskrivningen blir väldigt komplicerad eftersom varje del i lösningen behöver förklaras.

Att istället använda sig utav ett givet designmönsters namn och förklara vilka delar av lösningen som motsvarar de olika delarna i designmönstret gör att andra designers som är medvetna om designmönstret snabbt kan få sig en bild utav lösningen.

Ett bra namn beskriver, med få ord, designproblemet, lösningen och konsekvenserna.

(Gamma m fl 1994)

5.3.2 Problem

Problemdelen beskriver ett problem i en särskild kontext (Gamma m fl 1994).

Problembeskrivningen inleds med en generell beskrivning av det stora designproblemet som ska lösas. Den generella beskrivningen av problemet avslutas sedan med ett antal krafter som

16

beskriver de aspekter av problemet som bör tas hänsyn till, exempel på krafter kan vara krav som lösningen måste uppfylla, restriktioner för lösningen samt önskvärda egenskaper för lösningen. Begreppet krafter är lånat ifrån Alexanders (Christopher 1979) definition av mönster. (Buschmann m fl 1996)

Istället för att använda begreppet krafter så menar Gamma (Gamma m fl 1994) att ibland inkluderas även en lista med krav som bör vara uppfyllda för att mönstret ska kunna tillämpas.

Problemet beskriver när mönstret bör tillämpas. (Gamma m fl 1994)

5.3.3 Lösningen

Elementen, eller krafterna som Buschmann (Buschmann m fl 1996) beskriver, som utgör designen, deras relationer, ansvar och samarbete med andra element beskrivs i Lösningsdelen.

(Gamma m fl 1994)

Enligt Buschmann (Buschmann m fl 1996) så beskriver lösningen hur de associerade krafterna till problemet kan balanseras så att just det problemet elimineras. Lösningen är uppdelad i två delar: de statiska aspekterna för lösningen samt de dynamiska.

De statiska aspekterna är strukturen mellan de element som ingår i designen, deras relationer samt ansvar. Genom att elementen har definierade ansvarsområden så bestämmer deras relation till de andra elementen var i strukturen de har sin plats.

Med dynamiska aspekter så menar Buschmann (Buschmann m fl 1996) samarbete och kommunikationen mellan de element som ingår i strukturen.

Lösningen beskriver abstrakt designproblemet och generellt hur elementen eller krafterna borde vara arrangerade för att lösa problemet. (Gamma m fl 1994)

Ett designmönsters roll handlar mer om att vägleda andra designers till att följa en viss struktur för elementen som ingår i designen än att fungera som en ritning som visar exakt hur ett visst problem löses i en särskild kontext. Detta för att kärnan i strukturen fortfarande ska gå att fasthålla även när vidareutveckling av designen sker. (Buschmann m fl 1996)

5.3.4 Konsekvenser

Beskriver konsekvenserna av att tillämpa designmönstret, eller konsekvenserna av att

balansera de associerade krafter enligt Buschmann (Buschmann m fl 1996). Konsekvenserna kan vara att ett krav för lösningen har vissa restriktioner. Att veta konsekvenserna av att tillämpa ett visst designmönstret är väldigt användbart. Det blir då möjligt att utvärdera olika

17

designbeslut samt underlätta förståelse av vinster och kostnader vid tillämpningen av ett designmönster. (Gamma m fl 1994)

5.4 Designmönster, Arkitekturmönster och idioms

Inom mjukvaruutveckling så finns det flera olika designmönster på olika nivåer av abstraktion. Nivån av abstraktion beror på i vilken fas av utvecklingen av systemet designmönstret ska tillämpas. Enligt Buschmann (Buschmann m fl 1996) består

utvecklingsprocessen av tre faser då designmönster tillämpas. I första fasen tillämpas mönster med en hög abstraktionsnivå. Mönster med en hög abstraktionsnivå tillämpas för att designa en övergripande struktur för systemet. Andra fasens fokus är att designa de olika elementen, eller del-systemen, och deras relationer som hela systemet består av. I sista fasen på lägsta abstraktionsnivån så är fokus på designaspekter av ett särskilt programmeringsspråk.

Buschmann (Buschmann m fl 1996) har kategoriserat dessa faser med tre olika mönster:

arkitekturmönster, designmönster samt idiom.

Syftet med detta arbete är att modulera tillämpningen av en MVC-struktur för webbplatsen.

MVC är kategoriserat som ett arkitekturmönster. (Buschmann m fl 1996) Därav har endast arkitekturmönster valts för djupare beskrivning.

5.4.1 Arkitekturmönster

Ett arkitekturmönster är av den högsta abstraktionsnivån och representerar den övergripande strukturen för systemet. Den övergripande strukturen representeras av en mängd

fördefinierade del-system med specificerade ansvarsområden samt regler och riktlinjer för att organisera relationerna mellan dem. (Buschmann m fl 1996)

Då arkitekturmönster specificerar den övergripande strukturen för systemet så påverkas systemets olika del-system-arkitekturer, vilket gör valet av arkitekturmönster grundläggande vid utvecklingen av system. (Buschmann m fl 1996)

18

6 MVC (Model-View-Controller)

I följande kapitel beskrivs mönstret MVC och dess tillämpning.

6.1 Beskrivning

MVC, Model-View-Controller, är ett mönster kategoriserat som arkitekturmönster inom mjukvaruutveckling (Buschmann m fl 1996). MVC introducerades 1978-79 av den norske professorn Trygve Reenskaug. Det primära målet med MVC är att ge användarna mer kontroll över informationen de behandlar. Detta genom att göra det möjligt för användarna att kunna manipulera och se informationen ur flera olika synvinklar. (Reenskaug 10/5-12)

MVC-mönstret kan tillämpas för att specificera den övergripande strukturen för interaktiva system med grafiska användargränssnitt. Grundprincipen med MVC är att separera

funktionaliteten och presentationen i systemet. Separationen underlättar vidareutvecklingen av systemet då till exempel om en ändring innebär att designa presentation av data så behöver designern enbart arbeta med presentationsdelen. (Buschmann m fl 1996)

Separationen av funktionalitet och presentation är något som Martin Fowler (Fowler 10/5-12) kallar för Separated Presentation vilket han har definierat som:

”Försäkra att all kod som manipulerar presentation enbart manipulerar presentation, så att all domän- och datalogik tydligt separeras till olika delar av programmet”

(Egen översättning)

Martin menar att idén bakom Separated Presentation med MVC-arkitektur är att tydligt separera domänobjekten som modulerar data och presentationsobjekten som är elementen som syns i gränssnittet på skärmen. Domänobjekten ska vara helt oberoende av

presentationsobjekten samt att flera representationer av domänobjektet ska vara möjliga.

Nackdelarna när olika delar av systemet är beroende av varandra är att det kan leda till att systemet blir svårt att förstå sig på, vidareutveckla eller underhålla (Gamma m fl 1994).

Gamma (Gamma m fl 1994) nämner detta problem som Tight Coupling vilket kan göra att när någon del i systemet ska ändras så måste utvecklaren dessutom förstå sig på och ändra andra delar, då de är beroende av varandra. Loose Coupling är lösningen på detta problem och har samma mål som Separated Presentation, nämligen att göra de olika delarna så oberoende av varandra som möjligt. MVC-mönstret använder sig utav denna metod och delar upp systemet i tre olika delar; Model, View och Controller. Nedan följer en beskrivning utav dessa delar.

19

Figur 1: Visualisering av MVC

Model är den del av systemet som innehar funktionaliteten och utför all manipulering av data.

När manipulering av data sker så notifieras alla views kopplade till model-delen. model-delen är oberoende av de andra delarna.

View är den visuella representationen av model-delen. Flera olika view-delar kan representera samma model. Varje view är associerad med en controller-del.

Controller sköter interaktionen med användaren. Controllern får indata i form av inmatning av data eller olika events, till exempel knappklick med musen, för att sedan kommunicera med model-delen och visa resultatet i view-delen. Interaktionen i systemet sker enbart mellan användaren och Controller-delarna. (Buschmann m fl 1996)

För att ytterligare demonstrera vad de olika delarna har för ansvar så följer ett exempel från Microsofts (ASP.NET MVC Overview 10/5-12) hemsida:

Model används ofta för att spara eller hämta ett visst tillstånd av ett Model-objekt. Till exempel ett Model-objekt av en produkt kan hämta data om produkten från databasen,

manipulera datan och sedan skicka tillbaka datan och uppdatera produkt-tabellen i databasen.

View skulle kunna vara en vy där användaren kan ändra egenskaperna av en produkt. view- delen presenterar då det nuvarande tillståndet av produkt-objektet med till exempel

inmatningsformulär, rullmenyer eller kryssrutor.

Controller används i detta exempel till att skicka, om ändringar ska göras av datan som representeras i view-delen, datan som skall ändras till model-delen så att den sedan kan skicka till exempel en MYSQL-fråga till databasen för uppdatering av produkt-objektet.

20

6.2 Beståndsdelar

Nedan beskrivs MVC-mönstret enligt de beståndsdelar som mönster innehar från kapitel 4 (4 Mönster) enligt Buschmann (Buschmann m fl 1996):

6.2.1 Namn

Model-View-Controller (MVC)

6.2.2 Problem

Kontexten MVC tillämpas i interaktiva system med grafiska användargränssnitt. Det generella problemet för dessa typer av system är att de vidareutvecklas ofta, då nya krav för systemet ställs av användarna.

Olika användare kan kräva olika sorters interaktion med systemet. Till exempel så kan en sorts användare vilja använda tangentbordet för att interagera med systemet medan en annan vill använda sig utav musen och klicka. Dessa olika krav kräver olika sorters

användargränssnitt för samma system, vilket i sin tur gör att det bör vara enkelt att tillämpa olika sorters användargränssnitt för samma system.

I exemplet ovan kan ett stort problem vara att presentation och funktionaliteten av systemet är för beroende av varandra. Det tvingar utvecklare att utveckla nya mindre del-system om till exempel ett nytt interface för systemet ska utvecklas. Det kräver att alla dessa del-system behöver underhåll och när en ändring sker i systemet kan flera olika del-system påverkas.

Här presenteras några krafter som påverkar lösningen:

 Samma information presenteras i olika sorters vyer (olika användargränssnitt från exemplet ovan)

 All datamanipulering i systemet måste uppdatera alla presentationer av systemet (om data ändras så ska alla de olika vyer som presenterar datan uppdateras).

 Att modifiera användargränssnittet för systemet ska vara enkelt att utföra.

6.2.3 Lösningen

Vid tillämpning av MVC-mönstret delas interaktiva system upp i tre olika delar:

datahantering, presentation och inputlogik. Dessa tre delar representeras av: Model, View och

21

Controller. Models ansvar är datahanteringen i systemet. Model innehar funktionalitet för att notifiera alla beroende views om ändring av data sker. Model är helt ovetandes om

inputlogiken eller presentationen av data. Views ansvar är presentationen av data från model.

Controllers ansvar är inputlogiken och interaktionen. Kommunikationen mellan dessa delar sköts av controller-delen. Controller tar emot input och anropar sedan models eller views.

6.2.4 Konsekvenser

Här nedan beskrivs några konsekvenser som finns vid tillämpningen av MVC-mönstret.

Fördelar med MVC

Separationen av Model-delen från Controller-delen och View-delen gör det möjligt för flera olika views att presentera samma model-objekt.

Views presenterar datan i realtid då models notifierar sina beroende views så de kan uppdateras när ändring sker.

Genom att Model-delen är separerad från både View-delen och Controller-delen så är det lätt att byta ut eller lägga till de två sistnämnda utan någon större påverkan på systemet i stort.

Nackdelar med MVC

MVC är inte alltid är det bästa sättet att designa ett interaktivt system. Separationen av Model, View och Controller gör att det blir fler delar vars relationer behövs hanteras, vilket gör att komplexiteten i systemet ökar. För små interaktiva system så kan separationen betyda att enbart komplexiteten ökar utan någon vidare vinst i form av separation.

När Model-delen av systemet alltid notifierar alla beroende views så kan det leda till att många onödiga uppdateringar sker, då vissa View-presentationer av Model-delen kanske inte ens påverkas av ändringen.

Tight Coupling-problemet nämndes tidigare i kapitlet (se 5.1 Beskrivning) och är ett problem med Controller-delen och View-delen i en MVC-struktur. Då både Controller-delen och View- delen är helt beroende av Model-delen, plus att flera par av controllers och views kan vara beroende av samma Model-del, kan en ändring i Model-delen göra att delar av systemet slutar att fungera.

22

7 UML

Följande kapitel handlar om modelleringsspråket UML, vad det är och en beskrivning av olika diagram och diagramtyper i UML.

7.1 Beskrivning

UML är ett standardiserat visuellt modelleringsspråk, Unified Modeling Language.

Specifikationen för standarden togs fram och handhas av OMG (Object Management Group).

Arbetet med UML började 1994 då förespråkare för olika modelleringsspråk gick ihop för att skapa ”Unified Method” som senare blev UML-standarden. Den första versionen av

standarden togs fram 1997. Version 2.0 som ligger till grund för dagens version togs fram 2005. Nya versioner av standarden tas fram kontinuerligt och den senaste versionen av UML är version 2.4.1. som togs fram i augusti 2011. (Uml Resource Page, 2011)

Modelleringsspråket är ett försök att kombinera de bästa teckensystemen och få ett förenat modelleringsspråk. Det innebär att UML är ett modelleringsspråk med teckensystem som möjliggör modellering av olika typer av system och applikationer. Det betyder nödvändigtvis inte att samma notation använd i alla fall utan vissa fall kräver viss notation som kan saknas i andra fall. UML har inte krav på att allt UML erbjuder ska användas i varje modell och inte heller är det så att varje typ av diagramtypsspecifik symbol måste finnas i ett diagram. Istället används det man behöver för att förmedla budskapet med modellen. Eftersom det i UML är valbart vilka symboler som används så är det lätt hänt att man missar att modellera detaljer om ett system. (Hunt 2000)

Vid objektorienterad modellering så är UML det modelleringsspråk som är den gemensamma vokabulär som används. I de mjukvaruverktyg som finns för modellering används UML i väldigt stor utsträckning. UML har spridit sig mycket sedan standarden först togs fram och är idag en de-facto standard för modellering inom främst mjukvarusystem.

UML byggs upp av ett antal olika diagram som tillsammans kan användas för att beskriva ett helt system i form av modeller. Modellerna fås genom att använda sig utav de olika

diagrammen samt den dokumentation och specifikation som släppts av OMG. UML innefattar 14 olika modeller/diagram som är uppdelade i tre olika typer av diagram: strukturdiagram, interaktionsdiagram och beteendediagram.(Uml Resource Page, 2011) Figur 2 visar ett exempel på ett UML-digram.

23

Figur 2. Ett class diagram som visar klasserna Student och Föreläsare som implementerar interfacet Person.

7.1.1 Strukturdiagram

Strukturdiagram används för att beskriva strukturen i ett system och används därför ofta för att dokumentera mjukvaruarkitekturen i ett system.

Class diagrams.

Dessa representerar klass-strukturen och klassernas relationer i ett system. Klasserna är grundläggande inom objektorienterad design och UML- notation. Class diagram är ett

diagram som har en direkt motsvarighet i koden i form av klasser och som därför är lättast att förstå som programmerare.(Hunt 2000)

Object diagrams.

Visar relationer mellan objekt under en viss tid.(Hunt 2000) Component diagram.

Dessa visar hur den mjukvara är uppdelad i fysiska komponenter och hur strukturen av koden ser ut. Detta i form utav filer med kod och deras relationer.(Hunt 2000)

24 Composite structure diagram.

Dessa diagram är nya för version 2.0 av UML. I takt med att system blir mer komplexa så blir relationerna mer komplexa. Composite structure diagram illustrerar en länkning av class diagram och component diagram. Kombinerat så visar det hur elementen tillsammans ger någon form av funktionalitet.(Pilone och Pitman 2005)

Deployment diagram.

Dessa visar hur systemet är uppbyggt fysiskt med vilken hårdvara som används och vilka nätverks som systemet involverar.(Hunt 2000)

Package diagram.

Dessa illustrerar specifika grupperingar av klasser och interfaces som paket. Samma notation som används för Class diagram.(Pilone och Pitman 2005)

Profile diagram.

Dessa är tilläggsmekanismer till UML. Object Management Group(OMG) har tagit fram arkitektur i form av en metamodell för att definiera UML. Profilerna gör att metamodellen kan användas för olika plattformar som t.ex. .NET eller J2EE.(UML Profile Diagrams)

7.1.2 Interaktionsdiagram

Interaktionsdiagrammen är en form av beteendediagram som visar kontroll av flöde och data i det man valt att modellera.

Communication diagram.

Dessa illustrerar hur meddelande skickas till och från element.(Pilone och Pitman 2005) Interaction overview diagram.

Dessa är en förenklad form av activity diagram. Fokus är vilka element som är involverade när en aktivitet utförs.(Pilone och Pitman 2005)

Sequence diagram.

De visar en sekvens av skickade meddelanden i kommunikation mellan olika objekt som utför en speciell uppgift. Diagrammen fokuserar på flödet mellan objekten i en

användarsituation.(Hunt 2000) Eftersom att sekvensdiagram är tidsbaserade så är dem lämpliga att använda för att kunna förstå en användarsituation i realtid(SYS-boken).

Timings diagram.

Dessa diagram visar tidsaspekten av meddelanden. De används ofta för att göra modeller av system i realtid som till exempel satellitkommunikation. De har en specifik notation för att visa hur lång tid det tar för system att starta en process eller skicka ett meddelande och om någon extern faktor påverkar.(Pilone och Pitman 2005)

25 7.1.3 Beteendediagram

Beteendediagrammen beskriver systemets beteende och används därför för att beskriva ett systems funktionalitet i helhet.

Use case diagrams.

Dessa visar interaktionen mellan aktörer i systemet. Därigenom visar diagrammen även på hur den grundläggande funktionaliteten ser ut i ett system.(Hunt 2000)

UML state diagram/state machine diagram.

Dessa illustrerar vilka olika tillstånd(states) ett objekt kan vara i och hur övergången mellan tillstånd ser ut.(Hunt 2000)

Activity diagram.

Dessa illustrerar flödet från ett beteende eller aktivitet, till nästa.(Pilone och Pitman 2005)

26

8 Resultat

Syftet med uppsatsen är att svara på frågor rörande en re-engineerinprocess där målet är att gå från ett befintligt system utan MVC-arkitektur till ett system med MVC-arkitektur. Vilka steg som kan användas för att utföra det tas fram. Dessa steg undersöks och om det finns

svårigheter som kan försvåra att dessa steg utförs. Utav dessa steg undersöks det om det finns risker och konsekvenser med att gå över till MVC-arkitektur. Den sista frågeställningen besvarar när det är ekonomiskt försvarbart att välja de steg som re-enigineering innebär istället för att bygga ett nytt system från grunden. Här beskrivs det resultat som tas fram i uppsatsen. De steg utifrån metoden som används beskrivs.

8.1 Analys av problemet

Av det problem som presenterades av uppdragsgivaren tas en lämplig uppgift fram. Det problem som uppdragsgivaren har är att deras nuvarande kod är svår att vidareutveckla.

Uppgiftsspecifikationen innefattar framtagning av modeller för det nuvarande systemet. Dessa modeller visar hur systemet ser ut strukturmässigt.

8.2 Problemlösning

För att lösa det problem som berörs i uppsatsen så används olika teorier, begrepp, tekniker och metoder. Den övergripande metodiken för uppsatsen är systemutvecklingsmetodiken. Det problem som uppdragsgivaren presenterat och de frågeställningar som uppsatsen behandlar rör re-engineeringprocessen. De steg som re-engineeringprocessen består behandlas i teorikapitlet om re-engineering. De steg i re-engineeringprocessen som används är första, andra, tredje, fjärde och femte. Dessa steg innebär att utvecklaren skapar en förståelse för systemet och upprättar en plan för hur de resterande sex stegen ska utföras. Den artefakt som tas fram är en samling modeller som ritats upp efter en analys utav valda delar av systemet.

Det modelleringsspråk som används i uppsatsen är det mångsidiga språket UML.

För att skapa en uppfattning om de aspekter som är viktiga vid re-engineeringarbete mot MVC-arkitektur används begreppet designmönster.

27

8.3 Grundproblemet och lösning med MVC

Uppdragsgivaren angav att deras problem med det nuvarande systemet är att koden är för dåligt strukturerad vilket gör vidareutvecklingen av systemet omständlig. Vid analysen av systemet identifierades det stora strukturproblemet.

Det nuvarande mönstret för systemets uppbyggnad är att alla olika presentationsvyer på sidan är uppdelade i egna filer som är helt självständiga, med undantag för databaskoppling. Det är en simpel lösning för att uppnå struktur som kan passa mindre hemsidor. Med mindre

hemsidor menas till exempel en hemsida för en frisörsalong med ett fåtal presentationsvyer och till största del statiskt innehåll. Det simpla mönstret kan fungera som lösning för mindre sidor när någon större utökning av systemet inte är planerad. Utvecklaren behöver då inte hålla reda på relationer mellan olika delar av systemet eftersom alla delar är självständiga med sin funktionalitet. Ett exempel på detta kan vara när en utvecklare ska lägga till en ny

presentationsvy i systemet, då måste utvecklaren skriva helt ny kod för all funktionalitet som presentationsvyn behöver för att utföra sin uppgift. Det betyder att om olika presentationsvyer har samma eller liknande funktionalitet blir duplicerad kod oundviklig. I figur 3 som visas nedan visas den struktur som hittades i systemet.

I den kod som finns så uppstår problem med vidareutveckling. Problemen är främst kopplade till duplicerad kod och kodsnuttar som är svåra att förstå. All duplicerad kod innebär att om en utvecklare utan kännedom om systemet vill ändra en tillsynes enkel funktion som görs flera gånger om i systemet så måste alla filer där det utförs hittas och modifieras. Det kan då handla om 20-talet modifieringar istället för en. När ny funktionalitet ska införas blir det omständligt eftersom att det inte går att använda tidigare kod på grund av att filerna i systemet är

självständiga. Problemet med att förstå kodsnuttar gör att utvecklaren har svårt att se var den nya koden ska skrivas.

Varför en MVC-struktur fungerar som en lösning för ett stort system som i detta arbete är för att vidareutveckling och underhåll förenklas markant. Detta på grund av att systemets struktur blir mer överskådlig. Systemets olika filsektioner och ansvarsområden har delats upp och benämns på ett logiskt sätt. Det gör att utvecklare som skall underhålla eller vidareutveckla systemet snabbt kan se vilka filer som skall förändras.

Problemet med duplicerad kod försvinner. Om en ny presentationsvy skall läggas till så behöver utvecklaren inte skriva helt ny kod utan kan använda sig utav objekt från Model- filerna beroende på vad som ska presenteras.

28

8.4 Kod och andra specifikationer

För att modellera ett system behövs tillgång till systemets källkod och övriga specifikationer. I detta fall finns enbart tillgång till systemets källdkod samt implementeringen av koden i aktuell miljö. För uppsatsarbetet sker tillgång till koden genom uppkoppling via FTP enligt överenskommelse med uppdragsgivaren. Den information som får delas vidare regleras enligt ett sekretessavtal som undertecknades innan tillgång till koden gavs.

8.5 Svårigheter, konsekvenser och risker

Här beskrivs de svårigheter, konsekvenser och risker rörande andra och tredje frågan i uppsatsens frågeställning.

8.5.1 Risker

Riskerna med att utföra re-engineering på ett system med över 200 filer är att utvecklaren inte snabbt kan skapa sig en uppfattning av hur mycket jobb som krävs under re-

engineeringprocessen. Risken finns att det tar längre tid att analysera systemets funktioner och dess struktur än vad det gör att skriva koden med MVC-arkitektur. Dessa faktorer kan i sin tur leda till att den utvecklare som tagit sig an uppdraget åt företaget väljer att sluta efter en tid då den funktionsproduktiva delen av arbetet dröjer och får mindre fokus.

8.5.2 Konsekvenserna

Konsekvenserna av utförd re-engineering är ett modifierat system som ska uppfylla krav specificerade av uppdragsgivaren. Förutom för systemet i sig tas dokumentation fram för hela systemet.

8.5.3 Detaljstudie av modeller och svårigheter

Det tredje steget i re-engineeringprocessen Familiarisation with the Existing Application är det steg där utvecklaren bekantar sig med de funktioner som systemet utför. Utvecklaren ska kunna svara på vad en funktion gör och hur den fungerar. I denna uppsats begränsas det steget till att innefatta djupare förståelse för index.php samt main.php. Index.php är den första fil

29

som laddas in när någon besöker webbplatsen Fragbite.se (se Fig 3.). Denna fil inkluderar olika filer beroende på vad besökaren har valt att klicka på. Att filen inkluderar en annan fil innebär att den laddar in det som står i filen. Ett besök direkt till www.Fragbite.se gör att index.php laddar in main.php som är den största delen av siten. Det som visas i main.php är indelat i vad som i denna uppsats valts att kallas sektioner. En sektion är ett kodblock som presenterar en del av webbplatsen. Varje sektion har sin egen logik och är ansvarig för sin presentation av det resultat den får fram. Sektionerna är skrivna i den ordning som sidan använder dem.

Fig 3. Visualisering av valda filer och sektioner på Fragbite.se. main.php markerad i rött och sektionen Nyhetslista markerad i grönt.

Index.php är den första filen som laddas när någon besöker fragbite.se. När index.php laddas så inkluderas flera filer som presenterar olika delar av sidan. Mittsektionen som är markerad i rött är presentationen av filen main.php. Vänsterspalten bredvid main.php är en annan fil som inkluderas av index.php, likaså högerspalten.

Den övergripande strukturen för det nuvarande systemet som bygger på att filer inkluderas för att fylla plats på sidan illustreras nedan:

30

Figur 4. Den övergripande strukturen för det nuvarande systemet som bygger på att filer inkluderas för att fylla plats på sidan.

Mittenspalten är den del av systemet som används för att visa de olika filerna. Filerna är helt separerade vyer för att visualisera olika saker. Separationen av detta slag gör att alla dessa filer innehåller all kod som behövs för att det ska kunna utföra sin uppgift. Mycket upprepad kod blir oundvikligt.

Main.php (markerat i rött på Fig 3.) är den första filen som inkluderas i mittsektionen på sidan. Den innehåller all den kod som behövs för presentationslogik samt datalogik.

Den övergripande strukturen för filen main.php illustreras nedan:

31

Fig 5. Den övergripande strukturen för filen main.php.

I figuren ovan visas hur det ser ut när systemet använder sig utav main.php för att presentera dess innehåll. Main.php är en av många filer som används för att presentera olika sorters innehåll i mittenspalten av systemet. Main.php kod har delats upp i olika sektioner beroende på funktionalitet och presentation. Nyhetssektionen visar en nyhetsrubrik med bild,

artikelsektionen visar en tabell med artiklar, coversektionen visar en tabell med covers till olika evenemang, listsektionen visar en tabell med de senaste nyhetsrubrikerna samt tradsektionen visar en tabell med populära trådar i forumet.

I figuren nedan illustreras schematiskt hur en MVC-struktur skulle kunna fungera som en lösning på problemet med den nuvarande strukturen:

32

Fig 6. Illustration av MVC-struktur för main.php

Figuren ovan illustrerar bara lösningen för main.php men eftersom systemet följer ett simpelt mönster är det sannolikt att lösningen fungerar för samtliga filer. Istället för att använda sig av stora filer med all funktionalitet för alla uppgifter så delas filerna upp i flera mindre filer.

Varje ny ”ruta” i figuren: models, views, controllers samt klasser representerar nya filer i systemet. Alla sektioner delas in i filer där inputlogik (controllers), presentationslogik (views) och datalogik (models och klasser) är separerade.

Main.php kommer med en MVC-struktur innehålla logik för att visa flera olika View-filer som är kopplade till olika Controller-filer och en Model-fil.

33

Under analysen av systemet framkom det att eftersom alla filer är nästan eller helt separerade från andra filer blir det oundvikligt med duplicerad kod i systemet om filerna har liknande funktionalitet. Detta är ett problem enligt Martin Fowler (Fowler 2000) som i sin bok Refactoring: improving the design of existing code bland annat nämner Bad Smells in Code, eller kod som stinker. Problemet med duplicerad kod är att det försvårar vidareutvecklingen av systemet. Modifiering av kod som är duplicerad kräver modifiering av samtliga kopior.

Mängden kopior kan vara svårt att överblicka. Problemet kan enligt Martin (Fowler 2000) lösas med metoden Extract Class vilket innebär att om en klass utför arbete som kan utföras av flera klasser extraheras det arbetet ur klassen ut till en egen klass.

Ett annat problem som framkom under analysen är att det är bristfälliga kommentarer i koden för filerna. Bristen på dokumentation av systemet och bristen på kommentarer i koden ökar tiden för förståelse av systemet.

Nedan i 8.5.3.1 visas en modell av sektionen vilkens uppgift är att hantera och presentera listan med länkar till de senaste nyheterna.

8.5.3.1 Sektion: Nyhetslista

Visualisering av sektionen nyhetslista i main.php:

34

Figur 7. Visualisering av sektionen nyhetslista i main.php.

I ovanstående figur visualiseras sektionen Nyhetslista med en schematisk MVC-struktur uppdelad i datalogik och presentationslogik. Detta för att visa vilka delar som skulle kunna motsvara model-delen och view-delen för just denna sektion.

Sektionen Nyhetslista består av all funktionalitet för att visa en tabell med länkar till de senaste nyheterna. Varje gång main.php öppnas så körs alla sektionerna i main.php enligt följande:

1. Först skickas en MYSQL-fråga till databasen för att hämta nyheterna för de senaste två dygnen.

2. En villkors-sats kontrollerar om det är färre än 8 nyheter i resultatet från MYSQL- frågan. Om det är färre än 8 nyheter så skickas en ny MYSQL-fråga till databasen för att hämta de senaste nyheterna från flera dygn med en gräns på 8 nyheter.

35

3. Skapar en array Array1 som tilldelas resultatet från MYSQL-frågan.

4. En MYSQL-fråga för att hämta sticky-nyheter skickas till databasen.

5. Skapar en array Array2 som tilldelas resultatet från föregående MYSQL-fråga.

6. Villkors-sats som kollar om det finns någon nyhet som både Array1 och Array2 innehåller. Om det stämmer så tas nyheten bort ur Array1

7. Array1 och Array2 slås ihop.

8. Innehållet i Array3 presenteras i main.php.

8.5.3.2 Exempel på MVC-struktur för Sektion: Nyhetlista

Nedan följer ett exempel på hur sektionen efter analysen kan delas upp för att uppnå en MVC- struktur:

Figur 8. Exempel på MVC-struktur.

Förklaring av modellen enligt MVCs olika beståndsdelar:

Model är markerat i rött på bilden och består då av all datalogik för hela sektionen. Model skapas i Model-mappen som en egen fil med ett namn som motsvarar vad det är för modell, till exempel Nyheter_model.php. Nyheter_model innehåller då all datalogik för Nyhets-objekt

36

som används i systemet. En klassfil med innehållande klass för att kunna hantera Nyhets- objekt i systemet implementeras. Namnet för klass-filen namnges efter vad för typ av objekt den representerar, i detta fallet nyheter. Ett bra namn kan då vara Nyhet. Klassen innehåller egenskaper som titel, brödtext och skribent för en nyhet. Dessa egenskaper går sedan att använda i systemet där Nyhets-objekt hanteras. För denna sektion skapas en funktion i Nyheter_model som heter Nyhetslista, som innehåller logiken markerat i rött ovan. När Nyhetslista-funktionen blir anropad av controllern så returneras en array (Array3 på bilden) innehållande flera Nyhets-objekt.

View är markerat med grönt på bilden. Enligt modellen ovan så kommer View-delen enbart bestå av presentationslogiken för objektet från modellen. Viewn skapas i en mapp under View-mappen med ett namn som motsvarar vilken modell den presenterar, i detta fallet Nyhetlista. I Nyhetslista-mappen kan då en index-fil för Viewn skapas. Presentationslogiken i detta fallet består av kod som itererar igenom och presenterar Array3 i form av en tabell med länkar till nyheterna.

Controllern för Nyhetslista-viewn anropas när main.php View öppnas. Nyhetlista-controllern anropar Nyheter_model som returnerar ett Nyheter_model-objekt från funktionen Nyhetlista.

Nyhetslista-controllern anropar sedan Nyhetslista-viewn med Nyheter_model-objektet.

När sektionen separeras till Model, View och Controller delas de olika ansvarsområdena för sektionen upp i olika filer, vilka placeras i en logisk mapp-struktur. Nedan visas ett exempel på mapp-strukturen:

Figur 9. Exempel på mapp-struktur enligt MVC.

System med en MVC-arkitektur är uppdelade i följande ansvarsområden; Model (datalogik), View (presentationslogik) samt Controller (inputlogik).

37

Utvecklare kan snabbt hitta en fils sektionstillhörighet och funktion/ansvar i mapp-strukturen när utveckling skall ske.

Ett exempel på underhåll av en presentationsdel i systemet kan vara att presentationen av nyhetslistan ska ändras. Ändringen kan vara att färgen på tabellen eller strukturen på länkarna behöver justeras. Om utvecklaren känner till MVC-strukturen vet denne snabbt att detta sköts i Nyhetlista-viewn, och behöver därför enbart arbeta med den filen.

Ett exempel på vidareutveckling av systemet kan vara att en ny View för att visa en nyhet med brödtext skall öppnas när någon av länkarna i nyhetslistan används. View-delen som ska läggas till använder sig utav någon typ av Nyhets-objekt och därför bör den nya View-delen och tillhörande Controller-del kopplas till Nyheter_model och inkluderas i mapp-strukturen med namn som knyter dom till Nyheter. Ny funktionalitet i Nyheter_model implementeras för att returnera ett Nyhet-objekt som representerar en nyhet. Funktionaliteten för att returnera Nyhet-objektet till den nya View-delen är kod som manipulerar data till den form som view- delen behöver. Kod som används i Model-delen för detta arbete kan vara bland annat PHP och MySQL.

Nedan visas en figur av hur mapp-strukturen ser ut efter tillägget av Nyhet_controller och Nyhet-view:

Figur 10. Exempel på mapp-struktur enligt MVC med tillägg av Nyhet_controller och Nyhet-view.

Nyhet-klassen och Nyheter-models funktionalitet för att returnera en nyhet i pseudokod:

Titelparameter, brödtextparameter samt skribentparameter är parametrar som skickas med anropet av Nyhet-klassen från Model-delen.