TN Transport og Spedition PROJEKT

Transkript

1 1 TN Transport og Spedition PROJEKT TN Transport og Spedition PROJEKT 2 semesters projekt på datamatiker uddannelsen på UCN. Skrevet efteråret DM67 gruppe : Jeanette Nielsen Side 1

2 2 TN Transport og Spedition PROJEKT University College Nordjylland Sofiendalsvej 60 Postboks Aalborg Tlf.: Fax: Mail: Titel: TN-Transport Projektperiode: 1 september december 2009 Deltagere: Jeanette Nielsen Synopsis: Denne rapport er en dokumentations rapport for projektforløbet på 2 semesteret på datamatiker uddannelsen på University College Nordjylland. Projektet omhandler en real case og er mit første forsøg til at lave et system til en konkret virksomhed. Der er tale om et fakturerings system til en mindre vognmandsvirksomhed. Projektet lægger derudover stor vægt på selve læringsprocessen og denne rapport udgør derfor en væsentlig del af projektet. Side 2

3 3 TN Transport og Spedition PROJEKT Forord Rapporten er dokumentation på et 2 semester projekt på datamatiker uddannelsen på UCN (University College Nordjylland). Emnet TN-Transport og Spedition er et selvvalgt emne, udarbejdet ud fra et virkeligt firma. Selve projektarbejdet har foregået ud fra UP metoden og har hentet inspiration i bøger fra studiet samt Objekt Orienteret Analyse og Design (se litteraturlisten). Læsevejledning: Rapporten er delt op i 5 dele. Hver del starter med et kort referat af afsnittets resultater. Del 1. STUDIERAPPORT. Første del er en studierapport der dokumentere arbejdsforløbet og de erfaringer jeg har gjort mig gennem projekt perioden. Del 2 Forberedelse. Anden del indeholder it-forundersøgelse, case beskrivelse samt systemdefinitionen. Del 3 DESIGN & ANALYSE. Tredje del indeholder dokumentation for system, database og brugergrænseflade valg og design, samt overvejelser herom. Del 4 IMPLEMENTERING & TEST. Fjerde del indeholder kommenteret kode samt beskrivelse af udførte tests og implementerede testklasser. Del 5 BILAG. Femte del indeholder kildefortegnelse, bruger og installations vejledninger samt supplerende diagrammer og SQL scripts. System vejledning Brugsvejledning og installations guide findes i bilagene. Ved prøvning af systemet vil du støde på en række elementer som endnu ikke er implementeret eller som endnu ikke har en funktion: I TurEditoren mangler Pris Beregner. Denne funktion er ikke implementeret. Der er gjort klar til den dog så knappen er klik bar men den vil blot vise et blank vindue. I KundeGUI en er bogfør funktionen under fakturaer og tjeckboksen udenlandsk adresse ikke implementeret. I Faktura Udkast er moms funktionen endnu ikke implementeret, grundet denne del af systemets sene og tidspressede implementering. Side 3

4 4 TN Transport og Spedition PROJEKT INDHOLDSFORTEGNELSE FORORD... 3 DEL 1 - STUDIERAPPORT... 5 PROJEKT MÅL... 6 KONKLUSION... 9 DEL 2 - FORBEREDELSE...10 CASE BESKRIVELSE KORT INTRODUKTION TIL TN-TRANSPORT IT-FORUNDERSØGELSE...13 VIRKSOMHEDENS MÅL OG STRATEGI SWOT IT- STRATEGI OG HANDLINGSPLAN SYSTEMDEFINITION DEL 3 - ANALYSE & DESIGN...21 ANALYSE...22 PROBLEMOMRÅDET ANVENDELSESOMRÅDE BRUGERGRÆNSEFLADE...29 ANALYSE KONKLUSION DESIGN...35 DATABASEDESIGN: DEL 4 - IMPLEMENTERING & TEST...42 IMPLEMENTERING...43 TEST...48 DEL 5 - BILAG...54 KILDER...55 SOFTWARELISTE LITTERATURLISTE INSTALLATIONS VEJLEDNING:...56 DRIVER OPSÆTNING: BRUGERVEJLEDNING:...58 SQL SCRIPTS...61 EKSTRA SEKVENS DIAGRAMMER...61 BILAG TIL DESIGN KLASSE DIAGRAMMET KLASSE BESKRIVELSER...61 Side 4

5 5 TN Transport og Spedition PROJEKT DEL 1 STUDIERAPPORT Referat Målet med projekt forløbet er at opnå større indsigt i system udvikling gennem en opgave, i dette tilfælde system udviklingen af et yderst brugervenligt regnskabssystem til TN-Transport. Studierapporten vil kort gennemgå arbejdsforløbet igennem projektet i henhold til UP metoden. Samt indeholde en slut konklusion på projekt forløbet, og hvorvidt det lever op til målene og opgaven beskrevet i Projekt mål. Side 5

6 6 TN Transport og Spedition PROJEKT Studie Rapport Projekt mål Jeg har valgt casen TN-Transport til mit 2 semesters projekt. Opgaven er beskrevet ved TN-Transport som ønsker et regnskabsprogram til faktura skrivning med en integreret database over fakturaer, kunder, ansatte og køretøjer. Mit mål med projektet er at opnå større indsigt i databasens praktiske anvendelse, og anvende UML i et omfang der gør mig i stand til at designe og implementere et program der lever op til min system definitions målsætninger. At få et færdigt og brugbart system er et mål, men læringsprocessen er min hovedprioritet. For at have en chance for at opnå et brugbart system, skal systemet laves enkelt og passe til mit erfarings niveau. Indhold Rapporten er dokumentation på et 2 semester projekt på datamatiker uddannelsen på UCN (University College Nordjylland) Emnet TN-Transport og Spedition er et selvvalgt emne, udarbejdet ud fra et virkeligt firma. Oprindeligt var vi en gruppe på 3, men grundet forskellige ambitions niveau valgte jeg at lave projektet alene. Dette har betydet en masse ekstra arbejde, men giver samtidig en dybere forståelse for systemudviklingen, da man selv har arbejdet grundigt med alle dele i processen. Selve projektarbejdet har foregået ud fra UP metoden og har hentet inspiration i bøger fra studiet samt Objekt Orienteret Analyse og Design (se litteraturlisten). Projektet startede officielt ved studiestarten i september 2009, og har kørt sideløbende med undervisningen indtil slutningen af november hvorfra der næsten udelukkende har været projekt dage. Overordnet tidslinje fra september til d. 21 december 2009: September 2009 September-oktober Oktober Slutningen af oktober Projekt start - udvikling af IT-forundersøgelse - analyse af problem og anvendelses område - gruppen deles November December - System design, samt implementering af simple programdele. Design af databasen. - System design, database rettelser og implementering Side 6

7 7 TN Transport og Spedition PROJEKT 12. december - planlagt programmerings stop (måtte forlænges til den 15) december - Test og rapport skrivning Når der skrives programmerings stop menes der at der ikke implementeres noget nyt. I forbindelsen med testen vil der uundgåeligt blive rettelser af mindre eller større fejl. UP-metoden Der er arbejdet efter UP metoden, hvilket har medført at systemet løbende har ændret sig designmæssigt. De grundlæggende funktionskrav blev fundet igennem it forundersøgelsen, samt analyse af virksomheden, især i form af mockups der blev uarbejdet og gennemgået med brugeren. Der er løbende blevet tilføjet nye mindre funktioner efterhånden som forståelsen for brugen og de designmæssige aspekter blev større. Hvorvidt det er lykkedes at lave et egentlig UP udviklingsforløb kan diskuteres. Projektets størrelse taget i betragtning er det utroligt svært at arbejde efter UP metoden. I normale udviklingsprojekter består hver iteration normalt vis på 5-6 uger. Da der har været undervisning sideløbende med projektet har den reelle projektlængde kun været 1-1½ måned. Dette sætter jo naturligvis nogle begrænsninger i forhold til mængden af iterationer. Grundlæggende er der 4 dele i UP metoden som hver afsluttes med en milestone ligesom vandfaldsmodellen. Forskellen er bare at disse 4 dele er delt op i iterationer. Figur 1- Unified Process(UP) - Hver iteration indeholder et mini-vandfald. I starten af projektet vil iterationerne indeholde meget analyse og buisness modeling hvorimod det i de sidste iterationer vil være implementering test og overdragelse der bruges mest tid på. Antallet af iterationer i hver hoved iteration afhænger af det ønskede systems kompleksitet og prioriteringerne i systemet. Et forslag til et iterativt UP forløb er vist på figuren. Det der adskiller UP metoden fra vandfaldmodellen er at systemet ændres sig i takt med udviklernes indsigt i systemet. Der vil altid opstå problemer man ikke havde planlagt på forhånd, ved UP metoden, er der mulighed for at man kan genoverveje designet og tilpasse det, så der opnås en ideel problemløsning. I vandfaldsmodellen er du bundet af tidligere krav og design beslutninger, og der vil ofte være lappe-løsninger. Side 7

8 8 TN Transport og Spedition PROJEKT Så når jeg nu vil gennemgå de fire hoved iterationer er det vigtigt at huske at grænsen mellem iterationerne er flydende, der vil blive ændret i arbejde fra design og analyse helt frem til slutningen af konstruktions fasen, dog i mindre og mindre grad jo længere i forløbet man når. Da det er et mindre program og jeg kun er en person har det ikke været muligt at have en færdig funktionel system del ved slutningen af hver iteration, da jeg enten havde valget mellem meget få iterationer eller mange små med færre krav. Derfor har jeg lidt utraditionelt valgt at bruge centrale design og analyse produkter som fx en domænemodel eller mockups som resultat af enkelte iterationer. Følgende hovedforløb indgår: Forberedelse (inception) Denne iteration er ikke delt ind i under iterationer. I denne hoved iteration, er it-forundersøgelse udviklet. Der startes på analyse af anvendelses og problem området. Det færdige produkt efter denne iteration er mock-ups. Varighed (september til midten af oktober). Etablering (Elaboration) Denne hoved iteration er delt op i flere under iterationer. 1. iteration. Der bliver fulgt op på de funktionelle krav, der blev fundet gennem itforundersøgelse og analyse af problem området. Det resulterede i næste generation af mock-ups, samt første udkast til en design klasse diagram og en domæne model. Varighed: oktober. 2. iteration fokuserede på database og system design. Resultatet af denne iteration var en relationel database model, design overvejelser. varighed: første halvdel af november 3. Iteration. Oprettelse af databasen. implementering af "Walking skeleton"(systemets design med tomme metoder). Samt indsættelse af postnr-by i databasen og implementeret i systemet. varighed: 1 uge. Konstruktion (Counstruction) Denne iteration er delt op i flere iterationer, som hver vil ende ud i en færdig systemdel. 1. Iteration. videre design af systemet. Kunde use-casen implementeres, og de første tests kan begynde. varighed: slutningen af november. Side 8

9 9 TN Transport og Spedition PROJEKT 2. Iteration. Kunde use-casen testes. Grundet prioritering i systemet, implementeres tur, selvom det ville være mere hensigtsmæssigt at udvikle alle de mere simple CRUD use-cases først. Tur use-casen implementeres, sammen med der løbende udføres funktions og database tests. Varighed. 29-nov - 11 december. 3. Iteration. Faktura implementeres og testes kort. White og blackboxtests bliver foretaget i mindre grad på tur use-casen. varighed: december. Overdragelse(Transition) Der er ingen iterationer under test da jeg ikke nåede så langt. Konklusion på brug af UP metoden. Konstruktions iteration er ca. en tredjedel gennemført. Selv med små projekter kræver det en større gruppe at nå længere i udviklingsforløbet. Det største problem har været at nå til konstruktionen af de mere spændende use-cases. Havde jeg startet med de simple use-cases og arbejdet mig op ad havde jeg ikke nået til de højest prioriterede use-cases: Tur og FakturaUdkast. Alt i alt har det været mere struktureret end tidligere arbejdsforløb og jeg har nået du overordnede tidsfrister jeg har sat, men tidsplanen kunne med fordel have været mere detaljeret planlagt.. Konklusion Jeg synes formålet er nået. Med hensyn til database, har jeg lært en masse nye problemstillinger og hvorledes disse løses. I enkelte situationer har det ikke været muligt at løse fejlene da programmet systemet er skrevet i (netbeans) og det databasen er lavet i (MS SQL) ikke snakker 100 % sammen. At have arbejdet alene har været meget lærerigt og jeg har opnået et meget større kendskab til UML og tests. Programmerings har jeg ikke lært så voldsomt meget nyt, men til gengæld udviklet større sikkerhed i mine problemsøgnings- og fejlretnings-teknikker, samt fået større rutine generelt. Hvad jeg har arbejdet mest med er database laget og GUI'en. Mine læringsmål er nået, men rent praktisk har det ikke været muligt at frembringe et brugbart system, da dette ville have kræve væsentlig mere tid. Side 9

10 10 TN Transport og Spedition PROJEKT DEL 2 FORBEREDELSE Referat TN-Transport Transport og Spedition er et lille vognmandsfirma med stor branche erfaring. Det har i mange år overlevet på sit gode ry og service, men prispresset fra udenlandske vognmænd bliver stadig større. Grundet den skarpe konkurrence har der været stor nedgang i firmaet og udvidelse er derfor ikke en mulighed. Strategien er at overleve på god service. Men da service alene ikke kan gøre det er firmaets arbejdsgange nødt til at blive effektiviseret. Der ligges stor vægt på brugervenlighed og simple arbejdsgange. Firmaets arbejdsgange er gammeldags dette skyldes hovedsageligt, Torben Nielsen s (ejeren af TN-Transport) manglende it-kendskab. Derfor ønskes et meget brugervenligt system som effektivisere virksomhedens arbejdsgange nærmere end at ændre dem. Kreditnota anvendes i firmaet som betaling til de vognmænd der kører for firmaet. Dette er utraditionelt men et fast krav fra virksomhedens side. It-forundersøgelsen viser at firmaet har en fornuftig økonomi de seneste år på trods af nedgangen, men størrelsen taget i betragtning kan det ikke anbefales at investere i udviklingen af et nyt it-system. Dette ser vi dog igennem fingrene med da dette er et lærings projekt og økonomien derfor ikke er vigtigt da der ingen udgifter er til udvikling. Side 10

11 11 TN Transport og Spedition PROJEKT CASE beskrivelse kort introduktion til TN-Transport TN-Transport er et vognmands og speditions firma drevet af vognmand Torben Nielsen. Firmaet omfatter 1 chauffører (Vognmanden selv), 2 lastbiler og 7 trailere. Derudover har han 3 freelance/ indlejede vognmænd med egne lastbiler, som kun tager imod transport fra TN-Transport og enkelte egne kunder. Bilerne kører hovedsageligt i Danmark, men også en smule i Sverige. Der er faste kunder, men selvom der er nogle enkelte faste ture er der generelt stor variation i godstypen, afhentning og leverings steder, og de forskellige læs skal som regel kombineres for at fylde traileren. Der aftales en fast pris fra start af, men tages hensyn til ekstra tillæg i forbindelse med fx ventetid ved af- eller pålæsning. Når der sælges kørsel fra til freelance vognmændene afregnes dette ved at der udstedes en kreditnota til vognmændene. Kreditnotaen fungerer som betaling til freelance vognmændene. Dette er lidt utraditionelt, men firmaet ønsker at forsætte på denne måde. Det typiske arbejdsforløb er illustreret i aktivitetsdiagrammet til højre. En kunne ringer og der aftales en tur der skal køres. Der tages notater til hvornår kunden ønsker turen kørt. Turen planlægges og kører, ofte kombineres flere kunders ordre, hvis der ikke er nok gods til at fylde traileren, og der skal findes retur gods så der ikke køre tom hjem. Tur oplysningerne kan først endeligt noteres når turen er kørt, dette skyldes at der kan opstå gebyrer i forbindelse med ekstra vente tid grundet problemer fra kundens side. Turen kan til enhver tid aflyses og aktiviteten slutter. Figur 2 - Aktivitets diagram De endelige oplysninger om turen noteres og der laves en faktura på en eller flere turer som sendes til kunden. Har en af freelance vognmændene kørt turen oprettes en Kreditnota som sendes til Vognmanden som betaling. Alt regnskab foregår som det gjorte for 30 år siden. Følgesedler trykkes hos et trykkeri og de fyldes ud vha. af skrivemaskine. Alt regnskab føres på ternede regnearks blokke. Excel benyttes men kun som et skriveprogram da alle udregninger foregår med papir og lommeregner og derefter skrives ind. Dette er tidskrævende og mange informationer skal indskrives flere gange da der ikke gemmes noget digitalt. Alt sendes med posten. Der har været udtryk ønske fra revisorens side om at modtage regnskaberne digitalt, hvilket på nuværende tidspunkt ikke kan imødekommes. Virksomheden ønsker et IT-system der kan effektivisere regnskabsførelsen. Det væsentlige krav til systemet er at det er brugervenligt og driftsikkert. Side 11

12 12 TN Transport og Spedition PROJEKT Ønsker til systemet: Systemet skal støtte skrivningen af den enkelte kundes regninger (fakturaer) hvor så mange oplysninger som muligt indsættes automatisk, samt skabe overblik over kundens bestillinger(turer). Støtte prisudregningen på fakturaerne i begrænset grad, evt. bare opsummering af slut beløb. Prisen fastsættes hovedsageligt ud fra et min kost-beløb pr km og konkurrencen. Dog har forhold som om traileren kan fyldes helt, længden af turen og gods typen har også indflydelse på prisen. Da vognmanden ikke har nogle faste rammer for hvordan han regner prisen ud, skal selve udregningen ikke være en del af systemet. Der kan forsøgsvis implementeres et mindre udregningsprogram, der valgfrit kan benyttes men fakturaskrivningen må ikke være afhængig af benyttelsen af dette. Systemet skal være fleksibelt. Kundekartotek, kundeoplysninger kan hentes fra kartoteket så de ikke skal skrives ind på ny hver gang der oprettes en faktura. Fakturaerne skal gemmes i et format som revisoren kan anvende. Detaljerne er ikke fastlagt på nuværende tidspunkt. Særdeles bruger venligt. Systemet skal kunne bruges af brugere med minimal computer kendskab, men med kendskab til regnskab. Skabe overblik over de enkelte kunders ubetalte fakturer. Systemet skal være pålideligt og driftsikkert, da selv små fejl skræmmer en uerfaren bruger. Mulige udvidelser Integreret med mailen, så kunderne kan modtage fakturas digitalt. Digital faktura til de kunder der ønsker det. Køreskiver er digitaliseret, kan dette udnyttes ved faktura skrivningen? Eller på anden måde med fordel involveres i it-systemet? Års regnskab Lønregnskab Prioritet Brugervenlighed og stabilitet samt fleksibilitet. Side 12

13 13 TN Transport og Spedition PROJEKT It-forundersøgelse I it-forundersøgelsen undersøges virksomhedens itbehov. Og derudfra udarbejdes en skriftligt oversigt over de væsentlige problemstillinger, løsningsmuligheder og vurderinger af situationen. Virksomhedsbeskrivelse TN Transport Omsætning 2007 Ejer og driftsansvarlig Ansatte 4 mio. kr. pr år Torben Nielsen 3 freelance vognmænd Historie: Torben Nielsen Transport og Spedition (vil gennem resten af rapporten blive refereret til som tn-transport) blev grundlagt i 1987 af Torben Nielsen som selv arbejder som chauffør og samtidig laver regnskab og planlægger kørslen (ture). Firmaet startede med kørsel i Danmark/ Sydeuropa og i ca. 15 år også med kørsel i Holland/Belgien /Frankrig. De seneste 5 år er kørslen omlagt til Danmark/Sverige/Norge grundet prispres fra østeuropæiske vognmænd. Firmaet havde for år tilbage 7 egne lastbiler samt 1-2 indlejede vognmænd (disse vil senere blive omtalt som "freelance vognmænd"). Firmaets egne chauffører var lønnet efter overenskomst, dvs. time og akkord lønnet. Freelance vognmændene betales efter hvor meget de kører og lønnen forhandles ofte fra gang til gang. Frasalg af kørsel til freelance vognmænd har gennem det seneste år stået for ca. 30% af omsætningen, dette vil fremover udgøre omkring 75%, de sidste 25% kommer fra egen kørsel (vognmanden selv). Der er for omkring 3 mio. investeret i firmaet hvoraf størstedelen er i biler og trailere. Pr er antallet af egne biler reduceret til 3 stk. og flere freelance vognmænd. Dette skyldes at lønudgifterne til chauffører (ca ,00 pr md.) er højere end hvad det koster at hyre en freelance vognmand. Pr reduceres antallet af biler yderligt. Der er ikke længere chauffører ansat i firmaet, kun vognmanden selv. Der er to egne biler, hvor af den ene er helt ny og ikke har kørt endnu, men som ikke kan sælges pga. det store udbud af billige brugte lastbiler efter de mange konkurser inden for faget. Virksomheden nu: 2 egne biler. 7 Trailere. Ingen fastansatte chauffører foruden vognmanden selv. 3 freelance chauffører tilknyttet. Side 13

14 14 TN Transport og Spedition PROJEKT Står for al kontakt med kunderne samt regnskab og administration. En revisor udefra tager sig af de endelige regnskaber. Vognmand Torben Nielsen Kører de turer de får tildelt af vognmanden. Hjælper med af og pålæsning. Fast ansatte chauffører Freelance vognmænd Figur 3 - "mini" Organisations Diagram Ledelse og struktur Ledelsen er autoritær, da det er vognmanden der træffer alle beslutninger. Dette er ikke en følge af dårlig ledelse, men en naturlig konsekvens af arbejdsopgavernes simple karakter, samt lederens mangeårige erfaring på området. Hvis man kikker på Tannenbaum & Schmidts teori om situationsbestemt ledelse som beskrevet i Organisation 1 kan man se at ledelsen ofte vil hælde kraftigt mod autoritær, da der er tale om simple opgaver med oftest kun en løsning, stramme tidsrammer, samt stabile og til tider ensformige arbejdsrutiner. Kultur og værdier Firmaet blev grundlagt for over 20 år siden, hvor god service og et godt ry spillede en væsentlig rolle i det at drive en vognmandsvirksomhed. Mange virksomheder har nået en størrelse hvor der ikke er en personlig relation til deres mindre leverandører og med finanskrisen der trykker så er prisen som oftest det afgørende. Personlig relation mellem faste kunder og good will, er det der hovedsageligt skaffer firmaet kunder. Der ligges vægt på personlig kontakt, og der sendes julekurve ud til kunderne hvert år, og julegaver og udflugter arrangeres for de ansatte. Der er en familiær og afslappet omgangstone i virksomheden og som oftest bliver chaufførerne i firmaet i mange år. Det er en lille virksomhed og at chef såvel som ansatte føler et personligt ansvar for virksomheden og hinanden, dette gælder selvfølgelig ikke freelance vognmændene i samme grad. Virksomhedens mål og strategi I løbet af de seneste år har mange mindre vognmandsfirmaer gået fallit. Der er stor konkurrence blandt de danske vognmænd og et stadig større pres fra polske vognmænd der presser priserne ekstremt langt ned. Dette medfører at dækningsbidraget på de kørte turer, bliver mindre og mindre. TN Transports strategi er at fokusere på god service og stabil og sikker levering. Prismæssigt er det ikke muligt at konkurrere med udenlandske chauffører, bl.a. pga. af de danske overenskomster og køre-hviletidsregler. Der har været en del nedgang i TN-transport og antallet af lastbiler er gået fra 7 til de nuværende 2. Dette skyldes at det bedre kan betale sig at have selvstændige freelance vognmænd til at køre for sig. Udviklingen går fra at være et vognmandsfirma til mere at blive et speditions firma, og firmaet lever derved på sit gode rygte. TN-Transport mål er, at opnå en større kundekreds, hovedsageligt baseret på faste kunder. Der er enkelte firmaer som udelukkende vil have deres vare transporteret af skandinaviske vognmænd, især hvis der er tale om skrøbeligt eller dyrt gods. Det er derfor et strategisk mål at skaffe flere "kvalitets bevidste" kunder, hvor service er vigtigere end pris. Desuden ønsker man at kunne være konkurrencedygtige på det svenske 1 Organisation s.187 af Henrik Kjær, Hans Jørgen Skriver, Erik Staunstrup, 2008 (4. udgave) Side 14

15 15 TN Transport og Spedition PROJEKT marked. Torben Nielsen der står for al virksomhedens aktiviteter, fra regnskab til ruteplanlægning, har ikke det store kendskab til computer. Al regnskab foregår derfor i hånden, hvilket er ressource- og tidskrævende. Desuden har revisoren udtrykt ønske om at modtage regnskaberne digitalt hvilket TN-Transport på nuværende tidspunkt ikke kan opfylde. Eftersom alle TN-Transports aktiviteter udelukkende styres af Torben Nielsen, er hans tid sparsom. Noget at det han tilbringer meget tid på er regnskaber som hver dag kræver flere timers kontor arbejde. Derfor ønskes et system der kan effektivisere og skabe overblik over regnskabsføringen. SWOT Strengths, Weaknesses, Opportunities og Threats. SWOT analysen har til formål at belyse virksomhedens styrke- og konkurrencesituation. Tabellen nedenfor er en oversigt over de styrker, svagheder, samt muligheder og trusler, der er forbundet til TN-Transport. Interne styrker Stor erfaring Good will Højt service niveau Specialiseret i Sverige kørsel Egne trailere Nyere biler og trailere Freelance vognmænd tilknyttet Faste kunder Interne svagheder Gammeldags og ressourcekrævende regnskabsføring. Indbrud og hærværk af/i trailere. Eksterne muligheder Udvid med flere freelance vognmænd. Reklame. Avis og på nettet (via en hjemmeside) Eksterne trusler Konkurrence, større firmaer, og polske arbejder. Sæsonsvingninger. Sløvt i juletid og industriferien. Miljøkravene i fremtiden, som medfører ekstra omkostninger. Figur 4 - SWOT analyse tabel Interne styrker TN-Transport er kendt for god service. De enkelte chauffører hjælper til med på- og aflæsning hos kunderne, hvilket ikke altid er en selvfølge i branchen. Lastbilerne bliver skiftet ud løbende så der altid kun er biler af nyere dato, pt er begge biler under 3 år gamle (da der var flere biler i firmaet blev max alderen hold på under 4-5 år). Vognmand Torben Nielsen er uddannet speditør og har beskæftiget sig med spedition og regnskab i over 25 år samt praktisk erfaring med faget da han selv kører som chauffør i firmaet. TN-Transport er en af de få danske firmaer der kører læs til Nordsverige. Firmaet ejer en speciel ekstra lang trailer som ikke er godkend til at køre med i Danmark, men som kan benyttes til kørsel i Sverige. Derudover er der også en tipsættevogn (ladet kan som navnet antyder, tippes. Denne trailer type anvendes Side 15

16 16 TN Transport og Spedition PROJEKT meget til minkfoder), samt 5 andre presenningtrailere hvilket gør at mange forskellige former for gods kan håndteres. Firmaet har 3 freelance vognmænd tilknyttet hvilket er billigere end at have chauffører ansat. Interne svagheder Regnskabsføringen er gammeldags og langsom. Der er ofte indbrud i trailere og lastbiler, dette er delvist løst ved at leje sig ind på en aflåst holdeplads facilitet, men det udgør stadigt et problem. Eksterne Muligheder Udvide speditions delen af virksomheden og sælge de sidste egne lastbiler fra. Skaffe nye kunder via reklame, fx avis eller hjemmeside. Eksterne trusler Finanskrisen har givet færre kunder. Derudover er der stor konkurrence fra udenlandske firmaer der kan køre billigere end danske firmaer kan konkurrere med grundet overenskomster og regler. Skrappe miljøkrav betyder øgede udgifter. Det er svært at få nye kunder og i ferierne kan der være meget lidt eller slet ingen kørsel at få. Disse svagheder kan ikke umildbart minimeres eller omgåes da de er samfundsbestemte. Virksomheden vil få mest ud af mini-maxi modellen, som går ud på at minimere svagheder og maximere mulighederne. Dette vil blive gennem gået i næste afsnit (IT-Strategi og handlingsplan -> Strategiske muligheder). I tabellen nedenfor er der en kort gennemgang af problem- og konfliktområder i virksomheden. Problemer Hypoteser Løsningsmuligheder Manuel regnskabsføring grundet manglende tiltro og forståelse for anvendelsen af it systemer Alt skrives i hånden. Der anvendes kun computere til renskrivning, hvilket er ressourcekrævende. Sygdom Få nye kunder I tilfælde af sygdom står alt stille da kun vognmanden har overblik over hvilken kørsel der er planlagt. Der er ikke nok kunder der vil betale det ekstra det koster at få deres varer transporteret af et dansk firma Figur 5 - Tabellen viser en kort gennemgang af problem- og konfliktområder i virksomheden. IT system skal være enkelt og brugervenligt. Der skal tages udgangspunkt i få og sikre funktioner. Systemet holder styr på planlagt kørsel. Der skal være let og enkel adgang til alle relevante oplysninger. Udvidet reklame. Sats på service. IT- Strategi og handlingsplan En kort gennemgang af de ønskede fremtidige it-løsninger og de aktuelle muligheder på længere sigt. På baggrund af en cost-benefit analyse vil vi komme med et forslag til en it handlingsplan. It vision: It skal så småt integreres i virksomheden. Revisoren skal modtage regnskabs dokumentation digitalt og computer programmer skal overtage så meget af det manuelle arbejde som muligt. Løn beregninger og Side 16

17 17 TN Transport og Spedition PROJEKT årsregnskab skal med tiden kunne administreres af et computerprogram med minimal indsat fra brugerens side. Dette forventes ikke lige foreløbeligt. Strategiske muligheder Ud fra SWOT analysen og virksomhedens mål vil en mini-maxi model være det mest optimale. Mini-maxi modellen går ud på at minimere virksomhedens svagheder og maksimere muligheder. At minimere svaghederne vil være at effektivisere regnskabsførelsen, hvilke dele af regnskabsføringen det bedst kan betale sig at lave et system til vil cost-benefit analysen vise. På et senere tidspunkt kan det værre en fordel integrere systemet med firmaets mail så kunderne kan modtage deres fakturaer digitalt. Tn-transport modtager selv regninger bl.a. fra Stenaline via googledocuments. Men på nuværende tidspunkt er det ikke nødvendigt. Maksimering af mulighederne vil være at skaffe flere kunder. Dette kan gøres vha. en webside på svensk, dansk og engelsk. Cost-Benefit analyse Parker-Benson analysen nedenfor har til formal at klarlægge hvilke systemdele der er mest nyttige for firmaet holdt op imod hvilke risikoer det er forbundet med. Business domain ROI SM CA Technology domain MI CR OR SA DU TU IR Total Vægt Debitor Faktureringssystem Kreditor Lønsystem Website Integreret mail Back-up system Figur 6 - Parker Benson's cost benefit analyse tabel Ud fra det ovenstående diagram (figur 1) er det muligt og se hvilke system dele der bedst kan betale sig at implementere, og dermed hvorledes der bør prioriteres. Ud fra diagrammet er det faktureringssystemet, kreditor og debitorsystem det bedst kan betale sig for virksomheden at investere i. Da der er meget få egentlig ansatte i firmaet har et lønsystem ikke så høj prioritet, da det vil være omkostningsfuldt at integrer og udbyttet vil være begrænset. Torben Nielsen har givet udtryk for at han ikke ser nogen fordele ved at integrere et lønningssystem. Back-up systemet har selvfølgelig altid en relevans, men da der er tale om en meget lille virksomhed, at det kan klares med gængse værktøjer som eksterne lagringsmedier eller online lagerplads. Dette behøves ikke yderlig udvikling. Side 17

18 18 TN Transport og Spedition PROJEKT En simpel website kan sættes op for små midler og indeholder ingen egentlige risikoer da den mest af alt er ment som en reklame der blot gør kontakt oplysningerne let tilgængelige. Det er dog meget usikkert om det vil kunne give nogen økonomisk gevinst. Er websiden dårligt designet vil den kunne give et uprofessionelt indtryk af virksomheden for nye kunder. Økonomi (i 1000 kr) Netto omsætning Overskud før renter Totale aktiver Overskudsgrad 10,4% 15,2% 21,1% Aktivers 1,41 1,156 1,20 omsætningshastighed Afkastningsgrad 14,6% 17,6% 25,3% Figur 7 - Nøgletal for TN-Transport Firmaet må siges at have en særdeles god afkastningsgrad i forhold til de penge der er investeret i det. Desværre har vi ikke for regnskabsåret 2008 eller statistikken for i år. Det er ikke til at lave en kvalificeret bedømmelse af den økonomiske situation da der grundet finanskrisen har været stor nedgang det sidste år. Men at dømme på afkastningsgraden de sidste år forstår firmaet at forvalte sine værdier. Hvorvidt det er forsvarligt at investere i et it-system på nuværende tidspunkt er svært at argumentere for, da det er et lille firma og da det jo nu er blevet endnu mindre. Samtidigt fungere firmaet jo mere og mere som et speditionsfirma og der ville et effektivt regnskabssystem jo helt klart være en fordel. Helt generelt vil jeg ikke anbefale firmaet at investere i et it-system på nuværende tidspunkt, da den økonomiske situation er noget usikker og da der ikke er nogen umildbar større gevinst ved at udvikle et nyt system. At udvikle et nyt system er tidskrævende og dyrt. Det vil være mere hensigtsmæssigt at investere i et færdigt system, især når man tager virksomhedens størrelse i betragtning. Men da dette er et skoleprojekt og der ikke er nogle udgifter til virksomheden kan det selvfølgelig godt betale sig. Forslag til it-handlingsplan It skal integreres i virksomheden. Den regnskabsansvarliges begrænsede computerkundskaber taget i betragtning, vil det mest optimale være at starte med et mindre meget simpelt og bruger venlig program der kan hjælpe med skrivningen af fakturaer og kreditnotaer, samt et kunde- og medarbejder kartotek. Systemet skal rumme mulighed for små delvise udvidelser, i takt med at brugerens erfaring og tillid til systemet. System skal køre på en Windows platform, men vil være platforms uafhængig da det skal skrives i java. Forslag til teknologi Ud fra den strategi vi anbefaler er der ingen større krav til teknologien. En stabil computer af nyere dato med de gængse værktøjer og med mulig internetforbindelse opfylder de fysiske teknologiske behov. Dette kunne sagtens være en bærbar der kunne medbringes på køretur. Systemet i sig selv sætter ingen større krav til systemet, computeren skal nærmere vælges ud fra hvilket styresystem man vil køre på den. Side 18

19 19 TN Transport og Spedition PROJEKT Vil man køre det i Windows XP kan firmaets nuværende computer sagtens køre det. Her er der tale om en ældre single core intel processor, ½-1 GB RAM og et lille integreret grafikkort af ukendt mærke. Vælger firmaet at opgradere til Windows Vista eller Windows 7 er der behov for en kraftigere computer, da man som minimum skal have 2 GB RAM hvis ikke Vista skal blive alt for tungt at arbejde med. Man må regne med investere kr i en ny computer. Jo mere data der gemmes digitalt jo større bliver sikkerhedsbehovet. Man kunne overveje at skifte fra det nuværende Windows system til Linux eller andet open source styresystem som er mindre udsat for hacker eller virus angreb. Andre fordele ved dette kan være at Linux systemer er mindre ressourcekrævende, så der stilles ikke så store krav til størrelsen af computeren, derudover er det også gratis at anvende. Ulempen er at brugeren på nuværende tidspunkt ikke er i stand til at bruge et Linux system. Teknisk er det hensigtsmæssigt at vælge et programmeringssprog der er platforms uafhængig da dette på længere sigt giver større frihed for brugeren. Det kan være en fordel at købe serverplads at gemme fakturaerne på, eller et eksternt lagringsmedie. Da det er en meget lille firma skønnes dette ikke at ville medføre nogen udgifter at betydning. Prioritering Systemet skal være brugervenligt og enkelt. Det skal have mulighed for udvidelse på længere sigt. Brugerdeltagelse Brugeren arbejdsrutine skal spille en stor rolle i udarbejdelse af systemet, men grundet brugerens manglende erfaring skal systemet udarbejdes ud fra expertstrategien. Brugeren vil kun blive indraget i forbindelse med spørgsmål om arbejdsrutiner. Systemet skal dog tidligt i forløbet introduceres for brugeren i form a mock-ups, så vi kan vurdere om de opstillede funktioner opfylder brugerens behov. Side 19

20 20 TN Transport og Spedition PROJEKT Systemdefinition Et it-system til at støtte den daglige fakturering og planlægning af kørsel i en mindre vognmands virksomhed. Systemet skal primært anvendes til skrivningen af fakturaer og sekundært til kreditnota. Der ligges stor vægt på fleksibilitet. Systemet skal kun foretage mindre udregninger som eksempelvis at udregne sum. Der skal desuden integreres et kundekartotek. Sekundært skal det kunne følge en standart eller kunne konverteres til en standart som firmaets tilknyttede revisor ønsker regnskabet afleveret i, dette er af knap så høj prioritet. Systemet skal baseres på en lille pc med kun gængse værkstøjer. Der skal i øvrigt også tages hensyn til at brugeren af systemet er meget uerfaren i brugen af computer, derfor er et yderst brugervenlig user-interface, samt stabilitet (troværdighed) de vigtigste design kriterier. Betingelser: Anvendelsesområde: Teknologi: Objekter: Funktionalitet: Filosofi: Systemet skal være let at anvende, og afspejle gammeldags fakturaskrivning så meget som muligt. Det skal indeholde nok fleksibilitet til at bruger selv let kan ændre alle oplysninger på fakturaen før udskrivning. Systemet skal kunne anvendes uden nogen, eller med blot en kort introduktion. Hjemmekontor med kun en eller få brugere med minimal computerkendskab men med adskillige års regnskabs erfaring. En relativ billig og stabil pc med gængse værktøjer. Faktura, følgesedler, kunder, ture, chauffører, lastbiler, trailere. Støtte den daglige fakturering af ture, samt lagring af kunde oplysninger. Brugervenligt faktureringsværktøj med stor fleksibilitet BATOFF kriterierne Begrænsninger: Ud fra vores cost-benefit analyse har vi valgt at begrænse systemet til håndtering af Faktura, Kreditnota og kunde- og ansatte-kartotek. Kreditnota håndtering skal ikke implementeres til at starte med, den minder meget om faktura håndteringen bare men anvendes slet ikke så hyppigt. Den skal derfor kun implementeres hvis der er tid i overskud. Løn ønskes ikke integreret på nuværende tidspunkt, og der ikke ønskes automatiserede udregninger, da brugeren ønsker det fulde overblik over hvad der sker. Websiten vurdere vi som et strategisk godt træk, men da den ikke har nogen relevans for brugen af regnskabssystemet skal den ikke udvikles i denne sammenhæng. Revisor venlig format. Dette kan tilføjes som en applikation til systemet på et senere tidspunkt da vi bedømmer det for kompliceret i forhold til udbyttet. Alle de mulige udvidelser skal ikke implementeres i dette arbejdsforløb, da vi bedømmer dem både for komplekse i forhold til tidsplanen og for avancerede for brugeren. Vi vil udelukkende fokusere på at lave et enkelt og brugevenligt system. De mange begrænsninger skyldes hovedsageligt projektets tidsbegrænsning. Side 20

21 21 TN Transport og Spedition PROJEKT DEL 3 ANALYSE & DESIGN Referat Denne del af rapporten udgør den største del da der til denne del findes mest papir-venlig dokumentering i form af diagrammer og use-cases. Analysen af problem området viste at Tur begrebet er det centrale element. Tur er hvad man inden for speditionsbranchen opfatter som en ordre. Analysen af anvendelses område satte kunde håndteringen i en central rolle, da alle ture(ordre) deles op efter kunden. Alt hvad der hedder planlægning og strukturering af kørsel håndteres separat fra selve ordren, derfor er begreber som dato og rute blot attributter. Håndtering og planlægning af disse ville betyde en helt ny problemstilling i sig selv og er derfor ikke integreret i systemet. Ovenstående kommer til udtryk gennem valgt af use-cases og design af brugergrænsefalden. Kort opsummeret betyder det at Kunde, Tur og Faktura delene i systemet er de vigtigste. Brugergrænsefladen er illustreret gennem mock-ups. De viste mock-ups er anden genereation af mockups (den klassificering referer til iterations delings beskrivelse), som er blevet gennemgået og godkendt af brugeren (TN-Transport). Der er enkelte rettelser især i forbindelse med navngivning, men ellers er det med disse mock ups som guide-lines at den endelige at brugergrænseflade er designet. System designet bliver klassisk lagdelt med åben arkitektur. Klasserne fra modellaget bruges til at flytte data rund i systemet. I denne forbindelse er der lavet et overbliks designklasse diagram, der viser klasserne i alle lag samt deres indbyrdes relationer, dog uden at indeholde lister over attributter og metoder. De fulde klassebeskrivelser kan findes i bilagene. Databasen designes med arkiv klasser så der er lagt op til på længere sigt at implementere et arkiv system, da det ellers ikke ville være forsvarligt at slette kunder og ansatte fra denne type systemet. Arkivet skal gælde for de fleste klasser fra modellaget. Der skal ikke være nogle fremmednøgler da arkiv dataen ikke skal kunne ændres men kun aflæses. System Sekvens, og Sekvens diagram over use-casene dokumentere den planlagte sammenhæng mellem use-casen Faktura Udkast og system designet. Flere sekvens diagrammer over andre use-cases kan findes i bilagene. Side 21

22 22 TN Transport og Spedition PROJEKT Analyse Dette analysedokument danner grundlaget for udviklingen af et faktureringssystem til et mindre vognmandsfirma, TN- Transport. Analysen er baseret på Objekt Orienteret Analyse og Design (OOAD) som beskrevet i (Mathiassen et al., 2001). Der er tale om en real case med et rigtigt firma som grundlag, nogle punkter i analysen vil måske virke for gennemanalyseret i forhold til virksomhedens størrelse. Dette skyldes at jeg ser analysen som en læringsproces og gerne vil have alle aspekter af analysen med, selv på punkter der måske ikke er stærkt nødvendige for denne case. Formål Formålet er at lave et skræddersyet faktureringssystem til vognmandsfirmaet TN- Transport. Systemet har til formål at lette regnskabsbyrden i firmaet, dog uden at ændre mere på arbejdsrutinen end højst nødvendigt. Der stilles derudover store krav til brugervenligheden da Torben Nielsen som tager sig af regnskaberne har et yderst begrænset kendskab til computere og nærer en mistro til ting han ikke har fysisk på papir. Problemområde Systemet hovedopgave vil være at støtte faktura skrivning og skabe overblik over hvilke kunder der mangler at blive oprettet faktura til. Der arbejdes med begreber som ture som inden for speditions verden svare til en ordre. Kreditnota, bruges i dette firma som betaling til de vognmænd der kører for firmaet. Det er utraditionelt men firmaet ønsker at forsætte på denne måde. Anvendelsesområde Systemet skal skabe overblik og hjælpe brugeren med let og hurtigt at oprette fakturaer og kreditnota med de nødvendige oplysninger. Kundekartotek, ansatte, biler og trailere skal let kunne administreres. Der skal til hver en tid kunne ændres forud indtastede data med bar et klik før faktura eller kreditnota udskrives. Der stilles desuden krav om det skal være særdeles brugervenligt og selve udformningen af systemet skal afspejle en allerede eksisterende arbejdsgang og ikke lave en ny. Problemområdet Domæne modellen har til formål at illustrere problem situation set fra brugerens synspunkt. Der anvendes begreber fra brugerens arbejdsgang. TN transport fungerer således: En kunde ringer ind og ønsker en vare transporteret. Fortæller hvor fra, hvor til og eventuelle stop på vejen(ruten), samt dato og tid. Turen bliver kørt af en enten en chauffør eller en vognmand. Køres den af en vognmand oprettes der en kreditnota. Der kan enten være en chauffør eller en vognmand knyttet til turen, det er dog ikke et krav for at turen kan faktureres. Er det en vognmand der har kørt turen oprettes der en kreditnota-tur som er en lille notits af hvilken tur, hvilken vognmand og den aftale pris. Kreditnota turene kan så senere bruges til at oprette en Kreditnota til vognmanden. Side 22

23 23 TN Transport og Spedition PROJEKT Kunden skal oprettes i systemet for at der kan oprettes en tur. Dette krav skyldes at turer og fakturaer er tilknyttet kunden, for at de skal kunne findes let må de have en reference til en kunde. Dette sætter nogle krav til at kundeoprettelsen skal være let og hurtig at foretage. Der er knyttet 0-1 trailer og 0-1 bil til hver tur. Det betyder der kan angives en bil og trailer til turen, men det er ikke en forudsætning for at kunne oprette turen. Der er altid knyttet 1 TurPris til en tur. TurPrisen indeholder oplysninger om eventuelle tillæg og grundprisen samt fakta til udregning af prisen. Turpris kunne med fordel fungere ligge grund for et prisudregningsmondul på et senere tidspunkt. En Faktura har tilknyttet en kunde, dato, nr, adr, samlet pris og en liste med x antal Ture. Kunde, Chauffør, samt Vognmand er knyttet til KontaktOpl(ysninger) som indeholder alle de nyttige oplysninger som adr. og telefon numre. Figur 8 - domænemodel Side 23

24 24 TN Transport og Spedition PROJEKT Anvendelsesområde Da alle indekommende ordre starter med en kunde, vil alle use-cases der omhandler ordre behandling/tur håndtering starte med at man søger en kunde frem. Dette sætter kunde kartoteket/søge muligheder som udgangspunkt for næsten alle aktiviteter. Fakturerede ture vil kun vises i forbindelse med en eventuel Arkiv del af systemet som ikke vil blive implementeret i denne udgave af systemet. Dette skyldes at det ikke er lovgivning mæssigt forsvarligt at redigere i en faktura. Derfor vil der først blive oprettet et Faktura Udkast. Disse kan frit ændres indtil de bogføres og bliver egentlige fakturaer Use-case Som det kan sews på use-case diagrammet er tilgangen til systemet meget enkel. Da der kun er en bruger har brugeren adgang til alle funktioner. Use-cases: Opret Kunde, Søg Kunde, Tur, Rediger Tur, Faktura Udkast, fælles Søg og opret use-case til de øvrige CRUD use-cases. Læsevejledning: Brugernes handlinger er nummeret, systemets svar er vist med kursiv. Alternative flows er indelt alfabetisk og deres løsninger er nummerert. Søg Chauffor/Vognmand/Bil/Trailer Figur 9 - Use-case Diagram Pre-betingelser: Kunden er oprettet i databasen Post betingelser: Kunde objektet hentes fra databasen og kunde oplysningerne vises på skærmen. Frekvens: ofte 1. Indtast navn/ firma-navn / nummerplade(navn) og vælg Søg Systemet finder det objekt i databasen der passer bedst til det indtastede navn, og viser dets oplysninger på skærmen. For mere præcis søgning, kan typen angives. Opret Chauffor/Vognmand/Bil/Trailer Chauffor, Vognmand, Bil og Trailere oprettes på samme måde: Pre-betingelser: Der findes ikke et objekt af samme type med samme navn i databasen. Post betingelser: Objektet er gemt i databasen Frekvens: sjældent 1. Vælg type(fx Vognmand). Indtast navn/firma-navn/nummerplade(navn) og vælg opret. Systemet opretter Chaufforen/Vognmanden/Bil/Trailer Opret Kunde Pre-betingelser: Kundens navn er ikke allerede oprettet i databasen Side 24

25 25 TN Transport og Spedition PROJEKT Post betingelser: Kunden gemmes i databasen Frekvens: ofte 1. Indtast kundens navn og evt. cvr nr. og vælg opret. Systemet opretter kunden. Søg Kunde Pre-betingelser: Kunden er oprettet i databasen Post betingelser: Kunde objektet hentes fra databasen og kunde oplysningerne vises på skærmen. Frekvens: Ekstremt hyppigt 1. Indtast kundens navn (eller blot en del af navnet) eller cvr og vælg søg Systemet viser kundens oplysninger. Tur Aktør: vognmanden Pre-betingelser: Kunden, biler, trailer og ansatte er oprettet i systemet. Post betingelser: Turen gemmes i databasen Frekvens: Meget hyppigt Basic flow: 1. En kunde ringer og ønsker en tur kørt. Brugeren søger kunden frem (se Søg Kunde use-casen) og vælger "Ny tur". Systemet opretter Turen i databasen og åbner en "Tur editor". 2. Brugeren indtaster oplysninger om turen; dato, bil, trailer, rute, godsbeskrivelse, pris, samt evt. tillæg og afkrydsning hvis der skal oprettes en kreditnota. I tilfælde af at der skal oprettes en kreditnota skal der angives hvem der har kørt turen. Ikke alle oplysninger udfyldes under oprettelsen men tilføjes senere - se "Rediger Tur". Brugeren vælger "Godkend". Systemet opretter en tur i databasen og Tur Editor en. Skærmbilledet med Kundens oplysninger opdateres således at de ny indtastede data om en af kundens turer kan ses. Alternativ flows: A. Kunden findes ikke i databasen 1. Brugeren oprettes. Se use-casen Opret Kunde. Systemet opretter kunden i databasen. 3. Brugeren vælger "ny tur" og flowet forsætter som forklaret i punkt 3 og 4 i basic flowet. Rediger Tur (Opdater Tur) Aktør: vognmanden Pre-betingelser: Der er oprettet mindst en ufaktureret tur i databasen. Post betingelser: De foretagede ændringer i turen opdateres i databasen. Frekvens: Meget hyppigt Basic flow: 1. Brugeren markerer en tur på en liste over endnu ufakturerede turer og vælger "rediger". Systemet åbner en "Tur Editor" og indsætter den markerede turs oplysninger. 2. Brugeren foretager de ønskede ændringer og vælger "Godkend". Side 25

26 26 TN Transport og Spedition PROJEKT Systemet opdaterer tur objektet i databasen og lukker "Tur Editor" en. Alternativ flows: A. Brugeren ønsker ikke at gemme de foretagede ændringer alligevel. a1. Brugeren vælger "Annuller". Systemet lukker "Tur Editor" en og opdatere IKKE tur objektet. KreditnotaUdkast Aktør: vognmanden Pre-betingelser: Der er oprettet KreditnotaTure og de er tilknyttet en eksisterende Vognmand. Turene er færdig skrevne og der er angivet pris. Post betingelser: KreditnotaUdkastet er udskrevet, samt gemt i databasen. Frekvens: Ofte Basic flow: 1. Brugeren søger en Vognmand frem (se Søg Vognmanden use-casen) og vælger de ønskede ture og vælger "Opret Faktura Udkast". Et nyt KreditnotaUdkast objekt oprettes i databasen. Der åbnes redigerings muligheder til KreditnotaUdkast. De valgte KreditnotaTure, Vognmandens adresse, samt dags dato og kreditnota nr. vises. 2. Brugeren tilpasser rækkefølgen på KreditnotaTurene (fx ved at flytte dem en tak op eller ned på en liste) Systemet opdaterer K_Tur_Listerne i databasen og opdater listen. 3. Brugeren vælger Udskriv. Systemet åbner et printvindue. 4. Brugeren vælger print indstillinger. Systemet, sender KreditnotaUdkastet til printeren. 5. Brugeren vælger "Godkend". Systemet opdaterer KreditnotaUdkastet i databasen og lukker redigerings mulighederne. Alternative flows: A. Brugeren vil tilføje flere KreditnotaTure til KreditnotaUdkastet. a1. Brugeren vælger "Tilføj KreditnotaTur". Systemet viser Vognmandens resterende endnu ikke afregnede KreditnotaTure. a2. Brugeren vælger den ønskede KreditnotaTur og vælger "Tilføj". Systemet tilføjer den ønskede KreditnotaTur til KreditnotaUdkastet, og opdatere skærmbilledet, (sum opsummeres). B. Brugeren har tilføjet en forkert KreditnotaTur til KreditnotaUdkastet. b1. Brugeren markerer Turen og vælger "fjern". Systemet fjerner KreditnotaTuren fra KreditnotaUdkastet, (sum opsummeres). Side 26

27 27 TN Transport og Spedition PROJEKT C. Prisen skal ændres på en KreditnotaTur inden den kan faktureres. c1. Brugeren markerer KreditnotaTuren og angiver ny pris. Systemet opdaterer "KreditnotaUdkastet" oplysningerne på skærmen, (sum opsummeres). D. Brugeren ønsker ikke at oprette fakturaen alligevel. d1. Brugeren vælger "Annuller". Systemet lukker "Faktura Udkast" redigeringen og sletter fakturaen fra databasen. FakturaUdkast Aktør: vognmanden Pre-betingelser: Der er oprettet Ture og de er tilknyttet en eksisterende Kunde. Turene er færdig skrevne og der er angivet pris. Post betingelser: FakturaUdkastet er udskrevet, samt gemt i databasen. Frekvens: Hyppigt Basic flow: 1. Brugeren søger en kunde frem (se Søg Kunde use-casen) og vælger de ønskede ture og vælger "Opret Faktura Udkast". Et nyt FakturaUdkast objekt oprettes i databasen. Der åbnes redigerings muligheder til FakturaUdkast. De valgte Ture, Kundens adresse, samt dags dato og faktura nr. vises. 2. Brugeren tilpasser rækkefølgen på turene (fx ved at flytte dem en tak op eller ned på en liste) Systemet opdaterer Tur_Listerne i databasen og opdater listen. 3. Brugeren vælger Udskriv. Systemet åbner et printvindue. 4. Brugeren vælger print indstillinger. Systemet, sender FakturaUdkastet til printeren. 5. Brugeren vælger "Godkend". Systemet opdaterer FakturaUdkastet i databasen og lukker redigerings mulighederne. Alternative flows: A. Brugeren vil tilføje flere Ture til FakturaUdkastet. a1. Brugeren vælger "Tilføj Tur". Systemet viser Kundens resterende ufakturerede Ture. a2. Brugeren vælger den ønskede Tur og vælger "Tilføj". Systemet tilføjer den ønskede Tur til Faktura Udkastet, og opdatere skærmbilledet, (sum opsummeres). B. Brugeren har tilføjet en forkert Tur til FakturaUdkastet. b1. Brugeren markerer Turen og vælger "fjern". Systemet fjerner Turen fra Faktura Udkastet, (sum opsummeres). Side 27

28 28 TN Transport og Spedition PROJEKT C. Der skal ændres noget i en af Turene inden den kan faktureres. c1. Brugeren markerer turen og vælger "rediger". Se use-casen for Rediger Tur. Systemet opdaterer "FakturaUdkastet" oplysningerne på skærmen, (sum opsummeres). D. Brugeren ønsker ikke at oprette FakturaUdkastet alligevel. d1. Brugeren vælger "Annuller". Systemet lukker "FakturaUdkast" redigeringen og sletter fakturaen fra databasen. System sekvens diagrammet er over use-casen FakturaUdkast. Handlingerne er nummeret og matcher use-casens nummeringer. De alternative flows A, B og D er vist i svagt farvede bokse. C er undladt da den involvere en helt anden use-case. Figur 10 System Sekvens Diagram for Faktura Udkast Side 28

29 29 TN Transport og Spedition PROJEKT Brugergrænseflade Funktioner Nedenstående tabel viser en oversigt over funktioner, deres kompleksitet og type. Funktion Kompleksitet Type Lav, opdater turer simpel opdatering Lav faktura medium opdatering, print Tilføj, fjern turer medium opdatering Søg kunde simpel aflæsning Lav, opdater, fjern kunde simpel opdatering Lav, opdater, fjern bil simpel opdatering Lav, opdater, fjern trailer simpel opdatering Lav, opdater, fjern ansat simpel opdatering Figur 11 - Oversigt over programmets ønskede funktioner, deres type og kompleksitet Der er to hovedvinduer; kunder og virksomheden. Disse vinduer har hver især en række undervinduer som er illustreret vha. faneblade som kan bladres igennem som arkiv ark. Redigerings funktionerne har deres egne editor vinduer, dette er valgt med det formål at gøre det lettere for brugeren da det altid tydeligt vil fremgå hvad der ændres i. Hvis tingene kunne redigeres i hovedvinduet skulle brugere hele tiden trykke gem eller opdater og dette ville kunne forvirre en bruger på dette bruger-niveau, det ville skulle deles meget skarp op så der ikke ville være nogen tvivl om hvilke tekstfelter der hørte under hvilken opdaterings knap. Dette ville gå på kompromis med det ønskede workflow, ved at vælge selvstændige editor vinduer kan brugerens arbejdsrutine gennemføres på den mest brugervenlige og effektive metode. Vinduer: KUNDE: søg, adresse, kontakt, VIRKSOMHEDEN: Ansatte, Materiel, EDITORS: FakturaUdkast, Tur, Bil, Trailer, Ansat, TilføjTur, Listevisning (tabel oversigter), Der er blevet oprettet en mængde mock-ups der har til formål at skabe overblik over programmets user interface og hjælpe brugeren med få en forståelse for programmet og dets funktioner, dette skal hjælpe med at give os et indblik i om vi har matchet brugerens behov. Der tages forbehold for at det endelige design kan afvige fra mock-ups'ene både visuelt og funktionsmæssigt. Disse ændringer vil blive gennemgået senere i rapporten. På næste side er et navigations diagram, dette kan findes i større format i bilagene bagerst. Herefter er en gennemgang af de enkelte vinduer. ÆNDRINGER: Efter en gennemgang af mockupsene med tn-transport og de tilknyttede vejledere på uddannelsen vil følgende ændringer blive foretaget. Ansatte vil blive delt op i vognmænd og chauffører. Faktura, skal i stedet hedde faktura udkast af lovgivnings mæssige grunde. I mock-upsene og navigations diagrammet står det dog stadig angivet som faktura-editor da de blev designet tidligt i forløbet. Side 29

30 30 TN Transport og Spedition PROJEKT Figur 12 - Navigations Diagram Side 30

31 31 TN Transport og Spedition PROJEKT Fane1: Kunder ( Søg) "Søg" - Søg efter kunde ud fra firmanavn eller cvr nr. Hvis kunden findes fyldes dennes oplysninger automatisk ind i de tomme felter på "søg" fanen og de to efterfølgende faner; adresse og kontakt. "Nulstil" - fjerner alle kunde oplysninger fra vinduet, inkl. turer, adresse og kontakt data. "Opret" - Opretter en ny Kunde, der skal indtastes et navn. "Vis alle kunder" - Åbner en tabel med en liste over alle kunder. "Favoritter" åbner en tabel med en liste over alle kunder der er klassificeret som favoritter. "Opret tur" - Åbner en tom "Tur Editor". "Rediger Tur" - Åbner "Tur Editor" hvor turens data kan aflæses og ændres efter behov. "Slet tur" - Sletter en tur fra listen. "Opret Faktura" - Inden denne knap vælges skal der krydses mindst en tur af på listen. Herefter åbner vinduet "Faktura Editor" hvor fakturaen kan tilpasses. (Kontakt) Kontakt personer er et simpelt tekst felt hvor der frit kan skrives. På denne måde er man ikke afhængig af tabeller eller lister for at vise alle kontaktpersoner og deres mobil nr. Tjek boksen "Favorit" tjekkes af ved de kunder der anvendes mest, de kommer derefter på listen der vises ved at trykke på "Favoritter" under "Søg" fanen. (Adresse) I boksen "adresse" skal vise den færdige adresse. Efter at man har indtastet postnr skal by automatisk udfyldes. Side 31

32 32 TN Transport og Spedition PROJEKT (Tur Editor) Hvis en tur køres af en fremmed vognmand kan der allerede ved turens oprettelse blive oprettet en kreditnota som senere kan tilpasses og udskrives. "Godkend" - er turen endnu ikke oprettet vil den blive oprettet. Er turen allerede oprettet vil den blive opdateret. "Annuller" - Tur editoren lukkes og ingen ændringer gemmes. (Faktura Udkast) "Fjern" - fjerner den markerede tur fra fakturaen. "Tilføj" åbner et vindue med en liste af turer som kan afkrydses og tilføjes. (ses nedenfor) "Rediger" - åbner "tur editor" vinduet. "Vis Udskrift" - åbner udskrifts vinduet. "Godkend" - Åbner et vindue med udskriftsmuligheder for fakturaen. "Annuller" - lukker fakturaen uden at gemme nogle ændringer. Side 32

33 33 TN Transport og Spedition PROJEKT Fane2: Virksomheden (Ansatte) Ansatte vinduet skal i første omgang holdes så enkelt som muligt, da "kreditnota" delen af systemet ikke skal implementeres i første omgang (se begrænsningerne i system definitionen). Ved evt. senere udvidelse af systemet skal Ansatte vinduet laves på samme måde som Kunde vinduet, hvor man så kan oprette Kreditnota i stedet for Faktura. Når der trykkes "Rediger" eller "Ny" åbnes der ligesom i alle de andre vinduer et editor vindue. (Køretøjer) Her kan tilføjes biler og trailere som kører for TN-Transport. Der skal angives om traileren og bil tilhøre tn transport samt om bilen har en fast chauffør. Der kan som i de foregående vinduer oprettes "ny" eller redigere i et markeret objekt via et editor vindue. Der tages forbehold for at der kan tilføjes attributter på objekterne således at der i stedet for angives ejer af bilen eller traileren og ikke blot om tn-transport ejer den eller ej. Side 33

34 34 TN Transport og Spedition PROJEKT Analyse konklusion Der er ikke tid til at implementere hele systemet. Fra firmaets side er det Fakturerings delen der vejer tungest. For at kunne implementere denne skal kunde og tur delen først implementeres. For at have et funktionelt anvendeligt system vil det være nødvendigt at implementere et system til håndtering af chauffører, vognmænd samt køretøjer. Dette vil dog ikke blive implementeret da det ikke er muligt nå ordenligt i dybten med tur use-casen hvis alt skal implementeres. Arkiv systemet vil ligeledes være nødvendigt da det ikke er forsvarligt at kunne slette en kunde i et fakturerings program, men heller ikke praktiskt at en kunde liste kan indeholder kunder der ikke længere har ordre ved firmaet. Det er uvist om det er muligt at når at implementere Faktura delen så den virker korrekt. I første omgang skal der ligges størst vægt på Kunde og Tur, da ordentlig implementering af disse er en forudsætning for at kunne implementere Faktura Udkast. Side 34

35 35 TN Transport og Spedition PROJEKT Design System, database design og forklaring, samt valg af mønstre. System Design Der er anvendt åben lagdelt arkitektur. Det er åbent i den forstand at modellagets klasser bruges til at sende data, så modellaget er tilgængeligt fra alle lag. Den lagdelte arkitektur går som vist på figuren ud på at du har GUI laget i toppen. GUI ens eneste formål er at styre in- og output til/fra brugeren. GUI en sender så sine data til CTR laget som så løser opgaverne og sender svaret tilbage til GUI en. I det implementerede system er CTR lagets opgave hovedsageligt at kommunikere med databaselaget. Databaselaget styrer alt kommunikation med databasen. Hvert lag kan når et hak ned, men aldrig op. GUI en kan anvende CTR laget, CTRlaget kan anvende DB laget, men ikke GUI Laget. Model laget kalder Figur 13, Kilde: "Tema Persistens" (Power point præsentation) af Kis Boisen Hansen ingen metoder uden for sig selv. Alle lag har selvfølgelig adgang til Model Laget som følge af den åbne arkitektur. Det er praktisk med en lagdelt arkitektur da det gør det lettere at skifte delene ud. Skal databasen skiftes ud er det kun DBLaget det der skal udskiftes/ændres, da det er den eneste klasse der har forbindelse til databasen. Brugergrænsefladen kan også skiftes uden at det kræver nogle ændringer i de andre lag. Mønstre: Der er designet ud fra low coupling mønsteret. Koblingen er meget lav. Den eneste forbindelse der er mellem klasserne er kald af offentlige metoder. Systemet er designet således at der er højst mulig samhørighed (cohesion) i den enkelte klasse og så lav kobling mellem klasserne som muligt. Dette gør systemet mere vedligeholdelses venligt, da der lettere kan ændres i en klasse uden at det påvirker en anden. Generelt er samhørigheden høj. Dog er der i hvert lag enkelte klasser man kunne argumentere for burde være to separate klasser i stedet for en, men så står man jo med det generelle problem at disse to klasser ville få for høj koblingen eller at der generelt ville være stor duplikation af kode. Et godt eksempel på det er DBTur. DBTur tager sig af database tilgangen til Tur og TurKladde tabellerne. Tabellerne har de samme attributter men forskellige navne. Man kunne sagtens dele klassen op og lave en DBTurKladde klasse, men så ville DBTur så bare være nødt til at kalde DBTurKladde hver gang den skulle opdatere en Tur der skal Side 35

36 36 TN Transport og Spedition PROJEKT sættes ind i kladde tabellen. Derudover ville dette betyde at man ville have to klasser med næsten identiske kode og dette er yders upraktisk vedligeholdelses mæssigt. Det bør også nævnes at der anvendes singleton mønster i alle CTR klasserne. En kort gennemgang af lagene GUILayer Hver klasse i GUIlaget repræsenterer et vindue, med GUIKunde som det centrale element. Pakken TableModel i GUIlaget indeholder de tabeller der anvendes i GUIlaget. Pakken Tools indeholder test værktøjer og print klasse til GUIlaget. Tool klassen vil blive gennengået i afsnittet om implementering. CTRLaget I controler klasserne er anvendt singleton mønsteret, det betyder at der kun er et objekt af klassen. Der er en ctr klasse for hver use-case der er implementeret, altså Kunde, Tur og FakturaUdkast. Derudover er KreditnotaTur lagt under Tur da oprettelsen af en KreditnotaTur altid sker i forbindelse med en oprettelse eller opdatering af en Tur. For de use-cases der endnu ikke er fuldt implementeret: Bil, Trailer, Vognmand, Chauffør (alle simple CRUD usecases) er der oprettet en ArkivCTR. ArkivCTR ens eneste formål er at hente aflæsningsdata ud af databasen. Dette er selvfølgelig bare en midlertidig løsning, og denne klasse indeholder kun meget få metoder. Den sidste use-case der endnu ikke er nævnt er KreditnotaUdkast, implementerings mæssigt kommer denne til at minde meget om FakturaUdkast use-casen. Den har ligeledes en liste af Ture(KreditnotaTure selvfølgelig) som skal afregnes for, og så skal den skrives til en Vognmand og ikke en Kunde. Man skal dog huske at ligheden mellem Faktura- og KreditnotaUdkast kun er implementerings mæssigt, forretningsmæssigt er disse to modsætninger, da den ene er indbetaling og den anden udbetaling, men selve arbejdsgangen i dem ligner hinanden og de er begge centreret om begrebet Tur. DBLayer Databaselaget består af en DB klasse for hver klasse i modellaget. Til hver DB klasse er der lavet en interface (IFDB) klasse, som afskærer DB laget yderligt fra resten af systemet. De enkelte public metoder er veldefinerede og overskuelige. Der er en ekstra DB klasse som ikke er i modellaget, DBTurListe og IFDBTurliste. Da det ikke er muligt at ligge et Array i en tabel, har jeg i stedet lavet to tabeller der holder styr på hvilke Ture der er knyttet til hvilket FakturaUdkast, og hvilke KreditnotaTure der hører til hvilke KreditnotaUdkasts. DBTurliste har forbindelse til begge tabeller da tabellerne har de samme attributter, men blot forskellige fremmednøgler. Ud over DB klasserne og deres interface klasser er der 2 andre klasser, GetMax og DBConnection.GetMax klassen fungerer som et tool for de andre klasser og bruges udelukkende til at finde maxværdien af en bestem attribut i en given tabel i databasen. DBConnection bruges af samtlige DBKlasser i DBlaget da det er denne klasse der skaber forbindelse til databasen. Modellaget: Side 36

37 37 TN Transport og Spedition PROJEKT Til at starte med eksperimenterede jeg med at lave generaliseringer i modellaget som vist på figuren nedenfor. Vognmand, Chauffør og Kunde nedarver alle sammen fra Person. Figur 14 - Design spekulationer KontaktInfo er en del af personobjektet, dette er vist med en aggregering. Dette valgte jeg dog ikke at implementere da det gav flere implementering og funktionelle problemer end det gav fordele. Dette sætter også en Kunde i kategori med de ansatte hvilket rent forretningsmæssigt ikke kan forsvares. En anden løsning ville være at lave en Kunde og en Ansatte klasse, og så have mange attributter på den enkelte klasse. Ansatte skulle så kunne både være en vognmand og en chauffør. Dette var problematisk da der enten ville være tvetydige attributter eller null værdier. Fx har en virksomhed et cvr nr. og en chauffør har et cpr nr. Ønskede man på et senere tidspunkt at tilføje flere attributter ville det være problematisk da disse mere specifikke attributter typisk kun ville gælde for den ene type ansat. Ved kunde objektet er der implementeret en HashMap til kontaktpersoner, så der kan gemmes et navn og et telefonnummer. Dette ville være smart, men implementerings mæssigt især i DBLaget, og da telefonnumrene alligevel bare skulle bruges til simple visninger valgte jeg i stedet at lave en String. Hvad det endte med blev at lave en kunde, chauffør, vognmand og en kontaktopl klasse som har en aggregering til de 3 andre klasser. (Se figuren) Dette er praktisk da de oplysninger der er fælles for klasserne er samlet et sted, det Figur 15 Model layer diagram der viser relationerne mellem klasserne Side 37

38 38 TN Transport og Spedition PROJEKT gør det væsentlig lettere at tilføje flere kontaktoplysninger uden de store ændringer i koden, da det kun er kontaktopl klasserne der skal modificeres. Derudover er person klasserne lettere at arbejde med da de bliver simple og overskuelige. Design Klasse Diagrammet Dette er ikke et fuldt design klasse diagram da der hverken er angivet metoder eller attributter på klasserne, da dette desværre ikke er muligt at printe på et overskueligt sideantal. En fuld klasse oversigt med metoder og attributter kan findes i bilagene. Diagrammet er lavet i netbeans vha. reverse engineer for at lave et så præcist slut billede som muligt, da opdateringer af tidligere diagrammer ville være omstændigt og øge risikoen for fejl. Dette betyder dog at der skal tages forbehold for netbeans lettere overdrevne brug af aggregeringer. Man kan argumentere for at enkelte elementer i GUI en er aggregeringer af hinanden, men ellers er alt udenfor modellaget forbundet med associaseringer. I beskrivelsen af model laget er der en forklaring på hvilke objekter der er forbundet med aggregeringer og hvilke der blot er associaserede. Figur 16 - Design Klasse Diagram Side 38

39 39 TN Transport og Spedition PROJEKT Databasedesign: Jeg har valgt at lave Arkiv klasser så de gamle data ikke skal ligge og fylde i tabellerne. FX når en Tur er faktureret skal den ligges i Arkivet. Fyres en chauffør eller går en kunde fallit skal deres data stadig kunne findes i systemet da deres oplysninger stadig bruges i gamle fakturaudkasts, men samtidigt gider man jo ikke have det til at ligge fremme når det ikke er relevant for nye turer og fakturaer. Planen er så at de skal gemmes i Arkiv tabellerne. Arkiv delen er ikke implementeret i systemet, men tabellerne er oprettet i databasen. K_Tur_Liste (K = Kreditnota) og Tur_liste har til formål at knytte en mængde henholdsvis Ture og KreditnotaTure sammen med deres Faktura/KreditnotaUdkast. Tur_Kladde tabellen har alle de samme fremmed nøgler som Tur tabellen, dette er ikke vist med pile for læsevenlighedens skyld, da tabellerne er placeret lige ved siden af hinanden og indeholder de samme attributter. Kladden har til formål at kunne hentes frem som en slags skabelon for de mest kørte ture. Databasen er på tredje normal form da alle attributter er afhængige af dens tabels respektive primærnøgle. De fleste af tabellerne er også på Boyce- Codd normal form. De tabeller der kunne deles mere op ville være KontaktOplysninger og TurPris, da man ville kunne argumentere for at der er flere kandidatnøgler i disse. OBS! Ved fejlretning af kladde funktionen i Tur Editoren, blev det implementeret en Kreditnotatur_Kladde. Denne tabel er identisk med Kreditnotatur, borset fra navnet og fremmednøglen der peger på Tur_Kladde i stedet for Tur. Figur 17 - Relationel database model for systemet Side 39

40 40 TN Transport og Spedition PROJEKT Sekvens Diagram Nu er det nogenlunde på plads hvorledes systemet overnet skal se ud og hvad design målene er. Men hvordan det helt konkret skal udføres, hvordan metoderne skal kaldes er stadig meget frit. For at skabe mere overblik laves der Sekvens Diagrammer over de vanskeligste funktioner. Dette SekvensDiagram er lavet ud fra Faktura Udkast use-casen og viser OpretFaktura() funktionen. Operationskontrakt Operation: OpretFakturaUdkast(ArrayList<ture>, Kunde) Use-case: Faktura (punkt 1) Type: insert/opdatering Pre-betingelse: De valgte ture er oprettet med gyldige priser. Kunden, trailer og bil er oprettet. Post-betingelse: FakturaUdkastet og TurLister for alle de tilknyttede Ture oprettes i databasen. kald foregår gennem DBTurliste. Inden man kan redigere i fakturaen bliver den oprettet i databasen, sammen med TurListe erne der knytter den sammen med de valgte Ture. Dette har sine fordele da man kan kalde de allerede oprettede metoder til visning af ufakturerede Ture. Læsevejledning: Enkelte elementer er undladt for at fremme læsevenligheden. Dette omfatter størstedelen af kaldene til modellaget, da dette blot er set- og getmetoder, det eneste objekt fra model laget der er vist er FaukturaUdkast selv. Interface objektet IFDBTurliste er ikke afbilledet da alle videre Forklaring Der trykkes på Opret Faktura knappen i GUI en. ActionListener sender en ActionEvent til GUIKunde. GUIKunde laver et Faktura objekt (dette er ikke illustreret). Der hentes en instance af CTRFakturaUdkast (CTR) og herefter kaldes insert(fakturaudkast) i CTR. FakturaUdkast et lavet i GUI en og sendes ned gennem systemlagende. CTR laver et nyt objekt af DBFakturaUdkast gennem IFDBFakturaUdkast(dette var ikke muligt at illustrere helt entydigt, og det er derfor der ikke er noget metode kald mellem CTR og IFDBFakturaUdkast). Insert metoden kaldes i DBFakturaUdkast som opretter forbindelse til databasen gennem DBConnection. Gennem MaxId hentes det nye id til FakturaUdkastet. FakturaUdkastet indsættes i databasen vha. et SQL statement som bliver lavet ud fra et String objekt. Hvis dette lykkes lukkes forbindelsen til databasen og der startes et loop som opretter TurListe i databasen. Der oprettes en turliste for hver tur der er på FakturaUdkastet. Turlisten angiver hvilken Tur, hvilket FakturaUdkast og placeringen på FakturaUdkastets liste. Turliste objektet er lavet gennem IFDBTurListe, ligesom med det førnævnte DB-objekt, men dette er undladt for læsevenlighedens skyld. TurListe opretter også forbindelse til databasen gennem DBConnection. rc er et tjek tal der fortæller hvorvidt det lykkedes at indsætte værdierne i databasen. Er rc = -1 er noget gået galt undervejs. Da id et først bliver bestemt i database laget har jeg valgt at returnere id hvis operationen lykkes. Dette er praktisk da det så er let at hente FakturaUdkast objektet frem igen, når man kan søge direkte på id et. Side 40

41 41 TN Transport og Spedition PROJEKT Figur 18 - Sekvens Diagram for OpretFaktura() Side 41

42 42 TN Transport og Spedition PROJEKT DEL 4 IMPLEMENTERING & TEST Referat Der er en kort gennemgang beskrivelse af kodestandarten. Da der arbejdes alene har yderlig definering af denne ikke været prioriteret. Der gennemgås kode fra en af Tool pakken samt et use-case forløb for opretfakura() (se Sekvens Diagram i forrige afsnit). Der er løbende fortaget random tests af systemet. De har været use-case drevne og vist sig ret så effektive. Der er implementeret en test klasse som en integreret del af systemet. Denne klasse findes i Tool pakken og kaldes TjekTurObjekt. Der også en TjekKundeObjekt, men denne er endnu ikke implementeret. Idealet ville være at have sådan en klasse til alle objekter der bygges i GUI en. Tjek klasserne gennemgår systematisk objekternes attributter og returnere en specifik fejlmeddelelse der forklarer hvor eventuelle tastefejl eller længde bestemmelser ikke overholdes. Der er foretaget white- and blackboxtest af dele af systemet. Whiteboks testen af systemet har begrænset sig til at omfatte de variabler man har adgang til fra GUI en da der ikke var tid til at implementere flere test klasser. Black boks testen var funktions orienteret og der blevet fundet flere fejl. De fleste er løst inden afleveringen af projektet. Enkelte små elementer i systemet er ikke færdig implementeret og har ingen funktion. Disse er: Pris Beregner knap i Tur Editoren Udelandsk adresse checkboks i KundeGUI> Adresse Bogfør knap i KundeGUI > fakturaer Tur liste visningen i Faktura Udkast vises ikke korrekt i GUI en, men er implementeret efter planen i alle andre system lag. En brugsvejledning til systemet kan findes i bilagene (Del 5). Her er også en begrebs forklaring som anbefales at læse før brug af systemet. Side 42

43 43 TN Transport og Spedition PROJEKT Implementering Kodestandartsbeskrivelse samt kommenterede udsnit af kode. Kodestandart Eksempel på kodestandart: Første { placeres ikke på sin egen linje. Slut n } skal placeres så den er på lodret linje med starten af den linje hvorefter { er placeret. Efter hver ny { skal den næste linje have et nyt indryk. Variablernavne er forkortelser som fx begyndelses bogstavet i de ord der indgår i objektet. Feks. KreditnotaTur kt = new KreditnotaTur(); En ArrayList over Tur, kaldes t eller ture. Variabler der ikke er indlysende forklares kort med en kommentar // Denne behøves ikke have sin egen linje, men placeres hvor det kommentarens indhold i betragtning giver mest mening at placere den. Side 43

44 44 TN Transport og Spedition PROJEKT Kode eksempel fra Tool klassen. Klasse: TjekTurObjekt. Her er kode fra hele klassen TjekTurObjekt. Denne klasse ligger i Tool pakken. Den indeholder to public metoder tjektur(tur t) og tjekktur(kreditnotatur kt), som har til formål at tjekke et Tur eller KreditnotaTur objekt og se om det overholder databasens krav med hensyn til type og længde. Hvis der findes en fejl i tur objektet returneres en String med en beskrivelse af hvad der er galt, ellers returneres en tom String. tjekktur() Kreditnota objektet har kun en attribut der kan tjekkes; prisen. Derfor kaldes cifreok() metoden. Metoden er en boolean som tjekker om måden cifrene er sat op på overholder den ønskede længde. Den ønskede længde for før og efter kommaet, samt prisen sendes derfor til cifreok() metoden. Returneres true fra cifreok(), sendes en tom String retur, ellers kaldes metoden getprisfejl() som returnere en String med en fejlmeddelelse. tjektur() Der oprettes en lokal variable String s = ; Denne variabel returneres ved metodens slutning. Tur objektet har massere af attributter der skal tjekkes. Alle String attributterne sættes på en ArrayList vha. metoden turdatatilstring(). Metoden tjekturstring() kaldes. s = tjekturstring(); Side 44

45 45 TN Transport og Spedition PROJEKT ArrayListen fra før sendes med ned i metoden. tjekturstring kalder en ny metode getturspec() som returnerer en liste over max længde bestemmelserne for den enkelte attribut på en ArrayListe. tjekturstring() køre nu et while loop som tjekker om længden af String attributterne er for lange. Er de ikke det returneres en tom String. Findes der en fejl kaldes metoden getfejlmeddelsetur(). Index nummeret for ved hvilken tur det gik galt sendes med og der returneres en String med en fejlmeddelse der fortæller præcis hvad problemet er. Hvis s nu er andet end en tom String returneres s og metoden tjektur ()slutter. Hvis s er tom tjekkes priserne. Metoden tjekturdouble(), TurPris objektet fra Tur sendes med ned i denne metode. tjekturdouble() kalder cifreok() metoden på alle double værdier. Findes der en fejl kaldes getprisfejl() og denne returneres til tjekturobjektet() s = tjekturdouble(); s returneres og tjekturobjektet() metoden afsluttes. Side 45

46 46 TN Transport og Spedition PROJEKT Use-case Eksempel Opret Faktura OpretFaktura fra use-case forløbet FakturaUdkast. For at arbejde med FakturaUdkastet har jeg valgt at sige at det skal oprettes/indsættes i databasen først. GUI en sammensætter et FakturaUdkast objekt (Se klassen til venstre) som sendes til CTR laget: Metoden kaldes i CTRFakturaUdkast: Metoden kalder videre ned i DBLaget, mere præcist DBFakturaUdkast: Side 46

47 47 TN Transport og Spedition PROJEKT Da der ikke kan indsættes en ArrayList i en databasens tabeller, skal der i stedet indsættes værdier i tabellen TurListe som holder styr på hvilke Ture der høre til hvilket FakturaUdkast. Metoden updateturliste kaldes, stadig i DBFakturaUdkast. Side 47

48 48 TN Transport og Spedition PROJEKT Test White- og blackboxtest samt testresultater. Systemet er løbende blevet blackbox testet. Det har været af høj prioritet at få de simplere elementer gennemtestet og derudfra arbejdet videre. Dette har gjort at systemet har kunnet klare use-case forløb forholdsvis tidligt i forløbet. Den iterative arbejdsproces har betydet at der løbende er blevet ændret designmæssige ting, disse har medført størstedelen af de fundne fejl. Der har ikke været implementeret testklasser udover dem i Tool pakken, men der er blevet lavet enkelte metoder(se figuren til højre) til fx at genere Tur objekter der kunne bruges i de tidligste tests. Whitebox-test For at lave en fuld white box test skal der laves omfattende test klasser i DBlaget. Dette vil ikke blive implementeret, da en løbende testning allerede har testet dette efter bedste evne. Figur 19 - Test metode til at lave Tur objekt. Der vil derfor kun blive foretaget de tests der kan foretages fra GUI en, altså fejl der kan opstå ved brugeren måde at anvende systemet. White box testen er lavet over godkend() metoden som afvikles når der trykkes på Godkend knappen i TurEditor vinduet. Figuren til højre illustrer de mulige veje gennem metoden samt de mulige udfald. Under godkend() kaldes yderligt to lokale metoder: opdatertur(), opdaterkreditnotatur(). Disse to er der lavet separate diagrammer for, disse kan findes på den næste side. De variabler man kan have indflydelse på i GUI en er følgende: Godkend: A (true) = Kreditnota Figur 20 - whitebokxtest til metoden Godkend() i jdialogtureditor klassen Side 48

49 49 TN Transport og Spedition PROJEKT OpdaterTur: CheckBoks markeret. A (false) = Kreditnota CheckBoks IKKE markeret. B(true) = Gyldig pris. B(false) = ugyldig pris. C(true) = gyldige Strings, ikke for lange bogstav værdier. C(false)= ugyldige data D(true) = Kladde Checkboks er markeret D(false) = Kladde Checkboks er IKKE markeret OpdaterKreditnotaTur: (NY VÆRDI E = C i diagrammet) E (true) = hvis turen tidligere har fået tildelt en kreditnotatur er ktur!= null E(false) = Turen har ikke en kreditnota tur tilknyttet. Grænseværdier: Double (priser) <= decimaler (7,2) Tilladte antal karakterer i: Beskrivelse: 40 Rute: 40 Tillæg: 45 Dato: 10 Kommentar: 500 Side 49

50 50 TN Transport og Spedition PROJEKT Test skemaet nedenfor viser hvilke udsagn der skal være sande og falske og hvad resultatet bør bliver. Dette er ikke en fuld test, for så skulle testen udføres i på alle klik-bare felt og deres indbyrdes kombinationer, som brugeren har adgang til i TurEditor vinduet. T står for TRUE, F står for FALSE, X betyder at denne variabel allerede er sat eller ikke har relevans for denne test. Resultaterne står angivet til højre. Hvis resultatet matchede med det ønskede resultat er der krydset af i T, eller vælges F. Som det kan ses fandt test brugeren ingen fejl i denne test. Dette betyder IKKE at der ikke er fejl, da testen langt fra dækker 100 %. E A B C D resultater T F 1 T X T T T T X 2 T X T T F T X 3 T X T F T F X 4 T X T F F F X 5 T X F F F F X 6 T X F T F F X 7 T X F F T F X 8 X F F F T F X 9 X F F T F F X 10 X F F T T F X 11 X F T T T T X 12 X F T F T F X 13 X F F F F F X 14 X F F T F F X 15 X F T T F T X 16 F T T T T T X 17 F T T T F T X 18 F T T F T F X 19 F T T F F F X 20 F T F F F F X 21 F T F T F F X 22 F T F F T F X Side 50

51 51 TN Transport og Spedition PROJEKT Blackbox-test Test case Hovedformålet med denne test er at se hvorvidt TurEditoren kan klare use-casens krav og om hvordan den fungere sammen med KundeGUI en. Deres sammenspil er vigtig da alt håndtering af turen foretages fra KundeGUI. Dette er ikke en 100% test af systemet! Blot en test af hvad der forventes at blive de mest anvendte stier gennem systemet. Grænseværdierne testes ikke, kun funktionerne. Grænseværdierne testes af testklassen TjekTurObjekt, denne er løbende blevet testet gennem brug og har endnu ikke haft større mangler. Generelle ting at være opmærksom på: Rediger og Slet knapperne bør ikke kunne klikkes på hvis der ikke er en tur markeret i tabellen. Opret FakturaUdkast skal kunne klikkes på når der er en eller flere ture markeret. Tur Opret 1. Vælg "Kunde" fanen. Tast "Limfjorden" i søgefeltet og vælg "Søg". Der skulle nu vises en liste over ufakturerede turer i tabellen nedenfor. Vælg "Opret Tur". Der åbnes nu et nyt vindue med kundens navn øverst. 2. Indtast : dato: Vælg Bil: UU og Trailer: MN Rute: Hadsund-Aalborg-Hirthals-Hjørring Beskrivelse: 10 paller Pris: Afkryds Kreditnota og vælg vognmand: Anders Jensen. Sæt pris til Afkryds Kladde. 5. Vælg "godkend". Der skal nu komme en boks der siger " Turen er gemt". Klik "ok", vinduet lukkes og du er tilbage i "Kunde" fanen. 6. Turen skulle nu kunne ses på listen. Tur Rediger 1. Marker turen og vælg "Rediger". Tjek at alle oplysningerne står der korrekt og ændre følgende værdier: dato: Bil: VK Trailer: EL 6993 Rute: Aalborg- Hirthals beskrivelse: 450 kg Pris: Tillæg: olietillaeg Tillægspris: 500 Fjern kryds ved Kreditnota. 2. vælg så "Godkend". Der skal nu komme en boks der siger " Turen er gemt". Klik "ok", vinduet lukkes og du er tilbage i "Kunde" fanen. 3. Vælg nulstil. Alle felter skulle nu være tomme. Side 51

52 52 TN Transport og Spedition PROJEKT 4. Indtast Lim i søgefeltet. Kundeoplysningerne for Limfjorden burde nu vises på skærmen. 5. Vælg turen fra før fra tur-listen og vælg "Rediger". Tjek at opdateringen de sidste ændringer er gemt. Vælg annuller. Vinduet skulle nu lukkes og du er tilbage i "Kunde" fanen. 6. Marker turen igen og vælg slet. Turen skulle nu fjernes fra tur listen. 7. Vælg Nulstil, vælg Alle Kunder. Der burde nu åbnes et nyt vindue med en liste over alle kunderne i databasen. Maker Limfjorden og vælg Vælg. Vinduet lukkes og du er nu tilbage i Kunde fanen, og Limfjordens oplysninger er vist på skærmen. Tjek at turen stadig ikke er på listen. 8. Vælg opret tur. Klik på Kladder, marker den første på listen og klik på vælg. Felterne skulle nu blive fyldt. 9. Ændre pris og vognmanden og vælg Godkend 10. Du er tilbage i Kundefanen. Klik på turen fra før og vælg rediger. Tjek at oplysningerne stadig er der. 11. Ænder i et vilkårligt felt og vælg Annuller. 12. Marker turen og vælg rediger. Tjek at din ændring ikke er blevet gemt. Opret Faktura 1. Start i Kunde fanen. 2. Indtast Bilka i søgefeltet og tryk enter. Oplysningerne for Bilka Hus og Have vises nu på skærmen. 3. Marker en tur fra listen og vælg Opret faktura. Et Faktura Udkast vindue skulle nu åbnes og Kundens adresse oplysninger, dagsdato og den valgte tur er vist i tabellen. Tjek at Sum beløbet. 4. Vælg tilføj Tur. Der åbnes nu en nye dialogboks, marker en Tur i tabellen og vælg tilføj. 5. Du er tilbage i faktura vinduet og den nye Tur er nu vist på listen. 6. Tjek at Sum stemmer med turenes samlede priser. Tilføj en tur mere (tjek at den sidst tilføjede tur ikke længere er på listen over ture). Tjek summen igen. 7. Marker en Tur, vælg fjern. 8. Vælg Tilføj tur og tilføj den samme tur igen. 9. Ændrer rækkefølgen af turene ved at markere en tur og bruge knapperne ude til højre Flyt op og Flyt ned. 10. Ændrer i adressen og datoen. 11. Er du tilsluttet en printer, så vælg print. Under egenskaber vælg vis udskrift før udskrivning. Brug dette til at se udskriften og luk derefter vinduet ned. Dette vil højst sandsynligt ikke virke hvis ikke der er en printer tilsluttet. 12. Vælg godkend. Fakturaen er nu gemt. Du er tilbage i kunde fanen. Rediger Faktura 1. Vælg på fanerne i toppen Faktura. Der er en tabel med FakturaUdkasts, vælg den du lige har lavet og vælg rediger. (Dette er okay da den ikke er bogført endnu, men kun er en skitse/udkast). Der åbnes nu et FakturaUdkasts vindue som viser fakturaudkastet fra tidligere. 2. Ændre lidt i alle data og vælg godkend. 3. Marker turen og vælg rediger igen. Se at ændringerne er gemt og vælg Slet. 4. Du er tilbage til fakturaudkast tabellen. Tjek at FakturaUdkastet mangler. Vælg kunde fanen og tjek at turene er tilbage på tabel listen over ture. Side 52

53 53 TN Transport og Spedition PROJEKT 5. Marker 3 ture(hold ctr nede og klik-marker 3 ture), vælg opretfakturaudkast. 6. Der åbnes nu et FakturaUdkast vindue med de valgte Ture. 7. Vælg godkend. FakturaUdkastet er gemt. Du er tilbage i Kundefanen. 8. Vælg Faktura-fanen. Marker fakturaen på listen og vælg slet. Tabellen skulle nu opdatere så FaturaUdkastet ikke længere er på listen. Og turene skulle kunne ses på Kundefanen. Test resultater: Whiteboxtest: Ingen fejl fundet. Systemet svarede som forventet. Blackbokxtest: 1. KundeGUI: når man åbner Vis alle kunder eller Favoritter og vælger annuller kommer der stadig en kunde på skærmen. Øjensynligt den sidst valgte fra en liste. 2. Når der redigeres i et FakturaUdkast mangler adressen. Den bliver ikke vist. 3. Når man ændre rækkefølgen af turene i en faktura så ændres de godt nok, men når man gemmer og henter den frem igen, er de vist i modsat rækkefølge. 4. Der kan ikke oprettes kunder med i navnet. I Tur Editoren: 5. Tur Kladder kunne ikke fjernes fra listen Kladde listen. 6. Tur Kladdens turpris id lavede rod i id udelings metoden. 7. Der mangler en KreditnotaTurKladde tabel i databasen, hvis KreditnotaTur skal kunne gemmes sammen med TurKladde. 8. En opdaterings fejl hvis grund er ukendt. 9. Ved opdatering af en Tur, fjernes evt. KreditnotaTur ikke selvom man beder om det. 10. Summen er lang tid om at opdatere og nogle gange skal man klikke på feltet igen. Fejl nr. 1 kræver en mindre rettelse i GUI en. Omfanget af fejl nr 2 s omfang er ikke helt sikkert, Det kan være en fejl i såvel GUI som DB klasserne. Fejl nr. 3 er sandsynligvis en fejl i DBFakturaUdkast klassen. Fejl 1-3 kan ændres. Fejl 4 har grund i valget af måde at kommunikere med databasen på og kan ikke umildbart ændres. Fejl 5-9 er kræver store ændringer i systemet samt ændringer i databasen. Den vil derudover gøre ovenstående Whiteboxtest forældet. Andre fejl: MS SQL server snakker ikke særlig godt sammen med netbeans. Data lagt ind i databasen direkte gennem MS SQL kan ikke læses af netbeans hvis de indeholder Æ,Ø eller Å. Dette betyder at alle by navne der indeholder Æ,Ø eller Å ikke ville blive vist korrekt. Hvilke fejl er blevet rettet: 1,2,5,6,7,9 Nr. 8 var en fejl opstået i forbindelse med design ændringen som følge af rettelse af fejl nr. 6. Alle forsøg på at løse Fejl nr 3 har forudsaget væsentlig større fejl, så denne fejl er ikke blevet rettet. Side 53

54 54 TN Transport og Spedition PROJEKT DEL 5 BILAG Referat Bilagene indeholder: Kildeliste Installations vejledning, herunder script vejledning og driveropsætning til databasen. Bruger vejledning SQL scripts Oversigt over system klasser (bilag til designklasse diagrammet på s. 39) Ekstra Sekvens Diagrammer opdatertur(), getkunde() Side 54

55 55 TN Transport og Spedition PROJEKT Kilder Softwareliste Følgende udviklings og UML software er anvendt i dette projekt: Netbeans IDE Microsoft SQL Server 2008 Microsoft Office Visio 2008 Litteraturliste Følgende bøger er blevet brugt som inspiration: Objekt Orienteret Analyse & Design Lars Mathiassen, Andreas Munk-Madsen, Peter Axel Nielsen og Jan Stage Forlaget Marko Fundamentals of Database Systems Ramez Elmasri, Shamkant B. Navathe Forlaget Pearson Addison Wesley Applying UML and Patterns Craig Larman, Forlaget Prentice Hall Organisation Henrik Kjær, Hans Jørgen Skriver, Erik Staunstrup Forlaget Trojka Side 55

56 56 TN Transport og Spedition PROJEKT Installations vejledning: Åben Microsoft SQL Server Kør Scripts fra mappen SQL scripts Kør scriptene fra den medfølgende cd i denne rækkefølge: OBS! I det første script skal du ændre stien så den passer til en placering på din computer. 1 Create database 2 opret tabeller 3 by_postnr 4 insert Kør netbeans IDE, TN_Transport fra cd-en og run GUIKunde. Driver opsætning: Driver opsætning: Åben Kotrolpanel > Administration > Datakilder (OBDC) > Vælg fanen System-DNS > Vælg knappen Tilføj Vælg SQL Server Native Client 10.0 på listen og tryk på Udfør. Under Name skriver du: TN_Transport. Under Server vælger du din Computers navn. Klik på Næste Vælg With integrated Windows authentication Klik på Næste Side 56

57 57 TN Transport og Spedition PROJEKT Vælg Change the default database to: TN_Transport Vælg Use ANSI qouted identifier Vælg Use ANSI nulls, padding and warnings Klik på Næste Klik på Udfør I det nye vindue klik på Test Data Source.. Lykkes testen klik på ok. TN_Transport skulle nu stå på din liste over DataKilder. Side 57

58 58 TN Transport og Spedition PROJEKT Brugervejledning: Systemet køres fra KundeGUI en. Hvad kan systemet? Der er i forvejen lagret en kundedatabase i systemet. Du kan vælge selv at oprette en kunde eller bruge en af de allerede oprettede kunder. Under kunden kan du oprette ture (det man i normal forretningsøjemed ville kalde en ordre, men som i vognmands branchen lettere kan beskrives som en Tur ). Når du har en mængde ture kan du oprette et FakturaUdkast som kan printes ud. Begreber: FakturaUdkast: Lovgivningsmæssigt er det ikke tilladt at redigere i en Faktura. Derfor arbejdes der udelukkende med FakturaUdkasts. Der er ikke tale om en Faktura før dennes bogføres. Bogføringsfunktionen er ikke implementeret. KreditnotaUdkast: Kreditnotas anvendes til at betale freelancevognmændene for deres arbejde. Udkast, anvendes af samme lovmæssige grund som i FakturaUdkast. Favoritter: Kladde: Brugeren kan under brugere oplysningerne vælge om kunden er en favorit. Dette betyder at det er en fast kunde, som ofte bruges. Nogle ture minder meget om hinanden. For at gemme dem som kladde skabeloner, skal der klikkes på Kladde checkboksen i toppen af TurEditor Vinduet inden turen gemmes. Næste gang der er brug for kladden, opretter man en ny tur som normalt. Når TurEditoren så åbner klikker man på knappen Kladder hvorefter man kan vælge den ønskede kladde-tur fra en liste, og dermed genbruge allerede indtastede data. KreditnotaTur: Dette begreb er tæt forbundet med TN-Transports måde at anvende Kredinotas på. Hver gang en tur er blevet kørt af en af de tilknyttede freelance vognmænd skal der oprettes et KredinotaUdkast. Da der typisk afregnes for mere end en tur af gangen er begrebet KreditnotaTur indført. Ved oprettelsen af en Tur kan der krydses af om man også vil oprette en KreditnotaTur der senere kan laves til et KreditnotaUdkast (Dette er ikke implementeret endnu). Ved oprettelsen af en Kreditnota Tur angiver man, Vognmand og Pris. PrisBeregner: Er et endnu ikke implementeret hjælpe værktøj til at støtte prisudregningen på en tur. Side 58

59 59 TN Transport og Spedition PROJEKT Søg Kunde Der 4 forskellige måder at søge en kunde frem på. 1. Klik på knappen Alle Kunder. Der kommer nu et pop-up vindue med en liste over kunder. Marker en kunde på listen ved at klikke i tabellen og klik på Vælg knappen. 2. Klik på knappen Favoritter. Der kommer nu et pop-up vindue. Marker en kunde på listen ved at klikke i tabellen og klik på Vælg knappen. 3. Indtast navn eller cvr og klik på Søg knappen. 4. Indtast navn eller cvr og vælg <enter> OBS: En kunne kan til hver en tid søges frem vha. ovenstående metoder OGSÅ selvom en anden allerede er søgt frem. Opret kunde For at oprette en kunde skal alle felter være tomme. Klik på Nulstil knappen hvis du har kunde oplysninger vist fra tidligere søgning. 1. Indtast navn og evt et cvr nummer. Klik på Opret knappen. Rediger Kunde Når først kunden er vist på skærmen vil alle ændringer du laver blive gemt (dette dog med undtagelse af navn og cvr. nr. felterne). Du behøves ikke lede efter nogen gem knap, alt bliver gemt automatisk når du søger på efter en ny kunde eller nulstiller. Ændre kundens navn eller cvr: For at ændre kundens navn eller cvr, kræves det dog at du vælger Nulstil ellers vil disse oplysninger ikke blive gemt da felterne jo også fungere som søge felter. For at redigere kontakt oplysningerne på kunden bruges fanerne i toppen, her kan tilføjes adresse og andre kontakt oplysninger. Rediger adresse: For at redigere adressen, klik på Adresse fanen i toppen. Er det en dansk adresse indtastet Gadenavnet i feltet af samme navn. Herefter indtastes enten bynavn eller postnr i boksene under og der klikkes <enter>. Systemet finder nu selv byen der passer på postnummeret. Eller henter postnummeret der passer til bynavnet. OBS! Grundet SQL netbeans sprog barriere kan byer skrevet med æ, ø og å ikke vises korrekt. Ved udenlandsk adresse skrives hele adressen i feltet Gadenavn, postnr og by lades tomme. Opret Tur OBS! Der skal være søgt en kunde frem før der kan oprettes ture! Side 59

60 60 TN Transport og Spedition PROJEKT 1. Klik på knappen Opret Tur. Der oprettes ny en tur og der åbnes et vindue hvor du kan tilføje flere oplysninger. Dette vindue refereres til som TurEditoren. Rediger Tur 1. I TurEditoren indtaster du så de oplysninger du ønsker at tilføje. Disse gemmes når du klikker på knappen Godkend. 2. Ønsker du ikke at gemme de indtastede data så klik på Annuller knappen. Værd at vide: Summen vil automatisk blive opdater. Bil, Trailer, Vognmand, samt Chauffør, vælges vha. en combo boks der ved markering viser en liste. Ved at klikke på et af elementerne på listen vælger du dette. Du kan til hver en tid nulstille boksen ved at vælge det første element i boksen som er tomt. Priser kan max være på 7 cifre før kommaet. OBS! Kommaer angivet med PUNKTUM i alle tal. Der kan ikke skrives bogstaver i pris felter. KreditnotaTur og Kladde er kort gennemgået under begreber og vil ikke bliver forklaret yderligt i dette afsnit. Opret FakturaUdkast For at oprette en faktura skal du have ture oprettet under kunden du ønsker at lave en faktura til. 1. Marker de turer du ønsker at fakturere. Hold ctr-knappen nede og klik på turene med musen. 2. Klik på Opret FakturaUdkast. Der åbnes nu et FakturaUdkast vinduet hvor du kan redigere oplysninger om Fakturaen. Rediger Faktura I FakturaUdkasts vinduet kan du tilføje flere ture vha. Tilføj tur knappen som giver dig en liste med ture hvor du kan vælge en fra. Her kan kun vælges en af gangen. Du kan fjerne ture igen ved først at markere en tur og derefter klikke på Fjern knappen. Du kan ændre rækkefølgen af turene ved at markere en tur på listen og bruge Flyt op og Flyt ned knapperne til højre for tabellen. Du kan redigere i turene ved at markere dem og klikke på knappen Rediger. Summen opdatere automatisk. For at udskrive fakturaen, klik på Print knappen Du kan frit ændre i adresse, dato og faktura nr. felterne. Du kan vælge at gemme ændringerne i fakturaen ved at vælge Godkend ELLER slette den ved at vælge Slet. OBS! Du kan vælge at gemme fakturaen eller slette den. Ved at slette fakturaen sletter du IKKE turene, disse bliver blot sat tilbage på i tur tabellen i kundefanen. Side 60

61 61 TN Transport og Spedition PROJEKT SQL scripts Create databasen CREATE DATABASE TN_TRANSPORT ON ( NAME = tn_dat, FILENAME = 'c:\users\jeanette\documents\sql\tn_d at.mdf', SIZE = 10, MAXSIZE = 50, FILEGROWTH = 5 ) Tabeller USE TN_TRANSPORT create table POSTNR_BY ( bynavn varchar(33), postnr primary key (postnr)); create table KontaktOplysninger (id int not null, adr varchar(50), postnr varchar (50), web varchar (50), mb varchar(30), tlf varchar(30), kommentar varchar (600), kontaktpers varchar(600), fax varchar(20), primary key (id), foreign key(postnr) references POSTNR_BY(postnr)); create table KUNDE (id int not null, navn varchar(50) not null, favorit kontakt_id cvr varchar (15), primary key (id), foreign key (kontakt_id) references KontaktOplysninger(id)); create table KUNDE_ARKIV (id int not null, navn varchar(50) not null, favorit kontakt_id cvr varchar (15), primary key (id), foreign key (kontakt_id) references KontaktOplysninger(id)); create table TRAILER ( navn varchar(15), trailer_type varchar (100), beskrivelse varchar(600), prod_dato varchar (20), primary key (navn)); create table TRAILER_ARKIV ( navn varchar(15), trailer_type varchar (100), beskrivelse varchar(600), prod_dato varchar (20), primary key (navn)); create table BIL ( navn varchar(15), bil_type varchar (100), beskrivelse varchar(600), prod_dato varchar (20), primary key (navn)); create table BIL_ARKIV ( navn varchar(15), bil_type varchar (100), beskrivelse varchar(600), prod_dato varchar (20), primary key (navn)); create table VOGNMAND ( id navn varchar(50), cvr varchar(15), kontakt_id primary key (navn), foreign key (kontakt_id) references KontaktOplysninger(id)); create table VOGNMAND_ARKIV ( id navn varchar(50), cvr varchar(15), kontakt_id primary key (navn), foreign key (kontakt_id) references KontaktOplysninger(id)); create table CHAUFFOR( id navn varchar(50), cpr varchar(15), kontakt_id primary key (navn), Side 61

62 62 TN Transport og Spedition PROJEKT foreign key (kontakt_id) references KontaktOplysninger(id)); create table CHAUFFOR_ARKIV( id navn varchar(50), cpr varchar(15), kontakt_id primary key (navn), foreign key (kontakt_id) references KontaktOplysninger(id)); create table TURPRIS ( id grundpris decimal(7,2), tillaeg varchar(45), t_pris decimal(7,2), km kg pris_pr_km decimal(7,2), primary key (id)); create table TUR ( id int not null, beskrivelse varchar(40), kunde_id chauffor varchar(50), rute varchar(40), dato varchar(10), bil varchar(15), trailer varchar(15), kommentar varchar(500), pris_id primary key (id), foreign key (kunde_id) references Kunde(id), foreign key (chauffor) references chauffor(navn), foreign key (trailer) references Trailer(navn), foreign key (pris_id) references TurPris(id), foreign key (bil) references Bil(navn)); create table TUR_ARKIV ( id int not null, beskrivelse varchar(40), kunde_id chauffor varchar(50), rute varchar(40), dato varchar(10), bil varchar(15), trailer varchar(15), kommentar varchar(500), pris_id primary key (id)); create table TUR_KLADDE ( id int not null, beskrivelse varchar(40), kunde_id chauffor varchar(50), rute varchar(40), dato varchar(10), bil varchar(15), trailer varchar(15), kommentar varchar(500), pris_id primary key (id), foreign key (kunde_id) references Kunde(id), foreign key (chauffor) references chauffor(navn), foreign key (trailer) references Trailer(navn), foreign key (pris_id) references TurPris(id), foreign key (bil) references Bil(navn)); create table KREDITNOTATUR ( tur_id vognmand varchar(50), pris decimal(7,2), primary key (tur_id), foreign key (tur_id) references TUR(id), foreign key (vognmand) references VOGNMAND(navn)); create table KREDITNOTATUR_KLADDE ( tur_id vognmand varchar(50), pris decimal(7,2), primary key (tur_id), foreign key (tur_id) references TUR_Kladde(id), foreign key (vognmand) references VOGNMAND(navn)); create table KREDITNOTATUR_ARKIV ( id tur_id vognmand varchar(50), pris decimal(7,2), primary key (id)); create table FAKTURA_UDKAST ( id nr dato varchar(10), kunde_id pris decimal(7,2), adr varchar (75), primary key (id), Side 62

63 63 TN Transport og Spedition PROJEKT foreign key (kunde_id) references KUNDE(id)); nr dato varchar(10), vognmand_navn varchar(50), pris decimal(7,2), primary key (id), foreign key (vognmand_navn) references vognmand(navn)); create table KREDITNOTA_UDKAST_ARKIV( id nr dato varchar(10), vognmand_navn varchar(50), pris decimal(7,2), primary key (id)); create table FAKTURA_UDKAST_ARKIV ( id nr dato varchar(10), kunde_id pris decimal(7,2), adr varchar (75), primary key (id)); create table TUR_LISTE ( tur_id create table KREDITNOTA_UDKAST( id id array_nr primary key (tur_id, id), foreign key (tur_id) references TUR ( id), foreign key (id) references FAKTURA_UDKAST(id)); create table K_TUR_LISTE ( array_nr tur_id id primary key (tur_id, id), foreign key (tur_id) references KREDITNOTATUR ( tur_id), foreign key (id) references KREDITNOTA_UDKAST(id)); create table TUR_LISTE_ARKIV ( array_nr tur_id id primary key (tur_id, id)); create table K_TUR_LISTE_ARKIV ( array_nr tur_id id primary key (tur_id, id)); Inserts Her er et udpluk af de forskellige insert der bruges til at oprette databasen. Der er angivet to eksempler til hver tabel type. Alt med id nr. 0 er default værdier. USE TN_TRANSPORT København K insert into POSTNR_BY (postnr, bynavn) values (0, 'Ikke angivet') insert into POSTNR_BY (postnr, bynavn) values (1000, 'København K') insert into POSTNR_BY (postnr, bynavn) values (1001, 'København K') ect ect. USE TN_TRANSPORT; insert into BIL (navn, bil_type, beskrivelse, prod_dato) Values('','','',''); insert into BIL (navn, bil_type, beskrivelse, prod_dato) Values('UU ','','',''); insert into TRAILER (navn, trailer_type, beskrivelse, prod_dato) Values('','','',''); insert into TRAILER (navn, trailer_type, beskrivelse, prod_dato) Values('MN 9126','','',''); INSERT INTO KONTAKTOPLYSNINGER (id, adr, postnr, , web, mb, tlf, kommentar, kontaktpers, fax) Side 63

64 64 TN Transport og Spedition PROJEKT VALUES(1,'tyttebaervej 61', 9560,'','',' ', ' ', 'Ejer af firmaet', 'Eva Andrea Nielsen, kone, hjemme ,arbejde ',' '); INSERT INTO KONTAKTOPLYSNINGER (id, adr, postnr, , web, mb, tlf, kommentar, kontaktpers, fax) VALUES(0,'Adresse ikke angivet', 0,'','','', '', '', '',''); INSERT INTO Chauffor(id, navn, Cpr, kontakt_id) VALUES(0, '', '', 0); INSERT INTO Chauffor(id, navn, Cpr, kontakt_id) VALUES(1, 'Torben Nielsen', 'cpr ', 1); INSERT INTO VOGNMAND( id, navn, cvr, kontakt_id) VALUES(0,'', '',0 ); INSERT INTO VOGNMAND( id, navn, cvr, kontakt_id) VALUES(1,'Anders Jensen', '',4 ); insert into Kunde(id, navn, favorit, kontakt_id, cvr ) VALUES('1', 'Pur Teknik A/S', '0', '6', ' '); insert into Kunde(id, navn, favorit, kontakt_id, cvr ) VALUES('2', 'Fodercentralen Limfjorden', '1', '7', ' '); INSERT INTO TurPris(id, grundpris, tillaeg, t_pris, km, kg, pris_pr_km) VALUES('1','4000.0','olie','300.0','0 ','0','0.0') INSERT INTO TurPris(id, grundpris, tillaeg, t_pris, km, kg, pris_pr_km) VALUES('2','4800.0','olie','300.0','0 ','0','0.0') INSERT INTO Tur(id, beskrivelse, kunde_id, chauffor, rute, dato, bil, trailer, kommentar, pris_id) VALUES('1','12 paller',6,'','aalborg- Esbjerg',' ', 'UU ', 'MN 9126','','1'); INSERT INTO Tur(id, beskrivelse, kunde_id, chauffor, rute, dato, bil, trailer, kommentar, pris_id) VALUES('2','950 kg',6,'','kolding- Esbjerg-Aalborg',' ', 'VX ', 'XZY-1300','','2'); INSERT INTO KreditnotaTur(vognmand, pris, tur_id) VALUES('Per Roslev','2000.0',1); INSERT INTO KreditnotaTur(vognmand, pris, tur_id) VALUES('Ander Jensen','2100.0',2); Side 64

65 65 TN Transport og Spedition PROJEKT Side 65

66 66 TN Transport og Spedition PROJEKT Side 66

67 67 TN Transport og Spedition PROJEKT Side 67

68 68 TN Transport og Spedition PROJEKT Side 68

69 69 TN Transport og Spedition PROJEKT Side 69

70 70 TN Transport og Spedition PROJEKT Side 70

71 71 TN Transport og Spedition PROJEKT Side 71

72 72 TN Transport og Spedition PROJEKT Side 72