Et førsteårs eksamensprojekt skrevet af Danni Jensen og David Olsen

Et førsteårs eksamensprojekt skrevet af Danni Jensen og David Olsen Indledning til rapporten Denne rapport er skrevet for at dokumentere vores 2. semester og dermed også vores 1. års eksamensprojekt. Vi fik at vide, at vi skulle lave et system baseret på programmeringssproget Java, og en database, med mindst 4 tabeller. Vi har fået undervisning i databasesystemet Oracle, men har valgt at bruge MySQL i stedet, da vi fandt dette mere tilgængeligt og brugervenligt. Den egentlige rapport, starter med at gennemgå en række analyser af vores kunde, og systemet vi er blevet bedt om at udvikle, herunder krav til systemet og en række diagrammer af de centrale use cases. Herefter vil vi give et estimat af hvad der kræves af computer og programmel for at afvikle vores system, for endeligt at analysere vores database og hvad systemets klasser er ansvarlige for, og noget om de valg vi har truffet i forbindelse med implementeringen af disse. 0

Indholdsfortegnelse: Gruppeovervejelser side 2 Organisationsform, forretningsgrundlag og interessentanalyse side 2 Feasibility Study side 3 SWOT analyse side 5 Strategiske, organisatoriske og logistiske overvejelser ved indførelse af systemet side 7 Krav til systemet side 8 Use Case diagram for Tambour.com side 8 Use cases fra side 9 - Login side 9 - Opret Bruger side 11 - Find Bruger side 13 - Rediger Bruger side 15 - Slet Bruger side 17 - Samlet klassediagram side 20 Vurdering af Tambour.com herunder systemkrav side 21 Implementering af Tambour.com side 22 Databaseanalyse side 23 Klassebeskrivelser af implementerede klasser for Tambour.com fra side 26 - LoginGUI side 26 - ForsideGUI side 26 - OpretBrugerGUI side 27 - FindBrugerGUI side 27 - RedigerBrugerGUI side 27 - SkiftPasswordGUI side 28 - HentBrugerGUI side 28 - DBAccess side 28 - LoadDriver side 29 - InputKontrol side 30 Brugertest side 31 Studierapport side 35 Konklusion. side 37 Kilder side 37 1

Gruppeovervejelser Lavet af David Olsen og Danni Jensen Rekvirent o Livgardens Gamle Tambourer Problembeskrivelse o Loginsystem o Medlemsregister o Evt. billedfremviser Grov tidsplan o Analyse påbegyndes 11/9 o Kodning påbegyndes 25/9 o Kodning færdig 1/12 o Rapportskrivning færdig 14/12 Evt. Arbejds(for)deling o Vi er en tomandsgruppe, og alle meninger vægtes lige. Hvis vi opdager en ikke-bearbejdet problemstilling, vurderer vi hvem der har tid til at tage sig af den, og vedkommende tager sig så af den Kommunikation o Gruppen internt Via msn GoogleCode Mail o Til rekvirent Primært via David o Til vejledere Via mail I vejledningstimerne Organisationsform, forretningsgrundlag og interessentanalyse Lavet af David Olsen Livgardens Gamle Tambourer er en forening, med en bestyrelse, der består af en formand, en næstformand og en kasserer. Derudover er der en række medlemmer og en ekstern revisor. Foreningens formål er, at samle tjenestegørende og hjemsendte tambourer fra den Kongelige Livgarde. Livgardens Gamle Tambourers forretningsgrundlag består af: - Indkomster i form af medlemskontingent og økonomiske tilskud fra div. interessenter. - Udgifter i form af anskaffelse af nye instrumenter, og vedligeholdelse af de gamle. Yderligere yder foreningen også tilskud til foreningsmøder. LGT s interessenter består især af foreningens medlemmer. Derudover kan bl.a. nævnes den Kongelige Livgarde, Livgardens Tambourkorps, de Danske Garderforeninger og Hjemmeværnet. 2

Feasibility Study Lavet af David Olsen Definition af projektet Projektet handler om at lave et login-system til foreningen Livgardens Gamle Tambourer. Systemet skal bruges som et decentraliseret medlemskartotek, hvor skal være muligt for brugere at logge ind og indtaste og redigere informationer om sig selv. Der skal yderligere være nogle administratorer som bl.a. skal kunne oprette og slette brugere fra systemet. Projektgruppen består af Danni Jensen og David Olsen. Kontaktpersonerne til LGT er Niels Stig Larsen, Robert Guglielmetti, Ole Greve Madsen, og David Olsen. Formål med analysen Formålet med analysen, er at give LGT mulighed for at se, om det kan betale sig for dem, at anskaffe systemet. Markedsproblematik Det vurderes ikke, at systemet vil gøre noget ved markedet set med LGT s øjne, men en alternativ løsning hvis ikke projektet kan gennemføres er at fortsætte som man hidtil har gjort. Set med projektgruppens øjne, vil gennemførelsen af projektet kunne medføre en efterspørgsel, der kunne medføre en indtægt. Organisationsproblematik Med indførelsen af systemet, vil der komme til at ske nogle organisatoriske ændringer, idet medlemmerne selv kommer til at stå for opdateringen af personlig data. Det kommer også til at betyde, at muligheden for kontakt, medlemmerne internt, vil blive mindre besværligt, da man blot kan logge ind på systemet, og finde de relevante oplysninger. Teknologiproblematik Da systemets database kommer til at ligge på internettet, skal der anskaffes serverplads og et domænenavn. Derudover skal brugere og, især, administratorer sættes ind i hvordan systemet virker, så det bliver brugt korrekt. Økonomiproblematik Systemet i sig selv, kommer ikke til at koste noget for LGT, da systemet bliver udviklet som en del af projektgruppens studieforløb. Der kommer dog til at være en udgift, idet databasen kommer til at ligge på internettet (se ovenstående punkt). Senere vedligeholdelse af systemet, vil heller ikke medføre udgifter, da projektgruppens David Olsen vil være ansvarlig for dette. Pengene til at betale for serverplads og domæne, skaffes ved medlemskontingenter, men det er endnu uvist om det er nødvendigt at øge kontingentet eller om det kan blive på det nuværende niveau. 3

Supplerende analyse - Teknisk gennemførlighed o Da systemet kommer til at køre via internettet, skal der anskaffes serverplads og et domæne, hvilket ikke burde være et problem, da disse kan anskaffes forholdsvis billigt hos diverse webhotel-udbydere. Derudover skal der ikke anskaffes noget udstyr til den daglige drift antaget at brugere på nuværende tidspunkt har en computer internetadgang. o Hvis brugere ikke skulle have internet adgang, kan dette problem løses ved at medlemmerne internt hjælper hinanden med at opdatere systemet. Disse to punkter taget i betragtning, vurderes det, at det er teknisk muligt at gennemføre projektet. - Økonomisk gennemførlighed o Prisen på systemet afhænger af prisen på serverplads og domæne. Da disse, som sagt, ikke koster så meget, vurderes det, at det vil være økonomisk muligt at gennemføre projektet. o Det vurderes ligeledes, at det omkostningerne ved anskaffelse af systemet, lad det være tid eller penge, ikke overskygger fordelene ved projektets gennemførelse. - Lovmæssig gennemførlighed o Den eneste lov, der ville kunne komme i vejen for projektets gennemførelse, er persondataloven. En undersøgelse af dette viser, at det ikke er tilfældet, og derfor vil projektet godt kunne gennemføres. (Se evt. afsnittet Strategiske, organisatoriske og logistiske overvejelser ved indførelse af systemet ) - Operationel gennemførlighed o Der er ikke observeret nogen protester ved indførelse af systemet. Derimod, har der været en generel optimisme ved systemets omtale. Derfor vurderes det, at der ikke her står noget i vejen for, at projektet kan gennemføres. - Tidsplansmæssig gennemførlighed o Da der fra projektgruppens side, er udstedt en deadline, vurderes det at projektet godt vil kunne gennemføres inden for en rimelig tidsperiode. Konklusion Ovenstående undersøgelse, viser at der ikke er nogen væsentlige faktorer der stiller sig i vejen for projektets gennemførelse. Derimod viser undersøgelsen, at det vil være til LGT s egen fordel, at lade projektet gennemføre, da det i sidste ende vil lette arbejdsbyrden for den ansvarlige for det nuværende medlemskartotek, og det vil derfor give mulighed for andre fokuspunkter. 4

SWOT Analyse af LGT Lavet af Danni Jensen På trods af at ydelsen for LGT ikke er aflønnet er der ikke meget forskel på en SWOT analyse hertil og en analyse af en egentlig virksomhed. Vi starter med de styrker der er at finde for LGT. Styrker: Der er ikke mange konkurrenter der tager rundt til diverse arrangementer og spiller tambourmusik, så man må sige at der er meget få konkurrenter. Da hele konceptet er udspringet ud fra tiden i den Kongelige Livgarde er der samlet erfaring i et disciplineret og professionelt miljø. Den gode erfaring har givet fordele i form gode kontakter og samarbejdsaftaler. Der er stadig kontakter til den Kongelige Livgarde. Succesfulde og gennemførte optrædninger har givet tambourne et godt ry. Svagheder: Arbejdet vedrørende LGT er frivilligt og derfor er der nødt til at blive fastholdt interesse hos de gamle medlemmer og der er nødt til at være initiativer for at få nye medlemmer med også. Der er ingen indtjening i foreningen udover kontingentet og økonomisk støtte fra interessenter og derfor er det svært at markedsføre sin eksistens på normal vis - f.eks. ved reklamer. Utilfredse medlemmer kan trække andre med sig ved at skabe dårlig atmosfære. Det er en forening af frivillige i et lille segment og derfor er det ikke nemt at finde nye medlemmer. Det er primært på Sjælland, der spilles og medlemmerne kan komme fra alle dele af Danmark. Det kan være problematisk at så mange skal mødes et bestemt sted i landet. Muligheder: Hvis der kan findes en måde at markedsføre budskabet om foreningens eksistens og spille på de styrker der findes i foreningen, vil det bevirke større interesse for eksistensen og trække flere medlemmer til. Tambour.com vil give fordele i form af bedre og mere strømlinet organisering. Det vil være nemmere at oprette medlemmer og at holde medlemmernes kontaktoplysninger opdateret. Ny teknologi er desuden med til at give forening et godt image. Hver gang foreningen er ude at spille til et arrangement skaber det ny omtale. Dette er en klar mulighed for at udbrede budskabet og få anmodninger om at deltage i flere arrangementer. Organiseringen og den tidligere beskæftigelse i den Kongelige Livgarde giver et godt sammenhold som man nok ikke ser under andre omstændigheder. At foreningen allerede er eksisterende og kører gennem medlemsbetaling betyder at eventuelle konkurrenter kan få det svært. 5

Trusler: Hvis der bliver oprettet et nyt tambourkorps i nærheden af København, hvor LGT primært holder til, kan det udgøre en trussel. Et væsentligt optagelseskrav er, at medlemmerne som minimum 1 skal have aftjent værnepligt hos den Kongelige Livgardes Tambourkorps. Da et nyt korps højst sandsynligt ikke vil have sådan et krav, vil de to korps blive konkurrenter. De kontakter foreningen har, skal holdes ved lige, ellers er der chance for at der ikke bliver flere arrangementer hvor foreningen bliver bedt om at spille. Manglende interesse, familieforhold osv. kan bevirke at der kommer en nedgang i kontakter. Derfor er det nødvendigt at få nye kontakter løbende. Manglende fremmøde kan bevirke at et arrangement ikke forløber planmæssigt, og at niveauet ikke er som forventet. Dette kan give dårlig omtale og bevirke at kommende arrangementer bliver aflyst og at der ikke kommer nye arrangementer. Styrker Få konkurrenter Viden om faget Tilfredse medlemmer Gode kontakter/ samarbejdsaftaler Godt rygte Muligheder Markedsføring Ny teknologi God omtale Dårligt sammenhold og dårlig økonomi hos konkurrenter Svagheder Afhængig af interesserede Manglende markedsføring Utilfredse medlemmer Geografi Trusler Oprettelse af konkurrerende korps Kontakter forsvinder Dårlig omtale 1 Nogle medlemmer er tidligere konstabler i den Kongelige Livgardes Tambourkorps 6

Strategiske, organisatoriske og logistiske overvejelser ved indførelse af systemet Lavet af David Olsen Indtil nu har registreringen og administrationen af foreningens medlemmer, været baseret på et exceldokument, som én person, revisoren, en foreningen er ansvarlig for. Dvs. at når der kommer nye medlemmer, skal alle informationer om vedkommende gives til ham, så han kan indføre det i dokumentet. Dette gør processen meget indskrænket, og det gør, at informationerne ikke altid bliver holdt ajour. Yderligere betyder det, at hvis der var mere end én person, der havde adgang til at redigere i medlemsoplysningerne, så ville man ende med flere forskellige dokumenter, med forskellige informationer i. Ved indførelse af tambour.com skal revisoren kun oprette medlemmet i databasen, og behøver ellers ikke tænke mere på informationer om vedkommende, da medlemmet selv skal kunne gøre det via internettet. Ved at have databasen på internettet, kan man også give andre medlemmer mulighed for at se informationer om de andre medlemmer. I forbindelse til denne funktion, var der til at begynde med, en smule tvivl om hvor meget man kan tillade sig, at lade andre medlemmer se. Derfor satte jeg mig ned, undersøgte reglerne for dette, og fandt at persondataloven siger følgende: Videregivelse af medlemslister i foreningsblade m.v. kan som udgangspunkt ske uden den enkeltes (medlemmets) samtykke under forudsætning af, at bladet kun distribueres til medlemmer. [ ] I den forbindelse bemærkes, at Datatilsynet i sin praksis ligestiller lukkede sider på internettet med et foreningsblad m.v. under forudsætning af, at det f.eks. ved hjælp af password eller lignende sikres, at kun medlemmer har adgang til den pågældende side. 2 Med denne information, valgte vi i gruppen, at lade medlemmerne se alle oplysninger om hinanden, da det fra begyndelsen af projektet har været et krav, at programmet skal beskyttes med password. Yderligere har det også, fra projektets start, været et krav at passwords er krypterede. Se mere om dette senere. 2 http://www.datatilsynet.dk/erhverv/foreninger/ 7

Krav til systemet Der foreligger allerede et medlemskartotek i form af et Excel ark. Da der er mange medlemmer og mange informationer om hvert medlem er det et stort arbejde for en enkelt person at holde opdateret. Derfor ønskes der er et program der kan lette denne arbejdsbyrde. Dette specifikke behov for overskuelighed har været ideelt for projektgruppen at realisere. Der er udfærdiget følgende kravsliste i denne forbindelse. Lavet af David Olsen og rekvirent Use Case Diagram for Tambour.com Skrevet af Danni Jensen Dette er use case diagrammet for systemet. Det er værd at bemærke at use casen Find bruger indgår i så mange use cases som den gør. Vi har i de efterfølgende afsnit dokumenteret følgende use cases: Login Opret Bruger Find Bruger Rediger Bruger Slet Bruger Lavet af David Olsen og Danni Jensen 8

Use case: Login Skrevet af Danni Jensen Lavet af David Olsen Denne use case er helt central for systemet da der ikke kan foretages noget uden denne har fundet sted. Herunder ser vi sekvensdiagrammet for use casen Login og dertil hørende klasse diagram. I systemet skal der logges ind for at der kan foretages yderligere handlinger. Ved login tages der højde for om brugeren er oprettet som admin eller ej i systemet, da admins har rettigheder til mere end almindelige brugere i systemet. Selve login proceduren foregår ved at brugeren indtaster sit brugernavn og login ved en dertil oprettet GUI. GUI sender login videre til kontrolklassen login, der gemmer dette og sender det videre til InputKontrol klassen som tjekker for om der er nogle fejl i indtastningen, f. eks et felt der ikke er udfyldt. InputKontrol sender loginet videre til DBAccess der opretter en instans af LoadDriver klassen for at lave et SQL statement til databasen, dette statement tjekker om brugeren overhovedet findes, hvis ja, hvad dennes password er og om vedkommende er oprettet som admin. LoadDriver sender login tilbage til DBAccess der laver det returnerede resultset om til et Array for at kunne læse det internt i java og sender dette tilbage til login. Login sikrer sig nu om indholdet af det Array, der er modtaget, passer med de to strenge der er indtastet i GUI. Hvis disse to passer sammen, logges der nu ind i systemet, enten som admin eller ikke. 9

Her ses sekvensdiagrammet for Login use casen Det er påkrævet at man er oprettet i databasen for at kunne logge ind. Herudover er det nødvendigt at indtaste både sit brugernavn og sit password. Det er ikke muligt ikke at have allokeret noget password, derfor bliver der først og fremmest tjekket om man har indtastet det man skal. Herefter bliver det password der er relateret til det indtastede brugernavn hentet i databasen. Hvis man indtaster et ugyldigt brugernavn bliver der gjort besked på dette. Hvis man indtaster et forkert password er man ikke i stand til at logge ind. Login klassen er ansvarlig for at sammenligne det indtastede password med det relevante for brugeren, hvis dette verificeres bliver der logget ind i systemet og forsiden bliver vist for brugeren. Lavet af Danni Jensen Her ses klassediagrammet for use casen I klassediagrammet ses at attributterne brugernavn og password sendes med til login for at blive sammenlignet med database indholdet. I DBAccess er ip, bruger og kode med for at kunne lokalisere databasen. Dbmetadata er de informationer der modtages fra LoadDriver som resultset fra SQL. Statementet er det der oprettes for at kunne læse i databasen. Lavet af Danni Jensen 10

Use case: Opret Bruger Skrevet af Danni Jensen Lavet af David Olsen Admins er de eneste der har rettigheder i systemet til at oprette en bruger. Det bliver bestemt ved login om brugeren der er logget ind har admin rettigheder. Knappen i GUI til at oprette en bruger er kun synlig for admins via forsiden. Når brugeren skal oprettes tastes alt information ind i den hertil indrettede GUI. Der er felter der er påkrævet at blive udfyldt: fornavn, efternavn, adresse og postnummer. Der bliver kørt kontrol på om disse er udfyldt og i postnummerets tilfælde om det er et eksisterende dansk postnummer. Efter alt relevant information er indtastet trykkes der på knappen gem brugerinfo og brugeren gemmes i databasen. Brugernavn og brugernummer bliver fastsat af programmet ved oprettelse. Sekvensdiagram for Opret Bruger Admin indtaster de relevante informationer om medlemmet og trykker gem når vedkommende er tilfreds med indtastningerne. Systemet sender det indtastede videre til kontrol for fejl eller mangler. Herefter sendes data videre til DBAccess som har ansvaret for at videregive information der bruges til at oprette relevante statements. Når brugeren bliver bekræftet som gemt af systemet sender LoadDriver besked om at brugeren er gemt videre til OpretBruger og i sidste ende Opret bruger UI som herefter sørger for at admin bliver vist forsiden. Lavet af David Olsen 11

Nu ser vi aktivitetsdiagrammet, samt forklaring af use casen Vi ser her at den indloggede er nødt til at være admin for at kunne oprette en bruger. Den mulighed der er for forskellige fremgangsmåder går på om indtastningerne er foretaget korrekt. Er de ikke det bliver den nye bruger ikke oprettet og admin får besked om dette af systemet og de påkrævede information udfyldes hvorefter systemet gemmer, hvis de er korrekte denne gang. Lavet af David Olsen Til sidst har vi klassedigrammet OpretBrugerUI er fyldt med brugerinformation, det er ikke alle disse der skal udfyldes, men de er afbilledet alligevel. Disse brugerinfo er samlet som en enkelt attribut i de resterende klasser. Lavet af David Olsen og Danni Jensen 12

Use case: Find Bruger Skrevet af Danni Jensen Lavet af David Olsen Alle brugere i systemet der er logget ind, kan søge på andre brugere og få vist disses brugerinformation. Alle info bliver vist, med undtagelse af eventuelle kommentarer om brugeren. Det er kun admins der kan se og rette i disse kommentarer. Dette er gjort for at det er muligt at skrive om manglende indbetaling og lignende. For at finde en bruger skal der første logges ind, derefter vælges Find Bruger i GUI. Dette leder frem til en ny GUI der er indrettet til at søge efter brugere. Der kan søges på enten Fornavn eller Efternavn, eventuelt kun dele af navnet. Ud af denne søgning kommer der en combobox der indeholder de fundne brugere. I tilfælde af at der ingen brugere findes gøres søgeren opmærksom på dette via en meddelelsesbox og der kan på ny søges en bruger. Når en bruger er fundet kan denne vælges i comboboxen og når der trykkes på knappen Hent Bruger fremkommer information om den valgte bruger. Dette er en central use case da den er springbræt for en masse andre use cases, også markeret som include s i use case diagrammet. Aktivitetsdiagram for Find Bruger I aktivitetsdiagrammet beskrives hvilke muligheder der fremkommer når en bruger søges. Det interessante her er at når brugeren søges skal der forefindes en bruger med valgte kriterier for at der kan ske yderligere. Søgeren får derfor valget om at søge en ny bruger hvis en søgning ikke er frugtbar. Lavet af David Olsen 13

Sekvensdiagram for Find Bruger Brugeren starter med at indtaste søgekriterier og trykke på Find Bruger knappen. GUI en sender det indtastede videre til FindBruger kontrol klassen der tjekker for eventuelle fejl såsom tomme kriterier. Hvis der ikke er fejl sendes forespørgslen videre til forespørgsel i databasen. Resultaterne bliver lavet om fra resultset til et Array således at der kan returneres mere end en bruger. Nu kan den ønskede bruger vælges og hentes via GUI. Det er her igennem at admins har udvidede muligheder for manipulation med brugeren, såsom sletning og tilføjelse af en kommentar. Lavet af David Olsen Klassediagram for Find Bruger I klassediagrammet er det vigtigt at notere sig at FindBrugerUI via attributter er vidende om den indloggede bruger er admin i systemet. Dette giver nemlig specielle rettigheder som nævnt i sekvensdiagrambeskrivelsen. Lavet af David Olsen 14

Use case: Rediger Bruger Skrevet af Danni Jensen Lavet af David Olsen En bruger redigerer sine egne info. Det er ikke muligt for andre at redigere en bruger, heller ej en admin. Dette bevirker at det ikke er en enkelt person der har ansvaret for at holde medlemslisten over brugere opdateret. Dette var tilfældet før systemets indførelse og det blev simpelthen ikke holdt ved lige. Systemet er blevet til for at skabe overskuelighed og en lettelse af arbejdsbyrder. Dette betyder at en bruger skal være logget ind i systemet og derefter vælge at redigere sine egne informationer. Brugeren trykker på knappen rediger bruger og bliver herefter vist en hertil dedikeret GUI. Den indeholder de nuværende informationer om brugeren, således at det ikke er alt der skal opdateres, men kun den relevante information. Brugeren ændrer det der ønskes ændret og trykker på Gem Bruger. Systemet gemmer nu den opdaterede og den eventuelt uændrede information og giver brugeren bekræftelse på at informationerne er gemt. Her ses aktivitetsdiagrammet for Rediger Bruger Det er værd at bemærke at når forkert info er indtastet vendes der tilbage til GUI indeholdende brugerinformation så der kan indtastes korrekt information Lavet af Danni Jensen 15

Sekvensdiagram for Rediger Bruger Når en bruger ønsker at redigere sine data skal denne trykke på knappen Rediger Bruger. Det sender besked til databasen via DBAccess om at hente informationerne på den relevante bruger. Disse sender tilbage som et resultset der læses via et Array i DBAccess der så sender tilbage til GUI for Rediger Bruger. Nu kan brugeren indtaste de opdaterede oplysninger og trykke på Gem Bruger der sender de opdaterede informationer til Rediger Bruger for at tjekke det nye input for eventuelle fejl, såsom forkert postnummer. Når disse info er verificeret sendes det til DBAccess der sørger for at sende det videre til LoadDriver som generer et statement som databasen forstår for at gemme brugeren. Når dette er gjort sendes der besked tilbage om at alt er vellykket. Brugeren får via GUI besked om dette og forsiden vises på ny. Følgende er beskrivelse af klassediagrammet for Rediger Bruger Lavet af Danni Jensen Det ses her at der sendes information om den indloggede bruger til de relevante klasser i form af attributter der indeholder information om den bruger der er logget på og om de informationer der er registreret om denne bruger i databasen. Lavet af Danni Jensen 16

Use case: Slet Bruger Skrevet af Danni Jensen Lavet af David Olsen Når en bruger ønskes slettet, er det for det første nødvendigt at være logget ind og for det andet er det nødvendigt at være logget ind som admin. Databasen er ansvarlig for at holde styr på både brugere og hvilke af disse der er admins i systemet. En bruger bliver aldrig helt slettet fra systemet, men sat til at være inaktiv, på denne måde er det muligt stadig at hente brugerinformation hvis det skulle være nødvendigt, selvom denne er slettet. Herigennem har en bruger to tilstande, en hvor brugeren er aktiv og derved fremgår af alle menuer i systemet og en tilstand hvor brugeren ikke fremkommer som bruger ved søgning og lignende. Det er ej muligt for en slettet bruger at logge ind da de bliver slettet fra login tabellen i databasen. Der er oprettet en separat tabel til at holde styr på medlemmers aktuelle status i systemet, i denne sættes årstallet for brugerens sletning. Selve sletningen foregår ved først at benytte Use Casen Find Bruger for at finde den bruger der ønskes slettet. Da det som sagt kun kan gøres af en admin, skal det ske gennem den GUI der er lavet når en bruger er fundet og hentet. 17

Her ses sekvensdiagrammet for use casen Slet Bruger Aktøren er i dette tilfælde en indlogget at admin og for at slette en bruger er vedkommende nødt til først at finde brugeren der ønskes slettet, dette sker i use casen Find Bruger der er beskrevet andetsteds i denne rapport. Admin starter med at vælge den bruger der ønskes slettet gennem GUI. GUI giver herefter besked om at den vedkommende bruger ønskes hentet til admin formål. Når denne bliver vist i GUI vælger admin muligheden Slet Bruger hvilket sender besked til systemet om at denne bruger skal slettes fra databasen ved at oprette forbindelse og genere det relevante statement. Sletningen skal bekræftes af brugeren og herefter bekræfter systemet at brugeren er slettet og vender tilbage til forsiden for systemet. Dette sker da en sletning ikke forventes at være en hyppig hændelse. Lavet af David Olsen og Danni Jensen Vi ser her klassediagrammet for Slet Bruger use casen Her ses det på attributterne i SletBrugerUI at denne klasse kender til admin rettigheder og brugernavnet på den indloggede admin. Medlemsnummer i de 3 andre klasser er nummeret på det medlem der ønskes slettet fra systemet. I DBAccess og LoadDriver er indeværende år det årstal som medlemmet blev slettet. Lavet af David Olsen og Danni Jensen 18

Dette er et aktivitetsdiagram for Slet Bruger Her ses det at det er en admin der trykker slet bruger. Admin får et valg der skal bekræftes for at slette brugeren. Hvis dette opfyldes bliver brugeren slettet og admin får bekræftelse. Lavet af David Olsen 19

Samlet Klassediagram Herunder ses vores samlede klassediagram. Det viser de væsentligste metoder og variabler, der er brugt i systemet. For at dette klassediagram ikke skulle fylde for meget, har vi valgt at samle alle UI-klasser og alle Kontrolklasser i en samlet UI- og en samlet Kontrolklasse. Vi har tilføjet kardinalitet, der viser relationerne imellem de forskellige klasser: - Én UI-klasse kan have relation til én kontrolklasse, og én kontrolklasse kan have relation til mange UI-klasser - Én UI-klasse kan have relation til ingen eller én DBAccessklasse, og én DBAccessklasse kan have relation til ingen eller mange UI-klasser - Én UI-klasse kan have relation til ingen eller én LoadDriverklasse, og én LoadDriverklasse ingen eller mange UI-klasser - Én kontrolklasse kan have relation til én DBAccess-klasse, og én DBAccessklasse kan have relation til én Kontrol-klasse - Én Kontrolklasse kan have relation til én LoadDriverklasse, og én LoadDriverklasse kan have relation til én Kontrolklasse - Én DBAccessklasse kan have relation til én LoadDriverklasse, og én LoadDriverklasse kan have relation til én DBAccessklasse. 20

Vurdering af Tambour.com herunder systemkrav Lavet af David Olsen og Danni Jensen For at køre programmet, kræver det, at man har installeret følgende programmel: - Nyeste Java Runtime Environment 3 - Nyeste Java Development Kit 4, for at kunne se og redigere kildekode - NetBeans 5 (det foretrækkes at hente den fulde pakke) eller anden Java-udviklingsværktøj, for at læse og redigere kildekode (se evt. startvejledning) - MySQL Community Server 5.0 6 - MySQL GUI Tools 7 (MySQL Administrator 1.2, MySQL Query Browser 1.2, MySQL Migration Toolkit 1.1) - MySQL Connector/J 8, der er den officielle JDBC-connecter mellem Java og MySQL Java er blevet udviklet således, at det skal kunne køre på alle styresystemer. Vi har dog ikke haft mulighed for at teste det på andre styresystemer end Windows XP service pack 2 og 3. Derfor anbefaler vi, at det er dette styresystem der bliver brugt, da vi ved at det er fuldt funktionelt her. Systemkravene til Tambour.com er vurderet ud fra vores udviklingspc ere: - Windows XP Service Pack 2 - Pentium 4 på 1 GHz eller bedre - 512 Mb RAM - 500 Mb fri Harddiskplads eller mere alt efter størrelsen på databasen - Tastatur og pegeredskab Vores system fungerer som en tilgang til databasen via en GUI. Vi har ingen vilde algoritmer der skal regnes ud, så derfor har det ikke været en fordel at lave tråde. Derfor ser vi ikke at der er nogen fordele ved at afvikle systemet på en computer med mere end én CPU, ud over computerens øgede regnekraft, og computerens evne til at afvikle processer, der ikke har noget med vores system at gøre. Hvis computerens RAM-lager er for småt, vil det komme til at betyde længere responstid til data, da systemet vil være nødt til at anvende swapping (dvs. det der ligger gemt i RAM bliver flyttet til Harddisken, for at få plads til ny data i RAM. Dette giver langsommere responstid, da Harddisken har længere søgetid end RAM). 3 http://java.com/en/download/windows_xpi.jsp?locale=en&host=java.com:80 4 http://java.sun.com/javase/downloads/index.jsp 5 http://www.netbeans.org/downloads/index.html 6 http://dev.mysql.com/downloads/mysql/5.0.html 7 http://dev.mysql.com/downloads/gui-tools/5.0.html 8 http://dev.mysql.com/downloads/connector/j/5.0.html 21