Practicum OOP
Het practicum OOP biedt de mogelijkheid praktische ervaring op te doen in
het hanteren van object georienteerde ontwerp en implementatie technieken.
Info,
FAQ
Coordinatie en begeleiding
Anton Eliens (eliens@cs.vu.nl),
Jacco van Ossenbruggen (jrvosse@cs.vu.nl)
Neem bij voorkeur contact op via email.
Het verdient aanbeveling, voorafgaand aan de keuze van een opdracht,
met de
practicumbegeleiding te overleggen.
De synopsis dient via email aan eliens gestuurd te worden.
Inleveren, ook via email, bij jrvosse.
Vergeet niet naam, studentnummer en email te vermelden.
Synopsis
Omgeving
Uitgegaan wordt van C++. De
hush
bibliotheek dient gebruikt
te worden voor het ontwikkelen van de grafische gebruikers interface.
Voor eventuel andere talen en/of pakketten is overleg met de
practicum coordinator nodig.
Voor de documentatie wordt het gebruik van LaTeX aanbevolen.
De
Practicum handleiding Software Engineering
kan geraadpleegd worden voor technische informatie mbt
tot hush en Tcl/Tk, alsook het gebruik van make ed.
Werkwijze
Het practicum kan individueel of in groepjes van twee
afgelegd worden.
Er is een keuze mogelijk uit meerdere opdrachten.
Studenten dienen vooraf hun keuze bekend te maken door
een synopis te mailen naar de coordinator.
Een synopsis is
een (korte) omschrijving
van de eisen waaraan het te maken programma dient te voldoen.
De uitwerking van de opdracht (synopsis)
moet worden ingeleverd per email.
De synopsis dient in (plain) tekst dan wel HTML geschreven
te zijn.
Bij het inleveren van het eindresultaat dient
de documentatie ook op papier ingeleverd worden.
Streef naar goed leesbare documentatie, bijvoorbeeld
in de vorm van een artikel waarin de opzet en
architectuur (ontwerp) van het systeem op heldere wijze uitgelegd wordt.
Het ontwerp dient zodanig opgezet te zijn dat het de structuur van het
programma rechtvaardigt.
Afhankelijk van de beoordeling van de begeleider kan gevraagd
worden een aantal verbeteringen aan te brengen of
de documentatie (bijvoorbeeld
het ontwerp) uit te breiden.
Als dat plaatsgevonden heeft moet de opgave in zijn geheel opnieuw
ingeleverd worden.
(Vermijd bij het inleveren het gebruik van plastic.
Nietjes zijn oha voldoende.)
Zie ook: toelichting.
Tijdschema
Als richtlijn worden de volgende opzet gehanteerd:
- Begin: inleveren synopsis, voor 15 februari
- Eind: inleveren definitieve versie, voor 1 september
In tegenstelling tot eerdere jaren wordt er een strikte
deadline (van 1 september) gehanteerd.
Het is de verantwoording van de student (of groep) om
bij stagnering van de werkzaamheden tijdig contact
met de begeleider of coordinator op te nemen.
Inleveren per email
Inleveren per email moet in
shar formaat of in een uuencoded file.
In het voorbeeld in /usr/prac/oo/opdracht
staat aangegeven hoe dat moet.
Zorg dat alle object files en andere overbodige files verwijderd zijn.
Voorbeeld
Een voorbeeld directory staat in /usr/prac/oo/opdracht.
Documentatie
De eisen die aan de documentatie gesteld worden zijn afhankelijk
van de opdracht. Zowel de eisen als een
meer uitgewerkte versie van het ontwerp moeten
online beschikbaar zijn.
Verder dient dient een uitleg/help-faciliteit
een onderdeel te zijn van de gebruikers interface.
Ook moet er de mogelijkheid zijn een demo op te starten,
of default voorbeeld
in te lezen, die een beginnend
gebruiker de mogelijkheden van het programma demonstreert.
Opdrachten
De opdrachten zijn o.a. gebaseerd op in het college behandelde literatuur.
- Interactief videogame --
Een voorbeeld is een volley of tennis spel voor een of twee spelers.
Zorg ervoor dat er voldoende opties (snelheid, ed.) geimplementeerd
worden en dat de gebruiker informatie kan vragen over de behaalde
score. Een suggestie voor een mogelijke optie is de mogelijkheid
van replay, het laten na spelen van een gespeelde serie.
Literatuur: [Coplien, 1992]
- Een OO Case tool --
De bedoeling is een eenvoudig case tool, zoals
bijvoorbeeld beschreven in [Coad and Yourdon, 1991],
of een die het gebruik van CRC kaarten ondersteunt.
Literatuur: [Coad and Yourdon, 1991]
- Eenvoudig hypermedia systeem --
Het systeem moet ten minste eenvoudige teksten en graphics
kunnen bevatten en verwijzingen (links)
tussen teksten en plaatjes. Deze links moeten dynamisch (interactief) doorlopen kunnen worden.
De ingeleverde opdracht moet een voorbeeld (hypermedia informatie systeem) bevatten, over een onderwerp naar keuze.
Optioneel is het opnemen van grafische edit faciliteiten, browsing mogelijkheden,
en zoekfuncties.
Literatuur: [Meyrowitz, 1986], [Conklin, 1987]
- IInteractieve tekst editor --
De editor moet in ieder geval de functionaliteit van xedit
hebben. Bij deze opdracht ligt een grote nadruk op het ontwerp.
Literatuur: B.v. A. Diller, Z -- An introduction to formal specification, Wiley (1992)
- Direct manipulation score editor --
Met de editor moet op eenvoudige wijze interactief
een notenbeeld gecreeerd en gemanipuleerd kunnen worden.
Toelichting: Deze opgave is alleen geschikt voor studenten met enige kennis van muziek-theorie.
Literatuur: [Pope, 1991]
- Object georienteerd expert systeem
De implementatie van het expert-systeem, alsook de gebruikersinterface,
dient object georienteerd
te zijn. De integratie van OO technieken met het gekozen kennisrepresentatie formalisme
is optioneel. De ingeleverde opdracht moet een voorbeeld kennisbestand bevatten.
Literatuur: [Eliens,1991], David Hu, C/C++ for expert systems, MIS Press (1989)
- 3D animation --
Het systeem moet een editor bevatten en mogelijkheden
tot manipulatie van de figuren. Een extra vereiste is dat
uitgevoerde manipulaties (zoals rotatie en verplaatsing) herhaald
moeten kunnen worden.
Literatuur: L. Ammeraal, Programming principles in computer graphics, Wiley (2nd edn.)
- Een gok automaat --
Een voorbeeld daarvan is een fruitmachine,
zoals te vinden in elke snackbar.
Belangrijk bij deze opdracht is dat er
een realistische gebruikersinterface geboden wordt.
De kans van winnen moet bovendien instelbaar zijn.
- Een grafische editor voor ETAG
Dit is een opdracht die alleen
door studenten die het college mens-machine interactie
gevolgd hebben gedaan kan worden.
Toelichting: maak een afspraak met de coordinator
Toelichting
Bij al de opdrachten wordt een grafische gebruikers interface verlangd.
On-line help is tevens een vereiste, dwz. een gebruiker
moet het systeem kunnen gebruiken zonder eerst de documentatie
te raadplegen.
Eigen voorstellen van studenten zijn mogelijk.
Vooraf is echter goedkeuring van de coordinator nodig.
Beoordeling
De ingeleverde opgaven worden zowel op de kwaliteit van het
programma, het ontwerp daarvan, als de daarbij behorende documentatie beoordeeld.
De functionaliteit van het systeem dient kort, zeg in 1 a 2 pagina's
beschreven te zijn, met argumenten waarom het een goed, bijzonder,
dan wel slecht systeem is.
Het ontwerp en de daaraan voorafgaande beslissingen
dient helder, in een bestek van 4-5 pagina's, uiteengezet te zijn.
Gebruik een apart hoofdstuk of appendix voor een meer gedetailleerde bespreking
van het programma, of onderdelen daarvan.
Bij de beoordeling wordt tevens rekening gehouden met de wijze waarop
de aanwijzingen van de begeleider verwerkt zijn.
Klachten over de beoordeling dienen tijdig bij de coordinator
gemeld te worden.
Criteria
- Documentatie
-
De documentatie omvat de definitie van eisen, de beschrijving van
het ontwerp, een gebruikershandleiding
en eventueel een toelichting op de functionaliteit
van de applicatie.
- Architectuur
-
Onder architectuur wordt verstaan het ontwerp en de implementatie,
zowel qua opzet als verzorging.
Het systeem dient netjes, dwz. overzichtelijk, opgezet
te zijn en zich eenvoudig laten installeren.
- Interface
-
Het systeem dient eenvoudig gebruikt te kunnen
worden. Het wordt aanbevolen gebruikersdocumentatie
in de vorm van online help beschikbaar te maken.
Opmerking:
Bovenstaande criteria worden dienen als richtlijn.
Een individuele beoordeling kan van deze richtlijnen
afwijken.
eliens@cs.vu.nl