Figuur 1: Het waterval model.
© Marcel van de Weert, John Visser en Harry Broeders.
Om een indruk te krijgen, hoe software in team verband en op een moderne (UML) manier ontworpen kan worden, is het SOPX3 project ontwikkeld.
Dit project is een onderdeel van de onderwijseenheid SOPX3. Aan het halen van dit project worden 3 creditpoints toegekend. 3 creditpoints wil zeggen dat er maximaal per persoon 84 uur aan het project gewerkt moet worden. Dat is 84/7 = 12 uur per week. Iedereen moet zijn eigen tijd registreren tot op 15 min per dag nauwkeurig.
Als projectruimte voor met name het werken met Togethersoft en Borland C++ Builder, is lokaal 417 op maandag het 4de en 5de uur gereserveerd. De projectruimtes voor vergaderingen, brainstormsessies, etc. moeten bij het secretariaat of bij de receptie gereserveerd worden. Het werken met Togethersoft kan alleen in 217/417/413 gebeuren.
De indeling van de teams staat op blackboard. De indeling is mede gebaseerd op de uitslag van het tentamen SOPX3. Dit is gedaan om te voorkomen, dat één of meerdere personen het tempo van de groep niet kunnen bijhouden of dat één persoon zich gaat vervelen.
In tegenstelling tot het H1 project, is het doel van dit project niet om een geheel werkend product te maken, maar om iets te produceren, waarmee een ander team mee verder zou kunnen gaan. In week 9 zal een eindpresentatie en demonstratie worden gegeven.
De omschrijving van de opdracht en een weekplanning staan op het internet. Als je je niet aan de weekplanning houdt dan heeft dit consequenties voor het eindcijfer.
Het inleveren van de tussenrapporten moet wekelijks op tijd (zoals vermeld in de studiewijzer) gebeuren.
Het ontwerpen van software wordt in verschillende fases (stappen) gedaan. Traditioneel gebeurde dit volgens een waterval model, zie figuur 1. Als eerste wordt met de opdrachtgever gekeken wat het programma moet gaan uitvoeren en aan welke eisen het moet voldoen (analyse fase). Als tweede komt de ontwerp fase aan de beurt, hierin wordt het raamwerk van het programma neergezet. Nadat het raamwerk is neergezet kan pas met de implementatie en het debuggen van het te ontwerpen programma begonnen worden. Als laatste wordt het programma volgens een protocol uitvoerig getest.
Figuur 1: Het waterval model.
Diegene met een goed geheugen kunnen zich misschien nog wel herinneren dat deze methode ook bij het H1 project is toegepast (of toegepast had moeten worden).
Een nadeel van deze methode is dat er een lange tijd overeen gaat, voordat de klant zijn wensen in een programma gerealiseerd ziet. De klant kan dus pas laat reageren in de vorm van bijvoorbeeld uitgebreidere en of andere wensen.
In dit SOPX3 project wordt er op een andere manier software ontworpen. Dit wordt gedaan volgens de principes van het evolutionair ontwerpen, zie figuur 2. Het idee hierachter is dat het te ontwikkelen programma op een zodanige manier wordt ontworpen, dat er eerst een eenvoudige (beperkte) versie van gemaakt wordt. Hierin zit uiteraard weer de volgorde van analyse, ontwerp, implementatie en testen. Deze versie wordt vervolgens met de klant besproken. Nadat deze versie met de klant is doorgesproken kunnen eventuele verbeteringen aangebracht worden, waarna een nieuwe versie met een aantal nog niet geïmplementeerde opties worden uitgebracht. Deze versie wordt weer doorgesproken met de klant, enz.
Figuur 2: Schematische weergave van het evolutionair ontwerpen.
Het programma zal ontworpen worden volgens de methode die beschreven is in het boek "praktisch UML" van Jos Warmer & Anneke Kleppe. Bij het ontwerp zul je gebruik maken van de tool Borland Togethersoft. Als eerste zullen de functionele eisen en de systeemeisen van het te ontwikkelen programma bepaald moeten worden in de vorm van use-cases. Hierin wordt beschreven hoe de gebruiker met het systeem om wil gaan. Hierna kan een globale klassendiagram gemaakt worden. Om een klasse diagram te kunnen maken, moeten eerst alle mogelijke kandidaat klassen uit de opdracht gehaald worden. Dit wordt gedaan d.m.v. brainstormsessies en door alle zelfstandige naamwoorden te onderstrepen. Om aan te geven welke boodschappen (messages) de objecten na elkaar toe versturen, worden sequencediagrammen gemaakt. Hierbij worden de use-cases als uitgangspunt genomen. Na het versturen van een boodschap (message) naar een object, kan dat object in een andere toestand geraken. Dit dynamisch gedrag van een object wordt in een toestandsdiagram weergegeven. Nadat de toestandsdiagrammen gemaakt zijn, kan begonnen worden met het implementeren van de eerste versie van de opdracht. Als ontwikkelomgeving wordt naast Borland Togethersoft gebruik gemaakt van Borland C ++ Builder 6.
Nadat versie 1 is geïmplementeerd en uitgetest. Kan het tot nu toe bereikte resultaat aan de klant getoond worden. De klant zal hierop reageren. Ondertussen kan op eigen initiatief al aan versie 2 worden begonnen. Bij versie 2 wordt weer begonnen om eventueel functionele of systeem eisen aan te passen. Vervolgens worden de betreffende diagrammen aangepast, waarna versie 2 geïmplementeerd en uitgetest kan worden. Nadat versie 2 is geïmplementeerd en uitgetest. Kan het tot nu toe bereikte resultaat aan de klant getoond worden. Deze kan hierop weer reageren, diagrammen worden aangepast, enz.
Het bedrijf Aweta uit Nootdorp ontwerpt en maakt sorteer- en verpakkingssystemen voor groenten, bloemen en fruit. Zie http://www.aweta.nl. Dit bedrijf heeft een probleem: er moet een optimale transport methode gekozen worden voor één van de transport systemen. Dit kan prima gebeuren met behulp van een programma dat een simulatie van het transportsysteem uitvoert. Het is natuurlijk het leukst als het simulatieprogramma ook grafisch weergeeft wat er gebeurd.
De probleemomschrijving kun je hier vinden:
Probleem_Transport_Capaciteit.pdf.
