Software-ontwerp

Ga naar: navigatie, zoeken

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.

Samenvattingen

Het vak is weinig theoretisch, maar als je moeite hebt om alle patterns te onderscheiden en onthouden, kan deze samenvatting van Willem Van Onsem je helpen.

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 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.

Zelfstudiegids

Je moet voor dit vak heel wat design-principes/patterns kunnen toepassen, maar die worden niet (of in heel geringe mate) behandeld in de les. Alle theorie moet je kunnen toepassen vanaf deel 1 van het project. In het begin zul je dus veel zelfstudie moeten doen. Hier is een gids voor wat je best eerst bekijkt. Meningen kunnen sterk verschillen, maar de volgende vier categorieen geven grofweg aan wat een goede volgorde zou kunnen zijn.

  1. Essentieel (zeker toepassen of tenminste overwegen)
    1. GRASP
    2. Model-View-Controller (Prof. Jacobs is niet zo een fan, maar je moet zeker rekening houden met de bedoeling achter MVC)
    3. Composition-over-inheritance (niet hetzelfde als "Composite")
    4. Observer
    5. State
  2. Nuttig, zeker aanbevolen om te bekijken
    1. Decorator
    2. Visitor
    3. Strategy
    4. Bridge
    5. Template method
    6. Builder
    7. Facade
    8. Chain-of-responsibility
  3. Bestudeer deze eventueel later
    1. Mediator
    2. Factory method
    3. Prototype
    4. Singleton
    5. Adapter
    6. Composite
    7. Memento
    8. Command
    9. Proxy
  4. Normaal gezien niet nodig
    1. Flyweight
    2. Abstract Factory
    3. Interpreter
    4. Iterator

Noot: In het bijzonder categorie 2 en 3 lopen wat in elkaar over. Het is sterk afhankelijk van je project welke je het best toepast.

Lees kort de beschrijving op Wikipedia voor elk van de patterns en bestudeer in detail categorie 1 en liefst ook categorie 2 tijdens deel 1 van het project. Idealiter nog meer, natuurlijk. Zorg dat je naar het einde van deel 2 toe alle categorieen behalve de laatste kent.

De design-patterns vertellen je hoe goede ontwerpen er kunnen uitzien. Het is ook zinvol om te kijken naar slechte voorbeelden en een uitleg waarom ze slecht zijn. Die vind je in het boek "Refactoring: Improving the design of existing code". Daarin staan vaak gemaakte fouten en hoe je ze moet verbeteren. Bekijk die als je adviseur negatieve commentaar geeft over je code.

Het boek over UML is niet aangeraden.

Opdrachten en examenvragen

2019

Opgave project

Tablr, een in memory database applicatie.

Uitbreiding 25 juni 2019

Voeg functionaliteit toe om een row te deleten van een computed table, delete de desbetreffende rij uit de gerefereerde table die als eerste in de FROM voorkomt. Als dit ook een computed table is, herhaal het proces.

Vraag mondeling 25 juni 2019

Leg het verschil uit tussen Abstract factory en Factory method. Waar wordt Memento pattern voor gebruikt (buiten undo functionaliteit).

Uitbreiding 19 juni 2019

Tijdens het bewerken van tekst (bv. naam, veld, query, ...) kan de gebruiker op ctrl + F2 drukken om een nieuw window te openen waar die tekst in komt. Dit window kan de tekst over meerdere lijnen verdelen worden met een verticale scrollbar. De oorspronkelijke tekstbox kan niet aangepast worden zolang het window open is. Als het window sluit wordt de oorspronkelijke tekst geüpdatet. Als de tekst door iets anders wordt aangepast moet het window gesloten worden.

Tijdens de verdediging vroeg de prof ook om een gelijkaardig window te maken dat niet verbonden is met een tekstvak maar waarbij de tekst voor iets anders gebruikt wordt.

Uitbreiding 11 juni 2019

Voeg functionaliteit toe om een row te deleten van een computedTable

Uitbreiding 14 juni 2019

Ontwerp een grafische Query-editor waarbij een Query ontworpen en bewerkt kan worden door puzzelstukjes van een pallet naar een canvas te slepen. Ieder puzzelstuk heeft een bepaald aantal inputs en outputs. Niet alle puzzelstukken zijn compatibel met elkaar. Zeer complexe opgave met veel randvoorwaarden. Achteraf bij de mondelinge verdediging zei Prof. Holvoet dat de opgave niet volledig af moest zijn, enkel de core concepts.

2018

Opgave project

Opgave met de nieuwe toevoegingen van het derde deel gemarkeerd

Deel 1 bestond uit het maken van een programma om interactiediagrammen te tekenen. Hetzelfde model moet gebruikt kunnen worden om zowel een sequence-diagram als een communication-diagram te tekenen. Je mocht niet vertrouwen op grafische bibliotheken van Java; je mocht enkel de absoluut noodzakelijke basis gebruiken, bijvoorbeeld het tonen van een venster en het tekenen van rechthoeken en cirkels. In deel 2 moest hetzelfde gebeuren, maar er konden meerdere vensters openstaan die verwijzen naar hetzelfde model en elk een ander diagram tonen (bv. het ene is communication, het andere is sequence, of het ene heeft een Actor links bovenaan staan en het andere heeft diezelfde actor rechts bovenaan). Wijzigingen in het ene diagram moeten zichtbaar zijn in het andere diagram, tenzij die wijzigingen louter visueel zijn (bv. verplaatsen van een object). Deel 3 bestond uit het voorzien van een alternatieve input-methode, namelijk het gebruik van dialog boxes in plaats van in-place bewerkingen.

Uitbreidingen op het examen

Dinsdag 19 juni 2018

Voeg een menubar en een toolbar toe. Menubar items tonen een kolom van acties wanneer er op geklikt wordt, deze acties worden dan uitgevoerd wanneer het item aangeklikt wordt (bv. switch diagram type, create new diagram, add party). Toolbar items bevatten een icon. Menubar en toolbar items kunnen enabled of disabled zijn afhangende van bepaalde voorwaarden, toolbar items tonen een tooltip wanneer de cursor 0.5 seconden op het item blijft. De toolbar bevat ook een textbox om labels te bewerken. De menubar en toolbar passen de weergave en positie van de items aan naarmate de canvas resized.

datum onbekend

Maak scroll-bars in de subwindows en listboxes

datum onbekend

Voorzie een export/import-functionaliteit

Vrijdag 15 juni 2018

Maak een designer-modus voor de dialog boxes: Als de gebruiker op Ctrl+E drukt, wordt een dialog box in designer modus gezet. Dit houdt in dat de gebruiker het volgende kan doen met de controls

  1. verslepen
  2. een ander label geven
  3. verwijderen
  4. dupliceren, zodat die kopie identiek dezelfde functionaliteit heeft.

Als de gebruiker op Enter drukt, gaat de dialog box terug naar interactieve modus, waarin de controls gebruikt kunnen worden om het diagram te bewerken. Alle informatie die op een andere manier geüpdatet wordt, moet automatisch in de controls getoond worden, ook als de dialog box in designer-modus staat. Als de gebruiker wijzigingen heeft aangebracht, moet die nieuwe lay-out ook te zien zijn in alle andere dialog boxes van hetzelfde type. Als er een nieuwe dialog box wordt aangemaakt, dan heeft die ook deze nieuwe lay-out.

Maandag 11 juni 2018 (ochtend)

Maak een undo/redo-operatie

Als de gebruiker ctrl+Z indrukt (undo), wordt de vorige staat van het systeem getoond. ctrl+shift+Z (redo) toont de volgende staat van het systeem (indien deze bestaat). Dit moeten werken op alle operaties, buiten het aanpassen van karakter na karakter van een label. Daar moet de tekst in een keer veranderd worden naar het oude.