framförallt frontend är det mycket viktigt att ha en mjukvaruarkitektur som är lättförståelig och gör att alla får samma bild av systemet men även en som tillåter för att effektivt kunna lösa de problem som står framför gruppen. Som Artem Syromiatnikov och Danny Weyns skriver i inledningen till “A Journey through the Land of Model-View-Design Patterns” kan detta vara en ganska svår uppgift då skillnaderna mellan olika arkitekturmönster ibland är väldigt subtila men kan ha stor påverkan på projektets framgång. [61]
Här återges nödvändig bakgrundsinformation för att ge en bild av hur både MVVM och arkitekturen i DIM ser ut och fungerar.
Den här rapporten avgränsas till arkitekturer rörande (men ej nödvändigtvis begränsade till) frontend för att hålla den någorlunda koncis.
A.3
Teori
Här beskrivs nödvändiga begrepp och bakgrundsinformation samt de två arkitekturerna som jämförs.
A.3.1
Vad är en mjukvaruarkitektur?
En mjukvaruarkitektur kan anta många olika fysiska former och vara mer eller mindre ab- strakt. Dessa former är beroende på vad för information som ska förmedlas till vem, till ex- empel kan den beskriva hur data eller information flödar i systemet eller hur kod ska struk- tureras och förhålla sig till olika delar av ett system. En arkitektur kan delas upp i olika ab- straktionsnivåer, på samma sätt som en klassisk byggnadsarkitektur kan delas upp i ritningar över hela huset, våningar, rum eller ytor kan och ska en arkitektur delas upp på liknande sätt. Vem När information ska förmedlas till en viss grupp av användare används ofta vyer. En vy kan beskriva för en utvecklare hur en komponent eller modul kommunicerar med en annan. En vy kan även beskriva för en tekniker hur hårdvara ska konfigureras och så vidare.
Vad (artefakter) Den information som ska förmedlas kan beskrivas med hjälp av till ex-
empel diagram, här används ofta UML (Unified Modeling Language) [62]. För att ge mer bakgrund eller information till dessa diagram kan mer förklarande texter skrivas samt ko- dexempel produceras. Arkitektens artefakter är absolut inte nödvändigtvis begränsade till dessa. Se Eclipse’s OpenUP processramverk för mer information[63].
A.3.2
Begrepp
Här förklaras ett antal begrepp som används i rapporten.
Data Information i ett system, till exempel, strängar, bilder eller andra objekt.
Dataflöde (data flow) En applikations dataflöde säger hur data kommer från punkt A till
punkt B i ett system.
Horisontellt dataflöde Data kan flöda horisontellt, till exempel mellan två syskon. Se figur
A.1
Vertikalt dataflöde Data kan flöda vertikalt, till exempel mellan förälder och barn. Se figur
A.1.
Unidirectional Data Flow Data flödar endast åt ett håll, oftast från förälder till barn. Uni-
directional Data Flow populariserades av React [30] och har visat sig mycket fördelaktigt för att hålla komplexiteten av utvecklingen nere.
A.3. Teori
Figur A.1: Förälder/barn Dataflow.
Bidirectional Data Flow Data flödar i båda riktningar.
Tillstånd (state) Tillståndet (eller state) är den data som för tillfället lagras, används eller på något annat sätt behövs för webbapplikationens fungerande.
Oföränderligt (immutable) Begreppet oföränderligt används ofta när data diskuteras, mer
specifikt krävs det i många tillståndslagringar att tillståndet är oföränderligt. Det innebär att när ny data tillkommer ska den gamla inte ändras utan användas tillsammans med den nya för att generera ett nytt tillstånd.
A.3.3
Klassisk MVC
MVC står för Model, View och Controller. Model sparar och/eller ändrar applikationens data som ska visas för användaren av View (vyn/UI) och Controller är den delen av mjukvaran som sköter inmatning från en användare. Det är det klassiska MVC-mönstret som en stor del av mjukvara bygger på. Denna har senare anpassats, modifierats och evolverat till mönster som används idag. Man gör till exempel skillnad på web MVC och desktop MVC.
A.3. Teori
Förhållandet mellan Model, View och Controller kan variera men i nutida webbimple- mentationer vilar det största ansvaret på Model och View dels då användarens upplevelse och data fått en central roll i dagens webbapplikationer men även för att rollen Controller numera abstraherats en aning, inmatning hanteras av webbläsaren och utvecklaren därmed inte behöver ta hänsyn till det så mycket utan kan fokusera på vad inmatningen ska göra i webbapplikationen [64][65]. Se figur A.2 för översikt.
Figur A.2: MVC.
A.3.4
MVVM
MVVM[66] är en utveckling av MVC och står för Model, View och ViewModel. Generellt sett är ViewModel är ett objekt som lagrar data som används av View och synkroniserar data mellan View och Model, den används även för att behandla data som flödar mellan dessa. Implementationen av ViewModel kan såklart skilja sig en aning beroende på vem du frågar eller var du får din information.
MVVM förkroppsligar på ett sätt det som nämndes tidigare, nämligen att Controllern numera sköter så kallad “business logic” det vill säga att exempelvis formatera och skicka data till lagringen istället för att hantera input. Dock kan Controllerns roll anses vara aningen inbakad, om inte abstraherad till att kunna skötas av ViewModel med JavaScripts framfart inom världen av webbutveckling. Se figur A.3 för översikt.
A.3.5
Komponentbaserad arkitektur
Arkitekturen för den nutida webbsidan baseras mer och mer på komponenter. En komponent är bara en del av ett helt system men även denna är ofta implementerad med ett MVVM eller annat MV* (Model, View, Whatever) mönster[67]. Det innebär alltså att en applikation som är implementerad som en komponentbaserad arkitektur består av komponenter som i sin tur implementerar exempelvis ett MVVM mönster.