Vakoverschrijdend Eindproject

Vakoverschrijdend Eindproject 2009-2010

Doelstelling In team ontwerpen, realiseren, demonstreren en presenteren van een volwaardige gedistribueerde applicatie met een databank, een web- en een desktop-interface, waarbij gebruik gemaakt wordt van de aangeleerde ontwerp- en programmeertechnieken uit de verschillende opleidingsonderdelen.

Groepen en onderwerpen De teams werden op voorhand samengesteld. De groepsindeling wordt ad valvas bekendgemaakt. Elk team moet een onderwerp kiezen en een projectvoorstel maken. Dat is een korte tekst waarin de grote lijnen van het project uitgezet worden. Dat projectvoorstel moet aan bepaalde vereisten voldoen (zie verder), en moet door de docenten goedgekeurd worden. Eens je projectvoorstel goedgekeurd spelen de docenten de rol van klanten. En uiteraard is het de bedoeling om software af te leveren die de klant tevreden stemt. De ontwikkeling zal in verschillende fases gebeuren. Na elke fase worden documenten en/of software afgeleverd, eventueel gepaard met deployment op de klas-pc's, testen door docenten of medestudenten, demonstratie en/of presentatie. Zie planning.

Inhoudelijke vereisten Centraal in het project moet er een relationele databank gebruikt worden die voldoende complex is en die een grote hoeveelheid realistische gegevens bevat. Die gegevens moeten (gedeeltelijk) van het internet gehaald worden ("web scraping"). De gebruikersinterface moet uit twee gedeelten bestaan: een klassieke desktopapplicatie (GUI) en een webapplicatie (voor de technologische vereisten: zie verder). Bv. in bibliotheeksysteem kan de administratie gebeuren via een desktopapplicatie en krijgen de klanten (gedeeltelijke) toegang via een webapplicatie. Of omgekeerd: een multiplayer game als desktopapplicatie met admin via een webapplicatie. Probeer als academische bachelors het niveau van de klassieke "webshop"-applicatie te overstijgen. Dat kan bv. door • Niet-triviale algoritmen (zoeken, planning, artificiële intelligentie, ...)

• • • • •

Randapparaten zoals barcodelezer, touch-screen, eID-lezer, sensoren, GSM, zelfs PDA. Fraaie grafische vormgeving Kwaliteit van ontwerp en code met het oog op robuustheid, performantie en flexibiliteit. Generieke oplossingen, bv. customizable app, eigen ORM, auto-generated CRUD... XML-technologie bv. voor configuratie

Het klassenmodel moet minstens een N-op-N-relatie en overerving bevatten. De applicatie moet zorgen voor authenticatie en authorisatie van gebruikers. Er moeten verschillende gebruikersniveaus of rollen zijn (bv. admin, klant, bezoeker). Verzamel op het WWW zo veel mogelijk data waarmee de databank initieel kan opgevuld worden. Sla deze data op in diverse lokale bestanden, in HTML- of XML-formaat. Hoe je dit doet, manueel of geautomatiseerd, maakt niet uit. Ontwikkel vervolgens Perl-scripts om de relevante gegevens uit de databestanden te extraheren en te converteren in verzamelingen insertopdrachten. Voer deze insert-opdrachten tenslotte effectief uit. De applicatie moet goed gestructureerd worden, in aparte "lagen" (tiers). Meestal maakt men een onderscheid tussen datalaag, logicalaag (business logic) en presentatielaag (UI). De losse koppeling tussen de lagen moet het relatief makkelijk maken om bv. het databanksysteem te wijzigen of een interface voor mobiele toestellen te ontwikkelen. Het debuggen van een webapplicatie is niet makkelijk, en vaak tijdrovend. Zorg ervoor dat de lagen (min of meer) apart kunnen getest worden. Dat kan bv. d.m.v. • • • •

een dummy-datalaag zonder databank console-applicatie(s) voor het testen van de datalaag console-applicatie(s) voor het testen van de logicalaag scripts om de databank te initialiseren (tabellen, essentiële data) en om de databank op te vullen met testgegevens of met werkelijke gegevens • scripts die bepaalde testscenario's uitvoeren alle activiteiten • te loggen naar de databank of naar een bestand (of naar het scherm) Het gebruik van design-patterns zoals Model-View-Controller (MVC) is sterk aan te raden. Zorg er bij het logisch ontwerp van de databank voor dat ten minste één kolom van ten minste één tabel redundante (niet-genormaliseerde) informatie bevat, die op basis van gegevens, onder meer uit andere tabellen , kan berekend worden. Laat je bij de keuze van deze nietgenormaliseerde kolom (of kolommen) bij voorkeur leiden door het optimaliseren van de performantie van bepaalde select-opdrachten. Zorg er voor dat de inhoud van de cellen in een dergelijke niet-genormaliseerde kolom automatisch gecorrigeerd wordt bij het wijzigen, toevoegen of verwijderen van gegevens waarvan deze kolom afhankelijk is. Gebruik hiervoor verplicht after triggers . Leg bij het logisch ontwerp van de databank minstens één beperkingsregel (bijvoorbeeld een cardinaliteitsvoorwaarde) op aan gegevens uit diverse tabellen , die complexer is dan louter

referentiële integriteit. Dwing deze beperkingsregel automatisch af bij het wijzigen, toevoegen of verwijderen van gegevens door before triggers te definiëren.

Technologische vereisten Met het oog op een betere begeleiding zijn een aantal technologische keuzes vastgelegd: • Databank ◦ in Oracle ◦ prototype mag met ander RDBMS • Webapplicatie ◦ ASP.NET en IIS ◦ ADO.NET ◦ C# of VB.NET • Desktopapplicatie ◦ Java Swing ◦ JDBC Het gebruik van een object-relational-mapper is niet toegelaten (maar je mag er wel zelf een ontwikkelen). Voor logging kun je log4j of log4net gebruiken. Indien gewenst kun je ook gebruik maken van netwerkprogrammering met sockets, remoting of RMI. Ook JavaScript, AJAX, Flex en Silverlight zijn eventueel mogelijk. Wie met hardware-componenten aan de slag gaat mag uiteraard de gepaste driversoftware gebruiken. Voor het gebruik van andere libraries of frameworks moet toestemming gevraagd worden.

Logboek Elke student wordt verwacht om minimum 175 uren aan het project te spenderen. Hiervoor houdt elke student individueel een logboek bij van zijn activiteiten. Zorg er voor dat de gegevens als volgt vermeld worden: datumbeginuureinduur 13/3/ 8u30 09 15/3/ 10u 09

aantal uur

gedetailleerde omschrijving van je activiteit

10u

1.5

Implementatie van de loginprocedure voor de beheerder + oplossen van fout bij lege login

18u

8

Debugging

Totaal aantal uren:

9,5

In de eerste rij is de omschrijving voldoende gedetailleerd, in de tweede rij echter niet. Dergelijke ongedetailleerde omschrijvingen worden niet aanvaard en hebben uiteraard consequenties voor je eindbeoordeling. De logboeken moeten steeds up-to-date zijn en online raadpleegbaar; zie verder.

Projectbeheer Voor het projectbeheer maken we gebruik van enkele Google-tools. 1. Elk team moet een (private) discussiegroep maken op groups.google.com. Stuur een uitnodiging naar [email protected]. Deze discussiegroep kun je uiteraard gebruiken voor allerlei discussies binnen het team, je kunt er bestanden in opslaan enz., maar hij dient ook voor de communicatie van de docenten naar de groep, via het unieke e-mailadres van de groep. 2. Iedereen moet individueel een logboek bijhouden als Google-spreadsheet op docs.google.com. Plaats de links naar deze logboeken op de openingspagina van je discussiegroep. 3. Start een Google code open source project op code.google.com/projecthosting. Hier krijg je • • • •

Subversion (SVN) voor de code (versiebeheer, sharing) Wiki: analyse, handleidingen Issue tracking: bug reports, feature requests Download van releases

Plaats een link naar je code project op de openingspagina van je discussiegroep. Opm. indien gewenst kun je ook Google calendar of andere project tools gebruiken...

Analyse en ontwerp Gebruik UML tools. Streef naar "living documents", d.w.z. dat analyse- en ontwerpdocumentatie aangepast wordt in de loop van het project. Behoefte-analyse • Originele projectnaam • Tekstuele voorstelling van het project (max. 1 blz) Vermeld eventuele opties of uitbreidingen!

• • • •

Actoren Overzicht van de fysieke architectuur (computers, netwerk) Schetsen van de user interface Databronnen voor het scrapen

Functionele analyse • Klassendiagram / ERD / Databankschema • Use cases / Scenario's • Eventueel interactiediagrammen Per iteratie: • Analyse, ontwerp, implementatie, testen

Planning De twaalf beschikbare weken worden ingedeeld in verschillende fazen: a. Tegen wo 10 febr: behoefte-analyse b. Tegen vr 19 febr.: analyse => analysedocument c. Tegen di 23 maart: 1e iteratie (α-versie) => prototype - demo d. Tegen 20 april: 2e iteratie (β-versie) => deployment - handleiding - peer testing e. Tegen 18 mei: 3e iteratie (release)=> deployment, installer, testing, presentatie

Tegen wo 10 februari • • • • • •

Voorstel en projectnaam bedenken Behoefte-analyse uitwerken Google tools: discussiegroep, logboeken, code project opzetten Links naar logboeken en code project op de groepspagina [email protected] uitnodigen als lid van de discussiegroep Behoefte-analyse op de wiki-pagina's van het code project plaatsen

Contact De begeleiders zijn • Helga Naessens • Ann Vanoverberge • Koen Vandewiele

• Tim Depauw • Wijnand Schepens • Wim Vandenbreen Stuur je vragen of opmerkingen bij voorkeur naar [email protected]