Oplossingen voor het testen van objectgeoriënteerde software

Maat: px
Weergave met pagina beginnen:

Download "Oplossingen voor het testen van objectgeoriënteerde software"

Transcriptie

1 Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

2 1 Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving 2 3 Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes 4 Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

3 Een vierkant in een... Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Soms is compositie een betere oplossing. Maar het is nog steeds oppassen geblazen. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

4 Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Delegatie en niet abstracte methoden in Super Bij overerving van concrete methodes is ook de delegatie-oplossing problematisch, omdat een correct gedrag alleen door het overschrijven van alle, inclusief de concrete, methodes van de basisklasse gegarandeerd kan worden. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

5 Het substitutieprincipe volgens Liskov Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Substitueerbaar betekent: Exemplaren van een subklasse moeten onder alle omstandigheden in de plaats van exemplaren van elke superklasse inzetbaar zijn De pré-condities van iedere methode moeten gelijk of zwakker zijn dan in de superklasse De post-condities van iedere methode moeten gelijk of sterker zijn. Er mogen dus meer garanties gedaan worden, maar niet minder. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

6 Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Voor de zichtbare toestanden betekent dat: Alle zichtbare toestanden en toestandsovergangen (transities) van de superklasse moeten in de subklasse bewaard blijven. In de subklasse mogen transities tussen de toestanden van de superklasse toegevoegd worden. In de subklasse mogen nieuwe zichtbare toestanden toegevoegd worde, zolang deze bestaande toestanden van de superklasse orthogonaal aanvullen ofwel subtoestanden van een reeds bestaande toestand zijn. Het waarborg- en verantwoordelijkheidsprincipe: Een klasse kan geen waarborgen voor eigenschappen van haar superklasse afdwingen. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

7 A deflated world Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Flattening schematisch: We laten de lucht uit de verervingshiärarchie en zien welke vererfde methodes in de subklasses opnieuw getest moeten worden. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

8 Drie regels voor de vererving. Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Een subklasse mag een gebeurtenis van de superklasse in meer toestanden accepteren dan een superklasse. Op deze wijze kunnen we een toestand van de superklasse in subtoestanden partitioneren. Een subklasse mag nieuwe toestanden definiëren wanneer deze orthogonaal ten opzichte van de superklasse zijn, dus deze slechts met nieuwe aspecten uitbreiden. Het effect van private-variabelen van de superklasse op hun toestandsruimte moet orthogonaal ten opzichte van de toestanden van de protected-variabelen zijn. Compact Eis niet meer, beloof niet minder. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

9 Toevallige correctheid door vererving Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving p u b l i c c l a s s Account { p r o t e c t e d Date lasttxdate, today ; i n t newrequestsperday ( i n t n r R e q u e s t s ){ r e t u r n ( n r R e q u e s t s / d a y s S i n c e L a s t T r a n s a c t i o n ( ) ) ; } i n t d a y s S i n c e L a s t T r a n s a c t i o n ( ) { r e t u r n ( today. day ( ) l a s t T x D a t e. txdate ( ) + 1 ) ; } } p u b l i c c l a s s S p e c i a l A c c o u n t extends Account { i n t d a y s S i n c e L a s t T r a n s a c t i o n ( ) { r e t u r n ( today. day ( ) l a s t T x D a t e. txdate ( ) ) ; // newly d e f i n e d } } HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

10 Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Wat er allemaal mis kan gaan bij de vererving. Ontbrekende overschrijvingen: Directe toegang tot attributen: Hoekige plug in een rond gat : Ondeugende kinderen : een subklasse die niet alle berichten van de superklasse accepteert, een subklasse die in een toestand komt die voor de superklasse niet is toegestaan. Wormgaten Verantwoordelijkheidsverschuiving Fat Interface HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

11 Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving en de klasieke fout in java.util: HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

12 Teststrategie bij vererving Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Anti extentionaliteit: Een testsuite resp. de testcases voor één bepaalde implementatie volgens een eis dekken niet noodzakelijkerwijs ook de testcases voor een andere implementatie van dezelfde eis af. Anti-decompositie: De testcoverage voor een klassen- of ketentest dekt niet noodzakelijkerwijs ook de test voor de gebruikte (primitieve) klassen mede af. Anti-compositie De voor delen van een module adequate testcases zijn niet noodzakelijkerwijs ook voor de test over de gehele module voldoende. Objectoriëntatie is dus een Denken in verantwoordelijkheden HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

13 Test volgorde: In de V langs rechts omhoog 1 Methodes, dus functies van een klasse. 2 De klassen met hun methodes. 3 De hoeveelheid van klassen die gezamenlijk een taak in samenwerking uitvoeren. 4 Componenten of subsystemen als werkende bij elkaar horende groepen van hoeveelheden van klassen. 5 Applicatie of systeem. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

14 Structurele richtingen Daar komt nog de samenhang tussen klassen, dus structurele samenhang bij. top-down langs de verervingshiërarchie langs de associaties resp. de associatieketen HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

15 De orthogonale testeisen voor een klassentest HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

16 De twee integratierichtingen architectuur-test: Op basis van de klassendiagrammen wordt langs de klassenhiërarchie door de gegeneraliseerde klasse naar beneden in de richting van de gespecificeerde klassen getest. De superklassen zijn dus altijd het eerste aan de beurt. integratietest voor klassen: Op basis van de sequentiediagrammen wordt langs de associatieketens het samenspel van de afzonderlijke objecten, dus het correcte wederzijdse aanroepen van methodes getest. Daaruit resulteren twee vragen: In welke volgorde moeten de tests in objectgeoriënteerde programma s plaatsvinden? Hoe dienen objectgeoriënteerde programma s gestructureerd te worden zodat deze tests kans op succes hebben? HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

17 Associaties Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes Voorbeelden voor multipliciteitsbeperkingen bij associaties. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

18 Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes Multipliciteiten kunnen tot anomaliën leiden. Invoeganomalie: Gebeurt het invoegen van nieuwe associaties op de juiste plaats binnen de collectie? Veranderingsanomalie: Zijn veranderingen zoals bijvoorbeeld op mijn collectie correct? Wisanomalie: Wordt het juiste element gewist en is de toestand van de collectie na het wissen correct? Bij bi-directionele associaties kan het probleem van inconsistente verbindingen optreden. De heen- en terugverwijzingen passen dan niet bij elkaar (Volgende dia). HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

19 Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes Voorbeeld van een inconsistente bidirectionele associatie Tenslotte moeten de vererfde associaties aan een controle onderworpen worden. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

20 Vererving uit testers perspectief Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes strikt: In een subklasse vinden alleen uitbreidingen van haar superklassen plaats. niet-strikt: In een subklasse wordt basisfunctionaliteit uit de superklassen overschreven. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

21 Strikte vererving Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

22 Problemen bij niet-strikte vererving Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

23 Extra tests bij niet strikte vererving Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes Bij niet strikte vererving kan het voorkomen dat de overschreven methoden ook gebruikt worden in de ander methoden van de superklasse. Dat betekent dat alle vererfde methoden van de superklasse nog een keer getest moeten worden bij het testen van de afgeleide klasse HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

24 De pijltjes bepalen de volgorde Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes Uit het voorgaande vloeit voor onze tests in echte klassenomgevingen, waarin we een vervlechting van vererving en associaties hebben, een duidelijke volgorde voort. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

25 Testvolgorde voor methodes Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes 1 constructoren 2 get-methodes 3 boolean methodes, de is...()-testmethodes 4 set-methodes 5 iteratoren 6 complexe berekeningsmethodes of lokale procesbesturing binnen de klasse 7 overige methodes 8 destructoren HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

26 Invloed van zichtbaarheid (visibility) Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes 1 private alleen klassen intern zichtbaar 2 protected alleen klassen-intern en in afgeleide klassen zichtbaar 3 public overal zichtbaar 4 Default alleen zichtbaar binnen nhet package Het laatste kunnen we gebruiken om de klassen die niet buiten het package zichtbaar moeten zijn toch te kunnen testen. Hetzelfde geldt voor methoden met default visibility. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

27 Modale klasse Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Niet modaal Er zijn geen beperkingen in de volgorde van het aanroepen van methodes of eventsen. Voorbeeld DateTime-klasse Uni-modaal: Er zijn sequentieafhankelijke beperkingen in de volgorde van het aanroepen van methodes en eventsen. Voorbeeld verkeerslicht-klasse Quasi-modaal: Wij vinden inhoudsafhankelijke beperkingen in de volgorde van het aanroepen van methodes en events. Voorbeeld stack-klasse. Modaal: De echte modale klassen hebben bedrijfsspecifieke beperkingen in de volgorde van het aanroepen van methodes en events alsook binnen parallelle functionele gebieden. Voorbeeld Account-klasse. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

28 Aanroepvolgorde en modaliteit. Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Modaliteit zegt dat er een voorgeschreven aanroepvolgorde is. Beide groepen moeten getest worden. Voor de niet-modale methodes zijn er twee tests die in de praktijk deugdelijk zijn gebleken. Tests met verschillende oproepvolgordes Tests met herhaalde aanroepen van dezelfde methode Modale methodes testen we als volgt: Tests in de vereiste volgorde: Functioneert alles zoals het gespecifieerd is? Worden alleen maar correcte toestanden bereikt? Tests van elke verkeerde volgorde: Wijzen de methodes de aanroep in de verkeerde toestand af? Blijft de klasse in een stabiele, correcte toestand? HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

29 Het testpattern Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers geldige aanroepen van methodes die geaccepteerd moeten worden, illegale aanroepen van methodes die afgewezen moeten worden, de resulterende toestand voor het aanroepen van deze beide methodes, De resultaten van iedere aanroep van de methode. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

30 Het testpattern Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Ontbrekende transitie: Een methode wordt afgewezen, hoewel ze bedrijfsspecifiek is toegestaan. Verkeerde actie: Het resultaat voor een bepaalde methode in een bepaalde toestand is verkeerd. Ongeldige resulterende toestand. Corrupte of inconsistente toestand Een geheime zijstraat staat het aanroepen van een methode toe, hoewel die niet toegestaan is. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

31 Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Modale klasse: toestandsmodel van een reservering HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

32 Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Modale klasse: toestandsmodel als boom HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

33 Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Modale klasse: Tabel met toestandsovergangen reserved in use returned cancelled payed reserved in use returned cancelled payed : Geldige overgangen, ongeldige overgangen HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

34 Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Modale hiërarchie: voorbeeld van geometrische klassen HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

35 Testcontext Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Het testpattern voor een subklasse kent de volgende testcontext: De klasse die getest wordt is een concrete subklasse en erft van een modale superklasse, implementeert eigen gedrag en breidt het modale gedrag van de superklasse uit. De klasse moet conform haar eigen toestandsmodel en die van zijn superklasse zijn. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

36 Centrale foutenmogelijkheden Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Een overschrijvende methode in onze subklasse produceert toestanden die een deelverzameling of uitbreidingen van de toestanden van de superklasse zijn, maar zonder de toestanden van de superklasse te kunnen veranderen. De superklasse heeft fouten die echter alleen bij het gebruik in de subklasse optreden. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

37 Andere veel voorkomende fouten Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Alle op toestand gebaseerde fouten van de superklasse worden vererfd. Mogelijke nieuwe, op toestand gebaseerde fouten, die door de uitbreiding in de subklasse kunnen zijn ontstaan. Fouten die ontstaan zijn door de eisen aan de toestanden van de superklasse niet in acht te nemen. Een geldig bericht van de superklasse wordt afgewezen. Een ongeldig bericht van de superklasse wordt geaccepteerd. Naar aanleiding van het bericht van de superklasse vindt er een verkeerde actie plaats. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

38 Klassendiagram Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

39 Teststrategie Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Iedere polymorfe methode moet in de omgeving van haar eigen klasse en in alle client-subklassen, die ze erven, getest worden. Client-klassen van de polymorfe server-klasse mogen door hun overschrijvingen geen fouten veroorzaken. Dit wordt gewaarborgd door zich te houden aan het substitutieprincipe. Daarenboven moet de correctheid van alle implementaties van de basisklassen-interface 1 en zijn afspraken getoetst worden. De tests worden dan als reviews of als automatische test-suites resp. test-scripts uitgevoerd. 1 In ons voorbeeld zijn het de abstracte methodes van GeomFigur. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

Oplossingen voor het testen van objectgeoriënteerde software

Oplossingen voor het testen van objectgeoriënteerde software Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen

Nadere informatie

Objectgeorïenteerd werken is gebaseerd op de objecten die door het systeem gemanipuleerd worden.

Objectgeorïenteerd werken is gebaseerd op de objecten die door het systeem gemanipuleerd worden. Herhaling Objectgeorïenteerd werken is gebaseerd op de objecten die door het systeem gemanipuleerd worden. De basisbouwsteen is het object; een geïntegreerde eenheid van data en operaties werkend op deze

Nadere informatie

Verder zijn er de nodige websites waarbij voorbeelden van objectgeoriënteerd PHP (of Objec Oriented PHP, OO PHP) te vinden zijn.

Verder zijn er de nodige websites waarbij voorbeelden van objectgeoriënteerd PHP (of Objec Oriented PHP, OO PHP) te vinden zijn. Objectgeoriënteerd PHP (versie 5) Kennisvereisten: Ervaring met programmeren in PHP met MySQL Je weet wat een class of klasse is Je weet wat een instantie van een klasse (een object) is Je weet wat een

Nadere informatie

IMP Uitwerking week 13

IMP Uitwerking week 13 IMP Uitwerking week 13 Opgave 1 Nee. Anders moet bijvoorbeeld een venster applicatie een subklasse zijn van zowel Frame en WindowListener. Als de applicatie ook een button of een menu heeft, dan moet het

Nadere informatie

Eindtoets. Opgaven. 1 Gegeven is het domeinmodel van figuur 1. Domeinmodel voor betalingen. Eindtoets I N T R O D U C T I E.

Eindtoets. Opgaven. 1 Gegeven is het domeinmodel van figuur 1. Domeinmodel voor betalingen. Eindtoets I N T R O D U C T I E. Eindtoets I N T R O D U C T I E Deze eindtoets is bedoeld als voorbereiding op het tentamen. Het is belangrijk dat u de eindtoets pas probeert te maken op het moment dat u denkt klaar te zijn met de tentamenvoorbereiding.

Nadere informatie

Zelftest Programmeren in Java

Zelftest Programmeren in Java Zelftest Programmeren in Java Document: n0883test.fm 22/01/2013 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST PROGRAMMEREN IN JAVA Deze test

Nadere informatie

Domeinmodellen en klassendiagrammen

Domeinmodellen en klassendiagrammen Overview Architectuur Deployment-diagram Software-architectuur 1 Architectuur Deployment-diagram Software-architectuur 2 3 Architectuur Architectuur Deployment-diagram Software-architectuur Webapplicatie

Nadere informatie

Deel II: Modelleren en software ontwikkeling. Hoofdstuk 7 Software ontwikkeling - Overzicht. Naïeve benadering

Deel II: Modelleren en software ontwikkeling. Hoofdstuk 7 Software ontwikkeling - Overzicht. Naïeve benadering Deel II: Modelleren en software ontwikkeling Hoofdstuk 7 Software ontwikkeling - Overzicht 2005 Prof Dr. O. De Troyer, pag. 1 Naïeve benadering De vereisten voor het systeem worden geformuleerd en op basis

Nadere informatie

Hoofdstuk 1: Inleiding. Hoofdstuk 2: Klassen en objecten Datahiding: afschermen van implementatiedetails. Naar de buitenwereld toe enkel interfaces.

Hoofdstuk 1: Inleiding. Hoofdstuk 2: Klassen en objecten Datahiding: afschermen van implementatiedetails. Naar de buitenwereld toe enkel interfaces. Hoofdstuk 1: Inleiding Objectoriëntatie: 1. Objecten & klassen: samenwerking van componenten om bepaald doel te bereiken; herbruikbaarheid. 2. Encapsulation: afschermen gedragingen en kenmerken van de

Nadere informatie

VI. Klassen en objecten

VI. Klassen en objecten VI. Klassen en objecten Klassen en objecten vormen het fundament van OOP. We zullen dus uitgebreid aandacht besteden aan klassen en objecten. U kunt Java niet begrijpen zonder goed met klassen en objecten

Nadere informatie

Wat is een grafische gebruikersinterface (GUI)?

Wat is een grafische gebruikersinterface (GUI)? Wat is een grafische gebruikersinterface (GUI)? GUI is een Engelse afkorting voor Graphical User Interface, oftewel grafische gebruikersinterface. Het is de term voor het bedieningspaneel van een computerprogramma.

Nadere informatie

ALGORITME objectgeoriënteerd programmeren

ALGORITME objectgeoriënteerd programmeren ALGORITME objectgeoriënteerd programmeren Gunter Schillebeeckx 1 objectgeoriënteerd programmeren Object Klasse Instantie Eigenschap Methode Inkapseling Polymorfisme Overerving 2 Inleiding Kern Samenvatting

Nadere informatie

Tentamen in2705 Software Engineering

Tentamen in2705 Software Engineering Tentamen in2705 Software Engineering Voorbeeld (bijna tweemaal te groot) U mag meenemen naar dit tentamen: Lethbridge, afdrukken PPT slides, afdrukken handouts. 1. De TU wil een nieuw systeem ontwikkelen

Nadere informatie

Overerving & Polymorfisme

Overerving & Polymorfisme Overerving & Polymorfisme Overerving Sommige klassen zijn speciaal geval van andere klasse Docent is een speciaal geval van werknemer, dwz. elke docent is ook werknemer Functionaliteit van docent = functionaliteit

Nadere informatie

3.1 Opsomming data type

3.1 Opsomming data type Deel I Hoofdstuk 3: Klasse Model - gevorderd 2005 Prof Dr. O. De Troyer Klasse Model - gevorderd pag. 1 3.1 Opsomming data type Opsomming (enumeration) data type Data type waarvan de verzameling waarden

Nadere informatie

Inhoudstafel. UML (Unified Modeling Language)

Inhoudstafel. UML (Unified Modeling Language) UML (Unified Modeling Language) Inhoudstafel Inleiding...2 Waarvoor dient UML...2 Wat is UML... 2 Use-cases... 2 Inleiding...2 Voorbeeld...3 Eigenschappen van een goede use-case...3 Wat is een actor...4

Nadere informatie

1. Welke diagrammen beschrijven het dynamisch gedrag van een applicatie?

1. Welke diagrammen beschrijven het dynamisch gedrag van een applicatie? 1. Welke diagrammen beschrijven het dynamisch gedrag van een applicatie? -Use case-diagram -Use case-beschrijving -Activity diagram -Sequentie diagram 2. Welke diagrammen beschrijven de structuur van de

Nadere informatie

Tentamen Object Georiënteerd Programmeren TI1206 29 oktober 2014, 9.00-11.00 Afdeling SCT, Faculteit EWI, TU Delft

Tentamen Object Georiënteerd Programmeren TI1206 29 oktober 2014, 9.00-11.00 Afdeling SCT, Faculteit EWI, TU Delft Tentamen Object Georiënteerd Programmeren TI1206 29 oktober 2014, 9.00-11.00 Afdeling SCT, Faculteit EWI, TU Delft Bij dit tentamen mag je geen gebruik maken van hulpmiddelen zoals boek of slides. Digitale

Nadere informatie

SYNTRA-WEST. Cursus OOP. Deel

SYNTRA-WEST. Cursus OOP. Deel SYNTRA-WEST Cursus OOP Deel Syntra-West voorheen VORMINGSINSTITUUT VOOR KMO Syntra-West Doorniksesteenweg 220 8500 Kortrijk Tel. 056/26.02.00 Fax 056/22.81.07 i Inhoudsopgave SYNTRA-WEST... 0 CURSUS OOP...

Nadere informatie

Kleine cursus PHP5. Auteur: Raymond Moesker

Kleine cursus PHP5. Auteur: Raymond Moesker Kleine cursus PHP5 Auteur: Raymond Moesker Kleine cursus PHP PHP is platform en CPU onafhankelijk, open source, snel, heeft een grote userbase, het is object georiënteerd, het wordt omarmd door grote bedrijven

Nadere informatie

Deel I Hoofdstuk 2: Het klassenmodel

Deel I Hoofdstuk 2: Het klassenmodel Deel I Hoofdstuk 2: Het klassenmodel 2005 Prof Dr. O. De Troyer Klasse Model pag. 1 Hoofdstuk 2: Het klassenmodel Het Klassenmodel Beschrijft de statische structuur van een systeem door middel van Het

Nadere informatie

Object Oriëntatie Foundation (OOF.NL)

Object Oriëntatie Foundation (OOF.NL) Object Oriëntatie Foundation (OOF.NL) EXIN Hét exameninstituut voor ICT ers Janssoenborch - Hoog Catharijne Godebaldkwartier 365 3511 DT Utrecht Postbus 19147 3501 DC Utrecht Nederland T +31 30 234 48

Nadere informatie

Inhoud leereenheid 2. Overerving (1) Introductie 59. Leerkern 60. Samenvatting 88. Zelftoets 90. Terugkoppeling 94

Inhoud leereenheid 2. Overerving (1) Introductie 59. Leerkern 60. Samenvatting 88. Zelftoets 90. Terugkoppeling 94 Inhoud leereenheid 2 Overerving (1) Introductie 59 Leerkern 60 1 Specialisatie en generalisatie 60 2 Functionaliteit aan een klasse toevoegen 62 2.1 Toegangsspecificaties 63 2.2 Definitie van subklassen

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

Beginselen van programmeren Practicum 1 (Doolhof) : Oplossing

Beginselen van programmeren Practicum 1 (Doolhof) : Oplossing Beginselen van programmeren Practicum 1 (Doolhof) : Oplossing Introductie In dit document geven we een mogelijke oplossing voor het eerste practicum. Deze oplossing gebruikt verschillende klassen en overerving,

Nadere informatie

Informatica. Objectgeörienteerd leren programmeren. Van de theorie met BlueJ tot een spelletje met Greenfoot... Bert Van den Abbeele

Informatica. Objectgeörienteerd leren programmeren. Van de theorie met BlueJ tot een spelletje met Greenfoot... Bert Van den Abbeele Informatica Objectgeörienteerd leren programmeren Van de theorie met BlueJ tot een spelletje met Greenfoot... Bert Van den Abbeele http://creativecommons.org/licenses/by-nc-nd/3.0/legalcode Objectgeörienteerd

Nadere informatie

Oplossingen voor het testen van objectgeoriënteerde software. Oplossingen voor het testen van. Overzicht. Pieter van den Hombergh.

Oplossingen voor het testen van objectgeoriënteerde software. Oplossingen voor het testen van. Overzicht. Pieter van den Hombergh. Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen

Nadere informatie

Die inputs worden op een gecontroleerde manier aangeboden door (test) stubs. De test driver zorgt voor de uiteindelijke uitvoering ervan.

Die inputs worden op een gecontroleerde manier aangeboden door (test) stubs. De test driver zorgt voor de uiteindelijke uitvoering ervan. Nota: Schrijf je antwoorden kort en bondig in de daartoe voorziene velden. De puntenverdeling is 2 punten per theorie-vraag en 8 punten per oefening. Het totaal is 40. Vraag 1. Er bestaan verschillende

Nadere informatie

Programmeren in Java 3

Programmeren in Java 3 26 september 2007 Deze les korte herhaling vorige les Unified Modelling Language notatie van een class afleiding pointers abstracte classes polymorphisme dubieuze(?) constructies interfaces Meer over class

Nadere informatie

Inhoud leereenheid 1. Objectgeoriënteerd ontwerpen. Introductie 17. Leerkern 18. Samenvatting 50. Zelftoets 51. Terugkoppeling 52

Inhoud leereenheid 1. Objectgeoriënteerd ontwerpen. Introductie 17. Leerkern 18. Samenvatting 50. Zelftoets 51. Terugkoppeling 52 Inhoud leereenheid 1 Objectgeoriënteerd ontwerpen Introductie 17 Leerkern 18 1 Objectgeoriënteerd ontwerpen 18 1.1 Softwareontwikkeling 18 1.2 Wat is een goed programma? 24 1.3 Objectkeuze 28 2 UML-diagrammen

Nadere informatie

Les F-02 UML. 2013, David Lans

Les F-02 UML. 2013, David Lans Les F-02 UML In deze lesbrief wordt globaal beschreven wat Unified Modeling Language (UML) inhoudt. UML is een modelleertaal. Dat wil zeggen dat je daarmee de objecten binnen een (informatie)systeem modelmatig

Nadere informatie

Modeleren. Modelleren. Together UML. Waarvan maken we een model? overzicht les 14 t/m 18. ControlCenter 6.2

Modeleren. Modelleren. Together UML. Waarvan maken we een model? overzicht les 14 t/m 18. ControlCenter 6.2 Modelleren Werkelijkheid Modelleren Modeleren Waarvan maken we een model?!analyse " Maak een model van de te automatiseren werkelijkheid of van het op te lossen probleem! Domeinkennis = structuur! Functionele

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

Modulewijzer tirprog02/infprg01, programmeren in Java 2

Modulewijzer tirprog02/infprg01, programmeren in Java 2 Modulewijzer tirprog02/infprg01, programmeren in Java 2 W. Oele 17 november 2009 1 Inhoudsopgave 1 Inleiding 3 2 Studiehouding 3 3 Voorkennis 4 4 Inhoud van deze module 5 5 Leermiddelen 5 6 Theorie en

Nadere informatie

voorbeeldexamen I-Tracks voorbeeldexamen ISDDF Information Systems Design and Development Foundation uitgave april 2005

voorbeeldexamen I-Tracks voorbeeldexamen ISDDF Information Systems Design and Development Foundation uitgave april 2005 voorbeeldexamen Information Systems Design and Development Foundation I-Tracks voorbeeldexamen ISDDF Information Systems Design and Development Foundation uitgave april 2005 inhoud 3 inleiding 4 voorbeeldexamen

Nadere informatie

Programmeren met Java

Programmeren met Java Modulehandleiding voor Programmeren met Java PRO1 Progress code : PRO1 Schooljaar : 2012 2013 Docenten : R.van den Ham / U. Van Heesch Module omvang : 6 credits, 168 studiebelastingsuren Doel Inleiding

Nadere informatie

UML. From weblog http://dsnippert.wordpress.com. Dennis Snippert

UML. From weblog http://dsnippert.wordpress.com. Dennis Snippert UML From weblog http://dsnippert.wordpress.com Naam: Dennis Snippert Inhoudsopgave 1. Wat is Uml?... 3 2. UML diagrammen... 4 3. Uitleg diagrammen... 5 3.1. Usecase diagram:... 5 3.2. Class diagram:...

Nadere informatie

Oplossingen voor het testen van objectgeoriënteerde software

Oplossingen voor het testen van objectgeoriënteerde software Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen

Nadere informatie

et Zend Framework bestaat volledig uit objectgeoriënteerde

et Zend Framework bestaat volledig uit objectgeoriënteerde et Zend Framework bestaat volledig uit objectgeoriënteerde PHP-code. Om het Zend Framework goed te kunnen begrijpen en te kunnen gebruiken, moet u minimaal de basis van objectgeoriënteerd programmeren

Nadere informatie

UML is een visuele taal om processen, software en systemen te kunnen modeleren.

UML is een visuele taal om processen, software en systemen te kunnen modeleren. Vragen inleinding UML 1. Wat is UML? UML is een visuele taal om processen, software en systemen te kunnen modeleren. 2. Waar bestaat UML uit? Notaties(zijn symbolen, commentaar en waarden etc.) en diagrammen(grafische

Nadere informatie

Leertaak 2: Project Vossen & Konijnen

Leertaak 2: Project Vossen & Konijnen Leertaak 2: Project Vossen & Konijnen Tijdens deze leertaak ga je in een projectgroep van minimaal drie, maximaal vier personen werken aan het ontwikkelen van een wat grotere applicatie. De basis is het

Nadere informatie

Op de computer kan naar eigen inzicht software op worden geïnstalleerd, een andere besturingssysteem is mogelijk.

Op de computer kan naar eigen inzicht software op worden geïnstalleerd, een andere besturingssysteem is mogelijk. Planningsfase 1. Afspraken maken over doelstelling en randvoorwaarden De doelstelling van het project: De doelstelling van het project: het maken van het gewenste product. De doelstelling van de student:

Nadere informatie

Codereviews. Codereviews zijn een asynchrone Pair Programming 1 op kleine schaal. Untitled Sheets HOM. Oplossingen voor methodische problemen

Codereviews. Codereviews zijn een asynchrone Pair Programming 1 op kleine schaal. Untitled Sheets HOM. Oplossingen voor methodische problemen Codereviews Codereviews zijn een asynchrone Pair Programming 1 op kleine schaal. Grens en extreme Test van voor: de 1 Twee ontwikkelaars werken gezamenlijk achter een computer. /FHTenL March 9, 2016 1/25

Nadere informatie

Informatica. Deel II: les 1. Java versus Python. Jan Lemeire Informatica deel II februari mei 2014. Parallel Systems: Introduction

Informatica. Deel II: les 1. Java versus Python. Jan Lemeire Informatica deel II februari mei 2014. Parallel Systems: Introduction Informatica Deel II: les 1 Java versus Python Jan Lemeire Informatica deel II februari mei 2014 Parallel Systems: Introduction Arabidopsis (zandraket) Arabidopsis (zandraket) MMIQQA Multimodal Microscopic

Nadere informatie

T3 in het wild While Juni 2004. Tom de Valk 0115665 Tom Evers 0115525 Sjors Meekels 0138630

T3 in het wild While Juni 2004. Tom de Valk 0115665 Tom Evers 0115525 Sjors Meekels 0138630 T3 in het wild While Juni 2004 Tom de Valk 0115665 Tom Evers 0115525 Sjors Meekels 0138630 INHOUDSOPGAVE Inleiding... 2 1. WHILE OO... 3 1.1 Afbakening... 3 1.2 Uitbreidingen... 3 2. Syntax... 4 3. Semantiek...

Nadere informatie

Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V.

Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V. Regressietesten De aanpak en aandachtspunten Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING...3 1.1 ALGEMEEN...3 1.2 VERSIEBEHEER...3

Nadere informatie

Programmeren in Java 3

Programmeren in Java 3 2 september 2007 voor deeltijdstudenten Kop van Zuid Rotterdam, 3 juni 2007 Even voorstellen Naam: Wessel Oele(31) Docent bij opleiding technische informatica Kamer: I210 (tweede verdieping, links de gang

Nadere informatie

4, nov 2011 Vakcode: 192110174

4, nov 2011 Vakcode: 192110174 l J Tentamen lnleiding Object-Georienteerd Programmeren 4, nov 2011 Vakcode: 192110174 Dit tentamen bestaat uit 5 opgaven waarvoor in totaal 90 punten zijn te halen. Het eindcijfer wordt bepaald met de

Nadere informatie

De Vergeten Abstracties

De Vergeten Abstracties De Vergeten Abstracties Cesario Ramos Senior Consultant bij Xebia B.V. 2009 Inleiding Rollen zijn een belangrijk concept in object georiënteerde software ontwikkeling dat vaak vergeten wordt. Het gebruik

Nadere informatie

Datatypes Een datatype is de sort van van een waarde van een variabele, veel gebruikte datatypes zijn: String, int, Bool, char en double.

Datatypes Een datatype is de sort van van een waarde van een variabele, veel gebruikte datatypes zijn: String, int, Bool, char en double. Algemeen C# Variabele Een variabele is een willekeurige waarde die word opgeslagen. Een variabele heeft altijd een datetype ( De soort waarde die een variabele bevat). Datatypes Een datatype is de sort

Nadere informatie

14-9-2015. Scrum in het kort

14-9-2015. Scrum in het kort Les 3 Scrum in het kort Scrum is een agile proces dat het ons mogelijk maakt om de hoogste waarde in de kortste tijd te realiseren. Het maakt het ons mogelijk om snel en regelmatig echt werkende software

Nadere informatie

SmartTestAssistant. Het slimme testhulpmiddel. door Frank Stolker

SmartTestAssistant. Het slimme testhulpmiddel. door Frank Stolker SmartTestAssistant Het slimme testhulpmiddel door Frank Stolker Inhoud Waarom wéér een ander tool? Omdat dit is wat we willen Wat is SmartTestAssistant dan? Hoe zit het in elkaar? Hoe werkt het? Schematische

Nadere informatie

Java. Basissyllabus. Egon Pas

Java. Basissyllabus. Egon Pas Java Basissyllabus Egon Pas 2011 BeanPole bvba Gasmeterlaan 92-9000 Gent BTW BE 472.902.516 Tel: + 32 9 224 42 17 Fax: + 32 9 223 62 88 www.beanpole.be info@beanpole.be 1 Programmeren 1.1 Hoe werkt een

Nadere informatie

Unified Modeling Language

Unified Modeling Language Unified Modeling Language Een introductie voor leden van de expertgroep Informatiemodellen Harmen Mantel, Ordina ICT Management & Consultancy, werkzaam voor KING DOELSTELLING PRESENTATIE GEMEENSCHAPPELIJKE

Nadere informatie

Software Quality Assurance Plan

Software Quality Assurance Plan Software Quality Assurance Plan GameTrac Versie Datum Auteur(s) Opmerking 1.0 10-12-2010 Bram Bruyninckx Eerste iteratie 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn

Nadere informatie

Gebruiksaanwijzing elektronisch slot TeamLock 4

Gebruiksaanwijzing elektronisch slot TeamLock 4 ELEKTRONISCH SLOT MET MINSTENS 111.000.000 ECHTE INSTELMOGELIJKHEDEN Gebruiksaanwijzing elektronisch slot TeamLock 4 Het elektronisch slot TeamLock 4 is een elektronisch sluitsysteem, waarin max. 64 openingscodes

Nadere informatie

Programmeren in Java 3

Programmeren in Java 3 7 maart 2010 Deze les Zelf componenten maken Concurrency (multithreading): werken met threads levenscyclus van een thread starten tijdelijk onderbreken wachten stoppen Zelf componenten maken Je eigen component:

Nadere informatie

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans Canonieke Data Modellering op basis van ArchiMate Canonieke Data Modellering op basis van Archimate Bert Dingemans Abstract Modelleren op basis van de open standard ArchiMate is een goed uitgangspunt voor

Nadere informatie

Object Oriented Ontwerp. Yannick Reekmans

Object Oriented Ontwerp. Yannick Reekmans Yannick Reekmans 2008-2009 22 september 2008 Head First Java (hfstk. 6 blz. 125-164): Arrays & ArrayList; DotComBust game code nakijken Head First Java (hfstk. 10 blz. 302-306): Working with dates Head

Nadere informatie

BEKNOPTE BESCHRIJVING VOORZIENING BRIEFSTEMMEN WATERSCHAPSVERKIEZINGEN 2008

BEKNOPTE BESCHRIJVING VOORZIENING BRIEFSTEMMEN WATERSCHAPSVERKIEZINGEN 2008 BEKNOPTE BESCHRIJVING VOORZIENING BRIEFSTEMMEN WATERSCHAPSVERKIEZINGEN 2008 1. Inleiding Van 13 november tot 25 november om 12.00 uur kiezen de ingezetenen van de waterschappen via directe verkiezingen

Nadere informatie

6 Toepassingsvoorbeelden

6 Toepassingsvoorbeelden Overerving 116 6 Toepassingsvoorbeelden 6.1. oefening 1 : eenvoudige overerving Beschouw volgende basisklasse MoodyObject. MoodyObject pseudo-codes: + MoodyObject( ) # getmood( ):String + querymood( )

Nadere informatie

Software Test Documentation

Software Test Documentation FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN DEPARTMENT OF COMPUTER SCIENCE AND APPLIED COMPUTER SCIENCE Software Test Documentation Software Engineering Nicolas Carraggi, Youri Coppens, Christophe

Nadere informatie

Informatica 2 Studiehandleiding

Informatica 2 Studiehandleiding Informatica 2 Studiehandleiding Embedded Systems Engineering Groep: ES1D ir drs E.J Boks 25-02-2010 Inhoud 1 Inleiding... 2 2 Doelstelling... 3 3 Beoordeling... 4 4 Eisen aan het verslag... 6 Voorbeeld

Nadere informatie

Aan het eind van deze lesbrief wordt uitgelegd wat het nut van OOP is en vind je een aantal oefenopdrachten.

Aan het eind van deze lesbrief wordt uitgelegd wat het nut van OOP is en vind je een aantal oefenopdrachten. Doel van deze lesbrief Deze lesbrief is bedoeld om je op de hoogte te brengen van de basisbegrippen die gangbaar zijn bij object georiënteerd programmeren (OOP). In deze lesbrief kom je korte codefragmenten

Nadere informatie

Uitwerking Aanvullend tentamen Imperatief programmeren Woensdag 24 december 2014, 13.30 15.30 uur

Uitwerking Aanvullend tentamen Imperatief programmeren Woensdag 24 december 2014, 13.30 15.30 uur Uitwerking Aanvullend tentamen Imperatief programmeren Woensdag 24 december 2014, 13.30 15.30 uur 1. deze opgave telt voor 30% van het totaal. Schrijf een compleet programma, dat door de gebruiker vanaf

Nadere informatie

Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015

Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Software Test Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 1 Versie

Nadere informatie

Klassen & objecten, overerving, abstracte klassen, debuggen, interfaces, formulieren, polymorfie, statische methoden, event-handlers

Klassen & objecten, overerving, abstracte klassen, debuggen, interfaces, formulieren, polymorfie, statische methoden, event-handlers 1 Inhoud Klassen & objecten, overerving, abstracte klassen, debuggen, interfaces, formulieren, polymorfie, statische methoden, event-handlers 2 Geluidsbronnen simulator, deel 2 Inleiding De weergave versnellen

Nadere informatie

Tim Mallezie Architectuur van besturingssystemen: Vraag A2.

Tim Mallezie Architectuur van besturingssystemen: Vraag A2. Procesbeheer: kenmerken van moderne besturingssystemen. 1. Bespreek de (drie) meest typische kenmerken van moderne besturingssystemen. 2. In hoeverre beantwoorden UNIX, Linux en Windows NT hieraan? Geef

Nadere informatie

Workshop 12 ART-DECOR en Acute overdracht. Michael Tan Kai Heitmann Maarten Ligtvoet

Workshop 12 ART-DECOR en Acute overdracht. Michael Tan Kai Heitmann Maarten Ligtvoet Workshop 12 ART-DECOR en Acute overdracht Michael Tan Kai Heitmann Maarten Ligtvoet 22 november 2012 Topics Aanpak en visie Perinatologie Michael Tan Uitleg Acute Overdracht in ART-DECOR Kai Heitmann Faciliteren

Nadere informatie

HOGESCHOOL ROTTERDAM

HOGESCHOOL ROTTERDAM HOGESCHOOL ROTTERDAM IAN02 - Informatie-analyse (objectgeoriënteerde analyse) M O D U L E W I J Z E R I A N 0 2 1 V A N 1 5 Modulecode: IAN02 Modulenaam: Informatieanalyse 2 Belasting (aantal cp): 2 Bestemd

Nadere informatie

Unified Modeling Language

Unified Modeling Language Unified Modeling Language Een overzicht Danny Greefhorst Matthijs Maat 19 december 1997 Copyright 1997 Software Engineering Research Centre All rights reserved. Software Engineering Research Centre Stichting

Nadere informatie

Informatica. Deel II: les 1. Java versus Python. Jan Lemeire Informatica deel II februari mei 2015. Parallel Systems: Introduction

Informatica. Deel II: les 1. Java versus Python. Jan Lemeire Informatica deel II februari mei 2015. Parallel Systems: Introduction Informatica Deel II: les 1 Java versus Python Jan Lemeire Informatica deel II februari mei 2015 Parallel Systems: Introduction Arabidopsis (zandraket) Arabidopsis (zandraket) MMIQQA Multimodal Microscopic

Nadere informatie

Sjabloon testspecificatie. <>

Sjabloon testspecificatie. <<Organisatie>> Sjabloon testspecificatie SYSQA B.V. Almere : Status : Opgesteld door : Organisatie Pagina 2 van 5 Inhoudsopgave Inleiding...3 1 Analyse functiebeschrijving...4

Nadere informatie

HvA Instituut voor Interactieve Media ActionScript 3.0

HvA Instituut voor Interactieve Media ActionScript 3.0 PPRO 1: OEFENINGEN LES 1 Hierbij de werkgroepoefeningen behorend bij het practicum week 1. Lees de stukken uitleg aandachtig door, zonder deze informatie zullen de principes in de oefeningen moeilijk te

Nadere informatie

SYNTRA-WEST. Initiatiecursus JAVA. Deel

SYNTRA-WEST. Initiatiecursus JAVA. Deel SYNTRA-WEST Initiatiecursus JAVA Deel Syntra-West Syntra-West (vroeger Vormingsinstituut West-Vlaanderen) Doorniksesteenweg 220 8500 Kortrijk Tel. 056/26.02.00 Fax 056/22.81.07 i Inhoudsopgave SYNTRA-WEST...

Nadere informatie

Vraag 1... Vraag 2... Vraag 3...

Vraag 1... Vraag 2... Vraag 3... Nota: Schrijf je antwoorden kort en bondig in de daartoe voorziene velden. Elke theorie-vraag staat ofwel op 1.5 ofwel op 2 punten, en elke oefening op 10 punten. Het geheel staat op 60. Vraag 1...[.../3]

Nadere informatie

Software Test Document

Software Test Document Software Test Document PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie

Nadere informatie

Een inleiding in de Unified Modeling Language 67

Een inleiding in de Unified Modeling Language 67 Een inleiding in de Unified Modeling Language 67 1.4.5. Toepassing 5: Klasse Kaart. De opdracht bestaat erin algemene klassen te maken zodanig dat het mogelijk wordt om het even welk kaartspel te maken.

Nadere informatie

Top-down ontwerpen. Concentreren op de hoofdzaak zonder rekening te houden met allerlei details.

Top-down ontwerpen. Concentreren op de hoofdzaak zonder rekening te houden met allerlei details. Top-down ontwerpen Concentreren op de hoofdzaak zonder rekening te houden met allerlei details. Dus: de belangrijkste entiteittypes en hun onderlinge structuur proberen te vinden. De relaties in tekst

Nadere informatie

Datastructuren en algoritmen

Datastructuren en algoritmen Datastructuren en algoritmen Doelstelling Datastructures + algorithms = programs Boek van Niklaus Wirth: bedenker Pascal en Modula Datastructuur: structuur om informatie op te slaan Algoritme: voorschrift

Nadere informatie

Vier aandachtspunten bij het specificeren van digitaal geregelde voedingen

Vier aandachtspunten bij het specificeren van digitaal geregelde voedingen Vier aandachtspunten bij het specificeren van digitaal geregelde voedingen De industrie staat soms nog wat afwachtend tegenover digitaal geregelde voedingen omdat engineers, anders dan bij de traditionele

Nadere informatie

Voorbeeldvraag 1. Welke uitspraak is JUIST:

Voorbeeldvraag 1. Welke uitspraak is JUIST: Voorbeeldvraag 1 Welke uitspraak is JUIST: 1. De basisstelling van Nicolas Carr (auteur van "IT doesn't matter") is dat de investeringen die in IT gedaan worden niet opwegen tegen de voordelen ervan. Het

Nadere informatie

Inleiding Software Engineering! Unit Testing, Contracten, Debugger! 13 Februari 2014!

Inleiding Software Engineering! Unit Testing, Contracten, Debugger! 13 Februari 2014! Inleiding Software Engineering Unit Testing, Contracten, Debugger 13 Februari 2014 Beknopte info over Unit Testing en Contracten kan je vinden op het einde van dit document. Eclipse beschikt over een handige

Nadere informatie

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter 2 Opdrachtgever : Opdrachtnemers : Ing. P. van den Berg Michel van Reenen Thijs Mommen GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

Nadere informatie

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER Sander Hoogendoorn Versie 1.0 15 april 2002 Documentbeheer Versie Datum Auteur Omschrijving 0.1 15 April 2002 Sander Hoogendoorn 0.2 15 april

Nadere informatie

OBJECT SPAGHETTI : PATTERNS BIEDEN UITKOMST? Wat is het probleem nou eigenlijk? public class CoffeeDrinker { private CoffeeProducer mycoffeeproducer;

OBJECT SPAGHETTI : PATTERNS BIEDEN UITKOMST? Wat is het probleem nou eigenlijk? public class CoffeeDrinker { private CoffeeProducer mycoffeeproducer; OBJECT SPAGHETTI : PATTERNS BIEDEN UITKOMST? Object georiënteerde (OO) systemen kennen vele voordelen ten opzichte van traditionele procedurele systemen. Zo zouden OO systemen flexibeler en beter onderhoudbaar

Nadere informatie

VB Magazine Online 2004 01/08 1 / 6

VB Magazine Online 2004 01/08 1 / 6 Een van de krachtigste elementen binnen Visual Basic 2003 vind ik wel de mogelijkheid om objecten te overerven; ook wel inheritance genoemd. U kunt niet alleen uw eigen classes en business objecten overerven,

Nadere informatie

Unit testen van EJB's. Koert Zeilstra - iprofs

Unit testen van EJB's. Koert Zeilstra - iprofs Unit testen van EJB's Koert Zeilstra - iprofs Inleiding We weten tegenwoordig allemaal dat we ons product moeten testen om de kwaliteit te verhogen en behouden Software-ontwikkelaars zijn over het algemeen

Nadere informatie

Ontwikkelen en testen van e-business: beheerste dynamiek

Ontwikkelen en testen van e-business: beheerste dynamiek Ontwikkelen en testen van e-business: beheerste dynamiek Het ontwikkelen en gestructureerd testen van administratieve systemen is gebaseerd het watervalprincipe. Bij het ontwikkelen volgens het watervalprincipe

Nadere informatie

NHibernate als ORM oplossing

NHibernate als ORM oplossing NHibernate als ORM oplossing Weg met de SQL Queries Wat is ORM? ORM staat in dit geval voor Object Relational Mapping, niet te verwarren met Object Role Modeling. ORM vertaalt een objectmodel naar een

Nadere informatie

Vakgroep CW KAHO Sint-Lieven

Vakgroep CW KAHO Sint-Lieven Vakgroep CW KAHO Sint-Lieven Objecten Programmeren voor de Sport: Een inleiding tot JAVA objecten Wetenschapsweek 20 November 2012 Tony Wauters en Tim Vermeulen tony.wauters@kahosl.be en tim.vermeulen@kahosl.be

Nadere informatie

TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN

TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN Copyright Sogeti Nederland B.V. te Vianen Niets uit deze uitgave mag verveelvoudigd en/of openbaar worden gemaakt (voor willekeurig welke doeleinden)

Nadere informatie

HOGESCHOOL ROTTERDAM

HOGESCHOOL ROTTERDAM HOGESCHOOL ROTTERDAM INA02 - Informatie-analyse (objectgeoriënteerde analyse) M O D U L E W I J Z E R I N F I N A 0 2 1 V A N 18 Modulecode: IAN02 Modulenaam: Informatieanalyse 2 Belasting (aantal cp):

Nadere informatie

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;

Nadere informatie

Objectgericht programmeren 1

Objectgericht programmeren 1 KU Leuven Campus De Nayer Industrieel ingenieur 3Ba Elektronica-ICT Objectgericht programmeren 1 Academiejaar 2014-15 Lesgever: J. Vennekens Cursustekst ism. H. Crauwels II Inhoudsopgave 1 Inleiding 1

Nadere informatie

Inhoud Deel een Het ontwikkeltraject 1 2 3

Inhoud Deel een Het ontwikkeltraject 1 2 3 5 Inhoud Inleiding 11 Deel een Het ontwikkeltraject 13 1 Werken binnen organisaties 15 1.1 Non-profit-organisatie 15 1.2 Profit-organisatie 16 1.3 Doelen 16 1.4 Rechtsvormen 16 Rechtspersoon 17 Persoonlijke

Nadere informatie

INFITT01 Internettechnologie WEEK 2

INFITT01 Internettechnologie WEEK 2 INFITT01 Internettechnologie WEEK 2 Programma Contexts Listeners Scope/Attributes Thread safety Taken container Een servlet draait in een container (servlet container). De container, die ten dienste van

Nadere informatie

ELEKTRONISCH SLOT MET MINSTENS 111.000.000 ECHTE INSTELMOGELIJKHEDEN EIGENSCHAPPEN VAN HET SLOT, FABRIEKSINSTELLINGEN

ELEKTRONISCH SLOT MET MINSTENS 111.000.000 ECHTE INSTELMOGELIJKHEDEN EIGENSCHAPPEN VAN HET SLOT, FABRIEKSINSTELLINGEN ELEKTRONISCH SLOT MET MINSTENS 111.000.000 ECHTE INSTELMOGELIJKHEDEN Master-programmeeraanwijzing van het elektronisch slot TeamLock 4 Het elektronisch slot TeamLock 4 is een elektronisch sluitsysteem,

Nadere informatie