Ruby on Rails lämpar sig relativt väl för utveckling av webbapplikationer. Det stora utbudet av externa bibliotek kombinerat med att stora delar av komplexiteten bakom hantering av web- requests och databaser sköts av Rails, gör det väldigt enkelt och tidssparande att utveckla nya funktioner.
Rails kommer dock inte utan problem. Inlärningskurvan uppfattades av projektgruppen som relativt hög på grund av ”convention over configuration”-filosofin som kräver att ut- vecklarna vet hur ramverket förväntar sig att koden ska skrivas. Den höga inlärningskurvan visades också då den första funktionen som gruppen implementerade tog mycket längre tid än de senare funktionerna.
Ett annat potentiellt problem med Ruby on Rails är skalbarhet. Som diskuterades i Avsnitt 6.2 har ramverket kritiserats för att det är långsammare och skalar sämre än liknande ramverk.
A
Adam Lindberg – Arkitektur
vid utveckling i Ruby on Rails
A.1 Inledning
Ruby on Rails, som förkortat kallas Rails, är ett ramverk för webbutveckling som bygger
på designmönstret model-view-controller (MVC). Rails hjälper utvecklaren att följa denna konvention vilket gör att utvecklingen automatiskt blir styrd efter denna arkitektur. Gör detta att behovet av en mjukvaruarkitektur ser annorlunda ut i ett projekt där utvecklingen sker med hjälp av detta ramverk? Det är något som ska undersökas i denna utredning.
A.1.1 Syfte
Syftet med denna studie är att utreda behovet av en mjukvaruarkitektur vid utveckling i Rails. Detta ska göras med hjälp av de erfarenheter projektgruppen fått under arbetet med Boardeaser Contracts.
A.1.2 Frågeställning
De frågeställningar som ska besvaras i denna utredning är följande:
1. Vilka behov finns det av en mjukvaruarkitektur, utöver den inbyggda MVC-strukturen som följer med ramverket vid utveckling i Rails?
2. Hur såg behovet av en arkitektur ut för projektgruppen under utvecklingen i detta pro- jekt?
A.1.3 Begränsningar
Denna utredning kommer att utgå från de erfarenheter som projektmedlemmarna fått från ar- betet med Boardeaser Contracts. Detta kommer även att backas upp med teoretisk information om ramverket Ruby on Rails samt mjukvaruarkitekturer generellt. Någon vidare utredning om hur behovet ser ut för projekt som skiljer sig från detta kommer dock inte göras men kommer diskuteras.
A.2. Bakgrund
A.2 Bakgrund
Vid utveckling av en webbapplikation finns det många olika tillvägagångssätt. Några av valen som har stor betydelse är vilka språk och utvecklingsmetoder som ska användas. Även olika typer av ramverk och hjälpmedel kan användas för att underlätta utvecklingen. Dessa val var inget gruppen i detta projekt behövde göra, då det gällde en vidareutveckling av en befint- lig produkt vars ena krav var att använda sig av de språk och tekniker som redan fanns i huvudapplikationen.
Boardeaser, som är huvudapplikationen, är utvecklat i ramverket Rails som bygger på designmönstret MVC. Eftersom Rails följer principen konvention före konfiguration finns det redan en förbestämt metod för att lösa olika problem, på det sätt som utvecklarna anser är det bästa. Vid utvecklingen i detta projekt ska Rails konventioner följas vilket gör att utvecklingen automatiskt blir väldigt styrd och strukturerad. Betyder detta att den arkitektur som skapades i början av projektet inte behövs, eller kommer den komma till användning i andra sammanhang?
A.3 Teori
Detta avsnitt tar upp nödvändig kunskap som behövs för att kunna svara på frågeställningarna i detta kapitel.
A.3.1 Mjukvaruarkitektur
Syftet med en mjukvaruarkitektur är att ge en översiktlig bild av hur ett mjukvarusystem är tänkt att se ut. En arkitektur består av ett systems huvudkomponenter i form av moduler. Den ska även innehålla information om hur dessa moduler interagerar med varandra och ge en övergripande bild om vad modulerna ska innehålla. Arkitekturen tas fram med hjälp av de krav som har tagits fram för systemet. Vid framtagningen av arkitekturen är det även viktigt att tänka på vilka strukturer som lämpar sig bäst för systemet. Dessa strukturer gör att systemet blir lättare att utveckla då de vedertagna tekniker som är specialiserade på att lösa ett visst problem. Därför blir valet av struktur ofta gjort automatiskt genom att analysera vad systemet ska göra. Större system kan även använda flera olika strukturer samtidigt. Några exempel på vanliga strukturer är MVC, klient-server (eng. client-server) och flerlagersarkitektur (eng. multitier architecture) [95].
Mindre system kan klara sig utan en arkitektur men det kan komma att vara användbart vid utvecklingen för nästan alla system. Med att ett system klarar sig utan en arkitektur menas ej att systemet inte har någon arkitektur utan bara att ingen arkitektur explicit har designats, alla system har en arkitektur. Inom traditionell mjukvaruutveckling var det vanligt att designa och dokumentera systemet in i minsta detalj. Detta ledde till att utvecklaren endast behövde översätta designen till kod och behövde ej ta några egna beslut. Då allt fler företag börjar gå mot agila utvecklingsmetoder ändras även sättet för hur system designas. Mindre tid läggs på design och dokumentation och mer ansvar läggs på utvecklaren som får göra lågnivådesignen samtidigt som koden skrivs. Detta gäller speciellt för mindre system där en explicit arkitektur ej behövs i samma utsträckning som för stora system [95].
A.3.2 Detaljerad design
Nu för tiden behöver applikationer hantera väldigt stora mängder data vilket sparas i systemets databas. Detta gör att även systemets databas kan vara intressant att designa. Databasdesign är dock något som går lite utanför omfånget för vad en arkitektur ska innehålla då detta ska göras vid den detaljerade designen som är nästa fas i utvecklingen. När en databas ska designas används ofta ett entitetsrelation-diagram (eng. entity-relationship diagam, ER-diagram) för
A.4. Metod
att modellera databasen. Detta kan vara till stor hjälp vid utvecklingen och speciellt vid implementationen av själva databasen [95].
A.4 Metod
För att svara på frågeställningarna i denna utredning krävdes först en förståelse för hur Rails fungerar. Detta gjordes genom att läsa guider om Rails för att praktiskt kunna testa på utveckling men även genom att läsa boken Agile Web Development with Rails [85] för mer teoretisk kunskap. Vidare erhölls erfarenhet och kunskap genom utveckling av detta projekt. I projektets slutskede togs en enkät fram för att samla hela projektgruppens gemensamma erfarenheter av att jobba med Rails.
A.4.1 Enkät
En enkät togs fram för att samla projektgruppens gemensamma erfarenheter av att jobba med Rails. Denna skapades med google’s tjänst Forms och bestod av 3 huvudfrågor. En av frågorna hade även ett extra frivilligt fält för att utveckla deras svar och enkäten avslutades med en öppen fråga med möjlighet att ge en kommentar utöver det som efterfrågades i enkäten. Frågorna som enkäten bestod av var följande:
1. Har du använt dig av arkitekturen vi skapat som stöd vid utveckling under projektets gång?
2. Anser du att vi har haft användning av arkitekturen som vi skapat?
3. Om du anser att vi ej har haft användning av arkitekturen, finns det något vi kunde gjort annorlunda vid framtagning av denna?
4. Anser du att en arkitektur behövs, utöver MVC-strukturen som är inbyggd i Ruby on Rails?
5. Är det något du vill tillägga som ej efterfrågades i formuläret?
A.5 Resultat
Nedan presenteras resultaten från de Railsguider som följts. Därefter följer en sammanställning av resultaten från den enkät gruppmedlemmarna fick svara på.
A.5.1 Resultat från Railsguider
Grunden till denna utredning ligger i projektet som utvecklats i Rails. För att få en förståelse för Rails granskades och följdes guider som gick igenom steg för steg hur en exempelapplikation byggs upp. Genom att följa guiderna vid informationsinhämtningen kunde gruppen praktiskt testa på sina nyvunna kunskaper vilket gav en ökad förståelse för hur allt fungerar och hänger ihop. Detta gjorde att utvecklingen av projektet lättare kunde sättas igång och tips och tricks från guiderna kunde användas.
A.5.2 Resultat från enkäten
Detta avsnitt innehåller en sammanställning av resultaten från den enkät gruppmedlemmarna fick svara på.
A.5. Resultat
Figur A.1: Gruppmedlemmarnas svar på fråga 1
På frågan om de använt sig av arkitekturen under projektets gång svarade hälften av gruppen att de använt arkitekturen minst en gång och hälften hade aldrig använt sig av den. Detta illustreras i Figur A.1.
Figur A.2: Gruppmedlemmarnas svar på fråga 2
Trots att hälften av gruppen hade använt sig av arkitekturen under projektets gång så var det endast en tredjedel som tyckte att den var användbar. Två tredjedelar av gruppen ansåg att det hade gått lika bra utan den. Detta illustreras i Figur A.2.
A.6. Diskussion
På frågan om vad som hade kunnat göras annorlunda vid framtagningen av arkitekturen för att få den mer användbar så tyckte tre stycken att gruppen skulle ha väntat med att göra arkitekturen. Detta då gruppen hade dålig kunskap inom Rails i början och därav inte lade fokus på de delar som hade varit användbart i utvecklingen av projektet. En tyckte att mer fokus skulle ha lagts på databastabeller och modeller (eng. model) istället för moduler. Två av medlemmarna visste ej vad som hade kunnat göras annorlunda. Svaren från denna fråga illustreras i Figur A.3.
Figur A.4: Gruppmedlemmarnas svar på fråga 4
Den fjärde frågan var om de ansåg att en arkitektur behövs, utöver den MVC-struktur som är inbyggd i Rails. Där svarade två att en arkitektur inte behövs då MVC-strukturen i Rails redan ger tillräckligt med struktur i koden. Två gruppmedlemmar ansåg att en arkitektur är nödvändig ändå. En svarade ”Kanske inte just för vårt projekt då vi inte utvecklade det från grunden” och den sista svarade ”Det beror på storleken av projektet. Stora projekt med komplexa databaser och kontrollers kräver nog ändå arkitektur.”. Detta illustreras i Figur A.4.
Ingen gruppmedlem hade något att tillägga på den femte öppna frågan.
A.6 Diskussion
Detta avsnitt innehåller diskussion angående de resultat som presenterats med anknytning till syftet, frågeställningarna samt teorin. Diskussion kommer även ske kring den valda metoden samt en alternativ metod.
A.6.1 Diskussion av resultat
Alla i projektgruppen har tidigare gått en kurs i programutvecklingsmetodik och har därifrån fått en viss förståelse för vad en mjukvaruarkitektur ska innehålla. Efter att en kravspecifi- kation hade tagits fram skulle en arkitektur designas för systemet. Detta gjordes med hjälp av en systemanatomi och användningsfall (eng. use-cases). Därefter identifierades de huvud- sakliga modulerna som ritades i ett UML-diagram där pilar visade informationsflödet mellan modulerna. Efter att detta dokumenterats kände sig projektgruppen nöjd med vad som tagits fram, men det visade sig att det inte var rätt för just detta projekt. Eftersom Rails bygger på designmönstret MVC skiljer sig behovet av en arkitektur mot om utvecklingen hade skett utan detta ramverk. Rails ger en ram att bygga applikationen i vilket gör att utvecklaren ej kan göra hur som helst i form av att strukturera upp moduler och liknande. Detta är menat att göra utvecklingsprocessen lättare och snabbare så länge Rails konventioner följs [85].
Det var inte något projektgruppen hade i åtanke vid tiden för framtagningen av arkitek- turen, vilket ledde till att fokus hamnade på fel delar av arkitekturen. Detta ledde till att
A.6. Diskussion
majoriteten av projektgruppen ej kände att arkitekturen var till någon hjälp vilket illustreras i Figur A.2. I Figur A.3 finns svar på vad gruppmedlemmarna ansåg kunde göras annorlunda vid framtagningen av arkitekturen, för att göra den mer användbar. Hälften av gruppmedlem- marna att vi skulle vänta med att skapa arkitekturen tills projektgruppen hade mer kunskap om Rails. En tyckte även att fokus borde lagts på databastabeller och modeller, vilket tro- ligtvis hade varit fallet om den hade gjorts senare i utvecklingen, när gruppen hade fått mer kunskap inom området. Detta betyder att mindre tid skulle ha lagts på arkitekturen och mer på detaljdesign då databasdesign ej tillhör omfånget för arkitekturen [95].
Om utvecklingen av arkitekturen hade väntat så skulle projektgruppen kunnat ha funderat på vad för logik som skulle läggas i vilka kontroller (eng. controllers), vyer (eng. views) och så vidare. Istället designades moduler som genereras automatiskt av Rails, informationsflödet mellan olika moduler planerades vilket även det sker per automatik. Allt detta blev överflödigt då det bestäms automatiskt av ramverket. Det som faktiskt kom till användning var de an- vändningsfall som skapades. Det tvingade projektgruppen att fundera på hur olika funktioner skulle fungera. När arkitekturen väl var framtagen var det dock inget som användes igen då gruppen nu visste hur funktionerna skulle implementeras.
Vad ansåg projektgruppen angående behovet av en arkitektur till detta projekt? Om man utgår från den enkät som nämndes i resultatet så var åsikterna delade angående detta. Hälften av gruppmedlemmarna säger sig ha använt arkitekturen minst en gång men bara en tredjedel av medlemmarna anser sig ha haft nytta av den. Som skapare av enkäten svarade jag ej på den själv men mina erfarenheter kan vara intressanta att lyfta fram ändå. Hade jag svarat hade det resulterat i ännu en person som ej använt eller haft nytta av arkitekturen. Arkitekturen togs fram av mig som arkitekt i samarbete med utvecklingsledaren samt konfigurationsansvarig. Utöver själva framtagandet samt revidering av detta dokument är det dock ej något jag har använt eller tänkt på över huvud taget. Min syn på arkitekturen är att det var något som behövde göras för kursmålet men som ej var nödvändigt för just detta projekt, i alla fall inte i det utförande som den gjordes denna gång. För att arkitekturen skulle bli användbar i detta projekt hade den behövt göras senare i utvecklingsprocessen. Detta var ej möjligt då projekt- gruppen hade deadlines styrda av en kurs vilket ej var skräddarsytt för just detta projekt. Hade upplägget sett annorlunda ut hade det varit möjligt att lägga mer tid i utbildningsfa- sen av projektet innan arkitekturen påbörjades. Men eftersom utvecklingen skedde i Rails och projektets omfång ej var speciellt stort hade den MVC-struktur som kommer med ramverket räckt, vilket även nämns i boken Essentials of Software Engineering[95].
A.6.2 Diskussion av metod
Den ursprungliga idén var att använda tidigare forskningsmaterial att ställa mot de erfaren- heter projektgruppen haft under utvecklingen. Detta var dock ej möjligt då ingen tidigare forskning eller litteratur inom det specifika området kunde hittas. Önskvärd litteratur ha- de varit inom området framtagning av arkitektur vid utveckling i Rails. Informationen som hittades via sökningarna var begränsad till den inbyggda arkitekturen i Rails och inte kring behovet av en utökad arkitekturplanering. Det ledde till att undersökningen endast grundar sig på de erfarenheter som gruppmedlemmarna erhållit från detta projekt. Detta kopplas ihop med teori om Rails och arkitektur generellt för att försöka skapa en så bra bild som möjligt. Det finns absolut brister i detta då urvalet är väldigt litet med endast sju personer. Trots att det hade varit önskvärt var det svårt att bredda urvalet då det ej var fler projektgrupper inom denna kurs som utvecklade i Rails. Även projektmedlemmarnas erfarenhet är en brist i denna undersökning då projektet endast pågick i cirka fem månader. Ingen hade heller tidi- gare erfarenhet från att jobba med Rails vilket betyder att studien baseras på de erfarenheter som erhölls under denna femmånadersperiod. Det som hade kunnat göras annorlunda är att tillfråga ett större urval av utvecklare, gärna med större erfarenhet av att jobba med Rails. Att samla personer till detta är dock något som ligger utanför denna utrednings tidsmässiga resurser.
A.7. Slutsatser
A.7 Slutsatser
I detta avsnitt knyts utredningen ihop och svar på de frågeställningar som ställdes i början av kapitlet går att finna här.
A.7.1 Vilka behov finns det av en mjukvaruarkitektur, utöver den
inbyggda MVC-strukturen som följer med ramverket vid
utveckling i Rails?
Rails tillhandahåller ett gediget ramverk för utveckling av webbapplikationer. Detta gör att en extern arkitektur i de flesta fall inte behövs. Vid utveckling av stora applikationer med komplicerade modeller, vyer och kontroller är det dock en bra idé att ha en arkitektur ändå. En sådan arkitektur bör då vara inriktad på hur logiken ska delas upp i olika kontroller och vyer. Användningsfall är även något som kan vara väldigt användbart för att skapa en tydlig bild av hur olika funktioner ska fungera. För större projekt kan det även vara användbart att designa databastabeller och modeller.
A.7.2 Hur såg behovet av en arkitektur ut för projektgruppen under
utvecklingen i detta projekt?
I detta projekt fanns det ej några större behov av en arkitektur då omfånget på projektet ej var speciellt stort. Ramverket som Rails tillhandahåller räckte i detta fall gott och väl för att få en bra struktur på koden. Dessutom hade projektgruppen vid tiden för framställning av arkitekturen alldeles för dålig kunskap inom området för att kunna göra en arkitektur som skulle kunna komma till nytta. Det som ansågs användbart var de användningsfall som skapades för arkitekturen då det fick projektgruppen att fundera över hur olika funktioner skulle fungera.
B
Christian Thorarensen – En
övergripande jämförelse mellan
webbutvecklingsramverken
Ruby on Rails och Django
B.1 Inledning
Detta individuella bidrag till rapporten handlar om skillnaden mellan två ramverk för webb- utveckling. Det första ramverket, Ruby on Rails, har projektgruppen använt vid utveckling av Boardeaser Contracts webbapplikation. Det andra ramverket, Django, skulle ha varit intressant om projektgruppen själv fick välja ramverk, eftersom det bygger på programmeringsspråket Python.
B.1.1 Motivering
I projektet Boardeaser Contracts var det ett krav från företaget Boardeaser AB att använda webbutvecklingsramverket Ruby on Rails. Projektgruppen hade ingen valmöjlighet gällande detta. Ett annat webbutvecklingsramverk som annars hade varit intressant är Django, som ba- seras på programmeringsspråket Python. Båda ramverken marknadsförs som produkter som ska förenkla och snabba upp webbutvecklingen. De har också designats av erfarna webbutveck- lare som utlovar smart design. Varför skulle en utvecklingsgrupp vilja välja det ena ramverket framför det andra?
B.1.2 Syfte
Denna jämförelse mellan webbutvecklingsramverken Ruby on Rails och Django görs för att bättre förstå följande fråga: Varför skulle ett företag eller en privatperson välja Ruby on Rails framför Django, eller tvärtom? Ingen i projektgruppen hade använt Ruby som programme- ringsspråk innan projektets start. Det kan därför vara svårt att motivera varför gruppen skulle välja Ruby framför Python som alla gruppmedlemmar redan kunde. Jämförelsen kan också användas som bevis på att projektgruppens inlärda kunskaper om Ruby on Rails faktiskt har relevans.
B.1.3 Frågeställning
För att få en bra överblick av skillnaderna mellan Ruby on Rails och Django ska följande frågeställningar undersökas:
B.2. Teori
1. Vilka krav eller begränsningar finns på vilka utvecklingsverktyg som kan användas till ramverken?
2. Vilka större märkbara skillnader finns mellan ramverkens historia?
3. Vilka tillhandahåller bibliotek till ramverken och vart kan biblioteken hämtas?
4. Vad finns det för skillnader och likheter i den övergripande strukturen hos ramverken? 5. Vilka valmöjligheter finns gällande programmeringsspråk som kan användas till ramver-
ken?
B.1.4 Begränsningar
Ingen undersökning om varför Ruby on Rails och Django är olika kommer att göras. Endast skillnader och likheter mellan ramverken ska lyftas fram. Teori om Ruby on Rails och Django kommer endast presenteras och fördjupas så långt att respektive frågeställning kan besvaras.
B.2 Teori
Detta avsnitt tar upp nödvändig teori för att identifiera övergripande likheter och skillnader mellan webbutvecklingsramverken Django och Ruby on Rails.
B.2.1 Django
I denna del av teorin tas historia, utvecklingsverktyg, design och välkända webbapplikationer upp som gäller Django.
B.2.1.1 Historia
Django växte fram genom utveckling av verkliga webbapplikationer. Webbprogrammerarna Adrian Holovaty och Simon Willison kan anses som skapare när de år 2003 började använ- da Python för att bygga webbapplikationer. De tillhörde ett webbutvecklingsteam i Kansas,