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

Save this PDF as:
 WORD  PNG  TXT  JPG

Maat: px
Weergave met pagina beginnen:

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

Transcriptie

1 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 hiervan wordt de code geschreven 2005 Prof. Dr. O. De Troyer pag. 2 1

2 Naïeve benadering Deze benadering leidt vrijwel altijd tot problemen: Meer tijd nodig dan voorzien Meer middelen (geld) nodig dan voorzien Voldoet niet aan de verwachtingen Methoden voor het ontwikkelen van software zijn noodzakelijk 2005 Prof. Dr. O. De Troyer pag. 3 Software ontwikkelingsmethode Een software ontwikkelingsmethode biedt twee vormen van hulp: Een stappenplan (proces) dat men kan volgen Meestal gebaseerd op het maken van modellen Een aantal notaties om de modellen in neer te schrijven Meestal grafisch 2005 Prof. Dr. O. De Troyer pag. 4 2

3 Software ontwikkelingsmethode UML is vrij populair als standaard notatie voor OO ontwikkeling Er is minder eensgezindheid over het te gebruiken proces 2005 Prof. Dr. O. De Troyer pag. 5 Het waterval proces 2005 Prof. Dr. O. De Troyer pag. 6 3

4 2005 Prof. Dr. O. De Troyer pag. 7 Het waterval ontwikkelingsproces Elke stap (fase) vertegenwoordigt een andere activiteit Basis aannames van het waterval ontwikkelingsproces De verschillende stappen vinden sequentieel plaats Elke fase moet volledig beëindigd zijn voor de volgende kan aangevangen worden Meestal is er wel een vorm van feedback tussen de verschillende fasen 2005 Prof. Dr. O. De Troyer pag. 8 Het waterval ontwikkelingsproces Oudste ontwikkelingsproces Goed voor wel gekende systemen met weinig problemen en stabiele requirements Dit is echter zelden het geval Nadelen Het succes van het systeem enkel te verifiëren door testen Testen kan pas op het einde van het volledige proces Hoog risico: We kunnen enkel zien of het systeem voldoet wanneer al het werk al gedaan is 4

5 Iteratief ontwikkelingsproces Antwoord op de tekortkomingen van het waterval proces: Incrementeel: volledig systeem wordt deel per deel ontwikkeld Iteratief: de verschillende fasen van het ontwikkelingsproces worden verschillende keren herhaald De moderne ontwikkelingsprocessen zijn allemaal iteratief en incrementeel 2005 Prof. Dr. O. De Troyer pag. 9 Spiraal proces model Uitgangspunt: Meestal onmogelijk om iets van de eerste keer juist te hebben Daarom worden de verschillende fasen verschillende malen herhaald De 4 kwadranten vertegenwoordigen de belangrijkste fasen Geen vast proces 2005 Prof. Dr. O. De Troyer pag. 10 5

6 Unified Process (UP) Verschillende activiteiten (workflows) in verschillende iteraties Verschillende fasen Elke fasen bevat verschillende iteraties 2005 Prof. Dr. O. De Troyer pag. 11 De balans tussen de activiteiten is verschillend voor verschillende fasen UML en UP UML kan gebruikt worden met verschillende ontwikkelingsprocessen Omdat UP ontwikkeld werd door de ontwerpers van UML wordt UML vaak gebruikt in combinatie met UP 2005 Prof. Dr. O. De Troyer pag. 12 6

7 Ontwikkelingsfasen Systeem conceptie Analyse Design Implementatie Testen Training Ingebruikname Onderhoud 2005 Prof. Dr. O. De Troyer pag. 13 Ontwikkelingsfasen Systeem conceptie Bedenken van de applicatie; formuleren van de initiële vereisten 2005 Prof. Dr. O. De Troyer pag. 14 7

8 Ontwikkelingsfasen Analyse Doel is specificeren wat moet ontwikkeld worden; niet hoe het zal gebeuren Het probleem/systeem moet men begrijpen voor men het kan oplossen/maken Input: bestaande documenten, interviews, bestaande toepassingen,... Modellen om de problematiek te begrijpen 2005 Prof. Dr. O. De Troyer pag. 15 Ontwikkelingsfasen Analyse omvat: Domein analyse Het analyseren van het domein deel van de reële wereld dat relevant is voor het systeem Het maken van het domein model Beschrijft de relevante objecten en relaties in het domein Applicatie analyse (ook wel systeem analyse genoemd) Focus is nu op de applicatie/het systeem zelf. Verschillende gebruikers, gevraagde functionaliteit E.g. Applicatie objecten ipv domein objecten» bestaan niet in het domein maar zijn relevant voor de applicatie Het applicatie model beschrijft het systeem van buiten af (niet de implementatie - zwarte doos principe) 2005 Prof. Dr. O. De Troyer pag. 16 8

9 Ontwikkelingsfasen Systeem Design Ontwerp van de architectuur van het systeem Architectuur: Hoog niveau plan van het systeem Beslissen over strategieën Klasse Design Meer gedetailleerde modellen gericht op het realiseren van het systeem Gebaseerd op de resultaten van de analyse fase en rekening houdend met het systeem design 2005 Prof. Dr. O. De Troyer pag. 17 Ontwikkelingsfasen Implementatie Het programmeren Ontwerp modellen moeten vertaald worden naar code Tools kunnen tot op zeker niveau automatisch code genereren 2005 Prof. Dr. O. De Troyer pag. 18 9

10 Ontwikkelingsfasen Testen Om fouten uit de software te halen Om na te gaan dat het systeem inderdaad aan de verwachtingen voldoet Zowel wat betreft functionaliteit Als wat betreft gebruikersgemak Testen is niet enkel op het einde van het ontwikkelingsproces maar gedurende het gehele traject! 2005 Prof. Dr. O. De Troyer pag. 19 Ontwikkelingsfasen Training Opleiden van de gebruikers Hoeveelheid afhankelijk van het systeem en de gebruikers 2005 Prof. Dr. O. De Troyer pag

11 Ontwikkelingsfasen Ingebruikname (deployment) Installatie scripts nodig Interactie met andere systemen mogelijk Verschillen wat betreft OS Soms lokalisatie nodig (aanpassen aan de lokale gewoonten - taal, cultuur,...) 2005 Prof. Dr. O. De Troyer pag. 21 Ontwikkelingsfasen Onderhoud Oplossen van bugs Nieuwe vereisten 2005 Prof. Dr. O. De Troyer pag

12 Overzicht 2005 Prof. Dr. O. De Troyer pag. 23 Analyse Probleembeschrijving (in natuurlijke taal) is de input Onvolledig, niet precies, niet consistent Analyse moet dit omzetten naar precieze, ondubbelzinnige modellen Domein Analyse & Applicatie Analyse 2005 Prof. Dr. O. De Troyer pag

13 Overzicht 2005 Prof. Dr. O. De Troyer pag. 25 Domein analyse Beschrijving van de domein (deel van de reële wereld) Domein klassenmodel Domein toestandsmodel Domein interactiemodel 2005 Prof. Dr. O. De Troyer pag

14 Domein Klassenmodel Domein klassenmodel klassen en relaties van het domein Statische structuur is meestal stabieler dan de andere aspecten Daarom belangrijk vertrekpunt Initieel model bevat meestal tekortkomingen Verbeteren door iteraties 2005 Prof. Dr. O. De Troyer pag. 27 Domein toestandsmodel Maak een toestandsmodel indien relevant Identificeer klassen met toestandsafhankelijk gedrag Maak de toestandsdiagrammen 2005 Prof. Dr. O. De Troyer pag

15 Domein interactiemodel Een interactiemodel is zelden relevant voor domein analyse Nadruk ligt op de structuur van het domein 2005 Prof. Dr. O. De Troyer pag. 29 Overzicht 2005 Prof. Dr. O. De Troyer pag

16 Applicatie analyse Beschrijving van de applicatie Applicatie interactiemodel Applicatie klassenmodel Applicatie toestandsmodel 2005 Prof. Dr. O. De Troyer pag. 31 Applicatie interactiemodel Stappenplan Baken de grenzen van het systeem af Bepaal de actoren Bepaal use cases Komen tot sequentiediagrammen Maak scenario s voor de use cases Voeg variaties en uitzonderingen toe Maak sequentiediagrammen voor de scenario s Maak activiteiten diagrammen voor complexe use cases Organiseer de actors en use cases Check af met het domein model 2005 Prof. Dr. O. De Troyer pag

17 Baken de grenzen af Use cases delen het systeem op in delen en tonen wie betrokken is met elke deel Ze beschrijven echter niet het dynamisch gedrag 2005 Prof. Dr. O. De Troyer pag. 33 Applicatie interactiemodel Stappenplan Baken de grenzen van het systeem af Bepaal de actoren Bepaal use cases Komen tot sequentiediagrammen Maak scenario s voor de use cases Voeg variaties en uitzonderingen toe Maak sequentiediagrammen voor de scenario s Maak activiteiten diagrammen voor complexe use cases Organiseer de actors en use cases Check af met het domein model 2005 Prof. Dr. O. De Troyer pag

18 Applicatie interactiemodel Stappenplan Baken de grenzen van het systeem af Bepaal de actoren Bepaal use cases Komen tot sequentiediagrammen Maak scenario s voor de use cases Voeg variaties en uitzonderingen toe Maak sequentiediagrammen voor de scenario s Maak activiteiten diagrammen voor complexe use cases Organiseer de actors en use cases Check af met het domein model 2005 Prof. Dr. O. De Troyer pag. 35 Maak activiteitendiagrammen Maak activiteitendiagrammen voor complexe use cases Sequentiediagrammen geven niet duidelijk weer wanneer er keuze en alternatieven zijn 2005 Prof. Dr. O. De Troyer pag

19 Applicatie interactiemodel Stappenplan Baken de grenzen van het systeem af Bepaal de actoren Bepaal use cases Komen tot sequentiediagrammen Maak scenario s voor de use cases Voeg variaties en uitzonderingen toe Maak sequentiediagrammen voor de scenario s Maak activiteiten diagrammen voor complexe use cases Organiseer de actors en use cases Check af met het domein model 2005 Prof. Dr. O. De Troyer pag. 37 Organiseer actors en use case Toevoegen van include, extend en generalizatie 2005 Prof. Dr. O. De Troyer pag

20 Applicatie interactiemodel Stappenplan Baken de grenzen van het systeem af Bepaal de actoren Bepaal use cases Komen tot sequentiediagrammen Maak scenario s voor de use cases Voeg variaties en uitzonderingen toe Maak sequentiediagrammen voor de scenario s Maak activiteiten diagrammen voor complexe use cases Organiseer de actors en use cases Check af met het domein model 2005 Prof. Dr. O. De Troyer pag. 39 Check af met domein model De modellen moeten consistent zijn met het domein model Actors, use cases, scenario's moeten gebaseerd zijn op klassen en concepten uit het domein model Check of het domein model voldoende is voor de diverse scenario's 2005 Prof. Dr. O. De Troyer pag

21 Applicatie analyse Beschrijving van de applicatie Applicatie interactiemodel Applicatie klassenmodel Applicatie toestandsmodel 2005 Prof. Dr. O. De Troyer pag. 41 Applicatie klassenmodel Definieert nu de klassen van de applicatie zelf 2005 Prof. Dr. O. De Troyer pag

22 Applicatie toestandsmodel De klassen van de applicatie hebben meestal belangrijk toestandsafhankelijk gedrag Stappenplan Zoek de applicatieklassen met toestandsafhankelijk gedrag Maak de toestandsdiagrammen Check met de andere modellen voor consistentie 2005 Prof. Dr. O. De Troyer pag. 43 Voeg operaties toe aan applicatie klassenmodel Definieer operaties voor de applicatie klassen Basis operaties om attributen en associaties op te vragen/wijzigen Mogen gedurende analyse weggelaten worden Operaties afkomstig van de interactie modellen Operaties afkomstig van reële wereld operaties 2005 Prof. Dr. O. De Troyer pag

23 Overzicht 2005 Prof. Dr. O. De Troyer pag Prof. Dr. O. De Troyer pag. 46 Klasse Design Doel Analyse model verder uitwerken richting implementatie rekening houdend met de systeem design Niet nodig om te veranderen van techniek want OO geschikt voor analyse, design en implementatie Niet nodig om een nieuw model te maken; we kunnen vertrekken van de applicatie klasse uit het applicatie klassenmodel 23

24 2005 Prof. Dr. O. De Troyer pag. 47 Klasse Design Applicatie klassen verder uitwerken rekening houdend met Uitvoeringstijd Geheugen Ander kostfactoren Beslissen over algoritmen Opsplitsen van complexe operaties Detail toevoegen - aanpassingen maken Iteratief proces Implementatie Implementatie door middel van OO taal is meest voor de handliggend, bijv. Java, C++, C# OO talen hebben ook klassen en instanties Voor sommige zaken is er geen overeenkomstig implementatie constructie: associaties toestandsdiagrammen Gebruik een systematisch en consistente benadering voor het implementeren ervan 2005 Prof. Dr. O. De Troyer pag

25 Implementeren van klassen en instanties Klasse en instanties Ook in OO-talen Terminologie kan licht verschillen, voorbeelden: Instantie variabelen ipv attributen Extend/derive ipv inherit Static methods ipv Klasse methoden Er kunnen beperkingen of relaxaties zijn Bijv. geen multiple inheritance Bijv. Geen standaard encapsulatie van attributen Pure OO talen (bijv. Smalltalk) hebben geen ingebouwde datatypen en dus ook geen waarden (enkel objecten) Meestal expliciete constructor Opgelet met inheritance (zie later) 2005 Prof. Dr. O. De Troyer pag. 49 Implementatie Type verificatie en polymorfisme Polymorfisme Verschillende operaties in verschillende klasse kunnen dezelfde naam hebben. Vraag: welke methode moet gebruikt worden wanneer zo n operatie opgeroepen wordt voor een object Oplossing late binding bij uitvoering wordt opgezocht tot welke klasse het object behoort. Indien in deze klasse een methode bestaat die de operatie implementeert dan wordt deze methode gebruikt 2005 Prof. Dr. O. De Troyer pag

26 Implementeren van associaties in een programmeertaal Associaties kunnen worden geïmplementeerd via referentie (pointers) attributen Maar: Laten maar navigatie toe in één enkele richting Leg de verantwoordelijkheid voor het bijhouden en wijzigen van de referentie bij slechts één klasse Andere klassen hebben enkel toegang via een interface (operaties: getxxx, setxxx) 2005 Prof. Dr. O. De Troyer pag. 51 Implementeren van associaties in een programmeertaal Geval 1: associatie wordt maar in één richting doorlopen Implementeer de associatie via een referentie (pointer) attribuut naar het object in de vertrekklasse Is de multipliciteit 1 dan simpele referentie zoniet verzameling van referenties Een data structuur zoals een vector kan hiervoor gebruikt worden 2005 Prof. Dr. O. De Troyer pag

27 Implementeren van associaties in een programmeertaal 2005 Prof. Dr. O. De Troyer pag. 53 Implementeren van associaties in een programmeertaal Multipliciteit moet in de code gecheckt worden public Person(Company c) { if (c == null) { // throw NullLinkError } Employeer = c ; } 2005 Prof. Dr. O. De Troyer pag

28 Implementeren van associaties in een programmeertaal Geval 2: associatie wordt in beide richtingen doorlopen Implementeer maar 1 richting via een referentie (pointer) attribuut in één van de 2 klassen De andere richting moet dan via een zoekfunctie Enkel zinvol wanneer de niet geïmplementeerde richting maar sporadisch dient gebruikt te worden 2005 Prof. Dr. O. De Troyer pag. 55 Implementeren van associaties in een programmeertaal Geval 2: associatie wordt in beide richtingen doorlopen Implementeer beide richtingen Beide richtingen via een referentie (pointer) attribuut naar het object Voordeel : voor beide richtingen snelle toegang Nadeel: bij update moeten beide referenties aangepast worden Maak slechts 1 van de 2 klassen verantwoordelijk voor het onderhoud van de links 2005 Prof. Dr. O. De Troyer pag

29 Implementeren van associaties in een programmeertaal 2005 Prof. Dr. O. De Troyer pag. 57 Implementeren van associaties in een programmeertaal Geval 2: associatie wordt in beide richtingen doorlopen Implementeer via een associatie object 2005 Prof. Dr. O. De Troyer pag

30 Implementeren van associaties in een programmeertaal Toegang minder snel dan bij het gebruik van referenties Hashing techniek voor constante toegangstijd Goed wanneer niet alle objecten van de klassen links hebben Enkel ruimte voor de bestaande links 2005 Prof. Dr. O. De Troyer pag. 59 Implementeren van een associatie klasse Associatie met een associatieklasse Introduceer klasse voor associatie 2005 Prof. Dr. O. De Troyer pag

31 Implementeren van een associatie klasse class Registration { Registration(Student st) { student = st ; mark = 0 ; } private Student student ; private int mark ; } 2005 Prof. Dr. O. De Troyer pag. 61 Implementeren van een associatie klasse public class Module { private Vector registrations ; public void enrol(student st) { registrations.addelement( new Registration(st)) ; } } 2005 Prof. Dr. O. De Troyer pag

32 Relationele database Implementeren van klassen in een database Indien een identificerend attribuut Indien geen identificerend attribuut 2005 Prof. Dr. O. De Troyer pag. 63 Relationele database 1-to-many case Implementeren van associaties in een database 2005 Prof. Dr. O. De Troyer pag

33 Relationele database many-to-many case Implementeren van associaties in een database 2005 Prof. Dr. O. De Troyer pag. 65 Implementatie van compositie Sommige OO talen (bijv C++) laten toe dat objecten andere objecten bevatten dus compositie Andere talen (bijv Java) laten alleen een referentie naar een ander object toe. De eigenschappen van compositie (gelijktijdig bestaan) moet afgedwongen worden door middel van code 2005 Prof. Dr. O. De Troyer pag

34 Implementeren van toestanddiagrammen Oplossing 1: door het bijhouden van de toestand door middel van een attribuut public class Account { private final int InCredit = 0 ; private final int OverDrawn = 1 ; private final int Suspended = 2 ; private int state ; // } 2005 Prof. Dr. O. De Troyer pag. 67 Implementeren van toestanddiagrammen 2005 Prof. Dr. O. De Troyer pag

35 Implementeren van toestanddiagrammen Initiële toestand implementeren via de constructor public Account() { state = InCredit ; } Implementeren van de operaties via een switch public void withdraw(double amt) { switch (State) { case InCredit: if (amt > bal) { state = Overdrawn; } bal -= amt ; break ; case Overdrawn: case Suspended: break ; } } 2005 Prof. Dr. O. De Troyer pag. 69 Implementeren van toestanddiagrammen Groepeer toestanden voor samengestelde toestanden public void suspend() { switch (state) { case InCredit: case Overdrawn: state = Suspended ; break ; case Suspended: break ; } } 2005 Prof. Dr. O. De Troyer pag

36 Implementeren van toestanddiagrammen (2) Oplossing 2: Representeer elke toestand door een klasse (toestandsklasse) Elke toestandsklasse implementeert dan het gedrag voor elke operatie geldig in die toestand 2005 Prof. Dr. O. De Troyer pag. 71 Implementeren van toestanddiagrammen (2) Algemeen geval: De context klasse representeert de klasse met toestandsafhankelijk gedrag De toestanden worden voorgesteld door instanties van de Stateklassen: Elk context-object is geassocieerd met juist 1 state-object op elk moment in de tijd Wanneer een context-object een request krijgt delegeert hij dit daar het relevante state-object (door polymorfisme) 2005 Prof. Dr. O. De Troyer pag

37 Implementeren van toestanddiagrammen (2) 2005 Prof. Dr. O. De Troyer pag. 73 Or more general Implementeren van toestanddiagrammen (2) 2005 Prof. Dr. O. De Troyer pag

38 Implementeren van toestanddiagrammen Een gevolg is dat elke toestandsklasse toegang moet hebben tot het interne van de context klasse (zondigt tegen het principe van encapsulatie) 2005 Prof. Dr. O. De Troyer pag. 75 Goede en slechte programma ontwerpen Wanneer is een programma ontwerp goed? Goed Modelleert een systeem dat aan de verwachtingen van de gebruiker zal voldoen Is flexibel Requirements veranderen snel! De impact van veranderingen moet zo klein mogelijk zijn Realiseerbaar 2005 Prof. Dr. O. De Troyer pag

39 Ontwerpprincipes voor programma s 1. Lage graag van koppeling: low coupling 2. Abstractie 3. Hoge graad van samenhang: high cohesion 4. Hergebruik 5. Vervangbaarheid 6. Open-closed principe 2005 Prof. Dr. O. De Troyer pag. 77 Low coupling: encapsulatie Het principle van encapsulatie ondersteunt het principe van low coupling Hoe minder koppelingen, hoe gemakkelijker dingen kunnen gewijzigd worden zonder veel impact op de rest Wel noodzakelijk om te weten welke koppelingen er zijn Interfaces Definiëren waarop andere objecten/module zich mogen baseren Leggen dus mogelijke afhankelijkheden vast 2005 Prof. Dr. O. De Troyer pag

40 Encapsulatie interface interface Black box Als de black box wijzigt zonder dat de interface wijzigt dan heeft dit geen effect op zijn gebruikers (andere modules, andere objecten,...) Vb. Implementatie van een methode kan wijzigen zonder dat de signatuur van de methode wijzigt 2005 Prof. Dr. O. De Troyer pag. 79 Abstractie Abstractie De gebruiker moet afgeschermd worden van onnodige details De concepten encapsulatie en interface laten dit toe Gebruiker moet niet meer weten dan de interface om de module/interface te kunnen gebruiken Gebruiker mag niet meer weten dan de interface om de module/interface te kunnen gebruiken Ook wel information hiding genoemd 2005 Prof. Dr. O. De Troyer pag

41 High cohesion Een module/object zelf moet een hoge graad van samenhang hebben: high cohesion Geen samenraapsel van losse dingen Er moet een logisch verband zijn tussen de verschillende onderdelen Bijv via associaties, inheritance, Loskoppelen zou de regel van low coupling schenden! 2005 Prof. Dr. O. De Troyer pag. 81 Hergebruik Hergebruik Het opnieuw gebruiken van een module/object in een andere context Daarom object/module niet afhankelijk maken van een welbepaalde context/situatie 2005 Prof. Dr. O. De Troyer pag

42 Vervangbaarheid Vervangbaarheid Het moet gemakkelijk zijn om een object/module te vervangen door een andere zonder dat dit een effect heeft op de gebruikers Voorbeeld: sorteer-methode via buble sort te vervangen door quick sort Encapsulatie en interfaces ondersteunen dit 2005 Prof. Dr. O. De Troyer pag. 83 Open-closed principe Open-closed principe Betrand Meyer (boek: Object- Oriented Software Construction) Vaak maakt een klasse/deelsysteem gebruik van de diensten aangeboden door een andere klasse/deelsysteem Supplier module: verleent de diensten Client module : maakt gebruik van de diensten 2005 Prof. Dr. O. De Troyer pag

43 Open-closed principe Een module is gesloten indien het niet meer onderhevig is aan wijzigingen die een invloed kunnen hebben op clients De module is stabiel Clients kunnen de module gebruiken zonder dat men bevreesd moet zijn voor wijzigingen Een module is open indien het nog kan worden uitgebreid Belangrijk voor onderhoud en algemene uitbreidbaarheid van het systeem Open-closed principe Probeer modules te maken die zowel open als gesloten zijn 2005 Prof. Dr. O. De Troyer pag. 85 Open-closed principe Open-closed principe Lijkt een contradictie Daarom zijn mechanismen nodig die toelaten om een module uit te breiden zonder het te wijzigen Interfaces en encapsulatie laten dit toe clients mogen enkel afhankelijk zijn van de interface Implementatie kan gewijzigd worden zonder de clients te beïnvloeden 2005 Prof. Dr. O. De Troyer pag

44 Mechanismen - 1 Encapsulatie principe voor klassen: Alle attributen private Enkel de definitie van een publieke methode is zichtbaar, niet zijn implementatie Private methoden voor hulpmethoden Alles wat onzichtbaar is kan gewijzigd worden zonder problemen voor de clients Nadelen: Sommige programmeertalen ondersteunen dit niet volledig Niet elke client maakt gebruik van alles wat de supplier te bieden heeft Niet expliciet aan te geven 2005 Prof. Dr. O. De Troyer pag. 87 Mechanismen - 2 Abstracte Interface klassen Introductie van een extra (abstracte) klasse Definieert enkel de interface Heeft geen attributen Enkel de interface Attributen en de implementatie 2005 Prof. Dr. O. De Troyer pag

45 Mechanismen - 2 De abstracte supplier klasse is open Functionaliteit kan worden toegevoegd door extra subklassen Gesloten De concrete klasse kan worden gewijzigd zonder dat dit effect heeft op de clients Nadeel: Wijzigingen aan de interface (abstracte interface klasse) hebben nog steeds een invloed op de clients 2005 Prof. Dr. O. De Troyer pag. 89 Mechanismen - 3 Abstracte superklassen alle superklassen in een systeem zouden abstract moeten zijn Motivatie in the context of open-closed principe: Voorbeeld: Initieel enkel één soort van rekening Nu uitbreiding naar spaarrekeningen 2005 Prof. Dr. O. De Troyer pag

46 Mechanismen - 3 SavingsAccount is nu afhankelijk van CurrentAccount! Wijzigingen aan CurrentAccount hebben invloed op SavingsAccount De wijzigingen zijn niet noodzakelijk van toepassing op SavingsAccount Overwriting wordt noodzakelijk Of code in CurrentAccount nodig om uit te zoeken over welk soort rekening het gaat» Superklasse wordt afhankelijk van zijn subklasse» Toevoegen van subklasse niet meer zonder meer mogelijk 2005 Prof. Dr. O. De Troyer pag. 91 Mechanismen - 3 Oplossing Abstracte klasse 2005 Prof. Dr. O. De Troyer pag

47 Mechanismen - 4 Nadeel van abstracte interface klassen: Wijziging aan de interface klasse impliceert wijzigingen bij de clients + in de concrete klasse(n) Bijv. Toevoegen van een operatie 2005 Prof. Dr. O. De Troyer pag. 93 Mechanismen - 4 Oplossing: Abstracte Interface klassen loskoppelen Concrete klasse niet meer als subklasse van de abstracte interface klasse 2005 Prof. Dr. O. De Troyer pag

48 Mechanismen - 4 Uitbreidingen nu via specialisaties van de abstracte interface klasse 2005 Prof. Dr. O. De Troyer pag

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

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

Abstracte klassen & Interfaces

Abstracte klassen & Interfaces Abstracte klassen & Interfaces Overerving public class Vierhoek {... Vierhoek public class Rechthoek extends Vierhoek {... public class Ruit extends Vierhoek {... Rechthoek Ruit Elke rechthoek is een vierhoek.

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

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

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

voorbeeldexamen Object Oriëntatie Foundation (OOF.NL) editie juli 2010 inhoud inleiding 3 voorbeeldexamen 4 antwoordindicatie 11 evaluatie 22

voorbeeldexamen Object Oriëntatie Foundation (OOF.NL) editie juli 2010 inhoud inleiding 3 voorbeeldexamen 4 antwoordindicatie 11 evaluatie 22 voorbeeldexamen Object Oriëntatie Foundation (OOF.NL) editie juli 2010 inhoud inleiding 3 voorbeeldexamen 4 antwoordindicatie 11 evaluatie 22 bijlage bijlagenset A711 EXIN Hét exameninstituut voor ICT

Nadere informatie

Deel I Hoofdstuk 4: Modelleren van Toestand

Deel I Hoofdstuk 4: Modelleren van Toestand Deel I Hoofdstuk 4: Modelleren van Toestand 2005 Prof Dr. O. De Troyer Toestandsmodel pag. 1 Berichten of boodschappen OO is gebaseerd op hoe de reële wereld werkt 2005 Prof. Dr. O. De Troyer Toestandsmodel

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

Zelftest OOAD/UML. Document: N0767Test.fm 30/08/2010. ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium

Zelftest OOAD/UML. Document: N0767Test.fm 30/08/2010. ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium Zelftest OOAD/UML Document: N0767Test.fm 30/08/2010 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INTRODUCTIE Deze test is gebaseerd op de inhoud van onze cursus OO

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

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

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

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

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

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

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

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

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

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

Noties Informatica. In java fungeren objecten als een model voor de elementen waarin een probleem kan worden opgesplitst

Noties Informatica. In java fungeren objecten als een model voor de elementen waarin een probleem kan worden opgesplitst s Informatica Hoofdstuk 1 Object Klasse Methode Parameters Type Velden Toestand Compiler Resultaten (returnwaarde) In java fungeren objecten als een model voor de elementen waarin een probleem kan worden

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

Design patterns Startbijeenkomst

Design patterns Startbijeenkomst Design patterns Startbijeenkomst Harrie Passier Docenten Sylvia Stuurman (1 e examinator) Sylvia.Stuurman@ou.nl Harrie Passier (2 e examinator) Harrie.Passier@ou.nl Aarzel niet vragen te stellen! Rooster

Nadere informatie

ARE methodiek Het ontwikkelen van Informatie Elementen

ARE methodiek Het ontwikkelen van Informatie Elementen ARE methodiek Het ontwikkelen van Informatie Elementen WI1: Het opstarten van het project Milestone 1 WI2: Ontwikkel een Vison WI3: Modelleer het Business Domain WI4: Creëer een Glossary WI7: Beheer wijzigingen

Nadere informatie

BRP-BZM Use Case Realisations Guidelines

BRP-BZM Use Case Realisations Guidelines BRP-BZM Use Case Realisations Guidelines Versie 2.0 02-09-2011 Definitief Versiehistorie Datum Versie Auteur 23-12-2010 0.1 Eerste versie R.F. Schaaf 04-01-2011 1.0 Feedback verwerkt R. Schaaf en D. Geluk

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

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

Kennis na het volgen van de training. Na het volgen van deze training bent u in staat:

Kennis na het volgen van de training. Na het volgen van deze training bent u in staat: Training Trainingscode Duur Gepubliceerd Taal Type Leermethode Kosten SF2015V8 4 dagen 02/02/2015 Nederlands & Engels Developer, basis Invidueel & klassikaal Op aanvraag Deze training richt zich op het

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

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

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

Module 1 Programmeren

Module 1 Programmeren Module 1 Programmeren Programmeertalen 13 1.1 Inleiding 13 1.2 Programmeertalen in historisch perspectief 13 1.2.1 Machinecode 13 1.2.2 Assembleertalen (assembly) 14 1.2.3 Hogere programmeertalen 15 1.2.4

Nadere informatie

Deel I Hoofdstuk 6: Modelleren van interactie

Deel I Hoofdstuk 6: Modelleren van interactie Deel I Hoofdstuk 6: Modelleren van interactie 2005 Prof Dr. O. De Troyer, pag. 1 Introductie Interactiemodellen beschrijven de interactie die plaats vindt tussen objecten Toestandsmodellen beschrijven

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

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

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

case: toestandsdiagrammen

case: toestandsdiagrammen Hoofdstuk 13 case: toestandsdiagrammen In dit hoofdstuk wordt het maken van de eerste versie van de toestandsdiagrammen voor het boodschappensysteem van Hans en Jacqueline uitgewerkt. 13.1 Vind klassen

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

Problemen met platte toestandsdiagrammen

Problemen met platte toestandsdiagrammen Deel I Hoofdstuk 5: Modelleren van toestand -- gevorderd 2005 Prof Dr. O. De Troyer OO modelleren pag. 1 Problemen met platte toestandsdiagrammen Bij complexe systemen krijgt men een explosie van toestanden

Nadere informatie

Vergelijking Oracle certificering voor Java en het CPP Gecertificeerd Javaprogrammeur van de Open Universiteit

Vergelijking Oracle certificering voor Java en het CPP Gecertificeerd Javaprogrammeur van de Open Universiteit Vergelijking Oracle certificering voor Java en het CPP Gecertificeerd Javaprogrammeur van de Open Universiteit Inleiding Op het gebied van scholing van de taal Java zijn er vele aanbieders op de markt.

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

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

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

Technische architectuur Beschrijving

Technische architectuur Beschrijving A gemeente Eindhoven Technische architectuur Beschrijving Specificatiecriteria Versie 1.1 A. van Loenen Technisch Beleidsadviseur B&E 21-Sep-2011 avl/fd11027578 Colofon Uitgave Gemeente Eindhoven Realisatie

Nadere informatie

OOAA. Object Oriented Analysis Advanced. Arie Bubberman 12/10/2009

OOAA. Object Oriented Analysis Advanced. Arie Bubberman 12/10/2009 OOAA Object Oriented Analysis Advanced Arie Bubberman 12/10/2009 Contents 1 Analyse...3 Kiezen van een ontwikkelproces...3 Agile Methoden...3 Deelprocessen in het OO-ontwikkelproces...Fout! Bladwijzer

Nadere informatie

Cyberpesten: social media platform mining tools

Cyberpesten: social media platform mining tools Cyberpesten: social media platform mining tools ABI team 27: Pascal Pieters, Stephaan Declerck Begeleider: dr. Rik Bos Opdrachtgever: prof. dr. ir. Remko Helms Inhoud Achtergrond Opdracht Projectaanpak

Nadere informatie

NAAM: Programmeren 1 Examen 21/01/2011

NAAM: Programmeren 1 Examen 21/01/2011 Programmeren 1 21 januari 2011 Prof. T. Schrijvers Instructies Schrijf al je antwoorden op deze vragenbladen (op de plaats die daarvoor is voorzien). Geef ook je kladbladen af. Bij heel wat vragen moet

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

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

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

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

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Unified Process Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Unified Process... 4 3. Fasering... 5 3.1.

Nadere informatie

Tools voor canonieke datamodellering Bert Dingemans

Tools voor canonieke datamodellering Bert Dingemans Tools voor canonieke datamodellering Tools voor canonieke datamodellering Bert Dingemans Abstract Canonieke modellen worden al snel omvangrijk en complex te beheren. Dit whitepaper beschrijft een werkwijze

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

Modelleren en Programmeren

Modelleren en Programmeren Modelleren en Programmeren Jeroen Bransen 11 december 2015 Ingebouwde datastructuren Meer boomstructuren Access specifiers Gebruikersinvoer Codestijl Packages SAT-solver Ingebouwde datastructuren Ingebouwde

Nadere informatie

B.Sc. Informatica Module 4: Data & Informatie

B.Sc. Informatica Module 4: Data & Informatie B.Sc. Informatica Module 4: Data & Informatie Djoerd Hiemstra, Klaas Sikkel, Luís Ferreira Pires, Maurice van Keulen, en Jan Kamphuis 1 Inleiding Studenten hebben in modules 1 en 2 geleerd om moeilijke

Nadere informatie

Zelftest Java concepten

Zelftest Java concepten Zelftest Java concepten Document: n0838test.fm 22/03/2012 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST JAVA CONCEPTEN Om de voorkennis nodig

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

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

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

Dynamische webapplicaties in Java

Dynamische webapplicaties in Java Dynamische webapplicaties in Java October 7, 2006 In java is het mogelijk dynamische webpagina s te implementeren. De code om de dynamische gegevens te genereren staat in servlets of Java Server Pages

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

Nederlandse samenvatting (Dutch summary)

Nederlandse samenvatting (Dutch summary) Nederlandse samenvatting (Dutch summary) Ditproefschriftpresenteerteen raamwerk voorhetontwikkelenvanparallellestreaming applicaties voor heterogene architecturen met meerdere rekeneenheden op een chip.

Nadere informatie

Object Oriented Programming

Object Oriented Programming Object Oriented Programming voor webapplicaties Door Edwin Vlieg Waarom OOP? Basis uitleg over OOP Design Patterns ActiveRecord Model View Controller Extra informatie Vragen OOP Object Oriented Programming

Nadere informatie

NAAM: Programmeren 1 Examen 29/08/2012

NAAM: Programmeren 1 Examen 29/08/2012 Programmeren 29 augustus 202 Prof. T. Schrijvers Instructies Schrijf al je antwoorden op deze vragenbladen (op de plaats die daarvoor is voorzien). Geef ook je kladbladen af. Bij heel wat vragen moet je

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

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

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

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

Software Mobiliteit. UAMS - 6 maart 2001. Theo D'Hondt Lab voor Pogrammeerkunde Vrije Universiteit Brussel http://prog.vub.ac.

Software Mobiliteit. UAMS - 6 maart 2001. Theo D'Hondt Lab voor Pogrammeerkunde Vrije Universiteit Brussel http://prog.vub.ac. Software Mobiliteit Theo D'Hondt Lab voor Pogrammeerkunde Vrije Universiteit Brussel http://prog.vub.ac.be/~tjdhondt p. 1 Overzicht Stelling Objecttechnologie Distributie Mobiliteit Evolutie Besluit p.

Nadere informatie

Tentamen Objectgeorienteerd Programmeren TI februari Afdeling ST Faculteit EWI TU Delft

Tentamen Objectgeorienteerd Programmeren TI februari Afdeling ST Faculteit EWI TU Delft I ' Tentamen Objectgeorienteerd Programmeren TI 1200 1 februari 2012 9.00-12.00 Afdeling ST Faculteit EWI TU Delft Bij dit tentamen mag je geen gebruik maken van hulpmiddelen zoals boek of slides. Dit

Nadere informatie

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Socio-technisch systemen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Systeem categoriën Technische op computer gesteunde systemen Systemen die HW en SW bevatten, maar waar

Nadere informatie

Hoofdstuk 9: Object Constraint language (OCL) Prof. Dr. Olga De Troyer. Constraints

Hoofdstuk 9: Object Constraint language (OCL) Prof. Dr. Olga De Troyer. Constraints Hoofdstuk 9: Object Constraint language (OCL) Prof. Dr. Olga De Troyer 2005 Prof Dr. O. De Troyer, pag. 1 Constraints UML s notatie is grafisch Goed voor het uitdrukken van structurele eigenschappen van

Nadere informatie

Stacks and queues. Hoofdstuk 6

Stacks and queues. Hoofdstuk 6 Hoofdstuk 6 Stacks and queues I N T R O D U C T I E In dit hoofdstuk worden drie datastructuren stack, queue en deque behandeld. Om deze datastructuren te implementeren, worden onder andere arrays en linked

Nadere informatie

Tentamen Object Georiënteerd Programmeren TI1200 30 januari 2013, 9.00-12.00 Afdeling SCT, Faculteit EWI, TU Delft

Tentamen Object Georiënteerd Programmeren TI1200 30 januari 2013, 9.00-12.00 Afdeling SCT, Faculteit EWI, TU Delft Tentamen Object Georiënteerd Programmeren TI1200 30 januari 2013, 9.00-12.00 Afdeling SCT, Faculteit EWI, TU Delft Bij dit tentamen mag je geen gebruik maken van hulpmiddelen zoals boek of slides. Dit

Nadere informatie

J2EE/.NET en de rol Applicatie Architectuur

J2EE/.NET en de rol Applicatie Architectuur J2EE/.NET en de rol Applicatie Architectuur Edwin van Dillen evdillen@sogyo.nl 2003 Sogyo Information Engineering 1 Sogyo information engineering! IT Innovator sinds 1995! Klanten: ABN AMRO, Rabobank,

Nadere informatie

Archimate risico extensies modelleren

Archimate risico extensies modelleren Archimate risico extensies modelleren Notatiewijzen van risico analyses op basis van checklists versie 0.2 Bert Dingemans 1 Inleiding Risico s zijn een extra dimensie bij het uitwerken van een architectuur.

Nadere informatie

Inhoud. Introductie tot de cursus

Inhoud. Introductie tot de cursus Inhoud Introductie tot de cursus 1 Plaats en functie van de cursus 7 2 Inhoud van de cursus 8 2.1 Voorkennis 8 2.2 Leerdoelen 8 2.3 Opbouw van de cursus 8 2.4 Leermiddelen 9 3 Aanwijzingen voor het bestuderen

Nadere informatie

Genetische algoritmen in Java met JGAP

Genetische algoritmen in Java met JGAP Genetische algoritmen in Java met JGAP Inleiding JGAP, uitgesproken als "jee-gep", is een framework voor het implementeren van genetische algoritmen en het gebruik ervan in Java. Genetische algoritmen

Nadere informatie

Aliens? http://www.youtube.com/watch?v=e5pqleh2hz8

Aliens? http://www.youtube.com/watch?v=e5pqleh2hz8 Aliens? http://www.youtube.com/watch?v=e5pqleh2hz8 Ontwikkelmethoden en technieken Kenmerken van ontwikkelmethoden POMT HC2 2 Vorige week 3 Rollenspel Klant is koning Communicatie en afspraken Documentatie

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

case: ocl-expressies

case: ocl-expressies Hoofdstuk 7 case: ocl-expressies In dit hoofdstuk worden de expressies ontwikkeld bij het domein-klassediagram van de case zoals dat in hoofdstuk 5 ontwikkeld is. Daarna worden de resterende stappen uit

Nadere informatie

Software-ontwerp User stories Use cases Opdracht. Ontwerpmethodologie. Nick Vannieuwenhoven. October 17 18,

Software-ontwerp User stories Use cases Opdracht. Ontwerpmethodologie. Nick Vannieuwenhoven. October 17 18, October 17 18, 2013 1 Software-ontwerp 2 User stories 3 Use cases 4 Opdracht Overview 1 Software-ontwerp 2 User stories 3 Use cases 4 Opdracht Het waarom van softwareontwerp Enkele veelvoorkomende redenen

Nadere informatie

H9: Klasse Ontwerp. Richtlijnen Specificaties Multiple inheritence

H9: Klasse Ontwerp. Richtlijnen Specificaties Multiple inheritence H9: Klasse Ontwerp Richtlijnen Specificaties Multiple inheritence SchetsPlus... doe ik het goed? 2 Hoe maak ik goede klassen? We gaan kijken naar: algemene ontwerp-richtlijnen software metric Complement:

Nadere informatie

Tentamen Objectgeorienteerd Programmeren IN1205 Voorbeeld

Tentamen Objectgeorienteerd Programmeren IN1205 Voorbeeld Tentamen Objectgeorienteerd Programmeren IN1205 Voorbeeld Afdeling ST Faculteit EWI TU Delft Bij dit tentamen mag u gebruik maken van: Barnes, Object-Oriented Programming with Java en de Notitie Algoritmiek

Nadere informatie

Uitbreiding van UM Aquo cluster metingen, toevoegen optioneel attribuut Identificatie waarnemingssoort aan klasse WaardeReeks MIDDELGROOT

Uitbreiding van UM Aquo cluster metingen, toevoegen optioneel attribuut Identificatie waarnemingssoort aan klasse WaardeReeks MIDDELGROOT Uitbreiding van UM Aquo cluster metingen, toevoegen optioneel attribuut Identificatie waarnemingssoort aan klasse WaardeReeks algemeen onderdeel: Publicatiedatum 1 mei 2012 UM Aquo - metingen Status concept

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

SMART requirements schrijven

SMART requirements schrijven SMART requirements schrijven Reverse Engineering als aanpak voor leren Requirements Kenniscentrum 27 maart 2012, 18:50 19:30 uur Hossein Chamani, docent en trainer bij Hogeschool Rotterdam 1 Introductie

Nadere informatie

Hoofdstuk Error! Style not defined. 19. 3. Use-case analyse

Hoofdstuk Error! Style not defined. 19. 3. Use-case analyse Hoofdstuk Error! Style not defined. 19 3. Use-case analyse Hier worden een paar use-case diagrammen gegeven en een aantal use-case beschrijvingen volgens het template van Warmer & Kleppe. 3.1 Use-case

Nadere informatie

Objectgeoriënteerd programmeren in Java 1

Objectgeoriënteerd programmeren in Java 1 Objectgeoriënteerd programmeren in Java 1 CPP Javaprogrammeur Bijeenkomst 3 Leereenheden 7, 8, 9 De Java API Java bevat een grote bibliotheek standaardklassen: de Java API Voorbeelden java.lang basisklassen

Nadere informatie

Objectgeoriënteerde systeemontwikkeling

Objectgeoriënteerde systeemontwikkeling 2 Objectgeoriënteerde systeemontwikkeling Objecttechnologie of objectoriëntatie is een bekende term in de automatisering. Regelmatig verschijnen artikelen over dit onderwerp in de bekende vaktijdschriften.

Nadere informatie

Enterprise Connectivity. Marnix van Bo. TU Delft Elek Software Architect 20 jaar ervarin ontwikkeling

Enterprise Connectivity. Marnix van Bo. TU Delft Elek Software Architect 20 jaar ervarin ontwikkeling Fir rst Base Enterprise Connectivity Marnix van Bo chove First Base: opgericht in 2001 TU Delft Elek ktrotechniek - 1998 Software Architect 20 jaar ervarin g met software ontwikkeling Presentatie Ideeën

Nadere informatie

Abstraheren van modellen

Abstraheren van modellen Abstraheren van modellen Geert Delanote 7 maart 2005 Geert.Delanote@cs.kuleuven.ac.be Software Development Methodology 1 Inhoudstafel Motivatie Denkpistes Software Development Methodology 2 Motivatie Verslag

Nadere informatie

APPENDIX 3. Visueel voetmodel ter simulatie van voetkinematica aan de hand van planetaire drukdata (Friso Hagman)

APPENDIX 3. Visueel voetmodel ter simulatie van voetkinematica aan de hand van planetaire drukdata (Friso Hagman) APPENDIX 3. Visueel voetmodel ter simulatie van voetkinematica aan de hand van planetaire drukdata (Friso Hagman) 1. Introductie De doelstelling van het SIMKINPRES-project is het ontwikkelen van een klinisch

Nadere informatie

Tentamen Imperatief Programmeren

Tentamen Imperatief Programmeren Tentamen Imperatief Programmeren Maandag 22 oktober 2001 Toelichting Dit is een open boek tentamen, d.w.z. het cursusboek mag gebruikt worden. N.B.: Het tentamen is individueel: voor het maken van de opgaven

Nadere informatie

Organiseer uw verschillende SOAP services in één scenario

Organiseer uw verschillende SOAP services in één scenario 1 Organiseer uw verschillende SOAP services in één scenario Wouter Luijten wouterluijten@creetion.com 2 Introductie Tijdens de implementatie van een proces heeft u vaak te maken met een veelvoud aan services.

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

EEN INLEIDING IN DE UNIFIED MODELING LANGUAGE

EEN INLEIDING IN DE UNIFIED MODELING LANGUAGE Een inleiding in de Unified Modeling Language 51 III EEN INLEIDING IN DE UNIFIED MODELING LANGUAGE Als een aannemer een huis bouwt, dan ontwerpt hij dat huis niet terwijl hij het bouwt. Hij bouwt het huis

Nadere informatie

Software Design Document

Software Design Document Software Design Document Mathieu Reymond, Arno Moonens December 2014 Inhoudsopgave 1 Versiegeschiedenis 2 2 Definities 3 3 Introductie 4 3.1 Doel en Scope............................. 4 4 Logica 5 4.1

Nadere informatie

Oefeningen Jaarproject I

Oefeningen Jaarproject I Oefeningen Jaarproject I Deze oefeningenreeks behandelt de grafische Scheme bibliotheek die jullie mogen gebruiken voor de implementatie van het Pacman spel. De bibliotheek i is een evaluator voor Scheme

Nadere informatie