IT 18 070
Examensarbete 15 hp
Januari 2019
Resursoptimering för restauranger
Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student
Abstract
Resursoptimering för restauranger
Göran AhlgrenAn optimization of reservation systems for tables in the restaurant industry. The optimization is aimed at maximizing the number of guests as well as placing guests at the optimal tables based on the prevailing conditions.
Contents
1 Introduktion 4
1.1 M˚al . . . 4
1.2 Praktiska begr¨ansningar och krav . . . 5
1.2.1 Bord . . . 5
1.2.2 Prioriteter . . . 5
1.2.3 Snabb information . . . 5
1.2.4 Tidsaspekten . . . 6
1.2.5 M¨ojlighet att l˚asa bord . . . 6
1.3 Arbetets begr¨ansningar . . . 6
2 Minneshantering 6 2.1 Bord som objekt . . . 6
2.2 Bordstabell . . . 7
2.3 IDK-schema . . . 7
3 Tidsaspekten 7 3.1 Block och tidsblock . . . 7
3.2 Tidpunkter . . . 8
4 Mer detaljer om bord och restauranger 8 4.1 Olika bord och deras egenskaper . . . 10
4.1.1 Fasta bord . . . 10 4.1.2 R¨orliga bord . . . 10 4.1.3 N¨arliggande bord . . . 10 4.1.4 Extra stolar . . . 10 5 Metod 11 5.1 F¨ortydligande av IDK . . . 11
5.2 L¨agga grunden med IDK:er . . . 12
5.3 Restaurang¨agarens prioritet . . . 14
5.4 IDK-data . . . 16
6 Struktur 17 6.1 Alternativ 1 . . . 17
6.1.1 Datastruktur alternativ 1 . . . 17
6.1.4 Reservera via telefon eller restaurangens hemsida . . . 22
6.1.5 Avboka eller l¨amnar . . . 24
6.1.6 G¨aster anl¨ander . . . 27
6.2 Alternativ 2 . . . 29
6.2.1 Datastruktur . . . 29
6.2.2 Reservera via telefon eller restaurangens hemsida . . . 30
6.2.3 Avboka eller l¨amnar . . . 32
6.2.4 G¨aster anl¨ander . . . 33
7 S¨oka 35 7.1 Hur g˚ar en s¨okning till . . . 35
7.2 Ut¨okad s¨okning - tidsm¨assigt . . . 36
7.3 Ut¨okad s¨okning parallellt med fler antal g¨aster . . . 37
7.4 Brist i s¨oksystemet . . . 37
7.5 L¨osningsf¨orslag p˚a brist i s¨ok . . . 38
8 Optimera IDK-schema 39 8.1 Optimeringsalternativ 1 - Tidigaste tiden och st¨orsta blocket . 39 8.1.1 Brist i alternativ 1 . . . 40
8.2 Optimeringsalternativ 2 - Tidigaste tiden och st¨orsta sam-manh¨angande blocket . . . 41
8.2.1 Brist i alternativ 2 . . . 42
8.3 Optimeringsalternativ 3 - Optimera inom ett tidsintervall och flest anv¨anda tidpunkter f˚ar h¨ogsta prioritet . . . 43
8.4 L˚asta block . . . 44
9 Placera g¨aster 45 10 G¨aster l¨amnar. Optimering n¨ar block f¨orsvinner 47 11 Skapa egna tillf¨alliga IDK:er 47 12 Resultat 49 12.1 Sammanfattning tidskomplexitet . . . 49
12.2 Sammanfattning minnesanv¨andning . . . 51
12.3 Alternativ 1 f¨ortydligande . . . 51
12.3.1 Algoritm 1 Telefon/Webb reservation . . . 51
12.3.2 Algoritm 2 Avboka eller l¨amna . . . 52
12.4 Alternativ 2 f¨ortydligande . . . 53
12.4.1 Algoritm 4 Telefon/Webb reservation . . . 53
12.4.2 Algoritm 5 Avboka eller l¨amna . . . 53
12.4.3 Algoritm 6 G¨aster anl¨ander . . . 53
12.5 Optimeringsalternativ f¨ortydligande . . . 54 12.5.1 Optimeringsalternativ 1 . . . 54 12.5.2 Optimeringsalternativ 2 . . . 54 12.5.3 Optimeringsalternativ 3 . . . 54 13 Relaterat arbete 55 14 Diskussion 55 15 Framtida arbete 56
1
Introduktion
De absolut flesta restaurang¨agare vill g¨ora vinst. Detta ¨ar ett ganska sj¨alvklart p˚ast˚aende d˚a det ¨ar vad som kr¨avs f¨or att en restaurang ska kunna forts¨atta sin verksamhet. F¨or att kunna maximera sina vinster m˚aste man str¨ava efter att maximera sina resurser. Denna rapport fokuserar p˚a att maximera resursen bord och de sittplatser borden medf¨or.
Denna resursoptimering kan utformas ur flera olika vinklar. Den mest uppenbara ¨ar att s˚a m˚anga g¨aster som m¨ojligt ska f˚a plats i restaurangen. Detta ¨ar tydligt sammankopplat med str¨avan efter att s˚a effektivt som m¨ojligt placera ”r¨att” antal g¨aster vid borden f¨or att p˚a s˚a s¨att slippa svinn med platser som blir oanv¨anda. Detta involverar ocks˚a m¨ojligheten att flytta ihop och s¨ara p˚a bord f¨or att kunna ta in st¨orre s¨allskap. Dessa kombina-tioner m˚aste h˚allas s˚a flexibla som m¨ojligt f¨or att kunna hantera avbokningar, of¨oruts¨agbara h¨andelser och walk-in bokningar d˚a g¨aster anl¨ander till restau-rangen utan att ha bokat i f¨orv¨ag.
En annan vinkel ¨ar att olika bord ¨ar olika attraktiva utifr˚an dess placering. Ett bord placerat vid ett stort f¨onster med vacker havsutsikt har st¨orre v¨arde ¨
an ett bord placerat l¨angst in i ett m¨orkt h¨orn. Det b¨attre bordet kommer att generera n¨ojdare kunder vilket ger en positiv bild av restaurangen.
Ytterligare en vinkel ¨ar att restaurang¨agaren har ¨onskem˚al om vilka platser som g¨aster ska placeras vid f¨orst. Detta kan exempelvis vara de bord som st˚ar vid f¨onster som ligger mot gatan. Att f¨orst fylla dessa bord ger m¨anniskor som g˚ar f¨orbi en k¨ansla av att denna restaurang ¨ar fullsatt och m˚aste d¨armed vara bra.
Alla dessa synpunkter pekar mot att det inte ¨ar mest resurseffektiv att bara fylla p˚a med s˚a m˚anga g¨aster som m¨ojligt. Det finns m˚anga fler aspekter att ta h¨ansyn till.
1.1
M˚
al
M˚alet med detta arbete ¨ar att konstruera en datastruktur, ett fl¨odesschema och en algoritm f¨or att resursoptimera bordshanteringen i en generellt upp-byggd restaurang. Resursoptimeringen ska ha som syfte att de ¨onskade bor-den alltid ska vara anv¨anda samtidigt som restaurangen inte ska beh¨ova ha oanv¨anda sittplatser. Om systemet lyckas kommer en restaurang alltid vara s˚a pass fullsatt att k¨oket och servit¨orerna hinner med samt g¨asterna blir n¨ojda med bes¨oket. I de fall d¨ar systemet inte fungerar skulle det resultera
i att g¨aster blir placerade vid restaurangens s¨amre bord eller att det blir ett on¨odigt svinn av sittplatser n¨ar sm˚a s¨allskap blir placerade vid stora bord.
1.2
Praktiska begr¨
ansningar och krav
Varje restaurang ¨ar uppbyggd p˚a olika s¨att. ¨Aven restaurang¨agare har olika krav och ¨onskningar p˚a hur deras g¨aster ska bem¨otas och placeras. Detta leder till n˚agra generella praktiska begr¨ansningar som programmet m˚aste kunna hantera.
1.2.1 Bord
I praktiken ¨ar bord mycket mer komplexa ¨an bara antal sittplatser. Borden som ska hanteras i programmet kommer att ha v¨aldigt olika egenskaper. N˚agra bord ¨ar fasta och kan d¨armed inte flyttas. Andra ¨ar r¨orliga och kan d¨armed placeras bredvid andra bord f¨or att p˚a det s¨attet bygga ett st¨orre bord. Bord kan vara runda, avl˚anga, fyrkantiga, L-formade med mera. Antal platser och beskaffenhet varierar. Lokalens utformning begr¨ansas av hur man kan flytta bord och om man kan ha m¨ojlighet att placera g¨aster vid n¨arliggande bord eller st¨alla dit extra stolar. Allt detta skapar begr¨ansningar men ocks˚a m¨ojligheter.
1.2.2 Prioriteter
Det finns en stor variation p˚a vad en restaurang¨agare kallar f¨or ett bra bord. Detta varierar ocks˚a utifr˚an vad ¨agaren vill ˚astadkomma med varje placer-ing. ¨Agaren kan se p˚a ett bra bord ur g¨asternas perspektiv, restaurangens anseende eller servit¨orernas effektivitet och arbetsmilj¨o. ¨Agarens kunskap, erfarenhet och prioriteter m˚aste tas h¨ansyntill och hanteras p˚a ett bra s¨att. 1.2.3 Snabb information
N¨ar g¨aster st˚ar i restaurangen och undrar om det finns lediga bord ¨ar det viktigt att serveringspersonalen kan ge ett snabbt svar. Att l˚ata hungriga potentiella g¨aster v¨anta ¨ar inte ¨onskv¨art. Detta leder till att systemet m˚aste kunna leverera den ¨onskade informationen inom en godtagbar tid.
1.2.4 Tidsaspekten
Alla sittningar tar olika l˚ang tid och restauranger hanterar detta p˚a olika s¨att. D¨armed m˚aste programmet ha m¨ojlighet att f¨ors¨oka f¨orutse n¨ar borden ¨
ar upptagna och n¨ar de kommer att vara lediga f¨or nya g¨aster. Hur den tidsramen ser ut ska restaurang¨agaren ha m¨ojlighet att sj¨alva best¨amma. 1.2.5 M¨ojlighet att l˚asa bord
Vid vissa tillf¨allen har g¨aster speciella ¨onskningar. Detta kan vara ¨onskan om att f˚a bord vid f¨onster, ha blommor placerade vid bordet vid ankomst eller av sentimentala sk¨al sitta vid ett specifikt bord. Av denna anledning m˚aste anst¨allda kunna g˚a f¨orbi systemet och l˚asa vissa bord till ett speciellt s¨allskap.
1.3
Arbetets begr¨
ansningar
Detta arbete kommer inte att ha tillg˚ang till n˚agon befintlig kod eller pro-gramvara. D¨armed kommer inte heller detta arbete ha som m˚al att imple-mentera n˚agon del av programmet. Att skriva kod kommer inte att utf¨oras. Resursoptimeringens struktur och fl¨ode ¨ar vad arbetet framf¨orallt kommer att handla om.
Hur de olika kombinationerna och de olika prioriteringarna kommer ska-pas ¨ar inget denna rapport kommer att hantera. Denna rapport f¨oruts¨atter att de ¨onskade kombinationerna och deras prioriterer redan ¨ar implementer-ade. Regler f¨or hur det f¨orslagsvis ska g˚a tillv¨aga kommer d¨arimot att kunna diskuteras.
Gr¨ansnitt och hur resultaten ska presenteras ¨ar inte vad rapporten kom-mer att ha i fokus.
2
Minneshantering
2.1
Bord som objekt
Varje bord hanteras som ett separat objekt. Vilka attribut detta objekt kommer att inneh˚alla kan variera utifr˚an anv¨andarens ¨onskem˚al. Men det kan vara exempelvis antal sittplatser, bordets form och storlek.
Borden kommer att ing˚a i olika kombinationer. Varje kombination kom-mer att ha ett eget identitetsnumkom-mer (IDK). Dessa IDK:er komkom-mer ¨aven att ha sin egen prioritets grad. Det som varje bordsobjekt m˚aste inneh˚alla ¨ar en samling med information om vilka IDK:er detta bord ing˚ar i. Denna samling kommer att ben¨amnas som MyIDK och ¨ar unik f¨or varje bordsobjekt. Denna m˚aste finnas d˚a det ¨ar viktigt att veta vilka IDK:er som blir oanv¨andbara n¨ar detta bord blir anv¨ant. Detta f¨or att undvika dubbelbokning.
2.2
Bordstabell
Varje anv¨and tidpunkt kr¨aver en bordstabell. En bordstabell ¨ar en samling med bool element som representerar varje bords status i denna tidspunkt. Detta f¨or att systemet ska kunna veta vilka bord som ¨ar anv¨anda eller lediga.
2.3
IDK-schema
IDK-schema ¨ar till f¨or att hantera de olika IDK:ernas status. Ar IDK¨ L˚ast/Anv¨and, reserverad eller oanv¨andbar. Detta ¨ar en viktig del i att hitta lediga IDK:er, optimera vilka IDK:er som ska anv¨andas och placera g¨aster vid de h¨ogst prioriterade IDK. Detta ¨ar ¨aven ett s¨att att visualisera restaurangens olika IDK:er och hur de f¨or tillf¨allet anv¨ands. Dessa scheman hanterar IDK:erna utifr˚an hur m˚anga sittplatser de kan generera. Det finns d¨armed lika m˚anga IDK-scheman som antalet sittplatser den st¨orsta IDK kan genererar.
3
Tidsaspekten
Restauranger har ¨oppet olika tider och olika l¨ange. ¨Aven restaurangens g¨aster ¨
ater olika l¨ange och har olika ¨onskningar om n¨ar de ska ¨ata. Det kan h¨anda att g¨aster l¨amnar sitt bord tidigare ¨an planerat men ¨aven att de sitter kvar l¨angre ¨an ¨onskat.
3.1
Block och tidsblock
I restaurangbranschen pratar man om sittningar eller sittningsl¨angd som tidsenheter f¨or hur l¨ange ett s¨allskap kommer att sitta vid bordet[1, 2, 3, 4]. Uttrycken kan innefatta ett eller flera s¨allskap. Dessa utryck har inte heller
n˚agon best¨amd l¨angd och varierar b˚ade inom en specifik restaurang men ¨annu tydligare mellan olika restauranger. En sittning vid lunchtid kan ber¨aknas ta en timme medans det senare p˚a kv¨allen kan ber¨aknas till tv˚a eller kanske till och med tre timmar. D˚a det inte finns n˚agon standardiserat begrepp kommer denna rapport i forts¨attningen tala om tidsblock. Om inget annat skrivs kommer tidsblocket innefatta tv˚a timmar. Rapporten tar ¨aven upp begreppet block. Om inget annat skrivs kommer ett block innefatta en IDK. Detta block ¨ar placerat eller kommer f¨ors¨oka placeras in i IDK-schemat.
3.2
Tidpunkter
F¨or att kunna hantera restaurangernas reservationer delar systemet upp ¨
oppettiderna i flera tidpunkter. Dessa tidpunkter ¨ar f¨orslagsvis med en kvarts mellanrum men kan variera utifr˚an restaurang¨agarens ¨onskningar. N¨ar tid-punkt skrivs i denna rapport menas en specifik tid utan n˚agot tidsintervall. Med anv¨and tidpunkt menas att det ska finnas minst ett bord denna tidpunkt som inte ¨ar ledigt.
4
Mer detaljer om bord och restauranger
Diskussionen ang˚aende problem och l¨osningar kommer att utg˚a fr˚an en fiktiv restaurang. Denna restaurang ¨ar uppbyggd med flera rum och bord som alla har olika f¨oruts¨attningar. Detta f¨or att kunna visa de olika problem som kan uppst˚a och hur de kan l¨osas eller m˚aste f¨orbises.
Figure 1: Karta ¨over fiktiv restaurang
Borden ¨ar bokstaverade fr˚an A-Z och kommer i forts¨attningen ben¨amnas med respektive bokstav.
4.1
Olika bord och deras egenskaper
Systemet m˚aste k¨anna till de praktiska egenskaper borden har f¨or att kunna bygga en modell som fungerar i praktiken.
4.1.1 Fasta bord
Fasta bord ¨ar bord som av en eller annan anledning inte g˚ar att flytta p˚a. Fasta bord inefattar ocks˚a bord som inte p˚a ett naturligt s¨att g˚ar att kom-binera med andra bord med syfte att skapa ett st¨orre bord. Borden A och B ¨
ar exempel p˚a fasta bord som inte g˚ar att flytta. De runda borden E, L, M, N och U ¨ar bord som visserligen g˚ar att flytta men p˚a grund av deras form eller placering inte p˚a ett naturligt s¨att g˚ar att bygga ihop till st¨orre bord. 4.1.2 R¨orliga bord
R¨orliga bord ¨ar de bord som g˚ar att flytta ihop f¨or att p˚a det s¨attet bygga ett st¨orre bord. De flesta borden i restaurangen ¨ar av denna sortens bord. Exempelvis borden F, G, H g˚ar alla att flytta ihop och d¨armed i st¨allet f¨or tre stycken 2 bord s˚a har man byggt ett 6 bord. (Se figur punkt 5.1) ¨Aven bordet K r¨aknas som r¨orligt d˚a man kan exempelvis flytta bord J och p˚a detta s¨att skapa ett 8 bord. Begr¨ansningarna f¨or dessa bord ¨ar fr¨amst restaurangens storlek och att andra bord kan st˚a i v¨agen.
4.1.3 N¨arliggande bord
Bord som inte p˚a ett naturligt s¨att g˚ar att flytta ihop men som ¨and˚a st˚ar n¨ara varandra kallas f¨or n¨arliggande bord. Exempel p˚a dessa bord ¨ar L, M och N. Deras runda form till˚ater inte att de flyttas ihop men kan ¨and˚a till˚ata ett s¨allskap att kommunicera mellan borden d˚a deras placering ¨ar tillr¨ackligt n¨ara. Vad som r¨aknas som n¨ara ¨ar upp till varje restaurang att avg¨ora. Teoretiskt skulle bord A och T kunna r¨aknas som n¨arliggande ¨aven om det inte ¨ar ¨onskv¨art.
4.1.4 Extra stolar
Bord ¨ar byggda f¨or ett specifikt antal stolar. Men man skulle kunna placera dit en eller flera extra stolar och p˚a detta s¨att skapa fler sittplatser. Vilka bord detta skulle kunna innefatta ¨ar upp till varje restaurang att avg¨ora.
Exempel p˚a dessa bord skulle kunna vara E, K och S. E:s runda form skulle eventuellt kunna inhysa en stol till med resultat att s¨allskapet skulle f˚a sitta lite tr¨angre. K och S skulle kunna till˚ata att placera en stol p˚a respektive kortsida och p˚a detta s¨atta kunna inhysa en g¨ast till ¨aven om det inte skulle vara optimalt med plats.
5
Metod
Stora restauranger med 100 tals bord skapar en stor m¨angd m¨ojliga bord-skombinationer. Alla dessa kombinationer m˚aste i realtid kunna sorteras och presenteras utifr˚an ¨onskat antal g¨aster som ska placeras. De olika ¨onskningarna p˚a vilka bord som ¨ar h¨ogst prioriterade och bordskombinationer som ¨ar m¨ojliga men inte ¨onskv¨arda ¨ar unika f¨or varje restaurang. Dessa begr¨ansningar ledde till beslutet att p˚a f¨orhand r¨akna ut dessa kombinationer och deras pri-oritet.
5.1
F¨
ortydligande av IDK
Varje IDK har sitt eget nummer och sin egen prioritet i sin grupp. Dessa IDK:ers grupptillh¨orighet blir best¨amd utifr˚an antalet sittplatser de kan generera. I denna rapport visas detta antal med en siffra framf¨or f¨orkortningen IDK. Om ingen siffra finns framf¨or eller om ett X finns i st¨allet ¨ar det en generell IDK som hanteras.
Borden E, F och G kan bilda IDK:erna: Tv˚a sittplatser
Fyra sittplatser
4 IDK[F, G] 4 IDK[G, H]
Sex sittplatser
6 IDK[F, G, H]
Notera att Borden F och H inte g˚ar att kombinera ¨aven fast b˚ada ¨ar r¨orliga. Detta f¨or att bord G ¨ar i v¨agen och g¨or det d˚a praktiskt om¨ojligt att flytta ihop dessa. D¨arf¨or ¨ar 4 IDK[F, H] inte ett m¨ojlig alternativ.
5.2
L¨
agga grunden med IDK:er
Dessa grovsorterade IDK:er blir numrerade utifr˚an vissa regler som har syfte att skapa ett prioritets system med m˚al att vara s˚a flexibelt som m¨ojligt. Dessa prioriteringsregler ¨ar etablerade p˚a varje grovsorterade grupp. Bor-den med 2 IDK(1) har prioritet 1 som ¨ar h¨ogsta prioritet i gruppen med 2 sittplatser. Borden med 4 IDK(1) har h¨ogsta prioritet i gruppen med 4 sittplatser. Vill ett s¨allskap best˚aende av 2 personer reservera bord kommer 2 IDK(1) att f¨orst och fr¨amst f¨ors¨oka v¨aljas. ¨Ar 2 IDK(1) inte tillg¨anglig s˚a blir 2 IDK(2) n¨asta f¨ors¨ok. Sedan 2 IDK(3) osv. Samma princip g¨aller s¨allskap best˚aende av 4 personer. F¨orsta hands valet ¨ar 4 IDK(1). Sedan 4 IDK(2) osv.
1. Fasta bord har h¨ogre prioritet ¨an r¨orliga bord och blir d¨armed valda f¨orst. Detta f¨or att bibeh˚alla flexibilitet.
2. S˚a f˚a bord som m¨ojligt i kombinationen med s˚a stort antal sittplatser som m¨ojligt vid ett bord.
Borden I, J och K kan bilda IDK:erna Tv˚a sittplatser 2 IDK(1)[J] Fyra sittplatser 4 IDK(1)[I] Sex sittplatser 6 IDK(1)[K] 6 IDK(2)[I, J]
˚
Atta sittplatser
8 IDK(1)[K,J]
L¨agg h¨ar m¨arke till att i IDK f¨or sex sittplatser har kombinationen [K] h¨ogre prioritet ¨an kombinationen [I, J]. Detta f¨or att regel 2 s¨ager att s˚a f˚a bord som m¨ojlig ska ing˚a i kombinationen. Detta f¨or att vara s˚a flexibla som m¨ojligt. Hade kombinationen [I, J] valts hade endast ett bord med sex sittplatser varit ledigt. Detta inneb¨ar i sin tur att om ett s¨allskap p˚a 4 personer kommer in i restaurangen s˚a m˚aste antingen hovm¨astaren meddela att det inte finns bord ledigt eller placera g¨asterna vid sex sittplatsers bordet med resultat att tv˚a sittplatser blir oanv¨andbara.
5.3
Restaurang¨
agarens prioritet
Under punkt 5.2 l¨aggs grunden f¨or hur IDK:ernas prioritet ska best¨ammas. Detta ¨ar den prioriteringsordning som ¨ar f¨or att maximera flexibilitet och d¨armed ¨aven antalet g¨aster. Men restaurang¨agare kan ha egna ¨onskem˚al om var g¨asterna ska placeras. Denna prioritet skiljer sig markant ˚at mellan restauranger och det g˚ar d¨armed inte att skapa n˚agra generella regler utan f˚ar beaktas i varje separat fall.
Borden A, O och P kan bilda IDK:erna: Tv˚a sittplatser
Tre sittplatser 3 IDK(1)[P] Fyra sittplatser 4 IDK(1)[P] 4 IDK(2)[A] Fem sittplatser 5 IDK(1)[O, P] Sex sittplatser 6 IDK(1)[O, P]
H¨ar ¨ar v¨art att notera att tv˚a regler bryts i detta exempel.
• Det r¨orliga bordet P prioriteras h¨ogre ¨an det fasta bordet A. P ing˚ar i andra kombinationer och borde d¨armed h˚allas ledigt f¨or m¨ojligheten att placera st¨orre s¨allskap.
• Kombinationerna [P] och [O, P] ¨ar placerade i flera IDK grupper. [P] genererar 4 sittplatser men ¨ar placerad i b˚ade f¨or gruppen 3 och 4 sittplatser. [O, P] genererar sex sittplatser men ¨ar placerad i grupperna f¨or 5 och 6 sittplatser.
I detta fall har ¨agaren valt att prioritera att g¨asters sitter vid bord P. Bord P har f¨onsterplats som ¨ar mot promenadgatan. Viljan att alltid ha bord P anv¨and har lett till beslutet att vara bered att offra flexibilitet och sittplatser.
5.4
IDK-data
Alla IDK:er och all information om dessa IDK:er kommer att refereras till som IDK-data. Det ¨ar i IDK-data som all information om varje IDK finns. Antal sittplatser, vilken prioritet och det viktigaste vilka bord som ing˚ar samt referenser till dessa bord.
Nedanf¨or ¨ar en bild p˚a hur IDK-data f¨or borden A, B, F, G, H, I, J och K skulle kunna se ut. Bokst¨averna inom hakparenteserna ¨ar referenser till respektive bordsobjekt.
2 Sittplatser 4 Sittplatser 6 Sittplatser 8 Sittplatser 2 IDK(1)[J] 4 IDK(1)[B] 6 IDK(1)[K] 8 IDK(1)[K, J] 2 IDK(2)[F] 4 IDK(2)[A] 6 IDK(2)[I, J]
2 IDK(3)[G] 4 IDK(3)[I] 6 IDK(3)[F, G, H] 2 IDK(4)[H] 4 IDK(4)[F, G]
4 IDK(5)[G, H]
6
Struktur
Borden ¨ar k¨arnan i bokningssystemet och de struktureras upp i IDK:er. Men f¨or att ha ett fungerande system m˚aste ¨aven IDK:er kunna hanteras p˚a ett ef-fektivt s¨att. I punkterna 6.1 och 6.2 ges tv˚a f¨orslag p˚a hur dessa ska hanteras. B˚ada med sina f¨or och nackdelar. Dessa tv˚a alternativ ¨ar uppbyggda f¨or att l¨osa samma uppgift men p˚a olika s¨att. Alternativ 1 har f¨ordelen att det ¨ar snabbare ¨an alternativ 2. Medans alternativ 2 har f¨ordelen att ha mindre minneskrav ¨an alternativ 1. Vilket alternativ som borde anv¨andas beror p˚a situation och anv¨andarens krav och ¨onskem˚al.
6.1
Alternativ 1
Detta f¨orslag utg˚ar fr˚an att det ska vara s˚a snabbt som m¨ojligt att hitta lediga IDK:er. Detta med nackdelen att m¨angden data kan bli stor och d¨armed en begr¨ansning.
6.1.1 Datastruktur alternativ 1
Varje anv¨and tidpunkt kommer att inneh˚alla ett IDK-referenstr¨ad (IDK-RT) som inneh˚aller referenser till IDK-data. Varje anv¨and tidpunkt ska ocks˚a inneh˚alla en bordstabell.
6.1.2 IDK-referenstr¨ad
Varje IDK m˚aste ha ett s¨att att meddela n¨ar de ¨ar lediga och n¨ar de ¨ar up-ptagna. ¨Aven IDK:er som inte ¨ar lediga men som ¨and˚a inte ¨ar tillg¨angliga m˚aste ocks˚a meddela detta. Detta l¨oses genom att sortera IDK:erna i olika grupper utifr˚an deras status. Dessa grupper organiseras i bin¨aras¨oktr¨ad. F¨or att s¨okningarna ska vara s˚a snabba som m¨ojligt m˚aste tr¨aden vara v¨alballanserade och d¨arf¨or b¨or ett ”R¨od-svart tr¨ad” tillv¨agag˚angss¨att anv¨andas[5, 6]. Det kr¨avs fyra referenstr¨ad.
• Anv¨anda IDK:er (AnvT). Detta ¨ar IDK:er d¨ar g¨aster redan sitter vid bordet eller ¨ar l˚ast av n˚agon annan anledning. Det kan vara att g¨aster har specifikt ¨onskat detta bord och hovm¨astaren har d¨armed l˚ast denna IDK till det s¨allskapet.
• Oanv¨andabara IDK:er (OanT). Detta ¨ar de IDK:er som har ett eller flera av borden i en annan IDK som ¨ar placerad i AnvT eller ResT. Detta betyder att denna IDK inte g˚ar att anv¨anda d˚a inte alla bord g˚ar att anv¨anda. Det skulle leda till dubbelbokning.
• Lediga IDK:er (LedT). Detta ¨ar IDK:er som g˚ar att anv¨anda. Dvs de ¨
ar inte placerade i n˚agot av de andra tr¨aden.
IDK:er kommer sedan att flyttas mellan tr¨aden utifr˚an hur deras status ¨
andras. Att en IDK flyttas startar sedan en kedjereaktion som i sin tur kan leda till att flera IDK:er blir flyttade.
Varje Node i dessa tr¨ad inneh˚aller en referens till IDK-data f¨or denna specifika IDK, prioritets nummer f¨or den specifika IDK:n och referens till n¨astkommande noder, dvs Node Left och Node right. Detta inneb¨ar att minnes˚atg˚angen f¨or varje Node kommer att se ut p˚a f¨oljande s¨att. Prioritet som representeras av en int, en referens till IDK-data, en referens till Node Left och en referens till Node Right.
Integers har storlek 4 byte [7] och referenser har storlek 4 byte [7]. Dessa tre referenser och en int ger att varje Node har storlek 16 byte. Detta ger i sin tur att varje anv¨and tidpunkt kommer ha ett IDK-referenstr¨ad med storleken 16 byte * antalet IDK:er.
6.1.3 Visualisera hur IDK-RT och prioriteter fungerar Tidsblocket nedan har starttid 1 november 2018 klockan 18:00
2018-11-01
18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 Ett tidsblock
Detta tidsblock innefattar tidpunkter som i sin tur inneh˚aller IDK-RT om det ¨ar anv¨anda tidpunkter. I bilden nedanf¨or ¨ar det IDK:er med 6 sittplatser som ¨ar aktuellt. LedT och de prioriteter respektive tr¨ad inneh˚aller visas.
2018-11-01 6 IDK-RT
LedT LedT LedT LedT LedT LedT LedT LedT
18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 2 4 5 6 6 6 7 8 3 5 6 7 7 7 8 9 4 6 7 8 8 8 9 10 5 7 8 9 9 9 10 11 6 8 9 10 10 10 11 12 7 9 10 11 11 11 12 13 8 10 11 12 12 12 13 14 9 11 12 13 13 13 14 15 10 12 13 14 14 14 15 11 13 14 15 15 15 12 14 15 13 15 14 15 8 olika LedT
Placeras dessa tr¨ad bredvid varandra och justerar de respektive prior-iteterna i h¨ojd till varandra kan det ses ett m¨onster. Luckan som bildas vid de h¨ogre prioriteterna ¨ar de IDK:er som av n˚agon anledning inte finns i LedT.
2018-11-01 6 IDK-RT
LedT LedT LedT LedT LedT LedT LedT LedT
18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 2 3 4 4 5 5 5 6 6 6 6 6 6 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 9 9 9 9 9 9 9 9 10 10 10 10 10 10 10 10 11 11 11 11 11 11 11 11 12 12 12 12 12 12 12 12 13 13 13 13 13 13 13 13 14 14 14 14 14 14 14 14 15 15 15 15 15 15 15 15
LedT placerade med prioriteter justerade i h¨ojd med varandra
F¨argl¨aggs de saknade IDK:erna och flyttar prioritetssiffrorna till en egen kolumn blir det tydligt hur IDK-schemat ser ut.
2018-11-01 6 IDK-RT
LedT LedT LedT LedT LedT LedT LedT LedT
Prioritet 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 IDK-schema tidsintervall 18:00 - 19:45
Med ett st¨orre tidsperspektiv blir det ¨annu tydligare hur de olika IDK-RT, prioriteterna och blocken samarbetar f¨or att visuellt kunna bygga upp ett IDK-schema f¨or anv¨andaren.
2018-11-01 6 IDK-RT
LedT LedT LedT LedT LedT LedT LedT LedT LedT LedT LedT LedT LedT LedT LedT LedT LedT LedT LedT LedT LedT LedT LedT Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 IDK-schema intervall 17:30 - 23:00
6.1.4 Reservera via telefon eller restaurangens hemsida
Reservationer kan g¨oras via telefon d¨ar en anst¨alld hanterar reservationen eller via restaurangens hemsida d˚a reservationen sker automatiskt.
Input: Antal g¨aster, ¨Onskad tid Start-Slut
Data: P ¨ar prioritet att g¨amf¨ora med, p prioritet i en LedT
1 Function hittaLedigIDK(antal, start, slut )
2 aktuellaLedT [ ] = skapaBlock(antal, start, slut) 3 while Inte alla ¨onskade f¨ors¨ok utf¨orda do
4 while (aktuellaLedT ¨ar inte slut OR perfekt tr¨aff hittat do 5 if aktuellaLedT[p] == P > Minsta antal godk¨ant
sammanh¨angande tidpunkter then
6 l¨aggTillF¨orslagIDK()
7 end
8 P = s¨amsta nu testade p;
9 N¨asta j¨amf¨orelse aktuellaLedT[P eller s¨amre ¨an P];
10 end
11 visaF¨orslag()
12 switch Ut¨oka s¨okningen do om ¨onskas 13 case Tidigare do start - Tid; 14 case Senare do slut + Tid; 15 case Fler g¨aster do antal + 1;
16 otherwise do break;
17 end
18 end
19 if accepterar f¨orslag then reserveraIDK(IDK);
20 else if ¨Onskar skapa egen IDK then reserveraIDK(skapaIDK()); 21 else Restaurangen full. Avvisa g¨aster;
22 end
23 Function reserveraIDK(IDK )
24 Aktuella IDK flyttas fr˚an LedT till ResT; 25 IDK placeras i IDK-schema;
26 bordsdata = h¨amtaBordsdata(IDK); 27 uppdateraBordstabellen(bordsData); 28 flyttaOanv¨andabaraIDK(bordsData);
29 end
Figure 6: Fl¨odesschema Telefon/Webb reservation alternativ 1
1. N¨ar en reservation ska g¨oras m˚aste systemet veta hur m˚anga personer som ing˚ar i s¨allskapet och vilket datum samt tid som ¨onskas.
2. Antalet personer i s¨allskapet och tidsblocket f¨or ¨onskad startpunkt noteras.
4. Om det inte finns n˚agon passande IDK kan systemet: (a) S¨oka tidigare starttid.
(b) S¨oka senare sluttid.
(c) S¨ok IDK:er f¨or fler antal g¨aster.
5. Om ingen tr¨aff hittas i IDK-RT kan hovm¨astaren skapa egna IDK:er. Hovm¨astaren f˚ar en karta eller lista ¨over lediga bord och kan markera ¨
onskade bord och p˚a det s¨attet skapa en tillf¨allig IDK.
6. Om inte n˚agon IDK blir vald ¨ar restaurangen fullbokad och g¨asterna m˚aste avf¨ardas.
7. N¨ar en l¨amplig IDK blir vald s˚a forts¨atter fl¨odet. Reservationen bekr¨aftas, vald IDK flyttas fr˚an LedT till ResT i de aktuella IDK-RT, och IDK:n placeras samt optimeras i IDK-schemat.
8. Den valda IDK:s data h¨amtas. D¨ar finns informationen vilka bord som ing˚ar.
9. Bordstabellen uppdateras f¨or de numera ej tillg¨angliga borden.
10. Borden skickar sina respektive MyIDK och samtliga dessa flyttas till OanT.
6.1.5 Avboka eller l¨amnar
N¨ar g¨aster avbokar ett reserverat bord och n¨ar g¨aster l¨amnar ett bord efter att de ¨ar klara hanteras p˚a liknande s¨att.
1 if S¨allskap avbokar then
2 IDK = V¨alj l¨agsta prioriterade IDK i det aktuella tidsblocket 3 IDK flyttas fr˚an ResT till LedT
4 else S¨allskap l¨amnar bord
5 IDK = IDK som s¨allskapet satt vid 6 IDK flyttas fr˚an AnvT till LedT
7 end
8 optimeraIDKSchema()
9 bordsdata = h¨amtaBordsdata(IDK) 10 uppdateraBordstabellen(bordsdata)
11 while Inte alla bord i MyIDK kontrollerade do
12 if Bordsdata.MyIDK.IDK [alla bord] == bord lediga then IDK
flyttas fr˚an OanT till LedT ;
13 end
Figure 7: Fl¨odesschema Avbokar/l¨amnar bord alternativ 1
1. N¨ar ett s¨allskap l¨amnar ett bord, dvs en IDK, resulterar det i att den specifika IDK:n kommer att bli ledig. N¨ar ett s¨allskap avbokar v¨aljer systemet den l¨agst prioriterade IDK som passar i detta tidsblock. 2. N¨ar en IDK ¨ar vald flyttas denna till LedT i det aktuella tidsbocket,
IDK-schemat optimeras och data f¨or den aktuella IDK:n h¨amtas. 3. IDK-data inneh˚aller information om vilka bord som ing˚ar i denna IDK. 4. Borden skickar sina MyIDK och bordstabellen uppdateras.
5. Samtliga IDK:ers bord i samtliga MyIDK j¨amf¨ors med bordstabellen. 6. ¨Ar alla bord i en specifik IDK lediga under en viss tidpunkt flyttas
6.1.6 G¨aster anl¨ander
N¨ar g¨aster anl¨ander till restaurangen finns det n˚agra olika situationer.
1 if Reservation finns men fel antal g¨aster then 2 avbokaBord()
3 reserveraBord()
4 else if Ingen reservation finns then 5 reserveraBord()
6 else
7 Samma antal g¨aster som vid reservation
8 end
9 if G¨aster har inte f˚att n˚agon reservation then 10 Avvisa g¨aster
11 EXIT()
12 end
13 IDK = h¨ogstPrioriteradeIDKDennaTidpunkt() 14 flyttaIDKTillLedT(IDK)
15 Visa g¨aster till IDK
Figure 8: G¨aster anl¨ander alternativ 1
1. Det finns tre olika situationer (Om inte s¨allskapet har en l˚ast IDK reserverad)
(a) Walk-in bokning. Detta leder till att hovm¨astaren f˚ar g¨ora en reservationss¨okning fr˚an detta klockslag. N¨ar hela det fl¨odet ¨ar klart kan ”G¨aster anl¨ander” fl¨odet forts¨atta.
(b) G¨aster har reserverat men ¨ar inte samma antal som angavs vid reservationen. Detta kan leda till att den t¨ankta IDK inte l¨angre ¨
ar optimal. D¨arf¨or hanteras ¨arendet f¨orst som ett avbokar ¨arende med syfte att frig¨ora borden. N¨ar det fl¨odet ¨ar klart g¨ors en reservation med m˚al att hitta en b¨attre IDK. N¨ar det fl¨odet ¨ar klart forts¨atter anl¨ander fl¨odet.
(c) G¨aster har reserverat och ¨ar samma antal personer som de uppgav vid reservations tillf¨allet.
2. IDK-schemat s¨oks fr˚an denna tidpunkt och den IDK med h¨ogst prior-itet blir vald. (Om inte s¨allskapet har en l˚ast IDK reserverad) Detta f¨or att alltid str¨ava efter att de IDK med h¨ogst prioritet ska vara anv¨anda.
3. G¨asterna blir visade till borden och den specifika IDK:n blir flyttad till AnvT.
6.2
Alternativ 2
Detta f¨orslag beh¨over mindre minnesutrymme ¨an alternativ 1. Detta p˚a bekostnad att tiden f¨or en s¨okning ¨okar snabbare desto fler bord som redan ¨
ar reserverade eller anv¨anda. 6.2.1 Datastruktur
Varje anv¨and tidpunkt har en bordstabell. Detta ¨ar utg˚angspunkten f¨or att veta vilka IDK:er som ¨ar anv¨andbara. Bordstabellen kommer att j¨amf¨oras med r¨att grupp i IDK-data och utesluta IDK:er med oanv¨andbara bord tills en IDK som g˚ar att anv¨anda hittas. Denna uteslutning g¨ors fr˚an h¨ogsta prioritet och ner˚at. Det betyder att den h¨ogst prioriterade lediga IDK:n kommer att bli vald f¨orst.
6.2.2 Reservera via telefon eller restaurangens hemsida Input: Antal g¨aster, ¨Onskad tid Start-Slut
Data: p ¨ar prioritet att kontrollera
1 while Inte alla ¨onskade f¨ors¨ok utf¨orda do 2 while Det finns fler IDK:er do
3 IDK = h¨amtaIDK(p) 4 if allaBordLediga(IDK) then 5 Break 6 else 7 p = 1 l¨agre prioritet ¨an p 8 end 9 end
10 switch Ut¨oka s¨okning do om ¨onskas 11 case Tidigare do Start - Tid; 12 case Senare do Slut + Tid; 13 case Fler g¨aster do Antal + 1; 14 otherwise do break;
15 end
16 end
17 if accepterar f¨orslag then Forts¨att;
18 else if ¨Onskar skapa egen IDK then IDK = skapaIDK(); 19 else 20 Restaurangen full 21 Avvisa g¨aster 22 EXIT() 23 end 24 placeraIDKSchema(IDK) 25 optimeraIDKShema() 26 uppdateraBordstabellen(IDK)
Figure 9: Fl¨odesschema telefon/webb reservation alternativ 2
1. N¨ar en reservation ska g¨oras m˚aste systemet veta hur m˚anga personer som ing˚ar i s¨allskapet och vilket datum samt tid som ¨onskas.
2. Antalet personer i s¨allskapet och tidsblocket fr˚an ¨onskad startpunkt noteras.
3. Den h¨ogsta prioriterade IDK-data i r¨att grupp blir vald.
4. Borden i den valda IDK:n j¨amf¨ors med bordstabellen f¨or varje tidpunkt. N¨ar ett av borden visar sig vara oanv¨andbart avf¨ardas denna IDK.
6. Om det inte hittas en passande IDK kan systemet: (a) S¨oka tidigare starttid.
(b) S¨oka senare sluttid
(c) S¨oka IDK:er f¨or fler antal g¨aster. Sedan upprepas s¨okningen fr˚an punkt 3.
7. Om ingen passande IDK hittas kan hovm¨astaren skapa en tillf¨allig IDK. Hovm¨astaren visas en karta eller lista ¨over lediga bord och kan markera ¨
onskade bord och p˚a det s¨attet bygga en IDK.
8. Om inte n˚agon IDK blir vald ¨ar restaurangen fullbokad och g¨asterna m˚aste avf¨ardas.
9. Om en IDK blir vald bekr¨aftas reservationen, IDK:n blir placerad och IDK-schemat optimeras och bordstabellen uppdateras.
6.2.3 Avboka eller l¨amnar
N¨ar g¨aster avbokar ett reserverat bord och n¨ar g¨aster l¨amnar ett bord efter att de ¨ar klara hanteras p˚a liknande s¨att.
1 if S¨allskap avbokar then
2 IDK = V¨alj l¨agsta prioriterade IDK i det aktuella tidsblocket 3 else S¨allskap l¨amnar bord
4 IDK = S¨allskapet satt vid IDK
5 end
6 taBordIDKFr˚anScheam(IDK) 7 opptimeraIDKSchema() 8 uppdateraBordstabell(IDK)
Figure 10: Fl¨odesschema avbokar/l¨amnar bord alternativ 2
1. N¨ar ett s¨allskap avbokar en reservation blir den l¨agst prioriterade IDK i passande tidsblock valt ur IDK-schemat. N¨ar g¨aster l¨amnar bord blir den IDK g¨asterna satt vid och dess tidsblock valt.
2. Den valda IDK blir bortplockad och IDK-schemat blir optimerat. Bor-dstabellen uppdateras.
6.2.4 G¨aster anl¨ander
1 if Reservation finns men fel antal g¨aster then 2 avbokaBord()
3 reserveraBord()
4 else if Ingen reservation finns then 5 reserveraBord()
6 else
7 Samma antal g¨aster som vid reservation
8 end
9 if G¨aster har inte f˚att n˚agon reservation then 10 Avvisa g¨aster 11 EXIT() 12 end 13 IDK = h¨ogstPrioriteradeIDKDennaTidpunkt() 14 andraIDKtillAnv¨andIIDKSchema(IDK) 15 uppdateraBordstabellen() 16 Visa g¨aster till IDK
Algorithm 6: G¨aster anl¨ander alternativ 2
Figure 11: Fl¨odesschema g¨aster anl¨ander alternativ 2
reserverad)
(a) Walk-in bokning. Detta leder till att hovm¨astaren f˚ar g¨ora en reservationss¨okning fr˚an detta klockslag. N¨ar hela det fl¨odet ¨ar klart kan ”G¨aster anl¨ander” fl¨odet forts¨atta.
(b) G¨aster har reserverat men ¨ar inte samma antal som angavs vid reservationen. Detta kan leda till att den t¨ankta IDK inte l¨angre ¨
ar optimal. D¨arf¨or hanteras ¨arendet f¨orst som ett avbokar ¨arende med syfte att frig¨ora borden. N¨ar det fl¨odet ¨ar klart g¨ors en reservation med m˚al att hitta en b¨attre IDK. N¨ar det fl¨odet ¨ar klart forts¨atter anl¨anderfl¨odet.
(c) G¨aster har reserverat och ¨ar samma antal personer som de uppgav vid reservations tillf¨allet.
2. IDK-schemat s¨oks fr˚an denna tidpunkt och den IDK med h¨ogst prior-itet blir vald. (Om inte s¨allskapet har en l˚ast IDK reserverad) Detta f¨or att alltid str¨ava efter att de IDK med h¨ogst prioritet ska vara anv¨anda. 3. G¨aster placeras vid vald IDK och bordstabellen uppdateras
7
S¨
oka
N¨ar systemet s¨oker efter lediga tider ¨ar utg˚angspunkten IDK-schemat.
7.1
Hur g˚
ar en s¨
okning till
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 A B 2 C D 3 E F 4 G H 5 I 6 J 7 K 8 9 Slut ¨ Onskan L
Table 1: Exempel p˚a IDK-schema
¨
ar bokstaverade. Detta ¨ar endast f¨or att l¨asaren ska kunna se vart varje respektive block flyttas. Det har inget med vilka s¨allskap som reserverat eller hur blocken ¨ar utformade.
Det som g¨ors ¨ar att varje tidpunkt kontrollerar vilket som ¨ar den h¨ogsta prioriterade IDK i denna tidpunkt. I tabell 2 ¨ar detta f¨ors¨ok 1. Om inte hela blocket har samma IDK justeras n¨asta s¨okning till lika stort eller st¨orre ¨an den l¨agsta prioriteten i f¨orra s¨oket. I detta exempel ¨ar det tidpunkt 19:45 som har IDK(8) och de ¨ovriga tidpunkterna anpassar sig efter detta i f¨ors¨ok 2. F¨ors¨ok 2 ¨ar IDK(8) ledigt vid alla tidpunkter vilket visas med gr¨on f¨arg i tabell 2. Detta visar att det finns plats i restaurangen och reservationen kan bekr¨aftas.
F¨ors¨ok 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 2 4 5 6 6 6 7 8
2 8 8 8 8 8 8 8 8
Table 2: Begr¨ansad s¨okning
7.2
Ut¨
okad s¨
okning - tidsm¨
assigt
Det g˚ar att antingen direkt eller efter en misslyckad s¨okning att ut¨oka s¨okalternativen. Med detta menas att systemet ¨aven kan kontrollera tidigare tidpunkter och
senare tidpunkter ¨an vad som ¨onskats. Detta kan generera flera alternativ. I detta exempel ¨ar det samma f¨oruts¨attningar som i tidigare exempel. S¨okningen g¨ors med tidsintervallet 17:30 - 20:30. Det vill s¨aga start tiden ¨ar en halvtimme tidigare och slut tiden ¨ar en halvtimme senare ¨an ¨onskad tid. Det accepterade blocket ¨ar i detta fall en timmes storlek och dessa alter-nativ kommer d¨armed att visas som m¨ojliga f¨orslag. I st¨allet f¨or att anpassa n¨asta s¨okning till l¨agsta prioriteten i tidigare s¨okning anpassas s¨oket till den minsta prioritet i ett m¨ojligt alternativ.
I tabell 3 g˚ar det att se att f¨ors¨ok tv˚a har tv˚a f¨orslag. Mellan 17:30-18:15 ¨
ar IDK(4) ledigt i alla tidpunkter. D˚a ett block p˚a en timme ¨ar acceptabelt r¨aknas detta block som ett alternativ. ¨Aven mellan 19:45-20:30 ¨ar det m¨ojligt f¨or g¨aster att sitta vid IDK(8) med en timmes block. Om dessa hade varit de enda alternativ som fungerade hade hovm¨astaren kunnat ge dessa som f¨orslag och sedan hade det varit upp till g¨asten att acceptera eller avb¨oja sittplatserna. Det g˚ar vidare under de kommande s¨okningarna att se att det finns flera tidsblock med m¨ojliga l¨osningar ¨anda fram till f¨ors¨ok 6 som har en perfekt tr¨aff f¨or ¨onskad reservation.
F¨ors¨ok 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 1 1 2 4 5 6 6 6 7 8 1 2 2 2 4 4 4 4 5 6 6 6 7 8 8 8 8 3 5 5 5 5 5 6 6 6 7 8 8 8 8 4 6 6 6 6 6 6 6 6 7 8 8 8 8 5 7 7 7 7 7 7 7 7 7 8 8 8 8 6 8 8 8 8 8 8 8 8 8 8 8 8 8
Table 3: Ut¨okad s¨okning
7.3
Ut¨
okad s¨
okning parallellt med fler antal g¨
aster
I de tv˚a tidigare exemplen har endast IDK:er i gruppen med samma antal sittplatser som det faktiska antalet g¨aster hanterats. Det skulle ¨aven kunna g¨oras en parallell s¨okning d¨ar det r¨atta antalet g¨aster hanteras men ¨aven antalet g¨aster plus en eller flera personer ytterligare. Denna s¨okning leder visserligen till att det kommer att finnas f¨orslag p˚a IDK:er d¨ar inte alla sittplatser blir anv¨anda. Men det kan ¨and˚a vara ett alternativ att starta denna s¨okning f¨or att ¨aven presentera dessa resultat.
7.4
Brist i s¨
oksystemet
Det finns situationer d¨ar dessa s¨okningar skulle ge resultat att inga lediga IDK:er finns.
Tabel 4 visar ett s˚adant situation.
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 A B 2 C D 3 E F 4 G Slut ¨ Onskan H
Table 4: Ett IDK-schema med ett block som ska placeras Det orange blocket symboliserar en ¨onskan om att reservera.
F¨ors¨ok 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00
1 1 1 1 2 3 4 4 4
2 Slut Slut Slut Slut 4 4 4 4
3 Slut Slut Slut Slut Slut Slut Slut Slut
Table 5: Begr¨ansad s¨okning d¨ar endast s¨ammre f¨orslag hittats
Som g˚ar att se i tabell 5 skulle en begr¨ansad s¨okning generera ett f¨orlag p˚a ett block som b¨orjar 45 minuter senare ¨an ¨onskat och endast ¨ar 1 timme l˚angt.
F¨ors¨ok 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 Slut Slut 1 1 1 2 3 4 4 4 4 1
2 Slut Slut Slut Slut Slut Slut 4 4 4 4 4 4
3 Slut Slut Slut Slut Slut Slut Slut Slut Slut Slut Slut Slut Table 6: Ut¨okat s¨ok med endast s¨ammre l¨onsningar hittade
Denna s¨okning skulle generera ett f¨orslag p˚a ett st¨orre block p˚a 1 timme och 30 minuter. Men starttiden skulle vara den samma.
Skulle s¨allskapet acceptera denna tid skulle IDK-schemat, efter en opti-mering, se ut som tabell 7 visar.
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 A H 2 C B 3 E D 4 G F Slut
Table 7: Optimerat efter att ett s¨ammre alternativ valts
Som g˚ar att se i tabell 7 bildas en lucka mellan block A och det nya blocket H. Detta ¨ar inte en optimal situation i och med att s¨allskapet ville reservera tidigare men fick endast ett senare f¨orslag.
7.5
L¨
osningsf¨
orslag p˚
a brist i s¨
ok
En t¨ankbar l¨osning p˚a bristen i s¨ok ¨ar att en testoptimering utf¨orts med ett ”test block”. Det vill s¨aga det placerar ett block p˚a en IDK som inte existerar. I tabell 4 anv¨ands nu block H som ett test block. Resultatet efter en optimering ses i tabell 8.
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 A H 2 C B 3 E D 4 G F Slut
Table 8: Optimering med testblock
Som g˚ar att se i tabell 8 skulle en perfekt tr¨aff kunna ske utan att n˚agra andra block skulle bli oanv¨andbara. Detta skulle vara ett b¨attre resultat b˚ade f¨or g¨aster och ¨agare.
8
Optimera IDK-schema
IDK-schemat b¨or vid varje f¨or¨andring optimeras. Med detta menas att schemat str¨avar efter att alltid ha s˚a f˚a tidpunkter som m¨ojligt lediga vid de h¨ogre prioriteterna. Detta betyder i sin tur att de h¨ogre prioriterade IDK:erna anv¨ands eller ¨ar reserverade i s˚a stor utstr¨ackning som m¨ojligt. Denna rapport tar upp tre s¨att att ˚astadkomma detta p˚a. Alla tre opti-meringar kommer att utg˚a fr˚an samma fiktiva ej optimerade IDK-schema. Detta IDK-schema kan ses i tabell 9. De reserverade blocken har ljusbl˚a f¨arg.
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 A B 2 C 3 D 4 E F 5 G 6 H I 7 J 8 K 9 L 10 M 11 N 12 O 13 P 14 Q 15 R
Table 9: Ej optimerat IDK-schema
8.1
Optimeringsalternativ 1 - Tidigaste tiden och st¨
orsta
blocket
Detta f¨orslag ¨ar det enklaste s¨attet att bem¨ota problemet och blir d¨arf¨or ocks˚a det minst komplexa samtidigt som det levererar ett gott resultat. Re-sultatet g˚ar att se i tabell 10.
Regler f¨or hur optimeringsalternativ 1 utf¨ors: 1. Vilket/Vilka block ¨ar tidigast av de ej placerade.
2. Vilket av dessa block ¨ar st¨orst (Vid lika stora block slumpas valet). 3. Placera valt block p˚a h¨ogsta m¨ojliga prioritet.
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 A O F 2 H B 3 G M 4 D J 5 E L 6 N P 7 C 8 Q I 9 K R 10 11 12 13 14 15
Table 10: IDK-schema optimerat med alternativ 1
8.1.1 Brist i alternativ 1
Det kan uppst˚a situationer d¨ar alternativ 1 inte fungerar optimalt.
En situation som utg˚ar fr˚an det ej optimerade IDK-schemat i tabell 11
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 2 A 3 B 4 C 5
Table 11: Ej optimerat IDK-schema
Resultatet efter optimeringsalternativ 1 g˚ar att se i tabell 12.
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 C 2 B A 3 4 5
Table 12: Ej optimal resultat med optimeringsalternativ 1
Som g˚ar att se i tabell 12 har reglerna f¨oljts och det st¨orre blocket C ¨ar placerat vid h¨ogsta prioriteten. Sedan block B och sist placeras block A. Detta leder till att det ¨ar mer anv¨anda tidpunkter i IDK(2) ¨an vad det ¨ar i IDK(1).
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 B A 2 C 3 4 5
Table 13: ¨Onskv¨art resultat efter optimering
8.2
Optimeringsalternativ 2 - Tidigaste tiden och st¨
orsta
sammanh¨
angande blocket
Alternativ 2 ¨ar mer komplext och kr¨aver mer processortid ¨an alternativ 1. F¨ordelen ¨ar att detta alternativ l¨oser bristen i alternativ 1 och kan under vissa omst¨andigheter leverera b¨attre resultat p˚a bekostnad av l¨angre arbetstid. Resultatet efter optimeringsalternativ 2 g˚ar att se i tabell 14.
Regler f¨or hur optimeringsalternativ 2 utf¨ors: 1. Vilket/Vilka block ¨ar tidigast av de ej placerade.
2. ¨Ar dessa blockens sluttid samma som ett annat blocks starttid. 3. Om ja, utf¨or punkt 2 ¨aven p˚a detta block. Utf¨or tills svaret ¨ar nej. 4. Vilket av dessa sammanh¨angande block ¨ar st¨orst. (Vid lika stora block
slumpas valet).
5. Placera de valda sammanh¨angande blocken vid h¨ogsta m¨ojliga prioritet. 6. G¨or om fr˚an punkt 1. Forts¨att tills alla blocken ¨ar placerade.
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 A I 2 H O F 3 G C 4 D B 5 E J 6 N L 7 Q R 8 M 9 K P 10 11 12 13 14 15
8.2.1 Brist i alternativ 2
Det kan uppst˚a situationer d¨ar alternativ 2 inte fungerar optimalt vilket ocks˚a har skett och kan ses i tabell 14.
Vi utg˚ar fr˚an fem av blocken i tabell 9 och l˚ater endast de intressanta blocken vara kvar i IDK-schemat. D˚a ser IDK-schemat ut som i tabell 15.
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 A 2 3 4 F 5 6 H I 7 8 9 10 11 12 O 13 14 15
Table 15: Ej optimerat IDK-schema
Resultatet efter optimeringsalternativ 2 g˚ar att se i tabell 16.
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00
1 A I
2 H O F
3
Table 16: Ej optimalt resultat efter optimeringsalternativ 2
Reglerna blev f¨oljda och f¨orst valdes och placerades block A. Efter block A valdes block H. Vid block H:s slut passade block O och sedan ¨aven block F. Dessa block placerades p˚a IDK(2) eftersom IDK(1) ¨ar anv¨and av block A. Efter denna placering ¨ar endast block I kvar som blir placerat p˚a IDK(1).
Som g˚ar att se i tabell 16 hade block F kunnat blivit placerad h¨ogre redan som schemat ser ut nu. ¨Aven block O och block I hade kunnat byta plats med resultat att h¨ogre prioritet hade f˚att mer tid.
Det optimala resultatet g˚ar att se i tabell 17.
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00
1 A O F
2 H I
3
8.3
Optimeringsalternativ 3 - Optimera inom ett
tidsin-tervall och flest anv¨
anda tidpunkter f˚
ar h¨
ogsta
pri-oritet
Detta alternativ garanterar flest anv¨anda tidpunkter i de h¨ogsta prioriteterna inom ett visst tidsintervall. Detta p˚a bekostnad av att det inte garanterar att g¨aster blir placerade vid den nu f¨or tillf¨allet h¨ogsta lediga prioriterade IDK:n. Detta kan leda till brister vid exempelvis sena avbokningar eller g¨aster som inte anl¨ander. Dessa problem minimeras i alternativ 1 och 2.
Att formulera tydliga regler f¨or hur optimeringen skall utf¨oras kan ocks˚a ses som en begr¨ansning.
Regler f¨or hur optimeringsalternativ 3 utf¨ors: 1. V¨alj ett tidsintervall att optimera.
2. R¨akna antalet tidpunkter som varje block anv¨ander p˚a de ej placerade blocken.
3. Addera antalet anv¨anda tidpunkter f¨or de block som ¨ar m¨ojliga att placera bredvid varandra.
4. Placera de block som ¨ar m¨ojliga att placera bredvid varandra och har det h¨ogsta sammanlagda antalet anv¨anda tidpunkter p˚a det h¨ogsta m¨ojliga prioriterade IDK:n.
5. G¨or om fr˚an punkt 2. Forts¨att tills alla blocken ¨ar placerade.
Resultat efter optimeringsalternativ 3 g˚ar att se i tabell 18. ¨Aven en extra kolumn har lagts till med syfte att f¨ortydliga antalet anv¨anda tidpunkter f¨or varje IDK.
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 Anv¨anda tidpunkter
1 A O F 18 2 H B 16 3 D J 16 4 N R 16 5 G Q P 14 6 E L 14 7 C 8 8 M 8 9 K I 8 10 0 11 0 12 0 13 0 14 0 15 0
8.4
L˚
asta block
Det kan uppst˚a situationer som kr¨aver att ett visst s¨allskap ska placeras vid en specifik IDK. Det kan vara att s¨allskapet har en specifik ¨onskan om var de ska sitta eller att hovm¨astaren vill att ett visst s¨allskap ska bli placerad vid en specifik IDK. Block som ¨ar reserverade f¨or ett specifikt s¨allskap eller redan har g¨aster placerade kallas l˚asta block. Det betyder att blocket endast ¨
ar till f¨or ett s¨allskap och d¨armed ¨ar den IDK:n inte tillg¨anglig f¨or andra g¨aster. Detta betyder att detta l˚asta block inte ska ing˚a i optimeringen och hanteras d¨armed som ett redan placerat block. Detta kan leda till ett s¨amre resultat och b¨or d¨arf¨or undvikas.
Tabell 19 har samma block placering som tabell 9 med till¨agget att n˚agra av blocken ¨ar l˚asta. De l˚asta blocken representeras med rosa f¨arg
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 A B 2 C 3 D 4 E F 5 G 6 H I 7 J 8 K 9 L 10 M 11 N 12 O 13 P 14 Q 15 R
Table 19: IDK-schema med l˚asta block
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 A B 2 G C F 3 D J 4 E P 5 N I 6 H O 7 Q R 8 M 9 K L 10 11 12 13 14 15
Table 20: IDK-schema med l˚asta block optimerat alternativ 1
I tabell 20 har optimeringsalternativ 1 anv¨ants. Blocken A, B, H och L har inte flyttats under optimeringen eftersom att de ¨ar l˚asta.
9
Placera g¨
aster
G¨aster som har l˚asta bord av n˚agon anledning ing˚ar inte i detta resonemang. De s¨allskapen kommer att bli placerade vid den specifika IDK:n som de ¨ar t¨ankta att sitta vid.
G¨aster som anl¨ander till restaurangen kommer att bli placerade utifr˚an IDK-schemat. Detta g¨aller ¨aven s¨allskap som inte har reserverat i f¨orv¨ag. Finns det lediga IDK f¨or s¨allskapet kommer det att placeras i IDK-schemat och hanteras som en reservation. Oavsett om det g¨ors p˚a plats eller en tid f¨ore.
Systemet bygger p˚a iden att ”f¨orst in b¨ast plats”. Detta betyder att har tv˚a eller fler lika stora s¨allskap reserverat bord samma tid kommer de som anl¨ander f¨orst att f˚a h¨ogsta prioriterade IDK:n. Detta med syfte att alltid fylla de h¨ogst prioriterade IDK:erna f¨orst. Detta utifall n˚agot of¨orutsett h¨ander med resultat att n˚agon av s¨allskapen inte anl¨ander.
Ett f¨ortydligande exempel.
S¨allskapet Anderson och s¨allskapet Bengtsson ¨ar b˚ada sex personer vardera. N˚agra dagar innan kontaktar de restaurangen och ber om att f˚a reservaera bord 1 november klockan 18:00.
Efter reservationerna ser IDK-schemat ut som i tabell 21.
2018-11-01 Prioritet 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 1 A 2 B 3 4 Table 21: IDK-schema
1 november 17:55 anl¨ander s¨allskapet Eriksson, sex personer, som inte har reserverat och undrar om det finns bord ledigt. Det g¨ors en s¨okning och de f˚ar svar att det finns. Eriksson reservations block blir placerat p˚a IDK(3). Men eftersom de ¨ar f¨orst p˚a plats blir de visade till IDK(1). Block A i tabell 22 blir nu l˚ast i och med att s¨allskapet Eriksson blivit placerade vid detta bord. IDK-schemat ser nu ut som tabell 22 visar.
2018-11-01 Prioritet 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 1 A 2 B 3 C 4
18:00 meddelar s¨allskapet Andersson att de inte kommer att komma och vill avboka sin reservation. Block C p˚a IDK (3) tas bort.
18:20 har s¨allskapet Bengtsson fortfarande inte anl¨ant och hovm¨astaren v¨aljer att sl¨appa deras reservation. N˚agot som ¨ar ganska vanligt i branschen [4, 8]. Block B p˚a IDK(2) tas bort.
Nu ser IDK-schemat ut som tabell 23 visar.
2018-11-01 Prioritet 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 1 A 2 3 4
Table 23: Optimerat IDK-schema med ett optimalt resultat
Som g˚ar att se i tabell 23 anv¨ands IDK(1) fast tv˚a av de t¨ankta s¨allskapen inte kommer att anl¨anda.
Hade samma scenario utspelat sig men att iden med ”f¨orst in b¨ast plats” inte hade till¨ampats hade det blivit f¨oljande resultat.
1 november 17:55 anl¨ander s¨allskapet Eriksson, sex personer. Eftersom block A p˚a plats IDK(1) ¨ar t¨ankt att anv¨andas till Andersson och block B p˚a plats IDK(2) ¨ar t¨ankt till Bengtsson blir s¨allskapet Eriksson reserverade och placerade p˚a block C p˚a plats IDK(3).
Nu ser IDK-schemat ut som tabell 24 visar.
2018-11-01 Prioritet 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 1 A 2 B 3 C 4
Table 24: IDK-schema med l˚ast block C
S¨allskapen Andersson och Bengtsson avbokar och IDK-schemat ser nu ut som tabell 25 visar.
2018-11-01 Prioritet 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 1 2 3 C 4
Table 25: Optimerat IDK-schema med ej optimalt resultat
Som g˚ar att se i tabell 25 ¨ar b˚ada de h¨ogst prioriterade IDK(1) och (2) oanv¨anda medan det s¨amre IDK(3) anv¨ands.
10
G¨
aster l¨
amnar. Optimering n¨
ar block f¨
orsvinner
N¨ar s¨allskap l¨amnar ¨ar det ¨onskv¨art att det aktuella blocket blir borttaget, att IDK-schemat blir optimerat och bordstabellen uppdaterad. Detta f¨or att undvika ha IDK:er som till synes ¨ar anv¨anda men i praktiken st˚ar tomma.
Tabell 26 visar ett exempel p˚a hur ett IDK-schema kan se ut d¨ar block A som ¨ar IDK(1) har s¨allskap sittandes.
2018-11-01 Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00 1 A B 2 C 3 Table 26: IDK-schema
Av n˚agon anledning v¨aljer s¨allskapet att l¨amna restaurangen redan klockan 18:20. Detta betyder att om block A tas bort och optimering utf¨ors kommer block C att flyttas upp till IDK(1) och d¨armed fylla de h¨ogre prioriteterna s˚a mycket som m¨ojligt.
2018-11-01
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00
1 C B
2 3
Table 27: Optimerat IDK-schema med bra resultat ¨
Aven om optimeringen inte leder till n˚agon f¨orb¨attring, exempelvis om g¨aster redan sitter vid block C, b¨or block A plockas bort f¨or att ge m¨ojlighet att fylla luckan som uppst˚att.
2018-11-01
Prioritet 17:30 17:45 18:00 18:15 18:30 18:45 19:00 19:15 19:30 19:45 20:00 20:15 20:30 20:45 21:00 21:15 21:30 21:45 22:00 22:15 22:30 22:45 23:00
1 B
2 C
3
Table 28: Optimerat IDK-schema med l˚ast block C
11
Skapa egna tillf¨
alliga IDK:er
Om inte n˚agon l¨amplig IDK finns ska hovm¨astarens ha m¨ojlighet att skapa en ny tillf¨allig IDK. En karta eller lista p˚a lediga bord ¨over en ¨onskad tidsin-tervall visas och sedan kan hovm¨astare sj¨alv markera ¨onskade bord med
re-Detta kan vara anv¨andbart n¨ar restaurangen har det efterfr˚agade antalet sittplatser ledigt men borden ¨ar placerade i olika delar av restaurangen. I detta fall kan hovm¨astaren erbjuda platser ¨aven om det inte ¨ar de optimala platserna. Sedan har s¨allskapet m¨ojlighet att acceptera borden som bli er-bjudna eller tack nej. Hur ¨an s¨allskapet v¨aljer s˚a ¨ar det bra service att ge f¨orslag p˚a l¨osningar.
Ett annat tillf¨alle kan vara n¨ar det ¨ar stora s¨allskap. Om ett s¨allskap p˚a 30 personer vill reservera kan det vara enklast att fr˚an en karta plocka ihop bord med r¨att antal sittplatser.
Detta ¨ar ett effektivt s¨att att minska det totala antalet IDK:er som m˚aste hanteras och d¨armed minska minnesanv¨andning samt prestandakrav sam-tidigt som alla kombinationer i hela restaurangen kan utnyttjas. En annan f¨ordel ¨ar att hovm¨astaren ges en k¨ansla av kontroll ¨over restaurangen. N˚agot som kan vara bra ur arbetsmilj¨operspektiv samtidigt som det ger restau-rangen en m¨ojlighet att s¨atta sin egen unika pr¨agel p˚a service.
12
Resultat
12.1
Sammanfattning tidskomplexitet
Uppgift Vad utf¨ors Kommentar Tidskompl-exitet Referens Alternativ 1 Telefon/ Webb Bokning Vid direkttr¨aff O(n) Algoritm 1 och sektion 12.3.1 Vid flera s¨ok O(n2) Algoritm 1
och sektion 12.3.1 Vid flera ut¨okade s¨ok O(n2) Algoritm 1 och sektion 12.3.1 Bakgrunds-process efter vald IDK O(n2logn) − O(n4) Algoritm 1 och sektion 12.3.1 Avboka/ L¨amnar Bakgrunds-process O(n3) − O(n4) Algoritm 2 och sektion 12.3.2 G¨aster anl¨ander Reserverat men fel antal O(n3) − O(n4) Algoritm 3 och sektion 12.3.3 Ingen reservation O(n3) − O(n4) Algoritm 3 och sektion 12.3.3 Reserverat och r¨att antal O(n) Algoritm 3 och sektion 12.3.3 Table 29: Resultat tabell alternativ 1
Uppgift Vad utf¨ors Kommentar Tidskompl-exitet Referens Alternativ 2 Telefon/ Webb Bokning
Vid s¨okning O(n3) Algoritm 4
och sektion 12.4.1 Vid flera ut¨okade s¨ok O(n2) Algoritm 4 och sektion 12.4.1 Avboka/ L¨amnar Bakgrunds-process O(n2) − O(n4) Algoritm 5 och sektion 12.4.2 G¨aster anl¨ander Reserverat men fel antal O(n2) − O(n4) Algoritm 6 och sektion 12.4.3 Ingen reservation O(n)−O(n3) Algoritm 6 och sektion 12.4.3 Reserverat och r¨att antal O(n) Algoritm 6 och sektion 12.4.3 Table 30: Resultat tabell alternativ 2
Uppgift Vad utf¨ors Kommentar Tidskompl-exitet
Referens
Optimering
Alt 1 Snabbast O(n2) Sektion 8.1
och 12.5.1 Alt 2 L˚angsammast men b¨attre resultat ¨an Alt 1 O(n4) Sektion 8.2 och 12.5.2 Alt 3 Garanterar flest anv¨anda tidpunkter vid h¨ogsta prioriteter O(n3) Sektion 8.3 och 12.5.3
Table 31: Resultat tabell Optimering av IDK-schema
12.2
Sammanfattning minnesanv¨
andning
Det som skiljer alternativ 1 fr˚an alternativ 2 ¨ar att alternativ 1 anv¨ander sig av IDK-referenstr¨ad. Detta inneb¨ar att alternativ 1 kommer att ha st¨orre minnesanv¨andning ¨an alternativ 2 om b˚ada alternativen j¨amf¨ors med samma f¨oruts¨attningar.
En restaurang med 2000 IDK:er och 3000 anv¨anda tidpunkter ger ca 90 MB mer utrymmeskrav f¨or alternativ 1 j¨amf¨ort med alternativ 2.
12.3
Alternativ 1 f¨
ortydligande
12.3.1 Algoritm 1 Telefon/Webb reservation
Denna algoritm kan ha h¨og tidskomplexitet beroende p˚a anv¨andarens s¨okningsparametrar och hur det aktuella IDK-schemat ser ut.
Looparna som befinner sig mellan raderna 3 - 18 ¨ar d¨ar m¨ojliga IDK alternativ hittas. Dessa kan vara de mest kritiska och tidskr¨avande.
Om s¨oket hittar en perfekt tr¨aff p˚a f¨orsta f¨ors¨oket resulterar i O(n). Om inte s˚a ¨ar fallet kommer hela processen att utf¨oras igen tills att en perfekt tr¨aff hittas eller samtliga aktuella IDK ¨ar j¨amf¨orda. Dessa tv˚a utf¨orande ger tillsammans tidskomplexitet O(n2). Om inte anv¨andaren ¨ar n¨ojd med
resultatet kan det utf¨oras igen med nya parametrar att ta h¨ansyn till. Detta ytterligare utf¨orandet ger den slutliga tidskomplexiteten O(n3).
Utifr˚an detta resonemang kan man dra slutsatsen att det kan vara till f¨ordel att ge tidigare starttid och senare sluttid redan vid f¨orsta s¨oket ¨an vad som ¨ar ¨onskat. Detta ger st¨orre m¨ojlighet att inte beh¨ova ¨andra parametrar ytterligare och d¨armed g˚a fr˚an O(n2) till O(n3) i tidskomplexitet.
Efter att en reservation har blivit accepterad och godk¨and startar en bak-grunds process. En m¨ojlig del med h¨og tidskomplexitet ¨ar delen att placera IDK i IDK-schemat p˚a rad 25. Beroende p˚a vilket optimeringsalternativ som ¨
ar valt tar det mellan O(n2) och O(n4). Detta ¨ar en process som sker utan
att anv¨andaren beh¨over vara aktiv men den m˚aste vara klar innan n¨asta reservation p˚ab¨orjas.
En annan bakgrundsprocess sker p˚a rad 24. Den som flyttar de IDK:er som inte l¨angre ¨ar anv¨andbara fr˚an LedT till OanT. Den valda IDK inneh˚aller n bord och samtliga m˚aste hanteras vilket ger oss O(n). Vart och ett av dessa bord ing˚ar i n IDK:er som samtliga m˚aste flyttas vilket ger oss O(n). Att ta bort och l¨agga till en node fr˚an i ett v¨albalanserat bin¨arts¨oktr¨ad tar O(logn) + O(logn) = O(logn). Dessa tre processer ger oss O(n) * O(n) * O(logn) = O(n2logn) i tidskomplexitet.
12.3.2 Algoritm 2 Avboka eller l¨amna
N¨ar detta fl¨ode har startat kan sedan hela processen ske i bakgrunden utan att n˚agon anv¨andare beh¨over vara aktiv. Denna process beh¨over inte vara klar innan exempelvis s¨okningen f¨or en reservation eller f¨ors¨ok att placera g¨aster genomf¨ors. Om inte processen ¨ar klar kan det resultera i s¨amre resultat i och med att det finns lediga IDK:er som uppfattas som oanv¨andbara av systemet.
Optimera IDK-schema p˚a rad 8 har en tidskomplexitet mellan O(n2) och
O(n4) beroende p˚a vilket av optimeringsalternativen som ¨ar valt.
Den mest tidskomplexa delen i denna algoritm ¨ar raderna 11 – 13. Alla bords MyIDK och alla IDK:er i dessa m˚aste kontrolleras. Dessa IDK:er inneh˚aller bord som alla m˚aste kontrolleras i fall de ¨ar lediga. Detta ger n bord som inneh˚aller MyIDK. MyIDK inneh˚aller n IDK:er. IDK:er inneh˚aller n bord som kontrolleras. Detta ger O(n) * O(n) * O(n) = O(n3)
12.3.3 Algoritm 3 G¨aster anl¨ander
Denna algoritm ¨ar beroende av de tv˚a algoritmerna presenterade i algoritm 1 och algoritm 2. Om g¨asterna har reserverat men anl¨ander med annat antal ¨an vad som uppgavs kommer if satsen p˚a rad 1 att leda vidare till rad 2-3. Dessa rader ¨ar funktionsanrop till att avboka och att reservera. Avbokarfl¨odet har tidskomplexitet O(n3) vilket visas i punkt 12,3,2. Reserverafl¨odet har
tidskomplex mellan O(n) och O(n3) enligt punkt 12,3,1. H¨ogsta prioritet denna tidpunkt h¨amtas fr˚an IDK-schemat vilket har tidskomplexitet O(n).
12.4
Alternativ 2 f¨
ortydligande
12.4.1 Algoritm 4 Telefon/Webb reservation
Denna algoritms tidskomplexitet beror till stor del p˚a om anv¨andaren vill g¨ora en stor bred s¨okning eller flera mindre.
While loopen p˚a raderna 2 – 9 har en tidskomplexitet O(n3). Varje IDK
inneh˚aller n bord som j¨amf¨ors mot bordstabellen i n tidpunkter. Om det inte ger en tr¨aff forts¨atter s¨oket tills alla n IDK ¨ar testade.
Detta oavsett vilken start och sluttid anv¨andaren ¨onskar. Om det inte presenteras ett ¨onskat resultat kan anv¨andaren v¨alja att ut¨oka s¨okningen n antal g˚anger. Detta ger tidskomplexiteten O(n) * O(n3) = O(n4).
12.4.2 Algoritm 5 Avboka eller l¨amna
N¨ar detta fl¨ode har startar kan sedan hela processen ske i bakgrunden utan att n˚agon anv¨andare beh¨over vara aktiv. Denna process beh¨over inte vara klar innan exempelvis s¨okningen f¨or en reservation eller f¨ors¨ok att placera g¨aster genomf¨ors. Om inte processen ¨ar klar kan det resultera i s¨amre resultat i och med att det finns lediga IDK:er som uppfattas som oanv¨andbara av systemet.
Optimera IDK-schema p˚a rad 7 har en tidskomplexitet mellan O(n2) och O(n4) beroende p˚a vilket av optimeringsalternativen som ¨ar vald. Detta ¨ar
den del som tar mest tid.
12.4.3 Algoritm 6 G¨aster anl¨ander
Denna algoritm ¨ar beroende av de tv˚a algoritmerna presenterade i algoritm 4 och algoritm 5.
Om g¨asterna har reserverat men anl¨ander med annat antal ¨an vad som uppgavs kommer if satsen rad 1 att leda vidare till rad 2-3. Dessa rader ¨
ar funktionsanrop till att avboka och att reservera. Om g¨asterna inte har n˚agon reservation leder if satsen till rad 5 d¨ar reservationsanrop genomf¨ors. Avbokarfl¨odet har tidskomplexitet mellan O(n2) och O(n4) vilket visas i
punkt 12,4,2. Reservera fl¨odet har tidskomplex O(n3) eller O(n4) enligt punkt 12,4,1.
N¨ar g¨asterna v¨al ska placeras h¨amtas h¨ogsta prioritet denna tidpunkt fr˚an IDK-schemat vilket har tidskomplexitet O(n). Detta sker p˚a rad 13.
N¨ar hovm¨astaren vet vilken IDK g¨asterna ska placeras vid kan resten av processen ske i bakgrunden medans g¨asterna tar plats. Den aktuella IDK:n blir l˚ast i IDK-schemat.
12.5
Optimeringsalternativ f¨
ortydligande
12.5.1 Optimeringsalternativ 1
Det ¨ar n stycken olika IDK:er som ska kontrolleras p˚a n stycken olika tid-punkter. Dessa tv˚a ger tidskomplexitet O(n2).
12.5.2 Optimeringsalternativ 2
Att kontrollera n stycken IDK en specifik tidpunkt tar O(n). Sedan kon-trolleras blockens slutpunkt vilket tar O(n). Dessa tv˚a upprepas sedan n g˚anger vilket totalt ger tidskomplexitet O(n3). Detta upprepas n g˚anger tills
alla block ¨ar placerade vilket ger slutliga tidkomplexiteten O(n4). 12.5.3 Optimeringsalternativ 3
Loopa alla IDK:er f¨or alla tidpunkter inom ¨onskat tidsintervall f¨or att veta antalet tidpunkter varje block anv¨ander. Addera de m¨ojliga kombinationer-nas anv¨anda tidpunkter. Loopa n IDK och n tidpunkter ger tidskomplexitet O(n2). Detta utf¨ors n g˚anger tills alla blocken ¨ar placerade. Vilket ger slutliga tidskomplexiteten O(n3).
