Examenvragen theoriegedeelte Software Engineering ( )

Maat: px
Weergave met pagina beginnen:

Download "Examenvragen theoriegedeelte Software Engineering (2007-08)"

Transcriptie

1 Examenvragen theoriegedeelte Software Engineering ( ) 07/06/ W.S. - 3ELICTI 1. Wat is software engineering? Teken en leg uit: klassieke levenscyclus, prototyping en spiraalmodel. Software engineering: Het instellen en gebruiken van gezonde ingenieursprincipes om economisch verantwoorde software te verkrijgen dat betrouwbaar is en efficiënt werkt op reële machines. Het bouwen van complexe maar betrouwbare software tot informatiesystemen. Het is een wetenschappelijk veld dat zich bezighoudt met methodes en werkwijzen om een vraag of probleem in de werkelijkheid om te zetten naar een computerprogramma. Ook tracht men te komen tot een optimaliserend proces voor het ontwikkelen, implementeren, testen en onderhouden van software. Klassieke levenscyclus (Fasen die de software doorloopt): Specificatie analyse & ontwerp (modellering) implementatie test onderhoud Watervalmodel: 1. Analyse (onderzoek en overleg over de vereisten en specificaties voor de software) 2. Ontwerp (gedetailleerde uitwerking van de structuur en de werking van de toekomstige software met behulp van bv. UML) 3. Implementatie (programmeren) 4. Test (uittesten van functionaliteiten en performantie en dergelijke voor de software naar de gebruiker gaat) 5. Onderhoud (na het in productie nemen van het eindproduct) Dit model biedt het voordeel van goed afgelijnde fasen zodat men (management & klanten) een mooi overzicht heeft. Er wordt wel vanuit gegaan dat de eisen van de klant niet wijzigen. Om dit nadeel tegen te gaan kan men werken met terugkoppelingen tussen fasen, of fasen kunnen elkaar overlappen.

2 Prototype: Bij protoyping wordt er een vroegtijdige versie van de software aangemaakt voor demonstratie. Na het analyseren van de vereisten maakt men een snel design en bouwt men het prototype. De klant kan dit evalueren waarna men de vereisten kan aanpassen en/of bijstellen. Vanaf dan kan men verder werken naar een volwaardig programma. Er bestaan verschillende prototypes Throwaway (helpt vereisten te begrijpen en/of bij te stellen maar kan niet evolueren naar leverbaar systeem) Quick and Dirty (snelle versie van een systeem dat later tot iets aanvaardbaar evolueert, tijdelijke dingen mogen niet permanent worden) Detail Design-Driven (preproductiemodel, evolutie aan de hand van tests en wegwerken van ontdekte fouten) Non-functioning Mock-ups (lege doos, enkel visueel, biedt geen interactie en dus functionele eisen kunnen niet getest worden) Evolutionary Rapid Prototyping (eenvoudig aanpasbaar/uitbreidbaar model van een systeem, tonen van sleutelelementen voor implementatiefase, ontdekken van functionele eisen, rekening houdend met budget, evolueert naar leverbaar systeem) Met dit systeem heeft men een betere interactie met de klant, eisen kunnen bijgesteld worden. Het is makkelijker om onvolmaaktheden te ontdekken, zo kan men fouten vroeger elimineren. Dit spaart tijd & geld. Het gevaar is wel dat men door het prototype te maken te weinig tijd besteedt aan analyse. Er bestaan ook een kans dat het prototype te weinig evolueert en een eindproduct van lage kwaliteit voortbrengt. Prototypes kunnen ook te ver evolueren terwijl men beter opnieuw was begonnen. Het maken van een prototype kan ten slotte (te) veel tijd kosten.

3 Spiraalmodel: Een voorbeeld van een iteratieve levenscyclus is het spiraalmodel. Het project wordt opgedeeld in deelprojecten. Indien de uitwerking van een deelproject niet voldoet wordt dit deel opnieuw gedaan tot men een bevredigend resultaat krijgt. Het spiraalmodel is eigenlijk een metamodel, het kan andere modellen bevatten. Er zijn vier fasen die herhaald worden: planning risicoanalyse engineering (ontwikkeling) evaluatie. Risicoanalyse bekijkt het grootste probleem best eerst, en men beslist of het een go of een no-go is. 2. Welke fasen kan men bij projectmanagement onderscheiden? Bespreek deze kort. 5 fasen: Initiatiefase planningsfase uitvoeringsfase controlefase afsluitfase

4 Fase 1: Initiatiefase Uitvoering project accepteren (genoeg kennis, mensen & tijd? Hoogste prioriteit? Noodzakelijkheid? Doenbaarheid: genoeg tijd, budget, techniek? Risico s?) Doelen van project definiëren (tijd- of kostenbesparing voor de klant & winst voor de onderneming, verwachte winsten en resultaten beschrijven, nadenken of de mensen het product wel zullen willen gebruiken) Algemene verwachtingen definiëren (van klanten & van management) (specifieke, meetbare & realistische doelstellingen, realistische einddatum, overeenstemming, verantwoordelijkheden voor bereikte doelen) Scope van project inschatten (risico s en beperkingen van economie, technologie, politiek, wetten en structuren, weer, werken aan elektriciteit, failliet leverancier, staking, reorganisatie van het bedrijf, budget, mensen) Initiële teamleden selecteren (bouwen van een team met verschillende persoonlijkheden, kennis en vaardigheden; weinig experts of veel mensen met basiskennis; hoeveelheid supervisie) Fase 2: Planning Opsplitsen project in beheersbare taken (logische volgorde, interferentie, beoordeling & controle, vereiste kennis & aantal mensen) Definiëren van de taken (duidelijk & gedetailleerd zodat er geen verwarring mogelijk is, één geheel, ook in tijd, moet in schema gevoegd kunnen worden, moet gemeten kunnen worden, bepalen van nodige middelen zoals tijd & mensen) Verfijnen scope project (evenwicht tussen resultaten, tijd & middelen) Opstellen takenlijst om doel te bereiken Bepalen van efficiëntste taaksequentie Maken van rooster en toekennen van middelen aan taken Plan laten goedkeuren Mijlpalen (onderverdelen van project in subprojecten, belangrijke verzamelingen van taken) Netwerkdiagramma s (tonen van sequenties en relaties tussen taken, identificeren van mijlpalen, grafische voorstelling van de takenlijst) Scheduling (schatten van de tijd voor elke taak door de taakverantwoordelijke te ondervragen, door objectieve expert te ondervragen, door te vergelijken met een taak in een voorgaand project, door zelf uit te testen, door inschatting met Lines Of Code / Function Points / CoCoMo II

5 Fase 3: Uitvoering Start: Projectbijeenkomst (doel meedelen aan teamleden, meedelen van ieders objectieven en verantwoordelijkheden, motiveren, duidelijk maken wie de leider is, identificeren van deadlines en fasen, uitleggen van procedures voor rapportering, vergaderingen e.d., expliciet de leden verantwoordelijkheden geven voor de initiële taken) Leiden van team (luisteren naar teamleden, veel vragen stellen, observeren wat er gebeurt, genoeg weten om te weten dat je niet alles weet, beschikbaar zijn als mensen je nodig hebben, beslissingen nemen als men er om vraagt, zoveel mogelijk werk delegeren, werk managen is niet gelijk aan het werk doen, niet overmanagen: jij doet het project en de leden doen hun eigen werk dat hen is toebedeeld) Vergaderen met teamleden (regelmatige groepsvergaderingen, kort en to-the-point, niet aflassen, eventueel individuele gesprekken, alles is bespreekbaar, feedback over projectstatus, grote feestjes enkel voor belangrijke mijlpalen, zo weinig mogelijk geschreven boodschappen, indien toch nodig kort en to-the-point, zorgen dat de boodschap duidelijk is qua woordenschat, toon & stijl, nadenken over het effect van de boodschap, nagaan of de boodschap is aangekomen, opletten dat de boodschap niet in andere handen terecht komt). Communiceren met management en klanten (rapportering e.a.) Oplossen van problemen & conflicten Zorgen voor voldoende middelen Fase 4: Controle Kijken of er geen afwijkingen zijn tegenover het plan Corrigeren van plan Behandelen van aanvragen voor projectwijzigingen Herschikken indien nodig Aanpassen van de middelen indien nodig Eventueel terug naar planning Succescriteria voor monitoring: vergelijking van projectverloop met plan, plan aanpassen om project in goede banen te leiden, aanpassingen pas doorvoeren als deze toepasselijk en goedgekeurd zijn, documenteren van vooruitgang en wijzigingen, betrokken zijn in het project. Conflicten oplossen (misverstanden over verwachte resultaten of volgorde van taken, taken niet specifiek genoeg, administratieve procedures voor vorm en aantal van rapporten en voor verspreiding van geheime informatie, teamleden weten niet goed wat ze moeten doen, technische onzekerheid, verdeling van saaie en minder saaie taken, verdeling van het budget, tijdsgebrek, persoonlijke conflicten)

6 Fase 5: Afsluiten Wat bereikt? Ontmantelen van het team Opgedane ervaring Bespreken van projectverloop en resultaten met teamleden & management Schrijven van een rapport 3. Wat zijn de gouden regels voor een projectleider? 12 Gouden regels 1. Zoeken naar consensus voor projectresultaten (duidelijke doelstellingen, consensus met management, team & de klant) 2. Zoeken naar beste team (qua motivatie & kennis, mensen motiveren en het werk verdelen ook als de ervaring tekort schiet of als er problemen zijn) 3. Ontwikkelen van een goed plan en dit up-to-date houden (compleet en gedetailleerd, toepasselijk) 4. Bepalen van de noodzaak aan middelen voor het project (echte noodzaak? Als middelen niet beschikbaar zijn onderhandelen wat zal uitgevoerd worden) 5. Een realistisch schema opstellen (gebrek aan tijd) 6. Niet meer proberen doen dan mogelijk/nodig (wat gedaan moet worden moet duidelijk zijn voor iedereen) 7. Onthouden dat het succes van het project sterk afhankelijk is van de menselijkheid van de teamleden (zaken worden niet altijd duidelijk overgebracht, ieder heeft zijn gebreken, tolerant zijn en constructieve kritiek geven) 8. Formele en blijvende ondersteuning van het management winnen (nood aan communicatieve- en onderhandelingsvaardigheden) 9. Bereid zijn om aanpassingen door te voeren (bij computerpanne, waterschade, nieuwe informatie, tool of technologie, verandering van de eisen van de klant) 10. Mensen goed informeren (uitleggen wat je zelf aan het doen bent aan het project) If they know nothing of what you are doing, they suspect you are doing nothing (Graham's Law) 11. Bereid zijn om nieuwe zaken uit te proberen (ieder project is verschillend, niet te star vasthouden aan de werkwijze van een voorgaand gelijkaardig project) 12. Word een leider (plannen, opvolgen, controleren, ondersteunen & lid van het team zijn, en zo aanvaard worden als leider)

7 4. Wat zijn taken en hoe kaderen zij zich binnen een project? Een taak is een klein, gedetailleerd, duidelijk afgelijnd deel van een project. Het vormt één geheel, is meetbaar, vereist specifieke mensen & middelen, en past in het schema. Meerdere taken identificeren zich in een logische volgorde. Ze kunnen eventueel gerelateerd zijn aan elkaar. Status van een taak is to do, in behandeling of afgewerkt. Het is aan te raden om een geheel aan taken die behoren tot een bepaalde fase van het project af te sluiten met een mijlpaal. Het is mogelijk en aan te raden om een grafische voorstelling te maken van de sequentie van taken zoals bijvoorbeeld een netwerkdiagram. 5. Welke conflicten kunnen tijdens het verloop van het project opduiken? Niet achter hetzelfde doel staan (misverstanden van verwachte resultaten, niet aanvaarden van volgorde van de taken) Taakbeschrijving is niet specifiek genoeg Administratieve procedures (aantal & vorm van rapporten, verspreiding van geheime informatie) Teamleden weten niet goed wat ze moeten doen Technische onzekerheid (ontwikkeling nieuwe technologie) Verdeling van saaie en minder saaie taken Oneerlijke verdeling van het budget Tijdsgebrek bij het volbrengen van een taak Persoonlijke conflicten Floating start date: geen of late start (werk delegeren en iemand anders laten starten) Nooit tijd genoeg voor alles (delegeren, schrappen wat niet echt nodig is, leren neen zeggen tegen bijkomende taken, prioriteiten aanpassen taken later uitvoeren, beter dan taken niet uitvoeren) Teveel rapporten en te weinig communicatie (noodzakelijkheid van rapporten, op regelmatige tijdstippen met iedereen praten, informele bijeenkomsten zoals lunchen voor een meer open en eerlijke communicatie, deur openhouden) Product liever gisteren dan vandaag (?) 90% gedaan syndroom (?) (technische problemen, creatieve taken, wegmoffelen van achterstand) Verandering in doelen (eerst analyseren en impact nagaan voor veranderingen door te voeren)

8 Sleutelpersoon stapt op (tevreden houden, meerdere personen betrokken bij zelfde taak) Te hoge kosten (slechte schatting, vertragingen laten loonkosten oplopen, onvoorziene technische problemen, veranderingen) Meer enthousiasme dan talent (niet in groep, bijkomende training, consultant) Het onmogelijke blijft onmogelijk 6. Dynamisch gedrag kan men modelleren met interactie-, toestands- en activiteitendiagrammen. Wanneer gaat men wat gebruiken? Geef een voorbeeld van elk. Dynamisch model: beschrijft het gedrag. Statisch model: beschrijft de structuur, de opbouw (klassen, bestanden). Functioneel model: beschrijft de functie (relatie tussen inputs en outputs) Interactiediagrammen: beschrijven hoe groepen van objecten samenwerken (interageren), meestal gedrag van één use case, diagram bevat een aantal voorbeeldobjecten & de boodschappen verstuurd door deze objecten binnen de beschouwde use case, het gedrag van meerdere use cases is geen interactiediagram maar een activiteitendiagram, twee veel gebruikte interactiediagrammen zijn het sequentiediagram en het communicatiediagram (of collaboratiediagram), twee minder gebruikte zijn het interaction overview en het timingdiagram. Sequentiediagram: focus op sequentie van boodschappen, volgorde van boodschappen verstuurd en ontvangen door objecten, verticale as stelt de tijd voor, horizontale as zijn de objecten die meespelen, als boodschap ontvangen is wordt een activiteit gestart in het object, dit is een rechthoek op de verticale lijn, conditie op boodschap met rechte haken [ ], objecten creëren vanaf boodschap, vernietigen met X en geen verdere levenslijn tekenen

9 Communicatie (collaboratie) diagram: meer ruimtelijk tonen van relaties, objecten en links zoals klassediagram, op de link staat een boodschap met eenvoudig decimaal sequentienummer Interaction overview: overzicht van control flow, interacties weergeven via een variant van activiteitendiagram, knoppen (initial, final, decision, merge, fork, join) vertegenwoordigen interactiediagrammen zoals sequence, communication, interaction overview of timing diagrams, interaction occurences & interaction elements ref. naar bestaande interactiediagrammen analoog, maar tonen van inhoud diagram

10 Timing diagram: redeneren over tijd, tijdstip van gebeurtenissen & wijzigen van condities Toestandsdiagrammen (oftewel state machines): veel gebruikte techniek om het gedrag van een systeem te beschrijven, het OOmodel wordt gebruikt voor één klasse, voor het gedrag van één object, niet voor interactie te beschrijven, toestandsdiagrammen beschrijven alle mogelijke toestanden van één object, en de overgangen tussen toestanden door gebeurtenissen, enkel te tekenen als een klasse een interessant of complex gedrag heeft, vooral gebruikt bij UI- of controleobjecten. Een toestand in een State Machine is afgebeeld als een afgeronde rechthoek, een transitie is een pijl tussen twee toestanden, een toestandsdiagram heeft één startpunt en kan meerdere eindpunten hebben.

11 Een toestand kan drie compartimenten hebben: een naam, toestandsvariabelen (attributen klasse) & activiteiten (entry, exit en do-activiteiten) Op een transitie kan een guard-conditie staan, transitie(-actie) wordt uitgevoerd als de voorwaarde true is. Syntax: Event [Guard] / Action. Een actie is geassocieerd met een transitie, een activiteit hoort bij een toestand. Een activiteit kan onderbroken worden door een gebeurtenis. Een history state kan gebruikt worden om een toestand te onthouden.

12 Activiteitendiagrammen: voor het modelleren van de workflow over verschillende use cases (interactie tussen de use cases), voor het analyseren van een use case, welke acties er moeten plaatsgrijpen en wat de gedragsafhankelijkheden zijn, behandelen van multi-threaded toepassingen, werk uit te voeren in een operatie/methode, de verbinding tussen acties en objecten is niet erg duidelijk. Activiteitendiagrammen zijn niet geschikt voor samenwerking tussen objecten (interactiediagram) of om het gedrag van een object (toestandsdiagram) duidelijk te maken. Een activiteitendiagram is een variant op het toestandsdiagram: toestanden zijn actietoestanden, transitie gebeurt als actie uitgevoerd is, er zijn geen events, swimlanes groeperen activiteiten op locatie of verantwoordelijkheid. Een activiteitendiagram begint met een startnode, en eindigt met een eindnode, actietoestanden zijn rechthoeken met afgeronde hoeken, transities zijn de verbindingen tussen de actietoestanden, ze vinden plaats als via guard condities, parallellisme is mogelijk door de fork en join nodes. De objecten die gebruikt worden in een activiteitendiagram zijn input naar of output van een activiteit, objecten die beïnvloed worden door een activiteit, rechthoeken met object of klassenaam, gestreepte I/O pijlen. 7. Waarmee moet men rekening houden bij het ontwerp van een User Interface? Programmeurs zijn meestal goed in softwaretechnieken maar de User Interface is vaak niet echt aantrekkelijk of geschikt voor de doelgebruikers. De UI is van groot belang voor het af- of goedkeuren van het product door de gebruiker. Een User Interface moet gemakkelijk om te leren zijn, eenvoudig om te gebruiken, logisch zijn qua opbouw en werking en moet vergevingsgezind zijn (niet blokkeren bij een verkeerde toetsencombinatie of volgorde van clicks). Een User Interface moet de dialoog vormen tussen de mens en de machine, waarbij de mensen (gebruikers) kunnen verschillen van elkaar op vlak van kennis (specialist beginneling), persoonlijkheid (nemen van risico s & motivatie), cultuur, links- of rechtshandig of eventueel mindervaliden. Gebruikers kunnen zich onderscheiden op vlak van semantische (over de betekenis) en syntactische kennis (over de opbouw): nieuwelingen, minder frequente gebruikers (moeilijk om syntactische kennis terug op te bouwen) & frequente gebruikers (gebruik van short cuts en snelste manier van werken). Een interface gebruiksvriendelijk maken is niet eenvoudig, met moet de gebruikers kunnen inschatten.

13 Ontwerpprincipes: User familiarity: termen en concepten uit de ervaringen van de belangrijkste gebruikers Consistency: vergelijkbare operaties op dezelfde manier activeren Minimal surprise: gebruiker nooit verrassen Recoverability: mechanisme voorzien om fouten te herstellen (Undo) User guidance: betekenisvolle feedback bij fout en context-sensitive help User diversity: verschillende interactiemogelijkheden voorzien Ontwerp kwesties Systeem antwoord: zorgen dat de antwoordtijd van een systeem niet te lang (frustratie) of te kort is (tijd nodig om verandering te zien) en zorgen dat alles ongeveer even lang duurt. Foutboodschappen: duidelijk, constructieve raad, melden van mogelijke gevolgen, aandacht trekken (auditief en/of visueel), gebruiker niet beschuldigen, niet te frequent Help: uitleg over huidige opdracht of I/O waarde, online manuals, help voor alle mogelijke functies? Help menu/functietoets/helpcommando? Korte uitleg op vaste plaats of nieuw venster? Hoe help info verbergen? Structuur? Intelligente help? Getoonde informatie: relevant, beste vorm (grafiek i.p.v. tabel), consistent, duidelijke opbouw van tekst, verschillende vensters voor verschillende informatie User input: beperken van aantal inputs, beperken van typen (selecteren met muis, glijden over schaal), consistentie tussen informatie & gegevensinput, flexibele interactie (verschillende mogelijkheden waaruit de gebruiker kan kiezen), keuzes aan de gebruiker overlaten (niet één enkele sequentie opdringen), oudere studies (deactiveren van commando s die niet toepasselijk zijn) nieuwere studies (controle overlaten aan gebruikers), help voorzien voor commando s en inputwaarden, standaard inputeenheden instellen plus de mogelijkheid geven om de eenheid te veranderen, verschillende inputwaarden toelaten en eventueel automatische conversie implementeren (geheel naar kommagetal), defaultwaarden voorzien (inputwaarden & default knoppen zoals bv. Cancel), niets opvragen wat automatisch verworven kan worden, commando s voorzien (voor oudere, frequente computergebruikers (voor elke menu-optie? Vorm? Verschillende commando s opzoeken? Gebruiker zelf commando s laten definiëren?) Standaardisatie (bv. Menu File: New, Open & Save) Mogelijkheid tot personalisatie van de interface Efficiëntie

14 8. Geef 15 puntjes over het schrijven van ononderhoudbare code. Goede programmacode is geschreven met het oog op verstaanbaarheid, herbruikbaarheid, uitbreidbaarheid & robuustheid. Hieronder tips om deze zaken tegen te werken. 1. Maak dat in de commentaar uitleg staat die fout of niet up-to-date is. 2. Maak geen ontwerp, begin direct aan het schrijven van code. Een ontwerp maken is voor feilbare mensen. 3. Zorg dat iedere methode net iets meer of minder doet dan beschreven in de naam. 4. Gebruik zelf uitgevonden afkortingen om de code compacter te maken 5. Probeer zoveel mogelijk te schrijven op één enkele lijn 6. Gebruik voor variabelen ongewone afkortingen en schrijf ze af en toe op een verschillende manier en schrijf ze af en toe ook eens voluit. Zo bekom je verschillende variabelen of methoden voor ongeveer hetzelfde doel, de onderhoudende programmeur zal nauwelijks merken dat het verschillende methoden/variabelen zijn! 7. Laat de automatische code opmaker niet bepalen hoe je code uitgelijnd is! Doe de uitlijning manueel zodat je lussen en bodies net iets langer of korter lijken dan ze effectief zijn. 8. Gebruik enkel accolades {} bij if/else als het syntactisch verplicht is. Samen met het verkeerd inspringen van regels kan je zelf een expert onderhoudsprogrammeur misleiden. 9. Gebruik voor de benaming van variabelen, klassen en methoden zeer lange woorden die slechts één karakter verschillen van een andere, dit kan eventueel een hoofdletter zijn of letters & cijfers die zeer goed op elkaar lijken (1-i-l of O-o-0) 10. Volg de conventies in Java zeker niet wat betreft hoofdletters voor klassen (DoublePoint), variabelen (verylongstring) & constanten (MAX_INT). Sun doet dat trouwens ook niet (bv. Instanceof, isinstanceof en Hashtable) 11. Gebruik nooit i als lusvariabelen, gebruik gelijk welke andere benaming. Gebruik i voor elke benaming van een niet-int variabele. Gebruik bijvoorbeeld n voor de lusvariabele. 12. Gebruik nooit locale variabelen. Indien er toch één nodig is deel dan deze variabele met iedere andere methode door ze bijvoorbeeld static te maken 13. Als je vermoed dat er een fout in een klasse zit, of je hebt een vermoeden hoe ze beter zou georganiseerd of geschreven worden, schrijf dit zeker niet bij je klasse als commentaar! Stel dat de programmeur die de code geschreven heeft dit zou zien, of de eigenaar van het bedrijf, of de klant Je zou ontslagen kunnen worden. 14. Gebruik zoveel mogelijk synoniemen (print, present, show & display) voor methoden die exact hetzelfde doen, geef wel een hint dat er een klein verschil is. Geef dan wel dezelfde benaming voor gelijkaardige methoden die een cruciaal verschil hebben (methode print voor het schijven naar scherm & voor het schrijven naar een bestand)

15 15. Voor de benaming in methodes en commentaar gebruik zoveel mogelijk abstracte benamingen (it, everything, data, handle, stuff, do, routine, perform, digits, bv. routinex48, PerformDataFunction, DoIt, HandleStuff and do_args_method. 16. In Java worden primitieve parameters doorgegeven by-value, objecten worden daarentegen doorgegeven by-reference (de referentie naar het object wordt by-value doorgegeven, dus het object kunnen we lezen en aanpassen). Benoem je methoden zo dat het lijkt dat een object enkel wordt gelezen, terwijl het eigenlijk aangepast wordt 17. Maakt nooit duidelijk in welke eenheid je variabelen zijn (meter, liter, eenheden, ) of verzin een eenheid en noem hem naar jezelf. 18. Goed geschreven code faalt nooit, verspil je tijd dus niet aan exceptions. Schrijf beter één enkele try/catch voor de volledige klasse die System.exit() oproept. 19. Maakt regelmatig verbeteringen in je programma en verplicht gebruikers om up te daten. Iedereen zal blijer zijn met een gefixt programma. Vertel niet welke verbeteringen zijn gemaakt door de update, waarom zou je trouwens bugs vermelden als de gebruikers deze misschien niet gemerkt hebben. 20. Laat de naam van de variabele zo weinig mogelijk lijken op het label dat je gebruikte op het scherm (bv. Sla Postal Code op in de variabele zip) 21. Java maakt het mogelijk methoden aan te maken met dezelfde naam als de klasse zonder dat deze methoden constructoren zijn. Buit deze verwarring uit. 22. Maak zoveel mogelijk variabelen static. Als jij maar één instance van het programma nodig hebt, zal ook niemand anders die nodig hebben. Als andere programmeurs in het project zouden klagen, vertel hem hoeveel sneller je code werkt. 23. Laat alle oude methoden en variabelen staan, om makkelijk terug te kunnen gaan naar de vroegere werking van de code. Voorzie ze ook van voldoende raadselachtige code zodat andere programmeurs te veel twijfelen om ze te verwijderen. 24. Zet bij een methode als enige commentaar de naam van de methode. (/* make universal*/ bij makeuniversal( ). Leg zeker niet uit wat Universal betekent. 25. Verander af en toe de parameters van volgorde bij een methode (hoogte & breedte). 26. In plaats van parameters te gebruiken voor een methode, maak zoveel mogelijk verschillende methoden aan (setleftalignment() & setrightalignment() i.p.v. setalignment(char c)). 27. Maak iedere variabele en methode public, iedereen zou ze toch misschien willen gebruiken. Als de baas klaagt, vertel hem dat je de basisprincipes van transparante interfaces volgt. 28. Als je methodes overload, zorg dan dat de methode verschillende zaken doet naargelang de vorm van de parameters. 29. Gebruik voor een bestandsnaam file of bestand. Gebruik voor andere benamingen zoveel mogelijk gereserveerde woorden zoals class, const, constant, input, key,

16 keyword, kind, output, parameter, parm, system, type, value, var en variable. Als de gebruikers hopeloos verward zijn kan jij zeggen dat je de naamgeving zo koos om het doel van iedere variabele duidelijk te maken. 30. Maak gebruik van exceptions wanneer die niet echt nodig zijn. Gebruik bijvoorbeeld altijd een ArrayIndexOutOfBoundsException om een lus te beëindigen. 31. Controleer nooit op de juistheid van input data. Toon 100% vertrouwen. 32. Als je baas denkt dat zijn Fortran ervaring zeer goed kan helpen bij hedendaags programmeren, volg dan zonder twijfel al zijn richtlijnen. Zo kweek je vertrouwen. 33. Steek af en toe octale waarden tussen decimalen door een O te plaatsen voor de octale waarde: {111,120,O13,121} 34. Voeg veel third-party libraries toe zonder deze te gebruiken, vermijd altijd de goede, standaard tools. 35. Gebruik Extended ASCII karakters in namen van variabelen, deze zijn bijna onmogelijk te typen (meestal enkel te bekomen door copy-paste). 9. Bespreek Black Box testen, illustreer met een voorbeeld. Black Box static testing: review van requirements of specificaties. Het Black Box testen ziet een programma als een zwarte doos. De invoer is een juiste invoer binnen acceptabele tijd en de interne werking van het programma bekijkt men niet. Men controleert of het programma voldoet aan de specificaties. Het is onmogelijk om alle mogelijke inputwaaden & combinaties te testen. Het doel is om zo veel mogelijk fouten te vinden met een minimum aan tests. Methoden die gebruikt worden: Equivalence partitioning (reduceren van aantal tests zodat alle mogelijke scenario s gecovered worden, hoofdzakelijk toegepast op de verschillende inputs, bereik verdelen in partities met geldige en ongeldige partities, één test per partitie uitvoeren want de waarden in een partitie zijn equivalent, gemakkelijk toepasbaar op getallen, karaktercodes, aantal uitvoeringen, grootte van een som van getallen, lengte van een getal, string, samengevoegde string of bestandsnaam, grootte van file, beschikbaar geheugen, snelheid van invoeren gegevens, aantal aangesloten apparaten, datums & tijd) Boundary value analysis (bepalen van test cases die de grenzen van inputbereiken testen, een teller kan net te ver of net niet ver genoeg tellen, bij gebruik van < of <=, zoeken van grenzen door Equivalence partitioning, steeds een clean & dirty test case, bij clean zou men een geldig resultaat van het programma moeten krijgen, bij dirty een correcte en gespecifieerde foutafhandelijk, fouten bij waarden die niet in de buurt van de grens liggen worden niet gedetecteerd

17 Combination testing (samenhang van variabelen testen, cause-effect graphing zoekt naar de oorzaken en gevolgen van alle invoervariabelen, men bouwt een gerichte graaf door na te gaan van welke inputs samen tot een bepaald gevolg leiden, deze methode is moeilijk toepasbaar in huidige applicaties door te veel samenhang van inputs, bij een andere methode genaamd combinatorial design test men alle mogelijke combinaties uit) All-pair testing (bij elk paar van inputvariabelen worden alle combinaties getest) Error Guessing (testcases die fouten zullen geven gokken op basis van ervaring/intuïtie, speciale gevallen die vaak over het hoofd worden gezien en fouten uit vorige projecten) Fuzz testing (random input data, moeilijk op te lossen fouten als data verschillende fouten tegelijk triggert, moeilijk om te reproduceren, eenvoudige test) Model-based testing (testcases afgeleid van het model dat sommige aspecten van het te testen systeem beschrijft, wordt gezien als black box testing aangezien de testcases niet uitgaan van de code maar van het model, niet toepasbaar op complexe software systemen) Het tegengestelde van Black Box testing is White Box testing. Bij White Box testing bekijkt men de code om zo verschillende testcases te bekomen. 10. Bespreek kort het Unified Process en Extreme Programming Unified Software Development Process is een populair iteratief proces voor softwareontwikkeling. De levenscyclus van het proces bestaat uit een aantal cycli, waarbij elke cyclus een nieuwe release van het product naar de klant produceert (een nieuwe executable) [Use-case driven, architecture centric, iterative and incremental] Use case driven (ontwikkelaars moeten nagaan of alle opeenvolgende modellen conform de use cases zijn, bij de implementatie moet men steeds de gevraagde functionaliteit in het achterhoofd hebben, testers moeten de implementatie testen om zeker te zijn dat de use case correct geïmplementeerd zijn en dat het systeem dus voldoet aan de eisen van de klant) Architecture-centric (opbouw van het systeem, onderscheid tussen verschillende onderdelen, de relaties en interacties ertussen; het systeem moet logisch verdeeld zijn in subsystemen waarbij de afhankelijkheden tussen deze subsystemen eenvoudig en beperkt zijn, groeit uit de noden gereflecteerd in use cases, beïnvloed door platform, aanwezige hebruikbare delen zoals GUI & niet functionele eisen zoals performantie en betrouwbaarheid)

18 Iteratief & incrementeel (iteratie = aantal stappen in workflow selecteren en uitvoeren, increment = groei van product, in de iteratie pakt men een groep use cases aan die samen het product zoals het dan is uitbreidt en behandelt. Vroege iteraties moeten de grote problemen aanpakken en niet uitstellen, vroege iteraties mogen ook prototypes zijn die eventueel worden weggegooid, een mini-project doet uitbreidingen vanaf de use cases analyse, ontwerp, implementatie & test, met increment bedoelt men het toevoegen van extra functionaliteit, dit kan in het model of document zijn en is niet noodzakelijk additief, vervangingen zijn ook mogelijk zoals bijvoorbeeld een eenvoudig algoritme dat vervangen wordt door een meer complex algoritme) Levenscyclus van het proces bestaat uit een aantal cycli, elke cyclus produceert een nieuwe release van product naar de klant (een nieuwe executable). Elke cyclus bestaat uit 4 opeenvolgende fasen : inception fase (aanvang, plannen) - elaboration fase (uitvoerige behandeling, ontwerpen) - construction fase (bouw) - transition fase (overgang, overbrengen naar gebruikers - bèta). Elke fase bestaat uit een aantal iteraties, elke fase wordt beëindigd met een wel-gedefinieerde mijlpaal (beschikbaarheid van aantal artifacten, controle vooruitgang). extreme Programming (XP) (alle projectmedewerkers verstaan ten gronde wat gebruikers willen, ontwikkel software incrementeel, herbekijk de eisen na elke kleine stap, lever kleine incrementele componenten elke 3 weken, bewijs dat zonder defecten, herbekijk alle vragen van klant elke 3 weken). Common Sense to the Extreme (iedereen ontwerpt elke dag, altijd het eenvoudigste kiezen, code steeds herzien, altijd testen, ontwerp en verfijn steeds de architectuur, nieuwe code elke dag integreren en testen, elke dag afleveren) Eisen: klant moet altijd beschikbaar zijn voor vragen en evaluatie, pair programming (schrijver van code + iemand die naleest), code van iedereen (iedereen mag wijzigen), elke dag een half uur om samen het werk te verdelen, teamgrootte van 6 (max. 12), projectlengte van 6 à 9 maand. Nadelen: planning max. 3 weken vooruit, dus zeer moeilijk (onmogelijk) om kosten in te schatten, structuur van kleine blokjes, maar is er nog voldoende structuur in het geheel, vereist constante beschikbaarheid van de klant. 11. Hoe ga je de kwaliteit van software beoordelen? Bespreek ook kort Capability Maturity Model en ISO Software kwaliteit : expliciet vermelde functionele en perfomantie-vereisten (eisen van de klant), expliciet gedocumenteerde ontwikkelingsstandaarden (volgen van ontwerp/model), en impliciete karakteristieken die van alle professioneel ontwikkelde software wordt verwacht (bv. onderhoudbaarheid). Correctheid (specificaties = functionaliteit) Betrouwbaarheid (functionaliteit = verwachtingen van de gebruiker) Robuustheid (onwaarschijnlijkheid voor een crash of fail)

19 Performantie (response time e.a. binnen vooropgestelde doelen) Bruikbaarheid (gebruiksvriendelijk bv. beantwoorden aan standaarden) Verstaanbaarheid (van interne structuur & gedrag voor onderhoudbaarheid) Onderhoudbaarheid (corrigeerbaar, eenvoudig om nieuwe vereisten te implementeren) Schaalbaarheid (uitbreidbaar als er een duidelijke architectuur is) Verstaanbaarheid + onderhoudbaarheid + schaalbaarheid = supportability Herbruikbaarheid (van componenten/functionaliteit) Overdraagbaarheid (op verschillende platformen met kleine of zonder aanpassingen) (Interoperability : samenleven met andere software, open software) Processkwaliteit o o o Productiviteit (efficiëntie & performantie van proces) (Stiptheid of timeliness: on-time-to-market) Zichtbaarheid (transparant process : duidelijik gedefinieerde en gedocumenteerde stappen en activiteiten) Hoe kan dit gemeten worden? Auditability (eenvoud om gechecked te worden als conform standaards is) Accuracy (precisie van berekeningen & controle) Communication commonality (gebruik van standaard interfaces, protocollen & bandbreedtes) Conciseness (compactheid in aantal lijnen code) Consistency (gebruik van uniforme ontwikkelings- en documentatietechnieken) Data communality (standaard datastructuren & -types) Error tolerance (schade indien programma een fout tegenkomt) Execution efficiency (runtime performantie) Generality (breedte van mogelijke toepassingen van programmacomponenten) Hardware independence (werking onafhankelijk van gebruikte hardware) Instrumentation (programma houdt zichzelf in de gaten en identificeert fouten) Modularity (functionele onafhankelijheid van programmacomponenten)

20 Operability (gebruiksgemak) Security (mogelijkheid tot controle en beveiliging van data) Self-documentation (leveren van betekenisvolle documentatie uit source code) Simplicity (verstaanbaarheid & eenvoud) Software system independence (onafhankelijkheid van niet-standaard kenmerken van programmeertaal, karakteristieken van besturingssysteem & andere omgevingsbeperkingen) Traceability (verband tussen programmacomponenten en requirements) Training (hulp voor nieuwe gebruikers) Capability Maturity Model: model dat de mogelijkheid levert om de softwareprocescapaciteit van een onderneming te meten, zet doelen en prioriteiten voor procesverbetering, helpt om acties te plannen, geeft een methode om procesmanagement en kwaliteitsverbeteringsconcepten toe te passen op softwareontwikkeling en -onderhoud en leidt een organisatie naar software engineering excellence. Karakteristieken van een onvolwassen proces (immaturity) Ad hoc: geïmproviseerd proces door ontwikkelaars en hun management Niet nauwgezet gevolgd en afgedwongen Zwaar afhankelijk van huidige ontwikkelaars Moeilijk om productkwaliteit te voorspellen Grote kans op kost- en planningsproblemen door minder goede schattingen Verminderen van productfunctionaliteit en kwaliteit ten voordele van halen planning Gebruik van nieuwe technologie zeer risicovol Karakteristieken van een volwassen proces Gedefinieerd en gedocumenteerd (verstaan, gebruikt, levend) Zichtbaar ondersteund door management Rollen en verantwoordelijkheden goed gedefinieerd en verstaan Trouwheid aan proces wordt nagekeken en afgedwongen Consistent met manier van werken Gemeten Ondersteund door technologie

21 Evolutie tussen verschillende niveaus van rijpheid 1. Initieel: processen zijn ad hoc en chaotisch 2. Herhaalbaar: er is een basis projectmanagementproces voor het volgen van cost planning en functionaliteit. Er is procesdiscipline om vroegere successen te herhalen. 3. Gedefinieerd: softwareproces voor management en engineering is gestandaardiseerd, gedocumenteerd en geïntegreerd binnen een organisatie-wijd proces. 4. Gemanaged: softwareproces en productkwaliteit worden gedetailleerd gemeten en gecontroleerd. 5. Optimaliserend: continue procesverbetering voor kwantitatieve feedback van proces en door testen van nieuwe ideeën en technologiën. Sleutelprocessen niveau 5 (process change management, technology change management, defect prevention) niveau 4 (software quality management, quantitative process management) niveau 3 (process definition, software product engineering, intergroup co-ordination, integrated software management, process focus, training program, peer reviews) niveau 2 (requirements management, configuration management, project tracking and oversight, subcontract management, project planning, quality Assurance) niveau 1 Uitdagingen niveau 5 (still human intensive process, maintain organisation at optimizing level) niveau 4 (changing technology, problem analysis, problem prevention) niveau 3 (process measurement, process analysis, quantitative quality plans)

22 niveau 2 (training, technical practices, reviews, testing, process focus, standards, process groups) niveau 1 (project management, project planning, configuration management, software quality Assurance) Relatie CMM en ISO 9000 CMM - bedacht in de '80-er jaren aan het universitaire Software Engineering Institute in Amerika om de kwaliteit van software-ontwikkelprocessen te verbeteren - veronderstelt een groeipad voor procesbeheersing, dat langs vijf kwaliteitsniveaus (levels) naar een totaal beheerst proces loopt. ISO 9000 reeks zijn standaarden voor alle industriën. De meer specifiek de norm ISO 9001 richt zich op het ontwerp, de ontwikkeling en het onderhoud van een product. ISO is de toepassing van ISO 9001 op softwareontwikkeling en deze vereist in tegenstelling tot CMM een gedefinieerd kwaliteitsniveau voor de gehele procesorganisatie, waaruit bijvoorbeeld af te lezen valt wie waarop aangesproken kan worden en op welke wijze fouten worden gecorrigeerd of voorkomen. De norm is georganiseerd in een twintigtal kwaliteitsartikelen, waarvan een aantal overeenkomen met doelstellingen uit de CMM-levels. CMM of ISO 9001 algemene principes analoog sommige zaken enkel in ISO 9001, andere enkel in CMM CMM ruimer: blijven verbeteren gemakkelijker om vanuit CMM ISO 9001 te halen dan omgekeerd CMM is meer een verticaal procesmodel en ISO is bij uitstek een horizontaal organisatiemodel De ISO 9001:2008 is een norm die eisen stelt aan het kwaliteitsmanagementsysteem van een organisatie en de manier waarop de organisatie met het kwaliteitsbeleid omgaat. Zo moet bijvoorbeeld het kwaliteitsbeleid op papier staan en moet er gecommuniceerd worden naar alle medewerkers. De organisatie moet zorgen voor het verhogen van de klantentevredenheid door te voldoen aan de eisen en wensen van de klanten en aan de wettelijke eisen die van toepassing zijn op het product of de dienst van de organisatie. Daarnaast moet de organisatie de bedrijfsprocessen beheersen en dit kunnen aantonen. 12. Wat is software configuration management? (Te weinig uitleg?) Software Configuration Management (SCM) is het effectief tracken en controleren van varanderingen in de software, dit vereist drie zaken:

23 Identificatie (noemen van naam plus versienummer, elk deel dat onafhankelijk gebruikt of getest of verkocht kan worden, elke wijziging identificeren en versioneren, alles in één repository, soms kopieën in verschillende geografisch verspreide sites maar dan is wel periodische synchronisatie nodig) Communicatie (informatie over status van de taken, te doen/mee bezig/afgehandeld, wie doet welke taken) Kost controle (elke wijziging aanvragen en laten goedkeuren, prioriteiten, op elk ogenblik een zicht op de staat van het project) Hoe uit te voeren: Check-in, check-out ev via webinterface Build support (enkel gewijzigde delen opnieuw builden) Release support (bijhouden welke gebruikers welke versie van welke componenten) Problem and change management Proces management (ondersteuning voor kwaliteitsgarantie) Documentatie ontwikkeling 13. Wat zijn architecturale patronen? Geef enkele voorbeelden. Architecturale patronen zijn software patronen die efficiënte oplossingen beschrijven voor architecturale problemen in software engineering. Soorten Layers pattern (meest gebruikte) o Structureren van toepassingen die onderverdeeld kunnen worden in groepen van deeltaken, waarin elke groep zich op een specifiek niveau van abstractie bevindt. Pipes and Filters pattern: o Structureren van systemen die datastromen verwerken. Elke processtap is in een filterobject ondergebracht. Data wordt door pijpen tussen opeenvolgende filters doorgegeven. Recombineren van filters laat toe om gerelateerde systemen te bouwen. Blackboard pattern o Bruikbaar voor problemen zonder deterministische oplossingsstrategiën. Elk gespecialiseerd subsysteem gebruikt zijn kennis om een gedeeltelijke of benaderende oplossing te bouwen

24 o o komt uit AI-wereld (Artificial Intelligence) Vooral in onderzoek, als soort software nog niet welbekend is Voorbeelden Gedistribueerde systemen o Broker (instantie die verschillende services verdeelt) Interactieve systemen o Model-View-Controller (MVC): Model (managing van info) View (presentation) Controller (accept input, make calls to model & update view) o Presentation-Abstraction-Control (PAC) (hiërarchische structuur van componenten) Aanpasbare/herbruikbare systemen o o Microkernel Scripted components 14. Bespreek grondig het Singleton patroon Een ontwerppatroon die een maximum van één instantiatie (object) per klasse oplegt. Met dit ontwerppatroon is het mogelijk om de toegang tot bepaalde systeembronnen altijd via één object te laten gaan. Voorbeelden hiervan zijn een thread pool, logging, printer server, cache enz. Men zorgt ervoor dat maar één object kan aangemaakt worden door private maken van de constructor en met een methode getinstance die de instantie terug geeft of deze aanmaakt als dit nog niet gebeurd is. Er kunnen dan wel nog problemen optreden als men met verschillende threads werkt. Men kan dan de methode synchronized maken. Als de performantie niet van kritisch belang is dan maakt men de methode getinstance synchronized, anders maakt met de instantie onmiddellijk aan en geeft de methode getinstance enkel de instantie terug. Men kan ook de enkel de eerste oproep van de constructor synchronized maken.

25 Java cloning: creatie van objecten door cloning. (meer uitleg nodig) als singleton-class final en rechtstreeks afgeleid van Object: clone blijft protected en geen verdere overerving mogelijk als singleton-class erft van een class die clone() als public heeft overschreven en die Cloneable implementeert & overschrijf clone() en gooi CloneNotSupportedException op (overschrijven door this te returnen is de klant bedriegen en niet waterdicht als je reflectie gebruikt) Volatile object (private volatile static EenKlasse instantie;): een object dat synchronised is wanneer het word aangesproken. Bij het aanspreken van het object kan er nooit een Block optreden in tegenstelling tot een synchronized Block. Het object mag null zijn en als met dit object probeert te synchroniseren zal ere en NullPointerException opgeworpen worden. 15. Bespreek kort de Simple Factory, Factory Method & Abstract Factory patronen. Een factory is het omsluiten van code die objecten aanmaakt. Zo kunnen we werken met abstracties in plaats van éénduidige klassen of constructoren. Het Dependency Inversion Principle (DIP): Hogere lagen zouden niet mogen afhankelijk zijn van lagere lagen. Ze zouden zich beide moeten baseren op abstracties. Abstracties zouden niet afhankelijk moeten zijn van details. De details moeten afhankelijk zijn van de abstracties. Simple Factory (niet echt een ontwerppatroon, eerder een programmeer idioom, creatie van een object overlaten aan de klasse zelf, wijzigingen op één plaats kunnen aanbrengen, herbruikbaar) Factory Method (overerving van de klasse en de methode overschrijven, er wordt abstractie gemaakt van de methode maar naargelang het object zal de werking van de methode verschillen, welke methode opgeroepen wordt is afhankelijk van de meegegeven parameters) Abstract Factory (levert een interface voor de vervaardiging van reeksen gerelateerde of afhankelijke objecten zonder hun concrete klassen te specificeren. De code wordt zodanig geschreven dat deze de Factory gebruikt voor het aanmaken van deze objecten. Op deze manier kan een verscheidenheid aan objecten worden aangemaakt terwijl de cliëntcode ongewijzigd blijft) Voorbeeld met pizza s: createpizza geeft de correcte ingredientfactory door aan CheesePizza via de prepare(factory)- methode

26 Factory Method: orderpizza() roept createpizza (= factory method) op. The juiste createpizza() wordt opgeroepen door middel van polymorphisme. Als men een hiërarchie maakt voor factories spreekt men van polymorfe factories. Abstract Factory: Factory Methods voor ieder type ingrediënt (saus, kaas, deeg, ) Het verschil tussen een Factory Method en een Abstract Factory Factory Method maakt één object aan, kan terug gebracht worden tot een statische methode & de abstracte interface heeft vaak een methode die de factory-methode oproept. Een Abstract Factory maakt een familie gerelateerde objecten aan, heeft meerdere polymorfe methodes nodig & de client gebruikt het factory-object. 16. Bespreek grondig het Strategy patroon. Het Strategy patroon wil een aantal problemen van de statische overerving oplossen. Men probeert de zaken die veranderlijk zijn te scheiden van zaken die hetzelfde blijven. Gedragingen van een object die variëren worden in een interface geplaatst. Men programmeert naar interfaces toe en niet naar implementatie van de methoden. De basisklasse zal de gedragingen dan delegeren naar deze interfaces en zo kan men gemakkelijk functionaliteiten toevoegen (zelf at runtime!). Bij dit ontwerppattroon wordt dus de voorkeur gegeven aan compositie boven overerving, daarbij wint men aan flexibiliteit. (meer uitleg nodig?) Eendvoorbeeld: Voordelen: Behaviors toevoegen zonder Duck te veranderen, goed herbruikbaar, gedragingen veranderen at runtime (setflybehavior(flybehavior fb))

27 17. Bespreek de Adapter, Facade & Decorator patronen. Adapter: invoeren van een abstractie, client spreekt interface aan, adapter verbindt met adaptee. Facade: invoeren van een higher-level interface die de werking van een aantal interfaces groepeert. Decorator: toevoegen van functionaliteit aan één object en niet aan de klasse. Het Adapter patroon wil de client calls naar de interfaceklasse doorgeven naar een nieuwe specifieke interface, deze tweede interface zorgt er dan voor dat specifieke methoden opgeroepen worden. De tweede interface en de onderliggende werking kunnen dan eenvoudig vervangen worden zonder dat de clientcode gewijzigd moet worden. Client «interface» Duck +quack() +fly() TurkeyAdapter Turkey +quack() +fly() +gobble() +fly() Bij het Facade patroon wil men de werking van vele verschillende interfaces verbergen achter één grote interface. Er wordt voldaan aan de eisen van de client en de complexe werking van de onderliggende interfaces wordt verborgen. Het Facade patroon is ietwat gelijkaardig aan het Adapterpatroon omdat het client calls converteert, maar de hoofdbedoeling van het Facade patroon is om een complex subsysteem een eenvoudige interface te geven. Het Decorator patroon doelt erop om dynamisch functionaliteiten toe te voegen aan één enkel object van een klasse. Dit is onmogelijk door middel van overerving aangezien bij overerving de functionaliteit wordt overgenomen door ieder object van de klasse. De decorator of wrapper is een object met een identische interface als het object dat het bevat (als instantievariabele), de calls worden doorgegeven, eventueel met extra functionaliteit. Het gedecoreerde object heeft dus een andere identiteit. Men moet er wel op letten dat men de Component klasse lichtgewicht houdt en dat men enkel een abstracte Decorator maakt indien men meerdere verantwoordelijkheden nodig heeft, decorators kunnen trouwens sequentieel gecombineerd worden. Een goed voorbeeld hiervan is Java InputStream en BufferedInputStream.

28 18. Bespreek kort Service Oriented Architecture. Een service wordt gedefinieerd als: A loosely-coupled, reusable software component that encapsulates discrete functionality which may be distributed and programmatically accessed. A web service is a service that is accessed using standard Internet and XML-based protocols Service Oriented Architecture is een architecturaal patroon dat loosely coupled funtions groupeert in services, en deze services kunnen gedeeld worden over een netwerk zodat men ze kan hergebruiken en combineren tot grotere business applicaties. SOA wordt gezien als modular programming aangezien reeds geschreven software services gecombineerd worden. Men steunt op de platformonafhankelijkheid van de services. (UDDI) Service registry Find Publish Service requestor UDDI: Universal Description, Discovery and Integration SOAP: Simple Object Access Protocol WSDL: Web Services Description Language Voordelen Bind (SOAP) Service provider Service (WSDL) Services kunnen lokaal geleverd worden of uitbesteed aan externe leveranciers Services zijn taal-onafhankelijk Vroegere investeringen in legacy systemen gaan niet verloren (hergebruik van reeds geschreven systemen) eenvoudige informatie-uitwisseling vereenvoudigt inter-organisatorische computing In de eerste generatie SOA (zogenaamde client-server SOA) roepen de consumenten de service leveranciers rechtstreeks op (fat-client). De business logica bevond zich niet altijd op dezelfde plaats en dit vormde een probleem. De tweede generatie (SOA met Enterprise Service Bus) zorgde voor eenzelfde plaats van de middleware tussen client en server (requestor & provider), deze middleware (Enterprise Service Bus of ESB) bevat middle tier services die de uiteindelijke services oproepen. Services moeten niet noodzakelijk webservices zijn, door middel van adapters kan men ook andere services (her)gebruiken. Een middel tier service van de ESB bestaat meestal uit drie zaken: validation enrichement transformation. Controleren van binnenkomende data, evt. toevoegen van extra data, en het omzetten van data naar geschikte formaat voor de provider. Er zijn een aantal verschillende soorten services: een mediation service geeft de calls gewoon door, een orchestration service doet calls naar meerdere services & workflow services bevatten menselijke interacties.

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

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

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

Stichting NIOC en de NIOC kennisbank

Stichting NIOC en de NIOC kennisbank Stichting NIOC Stichting NIOC en de NIOC kennisbank Stichting NIOC (www.nioc.nl) stelt zich conform zijn statuten tot doel: het realiseren van congressen over informatica onderwijs en voorts al hetgeen

Nadere informatie

Software Engineering (I00094) College 3:

Software Engineering (I00094) College 3: Software Engineering (I00094) College 3: Kwaliteit, organisatie en documentatie Marko van Eekelen marko@cs.ru.nl kamer HG02.074 1 Huidige planning 1. 6 feb: Het systeemontwikkelproces 2. 13 feb: Requirements-analyse

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

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

Business Process Management

Business Process Management Business Process Management Prof. dr. Manu De Backer Universiteit Antwerpen Katholieke Universiteit Leuven Hogeschool Gent Wat is een bedrijfsproces? Een verzameling van (logisch) gerelateerde taken die

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

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

Cursus Software Architecture (T32311 en T32811)

Cursus Software Architecture (T32311 en T32811) Software Architecture, T 32311 en T32811 Cursus Software Architecture (T32311 en T32811) Dit tentamen bestaat uit 3 vragen, waarbij vraag 1 en vraag 3 elk uit 2 deelvragen bestaan. Voor dit tentamen kunt

Nadere informatie

IT Service CMM. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

IT Service CMM. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. IT Service CMM Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 2 GESCHIEDENIS EN ACHTERGROND...

Nadere informatie

Capability Maturity Model. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

Capability Maturity Model. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. Capability Maturity Model Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 11 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...FOUT!

Nadere informatie

Integratie in de praktijk

Integratie in de praktijk Integratie in de praktijk Werken als integratie consultant bij KLM Werken als integratie consultant bij KLM T. Lansbergen A. Kwekel Hogeschool Rotterdam 13/10/2015 Agenda Introductie - Organisatie Use

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

IT Service CMM. White paper. Frank Niessink. Versie 1.0.2, 30 november 2001. Copyright 2001 Software Engineering Research Centre All rights reserved.

IT Service CMM. White paper. Frank Niessink. Versie 1.0.2, 30 november 2001. Copyright 2001 Software Engineering Research Centre All rights reserved. White paper Frank Niessink Versie 1.0.2, 30 november 2001 Copyright 2001 Software Engineering Research Centre All rights reserved. Software Engineering Research Centre Stichting SERC Postbus 424, 3500

Nadere informatie

Model driven Application Delivery

Model driven Application Delivery Model driven Application Delivery Fast. Flexible. Future-proof. How Agis streamlines health procurement using Mendix Model driven Application Platform Mendix in a nutshell Mendix delivers the tools and

Nadere informatie

Capita Selecta Design Patterns voor administratieve applicaties

Capita Selecta Design Patterns voor administratieve applicaties Capita Selecta voor administratieve applicaties Bij afstudeerproject: Generiek framework voor administratieve toepassingen in een webgeörienteerde omgeving Henk van de Ridder 26 augustus 2006 Inhoud 26

Nadere informatie

Informatica 2 Studiehandleiding

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

Nadere informatie

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

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

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

Continuous Delivery. Sander Aernouts

Continuous Delivery. Sander Aernouts Continuous Delivery Sander Aernouts Info Support in een notendop Maatwerk softwareontwikkeling van bedrijfskritische kantoorapplicaties Business Intelligence oplossingen Managed IT Services Eigen Kenniscentrum

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

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Evo Evolutionary Project Management Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING... 3 2. EVO... 4 3. FASERING...

Nadere informatie

Technisch ontwerp. Projectteam 6. Project "Web Essentials" 02 april 2009. Versie 2.1.0

Technisch ontwerp. Projectteam 6. Project Web Essentials 02 april 2009. Versie 2.1.0 Projectteam 6 Faculteit Natuur en Techniek Hogeschool Utrecht Projectleider: Hans Allis, hans.allis@student.hu.nl Technisch ontwerp Project "Web Essentials" 02 april 2009 Versie 2.1.0 Teamleden: Armin

Nadere informatie

1.7 Ontleding van het eerste programma... 14

1.7 Ontleding van het eerste programma... 14 Inhoudsopgave 1 Inleiding 1 1.1 Wat kan je met Java doen?..................... 1 1.2 Over Java............................... 3 1.3 Gebruik van dit boek......................... 5 1.4 Installatie...............................

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

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

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

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

De architect: in spagaat tussen mensen en technische details. Illustratie met een simpel voorbeeld

De architect: in spagaat tussen mensen en technische details. Illustratie met een simpel voorbeeld De architect: in spagaat tussen mensen en technische details Illustratie met een simpel voorbeeld Illustratie van stap voor stap naar een architectuur aan de hand van een voorbeeld Overview Exercise Assistant:

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

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil eagileagileagileagileagileagileagileagi leagileagileagileagileagileagileagileag

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

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

Factsheet CONTINUOUS VALUE DELIVERY Mirabeau

Factsheet CONTINUOUS VALUE DELIVERY Mirabeau Factsheet CONTINUOUS VALUE DELIVERY Mirabeau CONTINUOUS VALUE DELIVERY We zorgen ervoor dat u in elke volwassenheidsfase van uw digitale platform snel en continu waarde kunt toevoegen voor eindgebruikers.

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

Betekent SOA het einde van BI?

Betekent SOA het einde van BI? Betekent SOA het einde van BI? Martin.vanden.Berg@sogeti.nl 18 september 2007 Agenda Wat is SOA? Wat is BI? Wat is de impact van SOA op BI? Sogeti Nederland B.V. 1 Agenda Wat is SOA? Wat is BI? Wat is

Nadere informatie

doel bereikt zelfsturing inrichten veiligheid fundament Behoeftepiramide van een "Social Business"

doel bereikt zelfsturing inrichten veiligheid fundament Behoeftepiramide van een Social Business Behoeftepiramide van een "" (Naar analogie piramide van Maslow) Maslow rangschikte de volgens hem universele behoeften van de mens in een hiërarchie. Volgens zijn theorie zou de mens pas streven naar bevrediging

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

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

Risk & Requirements Based Testing

Risk & Requirements Based Testing Risk & Requirements Based Testing Tycho Schmidt PreSales Consultant, HP 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Agenda Introductie

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

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

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

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

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

Handout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA.

Handout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven Johan Zandhuis SYSQA Start: 1999 Onafhankelijk Quality Assurance in IT 150 medewerkers (en groeiend) 2 SYSQA Operationeel

Nadere informatie

Stichting NIOC en de NIOC kennisbank

Stichting NIOC en de NIOC kennisbank Stichting NIOC Stichting NIOC en de NIOC kennisbank Stichting NIOC (www.nioc.nl) stelt zich conform zijn statuten tot doel: het realiseren van congressen over informatica onderwijs en voorts al hetgeen

Nadere informatie

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

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

Nadere informatie

Oplossingen Examenvragen Software Engineering

Oplossingen Examenvragen Software Engineering Oplossingen Examenvragen Software Engineering 1. Wat is software engineering? Het instellen en gebruiken van gezonde ingenieursprincipes om economisch verantwoorde software te verkrijgen dat betrouwbaar

Nadere informatie

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

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

Nadere informatie

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

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

End-to-End testen: de laatste horde

End-to-End testen: de laatste horde End-to-End testen: de laatste horde Dieter Arnouts Agenda Begrip End-to-End testen in het test proces Praktische aanpak End-to-End Test Omgeving Uitdagingen End-to-End testen: De laatste horde 11/10/2010

Nadere informatie

Tips & Tricks: Tip van de maand januari 2009

Tips & Tricks: Tip van de maand januari 2009 Tips & Tricks: Tip van de maand januari 2009 Project Management met Teamcenter 2007 Door: Ramon van Raak Beheert u complexe projecten dan weet u als geen ander dat de projectvoorbereiding de basis legt

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

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

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

Nadere informatie

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

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

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

Een Project Management model. Wat is IASDEO?

Een Project Management model. Wat is IASDEO? Een Project Management model Project Management betekent risico s beheersen, voldoen aan allerlei vereisten, klanten tevreden stellen, beslissingen nemen, producten leveren, activiteiten coördineren, inputs

Nadere informatie

Is APEX a worthy substitute for Oracle Forms?

Is APEX a worthy substitute for Oracle Forms? your oracle solu+ons partner Is APEX a worthy substitute for Oracle Forms? APEX for mission critical applications: the Groupm business-case By Ronny Boeykens & Stijn Van Raes iadvise o Opgericht in 2004

Nadere informatie

Distributed Systems Architectures

Distributed Systems Architectures Distributed Systems Architectures Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 12 Slide 1 Topics covered Multiprocessor architectures Client-server architectures Distributed object architectures

Nadere informatie

Software Design Document

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

Nadere informatie

Enterprise Architectuur de link tussen Business & ICT

Enterprise Architectuur de link tussen Business & ICT Enterprise Architectuur de link tussen Business & ICT Oriented Architecture (SOA) Nieuwe hype? Of. Jaap Schekkerman, B.Sc. Opinion Leader, Verdonck, Klooster & Associates President & Founder, Institute

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

Programmeren. Inleiding

Programmeren. Inleiding Programmeren Inleiding STAPPEN IN DE ONTWIKKELING VAN EEN PROGRAMMA 1. Probleem 1. Probleem Ideaal gewicht berekenen Wortel van een vierkantsvergelijking berekenen Schaakspel spelen Boekhouding doen 2.

Nadere informatie

Tim Mallezie Architectuur van besturingssystemen: Vraag A2.

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

Nadere informatie

Conclusie: voor elke organisatie die dit nastreeft is het goed besturen en beheersen van de bedrijfsprocessen

Conclusie: voor elke organisatie die dit nastreeft is het goed besturen en beheersen van de bedrijfsprocessen 1 Waarom? : Succesvol zijn is een keuze! Organisaties worden door haar omgeving meer en meer gedwongen om beter te presteren. Voornamelijk wordt dit ingegeven door de klant die haar eisen en wensen m.b.t.

Nadere informatie

Stuurgroep ICT innovatie in de ouderenzorg. 12 oktober 2010

Stuurgroep ICT innovatie in de ouderenzorg. 12 oktober 2010 Stuurgroep ICT innovatie in de ouderenzorg 12 oktober 2010 Agenda High Level Scope Projectorganisatie en werkingsprincipes Projectplanning en roll-out Projectopvolging Evaluatie diensten Agenda volgende

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

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

Dit voorbeeldproject beschrijft het gebruik van web services (open standaarden) voor de ontsluiting van kernregistraties bij de gemeente Den Haag.

Dit voorbeeldproject beschrijft het gebruik van web services (open standaarden) voor de ontsluiting van kernregistraties bij de gemeente Den Haag. Voorbeeldproject Een Haagse SOA Dit voorbeeldproject beschrijft het gebruik van web services (open standaarden) voor de ontsluiting van kernregistraties bij de gemeente Den Haag. Aanleiding Vanuit de visie

Nadere informatie

gewoon Start Event (Gebeurtenis) Deze lege cirkel, met dunne rand, geeft de aanvang (start) van het proces weer.

gewoon Start Event (Gebeurtenis) Deze lege cirkel, met dunne rand, geeft de aanvang (start) van het proces weer. BPMN 1.2 basis elementen en hun betekenis, core 2 Onderstaande tabel geeft een overzicht van de meest gangbare basis elementen van BPMN met telkens een beknopte toelichting. Hiermee kan men aan de slag

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

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

Master Software Engineering. Inhoud, begeleiding, tentamen dr. Anda Counotte Docent en mentor

Master Software Engineering. Inhoud, begeleiding, tentamen dr. Anda Counotte Docent en mentor Master Software Engineering Inhoud, begeleiding, tentamen dr. Anda Counotte Docent en mentor Thema Software Architectuur Design Patterns (DP) ir. Sylvia Stuurman, dr.ir. Harrie Passier en dr. Bastiaan

Nadere informatie

Kenmerken van DLArchitect

Kenmerken van DLArchitect Kenmerken van DLArchitect Bert Dingemans, e-mail : bert@dla-os.nl www : http://www.dla-os.nl 1 Inhoud KENMERKEN VAN DLARCHITECT... 1 INHOUD... 2 INLEIDING... 3 ARCHITECTUUR... 3 Merode... 3 Methode en

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

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

Agile systeemontwikkeling. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Agile systeemontwikkeling. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Agile systeemontwikkeling Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Terminologie... 4 3. Uitgangspunten...

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

Procestool; sleutel tot succes?

Procestool; sleutel tot succes? Procestool; sleutel tot succes? Gerard Hebenaar Gerard Hebenaar Adviesgilde 1 Even voorstellen.. Gerard Hebenaar Bedrijfskunde Adviesvaardigheden 15 jaar ervaring in de consultancy Verkoop en advies van

Nadere informatie

Hoe zeggen wat men niet wil horen

Hoe zeggen wat men niet wil horen Hoe zeggen wat men niet wil horen Developer training Drupal 16-03-2011 06-06-2011 Joris Henk Snoek van Cann Henk van Cann Managers willen kunnen praten met de IT-ers/Drupalistas. Hen begrijpen en ook horen

Nadere informatie

Extended ISO 9126: 2001. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Extended ISO 9126: 2001. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Extended ISO 9126: 2001 Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3

Nadere informatie

Software Project Management Plan

Software Project Management Plan Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn inhoud. Het

Nadere informatie

Scrum. Een introductie

Scrum. Een introductie Organisatie SYSQA B.V. Pagina 1 van 10 Scrum Een introductie Almere 1999 Proud of it Pagina 1 van 10 Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 Inleiding... 3 2 Scrum... 4 3 Scrum rollen...

Nadere informatie

Als een PSD selecties bevat, deelt de lijn van het programma zich op met de verschillende antwoorden op het vraagstuk.

Als een PSD selecties bevat, deelt de lijn van het programma zich op met de verschillende antwoorden op het vraagstuk. HOOFDSTUK 3 3.1 Stapsgewijs programmeren In de vorige hoofdstukken zijn programmeertalen beschreven die imperatief zijn. is het stapsgewijs in code omschrijven wat een programma moet doen, net als een

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

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

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

ISO 9000:2000 en ISO 9001:2000. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

ISO 9000:2000 en ISO 9001:2000. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. ISO 9000:2000 en ISO 9001:2000 Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 11 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

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

1 Wat is software engineering? Teken en leg uit: klassieke levenscyclus, prototyping en spiraalmodel.

1 Wat is software engineering? Teken en leg uit: klassieke levenscyclus, prototyping en spiraalmodel. Oplossing examenvragen Software Ingenieurstechnieken 1 1 Wat is software engineering? Teken en leg uit: klassieke levenscyclus, prototyping en spiraalmodel. 1.1 Software Engineering Software Engineering

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

Richtlijnen voor het ontwerpen een Intranetportal Door Bas Fockens

Richtlijnen voor het ontwerpen een Intranetportal Door Bas Fockens Richtlijnen voor het ontwerpen een Intranetportal Door Bas Fockens Copyright Datacon www.datacon.nl Wat is een intranetportal? Een intranet is een online gepersonaliseerde en geïntegreerde toegang tot

Nadere informatie