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
1104241 1112007 1130331
Opdrachtgever: Begeleider:
R. Grahmbeek M. Kodde
Moerstaal Moerstaal
BSc Commisie:
Ir. F. Ververs Ir. B.R. Sodoyer
TU Delft TU Delft
1
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
Inhoudsopgave 1 Voorwoord
2
2 Inleiding 2.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Verslag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 5 5
3 Project Organisatie 3.1 Planning . . . . . . . . . . . 3.1.1 Originele planning . 3.1.2 Uiteindelijke verloop 3.2 Communicatie . . . . . . . . 3.3 Faciliteiten . . . . . . . . .
. . . . .
6 6 6 6 7 7
4 Probleemstelling en Analyse 4.1 Opdrachtformulering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Doelstelling project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 7 7 7
5 User Interface 5.1 Inleiding . . . . . . . 5.2 Gebruikers Interface 5.3 Beheerders Interface 5.4 Screenshots . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
9 9 9 10 10
6 Ontwerp 6.1 Inleiding . . . . . . . . 6.2 Klasse diagram . . . . 6.3 Database ontwerp . . . 6.3.1 Gebruiker . . . 6.3.2 Admin . . . . . 6.3.3 Advertenties . 6.4 Sequence diagrammen
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
15 15 16 17 17 17 17 18
7 Implementatie 7.1 Inleiding . . . . . . . . . . . . . . . . . 7.2 Code layout . . . . . . . . . . . . . . . 7.3 Gebruikte software . . . . . . . . . . . 7.4 Verdeling in subsystemen . . . . . . . 7.5 Taakverdeling . . . . . . . . . . . . . . 7.6 Herzient ontwerp . . . . . . . . . . . . 7.6.1 Gebruiker zoekt advertentie . . 7.6.2 De gebruiker meldt zich af voor 7.6.3 Koper houdt favorieten bij . . 7.6.4 Admin mailt reclame rond . . . 7.6.5 Superadmin past admin aan . . 7.6.6 Gebruiker zegt account op . . . 7.6.7 Gebruiker moet via mail op de zoeken (en afmelden) . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . reclamemailing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . hoogte worden . . . . . . . . .
3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . gehouden van de . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . advertenties die zij . . . . . . . . . . . .
20 20 20 21 21 22 22 22 22 22 22 22 23 23
8 Testen 8.1 Inleiding . . . . . . . . . 8.2 Test Admin Inlog . . . . 8.3 Test Admin . . . . . . . 8.4 Test Advertentie Maken 8.5 Test Account Maken . . 8.6 Test Gebruiker Inlog . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
23 23 23 23 24 24 24
9 Conclusie en aanbevelingen
26
10 Defintities
27
11 Requirements Analysis Document 28 11.1 Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1.1 Doel van het systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1.2 Cruciale succesfactoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.2 Voorgesteld Systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.2.1 Functionele eisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.2.2 Niet-functionele eisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.3 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.3.1 Gebruiker zoekt advertentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.3.2 Gebruiker maakt account aan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.3.3 Koper houdt favorieten bij . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 11.3.4 Verkoper maakt advertentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 11.3.5 Verkoper wijzigt advertentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 11.3.6 Koper neemt contact op met verkoper via email . . . . . . . . . . . . . . . . . . . . . . 33 11.3.7 Gebruiker meldt zich af voor reclamemailing . . . . . . . . . . . . . . . . . . . . . . . 34 11.3.8 Gebruiker logt in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 11.3.9 De gebruiker logt uit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 11.3.10 Gebruiker zegt account op . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 11.3.11 Gebruiker vraagt wachtwoord op . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 11.3.12 Koper moeten op een advertentie kunnen bieden . . . . . . . . . . . . . . . . . . . . . 35 11.3.13 Gebruikers moeten via mail op de hoogte worden gehouden van advertenties die zij zoeken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 11.3.14 Gebruikers moeten zich af kunnen melden van de mailing naar gezochte advertenties . 36 11.3.15 Admin verwijdert advertentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 11.3.16 Admin verwijdert categorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 11.3.17 Admin voegt hoofdcategorie toe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 11.3.18 Admin voegt subcategorie toe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 11.3.19 Admin past categorie aan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 11.3.20 Admin mailt reclame rond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 11.3.21 Admin vraagt gegevens van alle gebruikers . . . . . . . . . . . . . . . . . . . . . . . . 38 11.3.22 Superadmin voegt admin toe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 11.3.23 Superadmin past admin aan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 11.3.24 Superadmin verwijdert admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 11.4 Screen mockups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4
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 emailadressen, homepages en domeinnamen en D.M. Media is een op email 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
3
Project Organisatie
3.1 3.1.1
Planning Originele planning
Ontwerp: (3 weken) 1. RAD: Requirements Analysis Document 2. SDD: System Design Document 3. ODD: Object Design Document
onderdeelnr. 1 2 3 4 5 6 7 8 9 10 11 12 13
beheer/gebruiker
Gebruiker Beheerder Gebruiker Beheerder Gebruiker Beheerder Gebruiker Beheerder Beheerder
Tabel 1: Implementatietabel implementatie beschrijving Database Ontwerp Database + zoekfunctie en een pagina die alleen de inhoud van de database weergeeft Account aanmaak/beheersysteem Accountbeheer (hierin kunnen ook admin-accounts aangemaakt worden) Login-gedeelte van de shop Login-gedeelte van de shop Advertentie beheer/aanmaak systeem Advertentie beheer systeem Winkelwagen beheer Information Extraction System (zowel op account als advertenties) Commercial Mailing System Grafische User Interface voor zowel front- als back-end. 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. 3.1.2
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
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 email. 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 4.1
Probleemstelling en Analyse 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¨en 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¨en als in subCategorie¨en 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 emailadres opgeven. De geldigheid van dit emailadres wordt gecontroleerd door een verificatie email die verstuurd wordt naar het 7
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 emailadres 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
5 5.1
User Interface 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¨eren om zodoende het gebruikersgemak te bevorderen. Door het gebruik van kleurvlakken is herkenbaarheid en ori¨entatie 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 http://www.speurplanet.nl 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
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
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
Figuur 6: Detail overzicht van een advertentie.
12
Figuur 7: Advertentie wijzigings scherm.
Figuur 8: Beheerders functionaliteit overzicht.
13
Figuur 9: Beheerders pagina voor het aanmaken, verwijderen en wijzigen van categorie¨en.
14
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 emailadres 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¨en moeten kunnen worden beheerd(aanmaken/wijzigen/verwijderen) • Reclame emails 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
6.2
Klasse diagram
De functionaliteit om gebruikers via email 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
6.3 6.3.1
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 EMail Provincie Verbannen Geactiveerd
type VARCHAR() VARCHAR() VARCHAR() VARCHAR() VARCHAR() SMALLINT() VARCHAR() VARCHAR() VARCHAR() SMALLINT() ENUM() VARCHAR() ENUM() BOOL BOOL
Tabel 3: Gebruikerstabel
6.3.2
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 EMail Rechten
type VARCHAR() VARCHAR() VARCHAR() SET()
Tabel 4: Beheerderstabel
6.3.3
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¨ en In tabel 6 worden alle records van de Categorie¨en weergegeven.
17
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¨ en Naam DefaultDatetodie Subcategorie
type VARCHAR() DATE VARCHAR()
Tabel 6: Categorie¨entabel
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 email kan versturen. Dit sequence diagram is niet meer van toepassing omdat de admin alle emailadressen opvraagt om de reclamemailing te versturen.
Figuur 11: gebruikers emailen In figuur 12 wordt weergegeven hoe een superadmin een (super)admin kan toevoegen.
18
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
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¨ent 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 ´e´en 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
XAMPP Control Panel 2.3 Macromedia Studio MX 2004 Ruby PHP Mailer Simple Test WindowsXP ConTEXT LaTeX HTML CSS
Deze bevat het volgende: MySQL - 5.0.21, PHP 5.1.4, phpMyAdmin - 2.8.1 en Mercury FireWorks, Dreamweaver en FreeHand MXa Programmeertaal Om emails te versturen Voor unit tests in php Operating system Tekst editor Opmaaktaal HyperText Markup Language 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 emails 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¨en van speurplanet.nl om te zetten naar MySQL queries. Met PHP Mailer kan op een eenvoudige wijze emails 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¨en. 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
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. 7.6.1
Gebruiker zoekt advertentie
De gebruiker kan nu ook in Categorie¨en en subCategorie¨en 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. 7.6.2
De gebruiker meldt zich af voor reclamemailing
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 reclamemailing meer. 7.6.3
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. 7.6.4
Admin mailt reclame rond
De admin krijgt nu alleen een lijst met emailadressen 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¨eren en plakken in zijn email client. 7.6.5
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
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 reclamemailing meer ontvangen. 7.6.7
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 8.1
Testen 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. Moerstaal zal de website verder zelf grondig testen m.b.v. vaste gebruikers.
8.2
Test Admin Inlog
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
en test correctheid email() testen of de juiste gebruikersnaam, wachtwoord en email geaccepteerd worden. Zo is bijvoorbeeld het email adres ‘
[email protected]’ niet correct en mag dus niet geaccepteerd worden. function function function function
8.4
test_rechten() test_correctheid_gebruikersnaam() test_correctheid_wachtwoord() test_correctheid_email()
Test Advertentie Maken
De test case ‘Test Advertentie Maken’ test of de gegevens correct worden gecontroleerd voor het aanmaken van advertenties. function function function function function function
8.5
test_titel() test_soort() test_prijs() test_telefoon() test_omschrijving() test_dagen()
Test Account Maken
De test case ‘Test Account Maken’ test of de gegevens correct worden gecontroleerd voor het aanmaken van een account. function function function function function function function function function function function function
8.6
test_voornaam() test_achternaam() test_wachtwoord() test_gebruikersnaam() test_straat() test_huisnummer() test_toevoeging() test_postcode() test_plaats() test_geboortejaar() test_geslacht() test_email()
Test Gebruiker Inlog
In het bestand test gebruiker inlog.php worden de functies getest die controleren of de gebruiker ingelogd is.
//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
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¨enteerd. 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´en 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
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. http://www.latex-project.org/intro.html, 2006. [2] Unit test. http://en.wikipedia.org/wiki/Unit_test, 2006. [3] MySQL database server. http://www.mysql.com/, 2006. [4] The PHP Group. Php. http://www.php.net, 2006. [5] SimpleTest. http://www.lastcraft.com/simple_test.php, 2006. [6] W3Schools. http://www.w3schools.com/, 2006.
27
11 11.1 11.1.1
Requirements Analysis Document 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. 11.1.2
Cruciale succesfactoren
• De opdrachtgever moet minimaal ´e´en keer per week op locatie zijn en moet zoveel mogelijk via mail en mobiel beschikbaar zijn. • De te cre¨eren werkplek met drie bureaus en bureaustoelen, internetaansluiting en drie pc’s moeten binnen twee weken gereed zijn voor gebruik.
11.2 11.2.1
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 emailadres 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¨en moeten kunnen worden beheerd(aanmaken/wijzigen/verwijderen) • Reclame emails 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
11.2.2
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 (15 000 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 email adres. Om dit te voorkomen zal initieel email contact tussen koper en verkoper via ons systeem gaan. Hierbij krijgt de koper niet het echte email adres van de verkoper maar zal hij een gegenereet email adres krijgen waarnaar hij kan emailen. Het systeem stuurt dit vervolgens door naar het echte email adres van de verkoper. Deze kan vervolgens reageren en zo krijgt de koper dan het echte email 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
11.3 11.3.1
Use Cases Gebruiker zoekt advertentie Gebruiker zoekt advertentie
Iteration Summary 1. Gebruiker vult ´e´en of meerdere trefwoorden in 2. Gebruiker klikt op zoek 3. Gebruiker krijgt lijst van advertenties te zien die zijn trefwoorden bevatten Preconditions Triggers Basic course of events Alternative paths
Gebruiker mag niet gebanned zijn. Gebruiker gaat advertenties zoeken. 1, 2, 3 • 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
11.3.2
Gebruiker maakt account aan Gebruiker maakt account aan
Iteration Summary 1. Gebruiker klikt op account aanmaken 2. Gebruiker vult zijn gegevens in: • Voornaam • Achternaam • Wachtwoord (2x) • Gebruikersnaam • Straat • Huisnummer • Toevoeging • Postcode • Plaats • Geboortejaar • Geslacht • Email (de gebruiker kan een email adres van moerstaal.nl krijgen) • Provincie 3. Gebruiker klikt op account aanmaken 4. Gebruiker activeert account met bevestigingsemail Preconditions Triggers Basic course of events Alternative paths
Gebruiker mag niet gebanned zijn. De gebruiker klikt de account aanmaak knop 1, 2, 3, 4 • Email en/of gebruikersnaam bestaat al: de gebruiker gaat naar event 2 en krijgt een melding dat het email 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 email is naar zijn emailadres gestuurd.
31
11.3.3
Koper houdt favorieten bij Koper houdt favorieten bij
Iteration Summary 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 Triggers Basic course of events Alternative paths Postconditions 11.3.4
De gebruiker is ingelogd en niet gebanned. De gebruiker gaat een favoriet bijhouden 1, 2, 3, 4 n.v.t. De verkoper heeft een lijst met te volgen objecten.
Verkoper maakt advertentie Verkoper maakt advertentie
Iteration Summary 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 Triggers Basic course of events Alternative paths
De verkoper is ingelogd en mag niet gebanned zijn. De verkoper gaat een advertentie plaatsen. 1, 2, 3 • 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
11.3.5
Verkoper wijzigt advertentie Verkoper wijzigt advertentie
Iteration Summary 1. Verkoper klikt op advertentie wijzigen. 2. Verkoper wijzigt zijn advertentie. 3. Verkoper bevestigt zijn wijzigingen. Preconditions Triggers Basic course of events Alternative paths
Verkoper moet ingelogd zijn. De advertentie moet door de verkoper zijn gemaakt. De verkoper klikt op advertentie wijzigen 1, 2, 3 • 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 11.3.6
De wijzigingen voor de advertentie zijn doorgevoerd.
Koper neemt contact op met verkoper via email Koper neemt contact op met verkoper via email
Iteration Summary 1. De koper vult zijn email adres in en klikt op verkoper emailen 2. De koper krijgt een tijdelijk gegenereerd email adres 3. De koper verstuurt een email naar dit gegenereerde email adres 4. De verkoper ontvangt een email van de koper met zijn echte email adres Preconditions Triggers Basic course of events Alternative paths
De gebruiker klikt de verkoper email knop 1, 2, 3, 4 • De koper vult een ongeldig email adres in. Hij krijgt dan een foutmelding dat hij zijn email adres verkeerd heeft ingevuld.
Postconditions
De verkoper heeft een email van de koper met zijn echte email adres ontvangen.
33
11.3.7
Gebruiker meldt zich af voor reclamemailing Gebruiker meldt zich af voor reclamemailing
Iteration Summary 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 Trigger Basic course of events Alternative paths Postconditions
11.3.8
De gebruiker heeft een reclame mailing ontvangen. De gebruiker gaat zijn reclame mailing opzeggen. 1, 2, 3 n.v.t. De gebruiker is afgemeld voor de reclame mailing en al zijn geplaatste advertenties zijn verwijderd.
Gebruiker logt in Gebruiker logt in
Iteration Summary 1. De gebruiker voert zijn gebruikersnaam en wachtwoord in. 2. De gebruiker klikt op de “login” knop. Preconditions Triggers Basic course of events Alternative paths
De gebruiker is niet gebanned. De gebruiker gaat inloggen. 1, 2 • 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 email wanneer hij zijn email invoert. Wanneer het email adres niet bestaat dan krijgt de gebruiker dit te zien in een melding.
Postconditions 11.3.9
De gebruiker is ingelogd.
De gebruiker logt uit De gebruiker logt uit
Iteration Summary 1. Gebruiker klikt op uitloggen. Preconditions Triggers Basic course of events Alternative paths Postconditions
De gebruiker moet ingelogd zijn. De gebruiker gaat uitloggen 1 n.v.t. De gebruiker is uitgelogd.
34
11.3.10
Gebruiker zegt account op Gebruiker zegt account op
Iteration Summary 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 Trigger Basic course of events Alternative paths Postconditions 11.3.11
De gebruiker is ingelogd. De gebruiker gaat zijn account opzeggen. 1, 2, 3 De gebruiker klikt op de “annuleren” knop. De gebruiker zijn account wordt niet opgezegd. Het account en alle advertenties van de gebruiker worden verwijderd.
Gebruiker vraagt wachtwoord op Gebruiker vraagt wachtwoord op
Iteration Summary 1. De gebruiker klikt op de “wachtwoord vergeten” knop. 2. De gebruiker vult zijn email adres in. 3. De gebruiker klikt op de “stuur wachtwoord” knop. Preconditions Triggers Basic course of events Alternative paths Postconditions 11.3.12
De gebruiker is niet gebanned. De gebruiker gaat zijn vergeten wachtwoord opvragen. 1, 2, 3 n.v.t. De gebruiker heeft zijn wachtwoord via mail ontvangen.
Koper moeten op een advertentie kunnen bieden Koper moeten op een advertentie kunnen bieden
Iteration Summary 1. Koper vult een bod in een tekstveld in 2. Koper vult zijn email adres in 3. Koper klikt op “doe een bod” knop Preconditions Triggers Basic course of events Alternative paths Postconditions
De gebruiker is niet gebanned. De koper gaat een bod doen. 1, 2, 3 n.v.t. De koper zijn bod is geplaatst.
35
11.3.13
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 Iteration Summary 1. De gebruiker vult zijn email adres in 2. De gebruiker klikt “sla zoek functie op” Preconditions Triggers Basic course of events Alternative paths Postconditions
11.3.14
De gebruiker is niet gebanned, heeft naar advertenties gezocht en heeft een correct email adres opgegeven. De gebruiker gaat een zoek functie opslaan. 1, 2 n.v.t. De gebruiker wordt op de hoogte gehouden via email 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 Iteration Summary 1. De gebruiker klikt op de link “meld mij af van mailing naar gezochte advertenties” in zijn email Preconditions Triggers Basic course of events Alternative paths Postconditions 11.3.15
De gebruiker is aangemeld voor mailing naar gezochte advertenties. De gebruiker gaat zich aanmelden mailing naar gezochte advertenties. 1 n.v.t. De gebruiker is afgemeld voor mailing naar gezochte advertenties.
Admin verwijdert advertentie Admin verwijdert advertentie
Iteration Summary 1. Admin klikt op advertentie verwijderen 2. Admin bevestigt advertentie verwijderen Preconditions Triggers Basic course of events Alternative paths Postconditions
Admin is ingelogd en heeft bevoegdheden om advertenties te verwijderen. Admin gaat een advertentie verwijderen. 1, 2 n.v.t. De advertentie is verwijderd.
36
11.3.16
Admin verwijdert categorie Admin verwijdert categorie
Iteration Summary 1. Admin klikt op categorie verwijderen 2. Admin klikt op bevestigen Preconditions Triggers Basic course of events Alternative paths Postconditions
11.3.17
Admin is ingelogd en heeft de bevoegdheden om categorie¨en te verwijderen. Admin gaat categorie verwijderen. 1, 2 Admin klik op de “annuleer” knop. De categorie wordt niet verwijderd. De categorie is verwijderd. Alle advertenties in de categorie zijn verplaatst naar overige.
Admin voegt hoofdcategorie toe Admin voegt hoofdcategorie toe
Iteration Summary 1. Admin klikt op nieuwe categorie toevoegen 2. Admin kiest nieuwe hoofdcategorie toevoegen 3. Admin vult naam nieuwe hoofdcategorie in Preconditions Triggers Basic course of events Alternative paths Postconditions 11.3.18
Admin is ingelogd en heeft bevoegdheden om categorie¨en toe te voegen. Admin gaat een hoofdcategorie toevoegen 1,2,3 n.v.t. Er is een categorie toegevoegd.
Admin voegt subcategorie toe Admin voegt subcategorie toe
Iteration Summary 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 Triggers Basic course of events Alternative paths Postconditions
Admin is ingelogd en heeft bevoegdheden om categorie¨en toe te voegen. Admin gaat een subcategorie toevoegen 1,2,3,4 n.v.t. Er is een subcategorie toegevoegd.
37
11.3.19
Admin past categorie aan Admin past categorie aan
Iteration Summary 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 Triggers Basic course of events Alternative paths Postconditions 11.3.20
Admin is ingelogd en heeft bevoegdheden om categorie¨en aan te passen. Admin gaat de categorie aanpassen. 1, 2, 3 n.v.t. De categorie is aangepast.
Admin mailt reclame rond Admin mailt reclame rond
Iteration Summary 1. Admin ’upload’ een email bestand naar de server. 2. Admin klikt alle gebruikers mailen. Preconditions Triggers Basic course of events Alternative paths Postconditions
11.3.21
Admin is ingelogd en heeft de bevoegdheden om bestanden te uploaden en alle gebruikers te emailen. Admin gaat alle gebruikers emailen. 1, 2 n.v.t. Alle gebruikers krijgen een email die de admin naar de server had ge-upload. Alle emails die niet aan zijn gekomen worden bijgehouden in een logboek.
Admin vraagt gegevens van alle gebruikers Admin vraagt gegevens van alle gebruikers
Iteration Summary 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 Trigger Basic course of events Alternative paths Postconditions
Admin is ingelogd en heeft bevoegdheden om gegevens gebruikers op te vragen. De admin gaat gegevens opvragen van de gebruikers. 1, 2, 3 n.v.t. Er is een lijst aangemaakt met de gegevens van de gebruikers.
38
11.3.22
Superadmin voegt admin toe Superadmin voegt admin toe
Iteration Summary 1. Superadmin klikt op nieuw admin account aanmaken. 2. Superadmin vult gegevens van de nieuwe admin in. 3. Superadmin klikt op bevestigen. Preconditions Triggers Basic course of events Alternative paths
Superadmin is ingelogd. Superadmin gaat een nieuwe admin toevoegen. 1, 2, 3 • 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 11.3.23
Een nieuw admin account is toegevoegd aan de database.
Superadmin past admin aan Superadmin past admin aan
Iteration Summary 1. Superadmin klikt op “admin gegevens wijzigen” 2. Superadmin past gegevens van de admin aan. 3. Superadmin klikt op bevestigen. Preconditions Triggers Basic course of events Alternative paths
Superadmin is ingelogd. Superadmin gaat de gegevens van een admin aanpassen. 1, 2, 3 • 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
11.3.24
Superadmin verwijdert admin Superadmin verwijdert admin
Iteration Summary 1. Admin klikt op admin lijst 2. Admin selecteert de admin die hij wil verwijderen 3. Admin klikt op “verwijder admin” Preconditions Triggers Basic course of events Alternative paths Postconditions
De superadmin is ingelogd. De superadmin gaat een admin verwijderen 1, 2, 3 n.v.t. Admin is verwijderd.
40
Object model
Figuur 18: Klassendiagrammen
41
Klassendiagram
11.4
Screen mockups
Figuur 19: De gebruiker zijn advertenties
42
Figuur 20: De gebruiker zijn gegevens
43
Figuur 21: De zoekresultaten
44
