Furnie ToolsArbetsverktyg för hantering av data

på Horreds Möbel AB

Furnie ToolsTool for handling data at Horreds Möbel AB

Mathias Nilsson

Simon Österholm

Examensarbetet omfattar 15 högskolepoäng och ingår som ett obligatoriskt moment iHögskoleingenjörsexamen i Datateknik, 180p

Nr 1/2009

Arbetsverktyg för hantering av data på Horreds Möbel AB

Tool for handling data at Horreds Möbel AB

Mathias Nilsson nilsson_mathias@home.se

Simon Österholm simonosterholm@hotmail.com

Kandidatuppsats examensarbete

Ämneskategori: Teknik

Serie och nummer: Datateknik 1/2009

Högskolan i BoråsInstitutionen Ingenjörshögskolan501 90 BORÅSTelefon 033-435 4640

Examinator: Magnus Lundin

Handledare: Åsa Johansson

Uppdragsgivare: Horreds Möbel AB

Datum: 2009-04-27

Nyckelord: Databas, database, UML, UP, program, verktyg

ii

Abstract

This report describes the creation of a software program and a database for handling differentkinds of data at Horreds Möbel AB, a furniture manufacturing company. Based on therequired specifications and by using a development tool UML (Unified Modelling Language),we created a template for how the software should operate. The template was used to form therequired functions which were needed by the software. The template was also used to formthe needed objects, classes and other important components that appear in the software.

A database and the software that it communicates with were created by using two softwaretools MS SQL 2000 and Jbuilder2005 as well as the data generated from UML. This softwaremakes it possible to handle the database´s different kinds of data. Through Jbuilder2005, agraphical user interface was developed and the corresponding code was automaticallygenerated. To complete this process, all functions needed in the software had to be createdmanually.

In order to form a comprehensive graphical user interface we drew on our own insights andideas in addition to the knowledge gained in the course Mjukvarudesign (translation: SoftwareDesign) Microsoft Office was used as template for the user interface.

The code was formed in different classes and structured in a way that a main class handles thegraphics and creation of new objects. The database was structured in tables where therelationships are based on the company's product catalogue.

Sammanfattning

I denna rapport beskrivs utvecklingen av ett program och en databas för hantering av datatänkt att användas på ett möbelföretag, Horreds Möbel AB. Med en kravspecifikation somutgångspunkt och med hjälp av ett utvecklingsverktyg, UML (Unified Modeling Language)har en mall för programmets utseende arbetats fram. Ur denna mall formas de funktionerprogrammet behöver och hur de rent teoretiskt ser ut. Även vilka objekt, klasser och andraviktiga komponenter som programmet kommer att ha, formas på samma sätt.

Med hjälp av två program, MS SQL 2000 och JBuilder2005, och det UML genererat, har endatabas och ett program formats. Dessa kommunicerar med varandra för att hantera data förolika syften. Genom JBuilder2005 skapades ett grafiskt gränssnitt som automatisktgenererade koden för detta. Sedan formades funktionerna manuellt till de olikakomponenterna i programmet.

För skapandet av ett användarvänligt gränssnitt tillämpades kunskapen given genom kursenMjukvarudesign på Borås högskola, samt egna tankar och idéer på hur man formararbetsfönstret på ett så tillfredsställande sätt som möjligt för användaren. Som underlag förgränssnittet användes programmen i Microsoft Office.

Koden formades klassvis och strukturerades så att en huvudklass ansvarar för grafiken ochskapandet av instanser av de andra klasserna. Databasen formades med tabeller och dessastrukturerades med relationer tagna från företagets produktkatalog.

iii

Innehåll

Abstract.....................................................................................................................................3Sammanfattning.......................................................................................................................3

1.1 Syfte.................................................................................................................................62. Principer för val av metod och verktyg.............................................................................6

2.1 Litteratur..........................................................................................................................72.2 Programvara.....................................................................................................................7

2.2.1 Utvecklingsmiljö.......................................................................................................72.2.2 Databas......................................................................................................................7

2.3 Modelleringsspråk: UML (Unified Modeling Language)...............................................72.3.1 Kravspecifikation och Begreppslista........................................................................82.3.2 Use Case ...................................................................................................................82.3.3 Interaktionsdiagram..................................................................................................82.3.4 Kontrakt....................................................................................................................92.3.5 Klassdiagram.............................................................................................................92.3.6 Validering, Testning och Integrering .......................................................................9

3. Objektorienterad Analys och Design av systemet.............................................................93.1 Idépresentation...............................................................................................................103.2 Identifikation av begrepp...............................................................................................103.3 Use Case.........................................................................................................................103.4 Interaktionsdiagram.......................................................................................................113.5 Kontrakt.........................................................................................................................113.6 Klassdiagram..................................................................................................................113.7 Utvecklingen av databasen............................................................................................123.8 Implementeringen..........................................................................................................123.9 Programmets funktioner.................................................................................................12

3.9.1 Skapande funktioner ..............................................................................................123.9.2 Ändrande funktioner mot databasen.......................................................................133.9.3 Ändrande funktioner i programmet.........................................................................13

4. Implementation..................................................................................................................134.1 Användargränssnitt........................................................................................................13

4.1.1 Grundfönstret..........................................................................................................144.1.2 Menyn & verktygsfält.............................................................................................154.1.3 Vänster sida.............................................................................................................174.1.4 Höger sida...............................................................................................................19

4.2 Databas...........................................................................................................................204.2.1 Databastabellerna....................................................................................................20

4.3 Kodstruktur....................................................................................................................214.3.1 Lägg till ny produkt (addProduct)...........................................................................224.3.2 Skapa tabellen materialgrupp..................................................................................23

5. Applikationens felhantering och hjälpinstruktioner......................................................235.1 Manualen........................................................................................................................235.1 Felhanteringsfunktion....................................................................................................23

6. Problem...............................................................................................................................246.1 Tidsaspekten..................................................................................................................24

7. Diskussion...........................................................................................................................257.1 Applikationens utformning och design..........................................................................257.2 Applikationens programmeringsstruktur.......................................................................25

iv

7.3 Databasens struktur........................................................................................................267.4 Applikationens felhantering...........................................................................................267.5 Applikationens hjälpinstruktioner..................................................................................267.6 Tidsaspekten..................................................................................................................26

8. Slutsats................................................................................................................................27Referenslista...........................................................................................................................28

Bilaga 1 KravspecifikationBilaga 2 BegreppslistaBilaga 3 Use Case DiagramBilaga 4 Use CaseBilaga 5 SystemsekvensdiagramBilaga 6 KontraktBilaga 7 Klassdiagram/systemarkitekturBilaga 8 Databasstruktur

v

InledningDetta arbete baseras på en förfrågan från företaget Horreds Möbel AB, där de efterfrågar ettprogram som kan hjälpa dem för att digitalt hantera deras produktsortiment och hjälpa demvid framställningen av nya produktkataloger. Företaget Horreds Möbel AB grundades 1936och har sitt huvudsäte i Horred i Västra Götaland. Deras affärsidé är främst kontorsmöbleringmed inriktning på design och kvalitet där de har skapat ett antal olika produktgrupper för attskapa attraktiva lösningar för olika typer av kunder.

Uppgiften för att tillmötesgå företagets önskemål blev att finna en lösning som stämde braihop med deras kravspecifikation. Och denna blev att bygga upp en databas för hantering avföretagets artiklar samt att skapa ett program som kan kommunicera med databasen för attredigera dess innehåll. Programmet skulle även innehålla en funktion där en nyproduktkatalog kan genereras från de mest aktuella data som lagrats i databasen. Programmetskulle vara enkelt och lätt att lära sig då datorkunskapen hos användarna är blandad ochdärför är ett tydligt användargränssnitt med hög igenkänningsfaktor viktigt.

Metoden som var underlag för arbetet heter UP (Unified Process) och som verktyg för attskapa detta program användes UML (Unified Modeling Language).

1.1 Syfte

Detta arbetes syfte var att leverera en lösning till Horreds Möbel AB som består i enstrukturerad databas med ett tillhörande program för redigering av dess data. Denna rapportingår som en del i arbetet och beskriver hur utvecklingen av programmet och databasen gåtttill och varför gränssnittet formats som det gjort.

2. Principer för val av metod och verktyg

För att skapa ett program och en databas som Horreds Möbel AB efterfrågar krävs kunskapom hur man programmerar och utformar ett program samt hur man bygger en databas. Närman startar ett projekt gäller det att välja bra verktyg och modeller för att nå bästa möjligaresultat. Problem uppstår alltid och genom att finna nya lösningar möjliggör man vidareutveckling och då genereras ny kunskap som är till nytta för utvecklingen av programmet. Iprogramutveckling är det liksom i så många andra sammanhang väldigt viktigt att lägga enstabil grund som man kan stå stadigt på genom hela utvecklingsarbetet.

I början av ett projekt är det svårt att välja vilket programspråk och vilken databas man skaanvända då valet av dessa bör baseras på programmets utseende och funktionalitet. Det manförst bör välja är med vilken utvecklingsmodell man vill forma sitt program. Valet blevmetoden UP och utvecklingsverktyget UML som passade bra för detta arbete. Med UP ochUML formas programmet, hur det teoretiskt kan fungera och därefter blir det lättare attbesluta om vilket programmeringsspråk som bäst passar in.

Valet av språk är viktigt, och då är det bra att väga fördelar och nackdelar mot varandra. Idetta projekt var det viktigt att välja ett språk som var lätt att implementera med en databas.Valet blev språket Java då detta är relativt enkelt att jobba med och uppfyller ställda kriterier.

2.1 Litteratur

UP och UML är stora ämnen som tillämpas på olika områden och därför finns det mycketlitteratur att tillgå. Två bra böcker är ”The unified software development process” och ”Theunified modeling language user guide” som strukturerat tar upp dessa ämnen.

Programmering är ett stort område och det finns mycket litteratur, både i bokform och påInternet. Java är ett relativt nytt språk som blivit populärt vilket gör det lätt att finnainformation. En bra bok är ”Java Direkt med Swing” som grundläggande beskriver språketJava. Den är tydlig och innehåller många exempel av kodstrukturer och fyller många behovför att klara av olika programmeringsuppgifter.

Koden i Java baseras på klasser och på Internet finns det många färdiga att ta del av gratis.Framför allt hemsidan http://java.sun.com/javase/6/docs/api/ innehåller många bra ochanvändbara klasser som kommer till hjälp vid programmering.

2.2 Programvara

2.2.1 UtvecklingsmiljöNär man bestämt sig för ett språk behövs ett program där man skapar gränssnitt och skriverkod. Det finns olika tillvägagångssätt, ett är att man skriver all sin kod själv i enklare programsom t.ex. en texteditor, ett annat att man väljer ett program där man bygger uppanvändargränssnittet och får koden för grafiken genererad som i t.ex. Jbuilder2005. Generelltfungerar det så att gränssnittet byggs upp med färdiga komponenter t.ex. knappar ochrullgardiner och sedan skapar programvaran den kod som motsvarar dessa vilket sparar tid förutvecklaren och gör det trevligt och smidigt att jobba med.

2.2.2 DatabasDe flesta applikationer som hanterar mycket data använder sig av någon form av databas därall information sparas. I detta arbete blev valet att använda Microsoft SQL 2000 påoperativsystemet Windows Server 2003 då Horreds Möbel AB sedan innan använder sig avMicrosoft SQL 2000.

2.3 Modelleringsspråk: UML (Unified Modeling Language)

Vid programutveckling och mjukvarudesign finns det olika metoder för hur man går till väga.En metod är UP(Unified Process) där man utifrån en kravspecifikation jobbar med ett språkUML, som innehåller verktyg för att beskriva olika typer av system. I detta fall användes detför konstruktion av mjukvara och objektorienterad programmering som är ett vanligtanvändningsområde för UML. Idén med det hela är att man först analyserar vad som skagöras, sedan designar hur det ska göras för att i slutändan genomföras. UML omfattar etttillvägagångssätt med olika diagram och modeller för att göra analyser och få designtips.Följer man dessa mallar och använder verktygen rätt så får man i slutändan fram delar avimplementeringen, detta tack vare att man med UML byggt upp de logiska relationerna sombehövs, vilka aktörer som gör vad och hur de gör det.

2.3.1 Kravspecifikation och BegreppslistaProjektet börjar med en kravspecifikation där beställarens krav finns nedskrivna, t.ex. vadprogrammet ska göra, vilka funktioner som ska finnas med och olika systemattribut mm.Frågan man ställer sig är alltså vad som ska göras. Ur denna kravspecifikation identifierasolika objekt, metoder, attribut mm som programmet ska bestå av och då har grunden börjatformas. I detta skede ska man börja skriva en begreppslista, som ska innehålla allt som kanuppfattas som objekt, metod, attribut mm. Denna lista underhåller man genom hela arbetetvilket är viktig för att få med alla egenskaper i programmet.

När man fått fram vad som ska finnas med får man ställa sig frågan vem som ska påverkaprogrammet, alltså aktörer. Är det en person som ska sitta vid en dator och jobba eller är detflera användare vid olika datorer. Detta är ett steg som bör tänkas igenom väl då det är härgrunden läggs för hur programmet ska formas. Det är viktigt att användaren/användarnadirekt känner att de kommer in på väsentliga delar i programmet och inte behöver klickaigenom saker som de inte har någon som helst nytta av.

2.3.2 Use CaseUse Case är ett verktyg för att illustrera hur en aktör utför ett moment i programmet ochenkelt visar vad som sker, från en utgångspunkt till en slutpunkt. Detta är ett bra sätt för att fåen bild av hur man kan strukturera programmet, vilka steg som ska finnas för att utföra någotmm. Med dessa som underlag utvecklas Use Case diagram där man förtydligar saker ochslutligen organiserar dem till ett enkelt flödesdiagram för att få en bild av hur programmet kanse ut. Förhoppningsvis har man identifierat vilka aktörer som finns, vad de gör och hur de kanrelateras till varandra, men också har man möjligen identifierat objekt som ska bli grunden förprogrammet.

Efter de första stegen gäller det att granska dokumentationen och se vad för begrepp mansamlat på sig och analysera vad man fått fram. Identifiering av begreppen görs för att byggaupp objekt med olika egenskaper eller attribut och bygga upp relationer mellan dem. Fråndessa objekt och deras relationer formas senare klasser.

2.3.3 InteraktionsdiagramInteraktionsdiagram använder man för att mer detaljerat beskriva systemet och hjälpa till attfinna olika mönster i det. Ur dessa ska man förhoppningsvis få ihop tillräckligt medinformation för att gå vidare med systemdesignen. Dessa diagram är en bild av händelser isystemet mellan olika element som aktörer, objekt eller komponenter.

Det finns olika interaktionsdiagram t.ex. sekvensdiagram, systemsekvensdiagram ochsamarbetsdiagram. Sekvensdiagram och systemsekvensdiagram beskriver händelser mellanobjekt utmed en tidsaxel medan samarbetsdiagram beskriver de naturliga länkarna mellanolika objekt och vad som sker mellan dem.

Här utgår man från sina tidigare utvecklade Use Case där man beskrev ett händelseförlopp,med en startpunkt och slutpunkt. Nu kan man utifrån Use Case skapa sinainteraktionsdiagram som beskriver händelserna. Dessa händelser döper man till passandenamn som ganska specifikt beskriver vad som händer i systemen, t.ex. ”AngeBelopp(Num)”.Inom parenteser i namnet anges också vad för typ av värde som funktionen handhåller, i dettafall ett numeriskt värde.

När man skrivit sina interaktionsdiagram har man förhoppningsvis fått en bättre bild av vadsom händer i systemet.

2.3.4 KontraktI interaktionsdiagrammen har en hel del systemhändelser identifierats och redovisats, mendessa är inte speciellt tydliga. Därför skriver man kontrakt som beskriver detta. Varjesystemhändelse eller operation beskrivs med ett kontrakt för att förtydliga dess syfte. Manbeskriver vad operationen gör eller uppfyller, vad för typ av funktion det är, var den finns(referenser), undantagshändelser, utgångsläge och slutläge.

2.3.5 KlassdiagramGenom tidigare steg i utvecklingen som t.ex. Use Case, interaktionsdiagram ochbegreppslista har man funnit begrepp och identifierat objekt som bildar olika klasser. En klassär en beskrivning av ett antal objekt som delar samma attribut, funktioner och relationer. Föratt skapa sig en visuell bild över programmets struktur och för att ha ett underlag vidimplementeringen skapar man klassdiagram. Här ställer man sig frågor som hjälper till attfinna relationer mellan de klasser man format. Relationerna visar hur kommunikationen ochsamarbetet mellan klasserna fungerar.

2.3.6 Validering, Testning och IntegreringNär man skapat de olika diagrammen och begreppslistan återstår det att granska dem ochjämföra och se så att allt stämmer. Att alla funktioner och objekt är korrekt redovisade ellerom det finns något som kan betraktas som överflödigt, t.ex. att man kanske kan ersätta tvåsaker med en. Allt detta är viktigt att göra innan man börjar med implementeringen, attupptäcka olika problem här sparar tid och pengar.

När man sedan har börjat med implementeringen är det viktigt att testa så att allt fungerar somdet ska, både under tiden man programmerar och när man tror sig är färdig med programmet.Att skicka en felaktig produkt är kostsamt och skapar dåligt förtroende från kunder.

Det som sedan återstår är att integrera produkten med kundens system och se till så att alltfungerar och att rätt saker är levererade. När man uppfyllt alla punkter som efterfrågats avkunden så kan man verifiera detta och se projektet avslutat.

3. Objektorienterad Analys och Design av systemet

Detta arbete lade sin grund efter en förfrågan från Horreds Möbel AB om ett program somkunde hjälpa dem vid framtagning av nya produktkataloger. Programmet som efterfrågadesska jobba mot en databas med information om deras produkter och där de ska kunna redigeradata, lägga till ny data och i slutändan generera en ny produktkatalog av befintlig data.Intressant uppgift och därför, för att följa tanken med UP, skickades en förfrågan om en tydligoch genomtänkt kravspecifikation som visade vad företaget hade för mål med projektet ochsamtidigt möjliggöra ett ställningstagande till om man var rätt personer för dem att genomförauppgiften.

3.1 Idépresentation

Kravspecifikationen (se bilaga 1) är kort men relativt tydlig. Det framgår tydligt vilkafunktioner de vill ha i programmet samt vad databasen ska innehålla. Som det beskrivstidigare i rapporten är UP en bra metod vid utveckling av nya program och därför tillämpasdessa idéer i detta arbete för dess utformning.

När man nu hade en kravspecifikation var det dags att sätta sig ner och läsa igenom den ochbedöma vilka möjligheter som fanns för att kunna tillmötesgå deras önskemål. Genom attsätta sig in i problematiken över vad som begärdes och sedan överlägga med handledaren tillexamensarbetet om möjligheterna att skapa ett program som uppfyller deras krav, gjordes enbedömning att alla punkter i kravspecifikationen inte gick att fullfölja. Skapandet av vissafunktioner som Horreds Möbler AB efterfrågade var enligt handledaren för svåra ochtidskrävande, framför allt önskemålet med att på något sätt generera en produktkatalog pådata som lagras i databasen.

Övriga punkter i deras kravspecifikation var helt rimliga att fullfölja så nu var en grundplanatt arbeta efter lagd och utvecklingen av programmet startade.

3.2 Identifikation av begrepp

Utifrån den färdiga kravspecifikationen lades en grund för programmet genom skapandet avbegreppslistan (se Bilaga 2). Denna följde med under projektet och uppdateradeskontinuerligt. Genom kravspecifikationen och en produktkatalog från Horreds Möbel ABurskildes de grundläggande funktioner och begrepp som senare användes i dokumentationen iUML.

Begrepp som framkom var framför allt olika egenskaper på produkter som ska lagras idatabasen och som företaget senare ska ha möjlighet att kunna ändra, som t.ex. pris, namn,beskrivning mm. Det samma gäller de funktioner som identifierades i kravspecifikationensom t.ex. funktioner för att lägga till en artikel, göra prisändringar på artiklar och möjlighetenatt handskas med olika valutor. En anmärkning här var att de flesta funktioner med störstasannolikhet skulle bli väldigt lika, detta underlättar vid implementeringen då man kanåteranvända kod.

3.3 Use Case

Med en färdig kravspecifikation och den påbörjade begreppslistan fanns grunden för att kunnagå vidare i utvecklingsarbetet. Genom att börja utforma olika Use Case, både enklare ochutvecklade, så tydliggjordes illustrativt vad som händer i programmet. Dessa sammanställdessedan till ett Use Case diagram (se Bilaga 3).

Huvudfunktionen med programmet som visas i Use Case diagrammet är att genom ett antalfunktioner kunna fylla en databas med information som ska användas för skapandet av enproduktkatalog. Diagrammet visar de underliggande enkla Use Case som identifierades ikravspecifikationen som t.ex. att lägga till en ny produkt eller lägga till en ny materialgrupp,alltså alla de funktioner som krävs för att skapa den data en produkt består av i en katalog.

Att alla enkla Use Case pekar på ett huvudprogram visade att denna fick bli programmetshuvudklass genom utvecklingsarbetet. Diagrammet visar att aktören jobbar mothuvudklassen.

Sammanfattat visar de enkla Use Case och diagrammet illustrativt hur en aktör interagerarmed systemet. De utvecklade Use Case (se Bilaga 4) beskriver de enklare Use Case, t.ex. nären aktör lägger till en ny produkt, de tydliggör flödet. Ur dessa framgick det att många UseCase hade en liknande uppbyggnad vilket grundlade tanken för en enklare utformning vidimplementationen där samma struktur på koden kunde återanvändas. De gav också en bild avhur gränssnittet skulle kunna formas då de beskriver hur en användare jobbar i programmet.

3.4 Interaktionsdiagram

För att utveckla och få en bättre bild över systemet skapades interaktionsdiagram, i detta fallsystemsekvensdiagram (se Bilaga 5). Diagrammen visar generellt att det är en kontinuerligkommunikation mellan databasen och programmet där användaren genom funktioner styr ochsätter värden på data som lagras i databasen. Den tänkta huvudklassen (system i diagrammet)skapar instanser som användaren utnyttjar för att kommunicera med databasen.

I de olika Use Case som formades skapades många händelser för att kunna fullfölja flödett.ex. när användaren vill skapa en ny produkt eller en post i databasen. Detta visas idiagrammet och betyder att det behövs funktioner för dessa händelser. Så med hjälp avsystemsekvensdiagram grundlades funktionerna genom identifiering av händelser.

I begreppslistan fanns alla dittills identifierade variabler som nu kunde placeras i händelsernaoch således bli variabler i funktionerna som formades i diagrammen. Detta bekräftar hurvariabler, funktioner och objekt kan relateras och organiseras gentemot varandra.

3.5 Kontrakt

Händelserna i interaktionsdiagrammen gav flertalet funktioner som dokumenterades medkontrakt (se Bilaga 6). Med dessa tydliggörs mer specifikt hur funktionerna ser ut medvariabler och returvärden. Här preciseras även vilket ansvar funktionerna har. Dessa varunderlag när funktionerna implementerades.

3.6 Klassdiagram

Med det underlag som skapats med verktygen i UML formadesklassdiagram/systemarkitektur (se Bilaga 7) för att illustrera programmets uppbyggnad.Diagrammet visar att huvudklassen ”Arbetsfönstret” innehåller en allmän funktion”NyttObjekt” som används för att skapa nya objekt som t.ex. en produkt, en ny materialgruppeller en ny valuta. Dessa i sin tur har en koppling till en databasadapter som ser till attdatabasen uppdateras. I ”Arbetsfönstret” finns även en funktion ”Ändraobjekt” som genomdatabasadaptern hämtar data så att användaren kan redigera den och sedan uppdateradatabasen med nya värden. Diagrammet visar även att det inte behövdes några kopplingarmellan klasserna då all hantering av dessa sker mellan klasserna och databasen.

3.7 Utvecklingen av databasen

En bra databas behöver en bra grund, man måste fastställa alla attribut som ska finnas medoch strukturera en relation mellan dem och finna nycklar. Genom UML finns det bra mallarför hur man formar en bra databas. Genom att bestämma rubriker efter attribut som tas framför databasens kolumner placeras och organiseras rubrikerna i ett antal tabeller.

Varje databas behöver nycklar för att skapa unika poster, dessa knyter ihop databasen ochsedan skapas funktioner som kan kommunicera med databasen för att få programmet attfungera.

Ur begreppslistan så identifierades alla objekt som blev rubriker i databasen och då blev ävende tillhörande attributen till dessa kolumner. I detta fall blev det naturligt att användaprodukternas artikelnummer som nyckel då dessa från början var unika. Andra nycklar somanvänds i databasen är t.ex. materialgruppernas och produktgruppernas id-nummer.

3.8 Implementeringen

Med hjälp av resultatet från UML så gick utvecklingsprocessen vidare och underlag förimplementeringen fanns färdig. I samband med detta så upptäcks saker som gör att man delvisavviker från den strukturerade plan som UML gav, verktyget ger en möjlig bild avprogrammet men ingen slutgiltig. Genom JBuilder så genereras kod i samband med att manformar användargränssnittet. Koden kan uppfattas som obekväm och ostrukturerad ochbehöver därför en del redigering.

3.9 Programmets funktioner

När programmet byggdes och formades i JBuilder2005 till det utseendet som önskades sågenererades också den kod som behövs för att skapa detta gränssnitt. Det som saknas är kodentill alla de tänkta funktioner som ska finnas i programmet vilket är upp till programmerarnasjälva att skapa. En annan sak som programmet inte hade hjälpt till med var att skapakommunikationen med databasen.

Genom kravspecifikation, Use Case och systemsekvensdiagram har det lagts en grund för enmängd funktioner som programmet behöver för att uppfylla kraven från Horreds Möbel AB.Programmet innehåller ett par grundläggande funktionsgrupper, alltså grupper med liknandefunktionalitet. En grupp med funktioner där man skapar något och lägger in det i databasen,en grupp där man kommunicerar med databasen och jobbar med dess innehåll och en gruppsom bara påverkar själva programmet.

3.9.1 Skapande funktionerGenom arbetet med UML visade det sig att det finns en hel del olika egenskaper till de artiklarsom ska skapas i databasen. Varje möbel tillhör en specifik möbelgrupp, är tillverkade i ettvisst material och tillhör därför en specifik materialgrupp, har ett pris, en beskrivning, ettspecifikt nummer som gör möbeln unik mm.

Programmet bygger upp databasen genom att lägga in möbler med alla dess tillhörandeegenskaper i en post där varje egenskap lagras i egna kolumner. För varje ny egenskap t.ex.

en ny materialgrupp, produktgrupp eller språk som läggs till i databasen fylls listor med dessagrupper på.

Dessa listor med egenskaper fyller upp comboboxar som underlättar för en användare somvill lägga till en ny produkt. Med hjälp av comboboxarna kan användaren välja bland alla despecifika egenskaper en produkt kan ha.

3.9.2 Ändrande funktioner mot databasenNär man har skapat poster i databasen så behöver programmet också andra funktioner därman kan ändra posterna i databasen t.ex. ändra något pris eller något i en produktgrupp. Dessatyper av funktioner är alla programmerade på ett liknande sätt, alla tar emot data ochuppdaterar databasen. Alla egenskaper som man skapat och sedan lagrat i databasen kan manändra i efterhand förutom identitetsnumret som är unikt och är en nyckel i databasen.

Dessa funktioner är placerade under olika flikar som är inlagda i gränssnittet. Varje flik harfått ett namn som är vägledande och visar vad man jobbar med t.ex. produkt, pris ellermaterialgrupp. När man växlar mellan flikarna anropas olika funktioner, det sker olikasökningar i databasen som visas i en lista som är inlagd i gränssnittet. Går man in på flikenmaterialgrupp syns alla tillgängliga grupper från databasen i listan och markerar man en postså visas data i de olika textfält som finns under de olika flikarna.

För att organisera vad som visas i listan är en funktion inlagd där man kan göra enklaresorteringar för att få ner antalet poster till en mer lätthanterlig mängd. Denna funktionanvänds när man väljer fliken produkter, som innehåller en oöverskådlig mängd poster. Meddenna funktion väljer man att t.ex. visa alla poster som tillhör en viss produktgrupp.

I kravspecifikationen fanns en önskan från Horreds Möbel AB att det skulle finnas enfunktion där man ställer in valutakursen och på så sätt få priserna i olika valutor. Dennafunktion fungerar så att man ställer in önskad kurs och sedan trycker på en knapp för attgenerera ändringarna. Programmet går igenom varje post och ändrar priset så att man får denefter rätt valuta. Valutakurserna lagras i databasen.

3.9.3 Ändrande funktioner i programmetDetta är den minsta gruppen funktioner och har gemensamt att de jobbar enbart i programmetoch inte mot databasen. Dessa små funktioner är sådana som gör ändringar på inställningarnaför utseendet på programmet.

4. Implementation

När man jobbar med JBuilder blir kodning och formgivning en gemensam sak då man byggerupp gränssnittet och får kod genererad. Koden skapar objekten i programmet som t.ex.knappar, menyer mm och det är sedan upp till programmeraren att utforma funktionerna ikoden och ge objekten funktionalitet.

4.1 Användargränssnitt

Programmet som användes för utformningen av gränssnittet är det grafiska designprogrammetBorland JBuilder2005 Enterprise. Denna typ av program underlättar då man kan brainstorma

fram idéer för ett bra användargränssnitt och man slipper skriva koden för att ge sina idéerutseende.

JBuilder fungerar som ett pussel där det finns ett flertal olika pusselbitar med blandadefunktioner. Man bygger upp ett gränssnitt med programmet, t.ex. placerar olika knappar,sätter ut olika fält för inmatning av data eller olika typer av redovisningsfält för data.Programmet skapar kod samtidigt som man bygger upp gränssnittet, så man får all grundkodav programmet. Sedan kan man utgå från grundkoden när man utformar och specificerarresten av programmet.

Grundtanken med programmet är att det ska vara enkelt att ta till sig och lätt att lära siganvända då kraven på datorkunskap är låg. Kunden Horreds Möbel AB uppgav baraprogramfunktioner i kravspecifikationen och gav inga krav på gränssnittet. Därför utformadesett par förslag som kunden fick ta del av och ta ställning till. Som underlag för utformningenav programmet användes boken GUI Bloopers av Jeff Johnson.

Det första förslaget baserades på ett grundfönster med de fundamentala funktionerna, där mangenom att klicka på en önskad funktion öppnar ett nytt fönster för underliggande funktionero.s.v. tills man får fram ett fönster med de aktuella funktioner man vill använda. Idénuppskattades inte då det upplevdes för plottrigt med alla fönster, dessutom upptäcktes det attkoden blev svår att hantera, alltså raka motsatsen till vad som ville uppnås. En annan nackdelmed denna struktur skulle vara att det blir monotont och väldigt oflexibelt.

Förslag två innebar att forma ett program som har ett arbetsfönster som innehåller de önskadefunktionerna. Detta är kanske den vanligaste lösningen i dag, vilket man ser hos en mängdprogram som många använder dagligen t.ex. Word och Excel. Det är en bra ide att formaprogrammet på ett sådant sätt att det har en hög igenkänningsgrad, personer tar snabbare tillsig programmet och känner sig tryggare enligt Jeff Johnson.

Den nya idén var som sagt att bara ha ett fönster som skulle innehålla grundfunktionerna ochäven ha någon typ av verktyg som gör att man kan granska och jobba med databasen. Attforma ett program är en vetenskap och väldigt svårt då meningarna går isär på vad som är denbästa lösningen, det finns inget rätt eller fel utan bara olika tycke.

4.1.1 GrundfönstretNär man startar programmet ska man inte uppleva programmet krångligt och ostrukturerat.Grundfönstret bör upplevas enligt Jeff Johnson som tydligt och med ett spartanskt utseende,inte att olika komponenter är ihopklumpade vilket gör det svårt för användaren. Men det ärsamtidigt viktigt att inte ha alla objekt rakt upp och ner för det kan motverka det logiskautseendet.

Enligt kravspecifikationen ska man genom programmet kunna jobba med artiklar i en databas,därför behövdes någon typ av verktyg som tydligt och enkelt redovisar innehållet i databasen.Java erbjuder ett par alternativ som uppfyllde behovet och valet blev att användatableScrollPanel som är ett listverktyg och som visas i urklippet.

4.1.2 Menyn & verktygsfält

Syftet med menyer och verktygsfält är att på ett strukturerat sätt samla ett antal funktioner såatt de är enkla att hitta när man behöver dem. Bortsett från standardfunktioner som att”Spara”, ”Hämta” eller ”Avsluta” så innehåller programmet i princip två olika typer avfunktionsgrupper. En grupp med funktioner som handlar om att skapa någon typ av objektoch en grupp funktioner där man bearbetar de olika objekten. Hur och var man placerarfunktioner är väldigt blandat men man kan utgå från att alla funktioner ska placeras på ett

Illustration 1: Urklipp på grundfönstret i programmet

Illustration 2: Urklipp som visarmenyraden i programmet

ställe där det känns logiskt att ha dem. De ska vara lätta att finna och det ordnas genom attt.ex. placera standardfunktioner där de vanligtvis ligger i program som t.ex. Word.

Därför används en enkel menyrad med rubrikerna ”Arkiv”, ”Inställningar” och ”Hjälp”, somför många känns bekanta då det är samma namn som används i Microsoft Office. Att användadessa namn skapar en viss igenkännande effekt och användaren lär sig snabbare att användaprogrammet.

Under ”Arkiv” placerades de fyra funktionerna ”Spara”, ”Hämta”, ”Förhandsgranskning” och”Avsluta”, alla fyra är vanliga funktioner som finns i de flesta program i Windows och äruteslutande placerade i ”Arkiv” –menyn. Logiskt och igenkännande vilket är signumet. Hadede lagts under en annan rubrik hade det med stor sannolikhet skapat irritation, vilket är någotJeff Johnson varnar för i sin bok.

Samma gäller den andra rubriken, ”Inställningar”. Logiskt sett bör alla funktioner som harmed inställningar i programmet att göra och som inte är direkta eller som regelbundet användsplaceras här. Allmänt säger man att alla funktioner ska placeras i menyerna även om de finnspå andra ställen i programmet men det är diskutabelt. Programmet har två funktioner som harhand om inställningar på programmet, ”Utseende” och ”Valutakurs”.

”Utseende” innehåller möjligheten att ändra grundinställningarna för hur användargränssnittetska se ut. En sådan funktion kan uppfattas som onödig då man vid utvecklingen kommitöverens om hur gränssnittets ska formas. Men då alla är olika och har olika tycke så kan detvara bra att det finns en extra möjlighet att ändra text och färger för att göra det bekvämare attanvända programmet även om grundinställningen förhoppningsvis tillfredsställer de flestaanvändare.

Programmets verktygsfält är rätt så litet och innehåller bara en knapp ”Nytt” som, om mantrycker in den, visar en lista med funktioner. Dessa funktioner är till för att skapa något nyttobjekt till databasen, t.ex. en ny materialgrupp. Dessa sparas sedan och lagras så att när mansedan skapar ett nytt objekt så finns de med som alternativ i comboboxar. När man väljer enav funktionerna så öppnas ett temporärt fönster där det finns olika val att fylla i, dennalösning anses som en bra lösning enligt Jeff Johnson. Att man i grundfönstret bara harfunktioner med behandlade funktionalitet.

Här visas det fönster som man får fram när man vill lägga in en ny produkt i databasen. Det ärstrukturerat så att fält ligger i linje med varandra, den svarta förklarade texten är härvänsterplacerad och avstånden mellan de olika komponenterna gör att man tydligt ser vadsom hör ihop. Valet att använda comboboxar till produktgrupp, materialgrupp och språk berorpå att en ny produkt måste tillhöra en redan befintlig produktgrupp, materialgrupp och språk.Comboboxarna innehåller alla de grupper som finns i databasen. Knappen ”Sök” som finnslängst upp innehåller en funktion som söker igenom databasen så att man inte kan välja attanvända ett redan befintligt artikelnummer. Knappen är placerad nära textfältet så attanvändaren ska förstå att den hör till just detta fält.

4.1.3 Vänster sidaIden med arbetsfönstret är att man ska kunna ha funktionerna synliga samtidigt som man kanse data man jobbar med. Därför föll det sig naturligt att använda ett delat arbetsfönster där enadelen innehåller funktioner och den andra delen ett fönster som redovisar olika data fråndatabasen i en logisk tabell. Det blir lätt och tydligt när man hela tiden kan se hur manpåverkar databasen när man jobbar med sina olika funktioner.

På vänster sida placerades en flikmeny som innehåller ett antal flikar med de olikafunktionerna under sig. Placeringen är gjord så att den funktion som används mest ligger försttill vänster o.s.v. Jeff Johnson skriver om hur man bör forma en flikmeny, t.ex. att inteanvända för många eller att bygga dem ovan på varandra då det gör det rörigt och mindreanvändarvänligt. Alla funktioner som finns under flikarna är till för att ändra redan inmataddata i databasen.

Att flikmenyn placerades med de olika funktionerna till vänster beror delvis på att det ärenklare att bygga det så när man använder JBuilder, men också att det känns bekvämt att hadet så när man jobbar med det. Detta kan bero på att man är van med att börja saker frånvänster och jobba sig mot höger, t.ex. när man skriver och läser.

Illustration 3: Urklipp som visar fönstret som kommerfram när man ska skapa en ny produkt.

4.1.3.1 Flikarna

Det finns sex olika flikar som alla innehåller i stort sett samma typer av objekt som knappar,textfält, comboboxar och radioknappar. När de utformades skulle de givetvis kännas enklaoch tydliga. Bra tips finns i GUI Bloopers av Jeff Johnson.

Knappar ska vara i en storlek så att de är tydliga och lätta att finna. Texten som står i dem skaha ett tydligt budskap som inte är vilseledande som t.ex. knappen ”Ändra” som innebär attman utför en ändring av något eller knappen ”Ta Bort” som innebär att man utför en handlingsom tar bort något från programmet. Valet att placera knapparna längst ner, tätt ihop och gedem likadant utseende i varje flik underlättar för användare som ska lära sig programmet.Knapparna placerades längst ner beroende på att det är med de man ska avsluta när man gjortnågon typ av ändring och därför blir det naturligt för användaren att blicka neråt när man skagå vidare, som t.ex. i en bok.

Comboboxar är ett bra sätt att lösa många problem. I programmet lagras data på olika möbleroch liknande saker som alla har olika attribut och som är indelade i olika grupper, t.ex.möbelgrupper eller materialgrupper. När man har bestämda attribut på objekt är det smidigtatt använda comboboxar. De fungerar så att man får ett textfält med en pil vid sidan där manfår färdiga alternativ att välja mellan, man kan alltså inte skriva i dem. Man ser ett alternativoch trycker man på pilen så visas en lista på de övriga som man kan välja mellan. På så sättundviker man att det skapas massa ”skräp” i databasen. En annan fördel med dem är att de ärlätta att använda.

Radioknappar är bra att ha om man har ett mindre antal alternativ där bara ett är aktivt åtgången. Denna metod är tydlig, användarvänlig och svår att göra fel med. Det är viktigt attplacera radioknappar som hör ihop i en grupp så att man inte kan misstolka vilka som ärrelaterade till varandra.

För övrigt används olika textfält där man vill att användaren ska har möjlighet att kunnaskriva in några fria ord, t.ex. en beskrivning på ett objekt.

I urklippet som visar fliken ”produktgrupp” kan man se hur man generellt har utformatgränssnittet. Svart tydlig text som förklarar vad som visas i textfältet till höger om den, textenär också vänstercentrerad. Allt ligger strukturerat så att de flesta objekten ligger i linje medvarandra vilket förespråkas av Jeff Johnson, allt för att det ska se organiserat och proffsigt ut.Alla fält är dimensionerade så att de passar innehållet bra. I urklippet ser man att knapparnaligger som det beskrevs tidigare och så som anses som en bättre lösning.

4.1.4 Höger sida

4.1.4.1 Lista

Den högra sidan i gränssnittet är mindre komplex än den vänstra då den bara består utav ettfast fönster och inte har ett skiftande utseende som flikmenyn ger. Tanken är att man helatiden ska kunna se och jobba med data från databasen. I JBuilder finns det olika färdiga list-komponenter som man har för att redovisa data på ett bra och tydligt sätt. Många användarekänner igen ett Excel-dokument och för att behålla den trygghet som många känner användsen listkomponent som påminner mycket om ett sådant. Andra fördelar är att det fungerar braatt implementera med en databas.

För att få en bra helhetssyn och möjliggöra att man kan se många olika poster samtidigtanvänds en stor del av fönstrets vänstra sida till listkomponenten.

När man öppnar fliken ”Produkt” så kommer det upp två stycken listor, en för att redovisa deolika produkterna och en som innehåller beskrivningen på produkterna. Detta för att ge entydligare bild av hur de är organiserade.

Illustration 4: Urklipp ur programmet som visarhur fliken produktgrupp ser ut.

4.1.4.2 Valutakurs

På kravspecifikationen efterfrågas en funktion där man kan ställa in valutakursen och på såsätt få priserna i olika valutor. Funktion placerades direkt i arbetsfönstret så att man snabbtkan växla mellan valutorna och undvika onödigt sökande i menyer. Genom att användaradioknappar uppnår man tydliga och enkla val av valutor. Inställningar av dessa gör attendast en valuta kan vara aktiv åt gången.

De är placerade längst ner där de inte är i vägen för mer regelbundet använda komponenter.Samtidigt är det bättre att placera saker som man inte ska titta på så ofta antingen långt nereller långt upp. Det är mest behagligt för huvudet att ha det man arbetar mest aktivt med imitten och det andra vid sidan av. Allt är inramat med en tydlig rubrik i ramen som förklararsyftet med knapparna. Bra avstånd och fet stil för att inte får det rörigt och svårt att ta till sig.En stor knapp har lagts vid sidan av ramen där man aktiverar ändringen av valutan medförklarade och tydlig text för att göra det enkelt för användaren.

4.1.4.3 Visning

För att bestämma vad som ska visas i listan med produkter så behövs en lättåtkomlig funktioneftersom den troligen kommer användas regelbundet och för att undvika onödigt sökande imenyer. Den är placerad längst ner i hörnet, nära listan för att förtydliga relationen mellandem. Två radioknappar visar tydligt vilket visningsläge som är aktiverat. Till den nedre finnsen tillhörande combobox som innehåller alla olika produkter i databasen. Allt är inramat meden fin rubrik för att tydliggöra det hela och gör det snyggt.

4.2 Databas

Databasen som används är Microsoft SQL 2000 och valet av denna databas beror på attföretaget Horreds Möbel AB redan använder sig av just Microsoft SQL. Detta är en mycketbra databas som är erkänd och används av stora företag över hela världen. Den är kraftfull ochenkel att implementera med Jbuilder2005.

4.2.1 DatabastabellernaDatabasen är uppdelad i sex horisontella tabeller som tillsammans handhåller all deninformation en produkt består av. Strukturen kan man se på bilaga 8.

De sex tabellerna agerar tillsammans och skapar en struktur som underlättar överskådlighetenoch gör hela databasen snabbare och mer effektiv jämfört med en databas uppbyggd på enenda tabell. Fem av tabellerna agerar ihop genom uppbyggda relationer medan den sistatabellen som innehåller valutakurser är fristående.

4.2.1.1 Horreds.dbo.Product

Denna tabell innehåller kolumnerna productId(ett unikt artikelnummer), groupId(denproduktgrupp artikeln tillhör), materialId(den materialgrupp artikeln tillhör), picture(en bildpå artikeln) och price(artikelns pris). Denna tabellen agerar tillsammans med tabellernamaterialgrupp, produktgrupp och text. Tillsammans bildar de Horreds Möbel ABs allaprodukter.

4.2.1.2 Horreds.dbo.Productgroup

Tabellen productgroup beskriver alla de olika produktgrupperna bland Horreds Möblersartiklar. Tabellen innehåller produktgruppens nummer, namn och en text som beskriverproduktgruppen.

4.2.1.3 Horreds.dbo.Materialgroup

Denna tabell innehåller information om artiklarnas materialgrupper. Här finnsmaterialgruppernas nummer, namn och en beskrivning sparat.

4.2.1.4 Horreds.dbo.Text

I tabellen text finns beskrivningar över alla produkter på alla de språk Horreds Möbel AB valtatt använda sig av i sin marknadsföring. Tabellen består av artikelnummer, språkkod ochbeskrivning på aktuellt språk. Denna tabellen agerar tillsammans med tabellerna produkt ochlanguage.

4.2.1.5 Horreds.dbo.Language

För att man på ett enkelt sätt ska kunna lägga till ett nytt språk finns tabellen language sombestår av språk och språkkod.

4.2.1.6 Horreds.dbo.Valutakurs

Man kan i programmet växla mellan ett antal olika valutor och tabellen valutakurs innehållerjust alla de valutor Horreds Möbler valt att lägga till, och som dom använder i sinaproduktkataloger. Denna agerar fritt från de andra.

4.3 Kodstruktur

Programmet är uppbyggt med olika klasser vilket är principen med Java, att allt ärobjektorienterat. Detta programs klasser är strukturerade enligt det klassdiagram (bilaga 7)som formades genom UML. I en huvudklass finns funktionen Main och där startar såledesprogrammet vid exekvering. Klassen heter Arbetsfönster och här skapas strukturen ochgrafiken med alla objekt som visas i arbetsfönstret. Här skapas alla instanser av de andraklasserna i programmet, således sker de flesta funktionsanrop här ifrån. Denna klass är denstörsta.

De övriga klasserna är uppbyggda på två olika sätt. De flesta är formade så att de genererar ettnytt fönster och innehåller ett antal funktioner som hör till detta specifika fönster som t.ex.klassen Produkt. Dessa klasser används i huvudsak när programmet lägger till något nytt tilldatabasen, fast själva kommunikationen med databasen sker i en egen klass Datamodule1.Den andra typen av klass genererar inget nytt fönster utan utför bara olika operationer med sinkommunikation med databasen.

Ur den tidigare redovisningen av hur man tillämpar UML fick man fram olika Use Case(bilaga 4), kontrakt (bilaga 6) och ett klassdiagram. Dessa används som beskrivits vidimplementeringen för att forma klasserna och programmet. Här följer en beskrivning av denkod som blev slutresultatet av detta arbete, här specificerat kring klassen Produkt.

4.3.1 Lägg till ny produkt (addProduct)Denna kod skapades för att kunna skapa en ny produkt till databasen.

//Funktionen innehåller ett antal olika variabler, alla skickas med när man anropar funktionen.public boolean addProduct(String pId, String gId, String pict, double price, String mId, Stringla, String pText){//Öppna dataset i databasen så att man kan kommunicera med den

product.open();text.open();textAll.open();

//Skapar textsträngarString[] prodStr = {"productId"};String[] textStr = {"productId","language"};

//Skapar temporära dataplatser med de två textsträngarnaDataRow datarowProdTemp = new DataRow(product,prodStr);DataRow datarowTextTemp = new DataRow(textAll,textStr);

//Tilldelar strängarna det värde som skickades med vid funktionsanropetdatarowProdTemp.setString("productId",pId);datarowTextTemp.setString("productId",pId);datarowTextTemp.setString("language",la);

//Kontrollerar om det finns en liknande produkt i databasen genom att jämföra de temporäradatasetraderna med de tillgängliga. Om inte, tilldelas de olika platserna i databasen de värdensom skickats med och det skapas en ny plats i databasen.

if(!product.lookup(datarowProdTemp,datarowProdTemp,8 | 32)){

DataRow datarowProd = new DataRow(product);datarowProd.setString("productId",pId);datarowProd.setString("groupId",gId);datarowProd.setString("picture",pict);//datarowProd.setInputStream("picture",pict);datarowProd.setDouble("price",price);datarowProd.setString("materialId",mId);product.addRow(datarowProd);

}

//Kontrollerar om det finns en liknande produktbeskrivning i databasen genom att jämföra detemporära datasetraderna med de tillgängliga. Om inte, tilldelas de olika platserna i databasende värden som skickats med och det skapas en ny plats i databasen.

if(!textAll.lookup(datarowTextTemp,datarowTextTemp,8 | 32)){DataRow datarowText = new DataRow(textAll);datarowText.setString("productId",pId);datarowText.setString("language",la);datarowText.setString("text",pText);textAll.addRow(datarowText);text.refresh();

}

//Spara ändringarna av produkt- och text-datasettenupdateProduct();product.refresh();textAll.refresh();return true;

}

4.3.2 Skapa tabellen materialgruppFunktion som ställer en fråga till databasen och fyller upp ett dataset som innehållerinformation (material-id och beskrivning av materialet) om materialgrupperna.

materialgroupAll.setQuery(new com.borland.dx.sql.dataset.QueryDescriptor( database1,"SELECT Materialgroup.materialId,Materialgroup.material FROM " +"Horreds.dbo.Materialgroup", null, true, Load.ALL));

5. Applikationens felhantering och hjälpinstruktioner

Varje dataprogram utsätts för användare med olika erfarenheter av datorprogram och som mereller mindre skapar situationer som utvecklaren inte förutsett under utvecklingen. Dessasituationer kan leda till osäkerhet när programmet ska användas eller att program låser sig ochviktig data eller tid kan gå förlorad, vilket kan bli kostsamt. En manual hjälper användaren såatt programmet används korrekt och ett felhanteringssystem säkerställer programmetsfunktionalitet. Att motverka allt är svårt då man inte kan förutse alla fel som kan uppkomma,men genom erfarenhet kan man motverka mycket.

5.1 Manualen

En manual är svår att utforma då den ska vara tilltalande och enkel att förstå, även för ennybörjare. Genom att använda urklipp från programmet när man beskriver funktioner ansesofta som mer användarvänligt än bara text. Att en bild säger mer än tusen ord är ett allmäntkänt uttryck. Därför är detta programs manual utformad med många förklarade bilder medtillhörande text. Manualen går igenom varje funktionen med grundläggande stegmoment, därvarje händelse beskrivs med så enkelt språk som möjligt.

5.1 Felhanteringsfunktion

I detta program finns en felhanteringsfunktion som bygger på Java-exceptions, vilket innebäratt programmet testar (try) data som t ex en användare skrivit in, och om den skiljer sig frånvad som är tänkt så fångar (catch) programmet in detta och utför en operation som kan varaatt meddela användaren med t ex ett varningsfönster som meddelar användaren att skriva inett nytt värde

Här följer ett stycke ur programmets kod och som visar principen med felhanteringsystemet.

Funktionen tar del av en händelse, en ”ActionEvent” av händelsen ”e”. Programmet försökerutföra händelsen ”e” i ”try-blocket” och om det inte fungerar så skapas ett ”Exception” ”ex”

som fångas upp med funktionen catch som utför en del moment. Detta fall beskriver enuppdatering av valutakurs och som skapar en feltext om det uppstår ett fel.

public void CurDeleteBtn_actionPerformed(ActionEvent e){

try{

datamodule1.valutakurs.deleteRow();datamodule1.updateValuta();

}catch (Exception ex){datamodule1.valutakurs.refresh();jdbTable1.setDataSet(datamodule1.valutakurs);System.out.println("Valuta NOT deleted");System.err.println("Exception: " + ex);

}}

6. Problem

Enligt kravspecifikationen skulle det efterfrågade programmet kunna visa så kallade EPS(enhanced post script)-bilder och även innehålla en funktion för att generera en fil som etttryckeri skulle kunna använda sig av i produktionen av en fysisk produktkatalog till HorredsMöbel AB.

Problemet med EPS är att det inte finns någon färdig modul i JBuilder2005 som kan hanteradetta filformat. Programmet klarar däremot vanliga filformat som jpeg, gif etc. Dåuppdragsgivaren inte hade bilderna av produkterna som programmet skulle hantera i något avdessa filformat så fick man undersöka alternativen. En konvertering av bilderna underexekveringen kunde vara ett av dem, men skulle vara oerhört tids- och prestandakrävande.

När databasen formats och kommit långt i utvecklingen upptäcktes en del brister som inte haråtgärdats utan mer konstaterats. Dessa brister upptäcktes vid granskandet av språkval vidskapandet av nya produktgrupper och materialgrupper. Problemet innebär att man harmöjligheten att skapa specifika produkter med olika språk men inte för de olika material- ochproduktgrupperna.

6.1 Tidsaspekten

Detta examensarbete har dragit ut på tiden väldigt mycket och därför kan man kanske väntasig en förklaring till detta. Problem som skapade stort tidsförluster förekom och är något sombör undvikas i alla projekt.

Genom möten med ansvarig projektledare lades en grund upp med en kravspecifikation somrymde tillräckligt med information att gå vidare, dock efter en hel del diskussion där denprojektansvarige visade blandat intresse. Planen med att forma programmet med metoden UPtogs och arbetet med verktygen i UML började. Motgångar som gjorde att situationen börjadebli tidkrävande var ett antal olika saker. Bristande intresse från arbetsgivare skapar dåligagrunder och ökar inte arbetsinsatsen. Att det brast i drivkraft gör inte situationen bättre.

Avvikelser från hur man arbetar med UP och dess verktyg i UML gör att det skapar fel sombildar en tidskrävande uppförsbacke.

7. Diskussion

7.1 Applikationens utformning och design

När man formger ett programs användargränssnitt så finns det inga regler som säger vad somär rätt och fel, däremot finns det många dokumenterade råd om hur man bör formagränssnittet för att det ska bli användarvänligt. Dessa råd baseras på erfarenhet från tidigareprogramutformningar och hur dessa har bemöts av användare. Mycket som litteraturenbeskriver är de utformningar där den mänskliga uppfattningsförmågan spelar roll för hur mangör. Helt enkelt hur en person generellt uppfattar olika färger, former och texter. I många fallbeskrivs det hur gränssnitt formats på ett sätt som gör att användare får svårt att användaprogrammet. Sådan information är viktig att ha med sig när man ska designa sitt gränssnittoch gör att man kan spara mycket tid och således även pengar för företaget genom att göradem nöjda snabbt. Att tänka på är att varje individ är unik och således inte blind lita pålitteraturen utan som utvecklare bedöma varje detalj ur kundens synvinkel.

Litteraturen beskriver även utformningar som gör att program inte fungerar riktigt,beskrivningar om hur utvecklare missat en knapp eller skrivit en felaktig rubrik.Grundläggande fel som inte bör passera utvecklingsstadiet och som enklast upptäcks genomatt testa programmet noga innan det levereras. Men då det är lätt att stirra sig blind på sinaegna saker så är det att rekommendera att låta någon utomstående testa programmet.

Den generella tanken vid utformningen av detta program var att ha ett vanligt allmänt användprograms gränssnitt som underlag, t ex Microsoft Office. Det skapar igenkännande och gör attprogrammet uppfyller de råd som givits från litteraturen som var underlag vid utvecklingen.

Specifika lösningar på enskilda grafiska och/eller funktionella problem går att diskutera, t exförespråkar man att combobox kan vara bra för att det spara utrymme och ge merprofessionellt intryck. Men att det blev radioknappar berodde mer på estetiska skäl. Detkändes tydligt, enkelt och snyggt. Med en mer avancerad utveckling av programmet så kanman överväga att gå från dessa då det skulle bli platskrävande.

7.2 Applikationens programmeringsstruktur

Att koden har den struktur den har beror framför allt på att det känns mest logiskt att formaden så. En grundklass som hantera det grafiska och ser till att arbetsfönstret får sin strukturoch sedan ett antal klasser som hanterar de stora funktionerna. Att strukturera det så här gördet lättare för mer oerfarna programmerare att kunna överblicka och arbeta med den.

Man kan säkerligen göra den mycket mer komplex och effektiv, allt handlar om erfarenhet,kunskap och tid. Då många av funktionerna har liknande funktionalitet så skulle man kanskekunna skapa mindre antal klasser som var mer mångsidiga. Funktioner som används för fleraändamål. En nackdel emellertid kan vara att det uppstår problem så kan det bli svårare att lösadet vilket det inte blir med mer uppdelade klasser och funktioner.

7.3 Databasens struktur

Horisontella tabeller innebär att tabellen har en fast mall med ett bestämt antal kolumner ochatt man är tvungen att bygga om modellen med fler kolumner om man vill lägga till nyaattribut. Fördelen med detta är att den inte tar så mycket plats i minnet. En dynamisk lösningkanske kunde upplevas som överambitiöst då programmet inte har flexibel data utan är merbestämd. En möbel har exempelvis ett visst antal attribut eller egenskaper.

7.4 Applikationens felhantering

Att programmet skulle ha någon typ av felhanteringssystem är inget svårt val då saknadenskulle vålla mycket stora risker vid användandet av programmet. Minneshanteringen sköterprogramspråket Java, så man behöver inte tänka på minnesallokering men kontrollen att t.ex.rätt data skrivs in i rätt fält är viktigt då en bokstav istället för en siffra kan få en algoritm attlåsa sig och således få programmet att krascha. Även databasen skulle troligen fyllas medskräpdata som tar minne och som kan leda till framtida problem.

7.5 Applikationens hjälpinstruktioner

En bra manual är a och o för att ett program ska vara lätt att ta till sig för en ovan användare.Den ska innehålla tydliga beskrivningar om hur alla funktioner fungerar i programmet och hurman går till väga när man använder dem, helst med stegprincipen. Den bör även innehålla endel som beskriver hur man gör felsökningar när man råkar ut för problem. Att skriva enmanual är svårt, man vill göra den enkel så att alla förstår men samtidigt inte så enkel att folkkänner sig stötta. Språket får inte innehålla massa fackliga ord som en nybörjare inte kännertill och som skapar uppgivenhet.

I dagens utvecklade IT-samhälle kan en pappersmanual anses bakåtsträvande och nyaprogram innehåller ofta en digital manual som aktiveras genom menyn eller någotsnabbkommando. Man bör ha båda, då användandet av en digital manual kan uppfattas somkrånglig. En digital manual behöver inte ha samma grundläggande utförande som en påpapper. Då användaren som klarar av den ofta har högre kunskap om data enpappersanvändare.

Till detta program finns endast en pappersmanual och då användarna klassas som nybörjare ärdetta en tillräcklig lösning av hjälpande dokument. Manual är uppbyggd så att den stegvis gårigenom varje funktion med bilder och enkel text för att gör det så enkelt som möjligt förläsaren. En digital manual bör införas i en nyare version av programvaran och det har gjortsplats för en sådan i programmet.

En vanligt förekommande del i en manual är ett kapitel där man möjligen kan finna lösningenpå enklare fel i programmet, om det inte fungerar som det ska. Ett sådant kapitel finns inte dåprogrammet är väldigt lite och då inget enklare fel är kända.

7.6 Tidsaspekten

Man kan fråga säg vad som skulle ha gjort för att inte hamna i den situation som gjort attarbetet dragit ut på tiden. Det är ingen idé att gå in på det personliga och börja hacka utan merse helheten.

Det första misstaget som gjordes var att påbörja ett tidskrävande arbete då det varken fannstid eller motivation att utföra det. Och det kan man väl skriva som en grundregel, att alltid hatid och drivkraft då man antar en utmaning.

Att delegera ut ett arbete och sedan inte visa något större intresse för att det fullföljs är endålig kombination. Att sedan inte vara stödjande när det svajar är lika dumt. Om företagethade visat större intresse för vad som gjordes och varit mer drivande och stödjande hade detnog aldrig gått så långt som det gjorde. Med rätt stöd så hade problem som fanns kunnatlösas.

Att avvika från den arbetsmetod man val skapar också problem. Att hoppa över något stegoch rusa fram med uppgiften skapar en obalans och luckor som gör det hela merarbetskrävande. Vid ett projekt gäller det att tydliggöra arbetssätt och metoder tidigt ochsedan jobba enligt dem utan avvikelser. Hade arbetets följt UML utan avvikelser hade detförmodligen gett en struktur i projektet som gjort det hela stabilare. Orsaken till att detuppstod avvikelser beror på bristande erfarenhet hur man jobbade enligt modellen och att manlätt undviker delar som uppfattas som tråkiga och onödiga vilket är ett dåligt antagande.

8. Slutsats

Att utveckla ett dataprogram är en process som kräver bra tillvägagångssätt för attslutresultatet ska bli bra. Rätt utvecklingsverktyg och program kan göra stor skillnad. UML(Unified Modeling Language) anses som ett bra verktyg och det är bara att hålla med. Att detsedan är lite svårt att tillämpa det är en annan sak, det handlar mest om erfarenhet vilket detav naturliga orsaker fanns lite av. När man jobbar med UML är det viktigt att hela tiden görade olika stegen i den ordning som förespråkas. När man går händelserna i förväg möter manbara en större trappa och det blir bara mer jobb. Det finns inget som säger att man måste göraalla stegen och hur man tillämpar dem och det är en avvägning man får göra under tiden manjobbar, lite beroende på jobbets storlek m.m. Men den hjälper en att lägga en bra grund för ettfint program. Allt som tas fram behövs inte användas men kan fungera som bra riktlinjervilket också kanske är ett syfte.

När det gäller implementering och att jobba med JBuilder2005 och Java så gav det braerfarenhet om hur de nyare grafiska programmeringsverktygen fungerar. Det är roligare ochenklare att hela tiden se vad man jobbar med och hur det ser ut. JBuilder2005 är ett trevligtoch användarvänligt program där de färdiga funktionerna som finns tillgängliga gör det helaenklare. Implementeringen mot databasen var inte svår, men något krånglig i början dåerfarenheten av databaskopplingar i Java var dålig vilket gjorde att det också blevtidskrävande. Att programmera och felsöka ett program är också tidskrävande och svårt.Framför allt bugg-/felsökningen då det är svårt att veta vad man ska söka efter. En del fel harupptäckts men det är svårt att inte misstänka att det finns fler. Men det är ett problem som allautvecklare har och som bara tid och pengar kan bota. Det som upptäcktes är åtgärdat ochprogrammet fungerar tillfredsställande.

Att tiden varit en speciell del av detta arbete går inte att förneka och att det tagit lång tid attfärdigställa är minst sagt anmärkningsvärt. Att se till att man har tiden som krävs vid tillfälletdå man antar utmaningen är väldigt viktigt för att undvika samma misstag. Och samtidigtgäller det att ha rätt motivation och känna att man har orken, man startar inte ett projekt utanatt se möjligheten att nå målet.

Referenslista

Skansholm, J. (2004) Java direkt - med Swing. Lund: Studentlitteratur.

Booch, G., Rumbaugh, J., Jacobson, I. (2000) The Unified Modeling Language User Guide.Addison-Wesley

Booch, G., Rumbaugh, J., Jacobson, I. (1999) The Unified Software Development Process.Addison-Wesley

Johnson, J. (2000) GUI Bloopers: Don'ts and Do's for Software Developers and WebDesigners. : Morgan Kaufmann.

Connolly, T., Begg C. (2002) Database Systems. Harlow: Pearson Education.

Ronne, E. (1999) Java. Stockholm: Docendo Läromedel AB

Kursdokument om UML, kursen Mjukvarudesign (2001) Högskolan Borås

http://java.sun.com/javase/6/docs/api/ (2009-04-25)

Projekttitel:

Produktkatalog Horreds Möbel AB

Datum:

18/1-2009

Version:

2Författare:

Mathias Nilsson

Dokumenttitel:

Bilaga 1: Kravspecifikation

Kravspecifikation databas för prislista Horreds Möbel AB

1. Databasen skall innehålla alla Horreds artiklar med priser och symboler

2. Databasen skall vara enkel att uppdatera med nya produkter, både text, priser ochsymboler.

3. Prislista skall finnas i flera språk, idag Svenska, Danska och Engelska. Det vore bra omdet finns en funktion för att lägga till ytterligare språk.

4. Valutahantering ska vara inbyggd, vi vill själva sätta valutakursen manuellt.

5. Priserna ska kunna höjas på ett enkelt sätt med en procentsats. Det är en fördel om mankan höja olika produktgrupper med olika många procent. Det är även en fördel om mankan höja vissa priser manuellt.

6. Databasen ska kunna sammanställas så att den rent grafiskt ser ut som nuvarande prislistapå ett ungefär.

7. Prislistan ska kunna sparas i olika format, t.ex. PDF och XLS. Om ni har fler förslag påformat som kan vara bra så är det välkommet.

Projekttitel:

Produktkatalog Horreds Möbel AB

Datum:

18/1-2009

Version:

2Författare:

Mathias Nilsson

Dokumenttitel:

Bilaga 2: Begreppslista

Namn Beskrivning TypAktiv användare Den användare som har möjlighet att redigera databasens tabeller

Användare Någon som ittererar med systemet

Artikel En produkt i databasen

Artikelnummer Identifierings tal för en enskild produkt Attribut

Comboboxar Benämning på en sk. rullgardin, vid ett knapptryck på komponenten visas ett antal valmöjligheter i en lista

Databas Lagring av data i tabeller

Flikmeny En meny uppbygd av flikar för att separera olika funktionaliteter och göra gränssnittet användarvänligt

Färg Färg på bakgrunden i programmet Furnie

Id-nummer En del av ett artikelnummer som betecknar en produkt- eller materialgrupp

Listverktyg Komponent som grafiskt visar en eller flera poster som finns lagrade i databasen

Möbelgrupp En samling produkter som är samlade under samma Id-nummer

Nyckel Identifieringsparameter för en post i en databastabell

PDF Filformat

Poster Enhet i databasen

Primäraktör Direkt avändare av programmet

Pris Prisbeskrivning av en produkt Attribut

Procentsats Ett procenttal som används när man beräknar nya priser på produkterna Attribut

Produkt En artikel i Horreds Möbels databas Klass

Produktgrupp Flera artiklar tillhörande en viss grupp produkter specificerade av Horreds Möbel AB

Radioknapp En komponent som används vid vals ituationer då användaren endast har möjlighet att göra ETT val

Redigera Programdel där man hanterar olika produkter, genom att kunna ändra de olika parametrarna i produkterna

Redovisningsfält Komponent som grafiskt visar en post eller en del av en post som finns lagrade i databasen

Språk Språk på textbeskrivning av en produkt i produktkatalogen

Symbol Bildobjekt som beskriver en produkts utseende Attribut

Systemanvändare En användare som inte har rätt att redigera databasens tabeller

Text Textbeskrivning av en produkt i produktkatalogen Attribut

Textfält Ett fält där inmatning är möjlig

Valutahantering Hantering och val av valutakurser

Valutakurs En kurs på en vald valuta Attribut

XLS Filformat

Projekttitel:

Produktkatalog Horreds Möbel AB

Datum:

18/1-2009

Version:

2Författare:

Mathias Nilsson

Dokumenttitel:

Bilaga 3: Use Case-diagram

Projekttitel:

Produktkatalog Horreds Möbel AB

Datum:

18/1 2009

Version:

3Författare:

Mathias Nilsson

Dokumenttitel:

Bilaga 4: Use Case: Lägg till ny produkt

Namn: Ny produkt i databasenÖversikt: Syftet är att en användare ska lägga till en ny produkt till databasen,

genom att ange pris, produktsymbol, beskrivningstext ochartikelnummer.

Primäraktör: Aktiv användareSekundäraktör:Utgångspunkt: Primärfönstret i programmet.Mätbart slutresultat: En ny produkt har lagts till i databasen.Flödeshändelse:

1. Väljer produkt i en rullgardin som visas efter att användaren trycktpå knappen lägg till.

2. Ett nytt fönster visar ett antal fält där de olika parametrarna fylls i.3. Anvädaren fyller i det nya artikelnumret och trycker på sök för att

kontrollera att det aktuella numret inte redan finns.4. De resterande parametrarna fylls i.5. Användaren trycker på knappen bifoga bild och väljer i ett

sekundärt fönster vilken bildfil man vill bifoga till produkten ochtrycker ”OK”. Det sekundära fönstret stängs och man återkommertill fönstret lägg till ny produkt.

6. När allt är färdiginmatat trycker användaren på knappen ”OK”.7. Den nya produkten läggs till i databasen.

Avslutande del: Återgår till primärfönstret.

Alt. flödeshändelse: 1. Trycker på knappen ”Cancel” i fönstret lägg till ny produkt.

Avslutande del: Programmet återgår till primärfönstret och inga ändrar har gjorts.

1

Projekttitel:

Produktkatalog Horreds Möbel AB

Datum:

18/1-2009

Version:

3Författare:

Mathias Nilsson

Dokumenttitel:

Bilaga 5: Systemsekvensdiagram: Lägg till ny produkt

Projekttitel:

Produktkatalog Horreds Möbel AB

Datum:

18/1-2009

Version:

2Författare:

Mathias Nilsson

Dokumenttitel:

Bilaga 6: Kontrakt: Lägg till ny produkt

Namn: LaggTillProdukt(string artikelNummer, string beskrivning, double pris, filesymbol)

Ansvar: Ansvarar för att lägga till en ny produkt i databasenTyp: voidReferens: Use Case Lägg till ny produktNoteringar:Undantagsfall: Produkt finns redan i databasenReturvärde: ingetUtgångsläge: Användare vill lägga till produktSlutläge: Produkt skapad i databasen

Projekttitel:

Produktkatalog Horreds Möbel AB

Datum:

5/4-2009

Version:

3Författare:

Mathias Nilsson

Dokumenttitel:

Bilaga 7: Klassdiagram/Systemarkitektur

Projekttitel:

Produktkatalog Horreds Möbel AB

Datum:

5/4-2009

Version:

2Författare:

Mathias Nilsson

Dokumenttitel:

Bilaga 8: Databasstruktur