© John Visser en Harry Broeders.
| onderwijsdeel: | Software Ontwikkeling en Programmeren 3 |
| studiebelasting: | 168 SBU (84 in kwartaal 1 en 84 in kwartaal 2) |
| semester / kwartaal: | H3C&D / 1 en 2 |
| contacturen: | Kwartaal 1: 3 uur/week college en 1 uur/week practicum |
| Kwartaal 2: 1 uur/week projectbegeleiding per projectgroep | |
| toetsing: | tentamen (cijfer), practicumbeoordeling (O/V) en projectbeoordeling (cijfer) |
| benodigde voorkennis: | SOPX2 en eerste kwartaal van SOPX3. |
| verantwoordelijke docenten: | John Visser en Harry Broeders |
In steeds meer elektrotechnische producten en systemen wordt programmatuur gebruikt. Het is zeker dat een aanstaand elektrotechnisch C&D ingenieur hiermee te maken krijgt. In de propedeuse en in H1 heb je leren programmeren in de programmeertaal C met behulp van de functionele decompositie ontwerpmethode (structured programming and structured design). In H2 heb je de basisaspecten van object georiënteerd programmeren (OOP) geleerd aan de hand van de programmeertaal C++. In deze onderwijseenheid wordt dieper op deze programmeertaal ingegaan. Het opvangen van fouten door middel van exceptions wordt uitgebreid besproken en ook namespaces en run-time type information komen aan de orde.
In de propedeuse en in het H1 project heb je datastructuren zoals array en struct leren gebruiken. Deze datastructuren worden statisch genoemd omdat hun grootte tijdens het compileren wordt bepaald en vast is. In de praktijk heb je al snel behoefte aan zogenaamde dynamische datastructuren waarvan de grootte tijdens het uitvoeren van het programma kan wijzigen. Tijdens deze onderwijseenheid zal je kennis maken met zowel de implementatie als het gebruik van de klassieke dynamische datastructuren. Je zult leren hoe het met behulp van templates mogelijk is om algoritmen zoals zoeken en sorteren generiek te definiëren. Een generiek algoritme is een algoritme dat onafhankelijk is van de gebruikte datastructuur. In de C++ ISO/ANSI standaard is een verzameling generieke algoritmen en datastructuren opgenomen die in deze onderwijseenheid worden behandeld.
De programmeertaal C++ ondersteund dus 3 verschillende programmeer paradigma's:
Tevens wordt in deze onderwijseenheid een inleiding gegeven in het modelleren van object georiënteerde systemen met behulp van de UML (Unified Modelling Language) standaard. Je gaat deze theorie in het tweede kwartaal in projectvorm toepassen bij het SOPX3 project.
Tot slot van het eerste kwartaal van deze onderwijseenheid worden nog enkele applicaties waarin datastructuren worden toegepast besproken.
Je zult na afloop van het eerste kwartaal van SOPX3 in staat zijn om herbruikbare software componenten te gebruiken, ontwerpen, implementeren en testen. Na het tweede kwartaal van SOPX3 zul je in staat zijn om samen met collega's (in een projectgroep) de software voor een elekrotechnische systeem te ontwerpen en realiseren. Je bent in staat om de eisen van de gebruikers in zogenaamde use-cases te beschrijven. Je maakt bij het ontwerpen gebruik van een moderne ontwerptool (TogetherSoft) die de UML diagrammen automatisch omzet naar C++ code.
Als je dit project met een voldoende hebt afgesloten:
Bruce Eckel, Thinking in C++ 2nd Edition, Volume 1, ISBN 0-13-979809-9.
Bruce Eckel, Thinking in C++ 2nd Edition, Volume 2, ISBN 0-13-122552-9.
Deze boeken zijn ook gratis te downloaden van:
http://mindview.net/Books/TICPP/ThinkingInCPP2e.html.
Warmer & Kleppe,
Praktisch
UML, 4de editie ISBN 978-90-430-1265-2
John Visser en Harry Broeders, projectomschrijving SOPX3.
Er worden voor deze onderwijseenheid drie deelresultaten vastgesteld waarbij het eerste resultaat (tentamen) een cijfer (1..10) is, het tweede resultaat (practicum) een O(nvoldoende) of V(oldoende) is en het derde resultaat (project) weer een cijfer (1..10) is. Het eindresultaat wordt dan het gemiddelde cijfer van het tentamen (kwartaal 1) en het project (kwartaal 2) als het tweede resultaat een V is en een 1 als het tweede resultaat een O is.
Het cijfer voor het project wordt bepaald aan de hand van het eindproduct
en de tussenrapportages. De tussenrapportages (in totaal 3) wordt beoordeeld
volgens een schaal van 4 niveaus (A…D) waarbij A uitmuntend is en D
slecht. Zie: Het door de docenten gebruikte
beoordelingsformulier met de resultaten.
Indien leden van het ontwerpteam zich niet aan de team afspraken houden, kan dit teamlid na teamoverleg met de coach uit de groep gezet worden. Het uitgezette lid krijgt in dat geval geen cijfer.
De groepsindeling wordt gemaakt aan de hand van de toetscijfers van het eerste kwartaal.
Groep 1:
Groep 2:
Voor de duidelijkheid zijn de exacte data waarop een en ander ingeleverd moet worden aangegeven.
| Week | Werkzaamheden |
|---|---|
| Maken van een tijdsplanning voor deze week. Opstellen van functionele en niet functionele eisen (hoofdstuk 2+3). Maken van de use-cases (hoofdstuk 8+9). Inleveren 1ste tussenrapport voor maandag 26 november 8:30 uur. |
|
| Voortgangsbespreking met eventuele problemen van de vorige week. Maken van een eerste globale klassediagram (hoofdstuk 4+5). Inleveren 2de tussenrapportage voor maandag 3 december 8:30 uur. |
|
| Voortgangsbespreking met eventuele problemen van de vorige week. Maken van de sequencediagrammen (hoofdstuk 10+11). Maken van een toestandsdiagrammen (hoofdstuk 12+13). Implementatie en uittesten van het eerste globale model. Inleveren 3de tussenrapportage voor maandag 10 december 8:00 uur. |
|
| Demonstratie 1ste ontwerpmodel op maandag 10 december
tijdens practicumuren. Voortgangsbespreking met eventuele problemen van de vorige week. Aanpassen van de diagrammen voor een 2de uitgebreidere versie. Implementatie en uittesten van het 2de model. |
|
| Demonstratie 2de ontwerpmodel maandag 14 januari tijdens
practicumuren. Voortgangsbespreking met eventuele problemen van de vorige week. Laatste veranderingen toepassen en voorbereiding presentatie. |
|
| Presentatie en einddemonstratie op dinsdag 29 januari 14:00
uur. De presentatie en de einddemo wordt gehouden bij Aweta:
Burgemeester Winkellaan 3 - 2631 HG Nootdorp. Inleveren eindresultaat maandag 4 februari 8:30 uur. |
Maken van een tijdsplanning voor deze week.
Hiermee wordt bedoeld dat jullie met elkaar moeten afspreken wanneer aan het SOPX3 project gewerkt gaat worden (maandag 26 november 8:30 uur moet het eerste tussenrapport ingeleverd zijn). Ook moet je er aan denken om een projectruimte te reserveren.
Het opstellen van functionele en niet functionele eisen (hoofdstuk 2+3).
Uit de opdrachtomschrijving die jullie hebben gekregen moet je zelf een lijstje met functionele en niet-functionele eisen samenstellen. In het boek zijn daar verder geen richtlijnen voor gegeven.
Maken van de use-cases (hoofdstuk 8+9).
Het stappenplan voor het maken van de use-cases kun je vinden in hoofdstuk 8.7.1
De stappen 1 t/m 7 moet je volledig uitvoeren. Stap 7 kan al na stap 2. Bij de eerste versie is het nog niet de bedoeling dat je alle functionele eisen meteen meeneemt. Het is dus ook nog niet nodig om meteen alle use-cases uit te werken. Stap 4 t/m 6 moeten dus alleen voor een beperkt aantal use-cases worden doorlopen. We spreken hierbij af dat de belangrijkste use-case wordt uitgewerkt om geïmplementeerd te kunnen worden in de eerste versie van de software.
Inleveren 1ste tussenrapport.
Het tussenrapport is niets anders dan een mapje (op papier of elektronisch of een combinatie van beiden) met alle geproduceerde lijstjes en diagrammen van alle uitgevoerde tussenstappen. Het uiteindelijke eindproduct van de eerste week is een use-case diagram plus een aantal (in tabelvorm) uitgewerkte use-cases. Kijk naar de uitwerking van de case in het boek (hoofdstuk 9) en maak vergelijkbare tabellen en diagram!
Het maken van een eerste globale klassediagram (hoofdstuk 4+5).
Je moet hier het stappenplan volgen wat in H4.6 van het UML boek staat beschreven. Let op! Bij de eerste versie is het nog niet de bedoeling dat je alle functionele eisen meteen meeneemt. Je kiest er gewoon een aantal uit (natuurlijk wel bijhouden welke je al gedaan hebt) de rest komt later wel.
De stappen 8 en 9 hoef je niet te doen. Zie pagina 42. Vergeet niet om een modeldictionary te maken (stap 3).
Inleveren 2de tussenrapportage.
Het uiteindelijke eindproduct van de tweede week is een globaal klassemodel van een deel van het te bouwen systeem. Je moet ook documenteren hoe dit klassemodel ontstaan is. Kijk naar de uitwerking van de case in het boek (hoofdstuk 5) en maak dezelfde soort lijstjes en diagrammen! Maandag 3 december 8:30 uur moet het tweede tussenrapport ingeleverd zijn.
Maken van de sequencediagrammen (hoofdstuk 10+11).
Het stappenplan voor het maken van de sequencediagrammen kun je vinden in paragraaf 10.5. Alle stappen 1 t/m 5 moeten per gemaakte use-case worden doorlopen. Op dit moment dienen alleen de sequencediagrammen te worden uitgewerkt die geïmplementeerd worden in de eerste versie van de software.
Als je het moeilijk vindt om de sequencediagrammen vast te stellen dan kun je als hulpmiddel gebruik maken van CRC-kaarten zoals beschreven in hoofdstuk 10.6.
Maken van een toestandsdiagrammen (hoofdstuk 12+13).
Het stappenplan voor het maken van de toestandsdiagrammen kun je vinden in hoofdstuk 12.4.
De stappen 1 t/m 7 moet je volledig uitvoeren. Let op het is zeker niet nodig om voor elke class een toestandsdiagram te maken. Lees het eerste deel van paragraaf 12.4 goed door! Op dit moment dienen alleen de toestandsdiagrammen te worden uitgewerkt die geïmplementeerd worden in de eerste versie van de software.
Implementatie en uittesten van het eerste globale model.
Deze eerste werkende versie van het programma moet volgende week (week 4) worden gedemonstreerd. Let op! Er hoeft slechts een klein deel van de uiteindelijke applicatie geïmplementeerd te worden in de eerste versie. Maak deze week afspraken met je begeleidende docent over wat je gaat realiseren.
Inleveren 3de tussenrapportage.
Maandag 10 december 8:00 uur moet het derde tussenrapport ingeleverd zijn (inclusief sourcecode van de eerste implementatie).
Demonstratie eerste ontwerpmodel.
Het eerste ontwerpmodel zal gedemonstreerd worden op maandag 10 december tijdens de practicumuren.
Het doel van de eerste versie van het programma was om zo snel mogelijk een basis te leggen voor de verdere ontwikkeling van het programma. Het is heel belangrijk om snel een basisversie te produceren. Deze basisversie hoeft slechts voor een klein deel de benodigde functionaliteit te bevatten. Het is dus slechts een deel van het uiteindelijke programma. Deze basisversie wordt meteen geëvalueerd met de klant om er zeker van te zijn dat we de wensen van de klant goed hebben begrepen. Tijdens deze evaluatie kan de klant eisen die eerst "vaag" waren vaak beter formuleren. Meestal komen dan ook nog aanvullende eisen boven tafel. Ook kunnen we zelf (na het maken van de basisversie) vaak beter plannen hoeveel tijd de nog benodigde uitbreidingen gaan kosten. Fouten in ons klassemodel komen op deze manier ook snel aan het licht.
Het aanpassen van de diagrammen voor een tweede uitgebreide versie.
Het is nu de bedoeling om stap voor stap steeds completere versies te ontwikkelen zodat we uiteindelijk de eindversie bereiken. Bij het SOPX3 project is niet voldoende tijd aanwezig om uiteindelijk tot een eindversie te komen. Dat was ook niet de bedoeling. Om nu toch een idee te krijgen hoe deze evolutionaire (stap voor stap) ontwikkelmethode in zijn werk gaat zullen wij nog een tweede versie van ons programma gaan ontwikkelen.
Omdat we tijdens de eerste slechts een deel van de functionele eisen hebben verwerkt in ons model (en dus ook in ons programma) is het erg belangrijk om na het voltooien van de eerste versie goed te bekijken welke eisen we al wel en welke eisen we nog niet (of nog niet volledig) hebben gerealiseerd. Om dit te kunnen doen hebben we een duidelijke lijst met functionele eisen nodig (deze hebben we in week 1 al gemaakt maar we kunnen de lijst nog verbeteren). Het is daarbij de bedoeling dat elke eis afzonderlijk duidelijk wordt geformuleerd. Als je elke eis een nummer geeft dan kun je per eis aangeven in welk diagrammen deze eis vervuld is. Van bepaalde eisen kun je in een klassediagram zien dat aan deze eis is voldaan, andere eisen kun je in een interactiediagram terugvinden en weer andere eisen in een toestandsdiagram. Natuurlijk kun je elke eis (die is vervult) ook terugvinden in een use-case beschrijving. Door links aan te brengen van de eis naar de use-case en diagrammen waar deze eis is vervult zorg je ervoor dat het programma eenvoudig te wijzigen is als een eis verandert!
Stap 1. Jullie moeten dus beginnen met het maken van deze lijst met functionele eisen waarbij per eis is aangegeven of deze eis al is vervult en zo jaar waar dat te vinden is in het model. Het zou best kunnen dat tijdens deze inventarisatie van de functionele eisen fouten in het model worden gevonden. Het is dan van groot belang om deze fouten te verwijderen voordat met de tweede versie wordt begonnen. Let op: het is meestal niet nodig om de fouten meteen te herstellen. Je kunt het foute stuk gewoon verwijderen. De betreffende functionele eis moet dan natuurlijk in de tweede versie opnieuw worden meegenomen.
Daarna moet (eventueel in overleg met de klant) een keuze worden gemaakt uit de nog te vervullen eisen die bij de volgende versie worden ingevuld. Probeer niet te veel tegelijk te doen! Hoe bescheidener we zijn hoe eenvoudiger het wordt om de werkzaamheden voor de volgende versie te plannen. Ook krijgen we na het afronden van de volgende versie weer terugkoppeling van de klant en lopen we dus maar weinig schade op als we bij de eisen die we in deze versie vervullen niet goed hebben begrepen.
STAP 2. Maak een planning voor de tweede versie. Hou in de gaten hoeveel tijd je al hebt besteed aan SOPX3 en hou er ook rekening mee dat in de laatste week nog een korte presentatie moet worden gegeven.
STAP 3. Implementeer de tweede versie. Let op! Bij het maken van de tweede versie moet het hele ontwikkeltraject opnieuw doorlopen worden. Dus maak use-case beschrijvingen, klassediagrammen, interactiediagrammen en toestandsdiagrammen (of breid bestaande diagrammen uit) voordat je gaat implementeren (coderen)! Vergeet ook niet om de stappenplannen voor het maken van de verschillende diagrammen (zie boek) netjes te volgen.
In de toelichting voor week 4 t/m 6 is al uitgelegd dat je in week 4 t/m 6 aan de tweede versie van het programma werkt. In week 7 (maandag 14 januari tijdens practicumuren) geef je een demonstratie van het 2de ontwerpmodel. De rest van week 7 kun je gebruiken om de laatste verbeteringen aan te brengen en de documentatie af te ronden.
In week 9 geeft elke groep een presentatie en een einddemonstratie bij Aweta: Burgemeester Winkellaan 3 - 2631 HG Nootdorp. Deze presentatie zal dinsdag 29 januari 14:00 uur plaatsvinden. De presentatie moet vanzelfsprekend voldoen aan de normen die jullie bij het vak "communicatieve vaardigheden" hebben geleerd. In de presentatie moet de structuur van het programma worden behandeld aan de hand van enkele UML diagrammen. Het is natuurlijk niet mogelijk om het gehele programma te bespeken. Je moet je beperken tot de hoofdzaken, details hoeven niet besproken te worden. Wel is het leuk als elke groep een specifiek deel van de applicatie (iets waar je trots op bent) tot in detail bespreekt. Elke presentatie moet ongeveer 15 minuten duren, waarna er nog 5 minuten zijn om eventuele vragen te beantwoorden.
Het eindresultaat (alle code, alle diagrammen, alle tijdlijsten) moet uiterlijk maandag 4 februari 8:30 uur per e-mail bij J.Z.M.Broeders@hhs.nl en J.J.Visser@hhs.nl worden ingeleverd.
Notes:
1 Alle verwijzingen naar het UML boek verwijzen
naar paragraafnummers uit de vierde editie. Als je gebruik maakt van de derde
editie (die inhoudelijk gelijk is aan de vierde) dan moet je elk paragraafnummer
met 1 verlagen. Dus paragraaf 8.7 in de vierde editie was paragraaf 8.6 in
de derde editie.