APPLIKATION FÖR SAMORDNING AV ENTREPRENÖRER

Examensarbete 15 högskolepoäng C-nivå APPLIKATION FÖR SAMORDNING AV ENTREPRENÖRER Reg.kod: Oru-Te-DT3017-D106/08 Daniel Lindqvist Dataingenjörsprogrammet 180 hp Örebro vårterminen 2008 Handledare: Kjell Mårdensjö Examinator: Lars Karlsson APPLICATION FOR COORDINATION OF CONTRACTORS Örebro universitet Örebro University Institutionen för teknik Department of Technology 701 82 Örebro SE-701 82 Örebro, Sweden

Sammanfattning Denna rapport beskriver utvecklingen av en applikation för samordning av entreprenörer vid Outokumpu Stainless AB:s anläggning i Avesta, kallat Avesta Works. Målet var att skapa en bättre, och mer användarvänlig applikation än den som redan fanns inom företaget. Applikationen ska innehålla funktioner för att registrera entreprenörsarbeten inom Avesta Works, samt möjlighet att följa upp dessa. Syftet är att kunna följa upp vilka personer och vilka entreprenörer som befinner sig på området, och i slutändan få en säkrare arbetsmiljö Systemet består av ett användargränssnitt i form av en webbapplikation på företagets intranät, utvecklad i ASP.NET med C# i botten, en MS SQL Server databas, och ett serviceinterface i form av en WCF-service. Uppdraget bestod även av att testa en arkitekturmodell, som är framtagen av Outokumpu IT Delivery. Arkitekturen består av fem lager, i botten ett dataaccesslager, ett affärslager, ett fasadlager, ett servicelager och ett presentationslager på toppen. Abstract This paper describes the development of an application for coordination of contractors at Outokumpu Stainless AB s facilities in Avesta, known as Avesta Works. The assignment was to create a better and user-friendlier application than the one that already existed within the company. The applications main abilities should be to register and follow up coordinations. The purpose is to have knowledge about the work that is being executed by entrepreneurs within Avesta Works, and to know who s working for those entrepreneurs. This should hopefully, in the end, result in a safer working environment. The system consists of a user-interface in shape of a web-application which can be found on the company s intranet, developed with ASP.NET and C#, a SQL Server database and a service interface in shape of a WCF-service. The assignment was also to test a new architecture, which is created by Outokumpu IT Delivery. The architecture consist of five layers, with a data access layer in the bottom, a business layer, a façade layer, a service interface layer and on top a user interface. 2(24)

Förord Detta examensarbete är en del av min ingenjörsutbildning inom Datateknik vid Örebro Universitet. Arbetet är på C-nivå och omfattar 15 hp. Jag skulle vilja tacka Outokumpu Stainless som gett mig möjligheten att utföra detta examensarbete. Ett speciellt tack vill jag rikta till Kristoffer Rönnberg och Michael Carlborg som tagit sig tid att bistå med information. Avesta den 3 juni 2008. Daniel Lindqvist 3(24)

Innehållsförteckning 1 Inledning...5 1.1 Företaget...5 1.2 Syfte...5 2 Systemkrav...6 2.1 Funktionella krav...6 2.2 Icke funktionella krav...6 3 Teoretisk bakgrund...7 3.1.NET Framework...7 3.2 ASP.NET...7 3.3 C#...8 3.4 OR Mapping...8 3.5 LINQ...9 3.6 Windows Communication Foundation...10 3.7 AJAX...11 4 Genomförande...12 4.1 Utvecklingsmiljö...12 4.2 Arkitektur...13 4.2.1 Data Access Layer...14 4.2.2 Business Layer...14 4.2.3 Facade Layer...14 4.2.4 Service Interface...14 4.2.5 User Interface...15 4.3 Databasdesign...16 4.3.1 Job...17 4.3.2 Contractor...17 4.3.3 Person...17 4.3.4 Location...17 4.3.5 JobLabor...17 4.3.6 Checklist...17 4.3.7 JobMeasure...17 4.4 Webbapplikationen...18 4.4.1 Söka samordningar...18 4.4.2 Skriva ut en samordning...18 4.4.3 Registrera samordning...19 4.4.4 Redigera/Kopiera samordning...21 4.4.5 Administrationsgränssnitt...21 4.5 Val av OR Mapper...22 5 Slutsats...23 6 Referenser...24 4(24)

1 Inledning 1.1 Företaget Outokumpu är ett internationellt företag som tillverkar rostfritt stål. Kunderna finns i många branscher - från processindustrin och industriella maskiner till byggnad och konstruktion och elektrisk industri, transport, elektronik och informationsteknik samt catering och hushåll. Outokumpu verkar i omkring 30 länder och sysselsätter 8 000 personer. Under 2007 uppgick koncernens försäljning var EUR 6,9 miljarder, varav cirka 95% genererades utanför Finland. Koncernens huvudkontor ligger i Esbo, Finland. Moderbolaget, Outokumpu Oyj, har varit noterat på Helsingfors fondbörs sedan 1988 Outokumpus fabriker i Finland, Sverige, Storbritannien och USA producerar ett brett sortiment av rostfria produkter, inklusive varmvalsat och kallvalsat, precision band, rör och långa produkter tillsammans med ett omfattande utbud av rördelar, flänsar och svetsning Outokumpus anläggning i Avesta, kallat Avesta Works, sysselsätter omkring 1000 personer. I Avesta specialiserar man sig på specialstål, främst breda produkter och så kallade duplexa stålsorter. Outokumpu IT Delivery är en serviceorganisation som är gemensam för hela koncernen. I Avesta arbetar ca 60 personer inom ITD, och totalt inom koncernen är det ca 170 personer. Man räknar med att inom kort anställa ytterligare ett 30-tal personer. 1.2 Syfte Syftet med detta är examensarbete är att säkerställa vetskap om vilka entreprenörsjobb som utförs inom ett specifikt område på Outokumpus anläggning i Avesta. Detta ska åstadkommas genom att utveckla en webapplikation som ska finnas tillgänglig via Avesta Works intranät. I applikationen ska användarna kunna registrera och följa upp samordningar. En samordning är något som görs för att organisera inblandade parter i det jobb som ska utföras. Man anger bl.a. var arbetet ska utföras, vem som utför jobbet, vilken tidpunkt det sker och man gör också riskbedömning och planering. Förutom själva applikationen ska även en ny arkitektur prövas. Arkitekturen är framtagen av Outokumpu IT Delivery men har hittills inte realiserats i någon konkret applikation som är avsedd för produktion. Syftet med arkitekturen är att skapa ett standardiserat sätt att bygga skalbara system, som är enkla att förvalta, underhålla och ansluta andra system till. 5(24)

2 Systemkrav Följande krav har ställts på applikationen. Dessa punkter är resultatet av en inledande workshop där beställare och samordnare runt om i verksamheten har deltagit. 2.1 Funktionella krav En samordning ska innehålla information följande: arbetsbeskrivning, beställare, samordnare, entreprenör, tidpunkt, personal, ev. arbetsorder, bryt & lås, larmpunkt, riskbedömning och planering. Samordningen ska sparas elektroniskt i sin helhet, och den ska vara redigerbar. Skulle samordningen behöva ändras så ska det kunna göras utan att det blir en reviderad utgåva. Förutsättningen är att startpunkten för arbetet inte startat. Om en samordning ändras under arbetets, exempelvis p.g.a. förändrade risker, ny personal etc. så ska det framgå att det är en reviderad utgåva. Samordningen ska finnas tillgänglig även efter samordningens avslut. Det ska finnas ett administrationsgränssnitt för uppdatering och hantering av samordnare, beställare, placeringar, risker, planer och annat som kan tänkas behöva uppdateras. Vid datumfält ska det finnas möjlighet att välja datum ur en kalender. Man ska med andra ord inte behöva bry sig om att mata in rätt datumformat. En möjlighet ska finnas att skriva ut samordningen, samt en lista på samordningar. Det ska gå att söka samordningar på beställare, samordnare, placering eller via fritext sök. Under Riskbedömning och Planering ska det, om man kryssat Ja, dyka upp en textruta där man ska förklara vad man tänkt vidta för förebyggande åtgärd. 2.2 Icke funktionella krav Förbättrat workflow, möjlighet att navigera mellan sidorna. Det ska vara enkelt och man ska inte tappa inmatade data när man navigerar tillbaka. Applikationen ska finnas tillgänglig, och hittas med enkelhet, via Avesta Works intranät. 6(24)

3 Teoretisk bakgrund I detta kapitel beskriv de olika teknikerna som jag använt mig av i utvecklingen av applikationen. 3.1.NET Framework.NET Framework är ett samlingsnamn för Microsofts senaste plattform för utveckling av applikationer. Det är en språkoberonde plattform och kommer med en stor mängd av klassbibliotek som är tillgängligt för alla.net kompatibla språk. Det spelar därför inte så stor roll om man programmerar i C#, Visual Basic, eller något annat kompatibelt språk. Det som krävs för att utveckla en.net applikation är en kompilator som översätter koden till så kallad MSIL, MicroSoft Intermediate Language. IL är bytekod och den kompileras vid körning JIT (Just In Time), precis som Java. Men till skillnad från Java så används ingen virtuell maskin för detta utan istället kompileras bytekoden till maskinkod av något som kallas CLR, Common Language Runtime. CLR hanterar bl.a. garbage collection och kodsäkerhet. Det tveklöst största utvecklingsverktyget för.net är Microsofts egna IDE (Integrated Development Environment), Microsoft Visual Studio.NET. Applikationen i detta projekt använder sig av.net Framework 3.5 [1][2] 3.2 ASP.NET ASP.NET är en teknik för att skapa dynamiska webbsidor, webbapplikationer och webservices. Precis som det låter är detta en anpassning av ASP för.net plattformen. ASP.NET är baserat på Common Language Runtime (CLR) och det innebär att man kan utveckla ASP.NET kod med något av de många.net kompatibla språken. Man slipper därmed skriva med inbäddade skriptspråk, och använder istället exempelvis C# för att skriva code behind. I detta projekt är användargränssnittet utvecklat i ASP.NET. [3] Se nedanstående exempel: namespace SamO.WWW { public partial class Register : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) {... 7(24)

3.3 C# C#, eller C Sharp som det är uttalas är själva flaggskeppet i.net plattformen och ses som dess kärnspråk. C# är utvecklat av Microsoft och chefsdesigner är Anders Hejlsberg som tidigare har jobbat med Turbo Pascal, J++ med flera. Språket utvecklades i samband med.net plattformen och är baserat på C++, men har även hämtat mycket ifrån andra språk, där Java och Delphi märks tydligast. Den största skillnaden mot dess föregångare C++ är troligtvis att det har automatisk skräpinsamling (garbage collection) och avsaknaden av pekare. [4] Nedan visas ett kodexempel för klassiska Hello World : using System; namespace HelloWorld { class Hello { public static void Main() { Console.WriteLine("Hello World!"); } } } I detta projekt är all kod, utom det statiska i användargränssnittet, skrivet i C#. 3.4 OR Mapping OR Mapping står för Object Relational Mapping och brukar ibland förkortas som O/RM. O/RM är en teknik för att mappa/konvertera entiteter mellan en relationsdatabas och ett objektorienterat programmeringsspråk. I och med denna mappning skapas ett så kallat dataaccesslager mot databasen. Man kan se detta lager som en virtuell objektdatabas. Anledningen till att man i så stor utsträckning använder sig av O/RM är att det finns en enorm klyfta mellan dagens moderna programmeringsspråk som är objektorienterade, och de databaser som vi lagrar informationen i. Data representeras som objekt i dagens programmeringsspråk, medan de i databasen representeras av rader i en, eller flera, tabeller. En O/RM hjälper till med det mödosamma arbetet att skapa relationerna mellan dessa två olika tekniker, genom att automatiskt skapa mappningen mellan en databas och dess tillhörande applikation. Den hjälper även till med att omvandla förändringar av data hos ett objekt i applikationen, till SQL operationer för att åstadkomma samma förändringar i databasen. Man brukar säga att den skapar så kallade CRUD metoder. CRUD står för Create Read Update och Delete och skulle då motsvara Insert, Select, Update och Delete i en relationsdatabas. Nedanstående bilder visar OR mappern LINQ to SQL (se mer om LINQ och LINQ to SQL i nästa kapitel). Det är denna OR mapper som används i detta projekt för att generera dataaccesslagret. Designläget visas i bilden till vänster, och till höger en del av den kod som skapas automatiskt av OR mappern. 8(24)

Kritiker menar dock att man med hjälp av OR mappers försöker lösa fel sida av problematiken mellan relationsdatabasen och objektmodellen. De menar att den objektorienterade modellen är otillräcklig som sådan för att fullt ut kunna täcka behoven av att manipulera data. En del kritiker menar också att man i många fall sätter arbetet av en databasadministratör, som optimering och prestanda, i skymundan. Dock går utvecklingen snabbt framåt och OR mappers blir bättre och bättre på att effektivisera komplexa SQL operationer. Ett annat problem är hur olika OR mappers hanterar cachning av objekt. Ofta har man cachat objekt för att få snabbare svarstider, som kanske i själva verket inte behöver. Problemen uppstår om det har skett en förändring på motsvarande objekt (rad) i databasen. När man i programmet hämtar om objektet så får man ett cachat objekt som är likadant som det första man hämtade, alltså som det såg ut innan förändringen gjordes. [5][6] I detta examensarbete har jag provat två stycken olika OR Mappers, dessa är LINQ to SQL och LINQ to LLBLGEN. Mer om det kan läsas i kapitel 3. 3.5 LINQ LINQ står för Language Integrated Query och uttalas Link. Det är en del av.net ramverket och släpptes först i och med version 3.5. Med LINQ kan man på ett enhetligt sätt, med hjälp av så kallade query operators, ställa frågor mot Arrays, Enumerable-klasser, relationsdatabaser, XML och andra datakällor. Det kräver dock att datat man frågar emot är inkapslat i ett objekt. Med andra ord om man vill fråga mot en relationsdatabas så måste man först göra en mappning mellan relationsdatabasen och programkoden. Detta görs förslagsvis med en OR Mapper (se föregående kapitel).[7] Nedanstående är ett exempel på LINQ som är hämtat ur samordningsapplikationen. LINQ används flitigt i applikationen för frågor mot olika typer av datakällor. Här används det för att hämta alla entreprenörer. var q = from c in objcontractormgr.getallcontractors() select new ContractorSC { ContractorID = c.contractorid, Name = c.name, Phone = c.phone }; return q.tolist(); 9(24)

LINQ Providers är specifika implementeringar som anpassar LINQ-frågorna för olika datakällor. Det finns en uppsjö av dessa och bland några kan nämnas: LINQ to SQL Som både konverterar LINQ till SQL Server-specifik SQL och fungerar som O/RM. LINQ to Google För Google-sökningar. LINQ to SharePoint Som används för Microsofts collaboration-verktyg SharePoint. 3.6 Windows Communication Foundation Windows Communication Foundation, förkortat WCF, är ett ramverk som skeppades med.net Framework 3.0. Det används för att skapa serviceorienterade applikationer (SOA). WCF binder samman en mängd olika tekniker som.net Remoting, COM+, MSMQ, Webservices med flera. WCF kan användas för att kommunicera SOAP-meddelanden (SOAP är ett protokoll för XML-meddelanden) mellan två processer, vilket gör WCF-applikationer kompatibla med alla processer som kommunicerar via SOAP. När en WCF process kommunicerar med en annan typ av process, används istället XML-baserad kodning för SOAP-meddelanden. När det kommunicerar med en annan WCF processen kodas SOAPmeddelandena i ett optimerad binärt format. Båda kodningarna överensstämmer med den datastruktur av SOAP-format, kallad Infoset. WCF kan även användas via protokoll som TCP, HTTP, MSMQ och Named Pipes. En WCF Service består av tre delar - en serviceklass som implementerar den tjänst som skall tillhandahållas, en mottagande miljö som ska fungera som värd för tjänsten, och en eller flera endpoints som klienterna ansluter till. All kommunikation med en WCF tjänst sker via endpoints. En endpoint innehåller ett servicekontrakt som definierar vilka metoder som finns tillgängliga via den. Varje endpoint kan ha egna uppsättningar av metoder. De definierar också en binding som anger hur en klient ska kommunicera med tjänsten och en adress där endpointen driftas. WCF tillhandahåller Windows Service Activation som kan användas för att köra tjänsten som en vanlig Windows-service. En WCF tjänst kan också driftas i IIS eller i någon process med hjälp av ServiceHost-klassen, som tillhandahålls av WCF. De kan också drifta sig själva, i form av en konsoll-applikation eller en Windows Form.[8][9] I detta projekt används WCF för att exponera de funktioner som är implementerade i fasadlagret (se kap. 4.2 angående arkitektur). På så vis kan även andra system, få tillgång till informationen. 10(24)

3.7 AJAX Asynchronous JavaScript And XML, AJAX, är en samling av tekniker som används för att skapa interaktiva webbtillämpningar. Ett syfte med AJAX är att skapa bättre interaktivitet för webbsidor genom att det sker en del utbyte av data bakom kulisserna så att hela webbsidor inte måste laddas varje gång det finns ett behov av att hämta data från servern. Detta kan öka en webbapplikations prestanda, interaktivitet och funktionalitet. Ajax är som det säger asynkront på så sätt att allt som tas emot inte behöver reflekteras i webbsidan. Ajax anrop görs normalt via JavaScript. Data hämtas med hjälp av XMLHttpRequest-objekt Ajax är en plattformsoberoende teknik som är baserad på öppna standarder som DOM och JavaScript. Den kan därför användas på många olika operativsystem, datorarkitekturer och webbläsare.[10] 11(24)

4 Genomförande I detta kapitel beskrivs design och arkitektur, utvecklingsmiljö samt den resulterande applikationen. 4.1 Utvecklingsmiljö Utvecklingsmiljön som använts i projektet är uppsatt i en virtuell pc för att få en avskärmad miljö som är enkel att återställa vid eventuella problem. Det är också en ren miljö där endast de nödvändiga applikationerna är installerade. Följande programvaror har använts under utvecklingen: Microsoft SQL Server 2005 Microsoft Visual Studio Team System 2008 Development Edition Linq to LLBLGen Pro 2.6 Beta LINQPad StarUML 12(24)

4.2 Arkitektur Arkitekturen består av en 5-skikts lösning som är framtagen av Outokumpu IT Delivery. Det här projektet är det första som använder sig av denna lösning. Arkitekturen består i denna applikation av en SQL Server 2005 databas i botten, en webbapplikation skriven i ASP.NET 3.5 med C#, och en WCF-service som webbapplikationen kommunicerar med för att hämta och skriva data. Koden för affärslogiken är skriven i C#. Arkitekturmodell 13(24)

4.2.1 Data Access Layer Detta lager sköter all kommunikation med databasen. Dataaccesslagret är automatiskt genererat av en OR Mapper, i denna applikation är det gjort med hjälp av LINQ to SQL. Här finns alla entiteter mappade samt funktioner som skapar SQL-kommandon för att läsa, skriva och uppdatera poster i databasen. 4.2.2 Business Layer I Business Layer finns alla grundläggande metoder, t.ex. att läsa alla poster från en tabell i databasen, att redigera en post och att ta bort och lägga till. All kommunikation mot databasen går via underliggande lagret DAL. Metoder som hämtar något returnerar en IQueryable<T> av aktuell typ. Det betyder att själva frågan mot databasen inte körs i detta läge, den skapas bara och returnerar själva frågan. Ett BusinessContract innehåller attributen, eller fälten hos aktuellt objekt. 4.2.3 Facade Layer I fasadlagret finner man affärslogiken. Här finns metoder som exempelvis att hämta en specifik samordning, med tillhörande placering. Eftersom placering på en samordning (tabellen Job), är en foreign key till tabellen Location, så sätter man här en relation mellan två stycken funktioner som returner IQueryable<T> i where-villkoret. Det kan se ut enligt följande: public IList<JobPresSC> getjobwithlocation(guid JobID) { var q = from j in objjobmgr.getalljobs() from l in objlocationmgr.getalllocations() where j.locationid == l.locationid && j.jobid == JobID select new JobPresSC {... }; return q.tolist(); } Här returneras en lista av servicekontrakt (se mer i kap. 5.2.4). Det är först när frågan returneras och man kör.tolist() på den som frågan verkligen körs mot databasen. Den går då via BL och DAL för att konverteras till SQL-kod. Man brukar kalla detta förskjuten exekvering. 4.2.4 Service Interface I detta lager exponeras alla interface via en WCF-service som körs som en standard Windows Service. Via olika slutpunkter (i WCF-termer endpoints ) får man sedan tillgång till de funktioner som gränssnittet exponerar. Man kan själv bestämma om dessa ska köras via SOAP, Http, eller något annat protokoll. I detta projekt sker kommunikationen via Http. 14(24)

Ett så kallat ServiceContract bestämmer vilka metoder som ska finnas tillgängliga via en endpoint, och ett DataContract innehåller vilka attribut som finns tillgängliga för aktuellt objekt. 4.2.5 User Interface I User Interface lagret finner man det grafiska gränssnittet som presenteras för användaren. Detta lager brukar på svenska kallas presentationslager. Det kan bestå av exempelvis en Windows Form eller en webbapplikation, eller i andra fall både och. Eftersom det mesta av logiken ligger i fasadlagret så kan man relativt enkelt byta ut detta om sådant fall skulle uppstå. I samordningsapplikationen används som beskrivet tidigare en webbapplikation i detta lager. Webbapplikationen hämtar och skriver data via WCF-servicen och dess slutpunkter som exponerar funktionaliteten. Detta kan göras enligt följande där jag hämtar alla placeringar: SILocationMgrClient locclient = new SILocationMgrClient(); LocationSC[] loc = locclient.getalllocations(); locclient.close(); 15(24)

4.3 Databasdesign När jag modellerade databasen strävade jag hela tiden efter att göra den, tillsammans med applikationen, så flexibel som möjligt. Tabellerna ska helst inte behöva växa på bredden, d.v.s. man ska inte behöva lägga till ytterligare en kolumn för minsta ändring. Ett exempel på detta är tabellen Checklist. Checklist innehåller alla checklistpunkter som ska fyllas i för varje samordning. Dessa skulle kunna ligga i huvudtabellen jobb, med en kolumn för varje punkt, men det hade inneburit en hel del extra arbete då en punkt skulle tas bort eller läggas till. Nu skapas istället alla checklistpunkter dynamiskt i webbapplikationen genom att läsa den tabellen. När man kryssat i en punkt i checklistan ska man dessutom fylla i en åtgärd, dessa sparas i tabellen JobMeasure. På så vis kan man enkelt via ett administrationsgränssnitt lägga till eller ta bort punkter från checklistorna. Databasmodell 16(24)

4.3.1 Job Innehåller alla övergripande detaljer för en samordning. Några exempel är; Arbetsbeskrivning, start- och slutdatum, huvudentreprenör, samordnare, beställare o.s.v. 4.3.2 Contractor Innehåller alla företag som är godkända för arbete inom Avesta Works. 4.3.3 Person Innehåller alla personer som är samordnare eller beställare (flaggor anger vilken typ). 4.3.4 Location Innehåller en struktur som anger platser som arbetet kan utföras på. Den är av hierarkisk struktur genom att den har en kolumn Parent som anger förälder. Genom att skapa tabellen på sådant sätt kan jag även via en rekursiv funktion i applikationen bygga upp en grafisk trädstruktur med hjälp av en TreeView-komponent. 4.3.5 JobLabor Innehåller personal hos antingen huvudentreprenör, eller personal som i sin tur hyrts in av huvudleverantör. Här lagras bl.a. vilket jobb de är inne på, namn och vilket företag de tillhör. 4.3.6 Checklist Innehåller alla checkpunkter för en samordning. Dessa kan vara av typerna Risk eller Planering. 4.3.7 JobMeasure Innehåller åtgärder för varje punkt (ifrån checklist) som anses vara en risk eller något man bör planera inför jobbet. 17(24)

4.4 Webbapplikationen Webbapplikationen kommer att finnas tillgänglig via Avesta Works intranät. I detta kapitel beskrivs de olika delarna i applikationen. 4.4.1 Söka samordningar Det första man möts av i applikationen är en lista av samordningar. Listan visar som standard alla aktiva samordningar. Det går att söka på beskrivning, placering, entreprenör, beställare och samordnare. Ifrån listan kan man också välja att visa detaljer, redigera eller kopiera en samordning. 4.4.2 Skriva ut en samordning Ifrån listan kan man välja Visa. Man får då upp en utskrivbar sida som innehåller de flesta detaljer om en samordning. Vid klick på skrivarikonen öppnas en standard utskriftsdialog och skrivarikonen som man klickade på försvinner vid utskriften. 18(24)

4.4.3 Registrera samordning Under menyvalet Skapa ny samordning kan man registrera en ny samordning. Registreringsformuläret är uppbyggt av en AJAX-komponent, TabContainer, som i sin tur består av flera Tabs (flikar). Detta gör att man kan dela upp formuläret på ett smidigt sätt, och som dessutom gör att man på ett enkelt sätta kan gå framåt och bakåt i formuläret. Detta är annars ett vanligt problem man har i webbapplikationer när man försöker skapa ett naturligt workflow. Om man då är tvungen att hoppa mellan olika sidor så måste man hantera att data förloras i så kallade postbacks. Vid val av plats klickar man på den lilla ikonen till höger om texten Ingen plats vald!. Det öppnas då en AJAX Modal Popup. I denna dialog visas platser i form av en trädstruktur. Trädstrukturen skapas dynamiskt genom en rekursiv funktion som läser innehållet i tabellen Locations. Det blir därför enkelt den dagen man vill lägga till eller ta bort platser. 19(24)

Datumfälten styrs även de av en AJAX-komponent, Calender. Så fort man ställer sig i något av datumfälten dyker en kalender upp. Med kalendern är det enkelt att hoppa mellan olika månader och år, man säkerställer dessutom att datumen blir i rätt format. Under fliken Personal lägger man till namn, personnummer och företag på de personer som kommer att utföra arbetet. I flikarna Riskbedömning och Planering finns checklistor med risker och planer som ska hanteras. Klickar man i en riskpunkt dyker det automatiskt upp en ruta där en åtgärd måste fyllas i. Alla punkter och komponenter i dessa checklistor genereras dynamiskt. Det blir på så vis enkelt att lägga till eller ta bort punkter i listorna. När man har matat in alla uppgifter för sin samordning går man till sista fliken Spara. Vid klick på OK valideras alla fält som är obligatoriska. En summering av felen visas, och man kan även se respektive fel vid dess fält. 20(24)

4.4.4 Redigera/Kopiera samordning Via listan av samordningar kan man även välja att redigera eller kopiera en samordning. För dessa ändamål har jag återanvänt formuläret för registrering av samordningar. På så sätt blir det enklare att administrera/utveckla då förändringar endast behöver utföras i ett enda formulär. Att man har möjlighet att kopiera en samordning beror på att en entreprenör ofta återkommer och gör liknande, eller kanske ett exakt likadant, arbete men kanske vid en annan tidpunkt eller med annan personal. Man slipper då skriva om hela samordningen, utan kan istället gå in och ändra på exempelvis start och slutdatum. Det går naturligtvis även att ändra all annan data för aktuell samordning. 4.4.5 Administrationsgränssnitt Via administrationsgränssnittet kan man hantera följande: Administrationen kommer att skyddas av ett befintligt autentiseringssystem kallat Avesta Web Login. Personer Lägga till eller ta bort (inaktivera) personer. Ändra en persons egenskaper, samordnare och beställare. Platser Lägga till nya placeringar och ändra namn på befintliga. Entreprenörer Lägga till, ta bort (inaktivera), eller ändra namn på företag. Checklistor Lägga till eller ta bort (inaktivera) punkter under Riskbedömning och Planering. 21(24)

4.5 Val av OR Mapper I den arkitektur som beskrivs i föregående kapitel ska en OR-mapper användas för att generera ett s.k. dataaccesslager. En OR-mapper används för att mappa entiteter i databasen till objekt i koden. (se mer om detta i kap. 3.4). Eftersom arkitekturen är ny och inte helt fastställd så fick jag i uppdrag att testa OR Mappern Linq to LLBLGen Pro 2.6 (hädanefter LLBLGen Pro). LLBLGen Pro är en OR-mapper som är framtagen av Solutions Design. Fördelen med denna är att den har stöd för de flesta databaser, och den ska vara aningen snabbare än Microsofts egna produkt (LINQ to SQL). Den är även flexibel på sådant sätt att det går att modellera i designern för produkten. Det går att sätta upp arv mm direkt i GUI:t. Den version av LLBLGen Pro som jag använde mig av befann sig dessvärre fortfarande i betastadiet. Tidigare version hade inte stöd för LINQ och var därför inte ett alternativ. Till en början verkade allt fungera som förväntat, jag satte upp ett exempelprojekt och skapade en konsollapplikation där jag via lager-arkitekturen kunde utföra CRUD- (Create Read Update Delete) operationer. Problem uppstod dock när jag skulle börja skapa relationer (joins) mellan mina entiteter. Det visade sig att det ännu inte fanns stöd för att göra detta mellan flera funktioner som returnerar IQueryable<T>. Eftersom det fortfarande var några veckor kvar till releasen av den färdiga produkten, och därmed risk att försena projektet, så var jag tvungen att se mig om efter andra alternativ. Valet föll då på Microsofts egna produkt LINQ to SQL. Fördelarna med LINQ to SQL är den redan finns inkluderad i utvecklingsmiljön Microsoft Visual Studio 2008. Det finns också en hel del dokumentation att tillgå. Nackdelen är att den än så länge inte stöder någon annan databas än SQL Server. Eftersom både LLBLGen Pro och LINQ to SQL använder sig av en LINQ provider så är det relativt enkelt att bara byta ut dataaccesslagret som skapas av dessa OR-mappers. Det blev därför en ganska enkel uppgift att byta ut LLBLGen Pro mot LINQ to SQL. Väl utbytt så fungerade relationerna utmärkt. Vidare så kommer det förhoppningsvis även att vara en relativt enkel operation att byta ut LINQ to SQL mot framtida verktyg som t.ex. LINQ to Entities som är Microsofts kommande OR-mapper. 22(24)

5 Slutsats Resultatet av detta examensarbete är en väl fungerande applikation för samordning av entreprenörer med avseende på uppställda mål och förväntningar. Alla krav (anges i kap. 2) är idag uppfyllda. I skrivandets stund återstår testning och produktionssättning av applikationen, men det är och var planerat senare än slutdatumet för detta examensarbete. Administrationsgränssnittet ska också skyddas av ett behörighetssystem kallat Avesta Web Login, men eftersom gränssnitten för det systemet inte är klara förrän om ett par veckor har det inte kunnat implementeras. Det kommer dock att göras innan produktionssättningen av applikationen. Något som kunde ha gjorts lite bättre är kanske designen. Jag har inte haft så mycket tid som jag önskat att lägga ner på form och design, men jag anser ändå personligen att resultatet blev godkänt. Utvecklingsmöjligheterna är många. Eftersom interfacen exponeras av en WCF-service så öppnar detta för att även andra system skulle kunna hämta eller skriva data till applikationen. Ett önskemål om vidareutveckling är att integrera detta system till ett som hanterar körkort för skydd och säkerhet. Det finns idag ett krav att alla entreprenörer som arbetar inom området ska ha genomgått en kurs. Man skulle då kunna slå upp personnumret på aktuellt personal mot detta system och på så vis direkt kunna se om personen i fråga har genomgått denna kurs. Tyvärr är dock inte det systemet moget för en sådan integration ännu. Man skulle också kunna tänka sig en integration mot verksamhetssystem Maximo som används på orten. I Maximo hanterar man bland annat arbetsorder, och de kan i många fall vara relaterade till en samordning i denna applikation. Mindre förändringar som att lägga till eller ta bort punkter på checklistor, hantera platser osv. är väldigt enkla att genomföra eftersom allt sådant skapas dynamiskt. Det sparar både tid och pengar i förvaltningen av applikationen. Applikationen använder sig även av väldigt ny och modern teknik, vilket gör den relativt framtidssäker. Jag använder ordet relativ då utvecklingen går så otroligt snabbt framåt. Vad gäller den arkitektur som testats i detta projekt så återstår det fortfarande att se hur den klarar belastningen när den kommer ut i produktionsmiljö. När det gäller den initiala utvecklingen av en applikation så blir det en del extra arbete med den typ av struktur som denna arkitektur har, så var också fallet i detta projekt, men jag tror att man i det långa loppet kommer att tjäna på det med tanke på den skalbarhet arkitekturen innebär. Jag har någonstans läst att man med ett serviceorienterat angreppssätt får lägga till ca 30 % tid i den initiala utveckling men att har igen det mångdubbelt redan de första åren. Om det visar sig att arkitekturen håller även i produktionsmiljö så kommer jag varmt rekommendera att man fortsätter använda sig av denna. Eftersom jag tidigare inte hade jobbat med många av teknikerna som används i detta arbete så har jag även fått ut en hel del själv av examensarbetet. 23(24)