Planlægningssystem til autoværksted.

Transkript

1 Side 1 af 49 Planlægningssystem til autoværksted. udført af Henning Svensson Kim Damgaard Indholdsfortegnelse Planlægningssystem til autoværksted... 1 Indholdsfortegnelse... 1 Beskrivelse af autoværkstedet... 2 Problemformulering... 2 Autoværkstedets vision... 2 Inception-fasen... 3 Krav til systemet... 3 Definition af system grænse... 3 Primære aktører... 3 Primære aktørers mål... 4 Definer Use Cases... 5 Supplerende specifikation... 7 Planlægning af næste iteration... 8 Udviklingsplan... 9 Forfinet vision Ordliste Go - No go? Elaboration-fasen Aktivitetsdiagram UC1 "Basic Flow": Testovervejelser System Sekvens Diagram Domain Model Kontrakter Detaljeret design Sekvensdiagrammer Systemarkitektur Det videre forløb Bilag Bilag 1: Beskrivelser af Use Cases i "Brief Format" Bilag 2: SystemTester.java: Bilag 3: Output ved kørsel af klassen SystemTester Bilag 4: Kildetekst til selve programmet... 37

2 Side 2 af 49 Beskrivelse af autoværkstedet Autoværkstedet beskæftiger 1 værkfører, 15 mekanikere, 3 lærlinge samt en kontorassistent. Det er primært kontorassistenten og værkføreren, der i dag tager sig af henvendelserne fra kunderne. Kundehenvendelserne sker enten telefonisk eller ved personlig henvendelse og drejer sig typisk om reservation af tid til reparation eller service. Ud fra de løbende reservationer udarbejdes planer for den enkelte mekanikers arbejdsdag. Disse udføres manuelt i dag, primært af værkføreren samt kontorassistenten. Mekanikerne har forskellige arbejdstider, men med samme ugentlige timetal. Der sker løbende ændringer i de ressourcer der er til rådighed på værkstedet, fordi de ansatte, som kan have specielle kompetencer, bytter arbejdstid, bliver syge osv. Ferie planlægges op til 1 år frem i tiden. Autoværkstedet har omkring 1500 stamkunder, der er registeret med diverse person-oplysninger samt oplysninger om deres biler (registreringsnr., mærke, årgang etc.). Til autoværkstedet er der tilknyttet en brugtvognshandel, således at mekanikerne kan arbejde på klargøring af biler til salg, når de ikke udfører reparationer eller service for kunder. Problemformulering Autoværkstedet ønsker at frigøre noget af den tid, der benyttes på kundehenvendelser og den manuelle planlægning. Værkføreren vil hermed, i højere grad, kunne bidrage med sine meget stærke kompetencer på værkstedet. Kontorassistenten vil kunne øge sin indsats på en række administrative opgaver. Endvidere opleves det i dag tit, at kunden ikke kan få ordentlig besked vedr. reservation, da værkføreren og kontorassistenten mangler overblik som følge af den manuelle planlægning. Det manglende overblik gør det også mere besværligt, at efterkomme kundernes ønsker om akutte reparationer. Den manuelle planlægning medfører i visse situationer, at mekanikerne ikke arbejder optimalt. Enten arbejder de på forkerte opgaver set i relation til deres færdigheder eller set i relation til at få bilerne klar til den lovede tid. Indtastning i økonomi-systemet af mekanikernes Job-registreringer forgår manuelt, og tager unødig tid for kontorassistenten. Afholdelse af ferie kolliderer nogle gange med ordremængden, hvilket måske kunne undgås, hvis autoværkstedet blev bedre til at forudsige fremtidige behov for ressourcer. Autoværkstedets vision Autoværkstedet ønsker et system, som kan reducere tidsforbruget til behandling af kundehenvendelser og planlægning. De har en ide om at kunne tilbyde kunderne en form for "Self service" således, at kunderne selv kan varetage nogle af de funktioner som værkføreren og

3 Side 3 af 49 kontorassistenten i dag varetager. Endvidere skal arbejdsplanerne udarbejdes/opdateres automatisk. Der ønskes en integration til autoværkstedets økonomi-system, således at mekanikernes tidsforbrug samt fravær (ferie, sygdom osv.) automatisk kan overføres fra det nye system. Systemet skal kunne opsamle forbrugte ressourcer således, at historiske data periodisk set kan anvendes i den fremtidige planlægning. Afgrænsninger Det skal bemærkes, at vi har nedtonet, og nogle steder helt undladt, beskrivelser vedr. tilgang til systemet via Internettet for at begrænse denne opgaves omfang. Derudover har vi udeladt alt omkring reservedele/reservedelslager. Inception-fasen I denne fase undersøges det om, der skal investeres i en mere dybdegående analyse af problemdomænet. Med andre ord: Skal vi efter denne fase starte på Elaboration-fasen? Endvidere er det vigtigt at få afklaret om projektets interessenter er enige om visionen for projektet. Inception-fasens varighed bør som hovedregel være kort, hvilket typisk vil sige 1-2 uger. Krav til systemet Man kan med fordel kategorisere kravene efter FURPS+ modellen, for bl.a. at minimere risikoen for at glemme krav til systemet. For at finde samt dokumentere de funktionelle krav (F'et i FURPS+) benyttes Use-Case modellen, hvor ideen er at fokusere på hvorledes brugeren/aktøren, ved at bruge systemet, kan få sine mål opfyldt. Fremgangsmåden er at vælge system-grænse, identificere primære aktører; identificere primære aktørers mål og slutteligt definere Use Cases, der opfylder aktørernes mål. Definition af system grænse Systemet består af selve applikationen samt hardwaren og kan tilgås vha. et lokalt brugerinterface eller via Internettet. Uden for system grænsen er aktører samt autoværkstedets økonomi-system. Primære aktører Vi har fundet frem til følgende primære aktører: Kontorassistent Værkfører Mekaniker Lærling Kunde IT drift (pt. kontorassistenten/ Værkfører med en anden kasket på ). Overvågningsproces Tiden Det er indlysende, at kontorassistenten og værkføreren er primære aktører til systemet. De resterende aktører er afdækket gennem samtaler med nogle af de ansatte i autoværkstedet. Under samtalerne har vi stillet dem en række spørgsmål eksemplificeret ved følgende liste:

4 Side 4 af 49 Hvem vedligeholder kundeoplysninger? Hvem vedligeholder oplysninger om de ansatte? Hvem skal kunne reservere tider i værkstedet? Hvem skal starte og stoppe systemet? Hvordan planlægges den enkelte ansattes arbejdstid? Hvad skal der ske hvis systemet fejler eller går ned? Skal der ske af handlinger på givne tidspunkter, eller med givne tidsintervaller? Primære aktørers mål Aktør Kontorassistent Værkfører Mekaniker Lærling Kunde IT drift Overvågningsproces Tiden Mål Reservere tid til service/reparation på værkstedet for kunder. Ændre reservation for kunder. Afbestille reservation for kunder. Minimere tidsforbrug til registrering af mekanikernes tidsforbrug samt fravær. Reservere tid til service/reparation på værkstedet for kunder. Ændre reservation for kunder. Afbestille reservation for kunder. Minimere tidsforbrug til registrering af mekanikernes fravær. Udarbejde arbejdsplaner for mekanikere. Se arbejdsplan. Registrere tidsforbrug. Registrere fravær. Se arbejdsplan. Registrere tidsforbrug. Registrere fravær. Reservere tid til service/reparation på værkstedet. Ændre reservation. Afbestille reservation. Oprette/vedligeholde egne kundeoplysninger. Blive orienteret om gode tilbud osv. Start systemet. Luk systemet ned. Genstarte system-processer, der er gået ned. Meddele IT drift vedr. system-fejl. Kopiere personale-oplysninger fra økonomisystem. Kopiere kunde-oplysninger fra økonomi-system. Udskrive liste over nye/ændrede kundeoplysninger. Udsende nyhedsbreve, tilbud osv. Indkalde til service.

5 Side 5 af 49 Definer Use Cases En Use Case ifbm. kravanalyse for en software applikation bør, som en tommelfingerregel, omhandle forretningsprocesser på et niveau defineret som følger: En handling (som respons på en forretningsbegivenhed) udført af én person på ét sted på én gang, der tilfører målbar værdi til virksomheden og efterlader data på et konsistent stade. Ved at gennemgå listen over de primære aktørers mål og med ovenstående definition in mente, har vi på nuværende tidspunkt identificeret følgende Use Cases: UC1: UC2: UC3: UC4: UC5: UC6: UC7: UC8: UC9: UC10: UC11: UC12: UC13: UC14: UC15: UC16: UC17: Reserver tid til service/reparation. Ændre reservation. Afbestille reservation. Vis job-kø. Vis arbejdsplan for en given periode. Registrer tidsforbrug (start- og sluttidspunkt). Registrer fravær (sygdom, ferie etc.). Kopier personale-oplysninger fra økonomi-system. Kopier kunde-oplysninger fra økonomi-system. Opret/vedligehold kunde-oplysninger samt biler ejet af kunde. Udskrive liste over nye/ændrede kunde-oplysninger. Overfør tidsforbrug samt fravær til økonomi-system. Udsende nyhedsbreve, tilbud osv. Indkalde til service. Start systemet. Genstarte system-processer, der er gået ned. Meddele IT drift vedr. system-fejl. Se bilag 1 for beskrivelser i "Brief Format" for disse Use Cases. Det er vigtigt at notere sig, at ovenstående liste, i nuværende fase, ikke er udtømmende. Endvidere vil de funktionelle krav, som vores Use Cases skal være med til at afdække, næsten med sikkerhed, blive udsat for ændringer. Ændringer undervejs i projektforløbet skal ikke opfattes som et problem, men nærmere som en drivkraft i den igangværende proces, der officielt benævnes Unified Process (UP). UP kombinerer "best practices", iterativ- og risikodreven udvikling. For at give et overblik over systemet bringes her et Use Case Context diagram:

6 Side 6 af 49 Figur 1 - Use Case Context diagram.

7 Side 7 af 49 Det skal bemærkes at der ikke er medtaget kommunikationslinier fra kunden til systemet pga. den tidligere omtalte nedtoning af beskrivelser vedr. tilgang til systemet via Internettet. Endvidere skal det nævnes at, aktørerne Kontorassistent, Værkfører, Mekaniker og Lærling, for overskuelighedens skyld, er samlet i en aktør kaldet Ansat. Supplerende specifikation Ved fortsat at benytte FURPS+ modellen, skal vi nu have fundet frem til de ikke-funktionelle krav. FURPS+ er en forkortelse og er forklaret herunder: Functional (funktionelle krav) Usability (menneskelige faktorer, hjælp, dokumentation så som bruger-, installations- og administrator-vejledninger) Reliability (fejltolerance, muligheder for recovery osv.) Performance (svartider, datamængder, oppe-tid, driftsressourcer osv.) Supportability (tilpasningsevne, vedligeholdelse, internationalisering, konfigurerbart) Plusset i FURPS+ står for de krav, der kan relateres til følgende faktorer: Implementering (ressource begrænsninger, sprog og værktøjer, hardware osv.) Interface (bindinger ifbm. brugerinterface samt interface til eksterne systemer) Drift Pakning Juridiske forhold (licenser etc.) Vores analyse afdækkede følgende ikke-funktionelle krav: A. Systemet skal være et hurtigt værktøj ifbm. søgning af ledig tid til reservation af service/reparation (P). B. Det skal være et flerbruger system. Der skal være samtidig adgang til systemet fra kontoret (kontorassistent), værkførerkontoret (værkfører/mekaniker), samt fra værkstedet (værkfører/mekaniker/lærling) (U). C. Ifbm. at en mekaniker anvender systemet til job-registrering i værkstedet, kan tastatur ikke anvendes pga. mekanikernes snavsede oliefingre! (+) D. Kommunikationen med systemet skal foregå på Dansk (S). E. Der forventes en oppe-tid på 99% indenfor normal arbejdstid. (R). F. Ved nedbrud skal alle accepterede reservationer kunne gendannes (R) G. Systemet skal have interface til værkstedets økonomisystem.(+) H. Funktioner, der skal anvendes af mekanikere, skal være meget intuitive og nemme at bruge. (U)

8 Side 8 af 49 Planlægning af næste iteration For at kunne planlægge en eventuelt kommende iteration er kravene "ranket" i nedenstående skema: Krav Type Arkitektur / teknik Risiko / kompleksitet Kritisk for Sum løsningen UC1 F UC2 F UC3 F UC4 F UC5 F UC6 F UC7 F UC8 F UC9,10,11 F UC12 F UC13 F UC14 F UC15 F UC16 F UC17 F A P B U C D S E R F R G H U De enkelte krav er vurderet efter skalaen: 1 = Lav, 2= Middel, 3 = Høj. Inden for kategorierne: Arkitektur / teknik = Hvor stor indflydelse har kravet på det tekniske design af systemet. Risiko / Kompleksitet = Hvor kompleks er kravet. Kritisk for løsningen = Hvor stor forretningsværdi har kravet. En af de risici vi kan se er, at værkstedspersonalet ikke gider at anvende systemet, hvis det ikke bliver meget nemt at anvende. Dette skal derfor have en meget stor bevågenhed under udviklingen. Rent teknisk er dette dog ikke så risikofyldt, da personerne i projektgruppen er stærke inden for dette felt. Af andre "risktyper" kan nævnes problemet med at få projektet besat med ressourcer med de rette kvalifikationer. Heller ikke på dette punkt er der ikke problemer i relation til dette projekt. Et fokus område bliver projektets behov for tidsforbrug hos projekt personer (ansatte i autoværkstedet), som stadig skal varetage deres daglige arbejdsopgaver. Med ovenstående betragtninger in mente og med baggrund i den foretagne "rankning" vælger vi i den eventuelt kommende iteration at arbejde med "Basic Flow" scenariet i UC1 (Reserver tid til service/reparation).

9 Side 9 af 49 Udviklingsplan På baggrund af ovenstående "rankning" samt en vurdering af den logiske rækkefølge, har vi udarbejdet en foreløbig udviklingsplan. Det er vigtigt at understrege, at planen kun er foreløbig og at den efter hver iteration, vha. nye "rankninger", revideres. Efter en iteration er man jo som regel blevet klogere og "rankningen" vil som konsekvens heraf med stor sandsynlighed ændre sig. Processen vi følger (UP) består af følgende faser: Inception: Elaboration: Overordnet vision, identifikation af Uses Cases ca. 10% beskrevet i detaljer. Arkitektur beslutninger, afdækning af high risk elementer (også kode mæssigt), de fleste Use Cases beskrevet i detaljer. Construction: Kodning af tilbageværende low risk elementer, samt øvrige elementer. Transition: Beta test, systemet går live. De sidste 3 faser indeholder typisk flere iterationer. Det er vigtigt, at forstå at hver iteration selvom det er i Elaboration fasen ender op med færdige program elementer (kode). For mindre projekter vil store dele af systemet blive kodet i Elaboration fasen. Første udkast til udviklingsplanen: Fase Iteration Indhold nr. Elaboration 1 UC1: Reserver tid (NormalReservation) Basic flow. Elaboration 2 UC1: Reserver tid (SpecialReservation) + GUI Søg reservations tidspunkter Basic flow UC7: Registrer fravær UC15: Start system Elaboration 3 UC1: Reserver tid (NormalReservation) Alternativ flow. UC2: Ændre reservation Construction 1 UC3: Afbestille reservation UC1: Reserver tid (SpecialReservation) Alternativ flow UC10: Opret/vedligehold/søg kunde-oplysninger samt biler ejet af kunde. Construction 2 UC4: Vis job-kø UC6: Registrer tidsforbrug. UC11: Udskriv liste over nye/ændrede kunde oplysninger. Non-functional: C, H Construction 3 UC5: Vis arbejdsplan for en given periode. Construction 4 UC8: Kopier personale-oplysninger fra økonomi-system. UC9: Kopier kunde-oplysninger fra økonomi-system. UC12: Overfør tidsforbrug samt fravær til økonomi-system. Non-functional: F, G Construction 5 UC13: Udsende nyhedsbreve, tilbud osv. UC14: Indkalde til service. Transition 1 Første pilotversion installeres. Transition 2

10 Side 10 af 49 Non-functional krav: Til krav A, B, D og E forventes der ikke selvstændige aktivteter. De forventes at blive indarbejdet i de øvrige aktiviteter, som en del af udviklingsaktiviteterne. Forfinet vision På baggrund af den forudgående analyse har vi opstillet nedenstående vision, der har fået "commitment" fra projektets interessenter: Autoværkstedet ønsker et system, som kan reducere tidsforbruget til behandling af kundehenvendelser og planlægning. Kunderne skal, på sigt, på alle tider af døgnet kunne henvende sig til autoværkstedet for at reservere tid til reparation eller service. De skal ligeledes have adgang til, successivt rette, de oplysninger som autoværkstedet har registreret om dem. Nye kunder skal kunne oprette sig selv i systemet. Men som udgangspunkt udvikles og installeres systemet i første omgang til in-house brug. Oplysningerne om kunderne ønskes på sigt anvendt til en mere aktiv kundepleje, nyhedsbreve, indkaldelse til service, rabatter, konkurrencer, kampagner, tilbud osv. Arbejdsplaner skal opdateres automatisk når mekanikere pludselig skal bruge tid på akutte reparationer. Mekanikerne skal hele tiden være informeret om hvilken opgave, de skal arbejde på og de skal kunne se hvilke opgaver, der venter. Dette kunne eventuelt implementeres vha. en job-kø, der ydermere har den fordel, at den enkelte mekaniker kan vælge opgaver, der passer til vedkommendes kompetencer. Autoværkstedet opnår altså en decentralisering af planlægningen, som medvirker til en optimal udnyttelse af personale samt produktionsapperat. Der ønskes en integration til autoværkstedets økonomi-system, således at mekanikernes tidsforbrug samt fravær (ferie, sygdom osv.) automatisk kan overføres fra det nye system. Mht. personale- og kundeoplysninger betragtes økonomi-systemet som master. Systemet skal kunne opsamle forbrugte ressourcer således, at historiske data kan anvendes i den fremtidige planlægning. Decentraliseringen af planlægningen påtænkes ligeledes at omfatte ferie. Mekanikerne skal selv kunne booke ferie og med det samme se om det harmonerer med behovet for ressourcer. Ordliste Term Definition og information Aliaser Aktør Noget der kan påvirke systemet, så som en person (identificeret vha. en rolle), et computer system eller en organisation. Primær aktør Får mål opfyldt ved at benytte systemet. Use Case Beskrivelse af systemets brug.

11 Side 11 af 49 Term Definition og information Aliaser Service Kontrol/eftersyn af bilen efter et bestemt antal kilomenter. eks , Mindre reparationer som olieskift etc. foretages ifm. servicen. Arbejdsbeskrivelser Beskrivelse af opgaver der kan udføres på en bestemt biltype. Eks km service. Speciel reservation Normal reservation Kunde Mekaniker, Svend Ansat Lærling Fravær Autoværksted Reservation af et tidspunkt til en opgave på bilen, som kræver udlært personale. Reservation af et tidspunkt til en opgave på bilen, som ikke kræver udlært personale. Typisk service eftersyn. Ejeren af en bil, som er blevet repareret/serviceret på værkstedet. Udlært værkstedspersonale. Mekaniker, lærling, værkfører og kontorassistent. Person som er under uddannelse til mekaniker. Tidsperiode hvor en ansat ikke er på arbejde pga. ferie, sygdom etc. Det fysiske sted, der ønsker det nye system installeret og hvor biler bliver serviceret / repareret. Go - No go? Det vurderes at projektet kan gennemføres samt at tilbagebetalingstiden vil blive ca. 1 år. Autoværkstedets ledelse vurderer endvidere, at systemet har stor strategisk betydning. Det besluttes at gå videre til elaboration-fasen. Elaboration-fasen I 1. iteration, som vi skal i gang med nu, bestemte vi vha. "rankning", at arbejde med "Basic Flow" scenariet i UC1 (Reserver tid til service/reparation). UC1 beskrives derfor nu i "Fully Dressed" format. Tallene i parentes refererer til efterfølgende skærmbillede layouts.

12 Side 12 af 49 UC 1: Reserver tid til service/reparation Primary Actor: Kontorassistent. (kan også være værkføren, men med samme beføjelser som kontorassistenten). Stakeholders and Interests: Kontorassistent: Ønsker at kunne give kunden et hurtigt svar, på hvornår kundens bil kan Kunde: bliver behandlet. Ønsker at få behandlet sin bil hurtigst muligt, eller alternativt på en bestemt dag. Autoværkstedets ledelse: Ønsker tilfredse kunder, samt korrekt styring af tidsressource forbruget. Preconditions: Kontorassistenten er logget på systemet. Success Guarantee (Postconditions): Reservationen er registeret i systemet. Trigger: En kunde henvender sig for at foretage en reservation til service/reparation. Basic Flow: 1. Kunden henvender sig til autoværkstedet med ønske, om at få foretaget service/reparation. 2. Kontorassistenten beder om kundens tlf.nr. 3. Kontorassistenten indtaster tlf.nr. 4. Systemet fremfinder og præsenterer de registrerede kunde- samt bil-data i skærmbilledet "Søg reservations tidspunkter" (se udkast til layout efter denne Use Case). 5. Bil vælges (kunden kan have flere biler). 6. Systemet præsenterer en liste over mulige arbejdsbeskrivelser for den valgte bil (biltype). 7. Kontorassistenten vælger arbejdsbeskrivelser p.b.a. af kundens ønske. 8. Kontorassistenten igangsætter søgning efter ledig tid for reservation uden at ændre default værdierne i felterne (se skærmbillede-layout efter denne Use Case) Ønsket dato (1) og Arbejdsvarighed (2). 9. Systemet afgør p.b.a valgte arbejdsbeskrivelser om reservationen kræver udlært personale (Speciel reservation), eller ej (Normal reservation). 10. Systemet søger efter åbningstider, i en periode fra den ønskede dato (1) og 14 dage frem. 11. Indenfor de fundne åbningstider søger systemet herefter efter værkstedspersonel, der ikke er fraværende og ikke er optaget af opgaver. 12. Systemet præsenterer en liste over ledige tidspunkter i skærmbilledet "Vis ledige tidspunkter" (se udkast til layout efter denne Use Case). 13. Kontorassistenten forelægger kunden de ledige tidspunkter. 14. Kunden accepterer et tidspunkt. 15. Kontorassistenten registrerer reservationen. 16. Systemet gemmer reservationen som en opgave.

13 Side 13 af 49 Alternative Flows: 4a. Kunden er ikke registeret. 1. Kontorassistenten opretter kunden i systemet. 2. Kontorassistenten opretter kundens bil(er) i systemet. 4b. Bilen som kunden ønsker serviceret er ikke oprettet under kunden. 1. Kontorassistenten opretter kundens bil i systemet. 1b. Bilen er registreret under en anden kunde (tidligere ejer). 2. Ejer forholdet på Bilen ændres. 8a. Kunden har et specifikt ønske til tidspunkt for service. 1. Kontorassistenten forespørger systemet om ledig tid, ved at indtaste ønskede dato. 8b. Den ønskede reparation er af en anden varighed end den angivet i arbejdsbeskrivelserne. 1. Kontorassistenten kontakter en mekaniker for, at få et groft estimat på den ønskede opgave. 2. Kontorassistenten ændrer Arbejdsvarighed (2) og igangsætter søgning. 8c. Den ønskede reparation er ikke registeret under de fremsøgte arbejdsbeskrivelser. 1. Kontorassistenten kontakter en mekaniker for, at få et groft estimat på den ønskede opgave. 2. Kontorassistenten indtaster arbejdsbeskrivelsen som fritekst. 3. Kontorassistenten ændrer Arbejdsvarighed (2) og igangsætter søgning. 13a. Ingen af de fremfundne tidspunkter passer kunden. 1. Kontorassistenten foretager ny søgning ved at indtaste en anden dato.

14 Side 14 af 49 Skærmbillede layout: "Søg reservations tidspunkter" TimeFinder V0.01 Tlf.nr Screen Navn: layout: Adresse: Jens Vejmand Juelsmindevej 12 A 2650 Hvidovre Reg.nr: VB23123 BilType: Alfa Romeo 156 Sidste Service: CJ76122 VW Golf Arbejdsbeskrivelser for valgt bil (reg.nr. CJ76122) af typen VW Golf 2.0: km service. Varighed er 4 timer. Der kræves ikke udlært personale km service. Varighed er 4 timer. Der kræves ikke udlært personale km service. Varighed er 4 timer. Der kræves ikke udlært personale km service. Varighed er 3 timer. Der kræves udlært personale. Stor reparation. Varighed er 8 timer. Der kræves udlært personale. Middel reparation. Varighed er 4 timer. Der kræves ikke udlært personale. Lille reparation. Varighed er 2 timer. Der kræves ikke udlært personale. (1) Ønsket Dato: (2) Arbejdsvarighed: 8 Søg Tidspunkt Feltet Ønsket dato (1) er default udfyldt med dagsdato + 1 dag. Feltet Arbejdsvarighed (2) er default udfyldt med forventet varighed i timer bestemt ud fra biltype samt ønskede arbejdsbeskrivelser. Begge default værdier kan overskrives. Værkføren kan eksempelvis give et mere præcis estimat på arbejdsvarighed for store reparationer.

15 Side 15 af 49 Skærmbillede layout: "Vis ledige tidspunkter" TimeFinder V0.01 Ledige Tidspunkter: 1 Åbningstid: Varighed er 8 timer. Ledig tid på værksted (ressourcer-fravær-opgaver): =4 Varighed af arbejde: 8 Kunden KAN IKKE vælge denne dag. 2 Åbningstid: Varighed er 8 timer. Ledig tid på værksted (ressourcer-fravær-opgaver): =8 Varighed af arbejde: 8 Kunden KAN vælge denne dag. Accepter Tidspunkt Ny Søgning Aktivitetsdiagram UC1 "Basic Flow": Aktivitetsdiagrammet er OOAD s flowcharts, som viser aktiviteternes hændelsesforløb. I dette tilfælde bruger vi aktivitetsdiagrammet til, at billedeliggøre vores Use Case.

16 Side 16 af 49 Figur 2 - Aktivitetsdiagram til UC1 "Basic Flow"

17 Side 17 af 49 Det ovenstående aktivitetsdiagram viser Reservation af tid til service/reparation. Den centrale del af aktiviteterne (dialogen med systemet) står kontorassistenten for. Da kunden enten henvender sig personligt eller telefonisk vil der samtidigt med aktivitets flowet forekomme kommunikation mellem kontorassistenten og kunden. Dette er ikke medtaget, da formålet er at vise det principielle i aktivitets flowet. Testovervejelser Efter udarbejdelsen af UC1 (Reserver tid til service/reparation) i "Fully Dressed" format er det på sin plads, at overveje hvorledes testen skal foretages. Testens formål er bl.a. at skabe tiltro til, at systemet gør det som det skal gøre. Derfor er det vigtigt, at man gør sig klart hvad resultatet af testen skal blive. Sagt med andre ord bør man ifm. udarbejdelsen af en Use Case, samtidigt udarbejde tilhørende testcase. Vi har ladet os inspirere testmetoden "test-first programming", der anvendes i Extreme Programming (XP). Og da hver iteration i UP i princippet indeholder en "mini V-model", har de gode gamle test-dyder fra V-modellen, der jo også indgyder til at teste fra starten, selvfølgelig også været en kilde til inspiration. Fremgangsmåden ved testmetoden "test-first programming" er først at skrive lidt testkode, dernæst lidt kode der skal testes. Når koden er succesfuldt testet gentages forløbet. I UC1 fremsøges en kunde vha. tlf.nr. som argument. Vi skal altså først lave testkode, som kan teste oprettelse af en kunde samt fremsøgning af denne. Herefter laves kode der rent faktisk kan oprette kunden samt fremsøge denne. Når koden er succesfuldt testet vil vi på tilsvarende vis fortsætte med at arbejde os igennem UC1, indtil vi føler os overbeviste om at koden tilfredsstiller den beskrevne funktionalitet. Ovenstående er gennemført vha. klassen SystemTester.java som kan ses i Bilag 2 hvor også outputtet af testen kan ses (Bilag 3).

18 Side 18 af 49 System Sekvens Diagram Før det egentlige designarbejde i iteration 1 påbegyndes, er det formålstjenstligt at få afklaret input og output system events relateret til "Basic Flow" scenariet i UC1. Det letter overgangen fra analysearbejdet til designarbejdet. Hertil anvendes et System Sekvens diagram som er en Craig Larman opfindelse: R e se rv e r tid til s e rv ic e /re p a ra tio n U C 1 B a s ic F lo w s c e n a rie g e tk u n d e (p T lfn r) K u n d e g e tb ile re je ta fk u n d e (K u n d e Id ) B il[] g e ta rb e jd s B e s k riv e ls e r(b ilt y p e Id ) A rb e jd s B e s k riv e lse [] lis tf re e T im e (o e n s k e td a to, v a rig h e d, U d la e rtp e rs o n a le K ra e v e t) L e d ig e T id e r[] a c c e p tt im e (b ilr e g N r,d a to,v a rig h e d,v a lg te A rb e jd s B e s k r) Figur 3 System sekvens diagram. Som det ses betragtes systemet som et hele; som en "black box". Og vi har nu, i højere grad, fået konkretiseret operationerne, der relaterer sig til Basic Flow scenariet i UC1. Senere i designforløbet vil vi lave "rigtige" sekvensdiagrammer, hvor det vil fremgå hvilke objekter i systemet, der får ansvaret for at udføre operationerne. Til afklaringen heraf benytter vi Craig Larman's GRASP Patterns.

19 Side 19 af 49 Domain Model Designarbejdet påbegyndes ved at udarbejde en Domain Model. Da vi jo arbejder i henhold til UP er det vigtigt ikke at kaste sig ud i og lave en komplet model på nuværende stadie. I efterfølgende iterationer udbygges modellen til også at afspejle disse. Af hensyn til eventuelt nye udviklere på projektet er det vigtigt at Domain Modellen vedligholdes. Den er nemlig et godt værktøj til hurtigt at bibringe et godt indblik i problem domænet. Domain modellen repræsenterer konceptuelle klasser (ting, begreber fra den virkelige verden) og ikke software klasser. Et eksempel på en software klasse kan f.eks. være en interface klasse til en database. For at finde de konceptuelle klasser i problem-domænet anvendes en "Conceptual Class Category List": Conceptual Class Category Physical or tangible objects Specifications, designs or descriptions of things. Places Transactions Transaction line items Roles of people Containers of other things Things in a container Other computer or electromechanical systems external to the system Abstract noun concepts Organizations Events Processes (often not represented as a concept but may be) Rules and policies Catalogs Records of finance, work, contracts, legal matters Finacial instruments and services Manuals, documents, reference papers, books Candidates Bil Biltype, Arbejdsbeskrivelse Autoværksted Reservation Job-registrering Kontorassistent, Værkfører, Mekaniker, Lærling, Kunde Åbningstider Datoer, Tidspunkter. Økonomi-system Service, Reparation, Opgave, Fravær, Åbningstid Kundehenvendelse Bilmanual Reparationsvejledninger Servicevejledninger Endvidere er UC1 gennemgået for navneord (Arbejdsvarighed, Arbejdsbeskrivelse, Autoværksted, Bil, Biltype, Dato, Kontorassistent, Kunde, Opgave, Periode, Reparation, Reservation, Service, Tid, Tidspunkt, Tlf.nr., Åbningstid).

20 Side 20 af 49 Arbejdsvarighed, Dato, Tid, Tidspunkt samt Tlf.nr. er ikke konceptuelle klasser, men nærmere attributter, da disse kan repræsenteres vha. simple datatyper som f.eks. int. Dog repræsenteres eksempelvis Dato og Tlf.nr. vha. lidt mere komplekse datatyper nemlig Date og String, men betragtes stadig som attributter. Endvidere kan man sige at Arbejdsvarighed består af et antal samt en enhed, men for nu forudsætter vi bare at der er tale om et antal timer. Flg. liste repræsenterer de konceptuelle klasser, der relaterer sig til nuværende iteration: Autoværksted Bil Åbningstid Opgave Ansat Biltype Reservation Kunde Arbejdsbeskrivelse Fravær Herefter skal vi, uden at anvende ret meget tid, identificere associationer mellem de konceptuelle klasser. Hertil anvendes en "Common Associations List": Category A is physical part of B* A is logical part of B* A is physically contained in/on B* A is logically contained in B* A is a description for B A is a line item of a transaction or report B A is known/logged/recorded/reported/captured in B* A is a member of B A is an organizational subunit of B A uses or manages B A communicates with B A is related to a transaction B A is a transaction related to another transaction B A is next to B A is owned by B A is an event related to B Candidates Åbningstid - Autoværksted Ansat - Autoværksted Opgave - Autoværksted Biltype - Bil Arbejdsbeskrivelse - Biltype Arbejdsbeskrivelse - Opgave Reservation - Autoværksted Ansat - Autoværksted Kunde - Autoværksted Kunde - Bil Bil - Kunde Fravær - Ansat Reservation - Opgave Opgave - Bil Kategorier markeret med * er af speciel vigtighed i Domain Model henseende.

21 Side 21 af 49 Slutteligt har vi identificeret attributter for de enkelte klasser i Domain modellen, der herefter, på nuværende tidspunkt, ser således ud: Figur 4 Domain Model. Som det ses indeholder klasserne Opgave, Åbningstid og Fravær en dato og en varighed. Vi kan forudse, at dette problem-domæne måske kommer til at indeholde flere klasser med netop disse attributter. Endvidere er varighed, som tidligere omtalt, ikke en simpel datatype. Disse ting til sammen gør det nærliggende at lave en ny klasse der hedder Tidsperiode og så lave associationer fra denne til Opgave, Åbningstid og Fravær. Man kunne også overveje om klasserne Opgave, Åbningstid og Fravær skulle nedarve fra Tidsperiode, hvilket ville være ok i relation til "100%- reglen", men ikke i relation til "is a - reglen". Kontrakter Kontrakter anvendes normalt ifbm. store, tunge Use Cases, hvor en yderligere beskrivelse af systemet kan være værdifuld for det videre designarbejde. De beskriver resultaterne (ændringerne i objekternes tilstand) af system operationer fra System Sekvens Diagrammet og kunne godt beskrives i selve Use Casen, men det medfører som regel en meget stor detaljeringsgrad og

22 Side 22 af 49 mindsker måske hermed værdien af selve Use Casen. Vi har valgt at lave kontrakter for operationerne listfreetime og accepttime, der kort er beskrevet i punkt 9, 10, 11 og 16 i UC1: Contract CO1: Operation: listfreetime listfreetime(date oensketdato, int varighed, boolean udlaertpersonalekraevet) Cross References: Use Case: UC1 - Reserver tid til service/reparation. Preconditions: Postconditions: Åbningstider og Ansatte er oprettet i systemet. Endvidere er eventuelt fravær samt eventuelle opgaver ligeledes oprettet i systemet. Kunden er fremsøgt. Kundens bil(er) er fremsøgt en af disse er valgt til service/reparation. Mulige arbejdsbeskrivelser for valgt biltype er fremsøgt og de ønskede arbejdsbeskrivelser er valgt. Ud fra valgte arbejdsbeskrivelser er arbejdsvarighed bestemt. Ligeledes ud fra disse er det afgjort om udlært personale er krævet. Felterne Ønsket dato (1) og Arbejdsvarighed (2) er udfyldt. Objekterne i Domain modellen er ikke ændret. Objekt-instanser oprettet under fremsøgning er nedlagt. Liste over ledige tidspunkter præsenteres. Contract CO2: Operation: accepttime accepttime(string bilregnr, Date dato, int varighed, Vector ValgteArbBeskr) Cross References: Use Case: UC1 - Reserver tid til service/reparation. Preconditions: Postconditions: En bil er valgt (i CO1), de ønskede arbejdsbeskrivelser er markerede (CO1) og Arbejdsvarighed er bestemt. listfreetime (se CO1) er gennemført. Kundens valg blandt de ledige tidspunkter er valgt. Eventuelle kommentarer er anført. En Opgave instans er oprettet og gjort persistent. Detaljeret design Efter alle de forudgående undersøgelser føler vi os nu godt rustet til det mere detaljerede designarbejde. Vi kaster os over udarbejdelse af klassediagram og sekvensdiagrammer. Grundet de tidligere omtalte betragtninger vedr. tidsperioder i klasserne Opgave, Åbningstid og Fravær har vi set i relation til Domain Modellen lavet en ny klasse der hedder Tidsperiode. Dette fremgår at klassediagrammet som ses herunder:

23 Side 23 af 49 Figur 5 Klasse diagram

24 Side 24 af 49 I Figur 5 ses klasse diagrammet i sin nuværende form Klasse diagrammet har været, og vil i kommende iterationer være i konstant udvikling. Som Controller klasse for system events har vi pt. valgt klassen AutoVaerksted. Det er på nuværende stade i projektet ok, da der endnu ikke er så mange system operationer. High Cohesion er bevaret. State Pattern er valgt til Reservation. State Pattern anvendes i de tilfælde hvor et objekts opførsel afhænger af dets tilstand, og dets tilstand kan ændre sig på runtime tidspunktet. State Pattern giver den fordel, at der senere kan tilføjes yderligere specilaliseringer af reservations typer, uden ændringer af ireservation (som er et interface) eller de øvrige klasser. I øjeblikket kan Reservation være i 2 states enten en NormalReservation hvor der ikke kræves udlært personale alternativt i state SpecialReservation hvor der kræves udlært personale. På sigt kunne man forstille sig en tredje state, som eksempelvis specielle færdigheder kræves for, at løse en bestemt opgave. Denne nye reservationstype skulle derved blot arve fra ireservation (altså tilføjes side om side med NormalReservation og SpecialReservation). På kørsels-tidspunktet afgøres v.h.a polymofi hvilken objekttype (State) der er tale om, og derved hvilken listfreetime funktion der skal kaldes. Med på diagrammet er også en spæd start på servicelaget, der tager sig af persistens ved at kommunikere typisk med en database eller eksempelvis XML-filer. Pt. er servicelaget repræsenteret af en enkelt klasse der er navngivet TestDB_Singleton. Klassen, der er en Facade Controller, er medtaget for at kunne teste systemet og persistens vha. af SystemTester klassen (beskrevet herunder). TestDB_Singleton er implemteret, som en Singleton. En singleton garanterer, at der kun findes en instans af klassen. Tidsperiode er i princippet pt. kun attributter, som er udskilt fra Opgave, Fravaerd og Aabningstid. Vi har undervejs haft et lidt andet design på banen, som bør genovervejes i en senere iteration I dette alternative design var Opgave, Fravaerd og Aabningstider en specialisering af tidsperiode (Opgave, Fravaerd og Aabningstider arver fra tidsperiode). Const klassen indeholder en række konstanter, der kan benyttes i hele systemet denne klasse er også en Singleton. SystemTester-klassen er tidligere beskrevet i afsnittet Testovervejelser. For klassen Ansatte og deres beskæftigelse er modelleret vha. det GoF Pattern, der hedder Bridge. Brige anvendes i de tilfælde, hvor der ikke ønskes permanent binding mellem en abstraction (Ansat) og dets implemtering (Roller: Laerling, Mekaniker). Det giver den fordel, at implementeringen af en abstaction kan skiftes på runtime tidspunktet. Altså at en Laerling eksempelvis kan blive udlært, og skifte rolle til Mekaniker. Yderligere roller forventes tilføjet under implemteringen af SpecielReservation, samt hvis specielle færdigheder pr. ansat implementeres.

25 Side 25 af 49 Sekvensdiagrammer * [ i : = 1.. a n t W o r k i n g D a y s ] Figur 6 Sekvens diagram UC1 Basic Flow

26 Side 26 af 49 * [ i : = 1.. a n t W o r k i n g D a y s ] Figur 7 Sekvens diagram (Første udkast UC1 alternativt flow 4a)

27 Side 27 af 49 I figur 6 og 7 vises sekvensdiagram for Use Case Reserver tid til service/reparation (UC1). Sekvensdiagrammet i figur 7 er første udkast til alternativ flow(4a) i Use Casen. Sekvensdiagrammet figur 6 - Use Case Reserver tid til service/reparation (UC1) basic flow. Når kontorassistenten påbegynder en reservation af service/reparation, sendes ifm. fremsøgningen af kunden, en meddelelse getkunde til klassen AutoVaerksted. AutoVaerksted agerer set med GRASP briller i dette tilfælde Information Expert. Søgefunktioner som eksempelvis getansatte, getworkingdays, og getopgavevarighed er generelt set placeret i Autovaerksted, hvilket giver high cohesion AutoVaerksted får i sin nuværende version også rollen, som Controller (svarer til GoF Facade Pattern) mod databasen. Når kunden er fremfundet, sendes en meddelelse getbilerejetafkunde til kunde, som er Information Expert, overfor hvilke biler den enkelte kunde ejer. Arbejdsbeskrivelser hentes med en meddelelse getarbejdsbeskrivelser til Biltype ( Information Expert ). Fremsøgningen af ledige tidspunkter sendes, som meddelelse til Reservation, som spørger Information Expert en AutoVarksted. Reservation bruger i sit underliggende design Polymorphism ifm. afgørelsen af hvilke søge funktioner, der skal kaldes. Når et tidspunkt er accepteret sendes en meddelelse til Reservation, som har ansvar for opgaven bliver gemt på databasen. I de viste sekvensdiagrammer og i denne iteration, har vi ikke taget stilling til hvem, der skal være Creator af de enkelte klasser. I en senere iteration hvor GUI-delen udvikles skal dette ske. Den nuværende model tyder på, at der skal tilføjes en Controller (Facade) klasse mellem GUI-laget og forretningslaget Denne nye controller skal derved dele ansvaret med Autovaerksted for at få opgaven løst. Af hensyn til High Cohesion bør eksempelvis opretkunde og opretbil i en senere iteration flyttes fra AutoVaerksted, så denne kun indeholder søgefunktion. Systemarkitektur Planlægningssystemet udvikles i Java med udgangspunkt i 3-lags arkitekturmodellen: 1. lag: GUI laget Indeholder skærmbilleder til at varetage dialogen med brugeren. Kommunikerer med forretningslaget via en Controller (GoF Facade Pattern). 2. lag: Forretningslaget Den forretningsspecifikke funktionalitet. Kommunikerer med datalaget via en Controller (GoF Facade Pattern). 3. lag: Servicelaget Søger for persistens. Vil typisk være kommunikation med en database eller f.eks. XML-filer. GUI laget implementeres som en klient del. D.v.s en Java Applet, som køres via en Internet Browser. Af hensyn til værkstedets størrelse, og den ønskede IT investering - baseres systemet i første omgang på en enkelt server (PC). Der etableres klient adgang fra kontorassistentens og værkførerens eksisterende PC ere. Til visning af job-køen samt til registrering af bl.a. start- og sluttidspunkter opsættes en "terminal" (+krav vedr. oliefingre) i værkstedet. Dette er illustreret ved nedenstående Deployment Diagram:

28 Side 28 af 49 Figur 8 Deployment diagram. Det videre forløb I dette skoleprojekt stopper vi nu. I den virkelige verden ville vi nu, som tidligere nævnt, revidere udviklingsplanen og herefter starte på 2. iteration. Når alle iterationer er gennemført skulle vi så gerne stå med et færdigt system, der som et resultat af de mange feedbacks fra kunden, til fulde lever op til kundens forventninger.

29 Side 29 af 49 Bilag Bilag 1: Beskrivelser af Use Cases i "Brief Format" UC1: Reserver tid til service/reparation. En kunde henvender sig til autoværkstedet for at reservere tid til service/reparation af sin bil. Kundens oplysninger søges frem i systemet og disse verificeres. Ud fra den valgte bils biltype listes en række arbejdsbeskrivelser, der beskriver forskellige servicetyper samt reparationer. Arbejdsbeskrivelser vælges efter kundens ønsker, og med ønsket dato samt varighed som parametre fremsøges ledige tider til en reservation på værkstedet. Disse tider præsenteres for kunden, og det af kunden accepterede tidspunkt reserveres i systemet. UC2: Ændre reservation. En kunde henvender sig til autoværkstedet for at ændre tidspunktet for en reservation. Kundens oplysninger søges frem i systemet og disse verificeres. Herefter fremsøges reservation samt nye ledige tider på værkstedet. Disse nye tider præsenteres for kunden og det af kunden accepterede tidspunkt reserveres i systemet. UC3: Afbestille reservation. En kunde henvender sig til autoværkstedet for afbestille en reservation. Kundens oplysninger søges frem i systemet og disse verificeres. Herefter fremsøges reservation og denne annulleres. UC4: Vis job-kø. Når en mekaniker er klar til nye opgaver, går han hen til systemet og får vist den aktuelle job-kø, der generes dynamisk ud fra de foretagne reservationer. Mekanikeren vælger en opgave, der passer til vedkommendes kompetencer og i øvrigt passer ind i den decentrale planlægning på værkstedet. Specielle opgaver skal muligvis på sigt pointes til en bestemt ansat, som besidder specielle kvalifikationer. Bemærkning efter 1 iteration: Publish-Subscribe Pattern bør overvejes. UC5: Vis arbejdsplan for en given periode. Når værkføreren ønsker at skabe sig et overblik over behovet for ressourcer på værkstedet aktiveres UC5. Start- og slut-tidspunkt angives og herefter vises på grafisk form et overblik over ressourcer til rådighed, ressourcebehov til registrerede reservationer og endeligt forbrugte ressourcer i tilsvarende periode sidste år. Specielle opgaver skal muligvis på sigt pointes til en bestemt ansat, som besidder specielle kvalifikationer. Arbejdsplanerne danner også grundlag for planlægningen, af de enkelte mekanikers/lærlings arbejdstider i den kommende periode. UC6: Registrer tidsforbrug (start- og sluttidspunkt). Når en mekaniker er klar til nye opgaver, går han hen til systemet og får vist den aktuelle job-kø, der generes dynamisk ud fra de foretagne reservationer. Mekanikeren vælger en opgave, der passer til vedkommendes kompetencer og i øvrigt passer ind i den decentrale planlægning på værkstedet eller som er tildelt den enkelte ansatte p.g.a specielle kvalifikationer. Det sker ved at knytte mekanikerens initialer til opgaven. Samtidig med dette registres det egentlige starttidspunkt for opgaven til brug for job-registrering/fakturering. Når mekanikeren ikke længere arbejder på opgaven registreres sluttidspunkt og er opgaven helt udført markeres dette i et særskilt felt.

30 Side 30 af 49 UC7: Registrer fravær (sygdom, ferie etc.). Ved registrering af fravær indtastes årsag (sygdom, ferie etc.), starttidspunkt og sluttidspunkt. Herefter vises arbejdsplanen for den givne periode (UC5), således at man med det samme kan se indvirkningen på behovet for ressourcer. En mekaniker kan således med det samme se om f.eks. ønsket ferie kan lade sig gøre. Er det tilfældet gemmes registreringen af ferien. Er der tale om at en mekaniker sygemelder sig, kan værkføreren se om der skal indkaldes ekstra ressourcer eller om opgaver skal flyttes. UC8: Kopier personale-oplysninger fra økonomi-system. Personale-oplysningerne vedligeholdes kun i autoværkstedets økonomi-system. Disse kopieres en gang om måneden til det nye system. Kontorassistenten kan dog manuelt aktivere proceduren. UC9: Kopier kunde-oplysninger fra økonomi-system. Kontorassistenten vedligeholder kunde-oplysningerne (navn, adresse, tlf., biltype, årgang, forventet antal kilometer pr. år etc.) i autoværkstedets økonomi-system. Når nye kunder henvender sig oprettes de og når eksisterende kunder meddeler ændringer registreres disse. Kundeoplysningerne kopieres en gang i døgnet til det nye system. Kontorassistenten kan dog manuelt aktivere proceduren. Før kopiering af oplysningerne for en eksisterende kunde, kontrolleres det om kunden selv har rettet oplysningerne i det nye system. Er det tilfældet foretages kopiering ikke og UC11 aktiveres. UC10: Opret/vedligehold kunde-oplysninger samt biler ejet af kunde. I de tilfælde hvor kunden ikke er registeret i værkstedsystemet, eller oplysningerne i systemet er forkerte er der behov for, at kunne oprette/vedligeholde systemet med korrekte oplysninger. Dette gør sig også gældende for oplysninger om de biler ejet af kunden. Det skal være muligt, at flytte ejerskabet af en bil fra en kunde til en anden. UC11: Udskrive liste over nye/ændrede kunde-oplysninger. Når proceduren i UC9 køres udskrives eventuelt nye kunde-oplysninger, som kontorassistenten har oprettet/rettet i værkstedssystemet. Kontorassistenten benytter herefter udskriften til at opdatere autoværkstedets økonomi-system. På sigt overvejes en mere automatisk ajourførings funktionalitet. UC12: Overfør tidsforbrug samt fravær til økonomi-system. En gang i døgnet kopieres oplysninger om værkstedspersonalets tidsforbrug på diverse opgaver til autoværkstedets økonomi-system. Ligeledes kopieres oplysninger om fravær (fri, ferie etc.) til økonomi-systemet. UC13: Udsende nyhedsbreve, tilbud osv. På baggrund af kunde-oplysningerne kan værkføreren/kontorassistenten udsende nyhedsbreve, tilbud osv. Når materialet, der skal udsendes er klart, angives forsendelsesmåde (brev eller ) hvorefter kunder, der skal sendes til, fremsøges. Søgeargumenter kan f.eks. være en given biltype, da værkføreren måske har fået fat i nogle ekstraordinært billige reservedele til netop denne biltype. Når søgeresultatet er tilfredsstillende trykkes "Send" hvorefter kundedata flettes sammen med materialet. Er forsendelsesmåde afsendes med det samme. Er forsendelses måden brev printes materiale. UC14: Indkalde til service. Hvis kunden giver tilsagn herom kan systemet på baggrund af den registrerede biltype, årgang samt forventet antal kilometer pr. år, via , indkalde kundens bil til service.

31 Side 31 af 49 UC15: Start systemet. Systemet skal ideelt set kun startes en gang, da systemet, i hvert fald på sigt, påtænkes at skulle være til rådighed 24 timer i døgnet. Dog vil der blive tale om at skulle genstarte systemet i tilfælde af en uoprettelig fejl (UC16 fejler). Server startes, database samt database-listener startes og endeligt startes selve applikationen. UC16: Genstarte system-processer, der er gået ned. På systemet kører en række skygge-processer, der har det formål at starte de primære processer, såfremt de går ned. Skygge-processerne spørger med 3 minutters interval på om de primære processer kører. Er det tilfældet foretages intet. Er det ikke tilfældet forsøges de genstartet. Kan det ikke lade sig gøre aktiveres UC17. UC17: Meddele IT drift vedr. system-fejl. Hvis UC16 fejler logges fejlen i loggen, på sigt (når direkte online service til kunde aktiveres) skal der sendes en meddelelse til personen med ansvar for IT-driften. Bilag 2: SystemTester.java: import java.util.date; import java.util.enumeration; import java.util.vector; import java.text.dateformat; /* Generated by Together */ public class SystemTester public static void main(string[] argv) System.out.println("Instantier testdatabasen."); TestDB_Singleton db = TestDB_Singleton.getInstance(); System.out.println("/* ******** Opret testdata og gem dem i testdatabasen ******** */"); System.out.println("Opret selve AutoVærkstedet"); AutoVaerksted autovaerksted = new AutoVaerksted(); System.out.println("Opret ansatte i testdatabasen."); Rolle laerling = new Laerling(); Rolle mekaniker = new Mekaniker(); Ansat ansat1 = new Ansat("KD", "Kim", "Damgaard von papand", mekaniker, autovaerksted); db.addobject(ansat1); Ansat ansat2 = new Ansat("HS", "Henning", "Svensson Højben", laerling, autovaerksted); db.addobject(ansat2); System.out.println("Opret lidt fravær i testdatabasen. Fravaer(Tidsperiode newtid, String newaarsag, Ansat newansat)"); Fravaer fravaer1 = new Fravaer(new Tidsperiode(new Date(103,0,15,12,00), 4), Const.AARSAG_FRI, ansat1); db.addobject(fravaer1); Fravaer fravaer2 = new Fravaer(new Tidsperiode(new Date(103,0,16,8,00), 8), Const.AARSAG_SYG, ansat2); db.addobject(fravaer2); System.out.println("Opret åbningstider."); db.addobject(new Aabningstid(new Tidsperiode(new Date(103,0,15,8,00), 8), autovaerksted)); db.addobject(new Aabningstid(new Tidsperiode(new Date(103,0,16,8,00), 8), autovaerksted)); System.out.println("Opret kunder i testdatabasen."); Kunde kunde1 = new Kunde(1," ","Jens","Vejmand","Juelsmindevej", "12 A","2650","Hvidovre",autoVaerksted); db.addobject(kunde1); Kunde kunde2 = new Kunde(2," ","Jens Peter","Hansen","Dryadevej", "41","2650","Hvidovre",autoVaerksted); db.addobject(kunde2);