REDUNDANSELIMINERING VID SAMMANSTÄLLNING AV DATA

Examensarbete 10 poäng C-nivå REDUNDANSELIMINERING VID SAMMANSTÄLLNING AV DATA Reg.kod: Oru-Te-EXD083-D105/04 Jonas Samuelsson och Fredrik Svensson Dataingenjörsprogrammet 120 p Örebro vårterminen 2004 Examinator: Jack Pencz ELIMINATION OF REDUNDANCY WHILE ASSEMBLING DATA Ö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 sammanställning av tidsstudier, utfört på uppdrag av Consulting AB Lennermark & Andersson. Uppdraget var att utveckla en applikation som skall hantera snarlika poster i en databas. Applikationen förenklar arbetet och ger stor vinning i tid vid analysarbetet och efterarbetet av tidsstudier. Med hjälp av applikationen kan användaren på ett enkelt sätt modifiera de snarlika posterna. Abstract This report describes the development of an application used to assemble time studies, commissioned by Consulting AB Lennermark & Andersson. The assignment was to develop an application that handles similar posts in a database. The application simplifies the work and leads to big time profits in the analysis and after work of time studies. The user can in a simple way modify these similar posts by using the application. -1(23)-

Förord Vi vill tacka Consulting AB Lennermark & Andersson (CAB) för att vi fick möjligheten att genomföra vårt examensarbete hos dem. Speciellt vill vi tacka IT-avdelningen för deras goda omhändertagande av oss studenter. Att få göra examensarbete hos CAB har varit mycket lärorikt och inspirerande. Vi vill särskilt tacka följande personer: Sara Kjäll - Mentor, CAB Per Bergholm - Handledare, CAB Niclas Nilsson - Tekniker, CAB Gunnar Joki - Handledare, Örebro Universitet Christer Löwdahl - IT-chef, CAB Johan Rundberg - Systemutvecklare, CAB Örebro den 6 maj 2004 Fredrik Svensson Jonas Samuelsson -2(23)-

INNEHÅLLSFÖRTECKNING 1 INLEDNING... 5 1.1 Syfte... 5 1.2 Bakgrund...5 1.3 Uppdrag... 5 2 METOD... 8 2.1 Utvecklingsmetod/modell... 8 3 VERKTYG... 9 3.1 Microsoft dotnet Framework... 9 3.2 Microsoft Visual Studio dotnet... 9 3.3 Microsoft Visual SourceSafe... 9 3.4 Microsoft SQL Server 2000... 9 3.5 C#... 10 3.6 ADO.NET... 10 4 GENOMFÖRANDE... 11 4.1 Studie av tidsstudieprogram... 11 4.2 Användningsfallsspecifikation... 11 4.3 Grafiskt gränssnitt... 11 4.4 Arkitektur... 12 4.5 Design av databas... 14 4.6 Kodning... 15 4.7 Systemtestning... 18 4.8 Överlämnande av det färdiga systemet... 18 5 RESULTAT... 19 5.1 Användargränssnitt... 19 6 DISKUSSION... 22 6.1 Förbättringar... 22 6.2 Egna reflektioner... 22 7 KÄLLFÖRTECKNING... 23 7.1 Böcker... 23 7.2 Internetadresser... 23 7.3 Övrigt... 23-3(23)-

FIGURFÖRTECKNING Figur 1.1: Utdrag ur Excel-ark.... 6 Figur 4.1: De olika skikten i projektet... 12 Figur 4.2: Tabeller som vi har skapat och lagt till i databasen... 14 Figur 4.3: Datatypen DataSet... 15 Figur 4.4: Exempel på DataGrid.... 16 Figur 5.1: Hela programfönstret... 19 Figur 5.2: Översiktsläget... 20 Figur 5.3: Redigera objekt... 20 Figur 5.4: Redigering av objektets delar.... 21 BILAGOR 1. Projektdirektiv 2. Systemutvecklingsprocess 3. Användningsfallsspecifikation -4(23)-

1 Inledning 1.1 Syfte Syftet med detta examensarbete var att skapa ett verktyg som underlättar och sparar tid i analys- och efterarbetet av tidsstudier. Från företagets sida ville man även att vi med detta projekt skulle få en inblick i hur det går till att utveckla ett system, från första mötet med beställarna till överlämnandet av det färdiga systemet. 1.2 Bakgrund 1.2.1 Consulting AB Consulting AB (CAB) är ett nischföretag, och har sitt huvudkontor i Örebro. Deras speciella system tar fram tidsunderlag för reparation av bilar, vilka sedan används för att utveckla program som kalkylerar kostnaderna för bilreparationer. För att ta fram tidsunderlagen utför CAB bland annat tidsstudier ute på verkstäder. Deras kunder består av biltillverkare runt hela världen, försäkringsbolag i Europa och bilverkstäder, huvudsakligen i de nordiska länderna. Här följer några exempel på hur användare/kunder använder CAB:s system: Försäkringsbolagen använder deras system som grund för upphandling och administration av bilskador. Bilverkstäder använder deras system för att kalkylera och offerera bilreparationer. När en bilfabrikant tar fram en ny bilmodell används deras system för att utvärdera alternativa konstruktionslösningar ur reparationssynpunkt. 1.3 Uppdrag 1.3.1 Problem Resultatet av tidsstudien presenteras i ett Excel-ark, som genereras utifrån utseendet i en databas. Om flera poster i databasen är exakt likadana, representeras dessa poster endast en gång. När det däremot skiljer mellan posterna, t.ex. att den ena postens namn är Bakdörr och den andras namn är bakdörr (med litet b), kommer båda med. Fram till idag så har denna redundans åtgärdats manuellt genom att ta bort de snarlika raderna i Excel-arket. Vid borttagandet av en post så måste tiden, som tillhör posten, läggas till en annan befintlig post. Detta arbete upplevs krångligt och tidskrävande. 1.3.1.1 Orsak till problem Tidsstudier innebär att man på verkstäder följer verkstadsarbetare (en tidsstudieman följer en verkstadsarbetare) i deras arbete och registrerar tiden på varje moment de utför. Data sparas i databaser på flera bärbara datorer, en databas per tidsstudieman. Flera tidsstudiemän jobbar parallellt och efter tidsstudiens slut sammanställs all data från samtliga databaser till en databas, som ligger på en lokal server hos CAB. Tidsstudierna görs med hjälp av ett egenutvecklat program. Vid tidsstudier ska en mängd olika egenskaper sparas för varje bildel som verkstadsarbetaren arbetar på (påbörjad, avslutad, lös detalj, material, yta etc.). Eftersom flera verkstadsarbetare kan komma att jobba med samma bildel, så måste tidsstudiemännen skriva exakt samma -5(23)-

egenskaper på bildelen för att det ska bli exakt likadana poster i databasen, vilket det ska vara. Det enda som ska skilja posterna åt är vilket moment som är genomfört och den nerlagda tiden. Om två poster skiljer sig åt på en eller flera egenskaper kommer den att stå som två rader i Excel-arket. I exemplet (se Figur 1.1) finns t ex Sidodörr fram över list på tre rader (7, 8 och 10). Det enda som skiljer raderna 7 och 8 åt är sidangivelsen, den ena är markerad som vänster och den andra som höger. Den här typen av redundans är korrekt och skall inte tas bort, då man förmodligen har arbetat med både höger och vänster framdörr. Om man istället jämför raderna 8 och 10 är det endast egenskapen Finished som skiljer. Här kan det mycket väl vara så att två tidsstudiemän har satt olika värden på samma bildel. Dessa båda rader ska alltså egentligen bara vara en. Observa att de tider som är knutna till varje bildel inte kunde åskådliggöras i detta exempel på grund av utrymmesskäl. Figur 1.1: Utdrag ur Excel-ark. 1.3.2 Mål Utveckla en användarvänlig applikation som sammanställer valda poster i databasen, från flera snarlika poster till exakt likadana poster enligt användarens önskemål. 1.3.3 Krav Följande krav har ställts av uppdragsgivaren: Enkelt att använda. Inga tider får ändras eller gå förlorade. Inga data från databasen får förstöras. Inga val ska göras av programmet, användaren står för allt beslutsfattande. Användaren arbetar mot ett objekt i taget. Flera rader ska kunna läggas ihop till en. När rader läggs ihop ska tiderna alltid adderas. När rader läggs ihop ska användaren kunna välja vilka egenskaper som ska flyttas med från de gamla raderna till den nya. Användaren ska kunna välja om en post representerar en lös detalj. Skall till viss del klara av att antalet egenskaper och/eller verktider ändras från studie till studie. Skall klara av förändringar av tidsstudieprogrammet i viss mån. Ändringar av tiden ska inte kunna göras från programmet. Det ska finnas möjlighet att ångra tidigare ändringar, objekt för objekt eller hela databasen. Användaren ska kunna söka på objektnummer. Rader och objekt ska kunna förses med flaggor (osäker/färdig). Det första valet som görs på ett objekt är om det är påbörjat resp. avslutat eller inte. Vid sammanslagning av mycket olika objekt ska en varning visas. När val om påbörjat resp. avslutat objekt sker ska användaren kunna välja vilka tider som ska visas för att underlätta beslutsfattandet. -6(23)-

1.3.4 Åtgärd Planer finns inom företaget att använda en gemensam databas för samtliga tidsstudiemän. Detta projekt har dock skjutits på framtiden på grund av tidsbrist samt av ekonomiska skäl. Vårt uppdrag var att utveckla en applikation som hanterar posterna i databasen. Användaren skall kunna modifiera posterna i databasen så att problemet med snarlika poster försvinner. När användaren är klar med modifiering av databasen, med hjälp av vår applikation, generas Excel arket. Förhoppningen är att vårt program ska spara mycket tid i analysfasen av de tidsstudier som är utförda.bilaga 1 innehåller projektdirektiven för projektet. -7(23)-

2 Metod 2.1 Utvecklingsmetod/modell Den modell vi har använt för att utveckla detta projekt är en nedbantad version av den utvecklingsmodell som CAB använder sig av. Modellen är uppdelad i ett antal aktiviteter. Varje aktivitet ger ifrån sig ett resultat. En aktivitet har också ett drivobjekt knutet till sig som gör att aktiviteten kan starta. Att använda denna utvecklingsmodell bidrar till: Ett iterativt arbetssätt. Projektet får en objektorienterad syn på systemutveckling. Förändrad kravbild kan hanteras. Systemets kvalitet kan kontinuerligt verifieras mot såväl arkitektur som slutanvändaren. Under arbetet, utifrån denna modell, kommer man att iterera mellan de olika stegen. Om det visar sig att man måste göra om designen av databasen, eller att det kommer in nya önskemål angående funktionaliteten, backar man tillbaks till motsvarande steg i modellen. Detta upprepas till ett acceptabelt resultat har uppnåtts. För en mer detaljerad beskrivning se Bilaga 2. -8(23)-

3 Verktyg Inom CAB används i huvudsak Microsofts produkter, t.ex. SQL Server 2000. Företaget har nyligen gått över till att jobba med Microsofts dotnet som plattform. När CAB realiserade denna förändring så började man programmera i C# istället för som tidigare i Visual Basic (VB). Vid utvecklandet av detta projekt var det naturligt för oss att använda de verktyg som företaget använder sig av. 3.1 Microsoft dotnet Framework Microsofts dotnet är en ny mjukvaruplattform. Med hjälp av det inbyggda stödet för XMLwebbtjänster kan olika program kommunicera med varandra och dela data, oavsett operativsystem och programmeringsspråk. Plattformen Microsoft dotnet innehåller en serie produkter som bygger på XML och branschstandarder för Internet. Detta underlättar för alla moment i utvecklingen, hanteringen och användningen av webbtjänster. 3.2 Microsoft Visual Studio dotnet Vi har under detta projekt jobbat i utvecklingsverktyget Microsoft Visual Studio dotnet (VS). I VS kan man i samma gränssnitt utveckla lösningar i ett flertal olika språk som C++, C#, VB eller J#. 3.3 Microsoft Visual SourceSafe Microsoft Visual SourceSafe är ett program för versionshantering av filer. Med hjälp av detta program kan flera utvecklare jobba med samma projekt och alltid ha tillgång till den senaste versionen av alla filer. Dessutom minskas risken att utvecklare ska skriva över varandras ändringar, genom att en fil endast är tillgänglig för redigering av en person åt gången. 3.4 Microsoft SQL Server 2000 SQL Server 2000 är Microsofts flaggskepp bland databashanterare och deras kraftfullaste databas. Dess prestanda tillsammans med kostnaden har gjort SQL Server till den mest använda databashanteraren bland de IT-företag som använder Windows NT/2000. (Waymire, Richard och Sawtell, Rick - 2001) 3.4.1 Microsoft SQL Server Enterprise Manager SQL Server Enterprise Manager (SSEM) är verktyget som används för att implementera och modifiera databasen. I SSEM får man en god överblick över sin databas med tabeller, vyer och lagrade procedurer. 3.4.2 Microsoft SQL Query Analyzer SQL Query Analyser (SQA) är ett program som används för att ställa frågor mot databasen. Vi skapade lagrade procedurer i SSEM och kontrollerade att proceduren gav önskat resultat med hjälp av SQA. SQA användes också för att utveckla SQL frågor, som sedan användes i de lagrade procedurerna. -9(23)-

3.5 C# Programmeringsspråket C# härstammar från C och C++, men skapades helt från grunden och är helt anpassat till dotnet-plattformen. Microsoft började med det som fungerade i C och C++ och la sedan till nya funktioner som skulle göra C# lättare att använda. Vid skapandet av detta språk, har man undanröjt några av svårigheterna med att lära sig ett programmeringsspråk, bland annat har man plockat bort makron, mallar och multipelt arv. Precis som andra programmeringsspråk kan C# användas för att skapa en mängd olika typer av applikationer. Att språket kan användas till så skilda projekt som dynamiska webbsidor, utvecklingsverktyg och till och med kompilatorer visar på att C# är kraftfullt och flexibelt. (Jones, L Bradley - 2002). 3.6 ADO.NET ADO.NET är samlingsnamnet på klasserna som används i C# och Microsoft dotnet Framework för att komma åt data i tabellformat. Data kan finnas i relationsdatabaser, t.ex. SQL Server eller i andra datakällor. ADO.NET är integrerat i dotnet Framework och är utformat för att användas med dotnet-språken och då särskilt med C#. -10(23)-

4 Genomförande 4.1 Studie av tidsstudieprogram Som ett första steg i examensarbetet fick vi sätta oss in i hur det egenutvecklade programmet, som används vid tidsstudierna, fungerar. Det Excel ark som programmet genererar, utifrån innehållet i databasen, presenterades också. Detta för att få förståelse om varför problemet med upprepade och snarlika poster uppstår. 4.2 Användningsfallsspecifikation Under en av de första dagarna hölls ett möte med beställarna av systemet (CAB:s tekniker). De hade en genomgång av hur de ville att vår applikation skulle fungera i stort. Med detta möte som underlag kunde en användningsfallsmodell/specifikation, Bilaga 3, utformas. 4.3 Grafiskt gränssnitt Med användningsfallsspecifikationen och beställarnas önskemål som underlag utformade vi det grafiska gränssnittet. När gränssnittet var färdigutvecklat fick beställarna ge sitt godkännande innan vi gick vidare till nästa steg i utvecklingsprocessen. Utvecklingen av gränssnittet är ett steg i utvecklingsprocessen som man återkommer till vid flera tillfällen under projektets utveckling. -11(23)-

4.4 Arkitektur Innan vi började utforma arkitekturen hade vi programmerat en del, bland annat vid utformandet av den grafiska prototypen. Detta gjordes under den första tiden av exjobbsperioden. Avsikten med denna prototypprogrammering var att få en uppfattning om vilka skikt/klasser som kan behövas i utvecklandet av applikationen. Vid det här stadiet i projektet hade vi en god bild av hur applikationen skulle fungera och komma att användas. Programmeringsmässigt delas koden/klasserna in i olika skikt beroende på vad de har för funktion. Vi har valt att använda oss av tre skikt enligt Figur 4.1. Web GUI:t allt som hör till utseendet (interface) Business Logik här finns alla beräkningar (intelligens) Figur 4.1: De olika skikten i projektet. Pilarna i figuren visar hur kommunikationen sker mellan skikten och mellan skiktet DataAccess och databasen. Varje skikt kan ses som ett delprojekt som sedan inkluderas till ett projekt. Detta innebär att man kan jobba med ett delprojekt i taget. Att arbeta med detta upplägg bidrar till att flera systemutvecklare kan jobba parallellt och man får en objektorienterad syn på hela projektet. Vi valde att bygga på dessa skikt steg för steg. -12(23)-

4.4.1 DataAccess DataAccess skiktet är kopplingen till en datakälla som i vårt fall är en databas. Tanken med att jobba objektorienterat innebär att om datakällan byts ut, behöver endast det här skiktet förändras. I DataAccess-skicktet sker all kommunikation med databasen. Databaskommunikationen innebär framför allt två saker: Hämta data från databasen. Spara/Uppdatera data till databasen. 4.4.2 Business I detta skikt finns all logik. Här sker alla beräkningar och all manipulation av data. De data som skall manipuleras hämtas initialt via DataAccess-skiktet. Business-skiktet har kopplingar både till DataAccess-skiktet och till Web-skiktet, vilket medför att Business-skiktet är länken mellan dessa skikt. 4.4.3 Web/GUI Översta lagret i arkitekturen är själva användargränssnittet som är uppbyggt med WinFormskomponenter. De data som ska presenteras fås via Business skiktet. I detta lager finns även den logik som krävs för att bygga själva användargränssnittet samt för att reagera på händelser i det. -13(23)-

4.5 Design av databas Ett framfört krav var att inga data i databasen fick gå förlorade. För att förhindra detta så skapade vi egna tabeller (se Figur 4.2) som vi fyllde med de data som var intressanta för vår applikation. Vid start av programmet fylls dessa tabeller med data från andra tabeller i databasen. I applikationen jobbar vi sedan endast mot dessa tabeller. Det är endast i dessa tabeller som användaren ser till att det inte finns lika och snarlika rader/poster. På detta sätt har vi säkerställt att orginaldata aldrig ändras eller förstörs. Dessutom kan användaren alltid återställa de objekt han/hon arbetar med om så skulle behövas. Figur 4.2: Tabeller som vi har skapat och lagt till i databasen. -14(23)-

4.6 Kodning Utan att gå in för mycket på kodningsdetaljer följer här några rader om hur vi har löst projektet på kodningsnivå. Här tar vi upp för programmet viktiga och intressanta datatyper och delar. Framför allt har vi valt att redovisa hur kommunikationen med databasen har implementerats. 4.6.1 DataSet Det är DataSet (se Figur 4.3) som är den kanske viktigaste delen av vår applikation. DataSet är en datatyp som vi har använt till att fylla med data från vår datakälla (databasen). Ett DataSet kan fyllas med en eller flera tabeller. Det är data i DataSet som sedan manipuleras efter användarens önskemål. DataSet skickas mellan de olika skikten i vårt system. Figur 4.3: Datatypen DataSet. -15(23)-

4.6.2 DataGrid DataGrid (se Figur 4.4) användes för att presentera data som tillhör ett visst objekt. Genom att knyta en tabell till denna (genom att bestämma DataSource för DataGrid) så kunde innehållet i tabellen presenteras på ett enkelt sätt. Tabellen hämtas i vårt fall från ett DataSet. När man kopplar DataGrid till en DataSource kommer DataGrid att fyllas. Kodexempel 1: mydatagrid.datasource = mydataset.tables[ ObjectParts ]; DataGrid kommer att få samma utseende som tabellen beträffande kolumner och rader. Figur 4.4: Exempel på DataGrid. 4.6.3 SqlConnection SqlConnection används för att skapa en koppling till databasen. Kodexempel 2: SqlConnection mysqlconn = new SqlConnection( data source = ServerNamn; initial catalog = DatabasNamn; user id = användarnamn; password = lösenord ); 4.6.4 SqlCommand För att köra en fråga/procedur mot databasen så används bland annat ett objekt av typen SqlCommand. I vår applikation använde vi oss uteslutande av lagrade procedurer. Nedan följer ett exempel (Kodexempel 3) på hur ett SqlCommand skapas och initieras. Antag att vi har en lagrad procedur i databasen som heter getobjectparts som har följande syntax: CREATE PROCEDURE getobjectparts @ID int AS SELECT * FROM ObjectWork WHERE ObjectID = @ID GO Kodexempel 3: SqlCommand mycommand = new SqlCommand(); mycommand.commandtext = getobjectparts ; mycommand.connection = mysqlconn; mycommand.commandtype = CommandType.StoredProcedure; -16(23)-

4.6.5 SqlDataAdapter Det är via en SqlDataAdapter som vi hämtar data från databasen, respektive uppdaterar data i databasen. När data ska hämtas då behövs förutom en SqlDataAdapter även ett SqlCommand och ett DataSet. Kodexempel 4: SqlDataAdapter mysqldataadapter = new SqlDataAdapter(); mysqldataadapter.selectcommand = mycommand; mysqldataadapt.fill(mydataset, ObjectParts ); Kodexempel 4 ovan visar hur SqlDataAdapter fyller ett DataSet. Efter att ovanstående kod har exekverats kommer DataSet att ha en tabell med namnet ObjectParts. Under förutsättning att UpdateCommand i SqlDataAdapter är satt, kan förändringar i DataSet sparas till databasen enligt Kodexempel 5. Kodexempel 5: mysqldataadapter.update(mydataset.tables[ ObjectParts ]); För att skapa rätt UpdateCommand har vi i detta projekt utnyttjat datatypen SqlCommandBuilder. 4.6.6 SqlCommandBuilder Den datatyp som har underlättat vårt utvecklingsarbete mest är nog denna. Ett objekt av denna typ skapar mer eller mindre automatiskt de nödvändiga SQLUpdate-kommandon som SqlDataAdapter behöver när den ska uppdatera databasen. Kodexempel 6 åskådliggör hur detta fungerar. Kodexempel 6: // SqlDataAdapterns SelectCommand sätts mysqldataadapter.selectcommand = mycommand; // mysqlcommandbuildern kopplas till mysqldataadaptern. SqlCommandBuilder mysqlcommandbuilder = new SqlCommandBuilder(mySqlDataAdapter); // När vi uppdaterar databasen med nedanstående metod kommer // SqlCommandBuilder att jämföra hur tabellen ObjectParts såg ut // då den skapades och hur den ser ut nu. Därefter genereras de // SQLUpdate kommandon som SqlDataAdapter behöver. SqlDataAdapter // kör sedan SQLUpdate kommandona mot databasen. mysqldataadapter.update(mydataset.tables[ ObjectParts ]); -17(23)-

4.7 Systemtestning Innan leveransen av det färdiga systemet utfördes en ordentlig systemtestning. Detta genomfördes utifrån användningsfallspecifikationen (Bilaga 3). Med hjälp av detta steg i utvecklingsprocessen kan fel upptäckas innan leverans av systemet, detta för att kunna leverera ett så bra och stabilt system som möjligt. 4.8 Överlämnande av det färdiga systemet Applikationen som utvecklades under examensperioden är CAB:s egendom. Vid behov skall CAB:s systemutvecklare kunna modifiera systemet enligt nya önskemål. Därför är det viktigt att det finns dokumenterat hur applikationen är implementerad. Systemutvecklaren skall, på ett enkelt sätt, kunna sätta sig in i hur programmet fungerar med dess skikt, klasser, metoder, etc. genom att ta del av dokumentationen. 4.8.1 Systemdokument Systemdokumentet beskriver hur systemet fungerar i detalj. Här finns all relevant information angående applikationen såsom skikt, klasser, metoder, vilka lagrade procedurer som används, databas utformning, etc. 4.8.2 Webbsidor Utöver systemdokumentet har navigerbara webbsidor genererats med hjälp av VS. Webbsidorna skrevs i Hyper Text Markup Language (HTML). Webbsidorna åskådliggör kodstrukturen med klasser, klassvariabler och metoder i projektet. När HTML-sidorna skapas blir all kommentering i koden automatiskt en del av dessa. 4.8.3 Utbildning Innan applikationen sattes i drift hölls en utbildning för de tänkta användarna (CAB:s tekniker). Vid denna utbildning gick vi igenom hur programmet skall användas och fungerar. Tillsammans med den tilltänkta systemansvariga systemteknikern, gick vi igenom hur projektet har implementerats. Under denna genomgång användes dokumentationen som stöd. -18(23)-

5 Resultat Resultatet av detta examensarbete är ett färdigutvecklat, väl fungerande program som idag används av CAB:s tekniker. Programmet uppfyller de krav som ställts på programmets funktioner. För CAB:s räkning innebär detta att tidsåtgången för arbetet med att ta bort snarlika poster i databasen avsevärt minskar, vilket i förlängningen medför en ekonomisk vinst för företaget. Programmet fungerar så att det aldrig kommer att tas bort några poster från databasen. Anledningen till detta är att varje post har ett arbetsmoment och en tid knuten till sig. Om en post tas bort försvinner även momentet och tiden. Det som sker är istället att användaren väljer de poster som ska vara exakt lika och bestämmer vilka egenskaper som ska gälla för dessa poster. När sedan Excel-arket genereras, representeras likadana poster med en rad och de tillhörande tiderna summeras. 5.1 Användargränssnitt Ett framfört önskemål av beställarna var att alltid ha en överblick av hela projektet. För att gå beställarna till mötes löstes detta genom att i huvudfönstret visas en tabell där användaren kan se hur långt han/hon har kommit i sammanställningsprocessen. Denna tabell återfinns i den övre delen av programfönstret. Den slutgiltiga applikationen kom att få ett utseende enligt Figur 5.1. Figur 5.1: Hela programfönstret. -19(23)-

Hela programfönstret är alltid iakttagbart men hela programfönstret kommer inte att vara aktivt/tillgängligt samtidigt. Vilken del av programfönstret som är aktivt/tillgängligt beror på vad användaren vill göra. Dessa olika tillstånd som programfönstret befinner sig i kan summeras enligt följande: Tillstånd 1 - Översikt Här får användaren en överblick av de objekt som finns i databasen. Vilken status varje objekt har åskådliggörs genom bilder i form av ett rött frågetecken för osäker, en grön bock för klar och en helvit bild för ej klar. Se Figur 5.2. I översiktsläget är den övre delen av programfönstret aktivt. Figur 5.2: Översiktsläget. Tillstånd 2 - Redigera objekt I det här läget har användaren möjlighet att sätta de attribut som gäller för hela objektet. För att bestämma om objektet är påbörjat, avslutat eller inte kan användaren ta hjälp av de tider som är nedlagda på objektet som åskådliggörs vid behov. DataGrid innehåller i det här läget objektets alla delar. Alla delar som är identiska representeras endast med en rad i DataGrid. Attributen som gäller för hela objektet sätts i det nedre vänstra hörnet av programfönstret. Figur 5.3: Redigera objekt. -20(23)-

Tillstånd 3 - Redigera objektets delar I det här läget har användaren möjlighet att modifiera en eller flera av objektets delar. De delar som användaren valt att redigera laddas in i DataGrid. De aktiva delarna är DataGrid och den nedre högra delen av programfönstret. Figur 5.4: Redigering av objektets delar. När användaren har valt de attribut som ska gälla för de valda raderna genom att väja från alternativen i comboboxarna och har klickat på OK, kommer raderna få dessa attribut. Detta medför att flera valda rader blir identiska. Efter att användaren har klickat på OK eller Avbryt kommer DataGriden att fyllas med objektets delar på nytt och programfönstret övergår till tillstånd 2. -21(23)-

6 Diskussion 6.1 Förbättringar Presentationen av innehållet i databasen görs i ett Excel ark. Skapandet av detta Excel ark är inte en del av vår applikation, utan görs efter att vår applikation är avslutad. En vidareutveckling av programmet skulle kunna vara att lägga till den funktionen i programmet. För att utveckla och förbättra programmet ytterligare kan tydligheten angående särskiljande egenskaper i posterna förbättras. 6.2 Egna reflektioner Problemet med att snarlika poster uppstår vid insamlandet av data från flera databaser till en databas är ett vanligt förkommande problem. Därför skulle liknande applikationer kunna utvecklas för att underlätta arbetet med att modifiera snarlika poster. Inför detta projekt så hade vi ingen eller ringa erfarenhet av programmeringsspråket C#. Språket C# påminner starkt om Java och C++, eftersom vi har kunskaper i dessa språk, var det väldigt enkelt att komma igång att programmera i C#. Vi har uppfattat språket som mycket kraftfullt och flexibelt. Det har varit mycket intressant och lärorikt att få genomföra ett helt projekt från start till mål. Examensarbetet har gett oss god insikt i metodlösningar samt att arbeta i projektform. -22(23)-

7 Källförteckning 7.1 Böcker Jones, L Bradley (2002): Lär dig C# på 3 veckor. SAMS Publishing/Pagina Förlags AB. ISBN 91-636-0702-6 Stoecker, Matt (2002): Developing window-based applications with Microsoft Visual Basic.NET and Microsoft Visual C#.NET. Microsoft press. ISBN 0-7356-1533-0. Watson, Karli (2002): Börja med C#. Wrox Press/Pagina Förlags AB. ISBN 91-636-0712-3. Waymire, Richard och Sawtell, Rick (2001): Lär dig SQL Server 2000 på 3 veckor. SAMS Publishing/Pagina Förlags AB. ISBN 91-636-0676-3. 7.2 Internetadresser Welcome to the MSDN Library http://msdn.microsoft.com/library 2004-04-15 The Code Project - Multi-select ASP.NET datagrid http://www.codeproject.com/aspnet/multi-select_dataagrid.asp 2004-04-20 ArrayList.ToArray(Type) usage http://blogs.geekdojo.net/richardhsu/archive/2003/11/08/268.aspx 2004-04-28 Where can I find sample C# code for simple threading? http://blogs.msdn.com/csharpfaq/archive/2004/03/15/90082.aspx 2004-05-05 7.3 Övrigt MSDN Library July 2002. Microsoft Corporation. -23(23)-

Bilaga 1 Projektdirektiv

Utfärdare Sida Sara Kjäll 1 / 1 Projektdirektiv Projektets mål Projektet ska förenkla arbete och ge stor vinning i tid i analysarbetet och efterarbetet av lackstudier. Intressenter Teknik avdelningen på Consulting AB. Arbetsform Handledare: Per Bergholm Mentor: Sara Kjäll Utvecklare: Jonas Samuelsson Fredrik Svensson Problemformulering När Consulting AB gör tidstudier görs detta i ett egenutvecklat dataprogram ute på verkstäder. Tidstudier innebär (väldigt förenklat) att man i verkstäder följer en verkstadsman och registrerar allt han/ hon gör under en vecka. Datat sparas i MS SQL Server på bärbara datorer som, efter lackstudiens slut, förs samman till en MS SQLserver. Datat sammanställs sedan till Excel för vidare bearbetning och analys. Vid sammanslagningen av flera databaser till en gemensam databas blir ett objekt/en post på flera rader i databasen. Om det finns särskiljande egenskaper på objektet/posterna blir redundansen även i Excel. Den tänkta applikationen/uppdraget ska kunna hantera denna redundans. Ett användarvänligt program ska utvecklas för att hantera (välja) de särskiljande egenskaperna till en post i sammanställningen, utan att data förstörs. Tidplan Start vecka 13. 22/3-04 : Vilka förväntningar har vi. Ta fram en grovhandlingsplan. 23/3-04 : Börja med kravspecifikationen. Slut vecka 22. POSTADRESS Stortorget 11 702 11 Örebro TELEFON 019-15 86 00 TELEFAX 019-611 30 71 INTERNET www.cab.se E-MAIL Info@cab.se BANKGIRO 659-9138 POSTGIRO 54 24 56-9 ORGANISATIONSNR. 556131-2223 SÄTE Örebro

Bilaga 2 Systemutvecklingsprocess

Utfärdare Sida Sara Kjäll 1 / 3 Systemutvecklingsprocessen 1-13 = steg understrykning = outputs från steg För att få ett genomtänkt och strukturerat sätt att arbeta. 1. Initiera projekt Visionsdokument (projektdirektiv). Göras av uppdragsgivaren. Innehålla: förväntningar, vision, mål och behov, vilken form projektet ska ha, arbetsform. Projektplan: hur lång tid, milstolpar, grov handlingsplan, dela upp i olika delar, vad ska tas med. Kravspecifikation/ kravförteckning, detaljerad: icke funktionella krav (det ska vara lätt att registrera, bra överblick, vara uppe 2h/dygn etc.). funktionella krav (kopiera, registrera etc). Begreppslista (hjälp av C-G?) (en viss ändringshantering behövs) 2. Användningsfallsmodell Användningsfallsmodell, användningsfallsspecifikation: vad ska systemet göra, serie aktiviteter, tänka som en användare, vad ska hända, de funktionella kraven ska mynna ut i användningsfall (ej ta bort, ändra, skapa, lägga till). godkännas (4. Mer detaljerad systembeskrivning. Analysera vilka metoder kan behövas specificera användningsfallen etc.). 3. Planera iteration Vilka användningsfall som man ska jobba med, vilka aktiviteter som ska genomföras, detaljerat till de olika stegen i projektplanen detaljplanering. POSTADRESS Stortorget 11 702 11 Örebro TELEFON 019-15 86 00 TELEFAX 019-611 30 71 INTERNET www.cab.se E-MAIL Info@cab.se BANKGIRO 659-9138 POSTGIRO 54 24 56-9 ORGANISATIONSNR. 556131-2223 SÄTE Örebro

Utfärdare Sida Sara Kjäll 2 / 3 4. Arkitektur Välja plattform, grundstruktur, skikt, logisk, tekniska egenskaper, säkerhet, vara på handdator etc. Arkitektur dokument Kodstandard, namnsättningsstandard Under arkitektur.prototyp 5. Design arkitektur Tex. hur ska dataåtkomst ske, vara en del av arkitektur dokumentet 6. Design databas Viktigt att begreppsmodellen är klar i denna process. Logisk och fysisk db modell (jobba i Visio) Databasen ska spegla systemets funktionaliteter 7. Implementera komponenter Kodning db modell Koppla till VSS Viktig att inte glömma användningsfallen, ifall nya krav kommer in. I detta steg görs olika tester. 8. System integration (vid större projekt) - ett körbart system 9. System testa testning, mot specifikationen blev som det var tänkt POSTADRESS Stortorget 11 702 11 Örebro TELEFON 019-15 86 00 TELEFAX 019-611 30 71 INTERNET www.cab.se E-MAIL Info@cab.se BANKGIRO 659-9138 POSTGIRO 54 24 56-9 ORGANISATIONSNR. 556131-2223 SÄTE Örebro

Utfärdare Sida Sara Kjäll 3 / 3 10. Acceptanstest iteration 11. Driftsättning 12. Manual användar manual Allmänt: Iteration mellan steg 2-10 (~) POSTADRESS Stortorget 11 702 11 Örebro TELEFON 019-15 86 00 TELEFAX 019-611 30 71 INTERNET www.cab.se E-MAIL Info@cab.se BANKGIRO 659-9138 POSTGIRO 54 24 56-9 ORGANISATIONSNR. 556131-2223 SÄTE Örebro

Bilaga 3 Användningsfallsspecifikation

Sammanfattning Detta dokument är en användningsfallsspecifikation tillhörande projektet RedundansEliminering. Användningsfall Programmet består av ett huvudfönster (Parent) och två barnfönster (MDI.child). Följande tabeller visar vilka aktiviteter som är möjliga från respektive varje fönster: Huvudfönster och Projektfönster (MDIchild 1) Aktivitet Detta händer Start av programmet DataSet fylls med data från databasen. ListView fylls utifrån innehållet i DataSet. Klick på - Återställ alla objektknapp - Arkiv + Återställ alla objekt Klick på - Hjälp + Om redundanseliminering Klick på - Hjälp + Hjälp Klick på - Arkiv + Avsluta - Avsluta-knapp Markerar ett objekt i ListView Avmarkerar så att inget objekt är markerat i ListVeiw Klick på - Visa objekt-knapp - Höger-klick + Visa objekt - Dubbel-klick Klick på - Start-knapp En varning visas för att verifiera valet att alla objekt skall återställas (OK/Avbryt). Om användaren klickar OK, återställs alla objekt till hur de såg ut vid start av programmet (DataSet rensas och fylls med originaldata). Om-formen visas. Hjälpen visas. Programmet avslutas. Visa objekt-knappen blir aktiv. Visa objekt-knappen blir inaktiv. Öppnar det aktuella objektet i Objektsfönstret - Redigera objekt-läget (Tillstånd 2). Programmet letar upp det första objektet som har INTE har statusen klar och öppnar det i Objektsfönstret - Redigera objekt-läget (Tillstånd 2). 1/1

Objektsfönster (MDIchild 2) Aktivitet Detta händer Objektsfönster visas. Läs in objekt från databasen. Om objektet har motstridiga data för påbörjad/avslutad, ska ett fönster med objektets alla verktider och möjlighet till att sätta status visas. Om motstridiga data inte finns, ska datagriden fyllas med objektets alla rader och påbörjad/avslutad- respektive ej klar/osäker/klar-status ska fyllas i. Om motstridiga data finns och användaren klickar OK i verktidsfönstret, ska datagriden fyllas med objektets alla rader och påbörjad/avslutad- respektive ej klar/osäker/klar-status ska fyllas i. Om motstridiga data finns och användaren klickar Avbryt i verktidsfönstret, återgår man till projektfönstret. Klicka på knappen Visa tider. Visa verktidsfönstret med objektets alla verktider. Objektets aktuella status fylls i automatiskt. Klicka på OK i verktidsfönstret. Ändra objektets aktuella status till den status som är angiven i verktidsfönstret. Stäng verktidsfönstret. Klicka på Avbryt i Stäng verktidsfönstret. verktidsfönsret. Markera en rad i datagriden. Avmarkera en rad i datagriden. Högerklicka på någon rad i datagriden när ingen rad är markerad. Högerklicka på någon rad i datagriden när minst en rad är markerad. Ändra påbörjad/avslutad status. Ändra ej klar/osäker/klar status. Klicka på Redigera rader-knappen eller i popupmenyn. Raden bockas för och ändrar färg. Textetiketten Markerade rader uppdateras med rätt antal. Knappen Redigera rader aktiveras. Raden bockas ur och byter tillbaka till ursprungsfärgen. Textetiketten Markerade rader uppdateras med rätt antal. Knappen Redigera rader inaktiveras om ingen rad är markerad. En popupmeny visas med endast alternativen Markera alla rader och Avmarkera alla rader som aktiva. En popupmeny visas med alla alternativen som aktiva. Objektets alla rader sätts till vald status. En varning om att objektets alla rader kommer att ändras till den nya statusen visas. Om användaren klickar OK, ändras objektets alla raders status till den valda. Om användaren klickar Avbryt, händer ingenting. Om rader med olika värden i iname har markerats, måste användaren bekräfta att raderna ska redigeras. Om någon rads bmrname-värde inte är null, måste användaren bekräfta att raderna ska redigeras. 2/2

Endast de markerade raderna visas i datagriden. Kontrollerna Text, Lös detalj, Yta, Notes, Area3, BMRYta och Kommentar fylls i med värden från de markerade raderna. Datagriden och Objektinfo-kontrollerna inaktiveras. Radinfo-kontrollerna aktiveras. Klicka på Rensa Kommentarfältet töms på text. kommentar. Klicka på OK. Spara undan aktuellt objekt för att kunna ångra redigering. Spara de värden som finns i Radinfo-kontrollera till alla markerade rader. Rensa Radinfo-kontrollerna. Uppdatera datagriden. Inaktivera Radinfo-kontrollerna. Aktivera datagriden, Ångra redigering-knappen och Objektinfokontrollerna. Klicka på Avbryt. Rensa Radinfo-kontrollerna. Inaktivera Radinfo-kopntrollerna. Aktivera datagriden och Objektinfo-kontrollerna. Klicka på Ångra redigering-knappen eller i popupmenyn. Klicka på Visa tider i popupmenyn. Klicka på Ändar status till ej klar, osäker eller klar i popupmenyn. Klicka på Markera alla rader i popupmenyn. Klicka på Avmarkera alla rader i popupmenyn. Klicka på knappen Spara & stäng. Klicka på knappen Spara & ta nästa. Klicka på knappen Återställ objekt. Klicka på knappen Avbryt. Återställ objektet till hur det såg ut före senaste sammanslagningen av rader. Uppdatera datagriden. Verktidsfönstret visas med verktiderna för de markerade raderna. Om användaren klickar på OK, stängs fönstret och objektets status sätts till den som angavs i verktidsfönstret. Om användaren klickar på Avbryt, stängs verktidsfönstret. Statusen för de markerade raderna ändras till den valda. Uppdatera datagriden. Markera alla rader i datagriden. Avmarkera alla rader i datagriden. Spara objektet till databasen. Rensa och inaktivera alla kontroller. Återgå till projektfönstret. Spara aktuellt objektet till databasen. Rensa alla kontroller. Ladda nästa objekt från databasen (Objektfönster visas). Användaren måste bekräfta att objektet ska återställas. Rensa alla kontroller. Ladda in samma objekt från databasen (Objektsfönstret visas). Rensa och inaktivera alla kontroller. Återgå till projektfönstret. 3/3