Componenten: Revolutie, evolutie, of devolutie? door Bart Huylebroeck

Maat: px
Weergave met pagina beginnen:

Download "Componenten: Revolutie, evolutie, of devolutie? door Bart Huylebroeck"

Transcriptie

1 Componenten: Revolutie, evolutie, of devolutie? door Bart Huylebroeck Promotor: Frans Arickx Serge Demeyer Medelezer: Jan Broeckhove Abstract: Aan de hand van een aantal boeken wordt eerst gezocht naar een werkbare definitie van het begrip component. Daarna wordt nagegaan waarin het component-georienteerde paradigma verschilt van andere gangbare paradigma s, zowel in theorie als in praktijk. Uiteindelijk is het besluit dat hoewel er geen duidelijke scheidingslijn bestaat, het componentgeorienteerd paradigma toch genoeg nieuwe aspecten aan programmeren toevoegt om effectief van een paradigma te spreken

2 0 Inhoud 1 Definitie 1.0 Analogie 1.1 Clemens Szyperski 1.2 Bertrand Meyer 1.3 Bruce Powel Douglass 1.4 Siemens Gang of Five 1.5 Andere 1.6 Kenmerken van componenten 2 Distinctie 2.1 Object-Oriented programming 2.2 Aspect-Oriented Programming [XEROX] 2.3 Patterns Onstaan Definitie Toepassing 3 Eigenschappen en beloften 3.1 Correctness (correctheid) 3.2 Reliability (betrouwbaarheid) 3.3 Interoperability/compatibility (samenstelbaarheid) 3.4 Efficiency/performance (efficientie) 3.5 Testability/verifiability (verifieerbaarheid) 3.6 Reusability (herbruikbaarheid) 3.7 Changeability (veranderbaarheid) 3.8 User friendliness/ease of use (gebruiksvriendelijkheid) 3.9 Understandability (eenvoud) 3.10 Productivity (productiviteit) 3.11 Timeliness (tijdigheid) 3.12 Visibility (transparantie) 4 Huidige situatie 4.1 Besturingssystemen 4.2 Plug-in architecturen 4.3 Visual Basic 4.4 CORBA/OMA Overerving en hergebruik Versioning Management van Objecten Persistence Interoperabiliteit Huidig gebruik

3 4.5 COM/DCOM/COM Overerving en hergebruik Versioning Management van Objecten Persistence Interoperabiliteit Huidig gebruik 4.6 JavaBeans Overerving en hergebruik Versioning Management van Objecten Persistence Interoperabiliteit Huidig gebruik 5 Verlanglijstje 5.1 Taal Toevoegen van keywords Aspect-orientatie Componenten als threads 5.2 Contract Pre- en postcondities Niet-functionele vereisten Wettelijke aansprakelijkheid 6 Magic: the Gathering 6.1 Het spel 6.2 De software 6.3 Code hergebruik 6.4 Combineren van kaarten 6.5 Een alternatieve methode 7 Conclusie 8 Referenties

4 1 Definitie Het begrip "component" bestaat al tientallen jaren, al van zodra het begrip "reuse" in gebruik kwam. Toch is het nog steeds nuttig om stil te staan bij de exacte definitie van de term. Vergelijking van verschillende auteurs en teksten zal duidelijk maken dat een "component" een zeer rekbaar begrip is, zelfs al zijn er duidelijke overeenkomsten. 1.0 Analogie Programmeurs streven ernaar, net zoals iedereen, om hun job zo eenvoudig mogelijk te maken. Daarbij lonken ze graag naar beproefde technieken in verwante beroepstakken, zoals de wereld van electronische componenten. In het ideale geval zou software engineering sterk te vergelijken moeten zijn met "electrical engineering", waar een nieuw systeem bouwen dikwijls voor een groot deel bestaat uit bestaande componenten selecteren en verbinden met elkaar. Zo ook streven software ontwerpers ernaar om programmeren zoveel mogelijk te reduceren tot het combineren van bestaande software onderdelen. Daarom wordt de code die software componenten met elkaar verbindt al graag eens "wiring" genoemd. De vergelijking gaat natuurlijk nooit helemaal op. Bertrand Meyer en Szyperski zijn het eens dat software engineering verschilt van de andere engineering disciplines in een zeer fundamenteel opzicht: het onderscheid tussen ontwerp en product is veel vager. Het verschil tussen een tekening op papier, en de betonnen brug is vrij duidelijk: van het een kan je vallen, van het andere niet [SDM][SZYP, p.8]. Bij software engineering rijst dikwijls de vraag of een bepaalde keuze nu een kwestie van design of implementatie is. Dat vage onderscheid laat zich in verschillende kleine dingen voelen. Hoe dikwijls wordt een algoritme/procedure/handeling niet uitgelegd in pseudo-code? Hoe verleidelijk is het niet om zelf "in de code te duiken" om te weten te komen wat het precies doet? Een tweede punt waar de vergelijking mank zou kunnen lopen is de "wiring". Het woord zelf suggereert zeer eenvoudige verbindingen tussen de verschillende componenten, ongeveer zoals een geleidende draad wordt getrokken tussen twee poorten van electronische chips, of zoals cement de muur met de steunpilaar verbindt. In praktijk zou dat bij software wel eens tegen kunnen vallen. Sommige triviale dingen kunnen inderdaad zeer eenvoudig beschreven worden: in de Java beanbox bijvoorbeeld, is het mogelijk om een knop te "verbinden" met een animatie-bean op zeer intuitieve wijze, waarna de animatie kan gestart of gestopt worden met een druk op de knop. Zulke simpele en triviale verbindingen zullen jammer genoeg geen meerderheid uitmaken bij composities van componenten. Hoe leg je bijvoorbeeld vast dat enkele welbepaalde rijen cellen uit een

5 spreadsheet component integraal naar het database component moeten overgebracht worden, waar ze in een nieuwe database moet gestoken worden en bovendien enkele velden met geaggregeerde informatie (bijvoorbeeld een meetkundig gemiddelde) moeten worden gevuld? Drag-and-drop zal hier een beetje tekort schieten. Volgende delen gaan ietsje dieper in op de visies van enkele auteurs. 1.1 Clemens Szyperski Szyperski [SZYP] definieert een component als volgt: - A component is a unit of independent deployment. - A component is a unit of third-party composition. - A component has no persistent state. independent deployment Met "unit of deployment" worden verschillende dingen aangestipt. Ten eerste worden componenten in contrast gesteld met syntactische eenheden, zoals de klasse, of een enkele functie. Componenten kunnen verschillende objecten en procedures omvatten, zodat ze de grenzen kunnen overschrijden zoals die door een programmeertaal zijn vastgelegd. Toch vormt een component een duidelijke eenheid: het is een zeer duidelijk afgelijnd geheel, dat ofwel helemaal, ofwel helemaal niet wordt gebruikt. De interface naar "buiten" toe wordt zeer duidelijk vastgelegd, maar voor de rest geldt het component als een black box. Het woord "deployment" duidt op nog een tweede verschil met klassiekere "units of reuse": een component wordt niet gecompileerd, het wordt "deployed", dat wil zeggen het component wordt toegevoegd aan een draaiend systeem, op run-time. Dit wil ook zeggen dat een component niet wordt herbruikt als source-code, maar eerder in binaire vorm. Dit wordt erg benadrukt door Szyperski, en in columns [SDM] gaat hij iets dieper in op de noodzaak om binaire componenten te gebruiken, zodat ze op run-time niveau kunnen worden samengesteld. Indien noodzakelijk, kunnen zo zelfs systemen ontworpen worden met "hot-swapping". Dit is in sterk contrast met andere vormen van hergebruik, dat meestal op source-niveau gebeurt. "Independent" duidt op de sterke inkapsulatie. Om herbruikbaar te zijn in zeer verschillende omstandigheden, moet een component op zichzelf staan, en liefst niet te veel "verbindingen" hebben met die omgeving. Een kleine analogie: een levertransplantatie is veel moeilijker dan een harttransplantatie, enkel omdat de lever meer verbindingen heeft dan het hart. Bij componenten wordt er dus naar gestreefd om de "coupling" zo laag mogelijk te houden. Afhankelijkheden kunnen natuurlijk nooit helemaal vermeden worden. Het doel van componenten is immers om ze te combineren. Als een component dus op bepaalde

6 andere soorten componenten (services) rekent, moeten deze afhankelijkheden zo duidelijk, uniform en formeel mogelijk worden beschreven. Hierover later meer. third-party composition Dit heeft veel te maken met de droom van willekeurig combineerbare elementen, en het is dan ook het streefdoel voor component-georienteerde ontwikkeling. Componenten worden dan producten, die verkocht worden aan andere ontwikkelaars, die ze dan kunnen inzetten in hun software oplossing. Deze "derde partij" moet niet noodzakelijk een ander bedrijf zijn; het kan gaan om een ander departement binnen hetzelfde bedrijf, of zelfs gewoon een andere programmeur aan hetzelfde project. Bij elk software project rijst de vraag of een bepaald stuk intern moet worden ontwikkeld, of dat er bestaande software wordt gekocht. Interne ontwikkeling heeft als voordeel dat de software zeer sterk zal aangepast zijn aan de specifieke behoeften van het bedrijf, maar het brengt een vrij hoge ontwikkelingskost met zich mee, en ook een aanzienlijk risico, zowel financieel als op gebied van scheduling. Bovendien is er altijd de kans dat het warm water opnieuw wordt uitgevonden of dat de behoeften verkeerd werden ingeschat of ondertussen al geevolueerd zijn. Het kopen van bestaande software heeft als grote voordeel dat ze veel vlugger beschikbaar is, dat de aankoopprijs bekend is, en dat het onderhoud dikwijls wordt overgelaten aan de oorspronkelijke ontwikkelaar van de software. Nadeel is dat de software zelden voor 100% aan de wensen zal voldoen. En het wordt er ook niet makkelijker op om een voorsprong op de concurrenten te behouden, als de werking van het bedrijf afhangt van een product dat vrij verkrijgbaar is op de markt. persistent state Szyperski benadrukt ten stelligste dat een component geen "state" mag hebben [SZYP][SDM]. De redenering is dat als componenten zich in een bepaalde toestand kunnen bevinden, dan kunnen ze niet vrijelijk worden vervangen, of in een nieuw systeem worden ingebouwd. Het vervangende object kan niet garanderen dat het zich in dezelfde toestand bevindt, en zal dus verschillend reageren. Dit klonk me allemaal nogal verwarrend in de oren, en ik ben dus verder beginnen graven naar wat Szyperski hiermee juist bedoelt. Globale variabelen worden taboe verklaard, samen met elke constructie die globale variabelen vervangt, zoals niet-constante variabelen met class-scope. Dit is geen nieuw of radicaal standpunt: globale variabelen worden beschouwd als een bron van onvoorziene indirecte koppelingen, en ze bemoeilijken dus de documentatie, debugging en inzetbaarheid van componenten. Geen globale variabelen dus, maar wat dan met interne variabelen? Het moet toch mogelijk zijn om bepaalde gegevens bij te houden, al was het nog maar het opschrift van een simpele knop? Szyperski benadrukt dat het component niet mag verward worden met het object, en dat alle "state" in objecten moet worden bijgehouden. Een database component, bijvoorbeeld, mag niet verward worden met de eigenlijke gegevens, opgeslagen in een database met een zekere naam. Een filesystem component bevat zelf geen enkele informatie over een

7 toestand. In plaats daarvan voorziet het bewerkingen op objecten: de files. In theorie is het dus perfect mogelijk om het component filesysteem te vervangen in een run-time systeem. En hoewel een "delete" op een file heel anders kan geïmplementeerd in het nieuwe systeem, is de semantiek volledig dezelfde gebleven, en ondervinden de andere componenten in principe geen hinder van de hot swap. Alles komt dus neer op een tamelijk subtiel verschil in definitie van de term "component". Voor Szyperski staat een component gelijk aan een pakket van diensten. Vandaar ook zijn opmerking dat het, binnen een enkel software systeem, geen zin heeft om meer dan een component van hetzelfde type te installeren. Mijn eerste reactie daarop was dat de gemiddelde applicatie waarschijnlijk meer dan een knop zou gebruiken. Binnen Szyperski's filosofie zou een enkele knop eerder een object zijn, als onderdeel van het component "GUI". Dit staat haaks op bijvoorbeeld de JavaBeans definitie van een component, maar het leunt dichter aan tegen het COM model. 1.2 Bertrand Meyer In een reeks columns in dialoog met Szyperski [SDM], en vooral in "What to compose" van maart 2000 beschrijft Meyer wat volgens hem de kenmerken zijn van componenten. Veel van deze ideeën zijn al terug te vinden in zijn boek over object-oriented methoden [OOSC], maar het interessante aan de reeks columns is dat ze hier specifiek gebruikt worden om componenten te definiëren, en bovendien zijn ze geformuleerd in antwoord op Szyperski's definitie. "May be used by other software elements (clients)." De voornaamste bestaansreden voor componenten is gebruikt te worden door andere componenten. Samenstelling van componenten levert een totaal-systeem op dat een of meer taken kan uitvoeren, al of niet in interactie met de gebruiker. De vereiste dat componenten bruikbaar moeten zijn door andere stukken software, in plaats van de eindgebruiker legt bepaalde vereisten op in verband met de documentatie, de interface, en andere. Deze vereisten worden in de andere punten opgesomd. "May be used by clients without the intervention of the component's developers." Hergebruik is een van de belangrijkste beloften van component-georienteerd programmeren. Maar als de programmeur van het oorspronkelijke component aanwezig moet zijn om alles in goede banen te laten verlopen (bijvoorbeeld enkele aanpassingen van het component naar wens van de nieuwe klant), dan is natuurlijk alle voordeel verdwenen. Het idee achter componenten is dat een programmeur, eens alle functionele vereisten vastliggen, in een virtueel warenhuis langs de rekken zou moeten kunnen wandelen en de componenten selecteren die hem van pas kunnen komen. Daarna smeedt hij deze

8 tezamen met eigen code, en eventueel voegt hij nog enkele componenten van eigen makelei toe. Normaalgesproken kent de programmeur die de componenten in het warenhuis is gaan kopen de ontwikkelaar van de componenten dus niet, en toch moeten de componenten kunnen aangepast worden aan deze specifieke nieuwe situatie. Deze twee waren volgens Meyer de belangrijkste kenmerken voor componenten: hergebruik door andere software constructies, en hergebruik in een situatie waar de oorspronkelijke programmeur niet noodzakelijk bekend (of bereikbaar) is. Om deze twee mogelijk te maken, komen weer een aantal vereisten op de voorgrond, die Meyer in de volgende vijf puntjes heeft gegoten. "Includes a specification of all dependencies (hardware and software platform, versions, other components)." Om een component succesvol in te bouwen in een systeem, moet je weten wat dit component nodig heeft om te kunnen werken. Een component kan een bepaald stuk hardware nodig hebben, of het kan misschien alleen draaien onder een bepaald operating system. Maar het kan ook zeer goed zijn dat een component bepaalde andere componenten nodig heeft om te werken. Meestal wordt gezegd dat een component bepaalde diensten ("services") nodig heeft. Zo'n services moeten zeer nauwkeurig omschreven worden, zodat een development tool op een algoritmische manier kan bepalen of een bepaald component succesvol zal draaien binnen het ontworpen systeem. Als component A bijvoorbeeld een component nodig heeft dat de vuile was doet, dan moet JBuilder zeker weten dat component A de vuile was aan component B kan geven, en dat component B het gewassen en gestreken goed terug aan A zal bezorgen. De eis dat alle benodigde diensten nauwkeurig worden beschreven, heeft een logische tegenhanger: "Includes a precise specification of the functionalities it offers." Als JBuilder zeker wil weten dat alle vuile was van component A netjes zal behandeld worden, dan moet JBuilder erop kunnen vertrouwen dat component B alles zal doen. Gevolg: de diensten die component B aanbiedt, moeten nauwkeurig beschreven worden, zodat ze kunnen vergeleken worden met de diensten die component A vereist. Alleen als zowel de benodigde als geleverde functionaliteit formeel wordt beschreven, kunnen componenten gecombineerd worden volgens een bepaalde hiërarchie (een boom of een netwerk) van "A gebruikt B gebruikt C". Als de specificaties machinaal kunnen behandeld worden, kan een tool nagaan welke diensten nog ontbreken, en eventueel zelfstandig op zoek gaan naar een component dat deze dienst aanbiedt in ons virtueel warenhuis. "Is usable on the sole basis of that specification."

9 Als tools moeten zorgen voor compositie van componenten, dan staat of valt hun werking met de correctheid van de specificaties. Als component B van daarjuist plechtig belooft de vuile was te zullen doen, maar in plaats daarvan alle kledingstukken groen verft, dan zal het samengestelde systeem in de problemen komen. Tools moeten erop kunnen vertrouwen dat de formele specificatie ook werkelijk de semantiek van het component weergeeft. Het is onmogelijk voor een tool om eigenhandig het gedrag van een component te observeren en daaruit algemene conclusies te trekken over het toepassingsgebied van het component. Hoe kan de JBuilder zeker weten dat de kleren NOOIT kanariegeel zullen terugkomen? De dualiteit tussen specificatie en implementatie is een veelbesproken onderwerp, en ook Betrand Meyer besteedt hier de nodige aandacht aan [SDM][OOSC]. Specificaties, of interfaces zijn belangrijk om twee redenen: herbruikbaarheid ("reusability"), en vervangbaarheid ("substitutability"). Het idee van hergebruik is dat reeds software wordt ingeschakeld, zonder dat hiervoor noodzakelijk alle code opnieuw doorlopen wordt zodat een tijdsbesparing wordt gerealiseerd. Om het code-browsen te vermijden, is een specificatie nodig. Dit kan gaan van een informeel stuk tekst ("dit component kan uw was doen"), tot specifieke codes die door tools kunnen gelezen en geïnterpreteerd worden. Vervangbaarheid is het omgekeerde van hergebruik: in een bestaand systeem wordt een component verwijderd, en in plaats daarvan wordt een ander component geïnstalleerd met (op zijn minst) dezelfde interface ("wast witter dan wit!"). Dit kan alleen als alle andere componenten enkel kijken naar de interface, en niet naar de implementatie. Software engineering is vrij uniek ten opzichte van de andere ingenieursdisciplines, omdat het onderscheid tussen ontwerp en implementatie veel vager is dan in andere takken. Om het in de woorden van Bertrand Meyer te zeggen: "You can fall from the bridge, but not from the map, and you won't get an electric shock from the circuit diagram" [SDM]. De vereiste dat een component bruikbaar is enkel op basis van de specificatie lijkt dus triviaal voor andere ingenieursdisciplines, maar is dat niet altijd voor software. Heel dikwijls is het verleidelijk om documentatie te verwaarlozen uit tijdsgebrek of nonchalance, en even dikwijls is het ook verleidelijk (of zelfs noodzakelijk) om de werking van routines te controleren door de code na te gaan. Bij component-georienteerd programmeren is black box reuse dus niet alleen aangemoedigd, het is ook verplicht. En daarom is Bertrand Meyer zo blij dat componenten typisch gezien in binaire vorm worden verspreid: het is veel moeilijker om de exacte werking van een binair component te achterhalen [SDM]. Op die manier wordt "information hiding" (of "data encapsulation") afgedwongen op een manier die veel strikter is dan de meeste compilers kunnen garanderen. Omdat de source niet verkrijgbaar is, is het onmogelijk te code te inspecteren en kan dus enkel vertrouwd worden op de specificatie. En zelfs als de code toch beschikbaar is, vanuit de open-source filosofie, is het niet zo vanzelfsprekend om "even vlug" iets aan te passen in het component, omdat dat hier nu juist beter uitkomt. Szyperski werpt hiertegen op dat het onderscheid tussen binaire en leesbare vorm niet altijd even strikt is (denk maar aan scripts), en dat "data encapsulation" meestal niet de voornaamste reden is voor de binaire vorm van componenten, maar toch denk ik persoonlijk dat Meyer hier een goed argument heeft. Sterker nog: uit commerciële

10 overwegingen zou "information hiding" toch wel eens de belangrijkste drijfveer kunnen zijn voor de binaire vorm. "Is composable with other components." Bent u verrast? Het woord zelf suggereert dat componenten deel zijn van een groter geheel. Toch is de vereiste niet zo vanzelfsprekend als ze eerst lijkt. Zoals de voorgaande kenmerken duidelijk maken, komt er heel wat bij kijken om zinvolle combinaties van componenten mogelijk te maken. Meyer vernoemt het zelf pas in een andere column [SDM], maar hier komt ook het vraagstuk van de standaards bij kijken. "Wiring standards" worden ze genoemd, en ze zijn nodig om verschillende componenten gegevens te laten uitwisselen. Zowel Meyer als Szyperski zijn het erover eens [SZYP][SDM] dat teveel standaards het leven nodeloos ingewikkeld zouden maken, maar dat het langs de andere kant niet wenselijk is om een enkele standaard te hebben. Er zijn enkele gevaren verbonden aan pluggen die passen in apparaten die daarvoor niet bedoeld zijn, zoals Meyer duidelijk maakt in een klaagzang over zijn batterijlader die in rook opging [SDM]. Er is nog een ander aspect aan verbonden: Szyperski beschrijft hoe veel objectgeorienteerde frameworks impliciet aannemen dat ze het enige systeem zijn, en dus moeilijk gecombineerd kunnen worden met andere frameworks. Dit maakt duidelijk dat programmeren met hergebruik in het achterhoofd niet noodzakelijk hetzelfde is als programmeren met combineerbaarheid in het achterhoofd. "Can be integrated into a system quickly and smoothly." Hoe makkelijker, hoe liever. Aangezien de vorige zes kenmerken allemaal de eenvoudige integratie van componenten tot doel hebben, verdenk ik Meyer er hier van een beetje breedsprakig geworden te zijn. In de column in kwestie [SDM] stond niet veel extra uitleg bij dit punt, maar ik vermoed dat Meyer hier duidt op het feit dat een component typisch gezien ook code bevat die specifiek is voorzien om het integratie-proces gemakkelijker te maken. Ik denk hierbij aan run-time checks op de parameters, op de interne consistentie, op routines om hotswapping mogelijk te maken, etc. In "klassieke" hergebruikte code vind je zo'n run-time checks niet vaak terug, omdat samenstelling meestal gebeurt op compile-time, en de compiler dus de meeste checks uitvoert. 1.3 Bruce Powel Douglass Bruce Powel Douglass was een van de auteurs die gevangen zat in het spervuur van columns tussen Bertrand Meyer en Clemens Szyperski [SDM]. Hij heeft zelf enkele

11 columns geschreven, waarvan sommige een antwoord op de vragen die Meyer en Szyperski elkaar en zichzelf stelden. Douglass' definitie van componenten samenvatten is makkelijk, want hij doet het voor ons [SDM]: "A component is really a large-scale object used in an idiomatic way." Hij gaat verder met verklaren dat een component kan bestaan uit zowat elke grootteorde. Typisch gezien is een component kleiner dan een subsysteem van de architectuur, en typisch omvat het een of meerdere objecten. Doordat Douglass een component identificeert met een enkele interface, suggereert hij nochtans dat een component slechts bestaat uit een object, en ook elders gaat hij van deze veronderstelling uit. Zo'n object moet dan wel aan bepaalde vereisten voldoen om een component te kunnen zijn. Het voornaamste doel van deze eisen is de vervangbaarheid van een component binnen een bestaand systeem te vergemakkelijken. Merk op dat hij hiermee voorbijgaat aan een tweede aspect, namelijk de samenstelling van componenten tot een nieuw systeem. Douglass beperkt zich tot twee brede eisen: ten eerste moeten interface en implementatie duidelijk gescheiden zijn, en ten tweede moet het component grondig gedocumenteerd zijn. Documentatie moet zowel de interface als de pre en postcondities en varianten omvatten, het moet de aanvaardbare sequenties van functie aanroepen (het protocol) vastleggen, en ook het "gedrag". Protocol en gedrag kunnen onder andere vastgelegd worden door een "state diagram". In scherpe tegenstelling tot Szyperski, laat Douglass expliciet toe dat components ook "state" bevatten. Hun gedrag is dus niet alleen afhankelijk van de huidige parameters, maar ook van alle vorige function calls en hun parameters. Het voorbeeld dat hij aanhaalt omvat enkele componenten van hetzelfde type, namelijk twee verkeerslichten. Ook dit is in strijd met wat Szyperski eerder aanhaalde als definitie van een component. Douglass is zich hiervan bewust, maar gaat jammer genoeg niet dieper in op de reden hiervoor. Een polemiek over "statefulness" van componenten, hoewel nogal detaillistisch, had nochtans wel licht kunnen werpen op de verschillende impliciete stellingnames van de auteurs. Het ziet ernaar uit dat Douglass -samen met Meyer- componenten eerder ziet als geïnstantieerde objecten met een identiteit, dichter bij de definitie van CORBA componenten dan COM componenten. 1.4 Siemens Gang of Five Genoemde desperado's zijn eerder berucht om hun werk op het gebied van patterns, maar in hun boek [SGOF] op pagina 385 geven ze ook een expliciete definitie van een component: A component is an encapsulated part of a software system. A component has an

12 interface. Components serve as the building blocks for the structure of a system. At a programming-language level, components may be represented as modules, classes, objects or a set of related functions. Zoals ze zelf verder ook aangeven, hebben ze het woord component heel ruim opgevat. De definitie gaat voorbij aan aspecten zoals het doel van component-georienteerde ontwikkeling, het geeft niet aan waarom een component geïnkapsuleerd is, en het legt niet meteen nadruk op het belang van scheiding tussen interface en implementatie. Aspecten zoals hergebruik, combineerbaarheid, semantiek en dergelijke worden volledig terzijde gelaten. Hoewel de definitie niet veel zegt over "good practice" in verband met componenten, komen toch veel aspecten van hergebruik, inkapsulatie, vervangbaarheid en evolueerbaarheid en dergelijke aan bod in het book. Niet onlogisch, aangezien patterns een poging zijn om "good practice" op een heldere manier op te slaan en door te geven. Veel van de patterns die betrekking hebben op objecten kunnen integraal worden toegepast op componenten. Het "observer" patroon, bijvoorbeeld, wordt intensief gebruikt bij JavaBeans en in de Beanbox, waar event-handling altijd gebeurt via het toevoegen van "listeners". Hierover later nog meer. 1.5 Andere Veel boeken die software ontwikkelingstechnieken bespreken, of die verwijzen naar hergebruik in het algemeen, zullen vroeg of laat de term "component" gebruiken. Het woord heeft dan niet noodzakelijk alle extra betekenissen die het in andere werken of deze thesis krijgt. "Component" is immers geen nieuw uitgevonden term, en dikwijls wordt het gebruikt in de klassieke betekenis van onderdeel van een compositie. Ivar Jacobson, Martin Griss en Patrik Jonsson vermelden in hun boek [IMP] op pagina 85 expliciet dat ze het woord gebruiken in de breedst mogelijke zin: A component is a type, class or any other workproduct that has been specifically engineered to be reusable. Aangezien hun boek specifiek over hergebruik gaat, ligt de klemtoon bij componenten meer bij hergebruik dan bij de andere aspecten, zoals vervangbaarheid, run-time combineerbaarheid en dergelijke. Ook Carlo Ghezzi, Mehdi Jazayeri en Dino Mandrioli staan nauwelijks stil bij het woord "component". Het boek beschouwt modularisatie technieken in het algemeen als een manier om een groot probleem onder te verdelen in verschillende kleinere problemen, die elk eenvoudiger op te lossen zijn en/of recursief onder te verdelen. Een goede module (of

13 component) vertoont natuurlijk wel eigenschappen zoals "data encapsulation", functionele cohesie, losse "coupling" met andere modules, enzovoort [FUND]. Dit toont aan dat veel aspecten van component-georienteerd programmeren weinig revolutionair zijn, maar eerder goede algemene principes die al zeer lang gekend zijn. 1.6 Kenmerken van componenten Gebaseerd op de auteurs die hiervoor besproken zijn, en op enkele huidige standaards voor component-systemen, ben ik tot een eigen definitie gekomen van componenten: Een component is een softwarematige eenheid, dikwijls binair, waarbij speciale inspanning is geleverd op vlak van interfaces, documentatie en code met als voornaamste doel samenstelbaarheid, herbruikbaarheid en vervangbaarheid. Zoals elke zichzelf respecterende definitie vergt ze enige toelichting. Een component wordt gedefinieerd als een eenheid. Dit betekent dat, zelfs al is ze samengesteld, naar buiten toe fungeert het als een enkel... component. Er is geen onderverdeling mogelijk, het is niet mogelijk een component deels te herbruiken of enkele stukken aan te passen aan nieuwe behoeften. Dat componenten dikwijls binair worden verspreid is om deze eenheid nog strikter op te leggen. De interfaces zijn een formele beschrijving van de aangeboden en de vereiste functionaliteit. Het is een informatiestroom van het ene software-tool naar het andere. Componenten zoeken en samenstellen moet op basis van de interface kunnen gebeuren, en het moet grotendeels automatisch kunnen gebeuren. Een sterke scheiding tussen interface en implementatie komt ten goede aan zowel samenstelbaarheid, herbruikbaarheid als vervangbaarheid. Documentatie beschrijft het component op een minder formeel niveau. Het is informatie van de component-ontwikkelaar naar de component-gebruiker, die typisch ook een programmeur is. Documentatie dient om samenstelbaarheid en herbruikbaarheid te vergroten. Inspanningen op vlak van de code kunnen beschouwd worden als een informatiestroom van het component naar de omringende componenten. Ze beinvloeden rechtstreeks de samenstelbaarheid, herbruikbaarheid en vervangbaarheid van het component. Extra code om de binnenkomende parameters te controleren vergroot bijvoorbeeld de samenstelbaarheid. Extra code die rekening houdt met zoveel mogelijk verschillende situaties vergroot de herbruikbaarheid. Extra abstractie-lagen en strikte scheiding van specificatie en implementatie vergroten de vervangbaarheid. Samenstelbaarheid is een essentieel kenmerk van componenten: het laat toe de functionaliteit van verschillende componenten te combineren om uiteindelijk een software

14 systeem te bekomen dat voldoet aan gestelde eisen. Een van de constructies om samenstelbaarheid te vergroten zijn de "wiring standards" zoals COM, CORBA en JavaBeans. Een zeer sterke vorm van samenstelbaarheid is samenstelbaarheid op runtime. Voor Szyperski is dit zelfs een noodzakelijke voorwaarde om van een component te spreken. Herbruikbaarheid is de droom van elke "software engineer": door bestaande componenten in te voegen, is het mogelijk een software systeem te realiseren met veel minder tijd en middelen dan nodig zouden zijn om alles van nul te ontwikkelen. Als de herbruikbaarheid van een component optimaal is, moet de gebruiker van een component niet noodzakelijkerwijs in contact staan met de oorspronkelijke ontwikkelaar van het component. Meyer's vereiste dat een component hergebruikt moet worden zonder tussenkomst van de oorspronkelijke ontwikkelaar zit dus eerder impliciet vervat in de definitie. Vervangbaarheid komt ten goede aan wat Szyperski "evolvability" noemt: als een component kan vervangen worden door een nieuw component dat dezelfde interface realiseert, kan het systeem stap voor stap evolueren zonder dat er grote, algemene upgrades moeten gebeuren die tijdelijk het volledige systeem lamleggen en die een bedrijf dus extra tijd en geld kosten. Indien het systeem erop voorzien is, kan een bepaald component zelfs bij run-time vervangen worden, zonder enig tijdverlies. Een ander voordeel van vervangbaarheid is de mogelijkheid tot eenvoudige invoeging van een component waarvan een software fout is verbeterd, of waarvan de niet-functionele eigenschappen (zoals systeemvereisten of snelheid) zijn verbeterd. Enkele algemene principes die de vervangbaarheid ten goede komen zijn een sterke scheiding van specificatie en implementatie, en ook een lage "coupling" tussen de verschillende componenten. Nog een laatste opmerking: deze definitie gaat de discussie over "statefulness" uit de weg, om twee redenen. Ten eerste is het vermijden van "statefulness" (onder de vorm van globale variabelen, enz) volgens mij geen noodzakelijke voorwaarde om een component te maken. Het is natuurlijk wel een heel goed idee om dergelijke addertjes te vermijden, en dus valt het vermijden van "statefulness" onder de noemer "speciale inspanning met als doel " enzovoort. Ten tweede geloof ik dat Szyperski's definitie van een component niet wezenlijk van andere definities. Een stuk software dat component-georienteerd is volgens de definitie van Meyer, zal ook component-georienteerd zijn volgens Szyperski. Alleen zal Meyer een aantal objecten aanwijzen en zeggen: "dit zijn verschillende componenten die hetzelfde gedrag vertonen, en dus tot dezelfde klasse kunnen gerekend worden", terwijl Szyperski dezelfde objecten zal aanwijzen en zeggen: "dit zijn verschillende manifestaties van hetzelfde component".

15 2 Distinctie Bij elke nieuwe methodiek, hype of nieuw paradigma, is het belangrijk om zich af te vragen of het niet gaat om oude wijn in nieuwe flessen. In dit hoofdstuk wordt componentgeorienteerd programmeren vergeleken met enkele andere paradigma's. 2.1 Object-Oriented programming Wat bieden componenten meer dan objecten? De twee worden wel eens door elkaar gebruikt, en om alles nog makkelijker te maken is het onderscheid tussen klassen en objecten ook niet altijd even strikt. Een anekdote als voorbeeld van verwarring tussen objecten en klassen. In de tweede kandidatuur moesten we ("wij", dat waren toen "the RUCA Lions". Bescheidenheid is voor kwezels!) een object-georienteerd programma ontwerpen dat het virtueel geheugen in een computer nabootste. Na veel vijven en zessen hadden we een prachtig UML schema: "de processor" genereert een logisch adres, en geeft het door aan de MMU. De MMU vertaalt dit naar een virtueel adres. Dit adres kan ofwel gecached zijn, ofwel verwijzen naar een fysiek adres in het RAM geheugen, ofwel naar een adres of de harddisk, zodat het moet worden ingeswapped. De MMU sprak dus cache, RAM of disk aan, en gaf (eventueel na een swap) de waarde van het gevraagde adres terug aan de CPU. In ons software model zaten dus enkele vereenvoudigingen (zoals MMU die zelf de harddisk aansprak), maar al bij al vonden we dat we een "clean" model hadden weten op te bouwen. Nu was een van de opdrachten voor het project dat we de gebruikte strategieën moesten kunnen vervangen. Het moest dus mogelijk zijn een nieuwe MMU of een nieuwe cache te installeren, elk met specifieke vervangingsstrategieën. Zowel de cache als het RAM geheugen moesten van grootte kunnen veranderen, om de weerslag te kunnen meten op het swap gedrag van onze virtuele virtuele (sic) machine. De problemen begonnen pas bij het implementeren. De MMU bijvoorbeeld was een object dat bijna alle ander objecten moest kunnen aanspreken, en omgekeerd. Maar tegelijk moesten vele objecten ook kunnen vervangen worden terwijl het programma liep. In onze prachtige schema's liepen er simpelweg een aantal pijlen van MMU naar CPU, van MMU naar cache, van MMU naar RAM. In praktijk bleken er verschillende kandidaat-mmu's te zijn, en verschillende kandidaat-caches, enzoverder. We hebben alles dan opgelost door middel van stapels en stapels pointers, en ontwierpen we een heel stel ingewikkelde procedures om ervoor te zorgen dat als bijvoorbeeld de cache werd vervangen, dat dan alle pointers naar de huidige cache ook vervangen werden.

16 Wat was er gebeurd? Het antwoord op deze vraag kwam pas bij me op terwijl ik deze thesis aan het voorbereiden was: we hadden het prototype verward met de eigelijke objecten. In ons model sprak het prototype van de MMU het prototype van het RAM geheugen aan. We stonden niet stil bij de vraag hoe de MMU het RAM geheugen zou vinden. Dat leek ons even vanzelfsprekend als de kwestie hoe het MMU de klassedefinitie van het RAM geheugen zou weten te vinden. We hadden het onbewuste idee dat als we de headerfile van de RAM-klasse toevoegden aan de code van de MMU, dan liet de compiler ons toe om het RAM aan te spreken. Maar weten dat een bepaalde klasse bestaat is nog niet genoeg om ook effectief objecten van die klasse terug te vinden. Onze ontwerpen hielden dus geen rekening met het onderscheid tussen klasse en object. Bij componenten is het onderscheid tussen klasse en object, tussen specificatie en implementatie, zo mogelijk nog belangrijker. Ik zou willen beginnen met te zoeken naar een goede definitie van wat objecten juist zijn, en van daaruit te vertrekken om duidelijk te maken dat componenten een meerwaarde bieden Object-Oriented Programming: a Unified Foundation [OOPUF] Dit boek biedt een formele notatie om eigenschappen van object-georienteerde talen te beschrijven. Het benadert object-orientatie vanuit een sterk taal-theoretische hoek, en minder vanuit de "software engineering" hoek. De potentiële voordelen van componenten liggen echter niet in het taal-theoretische. Component-georienteerd programmeren wordt niet geassocieerd met een volledig nieuwe programmeertaal, maar vertrekt vanuit bestaande talen zoals C++, Java, VB, Eiffel, en andere. Maar het boek kan misschien wel dienen om een goede definitie van object-orientatie te geven. Op pagina 38 staat: Objects are programming items grouped in classes and possessing an internal state that may be accessed and modified by sending messages to the object. Iets verder, op pagina 40 staat: An object is a programming unit that associates data with the operations that can use or affect these data. Een object is dus, net als een component, een eenheid. Dit suggereert dat objecten geschikte constructies kunnen zijn om componenten van te bouwen. Het definieert een aantal operaties. Dit is gelijkaardig met de interfaces van componenten, maar in deze definitie is met opzet in het ongewisse gelaten hoe de definitie van operaties juist gebeurt. Merk ook op dat de eerste definitie expliciet gewag maakt van een "internal state", en dus tot op zekere hoogte onverenigbaar is met de definitie van componenten die Szyperski geeft.

17 Giuseppe Castagna beschouwt "late binding" als de belangrijkste eigenschap van objectorientatie: als een member-functie van een object wordt opgeroepen, is het op compiletime niet meer noodzakelijk bepaald welke code precies zal worden uitgevoerd. Als "vorm" een interface is die de methode "draw()" bevat, kunnen het object "vierkant" en het object "cirkel" (beide subtypes van "vorm") deze methode een heel andere invulling geven. Als ons tekenprogramma dan een "vorm" moet tekenen, roept het simpelweg de methode "draw" op, zonder te moeten nagaan of de vorm in kwestie nu een vierkant, cirkel, of iets geheel nieuw is. Terzijde: Castagna brengt late binding terug tot een vorm van function overloading, waarbij hij aantoont dat typische object-georienteerde talen een zekere vorm van function overloading negeren, omdat ze uitgaan van minimale informatie bij het compileren. Dat is eenvoudig aan te tonen met twee functies die dezelfde naam hebben, maar waarbij de een een argument van het basistype aanvaardt, terwijl de andere een argument van het subtype aanvaardt. De voorbeeld-code toont aan dat onder bepaalde omstandigheden de functie wordt aangeroepen die het basistype behandelt, terwijl toch een subtype als argument werd gegeven. Om terug te komen op de relatie tussen objecten en componenten: de "late binding" bevordert vervangbaarheid doordat een subtype kan gebruikt worden waar een basis type werd verwacht, en het bevordert samenstelbaarheid doordat nieuwe subtypes kunnen gebruikt worden door code die geschreven kan zijn nog voor het subtype bekend was. Het mag duidelijk zijn dat "late binding" een belangrijk hulpmiddel is bij zowel object-orientatie als bij componenten. Szyperski introduceert nog een hulpmiddel voor componenten: "very late binding" [SZYP] A Theory of Objects [THEO] Het boek opent met een definitie van objecten op pagina 8: The Object-Oriented approach to programming is based on an intuitive correspondence between a software simulation of a physical system and the physical system itself. An analogy is drawn between building an algorithmic model of a physical system from software components and building a mechanical model of a physical system from concrete objects. By analogy, the software components are themselves called objects. Merk op dat het woord "components" hier wordt gebruikt in de meest algemene betekenis: onderdeel van een samenstelling. Voor de rest benadrukt de definitie een overeenkomst tussen de objecten binnen de software, en de objecten in de wereld die door de software gemodelleerd wordt. Hier schuilt zowel de sterkte als het gevaar bij object-georienteerde analyse: object is zowat het meest vage woord dat er bestaat in het vocabularium van een

18 taal, en het kan werkelijk op alles slaan. Het boek ontleedt de grote en vage groep van objecten in drie delen, die elk geassocieerd worden met een fase binnen een objectgeorienteerd project. In de analyse-fase zijn objecten concrete dingen die gemodelleerd zullen worden. Als bijvoorbeeld een softwarepakket wordt ontworpen om een zonnestelsel uit te beelden zullen de objecten planeten zijn. In de designfase komt er een soort objecten bij: ze zijn geconcretiseerde abstracties, nodig om het model te beschrijven. Planeten, bijvoorbeeld, hebben elk hun eigen omloopbaan. Dit zijn geen fysieke entiteiten meer, maar wel degelijk "dingen" (let op de vage term) om het model te laten werken. Uiteindelijk resulteert dit alles in software-matige implementaties, in code die onderverdeeld is in objecten. Sommige daarvan zijn de implementatie van de fysieke objecten (planeten), andere van de abstracties (omloopbanen), en nog andere zijn alleen gecreëerd om technische implementatie-redenen (lijsten, abstracte datatypes,...) Dit alleen maar om mijn punt te onderstrepen dat component-georienteerd programmeren in hetzelfde bedje ziek is. Het woord "component" is net zo vaag als "object", en net zo vatbaar voor misverstanden. Ook componenten zullen gebaseerd zijn op een intuïtieve overeenkomst tussen een software-model en de fysieke wereld waar de software betrekking op heeft. Zo zullen er componenten zijn die betrekking hebben op fysieke entiteiten. In het project dat deze thesis vergezelt zitten bijvoorbeeld componenten die personen voorstellen, of kaarten uit het spel. Daarnaast bestaan er componenten die bepaalde abstracties voorstellen. In mijn project zitten componenten die "schade" voorstellen, of een component dat het spelverloop voorstelt. Dat component vervangen zou betekenen dat andere spelregels gelden. En tenslotte bestaan er componenten die gecreëerd zijn enkel omdat ze de creatie van software vergemakkelijken. Een database component bijvoorbeeld stelt niks uit de fysieke wereld voor, maar maakt het wel een stuk makkelijker om bepaalde gegevens op te slaan en terug te vinden. In deze zin vertoont component-georienteerd ontwerpen dus veel overeenkomsten met object-georienteerd ontwerpen. Ik denk dat het voornaamste verschil er een van schaal is: in een component-georienteerd ontwerp zal een component typisch gezien groter zijn en/of een belangrijker deel uit de werkelijkheid modelleren dan een object. Maar dit is geen wetmatigheid, en in object-georienteerde systemen kunnen zeker objecten voorkomen die groter zijn dan een flink uit te kluiten gewassen component "Het beste boek Java 2.0" Het ontbreekt dit boek nochtans niet aan ambitie, maar uiteindelijk is de bedoeling van het boek het aanleren van een enkele programmeertaal: Java. Omdat Java een objectgeorienteerde taal is, waagt het boek zich ook aan een definitie van object-orientatie. Ik heb dit boek genomen als voorbeeld voor meer populaire literatuur, die programmeren niet zozeer vanuit de academisch-theoretische hoek benadert, maar vanuit een semiprofessionele hoek. Op pagina 241 staat:

19 In plaats van programma's op een top-down lineaire manier aan te pakken zoals traditionele programmeertalen zoals Pascal of C, probeert OOP een probleem in onderdelen te splitsen. De oplossing concentreert zich op deze onafhankelijke objecten en hun relatie met andere objecten. Het eerste dat me opviel was een sterke identificatie van programmeertaal met het programmeerparadigma. Dit is niet altijd onterecht: vele talen werden ontworpen om nieuwe inzichten in te verwerken, en lenen zich dus beter tot dat ene paradigma dan tot andere. Zo werd Pascal ontworpen om procedureel programmeren te vergemakkelijken. Modula-2 zag het levenslicht om nieuwe vereisten in verband met apart compileren in te vullen. Oberon om object-georienteerde concepten in te verwerken, en Eiffel kwam er om ideeen over object-orientatie en hergebruik in te verwerken. Toch is het perfect mogelijk om in Oberon of Eiffel op een procedurele manier te werken, en object-georienteerde constructies te negeren. Omgekeerd is het ook mogelijk om zelfs in assembler op een object-georienteerde manier te werk te gaan. Alleen zijn er geen speciale constructies voorhanden om alles makkelijker en minder foutgevoelig te laten verlopen. Toch is de link tussen taal en paradigma niet vergezocht. Misschien is het wel een goed idee om een taal te ontwerpen die specifiek bedoeld is om componenten in te programmeren? Hier zou ik graag op terugkomen in het verlanglijstje. De definitie stelt ook dat er een contrast is tussen object-georienteerde analyse, en de "top-down lineaire manier". Hoewel het boek daarmee doelt te suggereren dat de objectgeorienteerde manier makkelijker of natuurlijker is, duidt het wel op een mogelijk probleem bij object-georienteerd design: de niet-lineariteit van de resulterende constructie. Szyperski behandelt de mogelijke gevaren in meer detail Clemens Szyperski [SZYP] Szyperski's definitie van objecten is zeer summier: "encapsulation of state and behaviour, polymorphism, and inheritance" [SZYP]. Tegelijk zijn dit ook allemaal eigenschappen van componenten. Verder op pagina 10 wordt ook weer duidelijk dat Szyperski en andere auteurs lichtjes verschillende visies hebben op componenten, en dus hun relatie tot objecten. Szyperski stelt vast (hoewel hij geen bronnen vernoemt) dat individuele objecten bijna nooit worden verkocht of ingezet. Hij concludeert daaruit dan een component dus een meer statische eenheid is: een klasse, of een groep klassen (bv. in een module). Vandaar ook zijn stelling dat een component als geheel nooit een instantie is, in tegenstelling met bijvoorbeeld de visie van Meyer of met het idee achter Javabeans. Maar wat maakt een component dan meer dan een -of meer- klassen? Ten eerste omvat de definitie van objecten geen eisen omtrent samenstelbaarheid, en ze gaat ook voorbij aan commerciële eisen. Er is nooit een levende markt gekomen voor objecten (of klassen)

20 gekomen, op enkele succesvolle uitzonderingen na, en dat valt te verklaren door de catch 22 rond objecten en ook componenten: de extra inspanning die het kost om een wijd herbruikbaar component te maken in plaats van een specifieke oplossing, is alleen gerechtvaardigd als het wordt terugverdiend op de markt [SZYP]. Zo'n markt moet dus al bestaan voor ze op gang kan komen. Szyperski noemt ook nog een aantal andere oorzaken waardoor object-georienteerde technologie er mogelijks niet in is geslaagd om een bloeiende markt in objecten te starten. Een typisch object (en naar mijn mening ook een klasse; al lijkt Szyperski hier het onderscheid niet te maken) heeft geen duidelijke bedoeling voor de eindgebruiker. Het is meer een gebruiksvoorwerp van de doorgewinterde programmeur. Zelfs in het beste geval is hergebruik van objecten (en klassen) dus voorbehouden voor een relatief kleine doelgroep. Meestal zijn ze zelfs helemaal niet bedoeld voor hergebruik door een derde partij, maar hoogstens door de oorspronkelijke programmeur. Om woorden te gebruiken uit mijn eigen definitie voor componenten: meestal zijn te weinig inspanningen geleverd om samenstelbaarheid en uitbreidbaarheid te garanderen. Een andere eigenschap van object-georienteerd design is dat ze niet noodzakelijk lineair is. Terwijl een procedureel design vrij sterk gelaagd is (toepassing bovenop libraries bovenop systeemsoftware bovenop hardware), leent object-orientatie er zich toe om een veel minder gelaagd systeem op te bouwen met clusters of netwerken van objecten die elkaar kunnen aanspreken. Constructies als inheritance en overloading creëren extra verbindingen die gewoonlijk laag-overschrijdend zijn, en dus de lineariteit niet ten goede komen. Op pagina 48 en verder doet Szyperski uit de doeken welke gevaren er kunnen optreden als de top-down lineariteit wordt doorbroken. In functionele omgeving (zonder callbacks) kunnen functies alleen beroep doen op functies die in dezelfde of een lagere laag gesitueerd zijn. Deze functies kunnen op hun beurt dan weer functies oproepen uit dezelfde of onderliggende lagen. Met andere worden: controle wordt nooit aan een hogere laag teruggegeven voordat de lagere functies volledig uitgevoerd zijn en de onderliggende laag dus terug in een stabiele, consistente toestand is. De pre- en postcondities van een functie in de onderliggende laag laten geen ruimte voor glitches: voor de aanroep van de functie moet de preconditie gelden, als de functie terugkeert moet de postconditie gelden. De bovenliggende laag merkt niks van de uitvoering van de onderliggende functie, en kan dus ook geen inconsistente toestand opmerken. Vervolgens doet Szyperski uit de doeken hoe callbacks deze schijnbaar triviale vereiste kunnen doorbreken. Een callback functie is deel van een hoger-gelegen laag, maar ze wordt opgeroepen vanuit een lager deel uit de hiërarchie. Terwijl de onderliggende laag dus nog bezig is met de verwerking van een opdracht (de onderliggende functie is nog niet beeindigd), wordt de hogere laag terug actief. Op dat moment is het mogelijk dat de bovenliggende laag (de callback functie) een toestand waarneemt die niet consistent is. Dit is allemaal nogal abstract, en ik verwijs graag naar Szyperski's boek voor een meer gedetailleerd voorbeeld. Als we overgaan naar objecten, dan kan ik een voorbeeld geven dat geinspireerd is op wat Szyperski aanvoerde, maar specifiek toegepast op java. Voor

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

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

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

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

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

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

icafe Project Joeri Verdeyen Stefaan De Spiegeleer Ben Naim Tanfous

icafe Project Joeri Verdeyen Stefaan De Spiegeleer Ben Naim Tanfous icafe Project Joeri Verdeyen Stefaan De Spiegeleer Ben Naim Tanfous 2006-2007 Inhoudsopgave 1 2 1.1 Programmeertaal PHP5..................... 2 1.2 MySQL database......................... 3 1.3 Adobe Flash...........................

Nadere informatie

Sparse columns in SQL server 2008

Sparse columns in SQL server 2008 Sparse columns in SQL server 2008 Object persistentie eenvoudig gemaakt Bert Dingemans, e-mail : info@dla-os.nl www : http:// 1 Content SPARSE COLUMNS IN SQL SERVER 2008... 1 OBJECT PERSISTENTIE EENVOUDIG

Nadere informatie

Vorig jaar in 5v cluster, tot en met OO hoofdstukken, geen problemen. Nu in mengcluster, tot OO hoofdstukken, wel problemen bij 4h leerlingen

Vorig jaar in 5v cluster, tot en met OO hoofdstukken, geen problemen. Nu in mengcluster, tot OO hoofdstukken, wel problemen bij 4h leerlingen Eerste programmeertaal Leren programmeren vs. een programmeertaal leren In Nijmegen: Algol68 als basis voor o.a. Modula-2 en C Voor Codi/Boxmeer: Pascal, Java, HTML/PHP Niet helemaal tevreden over Java

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

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 plug-in is heel eenvoudig te installeren met een setup-programma. Waarna je een aantal menu opties in het tools menu er bij krijgt.

De plug-in is heel eenvoudig te installeren met een setup-programma. Waarna je een aantal menu opties in het tools menu er bij krijgt. Plsqldoc Genereer je documentatie Beeklaan 444 2562 BK Den Haag www.darwin-it.nl info@darwin-it.nl KvK 27283780 ING 65.35.40.663 Technical Architect Net als (vrijwel) elke ontwikkelaar vind ik het documenteren

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

Component-based software engineering

Component-based software engineering Component-based software engineering Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 1 CBSE essentials Independent components gespecificeerd door hun interfaces. Component standards

Nadere informatie

Technisch Ontwerp W e b s i t e W O S I

Technisch Ontwerp W e b s i t e W O S I Technisch Ontwerp W e b s i t e W O S I WOSI Ruud Jungbacker en Michael de Vries - Technisch ontwerp Website Document historie Versie(s) Versie Datum Status Omschrijving / wijzigingen 0.1 20 nov 2008 Concept

Nadere informatie

Systems Engineering en de Modelgebaseerde aanpak. Eric Burgers

Systems Engineering en de Modelgebaseerde aanpak. Eric Burgers Systems Engineering en de Modelgebaseerde aanpak Eric Burgers 2 Context: Toepassing MBSE in tunnelprojecten Modelprecisie / formaliteit LST 1.2 LST 1.1 Nijverdal (2011) SysML Statisch model Dynamisch model

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

Dynamiek met VO-Script

Dynamiek met VO-Script Dynamiek met VO-Script Door Bert Dingemans DLA Ontwerp & Software bert@dla-architect.nl Inleiding Op de SDGN nieuwsgroep voor Visual Objects ontstond laatst een draad van berichten over de nieuwe libraries

Nadere informatie

Inhoudelijke reactie EGEM op adviesrapport Telematica Instituut: 'Over het service-georiënteerde gehalte van StUF 3.0.'

Inhoudelijke reactie EGEM op adviesrapport Telematica Instituut: 'Over het service-georiënteerde gehalte van StUF 3.0.' Inhoudelijke reactie EGEM op adviesrapport Telematica Instituut: 'Over het service-georiënteerde gehalte van StUF 3.0.' Versie Concept 0.2 Datum 15-11-2007 Inhoudsopgave 1 Inleiding...2 2 Inhoudelijke

Nadere informatie

Software-Ontwikkeling I Academiejaar 2006-2007

Software-Ontwikkeling I Academiejaar 2006-2007 Software-Ontwikkeling I Academiejaar 2006-2007 Project: Bibliotheekbeheer 1 1. Digitale bibliotheek a. Inleiding Bibliotheken houden onder meer hun collecties van uitleenbare artikels bij in digitaal formaat.

Nadere informatie

Verantwoording van het Logica In Lagen referentiemodel

Verantwoording van het Logica In Lagen referentiemodel Verantwoording van het Logica In Lagen referentiemodel Bijlage bij Meer inzicht in gelaagde architectuur - Deel 1: Uitleg, terminologie en methoden [Pruijt10]. Leo Pruijt, Lectoraat Architectuur van Digitale

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

Cloud Computing. Definitie. Cloud Computing

Cloud Computing. Definitie. Cloud Computing Cloud Computing Definitie In de recente literatuur rond Cloud Computing zijn enorm veel definities te vinden die het begrip allemaal op een verschillende manier omschrijven. Door deze diversiteit zijn

Nadere informatie

Gimme Five! Op weg naar TYPO3 5.0 'Phoenix'

Gimme Five! Op weg naar TYPO3 5.0 'Phoenix' Gimme Five! Op weg naar TYPO3 5.0 'Phoenix' Waarom TYPO3 5.0? Waarom TYPO3 5.0? Enkele redenen: Waarom TYPO3 5.0? Enkele redenen: Complexiteit De TYPO3 Core architectuur heeft zijn limiet bereikt en is

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

Virtueel of Fysiek. Uitdagingen bij migratie naar Windows 7

Virtueel of Fysiek. Uitdagingen bij migratie naar Windows 7 Het jaar 2011/2012 staat voor veel organisaties in het teken van Windows 7. De overstap van Windows XP naar Windows 7 lijkt in eerste instantie eenvoudig te zijn maar blijkt in de praktijk toch complex.

Nadere informatie

Software Quality Assurance Plan

Software Quality Assurance Plan FACULTEIT WETENSCHAPPEN Software Quality Assurance Plan Software Engineering groep 3 Jeroen Van den haute Versie Datum Auteur Commentaar 0.1 09/11/2010 Jeroen Van den haute Eerste versie 0.2 12/11/2010

Nadere informatie

High Performance Computing

High Performance Computing High Performance Computing Kristian Rietveld (krietvel@liacs.nl, kamer 138) Groep Computer Systems High-Performance Computing Optimizing compilers (generieke codes, maar ook specifieke rekenkernels). Parallel

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

Een Inleiding tot Software Engineering. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1

Een Inleiding tot Software Engineering. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1 Een Inleiding tot Software Engineering Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1 Software engineering De economie is compleet afhankelijk van software. Meer en meer systemen

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

Analyse Programmeertalen

Analyse Programmeertalen Analyse Programmeertalen De keuze van een programmeertaal mag niet onderschat worden. Het is dankzij deze taal dat de gebruiker interactie heeft met het complete systeem. Het is dus vanzelfsprekend dat

Nadere informatie

Waarmaken van Leibniz s droom

Waarmaken van Leibniz s droom Waarmaken van Leibniz s droom Artificiële intelligentie Communicatie & internet Operating system Economie Computatietheorie & Software Efficiënt productieproces Hardware architectuur Electronica: relais

Nadere informatie

CONFIDENTIEEL. EIB-RPT-880076 3 van 12. Samenvatting

CONFIDENTIEEL. EIB-RPT-880076 3 van 12. Samenvatting EIB-RPT-880076 3 van 12 Samenvatting Inleiding Dit rapport beschrijft de prototypekeuring van de SDUMJGA stemmachine RS- Vote. De RS-Vote stemmachine is bedoeld voor elektronisch gefaseerd stemmen en is

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

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

1 Inleiding in Functioneel Programmeren

1 Inleiding in Functioneel Programmeren 1 Inleiding in Functioneel Programmeren door Elroy Jumpertz 1.1 Inleiding Aangezien Informatica een populaire minor is voor wiskundestudenten, leek het mij nuttig om een stukje te schrijven over een onderwerp

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

Inhoudsopgave 3 INHOUDSOPGAVE

Inhoudsopgave 3 INHOUDSOPGAVE Inhoudsopgave 3 INHOUDSOPGAVE Auteur 5 Inleiding 7 1 Een website is geen project 9 2 Online strategie 11 1 Voor wie is de website en wat is het doel ervan? 12 2 De website als deel van een multi-omgeving

Nadere informatie

Testen van Java code met JML

Testen van Java code met JML Testen van Java code met JML Engelbert Hubbers Martijn Oostdijk Erik Poll University of Nijmegen Testen met JML p.1/23 Overzicht De specificatietaal JML voor Java Wat voorbeelden van JML specificaties

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

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

Flex_Rooster WERKBOEK. INTRODUCTIE iseries. Dit werkboek is eigendom van ICS opleidingen en mag niet worden meegenomen.

Flex_Rooster WERKBOEK. INTRODUCTIE iseries. Dit werkboek is eigendom van ICS opleidingen en mag niet worden meegenomen. Flex_Rooster WERKBOEK INTRODUCTIE iseries Dit werkboek is eigendom van ICS opleidingen en mag niet worden meegenomen. ICS Opleidingen Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt

Nadere informatie

Functionele beschrijving: scannen naar Exact Globe.

Functionele beschrijving: scannen naar Exact Globe. Functionele beschrijving: scannen naar Exact Globe. Algemeen Met de KYOCERA scannen naar Exact Globe beschikt u over een efficiënte oplossing om uw documenten te scannen naar Exact Globe. Met deze oplossing

Nadere informatie

ProjectHeatmap. Onderzoeksrapport v0.5 11-03-11 Dennis Wagenaar

ProjectHeatmap. Onderzoeksrapport v0.5 11-03-11 Dennis Wagenaar ProjectHeatmap Onderzoeksrapport v0.5 11-03-11 Dennis Wagenaar 1 Inhoudsopgave Inleiding...3 Gheat...4 Info...4 Voordelen...4 Nadelen...4 Google Fusion Tables...5 Info...5 Voordelen...5 Nadelen...5 OLHeatmap...6

Nadere informatie

Programmeren: Visual Basic

Programmeren: Visual Basic PETERSTUYVESANT COLLEGE INFORMATICA 2009-2010 Programmeren: Visual Basic Algemene Kennis: 01. Programmeren Programmeren is het schrijven van een computerprogramma, een concrete verzameling instructies

Nadere informatie

Reshaping the way you think and act to deal with the complex issues of today s world

Reshaping the way you think and act to deal with the complex issues of today s world Reshaping the way you think and act to deal with the complex issues of today s world HOE GAAT HET NU? We zetten allemaal verschillende methoden in om vraagstukken op te lossen, oplossingen te ontwerpen

Nadere informatie

Microsoft Excel. It s all about Excel - VBA

Microsoft Excel. It s all about Excel - VBA X Microsoft Excel Stap in de wereld van Visual Basic for Applications (VBA) binnen het Microsoft Office programma Excel. Leer hoe deze programmeertaal precies in elkaar zit en hoe u deze in de dagelijkse

Nadere informatie

UBC op Microsoft Windows 64-bits

UBC op Microsoft Windows 64-bits UBC op Microsoft Windows 64-bits Inleiding Op de 64-bits varianten van Windows werkt de UBC (en vele andere pakketten) op een andere manier dan op de oudere 32-bits varianten van deze Windows versies.

Nadere informatie

Wijzigingen volledig onder controle en geborgd

Wijzigingen volledig onder controle en geborgd Installation Management Platform IMProve 2014 is het ultieme hulpmiddel om het beheer van uw (terminal) serverfarm continu, stap voor stap, op een hoger niveau te brengen. Gedocumenteerd, geborgd en reproduceerbaar

Nadere informatie

Vraag 1. Vraag 1a TERUGKOPPELING PROEFTENTAMEN. Software architecture

Vraag 1. Vraag 1a TERUGKOPPELING PROEFTENTAMEN. Software architecture Software architecture IM0203 TERUGKOPPELING PROEFTENTAMEN Vraag 1 Vraag 1a Veel van de in het werkboek besproken patterns kunnen ingezet worden voor het referentiesysteem. We lopen de patterns hier stuk

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

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

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

Zelftest Informatica-terminologie

Zelftest Informatica-terminologie Zelftest Informatica-terminologie Document: n0947test.fm 01/07/2015 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INTRODUCTIE Deze test is een zelf-test, waarmee u

Nadere informatie

start -> id (k (f c s) (g s c)) -> k (f c s) (g s c) -> f c s -> s c

start -> id (k (f c s) (g s c)) -> k (f c s) (g s c) -> f c s -> s c Een Minimaal Formalisme om te Programmeren We hebben gezien dat Turing machines beschouwd kunnen worden als universele computers. D.w.z. dat iedere berekening met natuurlijke getallen die met een computer

Nadere informatie

Opdrachtformulering (pagina 3 van 7)

Opdrachtformulering (pagina 3 van 7) Afstudeerovereenkomst van Tim Wils Bijlage 1 Opdrachtformulering (pagina 3 van 7) Dit project betreft een eigen framework (soort API) waarmee relatief gemakkelijk en in korte tijd eindproducten opgezet

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

Wat is Arduino? Arduino = microprocessor (Atmel)

Wat is Arduino? Arduino = microprocessor (Atmel) Intro tot Arduino Wat is Arduino? Volgens de website: Arduino is an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software. It's intended for artists, designers,

Nadere informatie

Cover Page. The handle http://hdl.handle.net/1887/20225 holds various files of this Leiden University dissertation.

Cover Page. The handle http://hdl.handle.net/1887/20225 holds various files of this Leiden University dissertation. Cover Page The handle http://hdl.handle.net/1887/20225 holds various files of this Leiden University dissertation. Author: Heijstek, Werner Title: Architecture design in global and model-centric software

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

Perceptive Process. Release Notes. Version: 3.5.x

Perceptive Process. Release Notes. Version: 3.5.x Perceptive Process Release Notes Version: 3.5.x Written by: Product Knowledge, R&D Date: December 2015 2015 Lexmark International Technology, S.A. All rights reserved. Lexmark is a trademark of Lexmark

Nadere informatie

Werken met SNAP pakketten in Ubuntu 16.04

Werken met SNAP pakketten in Ubuntu 16.04 Werken met SNAP pakketten in Ubuntu 16.04 Eén van de nieuwe zaken die Canonical in zijn Ubuntu-reeks heeft geïntodruceerd zijn SNAP packages. Met convergency in het achterhoofd (zelfde look & feel zowel

Nadere informatie

Voor de database wordt een Access 2000 bestand gebruikt, met voorlopig 1 tabel:

Voor de database wordt een Access 2000 bestand gebruikt, met voorlopig 1 tabel: Eenvoudig voorbeeld. Er wordt verondersteld dat er met VS 2008 EXPRESS gewerkt wordt. Voor de database wordt een Access 2000 bestand gebruikt, met voorlopig 1 tabel: (Sommige schermafdrukken zijn afkomstig

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

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

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

Inhoudsopgave. Hoofdstuk 1.RMI...2

Inhoudsopgave. Hoofdstuk 1.RMI...2 - CORBA Inhoudsopgave Hoofdstuk 1.RMI...2 1.1.Inleiding...2 1.2.De remote...4 1.3.Het remote...5 1.4.De server...6 1.5.De server opstarten...8 1.6.De client applicatie...8 1.7.De stub en skeleton en...10

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

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

Uitleg algemene structuur WTell

Uitleg algemene structuur WTell Uitleg algemene structuur WTell Brondocument C:\WebServer\Handleiding\WTellAlgemeen\WTellStructuurGlobaal.odt Versiebeheer Versie Datum Uitleg 1.0v 21-09-11 1e versie met uitleg globale structuur WTell

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

Building Information Modeling Informatie in een digitaal prototype van het ontwerp kostenmanagement bbn adviseurs juni 2013

Building Information Modeling Informatie in een digitaal prototype van het ontwerp kostenmanagement bbn adviseurs juni 2013 Building Information Modeling Informatie in een digitaal prototype van het ontwerp kostenmanagement bbn adviseurs juni 2013 bron: Ector Hoogstad Architecten BIM BIM is een term die in het vakgebied bouw

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

Zelftest Java EE Architectuur

Zelftest Java EE Architectuur Zelftest Java EE Architectuur Document: n1218test.fm 22/03/2012 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST JAVA EE ARCHITECTUUR Nota:

Nadere informatie

Functionele beschrijving: scannen naar UNIT4 DocumentManager

Functionele beschrijving: scannen naar UNIT4 DocumentManager Functionele beschrijving: scannen naar UNIT4 DocumentManager Algemeen Met de KYOCERA Scannen naar UNIT4 DocumentManager beschikt u over een efficiënte oplossing om uw documenten te scannen naar UNIT4 DocumentManager

Nadere informatie

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken De business organisatie heeft altijd stijgende verwachtingen van uw IT organisatie. Meer dan ooit is het van

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

ADVIES voor mobiele toepassingen

ADVIES voor mobiele toepassingen ADVIES voor mobiele toepassingen Software-expertise bij KaHo Sint-Lieven Bart Blanckaert Joris Maervoet Overzicht software-expertise (1/2) 1. Begeleiden van bedrijven bij het maken van hun keuze in Hardwareplatformen

Nadere informatie

Zelftest Inleiding Programmeren

Zelftest Inleiding Programmeren Zelftest Inleiding Programmeren Document: n0824test.fm 22/01/2013 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST INLEIDING PROGRAMMEREN Deze

Nadere informatie

Auteur boek: Vera Lukassen Titel boek: Word Gevorderd 2010. 2011, Serasta Uitgegeven in eigen beheer info@serasta.nl Eerste druk: augustus 2012

Auteur boek: Vera Lukassen Titel boek: Word Gevorderd 2010. 2011, Serasta Uitgegeven in eigen beheer info@serasta.nl Eerste druk: augustus 2012 Auteur boek: Vera Lukassen Titel boek: Word Gevorderd 2010 2011, Serasta Uitgegeven in eigen beheer info@serasta.nl Eerste druk: augustus 2012 ISBN: 978-90-817910-7-6 Dit boek is gedrukt op een papiersoort

Nadere informatie

Erik Poll Martijn Warnier. http://www.cs.kun.nl/~erikpoll/linux

Erik Poll Martijn Warnier. http://www.cs.kun.nl/~erikpoll/linux Introductie Linux/UNIX Erik Poll Martijn Warnier http://www.cs.kun.nl/~erikpoll/linux Concrete doel van vandaag Basisvaardigheden UNIX/Linux werken met de command line shell file beheer proces beheer Betere

Nadere informatie

Terugkoppeling testen egeo internetpanel

Terugkoppeling testen egeo internetpanel www.rijksoverheid.nl Terugkoppeling testen egeo internetpanel Inleiding De Rijksdienst voor Ondernemend Nederland heeft in 2013 een nieuwe versie van de webapplicatie voor het bekijken en wijzigen van

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

Technologie en Interactie 3.2: software architectuur

Technologie en Interactie 3.2: software architectuur Technologie en Interactie 3.2: software architectuur Manual IAM-TDI-V2-Technologie en Interactie. Jaar 0809 blok 2 Oktober 2008 Fons van Kesteren 1/8 Inhoud Technologie en Interactie 3.2: software architectuur...

Nadere informatie

Programmeren in C++ (deel 1)

Programmeren in C++ (deel 1) FHT&L MODULE BESCHRIJVING Programmeren in C++ (deel 1) PRO4 Samenstelling: Cees van Tilborg, Thijs Dorssers Datum: september 2011 Versie: 1h Titel: Programmeren in C++ Identificatie Progresscode: PRO4

Nadere informatie

Functionele beschrijving: Scannen naar AFAS Profit.

Functionele beschrijving: Scannen naar AFAS Profit. Functionele beschrijving: Scannen naar AFAS Profit. Algemeen Met de Kyocera Scannen naar AFAS Profit beschikt u over een efficiënte oplossing om uw documenten te scannen naar AFAS Profit. Met deze oplossing

Nadere informatie

Uitgebreid eindwerkvoorstel Lokaliseren van personen en objecten met behulp van camera s

Uitgebreid eindwerkvoorstel Lokaliseren van personen en objecten met behulp van camera s Uitgebreid eindwerkvoorstel Lokaliseren van personen en objecten met behulp van camera s Sofie De Cooman 21 December 2006 Stagebedrijf: Interne begeleider: Externe begeleider: BarcoView Koen Van De Wiele

Nadere informatie

vanuit de technische en organisatorische omgeving, werk-verdeling, budget, planning, en hergebruik van componenten. Het documenteren van SA dient

vanuit de technische en organisatorische omgeving, werk-verdeling, budget, planning, en hergebruik van componenten. Het documenteren van SA dient 9 Samenvatting Software heeft vooruitgang in veel vakgebieden mogelijk gemaakt en heeft een toenemend invloed op ons leven en de samenleving in zijn geheel. Software wordt gebruikt in computers, communicatienetwerken,

Nadere informatie

Generiek framework voor administratieve toepassingen in een webgeörienteerde omgeving

Generiek framework voor administratieve toepassingen in een webgeörienteerde omgeving Generiek framework voor administratieve toepassingen in een webgeörienteerde omgeving Henk van de Ridder Stand van zaken 17 Maart 2007 Inhoud Probleemgebied afstudeerproject Oplossingsgebied afstudeerproject

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

High Performance Computing

High Performance Computing High Performance Computing Kristian Rietveld (krietvel@liacs.nl, kamer 138) Groep Computer Systems - Embedded systems - Specifieke software mappen op specfieke hardware. - Hardware synthesis. - Real-time

Nadere informatie

Application interface. service. Application function / interaction

Application interface. service. Application function / interaction Les 5 Het belangrijkste structurele concept in de applicatielaag is de applicatiecomponent. Dit concept wordt gebruikt om elke structurele entiteit in de applicatielaag te modelleren: softwarecomponenten

Nadere informatie

Het SEESCOA project; jouw user interface, altijd en overal

Het SEESCOA project; jouw user interface, altijd en overal Het SEESCOA project; jouw user interface, altijd en overal Kris Luyten Karin coninx 17 januari 2002 Samenvatting De informatica kende een ware revolutie voordat men tot de desktop PC gekomen is. 20 jaar

Nadere informatie

Jaarproject programmeren bij LORE

Jaarproject programmeren bij LORE Jaarproject programmeren bij LORE Elke onderzoeksgroep heeft een eigen karakter en vereisten. Zo ook met LORE. Opdat je zou weten wat we van je verwachten maar ook wat je van ons mag verwachten, hebben

Nadere informatie

Project Objectgericht Programmeren : Deel 3

Project Objectgericht Programmeren : Deel 3 Project Objectgericht Programmeren : Deel 3 Prof. Eric Steegmans Raoul Strackx Academiejaar 2010-2011 Deze tekst beschrijft het derde deel van de opgave voor het project van de cursus Objectgericht Programmeren.

Nadere informatie

Chris de Kok 223548 TDI 3. Vak: Software Architectuur Datum: 21-01-2008 Docent: Fons van Kesteren

Chris de Kok 223548 TDI 3. Vak: Software Architectuur Datum: 21-01-2008 Docent: Fons van Kesteren Chris de Kok 223548 TDI 3 Vak: Software Architectuur Datum: 21-01-2008 Docent: Fons van Kesteren Inhoud Inleiding... 3 Black box / White box... 3 XP... 3 SimpleTest... 3 Eclipse plugin... 4 GroupTest...

Nadere informatie