Software-ontwerp

Vakinformatie

Dit vak wordt gegeven in het tweede semester van het derde jaar informatica en in het schakelprogramma toegepaste informatica. Zowel in structuur als inhoud is het een soort van voortzetting van objectgericht programmeren. Er zijn in totaal een zestal lessen, bijna uitsluitend gegeven door prof. Jacobs (in 2016-2017 was er een gastles door Jan Spooren, één van de adviseurs, maar dit was geen leerstof). Voor de evaluatie is er naast hem ook nog prof. Holvoet.

De kern van het vak is bouwen van een middelgroot software-systeem in groepjes van 4. Dit gebeurt in 3 iteraties (van ongeveer 3, 5 en 3 weken): zoals bij OGP zullen er elke keer formele eisen gesteld worden aan wat je systeem kan doen en bouwen de iteraties voort op elkaar. Bij de eerste iteratie ligt de nadruk op de GRASP-principes, bij de tweede komen hier ook de design patterns bij en bij de derde ook refactoring. De relevante leerstof wordt altijd eerst besproken in de les, hoewel er ook verwacht wordt dat je leest in de handboeken (bij de design patterns wordt er inderdaad wel wat relevante patterns overgeslagen). Uiteindelijk is er niet veel theorie en ligt de nadruk van het vak dan ook eerder op je ontwerp- en programmeervaardigheden als team (of tenminste volgens de standaarden van GRASP).

Naast de lessen zijn er in het begin van het semester ook enkele oefenzittingen, maar deze zijn van niet zo'n groot belang. Verder krijgt elk team ook een adviseur toegewezen waarmee je elke week een afspraak van een uur kan maken. Hierbij kan je vragen stellen over de opgave maar ook verschillende ontwerpvoorstellen aankaarten en vragen wat hij/zij het beste vindt, of iets bepaalds wel "mag", ... (volgens Jacobs is er over de jaren heen een significante correlatie tussen teams die veel afspreken met hun adviseur en teams met hoge scores, maar de vraag is maar of dit causaal is ...).

Wel vallen een aantal van de eisen van OGP weg: geen formele documentatie, je hebt ook een beetje vrijheid in hoe uitgebreid je je informele documentatie schrijft, niet elke methode moet ge-unittest worden (hoewel het in de domeinlaag misschien geen slecht idee is) en totaal/nominaal/defensief programmeren wordt simpelweg vervangen door "defensief programmeren" in een nieuwe betekenis (zo weinig mogelijk aannames maken over de parameters van een methode, de caller van een methode, de staat van een object, ... maar je mag zelf kiezen hoe). Toch moet je nog steeds documentatie voorzien, automatisch testen (deze keer met coverage tools), klassediagramma en system sequence diagrams maken, ... voor elke iteratie. Afhankelijk van je adviseur kan het ook gevraagd worden dat je dergelijke documenten voorbereidt voor elke afspraak.

Evaluatie

De evaluatie gebeurt als volgt. Na elke iteratie is er een verdediging, bij de eerste en tweede iteratie komt dit neer op een presentatie over het ontwerp, tests, ... gevolgd door een demo van het programma voor de gebruiker en eventueel een demo van de tests (hier staan ze niet altijd op). Hierbij krijg je natuurlijk meestal wat vragen/kritiek van de evaluators (1 van de proffen, je adviseur en een andere adviseur). Op dit vlak lijkt Jacobs (misschien ook Holvoet) erg tolerant: zolang je je beslissingen kan verdedigen is er geen probleem, al vindt hij ze misschien op het eerste gezicht raar. De derde verdediging verloopt hetzelfde, behalve dat er geen presentatie gegeven moet worden. Ten slotte moet iedereen ook een peer/self-assessment indienen na elke iteratie, maar deze is louter informatief voor het didactisch team en heeft geen directe invloed op de punten.

De derde verdediging (tijdens de examenperiode) bestaat uit twee delen: een groepsdeel (dat eerder besproken is) en een individueel deel. Het groepsdeel is zoals de andere verdedigingen behalve dat je geen presentatie moet geven en dat de test-suite van groter belang is. Bij het individueel deel wordt je afgezonderd en krijgen jullie allemaal een bepaalde uitbreiding van de opgave, waarop je 100 minuten hebt om op papier de uitbreiding voor je systeem te ontwerpen. Je moet dus niets implementeren, maar wel nadenken over wie objecten maakt, bijhoudt, bepaalde methodes oproept, met welke parameters, welke klassen er toegevoegd moeten worden en of er overerving gebruikt kan worden, of er nuttige design patterns zijn, ... en dat met respect voor GRASP. Daarna ga je bij dezelfde evaluators tot 20 minuten lang je uitbreiding bespreken. Hierbij zullen bepaalde aspecten van het project ook ondervraagd worden (je adviseur heeft normaal gezien je code gelezen, de prof niet, dus er kunnen basisvragen over je systeem bij zitten).

Voor de individuele verdediging is het volgens Jacobs van groot belang dat je de 9 GRASP-principes en 23 design patterns allemaal kent. In de praktijk lijkt hij hier echter weinig naar te vragen, zolang je er 1 pattern ergens in je uitbreiding hebt ingewerkt is het erg waarschijnlijk dat hij er niets van zegt. Refactoring wordt ook niet ondervraagd. De belasting tijdens de examenperiode is dus redelijk licht, wat compenseert voor het werk dat je tijdens het semester in je project steekt.