Förslag På Arkitektur För It-stöd För Arrangörer Av Friidrottstävlingar

Ett förslag på arkitektur för ett IT-stöd för arrangörer av friidrottstävlingar Certifieringsuppgift i kursen Certifierad IT-arkitekt Frode Randers, Sirius IT Version: PA3

Sammandrag — Jag beskriver en arkitektur för ett tänkt ITstöd för planering, genomförande och uppsummering av i första hand friidrottstävlingar.

rande IT-stöd som irriterande, dels orsakat av slöseriet med tid men framför allt på grund av belastningen under pågående tävling.

Eftersom området är relativt omfattande och till vissa delar kräver ett genomtänkt användargränssnitt, så kommer jag att avgränsa mig. Jag väljer att fokusera på verksamhetsarkitekturen och begränsar genomgång av applikations- och teknisk arkitektur till valda delar. Vidare så begränsar jag också beskrivningen i denna omgång till någon process och några användningsfall.

II. BESKRIVNING AV VERKSAMHETEN

Detta arbete utgör certifieringsuppgift i kursen Certifierad IT-arkitekt i regi av Ingemar Lindqvist och Per-Erik Padrón.

I. INTRODUKTION Idrottsrörelsen engagerar ett stort antal utövare iform av barn, ungdomar och seniorer samt föräldrar och privatpersoner som arbetar ideellt för att stödja utövarna med träning, kurser och tävlingar. Varje år läggs det ner tusentals timmar med arbete för att få denna apparat att fungera. Huvudsakligen handlar detta om träning; mänskliga relationer, fostrande av kropp och själ som måste få ta den tid som krävs. Därutöver tillkommer aktiviteter som kommer utövarna till godo; exempelvis arbete med tävlingar som är centrala inom alla idrotter. Idrottsrörelsen har problem med att få föräldrar att engagera sig i detta arbete eftersom det inkräktar på den disponibla fritiden. Samhällsklimatet i stort gör att många familjer väljer att konsumera tjänster framför att själv bidraga. Med denna utgångspunkt så är det beklagligt när det förslösas tid på administrativa aktiviteter - exempelvis i samband med planering, genomförande och uppsummering av tävlingar. Denna administration är känd för att förbruka individernas engagemang och kan till tider vara mycket stressande. Eftersom idrottsrörelsen inte drivs som ett företag så har man inte i samma omfattning som näringslivet sökt efter ITstöd för att förenkla administrationen eller rent av för att tillföra mervärden. Av de IT-stöd som faktiskt finns och är ekonomiskt försvarbara att anskaffa, så har de flesta vuxit fram ad-hoc och utgår i allmänhet från att förenkla enskilda aktiviteter - det har således inte tagits något samlat grepp. Med denna arkitekturgenomgång försöker jag ta ett sådant grepp omkring friidrottstävlingar. Jag har under några år varit engagerad i att arrangera friidrottstävlingar för Luleå Friidrottsförening som samlat utövare från de nordliga länen i Sverige och Finland. Jag har sett avsaknaden av ett funge-

Copyright © 2007 Frode Randers

När en tävlingen väl genomförs så har många timmar redan ägnats åt planering och förberedelser. Inför en tävling så måste ett antal faktorer vara uppfyllda. A. Bokning av resurser Arenan där tävlingen hålls måste bokas i tid. Ofta delar flera olika idrottsföreningar samma arena och man måste därför enas om när tävlingen kan hållas. Det kan finnas regler för hur bokningar görs; tidsgränser inom vilka man måste inkomma med bokning, förtursregler för vissa idrottsarrangemang etc. Idrottsföreningar inom samma förbund och samma distrikt försöker så långt det går att inte lägga tävlingar till samma tider eftersom man då tävlar om utövarnas uppmerksamhet. Ett misslyckande kan innebära att en tävling får dålig uppslutning och detta kan få ekonomiska konsekvenser för arrangören. Det lokala förbundet kan dessutom ålägga en förening att arrangera distriktsmästerskap inom vissa grenar i samband med en tävling. I samband med löpgrenar så använder man oftast en målkamera. Detta är idag datoriserade lösningar med kamera och tillhörande programvara som medger tidsupplösningar ner på hundradelar av en sekund. Eftersom en målkamera utgör en betydande investering så delar ofta flera olika föreningar på användandet, vilket betyder att användandet måste regleras genom bokning. Även här kan det finnas regler för hur bokning skall ske. Utöver målkameran så behöver man för löpgrenar också en starter som använder pistol med tidtagningsutrustning som kopplats till tidsmätningen i programvaran för målkameran. Längdhopp och sprintlopp som går på en långsida och som har fördel eller nackdel av att vinden blåser på ett visst sätt när hoppet eller loppet utförs måste använda en vindmätare för att kunna dokumentera en längd eller en tid med rådande vind. Både för målkamera, startarens pistol och vindmätaren så måste man utöver utrustningen också avtala tid med personer som utbildats i att använda utrustningen. För att eventuella rekord skall gälla utanför föreningen så måste man söka sanktion för tävlingen hos sitt förbund. Därigenom åtar man sig vissa förpliktelser som syftar till att

Sida 1 av 12

säkerställa kvalitén på resultatsmätning och genomförandet av tävlingen. Slutligen så måste man också boka in ett antal funktionärer, gärna bland föräldrar till utövare. B. Planering av tävling Förutom att en idrottsförening kan vara ålagd av sitt förbund att arrangera vissa grenar vid en given tävling, så ges det stora möjligheter att fritt sätta samman ett spännande program som lockar många utövare från ett stort område. Många tävlande medför å andra sidan problem med genomförandet av tävlingen eftersom varje tävlingsmoment1 tar längre tid och det uppstår beroenden mellan dessa utifrån utövarnas val av grenar. Olika idrottsarenor kan ha egna karakteristiska egenskaper som påverkar genomförandet; exempelvis få löparbanor som ger fler heat2, flera längdhoppsgropar som gör att man kan hoppa parallellt, etc. Utövare kan anmäla sig till en eller flera tävlingsmoment som påverkar möjligheten att parallellisera dessa. Utöver detta så finns det beroenden mellan grenar som också påverkar möjligheten att parallellisera tävlingsmoment. Man kan inte hålla ett 60 meterslopp samtidigt som ett 100 meters häcklopp eftersom dessa utnyttjar samma resurser; löparbana, starter, vindmätare och målkamera. Vidare kan samma utövare ha anmält sig till båda tävlingsmomenten. Detta är dock information som man ännu inte har vid planeringen av tävlingen. Så gott det går försöker man använda underlag baserat på erfarenhet och mätetal från tidigare tävlingar. Man fastställer också om man behöver göra avsteg från idrottsförbundets regelverk vid genomförandet av tävlingen. Man kan exempelvis välja att låta de yngsta utövarna få färre försök vid kulstötning - ett grepp man kan ta om man är rädd för att kulstötningen skall dra ut på tiden och försvåra schemaläggningen. Utöver detta tillkommer arbete med att få funktionärer till tävlingens olika grenar, sekretariat, prisutdelning, speaker etc. C. Utlysning av tävling När tävlingens sammansättning är klar så är det viktigt att snabbt få ut information till föreningar och utövare. I dagsläget anslås tävlingsinbjudan på den respektive föreningens hemsida och inbjudan skickas också ut till föreningar i när och fjärran. Fortfarande skickas en del inbjudningar via vanlig post och det är inte heller självklart att sändlistan för e-post är uppdaterad och aktuell. Speciellt mindre föreningar nås ofta genom respektive tränare som kanske endast har en otillförlitlig hotmail-adress. I detta sammanhang är det också viktigt att informera om eventuella avsteg från idrottsförbundets regelverk. Dessa anslås i ett s.k. PM som följer tävlingsinbjudningen. Regelverket kan också fastställa en kortaste anslagningstid 1. Med tävlingsmoment avses en specifik kombination av gren, kön och ålder; exempelvis längdhopp för flickor i åldern 10 till 11 år. 2. Med heat avses ett lopp i löpning. Regelverk avgör hur många heat som hålls och om semifinaler behövs.

Copyright © 2007 Frode Randers

inför en tävling; exempelvis för grenar som ingår i distriktsmästerskap. D. Hantering av anmälningar I samband med mottag av anmälningar så framgår det av tävlingsinbjudningen vilken tidsfrist som gäller. Anmälningar som inkommit efter tidsfristen belastas ibland med en förseningsavgift, men det sker ofta att man ser mellan fingrarna med detta. Erfarenhetsmässigt så ser man ofta förändringar nära inpå själva tävlingen orsakat av strykningar och efteranmälningar - ibland vid själva tävlingstillfället. Å ena sidan vill man hålla öppet för att så många som möjligt kommer och deltar på tävlingen och gärna i så många grenar som möjligt. Å andra sidan behöver man tid för att kunna lägga schemat före tävlingen och gärna med så korrekt underlag som möjligt. Ett IT-stöd skulle kunna underlätta denna hanteringen kraftigt genom att skjuta över bördan av att administrera anmälningarna på utövare och deras föreningar. Om anmälningar skickas som e-post eller fax så tillkommer administration på arrangörssidan för att validera uppgifterna samt mata in anmälningarna. Nummerlappar återanvänds ofta från en tävling till den nästa och med tiden så kan det bli “luckor” i nummerserierna. Vid tilldelning av nummer så är det önskvärt att systemet kan hoppa över nummerlappar som fattas. E. Schemaläggning av tävling Baserat på underlag från anmälningar, förbundets regelverk och eventuella avsteg från detta regelverk så upprättas ett schema för tävlingens genomförande. Detta schema behövs bland annat vid fördelning av arbete bland funktionärer och långväga tillresande utövare behöver i rimlig tid få veta när deras tävlingsmoment startar så att de kan planera sin resa och eventuellt boende. Schemaläggningen är ett flerdimensionellt problem som kräver både erfarenhet och tid. Eventuella misstag kan bli förödande om de inte upptäcks innan själva tävlingstillfället. I detta steg görs följande avväganden; •

Beroenden mellan grenar som inte kan köras samtidigt, exempelvis 60 meter sprint och 100 meter häcklopp. Dessa måste serialiseras.

•

Beroenden mellan olika åldersklasser3. Exempelvis får inte flickor 19 tävla samtidigt som pojkar 19 eller män eftersom de då får draghjälp. Å andra sidan kan pojkar 19 och män samtidigt springa ett 60 meters sprintlopp. Regelverk från förbundet ligger till grund för dessa avväganden.

•

Beroenden mellan olika tävlingsmoment. Exempelvis kan inte flickor 15 år samtidigt schemaläggas att stöta kula och hoppa höjd. Om å andra sidan ingen inom åldersklassen anmält sig till båda tävlingsmomenten, så kan dessa parallelliseras.

3. Med åldersklass avses en specifik kombination av kön och ålder; exempelvis flickor i åldern 10 till 11 år.

Sida 2 av 12

•

Utövare som deltar i äldre åldersklass. Det händer ibland att en yngre utövare vill tävla bland äldre (av samma kön), exempelvis om stavhopp arrangeras från 15 år och äldre och en utövare på 13 år också vill hoppa stavhopp. Om man tillåter detta så får med andra ord tävlingsmomentet stavhopp inte krocka med något tävlingsmoment som den trettonårige utövaren deltar i.

•

Riggning av löparbanor, exempelvis flytt av mikrofon för startern för olika långa lopp eller utplacering av häckar med olika höjd och olika avstånd (beroende på åldersklass). Det är önskvärt att försöka köra alla heat på en viss distans innan man flyttar starten.

•

Regelverket [1] anger kortaste tid som bör gå mellan två lopp i löpning för en åldersklass. För lopp på upp till och med 200 meter gäller 45 minuter och för lopp över 200 meter upp till 1000 meter gäller 90 minuter. För längre lopp gäller nästa dag.

•

Så långt det är möjligt så försöker man hålla samman tävlingen för de olika åldersklasserna så att det inte blir orimligt lång väntetid mellan tävlingsmomenten. Om man deltar i sitt första tävlingsmoment klocka 10:00 så skall man inte behöva stanna tills 17:00.

Denna typ av avväganden är till stor del rent mekaniska och kan med fördel automatiseras; det handlar bara om att hålla reda på uppgifterna, emedan andra avväganden svårligen fullt ut kan automatiseras. Till hjälp för schemaläggningen kan man använda mätetal från tidigare tävlingar på samma arena; dels för att uppskatta antalet deltagare och dels för att uppskatta tidsåtgång per deltagare. Detta ligger till grund för att uppskatta total tid för ett tävlingsmoment. Vid presentation av schemat så är det önskvärt att se detta ur två vyer; utövarens och funktionärens. Utövaren önskar se hur de egna tävlingsmomenten är fördelade över dagen. En tränare önskar se hur de olika åldersklassernas tävlingsmoment är fördelade över dagen (i praktiken samma vy, fast alla åldersklasser är representerade). En funktionär önskar se schemat orienterad utifrån gren för att se när hon behöver vara på plats och när man kan ta rast. Ett IT-stöd skulle kunna förenkla schemaläggningen avsevärt. Alla delar av schemaläggningen kan sannolikt inte automatiseras och måste sannolikt tillåta att man går in och samverkar med systemet för att komplettera. Den största vinsten skulle endock vara kvalitetssäkringen av schemaläggningen samt att denna kan initieras tätare inpå tävlingen, vilket återverkar på utövarna som får bättre tid på sig att anmäla sig och/eller ändra sina anmälningar. Ett stöd för planering och administration av funktionärer skulle också kunna åstadkommas. Föräldrar till utövare i den arrangerande föreningen skulle exempelvis kunna få teckna sig för funktionärsjobb och systemet skulle kunna välja tider som gör att föräldrarna får närvara när deras egna barn tävlar.

F. Genomförande av tävling Förtjusningen med en tävling är givetvis att man inte kan sia om utfallet. Detta har sin motsvarighet i att man exempelvis inte kan generera underlaget för tävlingens alla löpgrenar före tävlingstillfället. Teknikgrenar1 kan förberedas innan tävlingen genom att deltagarna till dessa är kända från anmälningarna - även om efteranmälningar förekommer. En efteranmälning i en teknikgren är å andra sidan inget större problem - dessa introducerar sällan extra hantering när det gäller tävlingens schema. När det gäller löpgrenar så är det litet mer dramatiskt. Beroende på loppets längd, om man startar i var sin bana eller om man startar i grupp, så får man ett beroende till antalet löparbanor. En efteranmälning kan komma att spräcka ett finalheat och introducera två försöksheat i tillägg till finalheatet. På samma sätt kan bortfallet av en utövare förenkla schemat. Av detta skäl brukar man tillåta efteranmälningar på plats så länge det finns platser kvar och man inte behöver introducera flera heat. Särskilda regler gäller för vem som går vidare från försöksheat och semifinaler baserad på tid och placering. Om det exempelvis är en till sex tävlande och sex löparbanor så blir det finalheat direkt. Om det råkar vara mellan 19 och 24 utövare så blir det fyra försöksheat och två semifinaler, där 2 går vidare till semifinal på placering (per heat) och 4 på tid (bland alla övriga deltagare i alla försöksheaten) och där 2 går vidare till final på placering (per semifinal) och 2 på tid i de båda semifinalerna. Vidare gäller särskilda regler [1] för tilldelning av löparbanor för deltagarna i ett heat som baseras på deras tidigare prestation (seedning). Som tumregel gäller att de bästa löparna får springa i mitten. För längre lopp med individuella löparbanor så försöker man dessutom så långt det är möjligt att undvika att placera löpare i bana ett (innersta banan). Sammantaget gör detta att man snabbt måste hämta in resultat och baserat på dessa producera heatindelningar i god tid innan nästa heat skall gå. För teknikgrenarna så handlar arbetet i sekretariatet snarare om att fortlöpande sammanställa och presentera resultaten. Under pågående tävling så måste man också genomföra prisutdelningar fortlöpande. Detta görs dels för att inte i onödan dra ut på tävlingen och dels för att utövare som endast deltar i några grenar inte skall behöva invänta hela tävlingens avslutande. Det kan vara svårt att under pågående tävling hitta lämpliga tillfällen att genomföra prisutdelningen, exempelvis beroende på om de olika prismottagarna i övrigt tävlar i olika grenar. Utövare, tränare och media vill också fortlöpande ha information om resultat, eventuella tangeringar eller sättande av rekord, dramatiska personliga förbättringar etc. Målfoto hanteras med fördel med dator där kamera och tillhörande programvara gör att man får tidsupplösning ner på hundradelar. Från målfotosystemet är det också möjligt att få ut information som kan hanteras elektroniskt. Samma sak gäller data från vindmätaren. Ett IT-stöd skulle förenkla genomförandet av tävlingen, 1. Med teknikgren avses hopp-, kast- och stötgren.

Copyright © 2007 Frode Randers

Sida 3 av 12

att hantera uppgifter om sina medlemmar, utövare kan erbjudas hjälp med att hålla reda på statistik etc. Medveten om att funktionärer ofta rekryteras bland föräldrar och med vetskap om vilka deltagare en funktionär vill kunna följa så är det också möjligt att delegera viss administrationen kring tjänstgöringsschema för funktionärer till funktionärerna själva. Med vetskap om när deltagarnas tävlingsmoment äger rum så kan systemet hjälpa funktionären att hitta lämpliga tider för tjänstgöring.

speciellt om man kan låta grenresultat matas in automatiskt i systemet. Detta öppnar också för att automatisera heatindelning och produktion av underlag för starter, vindmätare, speaker, målfoto etc. Till stora delar skulle ett automaticerat system ersätta sekretariatet och dessutom bistå de olika rollernas uppgifter med realtidsdata; exempelvis skulle speaker kunna rapportera om stora personliga förbättringar (även för utövare som inte hamnar på pallen) samt tangerade eller nya rekord.

IV. VERKSAMHETSARKITEKTUR

G. Uppsummering av tävling När väl tävlingen är över så kvarstår publicering av resultat till förbund, tidningar, föreningar och anslag på föreningens hemsida. När det gäller rapporteringen till förbundet så önskar de att få resultatet med särskild formattering och ordnat på ett enhetligt sätt. Den enskilde utövaren är intresserad i egna uppgifter, sannolikt också i delresultat som inte vanligtvis redovisas i resultatlistor.

För att något begränsa mängden begrepp samt för att försöka sätta dessa i sitt sammanhang så väljer jag att redovisa begreppen eftersom man möter dem när man rör sig genom vissa stadier; planering av tävling och genomförande av tävling. Först beskrivs dock aktörerna. A. Aktörer Aktörerna kan grovt indelas i resursägare, idrottsförbund, arrangörer, deltagare, föreningsföreträdare och publik. Dessa är inte ömsesidigt uteslutande. Resursägare omfattar, säg, kommunens fritidsförvaltning som äger och administrerar sportsarenorna i kommunen och (som i vårt fall) också äger målkamera med tillhörande utrustning. Idrottsförbundet fastställer reglemente för tävlingen och dess lokala representant i distriktet ger sanktion för tävling. Det är ett krav att alla deltagare genom sina respektive föreningar är anslutna till gällande förbund såvida inte tävlingen utlyses som öppen tävling. Arrangörer omfattar arrangörsmedlemmar såsom tävlingsledare, funktionärer och speaker. Deltagare omfattar utövare (enskilda tävlande) och i viss mån deras målsmän (föräldrar). Det är ett krav att utövare har ett medlemskap i en till rätt idrottsförbund ansluten förening bland annat ur försäkringssynpunkt. Föreningsföreträdare omfattar tränare (för utövare) och övriga administratörer i föreningen.

III. MÅL Målet med IT-stödet är att underlätta administration i dess olika moment i samband med friidrottstävlingar. Syftet är att så långt det är möjligt automatisera aktiviteter, att distribuera uppgifter som tidigare koncentrerats till en eller ett fåtal personer samt att slippa merparten av all pappershantering. Utöver detta så önskar vi förbättra möjligheten att samarbeta kring arrangemang av tävlingar mellan föreningar och distrikt samt underlätta rapportering av resultat. Eftersom det är nödvändigt att hålla ordning på deltagarna och deras föreningstillhörighet så måste det upprättas någon sorts register. För att underlätta inmatning och kontroll, exempelvis då en utövare anmäler sig till en tävling, så vore det önskvärt att så mycket information som möjligt redan finns tillgänglig i systemet. Detta kan åstadkommas genom att skapa ett incitament hos föreningar och utövare att själva registrera informationen; föreningar kan erbjudas hjälp med

Idrottsförbund är en

Föreningsföreträdare

Person

Resursägare

är en

är en

är en

Deltagare

Arrangör

Publikum

företräder är en

är en är en är en

Speaker

Tränare

Administratör

Övriga

är en

är en

Funktionär

Journalist

är en

Tävlingsledare Figur 1. Aktörer/roller

Copyright © 2007 Frode Randers

Sida 4 av 12

Publikum omfattar bland annat journalister (media) och övriga som önskar ta del av resultaten. En person kan dessutom inneha flera roller; exempelvis samtidigt vara tränare, deltagare och funktionär.

•

Gren, företrädesvis idrottsgren, som är tänkt att ingå i tävling, exempelvis kulstötning.

•

Reglemente [1], i detta fallet ett dokument fastställd av Sveriges Friidrottsförbund, för tävlingens genomförande - både i sin helhet men också gren för gren.

•

Resursregel som beskriver krav på en resurs, exempelvis markeringar för kulstötning i angränsning till kulstötningsring och som härrör från reglementet (ovan). En resurs kan omfattas av flera resursregler.

•

Grenregel som också härrör från reglemente (ovan). En gren kan omfattas av flera grenregler. I exemplet med kulstötning fastställs krav på vikt och storlek för kula (beroende på ålder och kön), antalet stötar mm.

•

Åldersklass är en specifik kombination av kön och ålder. Beroende på antal deltagare så kan en åldersklass omfatta fler än ett år, exempelvis skulle flickor i ålder mellan 8 och 9 år kunna ingå i åldersklassen F9 medan flickor i ålder mellan 10 och 11 ingår i åldersklassen F11 etc. Åldersklass beskriver ett glidande fönster över födelsedatum.

B. Planering av tävling Begrepp som vi möter i detta sammanhang är: •

Arrangör som planerar tävlingen och utför de bokningar som krävs hos kommunens fritidsförvaltning och övriga resursägare.

•

Tävling som arrangeras på en specifik arena vid ett fastställd datum eller över en period av dagar. En tävling kan vara sanktionerad av förbundet.

•

Arena är den plats där tävlingen äger rum.

•

Resursägare från vilken man begär och avtalar om nyttjande av arena och allokering av resurser.

•

Resurs som finns på arenan i form av tävlingsredskap eller byggnation, exempelvis kulstötningsring. Samma resurs kan användas för olika tävlingsmoment (dock inte samtidigt) och användandet av en resurs kan utesluta samtidigt användande av annan resurs (om de påverkar/inkräktar på varandra).

Resursägare administrerar

äger

{fritidsförvaltningen, ...}

Arena

har

påverkar

Resurs

{Skogsvallen, Arcus, ...}

{kulstötningsring, ...} har

bokar

nyttjar

Resursregel {markeringar, ...} härrör från

Arrangör {LFIF}

Gren {kulstötning, ...}

Reglemente (fastställd av förbund) härrör från

arrangerar

Kön

Datumspann

{man, kvinna}

{‘96 - ‘97}

Grenregel har

Datum {2007-01-28}

har

{vikt, storlek, antal stötar, ...}

har

Åldersklass {F11, P11, ...}

har

har

Tävling

har

Tävlingsmoment

består av

{F11 Kula, ...}

{Arcusspelen 2007}

har

har

har definierar

Sanktion

Utföranderegel

överrider

{3 stötar, 1 min/stöt, ...} definierar

Grenjämförelse {längst, högst, snabbast, ...}

Delmoment {försöksheat, semifinal, ...}

Försöksjämförelse {bäst av 3}

Figur 2. Begreppsmodell - planering av tävlingens sammansättning

Copyright © 2007 Frode Randers

Sida 5 av 12

Förening med bokningsbehov

Boka arena

Boka målkamera

Arena bokad

{Fritidsförvaltn.}

{Fritidsförvaltn.}

Kamera bokad

Idrottsförbund {samordning med andra föreningar}

Funktionärer bokade

Boka funktionärer

Boka starter

Starter bokad

{Egna föreningen}

{Idrottsförbund}

Figur 3. Processbeskrivning - Bokning av resurser

•

Tävlingsmoment är en specifik kombination av åldersklass och gren. Vi talar exempelvis om F11 Kula eller P13 Höjd.

•

Utföranderegel härleds från grenregel och beskriver de regler som ligger till grund för utförandet av ett specifikt tävlingsmoment på en tävling. För kulstötning så kan en grenregel säga att man har rätt till tre försök per stöt, men en utföranderegel (dvs en faktisk regel som används vid tävlingen) kan bestämma att man endast har rätt till två försök per stöt.

•

•

Försöksjämförelse kompletterar grenjämförelsen genom att utifrån utförandereglerna fastställa hur en enskild utövares försök skall jämföras för att fastställa resultat. I exemplet med kulstötning skulle detta vara bäst av tre.

Ett antal av dessa storheter definieras utifrån regelverk och varierar inte från en tävling till den nästa och inte heller mellan tävlingar på olika arenor. Endast avvik från regelverk behöver anges och dessa avviken måste redovisas i samband med inbjudning till tävlingen. Rörande processer vid planering av tävling så är speciellt bokning av resurser viktig eftersom denna involverar kontakter med externa entiteter såsom kommunens fritidsförvaltning (i vårt fall) och detta måste påbörjas runt sex månader före tävlingen.

Grenjämförelse anger hur resultat inom en viss gren för olika utövare skall jämföras med varandra, dvs vilka av storheterna längd, höjd eller tid som skall jämföras för att fastställa vem som hoppade/stötte/ kastade längst, hoppade högst eller sprang snabbast (på kortast tid).

Åldersklass {F11, P11, ...} har {kulstötning, ...}

tillhör

Tävlingsmoment

Gren

{F11 Kula, ...}

har

{namn, kvinna, fött ‘96}

har

Utföranderegel

definierar

definierar

Förening {LFIF}

avser avser

{3 stötar, 1 min/stöt, ...}

Grenjämförelse

är medlem i

Deltagare deltar i

Försöksresultat {5.00 m, 5.51 m, 5.24 m}

Försöksjämförelse

{längst, högst, snabbast, ...}

{bäst av 3} nyttjar

baseras på

Person ( deltagare / journalist / tränare / ... )

nyttjar

tar del av

Tävlingsmomentresultat

sammanställs från

Tävlingsresultat

Figur 4. Begreppsmodell - genomförande av tävling

Copyright © 2007 Frode Randers

Sida 6 av 12

Delmomentserie

Deltagare

Delmoment

har

{försök1, försök2, ..., final}

deltar i

{ försök1 } avser

avser har

Delresultat { 10.12 s } definierar deltagare i nästa delmoment

Tävlingsmoment {F11 60 m}

{namn, kvinna, fött ‘96}

Tävlingsmomentet har delats upp i sina delmoment som avklaras ett i sänder på ett rekursivt sätt (i enlighet med grenreglerna). När finalen hållits så är tävlingsmomentet avklarat och tävlingsmomentresultaten för samtliga deltagare sammanställs.

Försöksheat 1 baseras på

Försöksheat 2

Grenjämförelse {längst, högst, snabbast, ...}

nyttjar

Delmomentresultat

sammanställs från

}

Finalheat

Tävlingsmomentresultat

Figur 5. Begreppsmodell - genomförande av tävling i löpgrenar med försöks-, semifinal- och finalheat

C. Genomförande av tävling

•

I samband med att man modellerar själva genomförandet av tävlingen så dyker ytterligare begrepp upp (i första hand avser modellen teknikgrenar - löpgrenar tas upp litet senare):

En delmomentserie utgör ett sammansatt tävlingsmoment; exempelvis en serie av försöksheat, semifinalheat till det slutliga finalheatet.

•

Delmoment utgör en del av en delmomentserie, exempelvis ett försöksheat i en delmomentserie.

•

Delresultat utgör resultat för en enskild utövare i ett enskilt delmoment

•

Delmomentresultat baseras på en grenjämförelse mellan alla utövares delresultat i ett delmoment. Baserat på delmomentresultatet så väljs vilka utövare som går vidare till nästa delmoment i en serie.

• •

•

Utövaren anmäler sig för deltagande i ett eller flera tävlingsmoment. Utövaren är medlem i en förening. Försöksresultat mäts per utövare enligt de utföranderegler som gäller för tävlingsmomentet. Om resultatet avser finalheat i löpgren så motsvarar detta utövarens finalresultat - mer om detta nedan. Tävlingsmomentresultat baseras på försöksresultaten från alla utövare som deltagit i tävlingsmomentet. Utifrån regelverket i försöksjämförelsen beräknas varje utövares bästa resultat och utifrån regelverket i grenjämförelsen sammanställs tävlingsmomentets resultat genom jämförelser av deltagarnas bästa resultat.

•

Tävlingsresultatet för tävlingens samtliga tävlingsmoment sammanställs från de olika tävlingsmomentresultaten.

•

En person representerar alla aktörer som har intresse av att ta del av tävlingsresultatet - både under pågående tävling likväl som efter tävlingens avslutande.

Modellen som redovisas i figur 3 täcker dock inte löpgrenar om tävlingsmomentet delas upp i delmoment; försöksheat, semifinal, final. I detta fallet beräknas delresultat utifrån respektive delmoment och dessa ligger till grund för beslut om vem som går vidare från försöksheat till semifinal och slutligen final. I dessa fall bryts tävlingsmoment upp i en delmomentserie med delmoment som har delresultat och delmomentresultat.

Copyright © 2007 Frode Randers

V. STEGEN I ETT INFÖRANDE AV IT-STÖD Det finns några naturliga steg i införandet av ett IT-stöd: •

En distribution av administration av anmälningar syftar till att flytta över arbete och ansvar till den enskilde utövaren, dennas tränare eller föräldrar.

•

En automatisering av genomförandet av tävlingen syftar till att flytta över arbete och ansvar till funktionärerna för de olika tävlingsmomenten. Dessa får mata in resultaten allt eftersom tävlingen fortskrider och vi slipper därmed mycket av logistiken kring pappershanteringen.

•

En automatisering av rapportering syftar till att på olika sätt ge aktörer tillgång till resultatinformation allt eftersom tävlingen fortskrider. Detta förutsätter givetvis att informationen redan finns.

•

Stöd för att under pågående tävling hitta tillfällen för prisutdelning.

•

En automatisering av schemaläggning av tävling syftar till att (så långt det nu är möjligt) avlasta

Sida 7 av 12

nare i en förening att anmäla flera utövare utan att behöva känna till inloggningsuppgifter för den enskilde.

arrangören vid fastställande av tidschema. Eftersom människan som mest tycks kunna hålla mellan 5 och 9 saker i huvudet samtidigt och schemaläggningen har fler dimensioner, så är detta en intellektuellt krävande uppgift. •

För närvarande så förekommer inga önskemål för applikationsarkitekturen utöver kraven ovan.

Delegerad administration av tjänstgöring för funktionärer syftar till att flytta över arbete och planering till den enskilde funktionären.

B. Datamodell Datamodellen begränsas till de entiteter som är involverade vid administration av anmälningar (se figur 6).

VI. AVGRÄNSNINGAR För närvarande så gör jag följande avgränsning i det vidare arbetet med applikationsarkitekturen; jag väljer att koncentrera mig på distribution av administration av anmälningar. Övriga delar får tillkomma vid ett senare tillfälle. VII. APPLIKATIONSARKITEKTUR

C. Användningsfall Användningsfallen redovisas separat med början på sida 11. VIII. TEKNISK ARKITEKTUR A. Krav på tillgänglighet Följande krav ställs på tillgänglighet:

A. Krav och önskemål •

Följande krav ställs på applikationsarkitekturen: •

Personuppgiftslagen (PUL) måste följas. För den del av informationen som görs tillgänglig via Internet så måste antingen utövaren eller dennas förmyndare ha godkänt att informationen publiceras, alternativt måste viss information kunna döljas. Eftersom resultatinformationen vanligtvis publiceras i dagstidningar så är detta inte så kontroversiellt.

•

Identiteter måste kunna döljas. Det måste vara möjligt att markera att information om en viss deltagare inte får redovisas i resultatinformationen. Detta görs för att ta höjd för att ungdommar i familjer som lever med skyddad identitet inte skall kompromitteras i samband med fritidsaktiviteter.

•

Fastställande av identitet krävs (inom rimliga gränser) vid registrering av utövare. Vi behöver viss information såsom kön och ålder för att kunna deducera åldersklass för utövaren, men det är önskvärt att kunna hantera personnummer som primärnyckel för personen ifråga. Detta indikerar att någon sorts inloggningsförfarande krävs, men detta måste ändå tillhandahålla möjligheten för trä-

har

{F11, P11, ...} tillhör

*

Tävlingsmoment * {F11 Kula, ...}

Detta säkerställs genom att använda backup-nät, exempelvis ett (säkert) trådlöst nätverk om ett trådbundet nätverk strular. Vidare så används redundans på server-sidan för att hantera hårdvaruproblem och systemet använder transaktionshantering vid modifiering av data för att till varje tid hålla databasen konsistent. Slutligen så övervakas processen där man nyttjar information om när tävlingsmoment arrangeras och information om utövare för att se att resultat inkommer från funktionärsklient som förväntat. Funktionärer som matar in resultat från pågående tävlingsmoment bör ha företräde framför funktionärer som begär uttag av resultatlistor. Systemet måste därför kunna prioritera tjänster fortlöpande under drift beroende på dessa faktorer. Utöver detta så måste det finnas backuprutiner som tillåter att man faller tillbaks på pappershantering vid strömavbrott. Detta betyder att man som ett förberedande steg producerar pappersunderlag för varje tävlingsmoment som kan delas ut vid behov. Stödmaterial måste också skrivas ut som gör att sekretariatet endast behöver sammanställa resultat och skicka

1

Åldersklass 1

Under pågående tävling så måste systemet ha en tillgänglighet på 100%.

* deltar i

*

Deltagare

är medlem i

{namn, kvinna, fött ‘96} *

Förening 1

{LFIF}

* företräder

*

Föreningsföreträdare ( tränare / administratör )

Figur 6. Datamodell - Administration av anmälning

Copyright © 2007 Frode Randers

Sida 8 av 12

ut underlag för tävlingsmoment som består av serier av delmoment (exempelvis löpargrenar med flera heat). B. Krav på modifierbarhet Följande krav ställs på modifierbarhet: •

Det måste vara möjligt att enkelt registrera nya funktionärsklienter i nätverket. I den mån det krävs installation av klientprogramvara så skall denna vara enkel. Orsaken till detta är att vi sannolikt kommer att vara beroende av att låna datorer, gissningsvis av funktionärerna själva.

•

Det måste vara möjligt att lägga till flera skrivare om utskrift visar sig vara en trång sektor. Systemet måste förstå hur det kan nyttja flera skrivare, alternativt att reservera skrivare för utskrifter med högre prioritet.

•

Om topologin i systemet måste ändras under drift, så skall funktionärsklienterna kunna hitta servern utan att konfigurationen måste ändras i klienten.

•

På serversidan måste konfigurationen kunna ändras under drift utan att systemet måste återstartas.

•

Så långt det är möjligt bör man eftersträva asynkrona kopplingar mellan komponenterna för att inte fördröjningar skall propageras vidare i beroendehierarkin.

C. Krav på skalbarhet

Det finns en viss motstridighet i kraven här. Funktionärsklienterna bör synkront rapportera resultat till server för att säkerställa att data inte förloras samtidigt som de skall få underlag för att rapportera resultat för nästa utövare. För att underlätta skalbarhet så bör dock funktionärsklienterna så långt det är möjligt återanvända information och inte i onödan “besvära” servern. Kraven på säkerställande av information överväger dock. D. Krav på säkerhet Följande krav ställs på säkerhet: •

Säker inloggning från funktionsärsklient till server för autenticering av användare. Det borde räcka med passordshantering i detta läget, speciellt eftersom arrangören har kontroll över antal och identitet för de olika funktionärerna. Det skall dock inte gå att avlyssna lösenord vid inlogging.

•

Det krävs en rollbaserad behörighetshantering där administratörer av systemet kan auktorisera roller och användare.

•

Säker kommunikation mellan funktionärsklient och server. Det skall inte gå att introducera en icke-auktoriserad funktionsärsklient i systemet. Det skall inte gå att påverka resultatinformationen som rapporteras in till server.

•

Servermiljön skall vara intrångsskyddad.

•

Nätverket i systemet skall vara isolerad från Internet under tiden som tävlingen pågår för att inte riskera DOS-attacker under pågående tävling. Det bör dock finnas möjlighet att rapportera progress till komponenter som befinner sig utanför tävlingsnätverket. Enklast kan detta lösas genom att placera nätverket bak en brandvägg och endast tillåta trafik ut från en serverkomponent som har till uppgift att rapportera progress.

•

Om ett trådlöst nätverk används för att binda ihop funktionärsklienterna med server, så måste hänsyn tas till att inte tillåta att icke-auktoriserade klienter får registrera sig i det trådlösa nätverket. Det är att föredra att använda trådbundet nätverk för att minimera risk för belastningsattacker.

•

Om systemet kompromitteras så skall det vara möjligt att återkoppla resultat till viss funktionär och viss funktionärsklient. Det skall också vara möjligt att se när resultatet rapporterats. Om intrång gjorts vid en känd tidpunkt så skall det (förhoppningsvis) vara möjligt att identifiera vilka resultat som kan anses vara giltiga och vilka som beläggs med osäkerhet.

•

Det bör vara möjligt att “signera” inmatade resultat med någon storhet så att man inte i eftertid kan gå in och ändra i databasen över historiska resultat på ett icke-befogat sätt. Vi önskar dels förhindra detta, men framför allt att upptäcka att sådana ändringar

Följande krav ställs på skalbarhet: •

Det skall vara möjligt att parallellt hantera ett antal funktionärsklienter.

•

Det måste vara möjligt att definiera prioritet för olika funktioner i systemet. Exempelvis är rapportering av progress mindre viktigt än att funktionärsklienterna skall kunna rapportera resultat. Vidare är presentation av resultat för utövarna själva mindre viktig än presentation av resultat för speaker och prisutdelare.

•

Serverprogramvaran måste vara flertrådad (vilket nästan är svårt att undvika med gängse ramverk).

•

Bakgrundsaktiviteter, som till exempel progressrapportering och rapportering till speaker och prisutdelar, måste kunna skeduleras, alternativt initieras utifrån händelser och kanske också köer för processning.

•

Det är önskvärt att kunna drifta systemet som en nättjänst. Detta kan innebära att planering och förberedelser görs mot nättjänsten, varifrån man gör en export till tävlingssystemet.

•

För att uppnå en så stor frikoppling mellan klient och server som möjligt, så bör funktionärsklienten vara autonom, dvs inte ett webbgränssnitt mot en webbserver, och använda ett gränssnitt, exempelvis ett Web Services-baserat gränssnitt, mot servern

Copyright © 2007 Frode Randers

Sida 9 av 12

ägt rum. Detta skulle kunna vara checksummeberäkningar på enskilda resultat eller på det totala tävlingsresultatet, som sedan signeras på något sätt. •

Ändringar eller justeringar av resultat loggas.

E. Krav på testbarhet Följande krav ställs på testbarhet: •

•

•

Det måste vara möjligt att under drift gå in och utföra uppgifter, exempelvis att registrera resultat, som inte skall redovisas. Tanken med detta är att tillåta diagnosticering av systemet eller testning av funktion/algoritm. Det måste också vara möjligt att slänga sådana testdata. Systemet skall utvecklas testdrivet. Automatiserade tester (testsuiter) skall tas fram i framkant av implementationsfasen och användas för validering under utveckling och förvaltning. Detta öppnar för automatiserade regressionstester. Särskilda testgränssnitt bör byggas in i systemet för att underlätta testning under drift, diagnosticering vid problem och larm vid upptäckt av problem under drift.

F. Krav på användbarhet

I båda fallen kan klientprogramvaran nyttja SOAP-anrop mot ett Web Services-gränssnitt på servern. För enklare gränssnitt, exempelvis för att ta del av resultaten så skall en klassisk webbapplikation användas med ett HTML-baserat gränssnitt. Detta skall dock byggas med Facelets, som är en förfining av Java Server Faces. En relationsdatabas skall användas som datalager och ett visst oberoende av leverantör skall eftersträvas. Persistenshantering av objekt skall så långt det är möjligt automatiseras, vilket innebär att ett O/R-verktyg skall användas. Företrädesvis används Java på serversidan, men inte Enterprise Java Beans et al. H. Modell

Publik server

Klientplattform

Webbgränssnitt

GUI GUI GUI

Affärslogik O/R (Hibernate)

Affärslogik Cache (basinfo)

Databas Export/import

WS-klient

Följande krav ställs på användbarhet: •

•

Systemet måste vara anpassat för de olika rollererna som är aktuella. Så långt det är möjligt så skall det grafiska gränssnittet vara anpassat enbart för den uppgift som användaren behöver utföra, allt för att vara så enkelt som möjligt. En användare som har flera roller måste kunna komma åt alla uppgifter som är relevanta, exempelvis genom att kunna välja roll i systemet och röra sig mellan dessa rollerna.

•

Det måste vara möjligt att ångra felaktiga inmatningar.

•

Det måste vara möjligt att i efterhand justera inmatade resultat, antingen i anslutning till tävlingsmomentet av funktionärerna eller senare av administratörer.

•

Brandvägg Tävlingsserver Progressmodul WS-gränssnitt Affärslogik O/R (Hibernate) Databas

Importmodul Rapportmodul Delmomentseriesmodul

Figur 7. Model

REFERENSER [1] Svenska Friidrottsförbundet, ”Tävlingsregler för friidrott”, 2007.

Det måste vara möjligt att avbryta om man gjort felaktiga val, exempelvis av delmomentserie för löpargrenar med flera heat.

G. Övriga icke-funktionella krav För att bygga en autonom klient som kan erbjuda ett rikt användargränssnitt och därigenom kunna bygga de rollspecifika användargränssnitten, så tar jag sikte på att använda Adobe FLEX. Klienter som byggts med FLEX kan både laddas ner via en webbläsare och köras i en Adobe Flash plugin eller deployas på Adobe AIR (tidigare känd under namnet Apollo) som är en runtime-miljö som kan installeras fristående.

Copyright © 2007 Frode Randers

Sida 10 av 12

IX. ANVÄNDNINGSFALL I föreliggande fall så har tävlingsmomenten redan definierats i samband med att tävlingen planerades, så dessa användningsfall tar utgångspunkt i att en eller flera utövare skall registreras för deltagande i tävlingsmoment. Användningsfall: Anmäla deltagande i tävlingsmoment Aktör: Deltagare (utövare, tränare, förälder) Beskrivning: En registrerad deltagare väljer tävlingsmoment som hon vill tävla i och anmäler sig till dessa. Startvillkor: Aktören måste vara autenticerad (och därmed också känd av systemet). En tränare måste ha valt vilken utövare som han vill företräda (anmäla). Tävlingsmomentet måste finnas definierad med angiven gren och åldersklass i aktuell tävling. Resultat: Aktören har anmält deltagande i ett (eller flera) tävlingsmoment. Händelseflöde: 1. Aktören väljer tävling. 1a. Om aktören är en utövare så svarar systemet med att visa alla tävlingsmoment inom den åldersklass som deltagaren tillhör. Systemet visar också tävlingsmoment för äldre åldersklasser (men samma kön) för grenar som inte finns representerade för den aktuella åldersklassen. 1b. Om aktören är en tränare så svarar systemet med att visa alla utövare i den förening som tränaren företräder och markerar vilka som redan anmälts till tävlingen. I detta fallet måste deltagaren välja vilken utövare som skall anmälas. 2. Aktören “bockar för” alla tävlingsmoment som hon vill anmäla sig till och skickar (submittar) anmälningen till systemet. Systemet svarar med att visa alla tävlingsmoment som deltagaren har anmält sig till, men också tävlingsmoment som deltagaren kan välja ytterligare. 3. Aktören väljer att avsluta. 3a. Om aktören är en utövare så loggas utövaren ut 3b. Om aktören är en tränare (eller föreningsföreträdare) så visas en lista över övriga utövare i föreningen som (inte ännu) anmälts till tävlingen. Användningsfall: Avanmäla deltagande i tävlingsmoment Aktör: Deltagare (utövare, tränare, förälder) eller arrangör Beskrivning: En registrerad deltagare eller arrangör avanmäler en utövare från en (eller flera) tävlingsmoment. Startvillkor: Aktören måste vara autenticerad (och därmed också känd av systemet). En tränare måste ha valt vilken utövare som han vill företräda (anmäla). En arrangör måste ha valt vilken utövare som han vill avanmäla. Resultat: Aktören har avanmält deltagande i ett (eller flera) tävlingsmoment. Händelseflöde: 1. Aktören väljer tävling. 1a. Om aktören är en utövare så svarar systemet med att visa alla tävlingsmoment som utövaren har anmält sig till. 1b. Om aktören är en tränare så svarar systemet med att visa alla utövare i den förening som tränaren företräder och markerar vilka som anmälts till tävlingen. I detta fallet måste tränaren välja vilken utövare som skall avanmälas. 1c. Om aktören är en arrangör så svarar systemet med att visa alla föreningar som anmält sig till tävlingen. Arrangören måste då välja förening och sedan vilka utövare som skall avanmälas. 2. Aktören “bockar bort” alla tävlingsmoment som hon vill avanmäla sig från och skickar (submittar) avanmälningen till systemet. Systemet svarar med att visa alla tävlingsmoment som användaren har anmält sig till, men också tävlingsmoment som deltagaren kan välja ytterligare. 3. Aktören väljer att avsluta. 3a. Om aktören är en tränare (eller föreningsföreträdare) så visas en lista över övriga utövare i föreningen 3b. Om aktören är en arrangör så visas en lista över övriga föreningar som anmälts till tävlingen.

Flera användningsfall finns givetvis, men jag väljer att sluta här.

Copyright © 2007 Frode Randers

Sida 11 av 12

Copyright © 2007 Frode Randers

Sida 12 av 12