BSc Project Computer Science / Software Technology IN3700

Transcriptie

1 BSc Project Computer Science / Software Technology IN3700 Speurplanet.nl onderdeel van Moerstaal TU Delft - Faculteit Elektrotechniek, Wiskunde en Informatica Datum: 27 augustus 2006 Auteurs: D. Krol J. Paalvast K. Sihan Opdrachtgever: R. Grahmbeek Moerstaal Begeleider: M. Kodde Moerstaal BSc Commisie: Ir. F. Ververs TU Delft Ir. B.R. Sodoyer TU Delft 1

2 1 Voorwoord Dit verslag is het eindproduct van een BSc stage gelopen door D. Krol, J. Paalvast en K. Sihan bij Moerstaal. Het vormt een samenvattend geheel van alle documentatie die tijdens het project geproduceerd zijn samen met een reflectie op de manier waarop het project is verlopen. In dit rapport zullen wij duidelijkheid verschaffen in de keuzes en aanpak hiervan. Wij willen graag onze begeleiders vanuit Moerstaal, R. Grahmbeek, M. Kodde en onze begeleiding vanuit de TU Delft, F.Ververs bedanken voor hun inzet, begeleiding, adviserende taken en vrijheid tijdens het project. D. Krol, J. Paalvast en K. Sihan 2

3 Inhoudsopgave 1 Voorwoord 2 2 Inleiding Context Verslag Project Organisatie Planning Originele planning Uiteindelijke verloop Communicatie Faciliteiten Probleemstelling en Analyse Opdrachtformulering Doelstelling project Analyse User Interface Inleiding Gebruikers Interface Beheerders Interface Screenshots Ontwerp Inleiding Klasse diagram Database ontwerp Gebruiker Admin Advertenties Sequence diagrammen Implementatie Inleiding Code layout Gebruikte software Verdeling in subsystemen Taakverdeling Herzient ontwerp Gebruiker zoekt advertentie De gebruiker meldt zich af voor reclam ing Koper houdt favorieten bij Admin mailt reclame rond Superadmin past admin aan Gebruiker zegt account op Gebruiker moet via mail op de hoogte worden gehouden van de advertenties die zij zoeken (en afmelden)

4 8 Testen Inleiding Test Admin Inlog Test Admin Test Advertentie Maken Test Account Maken Test Gebruiker Inlog Conclusie en aanbevelingen Defintities Requirements Analysis Document Introductie Doel van het systeem Cruciale succesfactoren Voorgesteld Systeem Functionele eisen Niet-functionele eisen Use Cases Gebruiker zoekt advertentie Gebruiker maakt account aan Koper houdt favorieten bij Verkoper maakt advertentie Verkoper wijzigt advertentie Koper neemt contact op met verkoper via Gebruiker meldt zich af voor reclam ing Gebruiker logt in De gebruiker logt uit Gebruiker zegt account op Gebruiker vraagt wachtwoord op Koper moeten op een advertentie kunnen bieden Gebruikers moeten via mail op de hoogte worden gehouden van advertenties die zij zoeken Gebruikers moeten zich af kunnen melden van de mailing naar gezochte advertenties Admin verwijdert advertentie Admin verwijdert categorie Admin voegt hoofdcategorie toe Admin voegt subcategorie toe Admin past categorie aan Admin mailt reclame rond Admin vraagt gegevens van alle gebruikers Superadmin voegt admin toe Superadmin past admin aan Superadmin verwijdert admin Screen mockups

5 2 Inleiding Het project bestond uit het vinden van een oplossing om het huidige speurplanet.nl te verbeteren danwel te vernieuwen. Hierbij was hergebruik van het reeds bestaande speurplanet.nl een optie. Samen met de opdrachtgever zijn we tot de conclusie gekomen dat hergebruik niet een optimale oplossing zou bieden. Ten gevolge dit besluit is er gekozen om van scratch, een compleet nieuw systeem te ontwerpen en te implementeren. In dit rapport zullen wij duidelijkheid verschaffen in de keuzes en aanpak hiervan. 2.1 Context Het project bestond uit het vinden van een oplossing om het huidige speurplanet.nl te verbeteren danwel te vernieuwen. Speurplanet is een website waar gebruikers (tweede hands) artikelen kunnen verkopen en kopen. De opdrachtgever wil het huidige speurplanet.nl vervangen. Het huidige speurplanet.nl moet worden vernieuwd/vervangen, omdat de huidige layout en implementatie niet meer aan de eisen voldoen. Speurplanet is een onderdeel van Moerstaal en D.M. Media. Het bedrijf Moerstaal is een provider van adressen, homepages en domeinnamen en D.M. Media is een op gericht marketing bureau. 2.2 Verslag Eerst zal in hoofdstuk 3 een overzicht worden gegeven van de projectorganisatie. Hierin zal onder andere gekeken worden naar de oorspronkelijke planning en hoe het uiteindelijke verloop is gegaan. In hoofdstuk 4 zal een probleemstelling en analyse gegeven worden. Daarna zal in hoofdstuk 5 het ontwerp behandeld worden, hierin is een samenvatting te vinden van wat er tijdens het ontwerp gemaakt is. Het volledige Requirement Analysis Document is als bijlage toegevoegd aan dit document. Vervolgens zal in hoofdstuk 6 de implementatie worden besproken en wordt er gekeken hoe deze afwijkt van het ontwerp. In hoofdstuk 7 wordt er een beschrijving gegeven van de uitgevoerde tests. Ter afsluiting wordt in hoofdstuk 8 een conclusie gepresenteert gepaard met enige aanbevelingen. 5

6 3 Project Organisatie 3.1 Planning Originele planning Ontwerp: (3 weken) 1. RAD: Requirements Analysis Document 2. SDD: System Design Document 3. ODD: Object Design Document Tabel 1: Implementatietabel onderdeelnr. beheer/gebruiker implementatie beschrijving 1 Database Ontwerp 2 Database + zoekfunctie en een pagina die alleen de inhoud van de database weergeeft 3 Gebruiker Account aanmaak/beheersysteem 4 Beheerder Accountbeheer (hierin kunnen ook admin-accounts aangemaakt worden) 5 Gebruiker Login-gedeelte van de shop 6 Beheerder Login-gedeelte van de shop 7 Gebruiker Advertentie beheer/aanmaak systeem 8 Beheerder Advertentie beheer systeem 9 Gebruiker Winkelwagen beheer 10 Beheerder Information Extraction System (zowel op account als advertenties) 11 Beheerder Commercial Mailing System 12 Grafische User Interface voor zowel front- als back-end. 13 Autocomplete search* Implementatie: (5 weken) *Dit onderdeel is een Could-Have en wordt geïmplementeerd wanneer er tijd over is. De geschatte verdeling van de implementatie onderdelen is als volgt: Tabel 2: Gewichtsverdeling voor implementatie onderdeelnr. gewicht 1 10% 2 t/m 4 20% 5 t/m 10 40% 11 t/m 13 30% Testen en documentatie van de code (1 week) Het testen gebeurt ook tijdens de implementatie Uiteindelijke verloop Het Plan van aanpak was klaar op 7 mei. Vervolgens hebben we vier weken besteed aan het ontwerp. Het ontwerp bestaat uit het Requirements Analysis Document, het Object Design Document en het System Design Document. Daarna is er aan de implementatie gewerkt. Het grootste gedeelte van de implementatie is in ruim vier weken afgerond en was klaar op 13 juli en door de opdrachtgever goedgekeurd. Na het houden van een zomerreces van twee weken is er vanaf eind juli aan de afronding van de implementatie, unit tests en de layout gewerkt. Deze werkzaamheden zijn afgerond op 13 augustus. 6

7 3.2 Communicatie Vanaf het begin is er afgesproken om 2 a 3 dagen in de week bij elkaar te komen om zo de voortgang van het project te bespreken en in groepsverband te werken. In de praktijk is dit echter meer 1 a 2 dagen geworden. Naast deze twee dagen hadden we om de week een evaluatie/voortgangs bespreking met een van de begeleiders vanuit Moerstaal. De verdere communicatie van de dagelijkse voortgang, samengaand met de uitwisseling van documenten en deliverables, geschiede per . Verder is er onderandere via MSN Messenger en telefonisch contact geweest. 3.3 Faciliteiten Voor het project is er door de opdrachtgever een kantoorruimte gehuurd. Tevens heeft de opdrachtgever deze ruimte voorzien van meubulair en de noodzakkelijke faciliteiten. Hieronder vielen 3 workstations, een printer, een telefoon/ internetaansluiting en standaard kantoorbenodigdheden. Tevens zou de opdrachtgever een test server ter beschikking stellen om het systeem op te testen. Helaas was het niet mogelijk een test server met php5 tot onze beschikking te stellen. Om dit probleem te verhelpen hebben we besloten ieder een eigen webserver met de benodigde services op te zetten. 4 Probleemstelling en Analyse 4.1 Opdrachtformulering Het project bestond uit het ontwikkelen van een website, inclusief beheeromgeving, waar (tweede hands) producten via het internet te koop aangeboden en verhandeld kunnen worden. De te ontwikkelen website moet minstens een user interface voor het plaatsen en tonen van adevertenties bevatten, een user interface voor het aanmelden als adverteerder en achteraf bewerken van persoons gegevens en een beheerinterface voor het bewerken en verwijderen van advertenties. Meerdere beheerders moeten kunnen inloggen op dit systeem en enkele super beheerders moeten de mogelijkheid hebben om de persoonsgegevens in te zien en hiervan een export te maken. Het naderhand onderhouden van de site behoort niet tot onderdeel van dit project. 4.2 Doelstelling project De opdrachtgever wil de te ontwikkelen website commercieel exploiteren door middel van het sturen van een wekelijkse reclame mailing aan alle gebruikers. Dit maakt het tevens mogelijk om de website geheel kostenloos voor de gebruikers te houden. 4.3 Analyse Voor het onderzoek naar de mogelijkheden voor speurplanet.nl is er voornamelijk gekeken naar: marktplaats.nl, ebay.nl, speurders.nl en speurplanet.nl. Bij al deze sites, met uitzondering van ebay.nl wordt de gebruiker gelijk geconfronteerd met grote onoverzichtelijke hoeveelheden tabellen met daarin Categorieën en advertenties. Ook hebben al deze sites links op de pagina een lange categorielijst staan om mee te zoeken. Deze categorie overzichten werden als erg onoverzichtelijk ervaren en als eerste onderscheidende punt is er voorgesteld om de beginpagina zo leeg mogelijk te laten en de gebruiker niet te laten confronteren met een grote hoeveelheid aan informatie. Deze stijl is bijvoorbeeld ook terug te vinden bij de populaire zoekmachine Google. Alleen moet de gebruiker dan wel de optie krijgen om in zowel Categorieën als in subcategorieën te zoeken. In overleg met de opdrachtgever hebben we besloten de beginpagina dan ook zo leeg mogelijk te houden. Het was echter wel gewenst dat de mogelijkheid om via een categorielijst te kunnen zoeken, zoals voorheen op speuplanet.nl mogelijk was, bleef bestaan. Om gebruikers te laten verkopen is er gekozen voor het gebruik van accounts net zoals bij ebay.nl. Voor het doel van het systeem is gekozen voor accountgebruik. Dit bleek tevens het versturen van reclame mailing eenvoudiger te maken. Gebruikers die zich voor een account aanmelden moeten een geldig adres opgeven. De geldigheid van dit adres wordt gecontroleerd door een verificatie die verstuurd wordt naar het 7

8 opgegeven adres. Door een link met unieke code in deze verificatie mail kan de gebruiker zijn account dan activeren. Als de gebruiker een of meerdere geldige advertenties heeft staan zal hij een wekelijkese reclame mailing ontvangen. Het systeem kan dit makkelijk controleren. Heeft de gebruiker geen advertenties meer staan zal hij ook geen reclame mailing ontvangen. Het accountgebruik is voor de verkopende gebruiker erg handig. Heeft de verkoper eenmaal een account aangemaakt dan kan hij snel advertenties aanmaken zonder dat hij steeds opnieuw zijn gegevens in hoeft te voeren. Ingelogde verkopers kunnen d.m.v. een advertentie beheerscherm makkelijk hun eigen advertentie bekijken, wijzigen en verwijderen. Voor het versturen van een bericht van kopers naar verkopers en het bieden is de manier van speurplanet.nl gebruikt. Kopers die een advertentie bekijken kunnen onderaan de pagina een formulier in vullen met een bod of een bericht aangaande de advertentie. De koper kan het adres van de verkoper niet zien. Dit bericht of bod wordt dan naar de verkoper gestuurd. De verkoper kan vervolgens via mail op de koper reageren. Deze manier is gebruikt omdat het op speurplanet.nl tot een goed resultaat leidt. 8

9 5 User Interface 5.1 Inleiding Dit hoofdstuk laat de uiteindelijke gebruikers interface van speurplanet.nl zien. Hieronder kan men een selectie aan screenshots van zowel de eindgebruikers interface als het beheersysteem terugvinden. De screen mockups uit het RAD waren de uitgangspositie voor de uiteindelijke layout van speurplanet.nl. Zoals ook de screen mockups al duidelijk maakten was het de bedoeling om een simpele en overzichtelijke layout te creëren om zodoende het gebruikersgemak te bevorderen. Door het gebruik van kleurvlakken is herkenbaarheid en oriëntatie binnen speurplanet.nl tevens verhoogd. Voor het spoedig laden van de index website is er gekozen voor een overzichtelijke simpele beginpagina die vervolgens doorlinkt naar een iets meer uitgebreide interface. Hieronder volgen de screenshots. 5.2 Gebruikers Interface In figuur 1 is de binnenkomst pagina weergegeven die men ziet als men naar surft. De kleurvlakken en het simpele ontwerp zal in de vervolg pagina terugkomen. Door te zoeken, of elke andere vorm van actie op deze pagina gaat men automatisch naar de volgende pagina waarvan hieronder in figuur 2 de layout is weergegeven. Zowel op de binnenkomst pagina als op elke andere pagina is de zoekbalk terug te vinden, deze lichtblauw gekleurde balk bestaat uit 3 onderdelen. Om te zoeken is er een text-field, hierin kan men keywords typen om te zoeken. Tevens kan men specifieker zoeken door een categorie of zelfs categorie gecombineerd met een subcategorie te selecteren. De velden om deze selecties te maken zijn respectievelijk in figuur 3 en figuur 4 weergegeven. Als Wanna-have zijn de Recent Toegevoegde Advertenties en Recent Bekeken Advertenties modules toegevoegd aan speurplanet.nl. Links in figuur 5 is een weergave gegeven van de Recent Toegevoegde Advertenties module, nadat er door de gebruiker is gekeken naar advertenties ziet men het in figuur 5 rechts weergegeven Recent Bebeken Advertenties. Nadat men heeft gezocht op speurplanet.nl krijgt men een overzicht met de zoekresultaten. Hier kan men op een van de producten klikken om details van het des betreffende product te kunnen zien. Een weergave van zo n detail scherm is in figuur 6 gegeven. Uiteraard kan men ook als ingelogde gebruiker ook zijn/haar advertenties wijzigen. Hieronder in figuur 7 is een screenshot van het advertentie wijzigings scherm gegeven. Figuur 1: De binnenkomst pagina 9

10 5.3 Beheerders Interface De beheer omgeving van speurplanet.nl is zoals gewenst door de opdrachtgever zonder uitvoerige layout aangelevert. Hieronder in figuur 8 & 9 zijn twee voorbeelden van beheer interface screenshots gegeven. 5.4 Screenshots Figuur 2: De hoofdpagina 10

11 Figuur 3: Het dropdown menu voor het kiezen van de hoofdcategorie waarin men wil zoeken. Figuur 4: Het dropdown menu voor het kiezen van de subcategorie waarin men wil zoeken. Figuur 5: Recent Toegevoegde Advertenties (links) & Recent Bekeken Advertenties (rechts). 11

12 Figuur 6: Detail overzicht van een advertentie. 12

13 Figuur 7: Advertentie wijzigings scherm. Figuur 8: Beheerders functionaliteit overzicht. 13

14 Figuur 9: Beheerders pagina voor het aanmaken, verwijderen en wijzigen van categorieën. 14

15 6 Ontwerp 6.1 Inleiding In dit hoofdstuk wordt het ontwerp besproken en de problemen die tijdens de ontwerpfase optraden. Naar aanleiding van vergaderingen met de opdrachtgever zijn de requirements opgesteld. Deze requirements zijn verwerkt in 14 gebruikers use cases en 10 beheerders use cases. De use cases die tijdens de implementatie veranderd zijn, zijn terug te vinden in het paragraaf herzient ontwerp 7.6 in het hoofdstuk implementatie 7. De opgestelde requirement van de use cases waren als volgt: Gebruikers De gebruiker moet met behulp van een zoekfunctie alle advertenties kunnen vinden Gebruikers moeten een account kunnen aanmaken Kopers moeten een lijst met Recent Bekeken Advertenties kunnen zien Verkopers moeten een advertentie kunnen beheren (aanmaken/wijzigen) Kopers moeten contact op kunnen nemen met verkopers zonder dat hiervoor het adres van de verkoper bekendgemaakt hoeft te worden aan de koper Gebruikers moeten zich kunnen afmelden voor de reclame mailing Gebruikers moeten in en uit kunnen loggen Gebruikers moeten hun profiel kunnen wijzigen Gebruikers moeten hun account kunnen opzeggen Gebruikers moeten hun wachtwoord kunnen aanvragen indien ze die zijn vergeten Gebruikers moeten op een advertentie kunnen bieden Gebruikers moeten via mail op de hoogte worden gehouden van advertenties die zij zoeken Gebruikers moeten zich af kunnen melden van de mailing naar gezochte advertenties Admin/beheer Advertenties moeten kunnen worden verwijderd Categorieën moeten kunnen worden beheerd(aanmaken/wijzigen/verwijderen) Reclame s moeten naar alle gebruikers kunnen worden verstuurd Alle gegevens van de gebruikers moeten kunnen worden opgevraagd Admin accounts moeten door de superadmin kunnen worden beheerd(aanmaken/wijzigen/verwijderen) De PHP bron code van speurplanet.nl was volgens de opdrachtgever niet een goede basis voor de nieuwe website. Daarom werd besloten dat de website het best volledig opnieuw ontworpen en geïmplementeerd kon worden. De belangrijkste punten uit het ontwerp, het klassediagram, het database ontwerp en de sequence diagrammen zullen in dit hoofdstuk worden behandeld. Voor verdere uitwerking van het ontwerp is het RAD als bijlage aan dit document toegevoegd. 15

16 6.2 Klasse diagram De functionaliteit om gebruikers via op de hoogte te houden van hun zoekresultaten is komen te vervallen (zie ook 7.6.7). Hierdoor vervallen de volgende twee klassen: WrapperAdvertentie en ZoekFunctie. De klasse Admins is niet geïmplementeerd. Figuur 10: Klassendiagrammen 16

17 6.3 Database ontwerp Gebruiker De gebruikerstabel houdt de gegevens van een geregistreerde gebruiker bij. Naast de personalia van de gebruiker wordt er bijgehouden of de gebruiker zijn account geactiveerd heeft en of hij gebanned is. Bij het inloggen van een gebruiker zal hier op gecontroleerd worden. Gebruiker Voornaam Achternaam Wachtwoord Gebruikersnaam Straat Huisnummer Toevoeging Postcode Plaats Geboortejaar Geslacht Provincie Verbannen Geactiveerd type VARCHAR() VARCHAR() VARCHAR() VARCHAR() VARCHAR() SMALLINT() VARCHAR() VARCHAR() VARCHAR() SMALLINT() ENUM() VARCHAR() ENUM() BOOL BOOL Tabel 3: Gebruikerstabel Admin Van de beheerder worden de inloggegevens en rechten bijgehouden. Een superadmin is een beheerder met alle rechten, deze kan andere beheerders toevoegen, wijzigen en verwijderen. Tevens zijn er apparte rechten voor gebruikersbeheer, categoriebeheer en advertentiebeheer. Als er een nieuw beheerdersaccount gewenst is, kan de superadmin deze aanmaken en specificieren welke rechten hij toegedeeld krijgt. Gebruiker Wachtwoord Gebruikersnaam Rechten type VARCHAR() VARCHAR() VARCHAR() SET() Tabel 4: Beheerderstabel Advertenties Van een advertentie wordt naast de informatie voor het plaatsen van de advertentie ook de datum waarop hij is aangemaakt bijgehouden. Met deze datum kan uitgerekend worden wanneer de advertentie verloopt (Datetodie). Categorieën In tabel 6 worden alle records van de Categorieën weergegeven. 17

18 Advertentie Advertentienr Gebruikersnaam Omschrijving Plaatje Plaatsdatum Datetodie Categorie Subcategorie Telefoonnummer Titel Soort Prijs PrijsDouble type INT VARCHAR TEXT LONGBLOB DATE DATE VARCHAR VARCHAR INT VARCHAR ENUM( Aangeboden, Gezocht ) VARCHAR DOUBLE Tabel 5: Advertentietabel Categorieën Naam DefaultDatetodie Subcategorie type VARCHAR() DATE VARCHAR() Tabel 6: Categorieëntabel 6.4 Sequence diagrammen De sequence diagrammen die in dit hoofdstuk worden voldoen aan het UML sequence diagrammen standaard. Alle aanroepem van methodes worden op chronologische volgorde in de sequence diagrammen weergegeven. In figuur 11 wordt weergegeven hoe de admin naar alle gebruikers kan versturen. Dit sequence diagram is niet meer van toepassing omdat de admin alle adressen opvraagt om de reclam ing te versturen. Figuur 11: gebruikers en In figuur 12 wordt weergegeven hoe een superadmin een (super)admin kan toevoegen. 18

19 Figuur 12: voeg een admin toe In figuur 13 wordt weergegeven hoe een gebruiker een advertentie kan aanmaken. Figuur 13: voeg een advertentie toe In figuur 14 wordt weergegeven hoe een gebruiker een bod kan toevoegen. Figuur 14: voeg een bod toe In figuur 15 wordt weergegeven hoe een admin een subcategorie kan toevoegen. Figuur 15: voeg een subcategorie toe In figuur 16 wordt weergegeven hoe een gebruiker zijn profiel kan wijzigen. In figuur 17 wordt weergegeven hoe een gebruiker naar advertenties kan zoeken. 19

20 Figuur 16: wijzig gebruiker Figuur 17: zoek een advertentie 7 Implementatie 7.1 Inleiding Dit hoofdstuk zal de implementatiefase van het project behandelen. Ten eerste zullen de afspraken aangaande code layout besproken worden. Vervolgens zal in het kort een overzicht gegeven worden van gebruikte tools en software. De verdeling in subsystemen zal hierna besproken worden. De verdeling bestaat uit vijf subsystemen waarvan hier per subsysteem behandeld zal worden wat zij inhouden. In sectie 7.5 wordt kort de taakverdeling besproken gepaard met een tabel die hier over overzicht biedt. Tenslotte wordt gemotiveerd uitleg gegeven over alle ontwerp elementen die niet meer in de uiteindelijke versie zijn gekomen maar wel in het ontwerp stonden. 7.2 Code layout Packages worden benoemd naar het subsysteem wat zij omvatten. De benaming geschied aan de hand van de CamelCase conventie waarbij de eerste hoofdletter als klein geschreven wordt. Klassen worden vernoemd naar de functionaliteit die zij vervullen dan wel het data object wat zij voorstellen. De klassen worden aan de hand van de CamelCase conventie benoemd. Functies worden met keywords dan wel keyphrases benoemd. De functies worden aan de hand van de snake case conventie benoemd. Verder zal de code zich aan de volgende regels houden: Unit tests voor betrouwbaarheid en kwaliteit van de broncode. Code layout voor leesbaarheid. Om zo effciënt mogelijk met de code te kunnen werken worden de volgende regels voor de code layout voor PHP gehanteerd: Haakjes openen worden op dezelfde regel geplaatst als dat van de functie/methode. Geen spatie voor een komma één spatie na een komma. Geen spatie voor of na haakjes Zowel spaties voor als na operators met uitzondering voor argumenten voor functies/methoden waarbij geen spaties rondom operators worden gebruikt. Constanten volledig in hoofdletters. Functie/methode/variabele namen met snake case (snake case). Namen van klassen in camel case (CamelCase). 20

21 XAMPP Control Panel 2.3 Deze bevat het volgende: MySQL , PHP 5.1.4, phpmyadmin en Mercury Macromedia Studio MX 2004 FireWorks, Dreamweaver en FreeHand MXa Ruby Programmeertaal PHP Mailer Om s te versturen Simple Test Voor unit tests in php WindowsXP Operating system ConTEXT Tekst editor LaTeX Opmaaktaal HTML HyperText Markup Language CSS Stylesheets voor de website Tabel 7: Gebruikte Software Vier spaties voor indentatie. Kleine methoden/functies van maximaal 15 regels per methode/functie inclusief witruimte en commentaar. In uiterste gevallen 30 regels ook inclusief witruimte en commentaar. Dit voorkomt dat de code moeilijk te begrijpen of inflexibel wordt. 7.3 Gebruikte software Voor een server omgeving is er gebruik gemaakt van het opensource XAMPP pakket. Dit maakt het installeren van een PHP zeer eenvoudig en het pakket bevat tevens MySQL (voor de database), phpmyadmin om de database te beheren en Mercury, een SMTP server om s te verzenden. ***iets over Macromedia Studio*** Macromedia Studio MX 2004 is zowel als editor als grafisch tekenpakket benut. Ruby is een handige scriptaal die tijdens het project gebruikt is om taken te automatiseren die anders handigmatig uitgevoerd hadden moeten worden. Zoals het maken van backups of alle (sub)categorieën van speurplanet.nl om te zetten naar MySQL queries. Met PHP Mailer kan op een eenvoudige wijze s worden verstuurd vanuit de webserver. Tabel 7 geeft overzicht van de gebruikte software. 7.4 Verdeling in subsystemen Het systeem is onderverdeeld in vijf subsytemen. Eentje specifiek voor de beheerder, het beheersubsysteem. Dit subsysteem is verantwoordelijk voor het aanmaken en verwijderen van admins en het beheren van Categorieën. Ook zorgt het ervoor dat een beheerder advertenties van gebruikers kan verwijderen, hievoor heeft het een eigen zoekfunctie om advertenties te vinden. Tenslotte maakt het beheersubsysteem het mogelijk om gebruikers te verbannen (en verbanningen weer op te heffen) en gegevens van gebruikers op te vragen. Voor de gebruikerssubsysteem zijn er het gebruikersubsysteem en het aanbiedsubsysteem. Met het gebruikersybsyteem is het mogelijk om gebruikeraccounts aan te maken en te wijzigen. Het aanbiedsubsysteem is verantwoordelijk voor het aanmaken, tonen en verwijderen van advertenties. Het maakt het tevens mogelijk om op advertenties te bieden, advertenties te zoeken, Recent Bekeken Advertenties en recent toegevoegde advernties weer te geven. De beheerders en gebruikers maken beide gebruik van het inlogsubsysteem en het databasesubsysteem. Het inlogsubsysteem maakt het mogelijk dat de beheerder en de gebruiker kunnen inloggen. Beide partijen hebben hun eigen inlogfuncties. De wachtwoorden worden ongecodeerd in de database opgeslagen. Bij het inloggen worden de gebruikersnaam en wachtwoord gehashed in een cookie opgeslagen zodat deze niet kan worden uitgelezen. Het databasesubsysteem zorgt voor het beheer en de oplsag van de door alle subsystemen gebruikte data die opgeslagen is in de database. 21

22 7.5 Taakverdeling De planning van de implementatie was nog niet besloten voor de aanvang van de implementatiefase. De directoriestructuur was de eerste stap voor de implementatie. Daarna zijn de interfaces die gespecificeerd waren in het ODD geïmplementeerd in PHP. Vervolgens is de database aangemaakt, deze is zeer weinig gewijzigd tijdens de implementatie. Joost begon met het advertentiesubsysteem en Kenji met het gebruikersubsysteem. Vervolgens implementeerde Joost het inlogsubsysteem en Kenji maakte een begin aan het beheersubsysteem. Daarna maakte Kenji het gebruikers gedeelte af en Joost het admin gedeelte. Donald heeft het Recent Bekeken Advertenties, Recent Toegevoegde Advertenties, het bieden op advertenties en de gebruikers interface geïmplementeerd. Tijdens en na de implementatie hebben Joost en Kenji alle unit tests geïmplementeerd. Tabel 8 geeft de globale taakverdeling weer. User interface Implementatie Testen D. Krol D. Krol, J. Paalvast en K. Sihan J. Paalvast en K. Sihan Tabel 8: Taakverdeling 7.6 Herzient ontwerp Tijdens de implementatie van het ontwerp zijn in overleg met de opdrachtgever een aantal functies komen te vervallen en enkele toegevoegd. Hieronder worden deze genoemd gepaard met voor ieder een beknopte motivatie Gebruiker zoekt advertentie De gebruiker kan nu ook in Categorieën en subcategorieën zoeken. Als gebruikers alle artikelen willen vinden uit een bepaalde (sub)categorie dan kan dit nu ook. Dit geeft iets meer mogelijkheden aan de kopers om precies te kunnen vinden wat ze zoeken De gebruiker meldt zich af voor reclam ing De gebruiker kan zich niet direct afmelden voor de reclame mailing. Gebruikers die geen advertenties hebben geplaatst krijgen geen reclame mailing. Dus als een gebruiker al zijn advertenties verwijderd ontvangt hij ook geen reclam ing meer Koper houdt favorieten bij Het bijhouden van favorieten is vervangen door Recent Bekeken Advertenties (RBA). Bij RBA worden automatisch de laatst bekeken advertenties weergegeven. RBA bleek een goed alternatief te zijn voor het bijhouden van favorieten Admin mailt reclame rond De admin krijgt nu alleen een lijst met adressen te zien van gebruikers die op dat moment een geldige advertentie op speurplanet.nl hebben staan. Dit was de wens van de opdrachtever, deze wilde een lijst met alle adressen die hij gewoon kon kopiëren en plakken in zijn client Superadmin past admin aan Deze functionaliteit is niet geïmplementeerd. Hetzelfde kan worden bereikt door een admin te verwijderen en opnieuw toe te voegen. Volgens de opdrachtever was de extra functionaliteit niet meer noodzakelijk. 22

23 7.6.6 Gebruiker zegt account op Het opzeggen van een account is niet geïmplementeerd. In plaats hiervan kunnen gebruikers gewoon al hun advertenties verwijderen zodat ze geen reclam ing meer ontvangen Gebruiker moet via mail op de hoogte worden gehouden van de advertenties die zij zoeken (en afmelden) Deze functionaliteit is een Would-Have waar wij niet aan toe gekomen zijn. 8 Testen 8.1 Inleiding Voor het testen van Speurplanet is er gebruik gemaakt van unit testing. De tests zijn terug te vinden in de direcrory./unittesting. Voor het testen is gebruik gemaakt van het testing framework: SimpleTest [5]. In totaal zijn er 187 test uitgevoerd. Per test functie zal er met behulp van assert functies worden getest of de functie correct werkt. Een assert false functie geeft aan dat het geen fout bericht geeft, een assert true geeft aan dat het wel een foutmelding geeft. In hoofdstuk 8.6 staat een voorbeeld van een test case die van extra commentaar is voorzien. In de hoofdstukken 8.2 t/m 8.5 wordt hetzelfde principe gehanteerd alleen dan zonder extra commentaar en code. Sommige tests maken gebruik van een tijdelijk gegenereerde database root speurplanettest met de volgende entries: gebruiker VALUES ( tstvoornaam, tstachternaam, tstwachtwoord, tstgebruik, tststraat, 0, tst, tst, tst, 0, man, tst, Brabant, n, j ) beheer VALUES ( sa, sa, sa, superadmin,categorieen,advertenties,gebruikers ) beheer VALUES ( admin, admin, admin, categorieen,advertenties,gebruikers ) categorie VALUES ( Auto s ) categorie VALUES ( Antiek/Kunst ) subcategorie VALUES ( BMW, Auto s ) subcategorie VALUES ( Fiat, Auto s ) subcategorie VALUES ( Audi, Auto s ) subcategorie VALUES ( Schilderijen, Antiek/Kunst ) subcategorie VALUES ( Beelden, Antiek/Kunst ) De database zal nadat de tests uitgevoerd zijn weer worden gedumpt. zelf grondig testen m.b.v. vaste gebruikers. 8.2 Test Admin Inlog Moerstaal zal de website verder De test case Test Admin Inlog test of het inloggen van admins correct functioneert. De methode test check admin inlog() test of een admin succesvol kan inloggen wanneer het juiste gebruikersnaam wachtwoord wordt gebruikt. Deze methode test ook of een verkeerd gebruikersnaam/wachtwoord combinatie niet wordt geaccepteerd. De methode test get admin login() test of een admin die correct is ingelogd ook correct wordt herkent als een ingelogde admin. Als de admin niet correct is ingelogd dan mag die admin ook niet als ingelogd worden geaccepteerd. function test_check_admin_inlog() function test_get_admin_login() 8.3 Test Admin De test case Test Admin test de rechten van de admins en of de gegevens correct worden gecontroleerd voor het aanmaken van admins. De methode test rechten() test of de rechten van admins correct worden herkent door de bron code. De methode test correctheid gebruikersnaam(), test correctheid wachtwoord() 23

24 en test correctheid () testen of de juiste gebruikersnaam, wachtwoord en geaccepteerd worden. Zo is bijvoorbeeld het adres niet correct en mag dus niet geaccepteerd worden. function test_rechten() function test_correctheid_gebruikersnaam() function test_correctheid_wachtwoord() function test_correctheid_ () 8.4 Test Advertentie Maken De test case Test Advertentie Maken test of de gegevens correct worden gecontroleerd voor het aanmaken van advertenties. function test_titel() function test_soort() function test_prijs() function test_telefoon() function test_omschrijving() function test_dagen() 8.5 Test Account Maken De test case Test Account Maken test of de gegevens correct worden gecontroleerd voor het aanmaken van een account. function test_voornaam() function test_achternaam() function test_wachtwoord() function test_gebruikersnaam() function test_straat() function test_huisnummer() function test_toevoeging() function test_postcode() function test_plaats() function test_geboortejaar() function test_geslacht() function test_ () 8.6 Test Gebruiker Inlog In het bestand test gebruiker inlog.php worden de functies getest die controleren of de gebruiker ingelogd is. <?php include_once("../inlogsubsysteem/login_functies.php"); include_once("../databasesubsysteem/connectie.php"); include_once( simpletest/unit_tester.php ); include_once( simpletest/reporter.php ); include_once( dummy_db.php ); include_once("../databasesubsysteem/connectie.php"); set_test_db(); //stel de test database in open_db(); //open een verbinding naar deze test database mysql_query("create DATABASE root_speurplanettest"); //query de test database maak_dummy_db(); //creeer een test database vul_db(); //vul de test database sluit_db(); //sluit de verbinding naar de testdatabase af 24

25 //maak een klasse TestInloggen met als super klasse UnitTestCase class TestInloggen extends UnitTestCase{ function test_check_gebruiker_inlog(){ //testen met mininaal 1 waarde niet ingevuld $this->assert_false(check_gebruiker_inlog("", "")); $this->assert_false(check_gebruiker_inlog("fout", "")); $this->assert_false(check_gebruiker_inlog("", "fout")); $this->assert_false(check_gebruiker_inlog("", "tstwachtwoord")); //wachtwoord goed $this->assert_false(check_gebruiker_inlog("tstgebruik", "")); //gebruikersnaam goed } //overige testen //gebruikersnaam fout, wachtwoord fout $this->assert_false(check_gebruiker_inlog("fout", "fout")); //gebruikersnaam fout, wachtwoord goed $this->assert_false(check_gebruiker_inlog("fout", "tstwachtwoord")); //gebruikersnaam goed, wachtwoord fout $this->assert_false(check_gebruiker_inlog("tstgebruik", "tstgebruikersnaam")); //gebruikersnaam goed, wachtwoord goed $this->assert_true(check_gebruiker_inlog("tstgebruik", md5("tstgebruik"."tstwachtwoord"))); function test_get_login(){ //testen met mininaal 1 waarde niet ingevuld $this->assert_false(get_login("", "")); $this->assert_false(get_login("fout", "")); $this->assert_false(get_login("", "fout")); //gebruikersnaam goed $this->assert_false(get_login("tstgebruik", "")); $this->assert_false(get_login("", md5("tstgebruik"."tstwachtwoord"))); //hashcode goed } } //overige testen //gebruikersnaam fout, hashcode fout $this->assert_false(get_login("fout", "fout")); //gebruikersnaam fout, hashcode goed $this->assert_false(get_login("fout", md5("tstgebruik"."tstwachtwoord"))); //gebruikersnaam goed, hashcode fout $this->assert_false(get_login("tstgebruik", "fout")); //gebruikersnaam goed, hashcode goed $this->assert_true(get_login("tstgebruik", md5("tstgebruik"."tstwachtwoord"))); $test = &new TestInloggen(); $test->run(new HtmlReporter()); open_db(); delete_dummy_db(); sluit_db();?> //maak een nieuw object van TestInloggen //roep de methode run aan zodat de unit tests worden gestart //verwijder de test database 25

26 9 Conclusie en aanbevelingen Het resultaat van dit project is: een website, speurplanet.nl. De Must-Haves van de functionele requirements zijn geïmplementeerd. Ten opzichte van het oorspronkelijke ontwerp zijn enkele veranderingen doorgevoerd, zoals: de manier waarop reclame mailing wordt verstuurd, de favoriete lijst voor gebruikers en de manier waarop een gebruiker naar een advertentie zoekt. Deze verandering zijn in overleg met de opdrachtgever doorgevoerd. De implementatie is voor een groot deel object georiënteerd. Waardoor de implementatie makkelijker is aan te passen en eenduidiger wordt. Om nog meer structuur te bieden aan de implementatie is deze verdeeld in vijf subsystemen. Dit om de onderhoudbaarheid van het door ons aangeleverd systeem te verhogen. Er is altijd wel ruimte voor verbetering aan de huidige implementatie omdat de lage prioriteit requirements niet zijn geïmplementeerd. Eén van de eerste functionaliteiten die als aanbeveling nog geïmplementeerd kan worden is de Would-Have : auto complete. Deze is voornamelijk interessant omdat zeer weinig andere websites deze functie aanbieden. Dit zou een unique selling point voor speurplanet.nl kunnen zijn. 26

27 10 Defintities RAD: Requirement Analysis Document In dit document staan alle functionele, niet functionele eisen en systeem modellen. ODD: Object Design Document In het ODD staan de UML klassendiagrammen om inzicht te krijgen in het ontwerp van de website. Deze documentatie dient de implementatie weer te geven in een grafische vorm dat makkelijk te begrijpen is. SDD: System Design Document Het SDD beschrijft de ontwerp doelen. Unit tests: Een unit test is een procedure om een stuk code te valideren. [2] UML: Unified Modeling Language Specificatie taal om software te modeleren. PHP: Hypertext Preprocessor Is een server-side HTML embedded script taal. [4] (X)HTML: (extensible) HyperText Markup Language Is een client-side opmaak taal. LaTeX: LaTeX is een document voorbereidingssysteem voor hoge kwaliteit type setting. [1] MySQL: Database server die met SQL (Structured Query Language) werkt. [3] W3Schools: Voor de meeste SQL, CSS, PHP en HTML tutorials. [6] Referenties [1] An introduction to latex [2] Unit test [3] MySQL database server [4] The PHP Group. Php [5] SimpleTest [6] W3Schools

28 11 Requirements Analysis Document 11.1 Introductie Doel van het systeem Het ontwikkelen van een website, inclusief beheeromgeving, waar (tweede hands) producten via het internet te koop en verhandeld kunnen worden Cruciale succesfactoren De opdrachtgever moet minimaal één keer per week op locatie zijn en moet zoveel mogelijk via mail en mobiel beschikbaar zijn. De te creëren werkplek met drie bureaus en bureaustoelen, internetaansluiting en drie pc s moeten binnen twee weken gereed zijn voor gebruik Voorgesteld Systeem Functionele eisen Gebruikers De gebruiker moet met behulp van een zoekfunctie alle advertenties kunnen vinden Gebruikers moeten een account kunnen aanmaken Kopers moeten een lijst met Recent Bekeken Advertenties kunnen zien Verkopers moeten een advertentie kunnen beheren (aanmaken/wijzigen) Kopers moeten contact op kunnen nemen met verkopers zonder dat hiervoor het adres van de verkoper bekendgemaakt hoeft te worden aan de koper Gebruikers moeten zich kunnen afmelden voor de reclame mailing Gebruikers moeten in en uit kunnen loggen Gebruikers moeten hun profiel kunnen wijzigen Gebruikers moeten hun account kunnen opzeggen Gebruikers moeten hun wachtwoord kunnen aanvragen indien ze die zijn vergeten Gebruikers moeten op een advertentie kunnen bieden Gebruikers moeten via mail op de hoogte worden gehouden van advertenties die zij zoeken Gebruikers moeten zich af kunnen melden van de mailing naar gezochte advertenties Admin/beheer Advertenties moeten kunnen worden verwijderd Categorieën moeten kunnen worden beheerd(aanmaken/wijzigen/verwijderen) Reclame s moeten naar alle gebruikers kunnen worden verstuurd Alle gegevens van de gebruikers moeten kunnen worden opgevraagd Admin accounts moeten door de superadmin kunnen worden beheerd(aanmaken/wijzigen/verwijderen) 28

29 Niet-functionele eisen Documentatie RAD ODD SDD Code Documentatie (phpdocumentor) Testplan Gebruikers interface Het systeem wordt gebruikt door twee gebruikersgroepen namelijk: beheerders en gebruikers. Deze laatste groep gebruikers valt uiteen in kopers en verkopers. Prestatie karakteristieken De response tijd van de website zal rond de 7 seconden zijn. Deze responstijd is berekend op gebruik van een normale adsl verbinding met een download snelheid van circa 100kb/s. Foutafhandeling en extreme condities De gebruiker moet eenduidige feedback krijgen wanneer hij formulieren verkeerd invult. De up/downtime van het systeem zal niet anders zijn dan gebruikelijk voor webservices. Dit houdt in dat downtime voor maintenance s avonds zal zijn. Incidentele downtime zal maximaal beperkt worden. Kwaliteits punten De website zal aan het XHTML standaard voldoen zodat deze minimaal complete compatibiliteit met Microsoft Internet Explorer (vanaf v6.0) zal hebben. Systeem aanpassingen De momenteel beschikbare technische infrastructuur zal voorlopig voldoen om het systeem en het aantal verwachte gebruikers aan te kunnen. Mocht het systeem echter veel meer dan zijn geplande troughput ( advertenties) moeten verwerken dan zal een upgrade van zowel de hostende web als database server noodzakelijk zijn. Beveiliging De verkoper dient beveiligd te worden tegen het ontvangen van spam ten gevolge van het openbaar toonbaar maken van hun adres. Om dit te voorkomen zal initieel contact tussen koper en verkoper via ons systeem gaan. Hierbij krijgt de koper niet het echte adres van de verkoper maar zal hij een gegenereet adres krijgen waarnaar hij kan en. Het systeem stuurt dit vervolgens door naar het echte adres van de verkoper. Deze kan vervolgens reageren en zo krijgt de koper dan het echte adres van de verkoper. Hulpbronnen De database zal dagelijks gebackuped worden. Verantwoordelijk voor de uitvoer zijn de technische beheerders binnen de hosting afdeling van speurplanet.nl. Voor instalatie van het systeem zullen wij als ontwerpers verantwoordelijk zijn. Voor onderhoud aan het systeem dient Speuplanet.nl zelf menskracht te verzorgen. 29

30 11.3 Use Cases Gebruiker zoekt advertentie Gebruiker zoekt advertentie 1. Gebruiker vult één of meerdere trefwoorden in 2. Gebruiker klikt op zoek 3. Gebruiker krijgt lijst van advertenties te zien die zijn trefwoorden bevatten Preconditions Gebruiker mag niet gebanned zijn. Triggers Gebruiker gaat advertenties zoeken. Basic course of events 1, 2, 3 Alternative paths Geen advertenties zijn gevonden die voldoen aan de trefwoorden van de gebruiker. De gebruiker krijgt een melding te zien dat geen advertenties zijn gevonden. Postconditions De gebruiker krijgt een lijst met advertenties te zien of een melding waarin staat vermeld dat geen advertenties zijn gevonden. 30

31 Gebruiker maakt account aan Gebruiker maakt account aan 1. Gebruiker klikt op account aanmaken 2. Gebruiker vult zijn gegevens in: Voornaam Achternaam Wachtwoord (2x) Gebruikersnaam Straat Huisnummer Toevoeging Postcode Plaats Geboortejaar Geslacht (de gebruiker kan een adres van moerstaal.nl krijgen) Provincie 3. Gebruiker klikt op account aanmaken 4. Gebruiker activeert account met bevestigings Preconditions Gebruiker mag niet gebanned zijn. Triggers De gebruiker klikt de account aanmaak knop Basic course of events 1, 2, 3, 4 Alternative paths en/of gebruikersnaam bestaat al: de gebruiker gaat naar event 2 en krijgt een melding dat het en/of gebruikersnaam al bestaat Veld niet goed ingevuld: de gebruiker gaat naar event 2 en krijgt een melding dat welke velden niet goed ingevuld zijn Postconditions Een account is voor de gebruiker aangemaakt en een bevestigings is naar zijn adres gestuurd. 31

32 Koper houdt favorieten bij Koper houdt favorieten bij 1. De gebruiker klikt op de deze advertentie volgen knop bij de advertentie die hij wil volgen 2. De gebruiker klikt op de favorieten knop. 3. De gebruiker ziet nu een lijst met te volgen objecten 4. De gebruiker klikt op de deze advertentie verwijderen knop om het object weer uit zijn lijst te verwijderen Preconditions De gebruiker is ingelogd en niet gebanned. Triggers De gebruiker gaat een favoriet bijhouden Basic course of events 1, 2, 3, 4 Alternative paths n.v.t. Postconditions De verkoper heeft een lijst met te volgen objecten Verkoper maakt advertentie Verkoper maakt advertentie 1. De verkoper kiest de categorie uit een lijst 2. De verkoper kiest hoe lang hij zijn advertentie wil plaatsen 3. De verkoper vult eventueel een telefoonnummer in Preconditions De verkoper is ingelogd en mag niet gebanned zijn. Triggers De verkoper gaat een advertentie plaatsen. Basic course of events 1, 2, 3 Alternative paths De verkoper is een veld vergeten in te vullen. De pagina wordt opnieuw getoond met waarschuwing bij het veld die de verkoper vergeten is in te vullen. Postconditions De verkoper heeft een advertentie geplaatst. 32

33 Verkoper wijzigt advertentie Verkoper wijzigt advertentie 1. Verkoper klikt op advertentie wijzigen. 2. Verkoper wijzigt zijn advertentie. 3. Verkoper bevestigt zijn wijzigingen. Preconditions Verkoper moet ingelogd zijn. De advertentie moet door de verkoper zijn gemaakt. Triggers De verkoper klikt op advertentie wijzigen Basic course of events 1, 2, 3 Alternative paths De wijzigingen worden niet doorgevoerd omdat een veld incorrect is ingevoerd. De verkoper krijgt een melding te zien waarin staat vermeld waarom de wijzigingen niet doorgevoerd konden worden. Postconditions De wijzigingen voor de advertentie zijn doorgevoerd Koper neemt contact op met verkoper via Koper neemt contact op met verkoper via 1. De koper vult zijn adres in en klikt op verkoper en 2. De koper krijgt een tijdelijk gegenereerd adres 3. De koper verstuurt een naar dit gegenereerde adres 4. De verkoper ontvangt een van de koper met zijn echte adres Preconditions Triggers De gebruiker klikt de verkoper knop Basic course of events 1, 2, 3, 4 Alternative paths De koper vult een ongeldig adres in. Hij krijgt dan een foutmelding dat hij zijn adres verkeerd heeft ingevuld. Postconditions De verkoper heeft een van de koper met zijn echte adres ontvangen. 33

34 Gebruiker meldt zich af voor reclam ing Gebruiker meldt zich af voor reclam ing 1. De gebruiker klikt op de reclame mailing opzeggen link in zijn mail en wordt verwezen naar de site. 2. De gebruiker klikt op de reclame mailing opzeggen knop. 3. Alle advertenties van de gebruiker worden verwijderd. Preconditions De gebruiker heeft een reclame mailing ontvangen. Trigger De gebruiker gaat zijn reclame mailing opzeggen. Basic course of events 1, 2, 3 Alternative paths n.v.t. Postconditions De gebruiker is afgemeld voor de reclame mailing en al zijn geplaatste advertenties zijn verwijderd Gebruiker logt in Gebruiker logt in 1. De gebruiker voert zijn gebruikersnaam en wachtwoord in. 2. De gebruiker klikt op de login knop. Preconditions De gebruiker is niet gebanned. Triggers De gebruiker gaat inloggen. Basic course of events 1, 2 Alternative paths De gebruikersnaam of wachtwoord is onjuist. De gebruiker krijgt een melding te zien waarin staat dat gebruikersnaam of wachtwoord onjuist is. Hij krijgt de optie om deze gegevens toegestuurd te krijgen per wanneer hij zijn invoert. Wanneer het adres niet bestaat dan krijgt de gebruiker dit te zien in een melding. Postconditions De gebruiker is ingelogd De gebruiker logt uit De gebruiker logt uit 1. Gebruiker klikt op uitloggen. Preconditions De gebruiker moet ingelogd zijn. Triggers De gebruiker gaat uitloggen Basic course of events 1 Alternative paths n.v.t. Postconditions De gebruiker is uitgelogd. 34

35 Gebruiker zegt account op Gebruiker zegt account op 1. De gebruiker klikt op een verwijder dit account knop. 2. De gebruiker klikt op de bevestigen knop. 3. Alle advertenties van de gebruiker worden verwijderd. Preconditions De gebruiker is ingelogd. Trigger De gebruiker gaat zijn account opzeggen. Basic course of events 1, 2, 3 Alternative paths De gebruiker klikt op de annuleren knop. De gebruiker zijn account wordt niet opgezegd. Postconditions Het account en alle advertenties van de gebruiker worden verwijderd Gebruiker vraagt wachtwoord op Gebruiker vraagt wachtwoord op 1. De gebruiker klikt op de wachtwoord vergeten knop. 2. De gebruiker vult zijn adres in. 3. De gebruiker klikt op de stuur wachtwoord knop. Preconditions De gebruiker is niet gebanned. Triggers De gebruiker gaat zijn vergeten wachtwoord opvragen. Basic course of events 1, 2, 3 Alternative paths n.v.t. Postconditions De gebruiker heeft zijn wachtwoord via mail ontvangen Koper moeten op een advertentie kunnen bieden Koper moeten op een advertentie kunnen bieden 1. Koper vult een bod in een tekstveld in 2. Koper vult zijn adres in 3. Koper klikt op doe een bod knop Preconditions De gebruiker is niet gebanned. Triggers De koper gaat een bod doen. Basic course of events 1, 2, 3 Alternative paths n.v.t. Postconditions De koper zijn bod is geplaatst. 35

36 Gebruikers moeten via mail op de hoogte worden gehouden van advertenties die zij zoeken Gebruikers moeten via mail op de hoogte worden gehouden van advertenties die zij zoeken 1. De gebruiker vult zijn adres in 2. De gebruiker klikt sla zoek functie op Preconditions De gebruiker is niet gebanned, heeft naar advertenties gezocht en heeft een correct adres opgegeven. Triggers De gebruiker gaat een zoek functie opslaan. Basic course of events 1, 2 Alternative paths n.v.t. Postconditions De gebruiker wordt op de hoogte gehouden via of er nieuwe advertenties zijn geplaatst die aan zijn zoekfuntie voldoen Gebruikers moeten zich af kunnen melden van de mailing naar gezochte advertenties Gebruikers moeten zich af kunnen melden van de mailing naar gezochte advertenties 1. De gebruiker klikt op de link meld mij af van mailing naar gezochte advertenties in zijn Preconditions De gebruiker is aangemeld voor mailing naar gezochte advertenties. Triggers De gebruiker gaat zich aanmelden mailing naar gezochte advertenties. Basic course of events 1 Alternative paths n.v.t. Postconditions De gebruiker is afgemeld voor mailing naar gezochte advertenties Admin verwijdert advertentie Admin verwijdert advertentie 1. Admin klikt op advertentie verwijderen 2. Admin bevestigt advertentie verwijderen Preconditions Admin is ingelogd en heeft bevoegdheden om advertenties te verwijderen. Triggers Admin gaat een advertentie verwijderen. Basic course of events 1, 2 Alternative paths n.v.t. Postconditions De advertentie is verwijderd. 36

37 Admin verwijdert categorie Admin verwijdert categorie 1. Admin klikt op categorie verwijderen 2. Admin klikt op bevestigen Preconditions Admin is ingelogd en heeft de bevoegdheden om categorieën te verwijderen. Triggers Admin gaat categorie verwijderen. Basic course of events 1, 2 Alternative paths Admin klik op de annuleer knop. De categorie wordt niet verwijderd. Postconditions De categorie is verwijderd. Alle advertenties in de categorie zijn verplaatst naar overige Admin voegt hoofdcategorie toe Admin voegt hoofdcategorie toe 1. Admin klikt op nieuwe categorie toevoegen 2. Admin kiest nieuwe hoofdcategorie toevoegen 3. Admin vult naam nieuwe hoofdcategorie in Preconditions Admin is ingelogd en heeft bevoegdheden om categorieën toe te voegen. Triggers Admin gaat een hoofdcategorie toevoegen Basic course of events 1,2,3 Alternative paths n.v.t. Postconditions Er is een categorie toegevoegd Admin voegt subcategorie toe Admin voegt subcategorie toe 1. Admin klikt op nieuwe categorie toevoegen 2. Admin kiest nieuwe subcategorie toevoegen 3. Admin kiest bij welke hoofdcategorie de subcategorie gaat horen 4. Admin vult naam nieuwe subcategorie in Preconditions Admin is ingelogd en heeft bevoegdheden om categorieën toe te voegen. Triggers Admin gaat een subcategorie toevoegen Basic course of events 1,2,3,4 Alternative paths n.v.t. Postconditions Er is een subcategorie toegevoegd. 37

38 Admin past categorie aan Admin past categorie aan 1. Admin klikt op categorie aanpassen. 2. De admin kiest welke categorie hij wil aanpassen. 3. De admin verandert de naam van de gekozen categorie. Preconditions Admin is ingelogd en heeft bevoegdheden om categorieën aan te passen. Triggers Admin gaat de categorie aanpassen. Basic course of events 1, 2, 3 Alternative paths n.v.t. Postconditions De categorie is aangepast Admin mailt reclame rond Admin mailt reclame rond 1. Admin upload een bestand naar de server. 2. Admin klikt alle gebruikers mailen. Preconditions Admin is ingelogd en heeft de bevoegdheden om bestanden te uploaden en alle gebruikers te en. Triggers Admin gaat alle gebruikers en. Basic course of events 1, 2 Alternative paths n.v.t. Postconditions Alle gebruikers krijgen een die de admin naar de server had ge-upload. Alle s die niet aan zijn gekomen worden bijgehouden in een logboek Admin vraagt gegevens van alle gebruikers Admin vraagt gegevens van alle gebruikers 1. Admin klikt op gegevens gebruikers opvragen 2. Admin kiest welke gegevens hij van de gebruikers in de lijst wil zien 3. Admin klikt op exporteer gegevens naar lijst Preconditions Admin is ingelogd en heeft bevoegdheden om gegevens gebruikers op te vragen. Trigger De admin gaat gegevens opvragen van de gebruikers. Basic course of events 1, 2, 3 Alternative paths n.v.t. Postconditions Er is een lijst aangemaakt met de gegevens van de gebruikers. 38

39 Superadmin voegt admin toe Superadmin voegt admin toe 1. Superadmin klikt op nieuw admin account aanmaken. 2. Superadmin vult gegevens van de nieuwe admin in. 3. Superadmin klikt op bevestigen. Preconditions Superadmin is ingelogd. Triggers Superadmin gaat een nieuwe admin toevoegen. Basic course of events 1, 2, 3 Alternative paths Gegevens zijn niet goed ingevuld. De superadmin krijgt dan een foutmelding te zien en de keuze om deze gegevens alsnog goed in te vullen. Superadmin annuleert i.p.v. bevestigt. Er wordt geen nieuw admin account aangemaakt. Postconditions Een nieuw admin account is toegevoegd aan de database Superadmin past admin aan Superadmin past admin aan 1. Superadmin klikt op admin gegevens wijzigen 2. Superadmin past gegevens van de admin aan. 3. Superadmin klikt op bevestigen. Preconditions Superadmin is ingelogd. Triggers Superadmin gaat de gegevens van een admin aanpassen. Basic course of events 1, 2, 3 Alternative paths Gegevens zijn niet goed ingevuld. De superadmin krijgt dan een foutmelding te zien en de keuze om deze gegevens alsnog goed in te vullen. Superadmin annuleert i.p.v. bevestigt. De gegevens van de admin worden niet aangepast. Postconditions Admin account is aangepast. 39

40 Superadmin verwijdert admin Superadmin verwijdert admin 1. Admin klikt op admin lijst 2. Admin selecteert de admin die hij wil verwijderen 3. Admin klikt op verwijder admin Preconditions De superadmin is ingelogd. Triggers De superadmin gaat een admin verwijderen Basic course of events 1, 2, 3 Alternative paths n.v.t. Postconditions Admin is verwijderd. 40

41 Object model Figuur 18: Klassendiagrammen 41

42 Klassendiagram 11.4 Screen mockups Figuur 19: De gebruiker zijn advertenties 42

43 Figuur 20: De gebruiker zijn gegevens 43

44 Figuur 21: De zoekresultaten 44