Teknik och samhälle Datavetenskap
Examensarbete
15 högskolepoäng, grundnivå
Parametrisering av förskämningsmodeller
Parameterization of spoilage modelsAnton Forsberg
Erik Haglund
Examen: Kandidatexamen 180 hp Huvudområde: Datavetenskap Program: Spelutveckling Datum för slutseminarium: 2015-06-03Handledare: Åse Jevinger
Sammanfattning
Dynahmat är ett projekt inom vilket matematiska modeller används för att predicera ett flertal olika livsmedels förskämningstid förutsatt aktuella miljötemperaturer, vilka uppmäts av sensorer. I detta examensarbete behandlas parametrisering av dessa förskämningsmodel-ler, med målet att alla livsmedels modeller ska följa en gemensam grund som kan tillämpas för att skapa nya instanser av förskämningsmodeller. Metoderna som tillämpas i arbetet är en kombination av design science och en för arbetet framtagen metod som kombinerar mate-matiskt arbete med mjukvaruutveckling. Den gemensamma modellgrunden tas fram genom att studera och parametrisera varje förskämningsmodell individuellt. Alla parametriserade modeller jämförs sedan med varandra, och modifieras så att en gemensam grund erhålles. Med denna gemensamma grund utvecklas ett konceptbevis för ett administrationsverktyg. Med detta verktyg kan en användare skapa nya förskämningsmodeller, endast genom att definiera ett uttryck för de matematiska parametrar som finns tillgängliga i verktyget. Som resultat presenteras ett förslag på en allmän modellform för förskämning av de livsmedel som behandlas i arbetet samt en prototyp för administrationsverktyget, baserat på den all-männa modellformen. Lösningens metod för beräkning av förskämningstid valideras med hjälp av jämförande data från det aktuella systemet. Det resulterande lösningsförslaget löser många av de problem som fanns i den tidigare hårdkodade implementationen, och kalkylerar förskämningstider med ett genomsnittligt fel på under 1 %.
Abstract
Dynahmat is a project within which mathematical models are used to predict the spoilage time, assuming current environmental temperatures which are measured by sensors, for a number of different food products. In this thesis, these models are parameterized with the aim of finding a common form which can be used for the instansiation of new spoilage models. The method applied in this thesis is a combination of design science and a new method with the intention of combining software development with mathematical model-ling. The common model form is produced by individually studying and parameterizing every spoilage model. Each parameterized model is then compared to the other models, and modified in such a way that a common expression is found. Using the final common model, a proof of concept for an administrative tool is developed. This tool allows the user to create new spoilage models, simply by defining an expression for the mathematical parameters available in the application. As result, a proposal for a common model form for predicting the spoilage time for the food products relevant in this thesis is presented, in conjunction with a prototype for the administrative tool based on this model form. The solution’s method of calculating spoilage times is validated by comparing results with that of the previously existing system. The resulting proposed solution solves a lot of the pro-blems in the previous, hard-coded implementation, and calculates spoilage times with an average error deviation of under 1 %.
Innehåll
1 Inledning 1
1.1 Bakgrund och tidigare forskning . . . 1
1.1.1 Bristfälliga bäst-före-datum . . . 1 1.1.2 Dynahmatprojektet . . . 1 1.1.3 Förskämningsmodeller . . . 1 1.1.4 Tidigare forskning . . . 2 1.2 Arbetets utgångspunkt . . . 2 1.2.1 Ursprunglig implementation . . . 2 1.2.2 Tillhandahållna modeller . . . 2 1.2.3 Modellparametrar . . . 3 1.3 Frågeställning . . . 4 2 Metod 5 2.1 Metodbeskrivning . . . 5 2.1.1 Parametrisering . . . 6
2.1.2 Matematisk evaluering av textsträngar . . . 7
2.1.3 Utveckling av Testmiljö . . . 8
2.1.4 Validering av parametriserade modeller . . . 9
2.1.5 Utveckling av prototyp för administrationsverktyg . . . 9
2.2 Alternativa metoder . . . 10
2.2.1 Testmetoder . . . 10
2.2.2 Implementationsmetoder . . . 11
2.2.3 Hevners Design Science . . . 11
2.2.4 Intervju och enkät . . . 11
2.3 Metoddiskussion . . . 12 2.3.1 Parametrisering . . . 12 2.3.2 Utveckling av Testmiljö . . . 12 2.3.3 Validering . . . 13 2.3.4 Prototyp för administrationsverktyg . . . 13 3 Resultat 14 3.1 Parametriserade modeller . . . 14 3.1.1 Gemensam parametrisering . . . 14 3.1.2 Parametrisering av bakterietillväxten . . . 15 3.2 Utvecklad mjukvara . . . 16 3.2.1 Testmiljö . . . 16 3.2.2 Prototyp av administrationsverktyg . . . 17 4 Analys 20 4.1 Design Science . . . 20 4.2 Validering . . . 20 4.3 Generaliserbarhet . . . 23
5 Diskussion 25
5.1 Arbetets styrkor . . . 25
5.2 Arbetets begränsningar . . . 25
5.3 Problem . . . 26
5.3.1 Användbarhet kontra effektivitet . . . 26
5.3.2 Otydligheter i tillhandahållen information . . . 26
6 Slutsatser och vidare forskning 27 Referenser 28 A Sökhistorik för litteraturstudie 30 B Matematisk redogörelse 31 B.1 Kvadratiska funktioner . . . 31
B.2 Exponentiella funktioner . . . 32
C Kod för implementerad mjukvara 33 C.1 Append . . . 33
C.2 NCalcExpression . . . 33
C.3 MathExpression . . . 33
C.4 Evaluate . . . 34
D Tillhandahållen hårdkodad implementation 35 E Tillhandlahållna excel-filer 36 E.1 Torsk (Dalgaard) . . . 36
E.2 Keso (Østergaard) . . . 38
E.3 Skinka (Devlieghere) . . . 40
E.4 Skinka (Kreyenschmit) . . . 42
1
Inledning
1.1 Bakgrund och tidigare forskning
1.1.1 Bristfälliga bäst-före-datum
Det årliga matsvinnet i Europa uppskattas till över 100 miljoner ton [6]. En av anled-ningarna till det stora matsvinnet är att det finns brister i dagens märkning av bäst-före-datum, vilken inte tar hänsyn till livsmedels temperaturer under transport och lagring [11]. Eftersom temperaturerna under kylkedjan inte uppmäts dynamiskt beräknas bakte-rietillväxten i livsmedlet preliminärt, vilket leder till felaktiga bäst-före-datum. Beroende på kylkedjan kan det verkliga bäst-före-datumet ligga tidigare eller senare än det angivna datumet [9].
1.1.2 Dynahmatprojektet
Dynahmat (dynamiskt hållbarhetsdatum för minimerat matsvinn) är ett projekt med fle-ra sammarbetspartners från olika industrisektorer. Projektet bygger på flefle-ra års forskning kring sensorer för dynamisk temperaturmätning, prediktionsmodeller och hur kedjans aktö-rer kan samarbeta och nyttja varandras information för att bidra till ett hållbarare samhäl-le. Syftet med projektet är dels att minska matsvinn men även att öka innovationsgraden i svensk livsmedelsindustri. Målet med projektet är att utveckla intelligenta logistik- och förpackningssystem, som i realtid kommunicerar och predicerar kvalitet och produktsäker-het hos kylda livsmedel. Lösningen ska kunna användas längs hela livsmedelskedjan hos såväl producenter, distributörer och konsumenter som i detaljhandeln. [5]
I Dynahmatprojektet används sensorer, som mäter temperatur för livsmedel vid spe-cifika intervall under kylkedjan och skickar dessa temperaturdata via en gateway till Dy-nahmats centrala system, där det lagras i en databas. Denna data används som indata i beräkningar av förskämningstider.
1.1.3 Förskämningsmodeller
Vid varje given tidpunkt under ett livsmedels produktion, lagring och transport hyser det en mikroflora som är karakteristisk för just det livsmedlet. Denna floras storlek och tillväxt är en funktion av råmaterialsfloran, processerings-, konserverings- och lagringsförhållanden. Trots att det finns stor möjlighet för variation i de senare tre, är det möjligt att med kunskap om några få kemiska och fysiska parametrar förutsäga vilka mikroorganismer som kommer att växa och dominera i ett givet livsmedel, och hur tillväxten kommer att se ut. [8]
För att göra denna förutsägelse hör till varje livsmedel i Dynahmatprojektet en för-skämningsmodell med vilken bäst-före-datum kan beräknas. Varje modell använder tem-peraturer som har mätts upp av sensorerna för att bestämma hastigheten på livsmedlets bakterietillväxt. Med hjälp av detta och tidpunkterna för mätningarna beräknas aktuell bakteriekultur och förskämningstid under nuvarande förhållanden. [11]
Idag hårdkodas varje ny modell, vilket innebär att för varje nytt livsmedel som skall analyseras i distributionskedjan måste en programmerare tillkallas. Eftersom flera av livs-medlen har liknande parametrar för mikrobiell tillväxt, torde det vara möjligt att para-metrisera modellerna så att en administratör kan lägga in nya modeller enbart genom att
definiera parametrarna. För detta examensarbete har fem modeller tillhandahållts. Tre av dessa gäller förskämningstiden för skinka (se Bilaga E.3, E.4 och E.5), medan övriga två gäller torsk (se Bilaga E.1) respektive keso (se Bilaga E.2).
1.1.4 Tidigare forskning
Detta examensarbete har som utgångspunkt tidigare arbete som utförts i Dynahmatpro-jektet i form av matematisk modellering av förskämningsprediktion (se Bilaga E). De ur-sprungliga förskämningsmodeller som är hårdkodade i systemet idag är förenklade, och härledda från fem artiklar som beskriver modeller för förskämning av keso [20], skinka [14] [13] [4], respektive fisk [3].
Samtliga artiklar innehåller härledning av och empirisk prövning för de förskämnings-modeller som beskrivs. De har tjänat ett visst syfte i detta arbete genom ett bidrag av ökad förståelse för mikrobiologin och matematiken bakom modellerna och deras paramet-rar, men har haft en mycket begränsad inverkan på det arbete som utförs. I realiteten är det Dynahmats förenklade och tillämpade modeller som är den huvudsakliga källan från vilken parametriseringen har utarbetats.
Det tycks finnas ett mycket tydligt forskningsgap som gjort sig uppenbart under infor-mationsinsamlingen tidigt i arbetet. Artiklar som beskriver förskämning av mat och deras parametrar generellt lyser med sin frånvaro. Alla tidigare studier om förskämning beskri-ver endast ett eller ett fåtal specifika livsmedel i likhet med de tidigare nämnda, från vilka förskämningsmodellerna härstammar. Även mer generella sökningar om parametrisering av matematiska modeller ger resultat med studier som innehåller tillämpningar i diverse tekniska fält, men inga av dessa har varit tillämpningsbara för detta arbete. Istället har arbetet huvudsakligen baserats på den tidigare forskning på vilken Dynahmats förskäm-ningsmodeller är baserade, samt de tillhandahållna modellerna. För en lista över användna nyckelord under sökning, se Bilaga A.
1.2 Arbetets utgångspunkt
1.2.1 Ursprunglig implementation
För att implementera en ny förskämningsmodell i det existerande systemet krävs det att en programmerare tillkallas för att skriva den PHP kod som är nödvändig för den weblös-ning som i dagsläget används. Problemet med denna lösweblös-ning är att de som är involverade i Dynahmat-projektet inte själva kan lägga till modeller när det blir nya tillgängliga vil-ket försvårar arbete. Att anställa utomstående på detta sättet skapar både kostnads- och effektivitetsproblem. För exempelkod från en metod för beräkning av förskämningstid för skinka, se Bilaga D.
1.2.2 Tillhandahållna modeller
I följande lista finns de fem förskämningsmodeller som tillhandahölls för examensarbetet, samt källor för de artiklar modellerna ursprungligen baserades på. Alla modeller innehåller en livsmedelsspecifik konstant för maximal bakteriehalt, Nmax. Modellerna räknar ut en förskämningstid genom att räkna ut tiden det kommer ta för bakteriehalten att gå från den nuvarande bakteriehalten Nx (vilken beräknas i ett separat steg), till den maximala
bakteriehalten Nmax, förutsatt beräknad bakterietillväxt (µmax). Funktionen för
bakterie-tillväxten är unik för alla livsmedel, men är alltid funktionellt beroende av temperaturen i vilken livsmedlet förvaras.
1. Torsk (Dalgaard m.fl. [3]) tagen från erhållen excel-fil (se Bilaga E.1) Tid till förskämning = ln 10·(log Nmax−log Nx)
µmax +
4 ln 2 µmax
2. Keso (Østergaard m.fl. [20]) tagen från erhållen excel-fil (se Bilaga E.2) Tid till förskämning = ln 10·(log Nmax−log Nx)
µmax
3. Skinka (Devlieghere m.fl. [4]) tagen från erhållen excel-fil (se Bilaga E.3) Tid till förskämning = ln 10·(log Nmax−log Nx)
µmax
4. Skinka (Kreyenschmidt m.fl. [13]) tagen från erhållen excel-fil (se Bilaga E.4) Tid till förskämning = ln 10·(log Nmax−log Nx)
µmax
5. Skinka (Mataragas m.fl. [14]) Tagen från erhållen excel-fil (se Bilaga E.5) Tid till förskämning = ln 10·(log Nmax−log Nx)
µmax
För samtliga förskämningsmodeller har det verifierats att dessa har sin grund i de artiklar på vilka de påstås vara baserade. Till detta arbete har även en stor mängd beräknings-och mätdata tillhandahållts. Den mest användna datan beräknings-och matematiska informationen har sammanställts i Bilaga E.
1.2.3 Modellparametrar
Nedanstående fyra förskämningsparametrar förekommer i samtliga tillhandahållna model-ler men deras värden elmodel-ler matematiska uttryck skiljer sig. Det är därför viktigt att dessa parametrar finns med i en gemensam parametrisering. Av denna anledning är det dessa parametrar som är mest relevanta för parametriseringen i detta examensarbete.
Nmax = Bakteriehalten vid förskämning [log cfu/g]
T = Temperatur [◦C]/[K] µmax = Bakterietillväxt
Nx = Nuvarande bakteriehalt [log cfu/g]
i formeln för Nx förekommer även parametrarna
∆t = Tid sedan senaste sensormätningen [Arbiträr tidsenhet]
Nx−1 = Bakteriehalt vid föregående beräknad förskämningstid [log cfu/g]
Nämnvärt är även att genomgående i arbetet gäller att log = log10
Nedanstående parametrar är konstanter och förekommer i modellernas olika uttryck för bakterietillväxt (µmax) men är inte relevanta för problemet med parametrisering av
mo-dellerna. Detta för att de är helt specifika till en modell. µref = Refensvärde för bakterietillväxt
Tmin= Minimumvärde för temperatur
Tref = Referensvärde för temperatur
P Hmin= Minimumvärde på surhet
P Hmax= Maximumvärde på surhet
P H = Logaritmiskt mått på surhet aw = Vattenaktivitet
awmin= Minimal vattenaktivitet
b = Okänd konstant (2.5 · 10−6) C = CO2-halt (50 procent)
CO2= Koldioxidhalt
CO2max= Maximal koldioxidhalt
1.3 Frågeställning
I detta arbete kommer följande frågor att belysas:
1. I vilken utsträckning är det möjligt att parametrisera de existerande förskämnings-modellerna på så sätt att två eller flera modeller kan beskrivas med ett gemensamt matematiskt uttryck?
2. Hur kan modellerna i sin parametriserade form tillämpas så att ett administrations-verktyg för att lägga in nya modeller kan tas fram, vilket av användaren inte kräver några tillägg i form av kod, utan endast i form av matematisk definiering av para-metrar?
2
Metod
2.1 Metodbeskrivning
För att belysa frågeställningen användes en egen metod. Figur 1 demonstrerar visuellt hur denna ser ut. Syftet med metoden var att parametrisera förskämningsmodellerna till former som av ökande grad liknade varandra, tills en gemensam form var framtagen. Den-na användes sedan för att utveckla en prototyp för administrationsverktyget. På vägen utvecklades en testmiljö för att säkerställa att de modeller som parametriserades kunde implementeras på sådant sätt att de gav samma beräkningsdata som de oparametriserade modellerna.
Figur 1: Visuell representation av metoden som tillämpats
För att stärka empirin i utvecklingen av mjukvarutartefakter och arbetet överlag, tillämpades ovanstående metod i samverkan med forskningsparadigmet design science för informationssystem såsom den beskrivs av Peffers m.fl. [18]. Enligt samma författare är det centralt för att utöva forskning i design science att artefakten som skapas utvecklas genom att dra nytta av redan existerande teorier och kunskap för att lösa ett tidigare olöst problem. Den existerande kunskap och teorin som nyttjas i detta arbete är de tillhållna modellerna och artiklarna på vilka dessa baseras, vilka omnämns i Avsnitt 1.1.4. Under arbetet har de sex aktiviteter som beskrivs av Peffers m.fl. [18] genomförts. En djupare analys av hur vår tillämpning av design science följer teorin finns i Avsnitt 4.1.
Enligt Chard m.fl. [2] tar design science upp uppgifter som ställs till utvecklare för att öka förståelsen av vad som fungerar eller inte, men även hur tekniker för att utveckla eller utvärdera programvara kan förbättras, och blir därmed ett verktyg för sammarbete mellan industin och den akademiska världen.
Mjukvaruartefakter som har utvecklats under arbetet är skrivna med objektorienterad kod. Detta har enligt Sneed m.fl. [19] många fördelar, såsom återanvändning av kod och optimering. Programmeraren strävar ofta efter att skriva kod som inte bara löser de exi-sterande problemen och funktionaliteter utan även framtida. Å andra sidan kan testning av ett objektorienterat program så sätt att alla användarfall täcks i många fall vara både tidskrävande och kostsamt.
För att testa mjukvaruartefakterna som producerats för detta arbete har vi valt att använda funktionell testning snarare strukturell testning. Funktionell testning, eller Black-box-testning är en teknik för programvarutestning där testaren inte behöver tidigare kän-nedom om programkoden, utan testar programmet genom användning [10]. Detta för att göra det möjligt att fokusera på de delar av projektet som är mer relevanta. För dessa tes-ter har vi valt att använda error guessing och acceptance testing som testmetoder. Detta istället för att göra en mer rigorös testning som branch-coverage eller liknande metoder som testar all körbar kod i programmet.
Bertolino [1] skriver att error guessing är en teknik där testfall designas specifikt för att hitta möjliga fel i det aktuella programmet. Här kan det vara användbart om testaren har en källa över funna fel från tidigare och liknande projekt såväl som testarens egna expertis. Acceptance testing verifierar att systemet uppfyller användarens krav, vilka bör ha specificerats redan sedan tidigare.
2.1.1 Parametrisering
För att parametrisera förskämningsmodellerna användes ett strukturerat matematiskt till-vägagångssätt. I ordets vidaste bemärkelse är parametrisering en metod i vilken man delar upp en formel i sina beståndsdelar för att göra den mer modulär [15].
Exempel på en parametrisering av cirkelns ekvation: [15]
x2+ y2 = R2 x = R cos(t)
y = R sin(t) , t ∈ [0, 2π)
På samma sätt som ovan kan parametrisering tillämpas inom andra områden för att skriva en matematiskt formel i allmän form, eller flera modeller i en gemensam form. Oxford dictionaries [17] definierar order parametrisera som följer:
Parametrisera: Att beskriva eller representera i termer av en eller flera parametrar. [17] För att undersöka till vilken grad parametrisering av förskämningsmodeller av olika livs-medel till gemensam form var möjlig bröts de ursprungliga modellerna (se Avsnitt 1.2.2) ner till sina mest grundläggande komponenter. Dessa delades in i funktioner, konstanter och databasberoende variabler enligt Figur 2. Utifrån identifierade komponenter paramet-riserades varje ursprunglig modell för sig till en form som tydliggjorde alla mikrobiologiska komponenter.
För varje livsmedel vars modell parametriserades utfördes en jämförelse med den ur-sprungliga formen av andra livsmedels förskämningsmodeller för att se vilka gemensamma faktorer som fanns. Om två eller flera modeller hade tillräckligt mycket gemensamt para-metriserades dessa så att de kunde uttryckas på exakt samma form.
De fem tillhandahållna förkämningsmodellerna kunde skrivas på två former som visas i uttrycken 1 och 2 nedan.
ln 10 · (log Nmax− log Nx)
µmax
+ 4 ln 2 µmax
(1) ln 10 · (log Nmax− log Nx)
µmax
(2)
För att förenkla uttryck 1 gavs värdet för extratid till förskämning (4ln2) ett konstant-namn, B. Det syns även tydligt att båda sidor av additionstecknet i uttryck 1 kan skrivas över samma nämnare, vilket leder resulterar i uttrycket 3. Tack vare införandet av kon-stanten B kan alla modellerna skrivas på samma form.
ln 10 · (log Nmax− log Nx) + B
µmax
(3)
Figur 2: Alla komponenter av en parametriserad modell.
Den mest komplexa parametern som förekommer i modellerna är funktionen för bak-terietillväxten (µmax). Eftersom skillnaden i dessa uttryck var så stor krävdes en extra undersökning för att avgöra om det var möjligt att parametrisera dessa funktioner till några gemensamma former. Funktionerna plottades i en graf för att undersöka kurvorna (se Avsnitt 3.1.2).
2.1.2 Matematisk evaluering av textsträngar
För att låta användaren av administrationsverktyget ange värdena på modellparametrarna bestämdes att matematisk evaluering av textsträngar skulle användas. Detta innebär att
användaren anger värdet eller det matematiska uttrycket för en parameter som en text-sträng, vilken sedan behandlas och beräknas matematiskt. Beslutet att använda denna metod motiverades med två huvudsakliga argument:
• Användbarhet
Användaren ska inte själv ska behöva göra några matematiska förenklingar för att nå fram till en form som går att skriva in i programmet. Detta blir onödigt extraarbete som kommer sänka användbarheten i administrationsverktyget. Med textevaluering försäkras att modellparametrarna kan skrivas in i den form de skrivits i av mikro-biologerna, förutsatt att denna är matematiskt korrekt. Detta blir både enklare och mer tidseffektivt för användaren.
• Modularitet
Alla modellparametrar är inte konstanta värden. Bakterietillväxten (µmax) är en
funktion som är beroende av temperaturen och skiljer sig drastiskt mellan de olika modellerna. De väsentliga skillnader som finns i de olika modellernas funktion för bakterietillväxt (µmax) gör i sig att en textbaserad lösning är fördelaktig. Varje
så-dant uttryck har unika konstanter. Dessutom är bakterietillväxten kvadratisk i vissa modeller och exponentiell i andra. Detta innebär att den mest framtidssäkra lösning-en är dlösning-en som låter användarlösning-en skriva in parametrarna på vilklösning-en arbiträr matematisk form som helst.
För att genomföra denna textbaserade lösning användes under utvecklingen ett program-bibliotek för att förse utvecklaren med funktioner för matematisk evaluering av textsträng-ar. Av dessa finns ett antal olika på marknaden:
• math.js • muParser • JEval • NCalc
Från detta urval bestämdes att NCalc skulle användas. NCalc har fördelarna att vara både matematiskt omfattande och baserat på .NET, vilket i sig har många fördelar (se Avsnitt 2.1.3). NCalc klarar av att översätta en mängd olika operationer från textsträngar till matematiska uttryck, inklusive de fyra räknesätten, potenser, exponenter och logaritmer [16]. NCalc använder sig utav en syntax som är case-sensitive, vilket innebär att hela textsträngen måste vara exakt så som syntaxen står definierad i dokumentationen. 2.1.3 Utveckling av Testmiljö
För att kontrollera och testa den parametriserade formen av de existerande förskämnings-modellerna utvecklades en testmiljö. Denna skrevs i C# med hjälp av ramverket .NET, huvudsakligen för att kunna nyttja programmeringsbiblioteket Windows Forms, vilket han-terar utvecklingen av användargränssnittet på ett enkelt och tidseffektivt sätt. Detta pri-oriterades för att få fram en artefakt så snabbt som möjligt utan att behöva lägga tid på irrelevanta saker som utformandet av programmets utseende. Kraven för detta program var relativt få:
• Det skall finnas en lista över existerande förskämningsmodeller. • Användaren skall kunna definiera parametrarna för en modell.
• Programmet skall kunna beräkna en förskämningstid utifrån angivna parametrar. För de matematiska delarna av programmet användes biblioteket NCalc, vilket ger förmågan att översätta textsträngar till beräkningsbara matematiska formler och evaluera dessa (se Avsnitt 2.1.2). Denna testmiljö gjorde det möjligt att testa de parametriserade modellerna succesivt under projektets gång för att säkerställa matematiskt korrekt para-metrisering.
Testmiljön utvecklades i princip utan hänsyn till användbarhet eftersom denna endast var ett valideringsverktyg för parametriseringen. Den användes inte av några utomstående och all fokus låg därför kring funktionaliteten för att gatantera ett så säkert resultat som möjligt.
För testning av verktyget tillämpades i viss mån error guessing och acceptance testing (se Avsnitt 2.1) för att hantera så många som möjligt av programmets undantag och verifiera att det uppfyller alla krav.
Under testmiljöns utveckling genomgick denna regelbundna jämförelser med etablera-de matematiska verktyg för att säkerställa att uträkningarna gav korrekt resultat. Unetablera-der dessa jämförelser användes de ursprungliga, oparametriserade förskämningsmodellerna för att beräkna en förskämningstid som sedan kontrollerades med motsvarande beräkning av webbverktygen WolframAlpha och web2.0calc. Först när testmiljöns förmåga att kunna göra matematiskt korrekta beräkningar försäkrades påbörjades validering av de paramet-riserade modellerna. Denna testmiljö och dess validerade modeller låg som grund för hur prototypen av administrationsverktyget utvecklades (se Avsnitt 2.1.5).
2.1.4 Validering av parametriserade modeller
När testmiljöns tekniska förmågor hade testats så att beräkningar kunde utföras med en matematisk noggrannhet användes denna för att validera de modeller som tagits fram genom parametriseringen.
För att uppnå ett hållbart resultat under valideringen gjordes ett stickprov i den tillhan-dahållna data där förskämningsmodellens utdata från excel-filen jämfördes med de resultat som gavs av testmiljön utifrån samma indata (se Avsnitt 4.2). Detta för att verifiera att testmiljön kunde utföra beräkningar med en matematisk noggrannhet och därmed ligga till grund för prototypen av administrationsverkyget.
Resultat och analys av denna validering finns i Avsnitt 4.2. 2.1.5 Utveckling av prototyp för administrationsverktyg
Prototypens huvudsakliga syfte var att fungera som ett konceptbevis som kan användas som utgångspunkt för för en eventuell framtida webbimplementation. Prototypen var es-sentiell för att kunna besvara arbetets andra frågeställning (se Avsnitt 1.3).
För att kunna utföra en lämplig mjukvarutestning för prototypen då den är färdigut-vecklad togs en serie krav på funktioner fram vilka är listade nedan.
• Användaren skall kunna definiera modellspecifika konstanter, ange ett värde på dessa samt använda dem i de existerande parametrarna.
• Det skall vara möjligt att skapa nya modeller utifrån den gemensamt parametriserade formen och spara dem.
• Det skall vara möjligt att redigera existerande modellers parametrar.
• Användaren skall kunna ange alla de matematiska operationer som är nödvändiga för att skapa en ny funktion.
• Det skall vara möjligt att beräkna den aktuella tiden till förskämning.
Den lista över krav som nämns ovan har legat till grund både för utvecklingen av artefakten och för testningen. För testningen har listan över krav testats med acceptance testing genom black-box-testning (se Avsnitt 2.1) vilket möjliggör en effektiv testning där varje krav kan testas var för sig endast genom användning av artefakten.
Det fanns två grundläggande problem som prototypen var avsedd att lösa. Programmet behövde kunna nyttja de parametriserade modellerna matematiskt så att nya modeller kan läggas in och tillämpa den gemensamma form som nu existerade. Dessutom var det viktigt att detta gjordes på ett sådant sätt att användbarheten säkrades. Trots att den matema-tiska elegansen var viktig, prioriterades att prototypen var enkel och intuitiv att använda. För att lösa problemen användes en stor del av funktionaliteten från testmiljön (se Avsnitt 2.1.3). Funktionaliteten för användaren att definiera parametrarna för varje modell togs direkt från testmiljön, eftersom denna validerats och visats sig fungerande. Programmet förbättrades genom att implementera en knappsats för matematiska operationer. Detta gjordes för att minimera risken för användarmisstag.
En stor del av utvecklingstiden lades på omfattande felhantering, vilket innebär att i princip inga handlingar av användaren leder till att programmet kraschar. Garcia m.fl. [7] beskriver vikten av rigorös felhantering, och förklarar att i många av dagens system är upp till två tredjedelar av koden dedikerad till felhantering. Interna tester utfördes, vilka tilläm-pade error guessing-metoden (se Avsnitt 2.1) för att hitta så många ohanterade fel som möjligt. Dessa hanterades sedan i koden, oftast genom try-catch-satser där felmeddelandet kunde förmedlas till användaren.
Då prototypen var färdigställd gjordes en intern demonstration för att säkerställa en tekniskt lyckad implementation.
2.2 Alternativa metoder
2.2.1 Testmetoder
White-Box testing är en teknik för programvarutestning där testaren behöver en tidigare kännedom av koden för att skapa testfall [19]. Att använda white-box testning som testme-tod är ett väldigt effektivt sätt att hitta fel som uppstår i programmet genom att analysera koden. I detta projekt kommer denna typ av testning inte användas då de utvecklade arte-fakterna bara är att betrakta som prototyper för framtida program, och kommer därmed att användas som konceptbevis. Av denna anledning är det mer relevant att testa så att de önskade kraven uppfylls och inte att bevisa att det inte finns någon kod som inte är nåbar eller kan skapa problem.
Branch-coverage är en testteknik som ökar chansen att hitta fel i mjukvaruprogram . Detta genom att systematiskt testa varje gren av körbar kod. Statement-coverage testar varje sats i programmet.[19]
2.2.2 Implementationsmetoder
Det kan argumenteras att det hade funnits många fördelar med en webbaserad imple-mentation av administrationsverktyget. Eftersom det slutgiltiga syftet med arbetet från Dynahmats perspektiv var en webbimplementation hade en sådan kunnat föra vårt arbete närmare ett användbart verktyg.
För att tillämpa en sådan implementationsmetod hade i princip det framtida verktyg som beskrivs i Avsnitt 4.4 arbetats fram istället för det administrationsverktyg som ut-vecklats i detta arbete. Även testmiljön hade fått utut-vecklats som en webbaserad lösning för att kunna validera modellernas parametrisering i en webbimplementation.
Som tidigare omnämnt valdes denna metoden bort för att kunna ta nytta av tidigare erfarenhet, vilken inte sträcker sig till webbutveckling i tillräckligt hög grad.
Det är också tänkbart att metoden skulle kunna varit mycket mindre beroende på utvecklingen av mjukvaruartefakter, och itsället mer fokuserad på en teoretisk lösning av den första frågeställningen (se Avsnitt 1.3). Detta hade gjort att mer tid hade kunnat lagts på att undersöka parametriseringen noggrannare. Det hade å andra sidan inneburit att arbetets andra frågeställning hade fått lämnats ute fullständigt.
2.2.3 Hevners Design Science
Ett alternativ till att tillämpa design science enligt Peffers m.fl. [18] hade varit att istäl-let utgå från Hevner m.fl. [10], alternativt kombinera de båda. Den senare skiljer sig från förstnämna i vissa avseenden. Peffers m.fl. [18] väljer att definiera design science utifrån sex aktiviteter, vilka på ett väldigt praktiskt och enkelt sätt tar upp de steg forskaren bör genomgå för att tillämpa design science. Hevner m.fl. [10] beskriver istället sju riktlinjer, vilka snarare är saker att ha i åtanke under tiden design science tillämpas. Det tycks att Peffers m.fl. [18] är mer fokuserad på själva problemlösningen och utvecklingen av själva mjukvaruartefakterna, medan Hevner m.fl. [10] snarare lägger fokus på själva forskning-en och forskningsbidraget. Dforskning-en förstnämnda valdes för att dforskning-en ansågs vara lättare att applicera för detta arbete, men den sistnämna hade potentiellt kunnat leda till starkare forskningskoppling i empirin.
2.2.4 Intervju och enkät
För att besvara fråga 2 i frågeställningen (se Avsnitt 1.3) undersöktes intervju och enkät som potentiella forskningsmetoder. Att utföra undersökningar genom enkäter har många fördelar, som möjligheten att samla in stora mängder krav från användare utan att behöva utföra personliga intervjuer vilka tenderar att vara betydligt mer tidskrävande [12]. Detta trots att personliga intervjuer har möjligheten att ge mer specifika krav då intervjuaren kan anpassa frågorna efter situationen och den som blir intervjuad.
Enkät eller intervju gällande användarvänlighet hade gett möjligheten att producera analyserbar data utifrån framtagna prototyper eller konceptdemonstrerande bilder för att få insikt i hur designen av verktyget eller dess funktioner ses av en potentiell användare.
Detta skulle ske i form av fokuserad intervju [focused interview] där intervjuaren fokuserar på en användares upplevelser [12]. Under en fokuserad intervju skulle användaren även kunna testa redan etablerade matematiska verktyg såsom wolframalpha eller web2.0calc m.fl. för att få insikt i vilka för- och nackdelar användaren kan se genom användandet av ett sådant verktyg.
Att använda dessa forskningsmetoder betyder dock inte att de måste ligga till grund för hela arbetet, utan skulle kunna tillämpas senare i projektets gång som konceptbevis och användardefinierad feedback. I detta fall skulle detta arbetet kunna fortsätta efter utvecklingen av prototypen med intervjuer eller enkäter av de som testar den slutliga webblösningen.
Enkäter är något problematiska då den som svarar på enkäten ofta får begränsad in-formation och behöver skriva svar utan att diskutera dessa [12]. Enkäter bedrivs ofta utan personlig kontakt vilket försvårar kommunikationen [12]. Detta är anledningen till att vi valt att skapa en prototyp utifrån forskningsfrågan. Fokusen hamnade på en lösning av problemet och implementera de funktionaliteter som krävs för detta ändamål.
2.3 Metoddiskussion
2.3.1 Parametrisering
Eftersom vi inte hade någon tidigare insikt i projektet eller i vilken utsträckning modellerna kunde parametriseras valde vi att arbeta så systematiskt och täckande som möjligt. Detta gjorde vi genom att parametrisera alla modeller för sig och utveckla en egen testmiljö för att försäkra oss om att resultaten blev korrekta.
Valet av metod har gett oss förmågan att inkrementellt bygga upp vår empiri, och producera relevanta artefakter, vilket gör att vi anser den vara adekvat. I efterhand inser vi att vissa förändringar av metoden skulle kunna tillämpas för att ha gjort arbetet mer tidseffektivt, men då skulle vi antagligen inte nå samma insikt i problemet, vilket skulle ha försvårat analysen av lösningen. Något specifikt som hade kunnat effektiviserat arbetet hade varit att jämföra alla modeller i ett tidigare skede. Detta hade lett till att vi kommit till insikt om huruvida gemensam parametrisering var möjlig och även hur denna kunde se ut mycket tidigare, vilket hade gett mycket mer tid till implementation.
2.3.2 Utveckling av Testmiljö
Valet att prioritera funktionalitet framför användarvänlighet under utvecklingen av test-miljön lät oss fokusera på att lösa problemet med validering av parametriseringen på ett effektivt sätt. Att definiera precis vilka funktionaliter som programmet behövde innehålla utan att tänka på användarvänlighet ledde till ett tidseffektivt arbete.
Valet att tillämpa black-box testning är dels på grund av tidseffektivitet och dels på grund av hur omfattande urvalet av testfall behöver vara. Detta då prototypen endast skall ligga till grund för utvecklingen av administrationsverktyget och inte användas av allmänheten. På grund av detta kommer en del av mjukvaruartefakterna genomgå rigorös testning medans andra funktioner ligger utanför testfallen. Att använda black-box testning i form av error guessing och acceptance testing skapar möjligheten att utföra tester på specifiska funktioner utan vidare utveckling dedikerad för testning.
2.3.3 Validering
För att ge en övergripande sammanfatting av valideringen har både diskussionen av vali-deringen och all testdata sammanställts i Avsnitt 4.2.
2.3.4 Prototyp för administrationsverktyg
Trots att slutmålet för projektet var en webbaserad implementation av administrations-verktyget togs beslutet att den huvudsakliga prototypen skulle utvecklas som en deskto-papplikation. Detta motiverades baserat på vår tidigare programvaruutvecklingserfarenhet, vilken var mycket begränsad vad gäller webbutveckling. Istället för att lägga en stor del av arbetet på att utöka dessa färdigheter lades denna tid på att lösa själva huvudproblemen. Vi ansåg dessutom att en webbaserad lösning inte var essentiell för att besvara frågeställ-ningarna. Den uppenbara nackdelen med detta beslut var att prototypen kom längre från det önskade slutresultatet, en webbadministrationstjänst.
Vidare implementerades ingen databasfunktionalitet i prototypen, eftersom detta an-sågs vara ett triviellt problem som inte egentligen låg inom forskningsfokus för arbetet. Detta är något som enkelt kan implementeras i framtiden, men potentiellt tar tid, varför det inte prioriterades för detta examenserbete. Prototypen är dock kodad på ett sådant sätt att implementation av databaskommunikation ska vara så enkel som möjligt.
Valet att effektivisera utvecklingsprocessen av prototypen till högsta möjliga grad ge-nom att använda ramverket Windows Forms gav oss många fördelar som bidrog till att prototypen kunde genomföras snabbt och utan större motgångar. Genom att eliminera i princip alla tekniska utmaningar i utvecklingen av användargränssnittet kunde fokus istäl-let läggas på innehålistäl-let. Dessutom hjälpte design science-metoden till att tydligt sätta upp målen för programmet och problemen som programmet skulla lösa, och var ett viktigt verktyg för att försäkra användbarheten.
Vi har valt att implementera möjligheten för användaren att ange alla de matematiska operationer som används i de fem tillhandahållna modellerna. Det finns givetvis andra operationer, såsom derivator och integraler vilka kan komma att läggas till senare om framtida förskämningsmodeller kräver det.
3
Resultat
3.1 Parametriserade modeller
3.1.1 Gemensam parametrisering
Parametriseringsarbetet har visat att alla fem modeller kan skrivas på en gemensam form enligt formel 4. Detta är betrakta som ett förslag till svar på den första frågeställningen (se Avsnitt 1.3).
ln 10 · (log Nmax− log Nx) + B
µmax
(4)
Där Nmax och B är modellspecifika konstanter, µmaxär den modellspecifika funktionen för bakterietillväxt, och Nx är en databasberoende variabel. För definitionerna av dessa
parametrar, se Avsnitt 1.2.3.
Nedan visas de modellspecifika värdena för alla parametrar i den gemensamt paramet-riserade modellformen: 1. Torsk Nmax= 7.9 Nx= Nx−1+ µmaxln 10(∆t) B = 4 ln 2 µmax= (0.29 + 0.032 · T − 1.6 · 10−3· C − (9 · 10−5· T · C + (9 · 10−6· C2))2 2. Keso Nmax= 6.1 Nx= Nx−1+ µmaxln 10(∆t) B = 0
µmax= µref · ((T(T −Tref−T min)min) )2· (1 − 10(pHmin−pH)) ·
(aw−awmin) (1−awmin) 3. Skinka (Kreyenschmit) Nmax= 7.0 Nx= Nx−1+ µmaxln 10(∆t) B = 0 µmax= e42.97983−13323.93832∗ 1 T
4. Skinka (Devlieghere) Nmax= 7.0 Nx= Nx−1+ µmaxln 10(∆t) B = 0
µmax= b(aw − awmin) · (CO2max− CO2) · (T − Tmin)2
5. Skinka (Mataragas) Nmax= 8.62 Nx= Nx−1+ µmaxln 10(∆t) B = 0 µmax= e46.6162− 109.911 0.009314·T 3.1.2 Parametrisering av bakterietillväxten
För att noggrannare besvara arbetets första frågeställning (se Avsnitt 1.3) parametriserades modellernas uttryck för bakterietillväxt (µmax) för sig. I Figur 3, åskådliggörs hur µmax
för de olika modellerna följer två mönster: Två av funktionerna ökar exponentiellt och tre ökar kvadratiskt. I denna graf är endast kurvornas utseende relevant. Utifrån detta parametriserades alla modellers uttryck för µmaxtill utrycken för sina kurvor, det vill säga
kvadratiska respektive exponentiella funktioner (se Bilaga B för matematisk redogörelse).
Figur 3: µmax (bakterietillväxt) för samtliga modeller.
För två av modellerna för skinka ökar denna exponentiellt med temperaturen och kan beskrivas med formel 5
eK1+K2T (5)
där e är basen för den naturliga logaritmen (2,71828. . . ), T är temperaturen och K1, K2
medan bakterietillväxten för en av modellerna för skinka samt för modellerna för ost och torsk ökar kvadratiskt med temperaturen och kan beskrivas med formel 6
K1T2+ K2T + K3 (6)
där T är temperaturen och K1, K2, K3 är konstanter för bakterietillväxt.
3.2 Utvecklad mjukvara
3.2.1 Testmiljö
I Figur 4 visas det testverktyg som utvecklats som hjälpmedel för validering under projektet gång. I programmet visas den gemensamt parametriserade modellformen överst (punkt 1 i Figur 4). I den övre rullgardinsmenyn (punkt 2 i Figur 4) finns en lista med modeller som testaren kan välja att redigera och utföra beräkningar med. När testaren har valt en modell att redigera kan denne ange värden eller uttryck för alla parametrar genom att skriva in de i textrutorna i parameterområdet (punkt 3 i Figur 4). För att ange parametrarna måste testaren skriva in de i en form som följer NCalcs syntax, annars kan inte beräkningar genomföras. Detta innebär att för att använda de mer avancerade operationerna såsom logaritmer eller potenser krävs att testaren kan, eller har tillgång till, NCalcs syntax.
När testaren har definierat alla parametrar kan denne trycka på Store-knappen (punkt 4 i Figur 4) för att lagra modellen i programmet. Efter att modellen är lagrad kan testaren trycka på Calculate (punkt 5 i Figur 4), varpå programmet beräknar en förskämningstid. Beräkningen sker genom att använda NCalc-bibliotekets funktioner för att evaluera en beräkningssträng, vilken är utfylld med angivna parametrar. Resultatet av beräkningen läggs till i listan vid punkt 6 i Figur 4, vilket innebär att en historik över beräknade värden visas här. Det senast beräknade värdet är synligt överst. Själva beräkningen sparas även i listan vid punkt 7 i Figur 4 så att en historik över beräkningarna kan ses.
Figur 4: Testmiljö för validering av parametriserade modeller
Testmijlön är inte kopplad till någon databas, utan kräver att testaren anger statiska temperaturer i sitt uttryck för bakterietillväxten (µmax). I den tidigare existerande imple-mentationen arbetar modellerna inkrementellt på så sätt att de använder både nuvarande och tidigare uppmätta temperaturer och beräknade bakteriehalter för att kunna beräkna förskämningstider. Detta innebär att en databas krävs för att spara en historik över tidigare beräknade värden vilka sedan kan utläsas.
För värdet på den nuvarande bakteriehalten, Nx, vars beräkning kräver
databasfunk-tionalitet, använder programmet istället ett inprogrammerat värde som anpassas beroende på vilken modell som ska testas.
3.2.2 Prototyp av administrationsverktyg
I Figur 5 visas den utvecklade prototypen för det administrationsverktyg som ska låta en administratör lägga in nya förskämningsmodeller eller redigera existerande utifrån den pa-rametriserade grunden. Detta verktyg är ett förslag till svar på arbetets andra frågeställning (se Avsnitt 1.3).
Figur 5: Prototyp för parameterbaserat administrationsverktyg
För att lägga in en ny förskämningsmodell i programmet klickar användaren på Open (punkt 1 i Figur 5) och väljer sedan Empty Model. Användaren får nu upp en ny modell där alla redigerbara parametrar (Nmax, B och µmax) har värdet noll. Dessa parametrar syns i punkt 2 i Figur 5. För att ändra uttrycket eller värdet för en parameter väljer användaren vilken parameter som ska redigeras med radioknapparna som finns intill varje parameter (punkt 4 i Figur 5). Användaren redigerar sedan parameterns uttryck med hjälp av knappsatsen för matematiska operationer (punkt 5 i Figur 5). Genom att använda dessa operationer kan användaren bygga ett eget uttryck för parametern, vilket kan stå på ett flertal olika matematiska former. Parametrarna kan anges som enkla numeriska värden (mest aktuellt för Nmax), simpla operationella uttryck (mest aktuellt för B) eller som mer
komplexa funktioner (som i modellernas uttryck för µmax).
Användaren kan även definiera sina egna konstanter och lägga in dessa i parametrarna. För att skapa en konstant anger användaren ett namn och värde i rutorna vid punkt 6 i Figur 5 och klickar sedan på Create constant. Alla konstanter som skapas listas i en tabell (punkt 7 i Figur 5). Genom att dubbelklicka på en rad i tabellen, läggs konstanten till i parameterns uttryck. Modellens slutliga matematiska uttryck med alla definierade parametrarar visas i rutan på punkt 3 i Figur 5.
Användaren kan även öppna en existerande förskämningsmodell genom att klicka på Open (punkt 1 i Figur 5) och välja en modell från listan över alla modeller som existerar. När en existerande modell har öppnats visas alla parametrars definition (punkt 2 i Figur 5) och användaren kan redigera dessa precis som när denne skapar en ny modell.
I applikationens bakre lager (dolt från användaren), tillämpas matematisk evaluering av textsträngar genom NCalcs inbyggda evalueringsfunktioner. Varje parameter som är synlig för användaren har ett alternativt uttryck, skrivet i NCalcs specifika syntax. Detta innebär att varje gång användaren redigerar en parameter, redigeras dels den synliga versionen av parametern, och dels den osynliga NCalc-baserade versionen (se Bilaga C.1). På samma
sätt har även det kompletta uttrycket för modellen (punkt 3 i Figur 5) två versioner (se Bilagor C.2 och C.3). När användaren trycker på Calculate-knappen (punkt 8 i Figur 5) beräknas en förskämningstid genom att låta NCalc evaluera den version av modelluttrycket som följer NCalcs syntax (se Bilaga C.2).
Ingen databasfunktionalitet är implementerad, vilket innebär att användaren får ange ett statiskt temperaturvärde i sitt uttryck för µmax. Detta implementeras enkelt i framtiden
genom att införa en temperaturvariabel som användaren kan lägga in i parameteruttrycken, och vars värde utläses från databasen med uppmätt sensordata. När användaren trycker på Store (punkt 9 i Figur 5), ska båda versionerna (allmän matematisk och NCalc) av alla parametrar sparas i en databas så att dessa sedan kan användas för beräkningar av förskämningstider. Denna funktion är teoretisk, och inte ännu implementerad.
4
Analys
4.1 Design Science
För att analysera hur vår tillämpning av design science följer teorin, definierar vi i detta avsnitt hur varje av de sex aktiviteter för forskning inom design science som beskrivs av Peffers m.fl. [18] är kopplat till arbetet.
Problemidentifiering och Motivation
Problemet som försetts med lösningsförslag i detta arbete är den hårdkodade imlpe-mentation som används i Dynahmats system för prediktion av förskämningstid (se Avsnitt 1.2.1). Denna bygger på oparametriserade modeller med många olikheter, varför ny kod är tvungen att läggas in varje gång en ny modell läggas in i systemet. Mål för lösningen
Målen för lösningen av problemet var att en användaren skulle kunna använda admi-nistrationsverktyget för att skapa nya modeller utan att ny kod skulle behöva läggas till. Detta innebar att användaren var tvungen att kunna skapa instanser av förskäm-ningsmodellerna utifrån en grundform som var parametriserad så att alla modeller kan uttryckas på detta sätt.
Design och Utveckling
Designen och utvecklandet är dels knutet till själva parametriseringen av förskäm-ningsmodellerna, och dels till de mjukvaruartefakter som producerades under arbetet. Testmiljön utvecklades för att experimentera med implementation av dem paramet-riserade modellerna, samt att validera de. Administrationsverktyget utvecklades som ett mer omfattande konceptbevis.
Demonstration
Demonstrationen under arbetet skedde genom test av testmiljön och administrations-verktyget. Vid demonstrationen tillämpades olika former av black-box-testning för att testa och demonstrera verktygens funktionalitet.
Evaluering
Evalueringen gjordes genom validering av de parametriserade modellerna i testmiljön. Denna data sammanställdes i tabeller och jämfördes med tillhandahållen data. Kommunikation
Kommunikationen för detta arbete utgörs av denna uppsats. Genom att demonstrera och analysera framtaget lösningsförslag genom utvecklade prototyp och förslag till framtida utveckling har vi kommunicerat principerna, styrkorna och svagheterna med lösningen och arbetet överlag.
4.2 Validering
För att göra en effektiv men ändå täckande testning har en mängd testfall valts ut från den tillhandahållna datan för modellerna (se Bilaga E). I testen har beräknad tid till för-skämmning från excel-filerna jämförs med de resultat som gavs av motsvarande beräkningar i testmiljön som utvecklats. I tabellen nedan presenteras resultaten från denna testning.
Det är nämnvärt att det finns betydligt fler kolumner i de tillhandahållna excel-arken (se Bilaga E) än vad som testats, men att göra test med all tillhandahållen data hade tagit för lång tid.
För alla tabeller nedan gäller att Utdata 1 är tagen från tillhandahållen data medan Utdata 2 är beräknad med det testverktyg som utvecklats för validering.
Data från Skinkmodell (Devlieghere) (Bilaga E.3)
In-data Utdata 1 Utdata 2
Tid(h) T (C) Nmax Nx µmax Förskämning(h) Förskämning(h)
0 8 7.0 1 0.062 223.9 222.8
84 8 7.0 3.25 0.062 139.9 139.3
156 8 7.0 5.18 0.062 67.9 67.6
228 8 7.0 7 0.062 0 0
Data från Skinkmodell (Kreyenschmit) (Bilaga E.4)
In-data Utdata 1 Utdata 2
Tid(h) T (C) Nmax Nx µmax Förskämning(h) Förskämning(h)
0 8 7.0 1 0.0119 1162.8 1162.7
40 8 7.0 1.21 0.0119 1122.8 1122.0
80 8 7.0 1.41 0.0119 1082.8 1083.3
120 8 7.0 1.62 0.0119 1042.8 1042.6
Data från Skinkmodell(Mataragas) (Bilaga E.5)
In-data Utdata 1 Utdata 2
Tid(h) T (C) Nmax Nx µmax Förskämning(h) Förskämning(h)
0 8 8.62 1 0.029 611.8 605.0
20 8 8.62 1.25 0.029 591.8 585.2
Data från Fiskmodell (Bilaga E.1)
In-data Utdata 1 Utdata 2
Tid(h) T (C) Nmax Nx µmax Förskämning(h) Förskämning(h)
0 4 7.9 -1.4 0.117 206.1 206.2
22.5 -2 7.9 -0.3 0.03 687.2 721.8
29 20.4 7.9 0.62 0.63 31.1 31.0
Data från Keso (Bilaga E.2)
In-data Utdata 1 Utdata 2
Tid(h) T (C) Nmax Nx Listeria µmax Listeria Förskämning(h) Förskämning(h)
0 8 2 -2.4 0.02 514.6 506.6
1.5 6 2 -2.39 0.013 803.2 777.57
17 8 2 -2.26 0.019 514.7 516.26
För att kvantifiera felen som gavs vid testning analyserades statistiken genom att be-räkna mean absolute percentage deviation (MAPD).
MAPD är medelvärdet av den absoluta procentuella skillnaden mellan ett faktiskt värde och ett predicerat värde och beräknas enligt formel 7. I detta fall är de två värdena för-skämningstiden beräknad av testmiljön och förför-skämningstiden från excel. MAPD beräknas för att dra slutsatser om den relativa storleken på de fel som finns i beräkningsdatan för att försöka avgöra lösningens matematiska precision.
MAPD = 1 N N X t=1 At− Ft At · 100 (7)
där At är beräknad tid till förskämning från tillhandahållna excel-filer och Ftär beräknad
tid till förskämning med testverktyget.
Modell Utdata1 Utdata2 |%Skillnad| MAPD (modell) MAPD (alla modeller)
Skinka(D) 223.9 222.8 0.49 0.307 0.988 139.9 139.3 0.42 67.9 67.6 0.44 0 0 Skinka(K) 1162.8 1162.7 0.0086 0.0363 1122.8 1122.0 0.071 1082.8 1083.3 0.046 1042.8 1042.6 0.019 Skinka(M) 611.8 605.0 1.11 1.113 591.8 585.2 1.12 Fisk 206.1 206.2 0.049 1.802 687.2 721.8 5.035 31.1 31.0 0.32 Keso 514.6 506.6 1.56 1.683 803.2 777.57 3.19 514.7 516.26 0.30
Efter att felen har analyserats med MAPD konstateras att för de värden som testats finns ett medelfel på strax under 1 %. Det framgår att i modellen för Skinka(D) är felet mycket litet och i Skinka(K) näst intill försumbart, medan felet i övriga modeller överstiger medelfelet. I både modellerna för Fisk och Keso ökar medelfelet emellertid kraftigt tack vare extremvärden som ger relativt stora fel på 5 % respektive 3 %. I dessa fall är temperaturen så låg att förskämningstiden är över en månad och felet är på runt ett dygn. Det är nämnvärt att dessa värden valdes från Excel-datan just för att de ansågs vara extremvärden. Om fler värden hade valts och med en mer slumpmässig process hade medelfelet antagligen hamnat betydligt lägre, närmare det för Skinka(D) och Skinka(K)
De fel som uppstått vid testning är i stor utsträckning inte matematiska eller imple-mentativa utan beror på införandet av modeller i testmiljön. Med detta menas att felen varken kommer utifrån matematiska förenklingar eller att programvaran inte klarar av att utföra beräkningarna tillräckligt noggrant. Istället uppstår dessa fel antagligen på grund av att värdena som använts för beräkning av tid till förskämning i testmiljön är inskrivna direkt från excel, där det inte är möjligt att se exakt vilket antal värdesiffror som används i
beräkningarna. Majoriteten av dessa fel skulle troligtvis lösas vid en riktig implementation där excel inte är en del av lagringsprocessen för modellerna i administrationsverktyget.
Efter granskning och jämförelse av utdata från både tillhandahållen data och testning anses adekvat matematisk noggrannhet vara uppnådd.
4.3 Generaliserbarhet
Den lösning som tagits fram i detta examensarbete skulle teoretiskt sett kunna applice-ras på flera olika områden där matematiska modeller används. Så länge flera matematiska modeller kan uttryckas på samma form så kan samma princip som använts i prototypen för administrationsverktyget användas. Denna princip kan generellt sammanfattas som att skapa en miljö med en grundform av en modell, för att sedan lägga in nya instanser av modellen genom att ange värden eller uttryck för alla parametrar. På så sätt slipper an-vändaren anställa en programmerare som hårdkodar modeller och all information kommer istället lagras i en databas.
4.4 Förslag till framtida utveckling av webbverktyg
Utifrån den metod som använts för en parametriserad implementation av administrations-verktyget (se kapitel 3.1.4 och 4.2) har ett förslag till framtida utveckling av ett webbaserat administrationsverktyg tagits fram. Denna lösning bygger på en databasbaserad front-end-back-end-implementation, beskrivs i detta avsnitt och demonstreras visuellt i Figur 6.
Figur 6: Visuell demonstration av föreslagen webbimplementation av administrationsverk-tyg.
I front-end-delen av systemet skulle en administrationshemsida finnas där systemad-ministratörer kan logga in och antingen editera existerande modeller eller skapa nya. Ad-ministratören definierar parametrarna för en given modell genom att skriva in värdet eller uträkningen på webbsidan. Denna del av systemet skulle visuellt och funktionellt påmin-na mycket om den utvecklade prototypen (se kapitel 4.2). Den bakomliggande tekniken skulle dock antagligen haft väsentliga skillnader, eftersom den utvecklade prototypen är utvecklat ur ett objektorienterat synsätt i C#. Kommunikation med en databas skulle skett
från både front-end och back-end. De modellparametrar som skrivs in i form av strängar i webbsidan sparas till databasen, och läses sedan ut av back-end-delen som gör de egentliga uträkningarna.
I back-end-delen av systemet skulle data (temperatur, sparade uträknade värden och parameterdefinitioner) hämtats från databasen och sedan beräknats med hjälp av den pa-rametriserade grundform som tagits fram (se kapitel 4.1). Detta skulle genomförts med en bakgrundsapplikation på servern som utför beräkningarna av förskämningstiderna med hjälp av en string-math-evaluator (exempelvis NCalc, vilket är det som användes för pro-totypen) och sparar dem i databasen.
5
Diskussion
5.1 Arbetets styrkor
Något som har bidragit till att styrka arbetet är projektets startpunk: Att vi kunde få sammanställda matematiska definitioner för de olika modellerna utan att själva samman-ställa den informationen utifrån källartiklarna, vilket skulle krävt tidigare kunskaper inom mikrobiologi. Att dessutom ha haft kontakt med mikrobiologierna har gjort att vi vidare kunnat förtydliga oklarheter i tillhandahållen information.
I den framtagna prototyplösningen (se Avsnitt 3.2.2) ges användaren möjlighet att lägga till en ny modell bara genom att ange värden eller uttryck för de tre relevanta parameterarna. Utöver detta har användaren även möjlighet att skapa och ge värden till de konstanter som kan behövas i modellen. Denna modulära lösning kan jämföras med den i nuläget existerade lösningen för att beräkna förskämningstid (se Bilaga D), vilken är helt hårdkodad för varje specifik förskämningsmodell. När dessa två analyseras som lösningar för problemet (frågeställning 2 i Avsnitt 1.3) framgår att även om vår prototyp kräver att användaren använder extern programvara, blir det betydligt lättare att lägga in nya modeller. Ingen ny kod behöver läggas till, och ingen större matematisk kunskap behöver besittas av användaren.
Vidare innebär införandet av konstanten B (konstant för extratid till förskämning) att tillämpningen av parametriseringen blir framtidssäker. Om framtida livsmedel skulle använda en annan formel för att beräkna extratid till förskämning går det enkelt att ange ett annat uttryck för B.
5.2 Arbetets begränsningar
Vid arbetets start visste vi inte hur många modeller som skulle komma att vara tillgängliga för projektet eller hur dessa var formulerade. I början av projektet fick vi två modeller, en för skinka och en för torsk samt en hårdkodad lösning som fanns implementerad för skinka. Efter detta fick vi tillgång till en tredje modell, som beskrev förskämningen för ost. Först efter att vi tagit kontakt med mikrobiologerna och bett om fler modeller fick vi två till för skinka. Om vi hade fått tillgång till alla fem modellerna vid projektets start skulle det antagligen gått betydligt snabbare att komma till det resultat för en gemensam modellform. Detta skulle möjliggöra andra tillvägagångssätt såsom att betrakta alla fem modeller på en gång för att definiera deras gemensamma parametrar, något vi var tvungna att vänta med tills det fanns fler modeller tillgängliga.
Den största begränsningen av projektet gällande parametriseringen är det faktum att det inte fanns fler modeller tillgängliga. Även vid en lyckad parametrisering hade det varit väldigt användbart med fler förskämningsmodeller för att försöka parametrisera dessa vi-dare. Detta hade även varit användbart om parametrisering av ytterligare modeller skulle leda till en falsifiering av teorin.
Även bristande kunskaper kring mikrobiologi har varit något av en begränsning, detta då mycket av litteraturen kring problemet varit riktat åt mikrobiologer vilket försvårade förståelsen för problemet tidigt under projektets gång.
Ett annat faktum som har varit någorlunda begränsande har varit den bristande forsk-ning som finns i området. Detta har försvårat arbetet gällande att hitta en lämplig metod som visat sig lyckad i tidigare projekt.
Utöver detta har det även funnits modellspecifika begränsningar, dessa innefattar inom vilka temperaturintervall modellen fungerar. Olika livsmedels bakteritillväxt börjar vid olika temperaturer vilket försvårar skapandet av en enhetlig miljö som endast skapas med hjälp av användardefinierade funktioner och konstanter.
5.3 Problem
5.3.1 Användbarhet kontra effektivitet
Trots att funktionen för bakterietillväxt (µmax) kunde parametriseras och därmed ge ett
mer lyckat resultat gjordes ett medvetet val att inte använda detta i prototypen för ad-ministrationsverktyget. Detta då den typen av parametrisering skulle ställa större krav på användaren av programmet och försvåra användningen. Användaren skulle själv behöva förenkla formeln för µmaxför att få fram de konstanter som parametriserats fram i Avsnitt
3.1.2. Vi valde att istället använda den oparametriserade formen av µmax i verktyget så att användaren själv inte behöver förenkla funktionen matematiskt.
Utöver detta bidrar parametriseringen av µmax till fler problem vid implementationen,
vilket är att många av konstanterna försvinner vid förenklingen. Detta skapar inte problem i modellen då ingenting i funktionen har förändrats utan bara skrivits om, dessa konstanter kan dock bidra till ökad förståelse för andra som använder sig utav programmet om dem finns tillgängliga.
5.3.2 Otydligheter i tillhandahållen information
Vid flera tillfällen har det uppkommit otydligheter i de tillhandahållna modellerna. Mesta-dels felskrivningar, både matematiska och i konstantnamn. Detta har till viss del försvårat arbetet men då vi haft kontinuerlig kontakt med mikrobiologerna har de kunnat säkerställa informationen.
Något vi valt att bortse från för de modeller som det är aktuellt, är faktorn för tempe-raturjustering. I alla ursprungliga modeller för Skinka (se Bilaga E.3, E.4 och E.5) finns en faktor som används för att justera det temperaturvärde som ursprungligen uppmätts av sensorerna. Uttrycket för denna faktor var mycket långt men tycktes ändå inte alls påverka förskämningstiden vid de temperaturer som var uppmätta. Temperaturjusteringsfaktorns lilla inverkan på den slutliga förskämningstiden gjorde att faktorn togs bort i ett försök att förenkla de tillhandahållna modellerna och skala bort onödiga parametrar. Det finns självklart inget som förhindrar införning av denna faktor i framtiden, ifall detta skulle visa sig nödvändigt.
6
Slutsatser och vidare forskning
I resultatet visas att båda forskningsfrågorna i frågeställningen har kunna besvarats med ett för Dynahmat gynnsamt resultat. Det visade sig vara möjligt att parametrisera alla fem modellerna så att de kunde beskrivas med en enhetlig formel. Det var även möjligt att skapa ett administrationsverktyg som kan användas för att lägga till nya modeller utan några tidigare kunskapar inom programmering och med endast användardefinierade matematiska funktioner och konstanter. Det framgår även att arbetet varit lyckat om vi jämför den tidigare lösningen för att implementera en ny modell i systemet (se Bilaga D) med hur en ny modell skulle läggas in i systemet med det verktyg som utvecklats här (se Avsnitt 3.2.2) där det inte behövs tillkallas en programmerare utan allt kan ske genom en administratör.
Vidare skulle det vara intressant att se ytterligare forskning för att undersöka om samma metod skulle vara tillämpningsbar om det skulle finnas fler förskämningsmodeller tillgängliga, gärna med en större variation av livsmedel. En bredare variation kring beräk-ningen för µmax skulle även kunna göra det relevant att använda denna parametrisering i
administrationsverktyget.
Framtida forskning för administrationsverktyget skulle kunna innefatta huruvida det skulle vara möjligt att skapa ett verktyg på ett sådant sätt att användaren även kan lägga till allmänna modeller. Detta skulle göra verktyget användbart för en bredare användar-bas, där det inte bara är tillgängligt för förskämningsmodeller utan även parametriserade modeller inom andra industrisektorer.
Referenser
[1] Bertolino A. (2001), Guide to the Software Engineering
Bo-dy of Knowledge, 2004. SWEBOK, publisher: IEEE
Chap-ter 5 http://www.inforede.net/Technical/Business/IT/SWEBOK%20-%20Software%20Engineering.pdf#page=91
[2] Chard M S, Strode E D. A proposal for using design science in small-scale postgradu-ate research projects in information technology, Teaching, Assesment and Learning (TALE), 2014 International Conference on, 8-10, December; Wellington, New Zea-land
[3] Dalgaard P, Mejlholm O, Huss H. Application of an iterative approach for develop-ment of a microbial model predicting the shelf-life of packed fish, Int J Food Microbiol 1997, 19, September; 38:169-179
[4] Devlighere F, Belle B, Debevere J. Shelf life of modified atmosphere packed cooked meat products: a predictive model, Int J Food Microbiol 1991, 4, November; 46:57-70 [5] Dynahmat [Internet]. [Plats okänd]: Dynahmat; [Besökt 2015-03-16]. Tillgänglig från:
http://dynahmat.com/projektet/
[6] European Commission [Internet]. [Plats okänd]: European
Com-mission; 2013-06-19 [Besökt 2015-03-16]. Tillgänglig från:
http://ec.europa.eu/food/safety/food_waste/index_en.htm
[7] Garcia A, Rubira C, Romanovsky A, Xu J. A comparative study of exception hand-ling mechanisms for building dependable object-oriented software, The Journal of Systems and Software 2001, 07, Mars; 59: 197-222.
[8] Gram L, Ravn L, Rasch M, Bruhn J, Christensen A, Givskov M. Food spoilage -interactions between food spoilage bacteria, Int J Food Microbiol 2002, 26, Maj; 78:79-97
[9] Göransson M, Nilsson F. (2013), The role of biosensors in future food supply chain, NOFOMA conference, Gothenburg.
[10] Hevner A R, March S T, Park J. Design Science in Information System Research, MIS Quarterly, 2004, Mars; 28(1):75-105
[11] Jevinger Å, Göransson M, Båth K. A Field Test Study on Dynamic Shelf Life Service for Perishables. 2014
[12] Kothari C R. Research Methodology: Methods and Techniques. New Age Internatio-nal; 2004.
[13] Kreyenschmidt J, Hübner A, Beierle E, Chonsch L, Scherer A, Petersen B. Deter-mination of the shelf life of sliced cooked ham based on the growth of lactic acid bacteria in different steps of the chain, Journal of Applied Microbiology 2009, June, 10, 108:510-520
[14] Mataragas M, Drosinos E H, Vaidanis A, Metaxopoulos I. Development of a Pre-dictive Model for spoilage of Cooked Cured Meat Products and Its Validation Under Constant and Dynamic Temperature Storage Conditions, Journal of Food Science 2006; 71(6): 157-167
[15] Math.kau.se [Internet]. Karlstads Universitet; [Besökt 2015-03-27]. Tillgänglig från: http://www.math.kau.se/niclbern/B1/fo13.pdf
[16] NCalc [Internet]. [Plats okänd]: NCalc; [Besökt 2015-04-05]. Tillgänglig från: https://ncalc.codeplex.com/
[17] Oxford Dictionaries [Internet]. [Plats okänd]:
Ox-ford Dictionaries; [Besökt 2015-03-27]. Tillgänglig från:
http://www.oxforddictionaries.com/definition/english/parameterize
[18] Peffers K, Tuunanen T, Rothenberger A M, Chatterjee S. A Design Science research methodology for information systems research, Journal of Management Information Systems / Winter 2007–8, Vol. 24, No. 3, pp. 45–77.
[19] Sneed H M. (2010), Testing object-oriented software systems, Proceedings of the 1st Workshop on Testing Object-Oriented Systems, Vienna, Austria
[20] Østergaard N, Eklöw A, Dalgaard P. Modelling the effect of lactic acid bacteria from starter- and armoa culture on growth of Listeria monocytogenes in cottage cheese, Int J Food Microbiol 2014, 21, Juli; 188:15-25
A
Sökhistorik för litteraturstudie
IEEE:
Metadata Only, 1990 - 2015, Conference Publications, Journals & Magazines Parameter
Parameter + Model
Parameter + Model + Predict
Parameter + Model + Predict + Shelf Life Predict
Predict + Shelf Life
Google Scholar: Ingen filtrering Parameters
Parameters + Introduction
Parameters + Introduction + Models
Parameters + Introduction + Models + Mathematical Parameterization
Parameterization + Models
Parameterization + Models + Mathematical Food spoilage
Food spoilage + Prediction
B
Matematisk redogörelse
B.1 Kvadratiska funktioner µmax för Torsk = (0.29 + 0.032T − (1.6 · 10−3) · C − (9 · 10−5) · T · C + (9 · 10−6) · C2)2 = (0.29 + 0.032T − (1.6 · 10−3) · 50 − (9 · 10−5) · T · 50 + (9 · 10−6) · 502)2 = (0.29 + 0.032T − 0.08 − 0.0045T + 0.0225)2 = (0.032T + +0.2325 − 0.0045T )2= (0.0275T + 0.2325)2= 0.000756T2+ 0.01279T + 0.054 µmax för Keso = µref · ((T(T −Tmin) ref−T min))2· (1 − 10(pHmin−pH)) ·(aw−awmin)
(1−awmin) = 0.73 · ((T −(−2.01))(25−(−2.01))2· (1 − 10(4.87−5)) ·(0.99−0.928) (1−0.928) = 0.73 · ((T +2.01)27.01 )2· 0.2387 ·0.0620.072 = 0.73 · (T +2.01)27.012 2 · 0.2387 · 0.86 = 0.162425·(T +2.01)2 729.59 = 0.000223 · (T + 2.01)2= 0.000223 · (T2+ 4.02T + 4.04) = 0.000223T2+ 0.0009T + 0.0009
µmax för Skinka (Devlieghere) =
b(aw− amin) · (CO2max− CO2) · (T − Tmin)2 =
2.5 · 10−6(0.97 − 0.956) · (6.1 · 103− 0.9) · (T − 9)2=
2.5 · 10−6· 0.014 · 6099.1 · (T − 9)2 =
0.0002134685(T − 9)2=
0.0002134685T2− 0.00384T + 0.01729
Här visas att de funktioner som ökar kvadratiskt kan beskrivas med formeln K1T2+ K2T + K3
B.2 Exponentiella funktioner
µmax för Skinka (Kreyenschmidt) =
e42.9−13322.9·T1 =
e42.9+−13322.9T
µmax för Skinka (Mataragas) =
e46.6162+0.009314T−109.911 =
e46.6+−11800.6T
Här visas att båda funktioner kan beskrivas på samma form: eK1+K2T
C
Kod för implementerad mjukvara
C.1 Append
p u b l i c v o i d Append ( s t r i n g math , s t r i n g nCalc ) {
t h i s . S e l e c t e d P a r a m e t e r N C a l c += nCalc ; t h i s . S e l e c t e d P a r a m e t e r M a t h += math ; }
Listing 1: Metod för att lägga till information i en parameter. Denna information kan antingen bestå av numeriska värden eller matematiska operationer.
C.2 NCalcExpression p u b l i c s t r i n g N C a l c E x p r e s s i o n { g e t { r e t u r n " ( ( Log ( 1 0 , 2 . 7 2 ) ∗ ( " + NMaxNCalc + "−" + Nx + ")+" + BNCalc + " ) ) / " + MuMaxNCalc ; } }
Listing 2: Retunerar NCalc-versionen av modellens uttryck genom att bygga en sträng av alla parametrars NCalc-version på den gemensamt parametriserade formen.
C.3 MathExpression p u b l i c s t r i n g MathExpression { g e t { r e t u r n " ( ( Ln ( 1 0 ) ∗ ( " + NMaxMath + "−" + Nx + " ))+ " + BMath + " ) / " + MuMaxMath ; } }
Listing 3: Retunerar den allmänna matematiska versionen av modellens uttryck genom att bygga en sträng av alla parametrars matematiska version på den gemensamt parametrise-rade formen.
C.4 Evaluate p u b l i c s t r i n g E v a l u a t e ( ) { i f ( N C a l c E x p r e s s i o n != " " ) { E x p r e s s i o n a = new E x p r e s s i o n ( N C a l c E x p r e s s i o n ) ; t r y { r e t u r n a . E v a l u a t e ( ) . T o S t r i n g ( ) ; } c a t c h ( E x c e p t i o n ex ) { r e t u r n ex . Message ; } } e l s e { r e t u r n " N o C a l c u l a t i o n E n t e r e d " ; } }
Listing 4: Metod som evaluerar (försöker beräkna) NCalc-versionen av det fullständiga modelluttrycker och retunerar det beräknade värdet.
