Løsningsforslag til Camp Let Case Beskrivelse: Camp Let Firmaet Camp Let har til formål at udleje forskellige typer transportable ferieboliger. Det drejer sig i øjeblikket om campingbusser, campingvogne, camplet'er og villatelte. En feriebolig udlejes altid sammen med et standardudstyr, som er inkluderet i lejeprisen for ferieboligen. Udover standardudstyret kan der lejes ekstra udstyr til ferieboligerne (f.eks. fortelt til campingvogne). Ekstraudstyr lejes kun ud i forbindelse med udlejning af en feriebolig. Ved udlejning skal lejeren være i besiddelse af et førerbevis. Dette er dog ikke nødvendigt ved leje af villatelte. For leje af campingbusser og campingvogne skal erlægges et større depositum. Endelig skal lejerens bil godkendes til kørsel med den ønskede størrelse campingvogn. Kunderne har mulighed for at reservere en feriebolig i en eller flere uger. Ved reservation af en feriebolig sendes en bekræftelse til kunden, sammen med et girokort, hvor udlejningsprisen står på. Girokortet skal betales senest 1 måned før udlejningen starter. Ved reservation på et tidspunkt, hvor der en mindre end en måned til udlejningens startdato, gives 1 uges betalingsfrist, hvis det er muligt, og ellers betales ved afhentningen af boligen. Ved manglende indbetaling slettes reservationen 1 uge efter sidste rettidige indbetalingsdato. Når indbetaling på en reservation er modtaget, betragtes reservationen som en lejeaftale, og der sendes en kopi af lejeaftalen til kunden. Denne kopi skal kunden medbringe ved afhentning af ferieboligen. Når kunden afleverer feriebolig og eventuelt ekstraudstyr tilbage, kontrolleres for eventuelle mangler eller defekter, ligesom det undersøges om afleveringsfristen er overholdt. Der udskrives en kvittering til kunden for det tilbage leverede materiel. Ved mangler, defekter eller for sen tilbagelevering udskrives desuden et girokort på et beløb, som skønnes at være rimeligt. Hver dag udarbejdes en pakkeliste for den kommende dag. Pakkelisten består af kopier af lejeaftaler, for hvilke det gælder, at lejeperioden starter den næste dag. Pakkelisten bruges til at gøre feriebolig og eventuelt ekstraudstyr klar til udlevering. 1
Løsningsforslag Forudsætninger og antagelser Forudsætninger og antagelser nedskrives løbende gennem udarbejdelse af løsningsforslaget En kunde reserverer kun en transportabel feriebolig ad gangen Formålet med systemet Formålet med projektet er at udarbejde et system der kan anvendes til administration af udlejning af transportable ferieboliger. Mulige kunder udover firmaet Camp Let er virksomheder der udlejer noget. Systemet skal sikre at firmaet Camp Let har overblik over hvor de enkelte ferieboliger er, hvornår de er ledige, hvilken tilstand de er i. Desuden være en støtte til opkrævning og registrering af indbetalinger fra kunderne samt udskrivelse af lejeaftaler. Systemet skal også sikre at der altid er korrekte pakkelister klar til brug. Krav 1. Kravspecifikation En liste over funktionelle og ikke funktionelle krav på formen: <id><systemet> skal <funktion>. Prioritering efter MoSCoW. Er ikke beskrevet nærmere her! 2. Use case modellen Beskrivelse af aktører På baggrund af case beskrivelsen og den udarbejde kravspecifikation er der fundet følgende aktører til systemet: Kunder: Bookingpersonale: Skal kunne leje, reservere feriebolig Har al kontakt med kunderne, leje, reservation, ændringer, afbestillinger Pakkepersonale: Pakker de forskellige ting til kunden, søger også for at modtage ferieboligen igen efter endt udlejning. Gennemgår boligen med kunden for at sikre der ikke er opstået skader, og at alt bliver afleveret. 2
Indkøber: Det er indkøberen der sørger for at indkøbe nye ferieboliger og ekstraudstyr efterhånden som det gamle skal udskiftes. Registrer reservation Bookingpersonale Registrerbetaling Pakkepersonale Udskriv pakkeliste Modtag tilbagelevering Indkøber Anskaf feriebolig Figur 1: Use case diagram Ovenstående oversigt diagram viser en oversigt over hvilke use case der er fundet i systemet og hvilke aktører der kan anvende use casene. Kort beskrivelse (brief description) af de fundne use case Use case: Reservation Aktører: Bookingpersonale Type: Primær Beskrivelse: Kunden kontrakter bookingpersonale for at leje en transportabel feriebolig. Er den ønskede boligtype er tilrådighed på det ønskede tidspunkt, registreres reservationen med evt. oplysninger om ekstraudstyr. Bekræftelse og girokort udskrives og sendes til kunden. Ønsker kunden at ændre en reservation findes reservationen frem og de ønskede ændringer tilføjes. Ønsker kunden at annullerer reservationen, registreres dette og afhængig af tidspunkt for annulleringen udregnes om der skal tilbagebetales evt. indbetalt depositum. Use case: Registrering af betaling Aktører: Bookingpersonale Type: Primær Beskrivelse: Det indbetalte beløb registreres i systemet, er hele depositummet indbetalt, er reservationen klar til at blive til en udlejning. Use case: Aktør: Type: Udskriv pakkeliste Pakkepersonale Primær 3
Beskrivelse: Pakkepersonalet beder om en udskrift at pakkelisten til klargøring af boligerne. Pakkelisten indeholder oplysninger om hvilke ferieboliger der skal klargøres til levering, samt hvilket ekstraudstyr der skal leveres. Use case: Modtag tilbagelevering Aktør: Pakkepersonale Type: Primær Beskrivelse: Pakkerpersonalet gennemgår ferieboligen med kunder for at registrerer evt. mangler og skader. På baggrund af skader udregnes evt. beløb kunden skal betale eller have tilbage. Use case: Anskaf ny feriebolig Aktør: Indkøber Type: Primær Beskrivelse: Indkøberen undersøger en gang i kvartalet om der er behov for ny indkøb til erstatning af noget beskadiget eller noget der er blevet forældet. Ny anskaffelserne registres i systemet. Beskrivelse af use casen Reservation Use casen registrer reservation vurderes til at være den vigtigste og mest komplekse. Derfor startes med denne, som designes og kodes i de første iterationer af elaboration fasen. For at kunne designe use casen er det nødvendigt at beskrive dens main flow mere detaljeret. Use case ID Aktører Pre-betingelse Post-betingelse Main flow Registrer reservation UC1 Bookingpersonale Ferieboliger er registreret Reservationen er oprettet og girokort sendt til kunden 1. Denne use case starter når en kunde ønsker at reservere en transportabel feriebolig 2. Bookingpersonalet indtaster oplysninger om boligtype og periode 3. Systemet undersøger om reservation er mulig 4. Hvis kunden ønsker at leje ekstraudstyr 4.1. Oplysninger om ønsket ekstraudstyr angives 5. Systemet beder om kundeoplysninger 6. Hvis kunden findes: 6.1. Kundenr. angives 6.2. Systemet returnerer kundeoplysninger 7. Ellers 7.1. Kundeoplysninger angives 7.2. Systemet registrer kunden 8. Reservationen oprettes 9. Systemet udregner depositum og restbeløb Girokort udskrives. 10. Beløb oplyses til kunden og girokort sendes til kunden 4
Figur 2: Main flow for use casen: Registrer reservation 3 Domænemodel Ud fra beskrivelser af use cases er der fundet følgende klasser Kunde: Der er behov for at registrere oplysninger om de kunder der lejer en feriebolig Transportableferieboliger: Der er behov for at registrere oplysninger om de ferieboliger som Camp Let har til udlejning. Reservation: Ekstraudstyr: Standardudstyr: Da man skal have styr på hvornår de enkelte ferieboliger er udlejet og til hvem, og om der er betalt er der behov for gemme oplysninger om reservation. Camp Let skal have styr på hvilket ekstraudstyr der kan udlejes, samt hvilken pris der er på ekstraudstyret. Det udstyr der følger med som standard ved udlejning, f.eks. hvor meget køkkengrej der er følger med en campingvogn. 5
Figur 3: Første udkast af domænemodel Den begrebsmæssige model er første udgave af modellen, det betyder at f.eks. ikke alle attributter er med endnu. Af modellen fremgår at en kunden kan have en eller flere lejekontrakter, men en lejekontrakt er altid kun knyttet til en kunde. En transportabel feriebolig kan reserveres flere gange, mens en reservation kun er knyttet til en transportabel feriebolig (se forudsætning). Ekstraudstyr er knytte til en eller flere lejekontrakter, lige som der kan reserveres flere ekstraudstyr til en lejekontrakt. Ovenstående begrebsmæssige model har den fordel at det er en simpel og overskuelig model, samtidig med at den indeholder de nødvendige informationer. Der er imidlertid nogle problemer. Ekstraudstyr og transportable ferieboliger har en del fælles attributter og måske vil det vise sig senere fælles metoder. Det vil forbedre modellen, hvis den afspejler dette forhold. Endvidere kunne det være hensigtsmæssig, hvis man kan reservere en ferieboligtype, så man ikke på reservationstidspunktet behøver at tage stilling til, hvilken konkret fysisk feriebolig, der skal reserveres. Hermed undgår man også at binde reservationen op på en bestemt fysisk feriebolig. Til gengæld skal der være en funktion i edb-systemet, som sikre at de reserverede ferieboliger er ledige og klargjorte på afhentningstidspunktet. 3.1.1 Overvejelser over generalisering og specialisering Der er flere muligheder for generaliserings/specialisering i modellen. For det første er der ovennævnte ligheder mellem ekstraudstyr og ferieboliger, der giver anledning til følgende mulige generalisering: 6
Udlejningsudstyr Transportabelferiebolig Ekstraudst. Figur 4: Mulig generalisering Endvidere er der mulighed for at specialiserer en transportabel feriebolig i hver af de nævnte typer: camplet, villatelt, campingbus og campingvogn Udlejningsudstyr2 Transportfbl Ekstraudstyr2 Camplet Villatelt Campingbus Campingvogn Figur 5: Mulig generalisering Ifølge teksten er der imidlertid meget lidt forskel på de forskellige feriebolig former. Kort opsummeret: for alle andre ferieboligtyper end villatelt skal lejeren vise førerbevis. For leje af campingbusser og campingvogne skal erlægges et depositum og endelig skal kundens bil godkendes til kørsel med en given campingvogn. 7
Der gælder med andre ord ikke noget specielt for villatelte. Da forskellen på de forskellige kørerende ferieboliger ikke er særlig stor kunne man vælge en specialisering af en transportabel feriebolig som vist nedenfor: Udlejningsudstyr2 Transportfbl Ekstraudstyr2 Kørendeferiebolig Figur 6: Mulig generalisering Udlejningsudstyr er en abstrakt klasse der er ingen objekter af klassen. Transportabel feriebolig derimod er en konkret klasse. Da der ikke gælder noget specielt for villatelte vil villatelteobjekterne være objekter af denne klasse. Skulle systemet laves som et standardsystem, hvor fleksibilitet og udvidelsesmuligheder var afgørende. Kunne man vælge en løsning med de mange subklasser eller et alternativ, hvor man skelner mellem generelle klasser af ferieboliger: transportable/ikke transportable, telte, ferieboliger til anhængertræk, selvkørende osv. Osv. Hensigten skulle være at få et vedligeholdelsesvenligt specialiseringshierarki, dvs. et hierarki som er nemt at udvide uden at lave om på grundstruktureren. En nærmere analyse og diskussion med brugeren måtte selvfølgelig afklare, hvad der måtte være relevant. 3.1.2 Andre strukturovervejelser Det har vist sig hensigtsmæssigt, at man ikke reserverer en konkret feriebolig, men derimod en type, f.eks. en camplet med 4 sovepladser. Knytningen af reservation til en konkret feriebolig sker først, når ferieboligen og ekstraudstyr pakkes kort tid før kunden afhenter den. Det forudsættes ovenfor, at der er behov for at objekterne af en feriebolig, er de konkrete fysiske campletter, campingvogne mv. De kørende ferieboliger vil kunne identificerer på deres indregistreringsnr, mens villatelt skal have en mærkat med en identifikation på. Objekterne af klassen ekstraudstyr er derimod typen (reservehjul, lænestol, barnestol osv) og man reserverer og lejer en af typen. Hver objekt skal have en antals-attribut, der angiver hvor mange der samlet er af typen. 8
Ud fra ovenstående overvejelser vælges følgende revideret begrebsmæssigemodel. Figur 7: Revideret domænemodel Skærmbilleder På nuværende tidspunkt er det relevant at udarbejde et skærmbillede der illustrer hvordan man forestiller sig systemet kommer til at se ud. Skærmbilleder er ikke medtaget her i løsningsforslaget. Analyse og design I analyse og design skal vi dels kigge på hvordan domænemodellen kan udvides til et analyseklassediagram med managerklasser samt hvordan use cases kan realiseres i interaktionediagrammer (UML sekvens- eller kollaborationsdiagram), som beskriver interaktionen mellem de forskellige klasser. Ved at udarbejde interaktionsdiagrammerne kommer det frem hvilke metoder der er behov for på de enkelte klasser. Desuden giver det grundlaget for hvilke klasser der skal kunne se hvilke klasser og hvilke metoder det giver på analysemodellens klasser. I design arbejdes videre på analysemodellen hvor der tages hensyn til valget af teknologi dvs. hvilken teknologisk platform (maskiner, programmeringssprog, databasesystem m.m.) der skal anvendes. 1. Interaktionsdiagrammer 9
Interaktionsdiagrammet over use casen: Registrer reservation er her delt op 4 diagrammer af hensyn til kommentarerne til diagrammet. : AftaleManager : Udstyrsmanager : Udlejningsudstyr : Lejeaftale : BookingPersonale 1: mulig=findbolig(type, startdato, slutdato):boolean 2: antal=findtype(type ):integer 3: gettype() 4: [hvis ok] getantal():integer For hver aftale 5: gettype() 6: [hvis ok] getstartdato() 7: [hvis ok]getslutdato() 8: mulig=ertypeledig(startdato, slutdato, type, antal):boolean Figur 8:Sekvensdiagram for FindBolig incl. trivielle metoder : AftaleManager : UdstyrsManager : BookingPersonale 1: mulig=findbolig(type, startdato, slutdato):boolean 2: antal=findtype(type ):integer 3: mulig=ertypeledig(startdato, slutdato, type, antal):boolean intern private metode Figur 9: Sekvensdiagram for FindBolig uden trivielle metoder 10
Ovenstående sekvensdiagram beskriver FindBolig. Der er valgt at bruge en AftaleManager klasse, der samarbejder med UdstyrsManager klassen som håndterer alt CRUD funktionalitet omkring ferieboligen. Først søges først i mængden af ferieboligtyper ved at hente antal af den ønskede type. Derefter undersøges hvor mange reservationer der er på den ønskede type i den ønskede periode. Er antal reservationer mindre en antal ferieboliger er reservation mulig. Alternativt til ovennævnte er at UdstyrsManager klassen får noget mere ansvar og også står for at finde ud af om det er muligt at udleje indenfor typen! : AftaleManager : BookingPersonale 1: opretkunde(navn...):kunde : KundeManager 2: opretkunde(navn..) k : Kunde 3: create(navn...) 4: addkunde(k) Figur 10: Sekvensdiagram for opretkunde inkl. trivielle metoder Derefter skal kunden registreres. Det er her valgt stadig at lade AftaleManager stå for at lede og fordele arbejdet. Alternativt kunne KundeManager klassen stå for det direkte! Reservation af ekstraudstyr foregår på samme måde som for ferieboligen. For hver type af ekstraudstyr, undersøges først antallet af den ønskede type og derefter undersøges hvor mange reservationer der er i den givne periode, på det givne udstyr for at se om der er noget ledigt. Så er alle oplysninger tilvejebragt for at en reservation kan oprettes. 11
: AftaleManager : Udlejningsudstyr : BookingPersonale 1: opretreservation(startdato, slutdato, typer, kunde) l : Lejeaftale 2: create(startdato,slutdato, typer, kunde) 3: addaftale(l) 4: beregnpris() 5: [for hver type]getpris() Figur 11: Sekvensdiagram for opretreservation inkl. trivielle metoder Lejekontrakten oprettes af AftaleManager klassen der laver et objekt af typen Lejeaftale med attributter samt objektreferencer til hhv. kunde og udstyrstyper. Objektet tilføjes til AftaleManagerens liste over Lejekontrakter. Til sidst udregnes en samlet pris. 2. Analyseklassediagram På baggrund af de udarbejde sekvensdiagrammer kan der nu sættes nogle metoder på klassediagrammet. Udover metoder er der tilføjet manager klasserne: Aftalemanager, KundeManager samt UdstyrsManager. 12
Figur 12: Analyseklassediagram for uc: Registrer reservation. Det skal overvejes hvilke lag man vil have i sit system. Her laves et GUI-lag(præsentationslag), et manager-lag og et domæne-lag. Manager- og domæne-lagene udgør applicationslogikken. Design er påbegyndt, idet nødvendige referenceattributter med typer med er påført for at få den nødvendige synlighed til de klasser der kaldes for at use casen: Registrer Reservation kan udføres. 13
Koden til klasserne Kunde og LejeAftale (Reservation) using System; using System.Collections; class Kunde //brug klasser fra namespace System //definition af Klassen Kunde private string navn; //instansvariable til klassen Kunde private string adresse; private string tlf; //attributterne: e-mail, kørekort og køretøj er ikke medtaget //constructor public Kunde(string n,string adr, string tlf) navn = n; adresse = adr; this.tlf = tlf; //properties til Kunde public string Navn get return navn; set navn= value; public string Adresse get return adresse; set adresse = value; public string Tlf get return tlf; set tlf= value; //metoder public override String ToString() //"overrides" fra object return Navn + " " + Adresse + " " + Tlf; //slut på klassen Kunde class AftaleManager private ArrayList aftaler; private KundeManager kundemanager; private UdstyrsManager udstyrsmanager; public AftaleManager() lejeaftaler = new ArrayList(); public void AddAftale(LejeAftale l) lejeaftaler.add(l); //slut klassen AftaleManager class LejeAftale private int id; private string startdato; private string slutdato; private double totalpris; private string status; private ArrayList udlejningsudstyr; 14
private ArrayList betalinger; private Kunde kunde; public LejeAftale(string stdato,string sldato, Kunde k) startdato = stdato; slutdato = sldato; kunde = k; status = reserveret ; public string StartDato get return startdato; set startdato = value; public string SlutDato get return slutdato; set slutdato = value; public Kunde Kunde getreturn kunde; setkunde = value; //metoder public void tilknytkunde(kunde k) kunde = k; class MainClass static void Main() //klasse indeholdende Main 15