Examenvragen theoriegedeelte Software Engineering (2007-08) 07/06/2010 - W.S. - 3 ELICTI
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.
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.
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
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
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)
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)
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)
•
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
•
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
•
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.
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.
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.
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
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. 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”,
”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
•
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)
•
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 9000. 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)
•
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
Productiviteit (efficiëntie & performantie van proces)
o
(Stiptheid of timeliness: on-time-to-market)
o
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)
•
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
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)
•
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 9000-3 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:
•
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
•
Pipes and Filters pattern: o
•
Structureren van toepassingen die onderverdeeld kunnen worden in groepen van deeltaken, waarin elke groep zich op een specifiek niveau van abstractie bevindt.
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
o
komt uit AI-wereld (Artificial Intelligence)
o
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
Microkernel
o
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.
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
•
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))
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 +quack() +fly()
Turkey +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.
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
Service requestor
Publish
Bind (SOAP)
Service provider
Service (WSDL)
UDDI: Universal Description, Discovery and Integration SOAP: Simple Object Access Protocol WSDL: Web Services Description Language Voordelen •
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.
19. Bespreek kort Aspect Oriented Programming & Software Development. Bij Aspect Oriented Programming (AO) is het hoofddoel om het programma op te delen zodat er zo weinig mogelijk functionele overlapping is. Cross-cutting concerns komen in een stand-alone module (aspect) terecht. Deze aspecten kunnen advice bevatten, een functionaliteit die hoort bij een soort module. Een pointcut is het ogenblik waarop een aspect en het programma samenkomen, dit noemt men een join point. Een join point kan een methodeoproep zijn of het uitvoeren van een methode, het instellen van een waarde (setten van een veld) of het afhandelen van een exception. •
Het Joint Point Model definieert wanneer een advice kan lopen, definieert de manier van specifiëren van join points (met pointcuts) & definieert de manier om de code te specificeren die op de join point moet lopen. Pointcuts selecteren enkel de join points, een advice implementeert het crosscutting-gedrag. Het advice brengt de selectie van een join point (pointcut) en de code die uitgevoerd moet worden samen.
•
Advice kan verschillende vormen aannemen. Before advice wordt gerund als een join point bereikt is, voor de advice methode opgeroepen wordt. After advice is de code die uitgevoerd wordt na de method call. Around advice wordt zoals before advice ook gerund als het join point bereikt is, en heeft de controle over het al dan niet uitvoeren van het join point.
•
Aspects groeperen crosscutting concerns, ze kunnen pointcuts bevatten alsook advice.
•
Door middel van tracing kan men de internet werking van het programma weergeven, dit geeft een duidelijk beeld en vergemakkelijkt het invoeren van verbeteringen. bv. System.out.println("Entering: " + thisJoinPoint);
•
Voorbeeld van een bank: Bankrekening (aspect), uitvoeren van security check (advice in security-module), toegang tot bankrekening (join point).
Aspect Oriented Software Development is een techniek voor systematische identificatie, modularisatie en compositie van crosscutting concerns tijdens het gehele proces van software ontwikkeling (requirements – specification – design – implementation – evolution). •
Men moet aspectgeoriënteerd beginnen denken vanaf het moment dat requirements opgesteld worden, tijdens de gehele ontwikkeling moet men blijven aspectgeoriënteerd blijven denken. Het houdt in dat men het programma opdeelt in verschillende afgeleinde delen, de zogenaamde concerns, samenhangende wat betreft functionaliteit. Ieder deel heeft een soort van encapsulatie en abstractie tegenover de andere delen.
•
De architectuur van een AO systeem is gebaseerd op een core system & extensions. Het core system zorgt voor de hoofd concerns. Extensions implementeren de secundaire concerns & crosscutting concerns (die abstractie niet mogelijk maken).
•
Soorten extensions die gebruikt worden zijn: o o o o
Secondary functional extensions (toevoegen van extra functionaliteiten aan het core system) Policy extensions (functionaliteiten toevoegen aan bv. security) QoS extensions (functionalteit toevoegen om de quality of service requirements te behalen) Infrastructure extensions (functionaliteit voor de implementatie op een specifiek platform)
20. Wat zegt de wetgeving i.v.m. auteursrecht voor programma’s & databanken? Wat van het auteursrecht geeft aan de auteur het alleenrecht om zijn werk te verveelvoudigen, te verspreiden, verhuren, uitlenen, aanpassen of vertalen. Het werk mag wel gebruikt worden binnen familiekringen, onderwijs of voor tentoonstellingen op publieke plaatsen, reproductie is toegelaten voor privé gebruik of voor wetenschappelijk onderzoek. •
Over computerprogramma’s zegt de wetgeving dat de auteur alleenrecht heeft op de code, niet op de functionaliteit. Indien iets maar op één manier technisch mogelijk zou zijn, is het gebruiken van de originele code geen schending. Het programma moet nieuw zijn, en als de code geschreven is door een werknemer behoor het recht aan de werkgever, tenzij anders vermeld in het contract.
•
Een softwareprogramma mag gereproduceerd of aangepast worden indien dit noodzakelijk is voor het gebruik (debug, backups, familie, collega’s) indien dit overeenkomstig is met de licentieovereenkomst.
•
Volgens de EG-richtlijn moet de wisselwerking met andere programma’s mogelijk gemaakt worden (om monopolie tegen te gaan).
•
Een programma mag geanalyseerd, maar niet gedecompileerd worden. Tenzij decompilatie nodig is voor het verkrijgen van de functionaliteit.
Het auteursrecht op databanken zegt dat de inhoud slechts beschermd is als het gaat over originele teksten of foto’s, feitenmateriaal zoals bijvoorbeeld adresgegevens en beurskoersen en ook officiële akten zijn niet beschermd door het auteursrecht. De opbouw van de databank is enkel beschermd als dit een creatieve selectie van materiaal is, of als de databank gemaakt is met een originele ordening of structuur. •
Het verzamelen van feitenmateriaal kan een grote investering vereisen. Daarom is het binnen de EG mogelijk om de opvraging of het hergebruik van deze gegevens te verbieden voor 15 jaar. Deze vijftien jaar kan hernieuwd worden als men een belangrijke investering doet. Onderwijs en wetenschappelijk onderzoek zijn weer een uitzondering op deze regel.
